Szukaj na Elektrodzie ale pierwotnie wątek miał być dla początkujących lecz przerodził się w dyskusję kompletnie nie związaną z tematem.
Po swoich doświadczeniach, mogę stwierdzić, że jesteś skazany na siebie ale jak będziesz potrzebował pomocy, to chyba tylko fora zagraniczne i Elektroda. Tu i na Forbocie, moim zdaniem (i doświadczeniem) nie masz na co liczyć.
(28-06-2019, 17:32)PierwszyWolnyLogin napisał(a): Chciałbym się zabrać za ten temat...
Tak z ciekawości, jak chcesz "pożenić" Arduino i RTOS?
Nie twierdzę, że się nie da, pamiętaj jednak, ze bez debugera będziesz długo walczył, a Arduino IDE nie wspiera debugera. Twórcy Arduino,m założyli, że Arduinowcy są nieomylni i debuger jest zbędny.
Kolejna sprawa, wielkość pamięci RAM. Gdy czytam Arduino, bez dodatkowych informacji, zakładam Arduino UNO. 2kB RAM to za mało dzisiejszych czasach na jakiś sensowny projekt zrealizowany zgodnie ze "sztuką" a co dopiero RTOS? RTOS, jak każdy system wielozadaniowy lubi RAM. Nie to, ze się nie da, ale po co się męczyć, jak zamiast Mega328, można użyć ok 100 razy szybszego, tańszego, lepiej wyposażonego (między innymi w pamięć RAM) ARM?
Proponuję STM32, CUbeMX, który wygeneruje kod, także dla RTOS. Napisałem tylko pobieżnie o sensie użycia (zwłaszcza z RTOS) ARM, więcej:
- ARM pzeważnie są tańsze niż AVR o podobnym wyposażeniu oferując zdecydowanie większe możliwości (DMA) i prędkość działania
- ARM, przy tym samym zegarze jest ok 7 razy szybszy od AVR, a maksymalne częstotliwości taktowania zaczynają się od 24MHz a kończą na 650 (w przypadku rodziny STM32.
- W przeważającej większości mają więcej pamięci RAM i można robić duże bufory nadawcze dla UART, I2c, SPI, USB.
- Maja bogatsze wyposażenie (liczba usart, I2C, SPI, timerów) i większe możliwości tychże peryferii.
- Mają DMA (AVR ATmega/tiny nigdy o czymś takim nie słyszały).
- Wiele ARM ma USB, w AVR to rzadkość.
- Wersje z Ethernetem, AVR nie ma z ETH.
- Wszystkie timery 16-bit (można łączyć w 32-bit) a wiele wersji posiada 32-bit.
- AC 12..16-bit, CA 12-bit.
- AC do 80MS/s (LPC), 18MH/s (STM32).
- Mają wielopoziomowy system przerwań.
- Tańsze narzędzia (debuger).
- Podczas debugowania na bieżąco widzę stan zmiennych w AVR po zatrzymaniu uC.
- CubeMX do konfigurowania i generowania kodu (najnowszy także IDE i kompilator).
- Nie muszę się zastanawiać czy dana jest w ram czy flasch aby użyć stosownej funkcji (z sufiksem _P).
- argument liczbowy w sprintf, scanf itp nie jest ograniczony do 16-bit int lecz do 32-bit.
- przesuwane bitu (w lewo) nie jest ograniczone do 16 bitów.
- Zdecydowanie większe pojemności pamięci FLASH (do 2MB) i RAM (do 1MB) o czym nawet AVR Xmega mogą tylko pomarzyć.
Dla początkujących:
https://stm32.eu/2019/01/31/nowa-ksiazka...-dostepna/
Czemu "naciskam" na DMA?
To będzie widać w poniższych linkach, ale ważniejsze, że brak DMA często "zabija" zalety RTOS. Nawet ARM nie lubi przerwań 300'000razy na sekundę (AVR się dławi - obciążenie CPU 80..90% przy 20MHz). Zakładam, że wiesz jak się oblicza obciążenie CPU?
ARM vs AVR:
Przykładowo, wysyłanie danych do WS2812 w przypadku Arduino (nie ważne AVR, ARM czy ESP) blokuje CPU na czas tej operacji. Nie wiem jak w przypadku ESP i ARM ale w AVR blokowane są przerwania. To oznacza, że w tym czasie nie będą np odbierane znaki przez UAR, nie działa USB, itp. Transmisja do LED może trwać nawet kilkadziesiąt ms. W ARM, sama transmisja będzie trwać tyle samo ale CPU będzie zajęty tylko przez kilkaset ns bo wysyłaniem danych zajmuje się DMA.
To samo z LCD, w AVR CPU zajęty 100% w czasie wysyłania danych (typowo 20..40ms w przypadku kolorowego wyświetlacza), na ARM us.
Wysyłanie na AVR danych do wyświetlacza w czasie dziesiątek ms jest możliwe, że ma wymaganą ilość pamięci RAM na bufor. Wyświetlacz 96x64 wymaga 12'288bajtów RAM (z Mega w grę wchodzi tylko Mega1284), 128x128 wymaga 32kB RAM, więc Mega odpada. Wymusza to stawianie punktu po punkcie, co zajmuje ok 3 razy więcej czasu.
Namacalne dowody:
https://www.elektroda.pl/rtvforum/topic3588785.html
Zainstalowałem bibliotekę „TFT_ILI9163C-master” ze strony „Nettigo”. Uruchomiłem przykład „Cube”, efekty widać na filmie.
https://es2.000webhostapp.com/Szescian_3...no_UNO.mp4
Zagoniłem do pracy ARM STM32F411CE. Zegar ustawiłem na 60MHz, co pozwoliło taktować SPI częstotliwością 15MHz, maksymalną dopuszczalną dla IL9306. Przeniosłem bibliotekę z Arduino, oto efekt:
https://es2.000webhostapp.com/Szescian_3...ez_DMA.mp4
Słaby coś ten ARM, animacja niewiele szybsza (użyłem HAL, gdyby wykorzystać dostęp rzez rejestry animacja byłaby prawie 2 razy szybsza niż na UNO). Nie, to nie ARM słaby tylko programista, który przeniósł kod nie wykorzystując możliwości sprzętowych ARM. Stworzyłem bufor na dane dla wyświetlacza (128*160*2=40960bajtów) i zagoniłem do pracy DMA. Efekt:
https://es2.000webhostapp.com/Szescian_3D_ARM_z_DMA.mp4
Na koniec porównanie ARM z AVR, gdzie na AVR wyraźnie widać rysowanie tła podczas jego zmiany.
https://es2.000webhostapp.com/Szescian_3...vs_AVR.mp4
https://es2.000webhostapp.com/Szescian_3...ne_tlo.mp4
Wracając do RTOS w ogóle. Wielokrotnie moderatorzy (który wyrośli bardzo szybko z amatorów dalay-owców) uświadamiali mnie , że forum Arduino Polska jest dla amatorów a tu widzę pełen profesjonalizm. Skoro chcesz się zabrać za RTOS, to z pewnością:
- Biegle posługujesz się przerwaniami od każdego możliwego układu peryferyjnego zarówno podczas nadawania jak i odbioru.
- Nie masz delay i pętli oczekującej na zdarzenie np
- Programy realizujesz w oparciu o maszynę stanów.
- Potrafisz synchronizować zdarzenia z różnych pseudowątków pomiędzy sobą (w RTOS będzie trudniej, mutex'y, semafory, kolejki) oraz pomiedzy przerwaniami a programem głównym.
Jeśli powyższe znasz bardzo dobrze, mogę pomóc w sprawie RTOS.