@Jarewa0606 wyjaśnił problem. Jak chcesz czegoś więcej niż zabawy porzuć AVR. Może nie zauważyłeś ale GCC na AVR praktycznie się nie rozwija i ma ogromne ograniczenia, jak wspomniany tu doble-float czy ograniczenie prawie wszystkiego do 16-bit więc nie działa << 16.
Porzuć AVR na rzecz lepszych i przy okazji tańszych ARM no chyba, że jesteś wyznawcą MK.
Używam ARM bo:
- ARM przeważnie są tańsze niż AVR o podobnym wyposażeniu oferując zdecydowanie większe możliwości (DMA, więcej bardziej zaawansowanych niż w AVR peryferii) i szybkość 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/UART, I2C, SPI, timerów) i większe możliwości tychże peryferii. 12 UART w STM32 nie jest problemem, AVR max 4. Można dołożyć np SC16IS7xx ale 1 UART to ok 10zł, 2 ok 19zł).
- Mają DMA (AVR ATmega/tiny nigdy o czymś takim nie słyszały).
- Wiele ARM ma USB, w AVR to rzadkość a USB jest teraz pewnym standardem.
- Sprzętowe sterowanie przepływem i kierunkiem transmisji (RS485), wykrywanie końca ramki, określanie prędkości transmisji.
- Wersje z Ethernetem, AVR nie ma z ETH.
- Wszystkie timery 16-bit (można łączyć w 32-bit) a wiele wersji posiada 32-bit.
- ADC 12..16-bit, CA 12-bit.
- ADC do 80MS/s (LPC), 18MS/s (STM32).
- Mają wielopoziomowy system przerwań (15 poziomów, Xmega tylko 3, Mega/Tiny 0 ale najnowsze wersje maja już 2/3 poziomy).
- Zdecydowanie większe pojemności pamięci FLASH (do 2MB) i RAM (do 1MB) o czym nawet AVR Xmega mogą tylko pomarzyć.
- Sprzętowe interfejsy CAN, LCD równoległe, matryce LCD kolor 18-bit.
- Stany wyjątkowe: Błąd magistrali i podobne jak w MC68k (dawne MAC, Amiga).
- Kilkadziesiąt razy tańsze narzędzia. Ddebuger STM32 - 13zł vs badaj najtańszy klon JTAG-ICE 45zł (tylko JTAG), ATATMEL-ICE-PCB 300zł, w obudowie 700 (Basic 470zł), Dragon ok 450zł.
- CubeMX do konfigurowania i generowania kodu (najnowszy także IDE i kompilator).
- Podczas debugowania na bieżąco widzę stan zmiennych w AVR po zatrzymaniu uC.
- Nie muszę się zastanawiać czy dana jest w ram czy flasch aby użyć stosownej funkcji (z sufiksem _P).
- Argument 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.
- W AVR nie ma typu double, ma taki sam zakres jak float. I tak dobrze, że od którejś tam wersji, typ long long ma 64-bity a nie jak wcześniej 32-bit tak samo jak long.
- AVR nie mają FPU, STM32 wiele rodzin posiada FPU.
- Odkładanie na stos w przerwaniu rejestrów, które czasem nie są używane (R0, R1, RAMPZ, rejestr statusu) co wymusza czasem używanie wstawek ASM.
- Maureli, Tytuł: uint64_t ciekawostka Wrzucam parę cennych informacji na temat błędu dotyczącego operacji AND na liczbach typu uint64_t w avr-gcc
https://stackoverflow.com/questions/5009...operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
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
Forum:
https://www.elektroda.pl/rtvforum/topic3588785.html
Akcelerator LCD forum:
https://forbot.pl/forum/topic/16876-akce.../#comments pokrewny temat:
https://www.elektroda.pl/rtvforum/topic3588785.html
Akcelerator LCD YT:
https://www.youtube.com/playlist?list=PL...acjvhzPRdM https://www.youtube.com/playlist?list=PL...86bcULhy33
Akcelerator WS2812:
https://forum.atnel.pl/post222192.html#p222192
Dla początkujących:
https://stm32.eu/2019/01/31/nowa-ksiazka...-dostepna/