Który układ jest najlepszy na świecie? - STM czy nie STM, o to jest pytanie!

[marek1707]

A czy mógłbyś te ograniczenia wskazać? Tylko nie pisz proszę o brakujących nóżkach, bo są ATmegi w 100 pinowych obudowach. Obecna m16 jest wyborem autora wątku i wydaje się wystarczać.

[Elvis]

Tak sobie czytam ten wątek i trochę żałuję, że pomieszały się dwa tematy. Z jednej strony kolega Gizmo112, buduje prostego robocika i fajnie, że znajduje pomoc. Drugi i zupełnie niezależny temat, albo raczej off-topic, to wybór mikrokontrolera.

W sumie jest dyskusja nabrała trochę niepotrzebnych emocji, ale może warto byłoby z niej zrobić nowy temat? Nie żeby udowadniać który układ jest najlepszy na świecie, ale np. podyskutować o doświadczeniach z różnymi mikrokontrolerami i kompilatorami? Na spokojnie spróbować porównać, kiedy które rozwiązanie sprawdza się lepiej.

[marek1707]

Takie rozmowy wychodzą same z siebie i nie wiem czy komukolwiek będzie się chciało udowadniać wyższość jednych świąt nad drugimi w osobnym, specjalnie do tego przeznaczonym wątku. Każda z rodzin procesorów ma swoje wady i zalety i nie ma jednoznacznej przewagi. Jedni cenią prostotę, inni moc obliczeniową a jeszcze inni dostęp do narzędzi czy ich "dojrzałość" - jak ich pogodzić? Przecież to zupełnie różne kryteria, żadne nie jest ważniejsze ani "lepsze". Także i ta dyskusja chyba nie miała nikogo do niczego przekonać i umrze śmiercią naturalną jak tylko Gizmo112 pójdzie dalej z projektem.

A wrzuty z boku typu "Zrób to na zupełnie innym, moim zdaniem dużo lepszym procesorze" - jeśli ktoś nie brnie w ewidentnie złe technicznie rozwiązanie - tylko mieszają w głowach początkującym. Oni i tak mają problem z ogarnięciem prostego schematu i wyborem opcji nawet w poczciwej m16. Ludzie jakoś nie siadają od razu za kierownicą wielkiej ciężarówki tylko robią B i pół roku jeżdżą z duszą na ramieniu (przynajmniej w Wawie).

[Elvis]

A nie sądzisz Marku, że czas AVR-ów powoli mija? Jeszcze kilka (no może dziesięć) lat temu bardzo popularne były układy oparte o '51 - był to znany i lubiany standard, każdy kto miał nieco więcej lat doświadczenia chętnie polecał takie rozwiązania.

Na Forbocie chyba nawet nie było konstrukcji opartej o 51. Może teraz kolej na inne 8-bitowce, nie mówię że dzisiaj, czy jutro, ale powiedzmy za 5 lat będą taką samą egzotyką jak teraz 8051?

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

