kayron pisze: ↑16 sty 2020, 22:39
No to ja, trochę z innej beczki.
Dla czego wszyscy zatrzymali się na ARDUINO UNO?
Nie wszyscy. Są taco co zakochali się w ESP ale ESP8266 sprzętowo prezentuje się skromie a ESP32 też ma spore ograniczenia, przypomina taki słabiutki RPi ZERO ze swoimi ograniczeniami co do liczby GPIO oraz peryferii.
Na razie wykorzystuje ESP8266 głównie w roli karty sieciowej, rzadko znajduję zastosowania, w których mógłby działać samodzielnie.
kayron pisze: ↑16 sty 2020, 22:39
Jest przecież ARDUINO ZERO na ARM, skoro chcemy rozmawiać o ARM.
Najlepszy uC nic nie zmieni w Arduino gdy:
- Nie będzie bibliotek wykorzystujących możliwości uC. Aby wykorzystać możliwości ARM trzeba używać sprzętu (przerwań, DMA) czego arduinowe biblioteki nie robią. Przenosiłem biblioteki obsługi LCD z Arduino na ARM i to co widziałem tam woła o pomstę do nieba. W konsekwencji przeniesienie biblioteki daje praktycznie zerowe przyspieszenie. Dopiero gdy zagoniłem DMA do pracy wyświetlacz zaczął działać z max prędkością. One Wire, WS2812 kolejne przykłady jak nie pisać bibliotek. Nawet obsługa banalnego TM1637 i podobnych jest zrealizowana źle, przez delay i "machanie" pinem. Jak sięgam pamięcią
nie widziałem biblioteki dla Arduino, która byłaby napisana "z głową", przypominają mi one czasy 8051 czy Z-8, gdzie większość interfejsów realizowano programowo ale było to spowodowane brakiem interfejsów sprzętowych w uC lub wysoka ceną uC wyposażonych w odpowiednie interfejsy.
AVR interfejsy ma, ale Arduino ich nie używa! W zakresie wykorzystania sprzętu lepiej wygląda Bascom.
- Najszybszy uC zostanie skutecznie spowolniony przez "programistę" używającego delay itp.
kayron pisze: ↑16 sty 2020, 22:39
Z drugiej strony wyprzedzając, trochę odpowiedz. Skoro użytkownicy ARDUINO w większości nie chcą się rozwijać, poza przykłady, to czy jest to w stanie coś zmienić?
Niestety, też widzę, że chęci nauki nie ma o czym świadczą tematy zakładane na forach.
kayron pisze: ↑16 sty 2020, 22:39
Co do STM32, może jakby ktoś pokazał jak to ruszyć w ARDUINO IDE, to by się coś ruszyło.
Arduino IDE można kazać używać za karę. Brak debugera skutecznie zniechęca aby na tym czymś, zwanym IDE, pracować. Porażka na całej linii. Wbudowane biblioteki mają różne "kwiatki", które widać w obsłudze GPIO oraz przerwania "systemowego".
Dla STM32 proponuje CubeIDE. Wcześniej używałem CubeMX + KEIL ze względu na problemy z połączeniem Eclipse z GCC. CubeIDE rozwiązuje ten problem i przyznam, że Eclipse bije na głowę płatnego KEILA. Co do GCC vs KEIL to nie robiłem porównań "jakości" generowanego kodu ale jeśli chodzi o szybkość kompilacji to różnica ponad 6 krotna. Kompilacja wszystkich plików (ten sam projekt) GCC 8 sekund, KEIL ponad minutę. Teraz nie będę już czekał 25minut na kompilację dużego projektu podczas której można zrobić śniadanie i je zjeść.
kayron pisze: ↑16 sty 2020, 22:39
Rozumiem że UNO to taka sztampowa płytka, ale chyba czasy świetności minęły.
Zwłaszcza, że są dostępne wypasione tanie płytki NUCLEO. STM32F1 i F4 są obsługiwane przez ArduinoIDE więc niby nie ma problemu aby ich używać, właśnie, niby. Wiele arduinowych bibliotek nie zadziała z innym uC niż AVR. Wygląda to tak jakby społeczność Arduino nie zauważało uC innych niż AVR podobnie jak firma Atnel a takie postępowania, na dłuższą metę, doprowadzi do upadku. Niewątpliwie biznes półprzewodników napędzają nie amatorzy ale odbiorcy hurtowi a ceny uC mówią same za siebie.
Większość peryferii pracuje przy max 3,6V. Niby AVR może być zasilany takim napięciem ale wtedy max zegar to nie 20MHz lecz np 12. Spowalniać powolny uC to raczej zły pomysł. Trzeba więc dodawać konwertery poziomów co generuje koszty, zmniejsza niezawodność, zwiększa pobór prądu, powierzchnię na PCB itd. Można oczywiście przetaktować uC ale to na własny użytek a nie w seryjnej produkcji, choć są kamikadze, np MiniPlayer Atnela przetaktowany o 20%.
Niedużym firmom też nie opłacają się AVR. W tym przypadku, kilkuzłotowa różnica w cenie uC, przy cenie końcowego produktu 100..200zł czy więcej nie ma znaczenie ale znaczenia nabiera czas a co za tym idzie koszt opracowania urządzenia (napisania programu). Program na ARM pisze się szybciej niż na AVR czyli taniej.
AVR niewątpliwie "umrą" jak 8051 czy Z-8 i wszystko wskazuje, że ten proces już się rozpoczął. Na Elektrodzie, jeszcze trzy lata temu, więcej było tematów dotyczących AVR, mniej ARM, teraz jest (na szczęście) odwrotnie.
ARM tez kiedyś umrze, prawdopodobnie zastąpi go RISC-V. Jedna jaskółka wiosny nie czyni ale pojawiły się GD32FV1xx. Dobry ruch, bo peryferia są kompatybilne z STM32F1xx, różnica tylko w rdzeniu. Dla programisty w C/C++ to żadna różnica! Inny rdzeń to "problem" kompilatora.
