[es2]

Problem jaki widzę w Arduino to ograniczenia samego procesora - czyli jedna pętla,
brak jakiejkolwiek wielozadaniowości itd.

Problemem jest nie Arduino, które od początku (IDE )do końca (C++ na 2kB RAM) to nieporozumienie, ale programista, który nie potrafi uruchomić RTOS'sa.

Problem jaki widzę to zdarzenia które długo trwają - jak np. odczyt temperatury z DS18B20
- trwa prawie sekundę, w czasie której można tylko czekać, a jeśli zdarzy się błąd pomiaru
to trzeba go ponowić...

Kolejny przykład ułomności programisty.
Jaki problem obsłużyć 1-Wire przez UART na przerwaniach? Obciążenie uC poniżej 1%.

Na AVR 20MHz robiłem rzeczy, których nie powstydziłby się ARM.
Dekodowanie DMX w "tym samym czasie" sterowanie do 1000 LED WS2812, wysyłanie DMX. Zrobiłem nawet gry aby zademonstrować co da się zrobić na AVR::
https://www.youtube.com/watch?v=h2RKAJZdVl4
https://www.youtube.com/watch?v=aM9hy4EpleY

Jak więc widać, AVR ma spore możliwości. Niestety, mało RAM, brak DMA zmusił mnie do odejścia od tych uC, które owszem, 20 lat temu były dobre, teraz są powolne, mają małe zasoby i co najgorsze, są stosunkowo drogie! Nawet bardzo drogie (AtMega2560 vs 10 czy 100 razy lepszy ARM).


PS
Co do RTOS, to na AVR widzę jego w miarę sensowne wykorzystanie na Mega1284 (16kB RAM), ostatecznie Mega2560 (8kB RAM), bo jak wiadomo, RTOS lubi RAM. Z tego powodu, na AVR, robi sie wielowątkowość, wystarczy oduczyć się "dealy" i "while{ coś się wydarzy}". Niestety, wysyłając szybko po SPI, trzeba kręcić się w pętli, bo wejście/wyjście w IRQ to dużo czasu. Problem rozwiązuje DMA, np Xmega, ale one są drogie i mają mało RAM i nie da sie zrobić bufora na większe, kolorowe LCD. Wybór jest prosty - ARM.