Tak, masz sporo racji. Każdy produkt (może nie licząc chleba i jabłek) ma okresy wzrostu, apogeum popularności i schyłek. W sumie ciekawe jest dlaczego właściwie '51 tak bardzo zdechły? Czy zastanawiałeś się dlaczego? Przecież to nie może być tak trywialne jak "bo są stare i wolne". Po chwili namysłu wydaje mi się, że nie było jednej przyczyny. Procesor jest tylko małą cząstką procesu projektowania. Wybór platformy w dużym stopniu zależy od podejścia inżynierów i dostępności narzędzi. Świetność rodziny '51 przypadła na czas programowania w asemblerze. Procesor ten zaczynał gdy królowało jeszcze 8080, Z80 czy 6502 a te systemy były ewidentnie przeznaczone do pisania kodu w języku asemblera - to była czysta przyjemność. Miały dopasowaną do tego architekturę i przed wszystkim listę instrukcji. '51 kontynuował tę chlubną 🙂 tradycję. Kompilatory C na te platformy pojawiły się za późno, były drogie i wyłącznie komercyjne. A gwałtowny rozwój narzędzi - już nie tylko samych kompilatorów, ale także środowisk czuwających nad spójnością dużych projektów i coraz bardziej rozbudowanych debuggerów umożliwiał łatwiejsze przechodzenie na coraz wyższe poziomy abstrakcji. A wymagania na na wielkość, skomplikowanie i niezawodność systemów zaczęły szybko rosnąć. Pisząc w C już nikt nie zastanawiał się jak wymyślić wydajne mnożenie 32x32 (bo ktoś to zrobił bardzo dobrze wcześniej) tylko jak zaimplementować np. wektor o dowolnej długości - bo tego w C nie ma. Za chwilę wybuchło wciąż rozwijane C++ i teraz w standardzie mamy zupełnie niesamowite struktury danych, klasy, funkcje wirtualne itd... Możemy jeszcze lepiej skupić się poprawności algorytmu nie myśląc o zarządzaniu strumieniami, pamięcią dynamiczną lub "jak zrobić krotkę?". Architektura procesora zeszła na dalszy plan, ukryła się pod warstwami oprogramowania i dlatego stała się mniej ważna. Nikt nie porównuje liczby rejestrów czy trybów adresowania - wiadomo, ze mają być i mają efektywnie realizować kod. A taki przeskok daje - także amatorom - zupełnie inny start i komfort pracy. Dostają np. moduł radiowy z potężnym ARMem, który nie tylko obsługuje samo WiFi, GSM czy LoRa, ale zostawia całkiem sporo mocy na dospawaną naszą własną aplikację w (mirco)Pythonie czy Javie. Podobna rzecz na AVR nie mogłaby się wydarzyć, bo nie starcza mocy obliczeniowej i zasobów. I w tym kontekście architektury 8-bitowe są przeżytkiem. Po co stawać na głowie i kombinować jak upchnąć w 20MIPSach i 128K FLASHa maszynę wirtualną Java, gdy można wziąć z półki obok tak samo tani, 20x wydajniejszy procesor 32-bitowy który zrobi to z palcem w nosie? Co więcej, dzięki dużej nadwyżce mocy obliczeniowej i generalnie większej uwadze poświęconej przez producenta (tranzystory wciąż tanieją) na wbudowane mechanizmy debugowania, w większych procach mamy JTAG-owe wsparcie do sprzętowych pułapek na pamięć danych, profilowanie czasu czy śledzenie wydarzeń w peryferiach - rzeczy zupełnie nieosiągalne w architekturach typu '51 czy AVR.

Tak więc: tak, biorąc pod uwagę coraz większe potrzeby, coraz potężniejsze firmware które dostajesz gdzieś pod spodem w produkcie nawet dla hobbystów, oderwanie programistów od sprzętu i jeszcze parę innych czynników to 8 bitów jest skazane na porażkę. Pozostaje jednak pewna nisza 🙂 Tak jak wciąż ktoś produkuje i można kupić scalaki logiczne serii 74xx czy 4xxx, statyczne pamięci RAM czy tym podobne proste układy cyfrowe, tak i dla AVRów czy małych PICów widzę nikłą nadzieję. Są nią naprawdę proste systemy programowane bare-metal, takie jak ten robot. Mogę jeszcze dorzucić kontroler kuchenki, akwarium, bramy garażowej czy stacji pogodowej. Żadnego RTOSa, żadnego Linuxa, żadnych wygórowanych wymagań na szybkość, peryferia czy I/O. Można już teraz stwierdzić, że program tego LFa nie będzie wymagał czasowego czy pamięciowego profilowania zadań, wywłaszczania i wielowątkowości itp rzeczy więc AVR - tak jak w 100 poprzednich projektach tego typu wystarczy. 8 MIPSów, 10-bitowy ADC i kilka timerów jest aż nadto wystarczające do tej aplikacji, pisanej od zera na "goły" procesor.

Czy trywialne "wystarczanie" jest wystarczającym powodem użycia prostej ATmegi? 🙂 To już każdy musi ocenić samodzielnie.

[Elvis]

To na pewno racja, że na spadek popularność '51 miało wpływ wiele czynników. Większość z nich bardzo ładnie Marku opisałeś. Ja dorzuciłbym jeszcze jedną cechę, mianowicie skalowalność.

Programując w językach wysokiego poziomu większość osób nie interesuje się rejestrami, trybami adresowania, czy innymi niskopoziomowymi cechami mikrokontrolera. Jednak programowanie wysokopoziomowe ma swoją cenę - programy są duże i bardzo szybko rosną. Rosną, bo rosną również oczekiwania użytkowników.

Dziesięć lat temu ekspres do kawy miał kilka przycisków do wyboru rodzaju napoju i to wystarczało. Teraz żeby nie stał na najniższej półce musi mieć wyświetlacz, obsługiwać wiele języków itd. Jako ciekawostkę o ekspresach do kawy napiszę tylko, że jeden z automatów popularnej w UK sieci ma wbudowaną kamerkę oraz oparte na OpenCV zaawansowane algorytmy wykrywania i rozpoznawania twarzy... A wszystko po to, żeby wyświetlać reklamy dopasowane do klienta (na podstawie obrazu rozpoznaje płeć osoby kupującej kawę i reklamuje inne produkty).

