brew pozorom te "zabawki" cieszą się dużym uznaniem modelarzy nie tylko w Polsce.
Cieszą, dopóki nie poniosą strat. Wielu cieszy się z Windows dopóki efekt kilku lat pracy nie przepadnie albo stracą długie godziny a nawet dni (np ponowna inmstalacja tego pseudosystemu, dużej liczby programów i ich skonfigurowanie). Ileż to razy szukałem błędu nie tam gdzie trzeba bo Window$ zawiódł. Ile godzin tracę na ciągłe restarty.
Z arduinowymi wynalazkami jest podobnie, na stole, u autora, wszystko pięknie działa w realu zawodzi w najmniej oczekiwanym momencie.
Cóż wart jest program, w którym w ciągu 10 minut znalazłem kilka rażących błędów? Błędów, które dyskwalifinują taki program z komercyjnego użytku. Gdybym mu się przyjrzał dokładnie pewnie powstała by długa lista.
A to, że programy są takie jakie są, to już w pewnym stopniu urok otwartego oprogramowania i osób go wspierających.
Po co więc było namawiać mnie na otwarte oprogramowanie dekodera? Aby działał gorzej? Tematem
http://forum.modelarstwo.info/threa...emade-projekt-otwartego-oprogramowania.50655/ udowodniłem chyba , że idea otwartego kodu nie ma sensu, a do tego dochodzi problem sprzętu. Kto będzie chętny wyłożyć kasę na kilka iteracji PCB, elementy aby później na tym nie zarobić?
Rozwiązania Arduino to demo, pokazujące możliwości mikrokontrolerów ale nie nadające się do praktycznego użytkowania. Takie demo, które zostało stworzone w np 5 dni, wymaga miesięcy na dopracowanie i testy. Nie sądzę, aby ktoś napracował się, stracił kasę na zakup urządzeń do testu i udostępnił to za free.
W moich i nie tylko moich programach, ok 70% to kontrola błędów i diagnostyka, w kodach arduino kontrola błędów to rzadkość.
Mogę się założyć o co chcesz, że praktycznie wszystkie arduinowe rozwiązania nie zostały sprawdzone w skrajnych warunkach pracy. W efekcie u autora urządzenie działa u innych po japońsku (jako-tako) lub wcale.
Natomiast bardzo dobra jest do programowania dekoderów. Pozwala odczytać CV-ki, co powoduje
że nie programujemy dekodera w ciemno.
Chyba wszystkie współczesne centralki mają taką możliwość. Nawet historyczne homemade NanoX ma odczyt CV, więc co to za argument?
Pozwala sterować jedną lokomotywą z dźwiękiem.
To akurat istotna wada pokazująca, że arduinowe rozwiązanie to demo, zabawka, nienadająca się do praktycznego użytku. Darmowe NanoX obsługuje 16 lokomotyw.
Podsumowując rozwiązanie na Arduino, dlaczego jest złe?
- Wybór ArduinoUNO z AVRmega328p. AVR jest droższy od setki razy lepszego ARM STM32.
- Kodu nie da się łatwo przenieść na inne niż zgodne z rodzina AVRmega328p mikrokontrolery bo użyto (bez ładu i składu, np w formie jednego pliku dołączanego) bezpośredniego dostępu do rejestrów. Magia przenośności kodu pomiędzy platformami Arduino prysła!
- Rażące błędy w kodzie.
- Przestarzały i drogi driver L298 (pewnie tylko taki autor miał w szufladzie).
Gdybym potestował arduinowe DCC pewnie znalazłbym dziesiątki kolejnych błędów czy niedociągnięć.
Ten wątek nie dotyczy dekodera, tym bardziej dźwiękowego..