Dużą wadą układów 8-bitowych jest brak możliwości "skalowania w górę". Mamy świetne układy mające powiedzmy 16kB - 256kB pamięci, ale dalej zaczyna się robić coraz trudniej. W przypadku obliczeń, kompilator wygeneruje kod, który na 8-bitowcu da takie same rezultaty jak na 32-bitach. Jednak wielkość programu staje się problemem. Można oczywiście zakładać, że 16kB to pamięć większa niż potrzebna i nigdy nie będziemy chcieli mieć więcej. Jednak oczekiwania klientów, albo nasza chęć poznawania nowych technik programowania, np. obiektowego, może szybko sprawić, że ilość pamięci będzie za mała.

Tym co moim zdaniem przemawia za uczeniem się programowania ARM-ów jest ogromny potencjał rozwojowy. Zamiast poświęcać czas na AVR, które raczej nie pokonają ograniczeń sprzętowych, może lepiej wykorzystać czas na opanowanie prostego Cortex-M0? Przykładowo LPC-1114 ma datasheet nawet nie dwa razy dłuższy niż Atmega16, ale jeśli go opanujemy możemy łatwo "przesiąść" się na Cortex-M3, itd.

Wracając do porównań z samochodami - nauka na 8-bitowcach, to jak jazda małym fiatem. Niby więcej nie potrzeba, ale wiele problemów po prostu nie istnieje w większych samochodach... Więc może lepiej zaczynać od czegoś bardziej współczesnego?

[marek1707]

W sensie przewidywanej (czy tylko przeze mnie?) jednak dłuższej obecności procesorów 8-bitowych na rynku, nie traktowałbym czasu poświęconego na AVR jako alternatywę dla 32-bitowców a raczej jako formę równoległą. Na każdym kroku jesteśmy zmuszani, zachęcani lub przyzwyczajani do szybkiej wymiany produktów: telefonu co nowy abonament, karty graficznej co nową wersję DirectX a kompa co kolejne Windowsy. I nie wiem, czy AVRy po prostu nie zestarzały się "moralnie" i czy tu nie tkwi ich największa słabość. Moja komóra ma z 6 lat, wytrzymuje tydzień bez ładowania w śniegu, mrozie, błocie i deszczu. Nie ma internetu, ekranu dotykowego ani arkusza kalkulacyjnego, ale mi wystarcza i dopóki się nie rozpadnie, nie będę myślał o kolejnej. Rozumiem, że polecanie jej komuś kto dziś kupuje swój pierwszy telefon byłoby śmieszne a taka właśnie jest sytuacja początkującego w elektronice. Odpowiedzialność (jednak wiemy więcej niż zaczynający swoją przygodę) nakazuje podpowiedzieć na start coś, o czym jesteśmy przekonani że ma przyszłość - więc ARMy są oczywistością. Naturalnym będzie też zwiększanie się (nawet tutaj, na Forbocie) udziału projektów opartych na tych prockach i super, niech nowi mają wybór. Narzędzia także stają coraz bardziej dopracowane i stabilne. Ja jednak wychowany zostałem w starej szkole, gdzie jeśli nie musiałem używać wzmacniacza operacyjnego to wstawiałem tranzystor i jeśli mam wybór (a znając N architektur mam go) będę dążył do używania rzeczy tylko wystarczająco dobrych. Być może dlatego trudno mi postawić się w położeniu osoby nie wiedzącej nic a chcącej nauczyć się czegoś. Dziś czas kosztuje coraz więcej, więc może nie ma sensu poświęcać go na poznawanie wielu dróg. Jedna dobra w większości wypadków zapewnia komfort 😉 wystarczy się rozejrzeć - to działa.

A w samochodach? Zarówno wypasiona bryka z klimą, siedzeniami, światłami i szybami oraz 126p wymagają tej samej kategorii B więc nakład pracy na samą naukę jazdy będzie podobny. Ale masz rację, M0 zeszły już do takiego poziomu uproszczenia, że ich opanowanie i aplikacja nie jest trudniejsza niż AVRa. To jakby wsiąść do TIRa z elektronicznym kokpitem i autopilotem.. Nadal można pewnie zahaczyć o hydrant, ale tym razem zamiast kompletu drzwi do wymiany, raczej tego nie zauważymy 🙂

[Elvis]

Ta dyskusja jest potwornym off-topem, ale wydaje mi się ciekawa, bo daje możliwość pokazania różnych platform. W tej chwili Arduino sprawiło, że AVR wydają się wszystkim proste, a cokolwiek innego trudne. Nie zachęcam do wyrzucania wszystkiego co nie jest ARM-em, raczej proponowałbym porównać różne rozwiązania. Są jeszcze przecież układy PIC, wspomniana '51, pewnie mnóstwo innych platform, które mają swoje zalety i wady. Może warto byłoby się podzielić doświadczeniami przy pracy z nimi?

Inaczej będziemy skazani na powtarzanie "sloganów" - AVR są łatwe, STM32 są trudne i mega wypasione. A w sumie i jedno i drugie stwierdzenie jest nieprawdziwe.

Jak chodzi o 126p to chodziło mi głównie o brak synchronizacji na jedynce... Rzecz niespotykana we współczesnych samochodach, a sam wspominam to jako koszmar podczas nauki jazdy 🙂

[Treker (Damian Szymański)]

To co Panowie, podzielić temat i wydzielić Wasze posty?

Jeśli tak to zasugerujecie, od której wiadomości 🙂

[Chumanista]

Treker,

Moim zdaniem:

Między https://www.forbot.pl/forum/postlink/112387.htm#112387 a https://www.forbot.pl/forum/postlink/112401.htm#112401.

Od https://www.forbot.pl/forum/postlink/112535.htm#112535 do końca.

[Treker (Damian Szymański)]

Ok posty wydzielone. Oczywiście nazwa tematu tymczasowa i z przymrużeniem oka, czekam na lepsze propozycje 🙂

[Chumanista]

Treker, dodałem dla czytelności 😉

[Elvis]

Skoro już temat został wydzielony, to może uda się go odkopać? Ktoś ma pomysł na układ lepszy od STM32? Może jakieś praktyczne doświadczenia z układami - ich zalety i wady?

[deshipu]

Może te nowe Xtensy? ESP8266 błyskawicznie podbiło rynek, ESP32 zapowiada się jeszcze lepiej, a Espressif chyba wyczuło okazję i stawia na wsparcie hobbystów -- zakładając, że czego się hobbysta nauczy, tego potem jako projektant będzie używać i do komercyjnych rzeczy.

Oczywiście są też inne ARM-y niż STM32, choćby niedawno wykickstarterowane płytki Teensy 3.5 i 3.6, które wydają się bardzo potężne jak na ten rynek (mam je w szufladzie, ale jeszcze nie wymyśliłem co z nimi zrobić). Nordic też robi swoje ARM-y, jeden z nich trafił do Micro:bit, co spowodowało, że wszyscy ludzie robiący klony tego urządzenia (jest już japoński i niemiecki, a nawet ruszyła już akcja uczenia micro:bit-ów w Polsce) szukają modułów z nimi.

Ja mam jeszcze jeden pomysł w jaki AVR-y i inne 8-bitowce mogą się jednak okazać przydatne -- montowanie ich w "inteligentniejszych" czujnikach. Takich, co już same robią filtrowanie, całkowanie, przeliczanie pomiarów według krzywych, do tego generują przerwania na życzenie i są plug-and-play. Jak budowałem mojego czworonożnego robota, to się zastanawiałem jak to wszystko podłączyć do jednej płytki i jak to potem sprytnie oprogramować, żeby robiło wszystko na raz. Dzisiaj bym się nie męczył -- każda noga dostałaby swojego własnego ATtiny45, który robiłby jej kinematyke odwrotną i generował sygnały do 3 serw (a może nawet sprawdzał ich obciążenie), zasilacz dostałby swojego do monitorowania baterii i włączania/wyłączania pushbuttonem, każdy czujnik miałby swoją logikę -- i wtedy budujemy w zasadzie jak z klocków. Każdy z komponentów możemy łatwo oprogramować i przetestować, bo robią tylko jedną prostą rzecz.

Na koniec, jeszcze jeden możliwy powód kończenia się życia danej serii czipów -- jak się taki czip projektuje, to nie tylko się projektuje architekturę i jakie tranzystory ma w środku, etc. -- ale właściwie cały proces produkcyjny -- pod konkretne maszyny, konkretne procesy, etc. No i teraz stare maszyny się psują, wymagają konserwacji, nie są tak wydajne jak nowe -- zaprojektowanie i produkcja nowego czipa mogą być tańsze, niż upieranie się przy starym.

[Elvis]

Przyznam, że nie miałem czasu się pobawić, ale bardzo interesująco wyglądają układy Cypress-a. Jak dla mnie szczególnie wersja z rdzeniem Cortex-M3 wydaje się warta uwagi: http://www.cypress.com/products/32-bit-arm-cortex-m3-psoc-5lp

Porównując z STM32 - dostajemy procesor z tym samym rdzeniem, czyli Cortex-M3. Jednak układy peryferyne możemy sami konfigurować, trochę jak w przypadku FPGA. Możemy więc wybrać to co potrzebujemy, a zrezygnować z niepotrzebnych modułów. Typowe mikrokontrolery mają na pokładzie jak najwięcej, a i tak często czegoś brakuje, powiedzmy dodatkowych kanałów PWM. Cypress daje ciekawą możliwość dopasowania sprzętu do naszych potrzeb.