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

[Chumanista]

Zapytam tylko jeszcze: Dlaczego Atmega 16? Nie ma ani pełnego wsparcie bibliotek Arduino ani mocy obliczeniowej STM32 które są w podobnej cenie (i też od niedawna są bardzo wygodne do programowania).

[marek1707]

Hm, bo w zupełności wystarcza?

[Chumanista]

marek1707, chwilowo wystarcza. Ale może będzie chciał zrobić zapamiętywanie trasy. Albo uczenie się. Albo inne rzeczy potrzebujące większej mocy obliczeniowej. Sam podkreślałeś możliwość rozbudowy przecież.

Poza tym moim zdaniem lepiej od razu uczyć się STM32 ponieważ kosztują praktycznie tyle samo a mają dużo większe możliwości. Nie rozumiem tego przywiązania sfery hobbystycznej do 8-bitowców.

EDIT: Atmega16 kosztuje ~10zł. STM32F030 kosztuje ~6zł i jest lepszy pod każdym względem (przynajmniej po szybkiej lekturze pierwszych stron datasheetów).

Istotne różnice:

➕ o rząd wielkości szybszy ADC z 12 bitami rozdzielczości zamiast 10

➕ 7 x 16bit timerów z dużo lepszą kontrolą (zamiast 2x8bit + 1x16bit)

➕ 6x szybsza praca na wewnętrznym oscylatorze

➕ 32bit operacje

➕ znacznie lepszy system przerwań zewnętrznych

➕ 16 (zamiast 8) możliwych kanałów ADC

➕ znacznie więcej pamięci każdego rodzaju

➕ znacznie więcej linii komunikacyjnych

[Chumanista]

deshipu, właśnie ostatnio robiłem początki STM32 i wyglądały dokładnie jak początki z Arduino.

Najpierw użyłem CubeMX do wygenerowania początkowych ustawień wszystkich rejestrów, a potem 2 funkcje HAL żeby zmienić stan wyjścia i zrobić delay.

Faktycznie programowanie za pomocą Low Layer to tortura, ale CubeMX i biblioteki HAL sprowadzają to do poziomu trudności pracy z 8bit.

[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

[deshipu]

deshipu, właśnie ostatnio robiłem początki STM32 i wyglądały dokładnie jak początki z Arduino.

Najpierw użyłem CubeMX do wygenerowania początkowych ustawień wszystkich rejestrów, a potem 2 funkcje HAL żeby zmienić stan wyjścia i zrobić delay.

Faktycznie programowanie za pomocą Low Layer to tortura, ale CubeMX i biblioteki HAL sprowadzają to do poziomu trudności pracy z 8bit.

Gorzej, jak chcesz (lub musisz) używać otwartego oprogramowania.

[Chumanista]

Oczywiście jak sztucznie ograniczysz zasób narzędzi to jest trudniej.

Zarówno CubeMX jak i SW4STM są darmowe do wszystkich zastosowań, dla jakichś 99% użytkowników jest to wystarczające.

[marek1707]

"Nie rozumiem tego przywiązania sfery hobbystycznej do 8-bitowców."

A ja rozumiem doskonale. Używam i jednych i drugich (i jeszcze trzecich i czwartych itd rodzajów procesorów) i wiem, że stopień skomplikowania - które ty uważasz za zaletę, jest mieczem obosiecznym. Owszem, w poważnym ARMie - nawet jakimś malutkim i taniutkim Cortexie M0 dostajesz to wszystko co wypisałeś za ułamek ceny ATmegi. Tylko, że to wszystko trzeba opanować. Ile czasu będzie musiał przesiedzieć Gizmo112 przed dokumentacją, by odpalić swojego upragnionego robocika? Nie ma na te dylematy jednoznacznej odpowiedzi, bo każdy inaczej ceni sobie swój czas i inaczej planuje swój rozwój. Ty czytasz pdfy, wgryzasz się w opisy peryferiów bo traktujesz to jak inwestycję. Opanowałeś po jednym czy dwóch projektach któryś procesor i środowisko i z czystym sumieniem to polecasz? A gdyby ktoś teraz polecał Ci PICe, bo fajne, dużo mogą i "są lepsze pod każdym względem"? Pójdziesz w ciemno? Trawa u sąsiada zwykle wcale tak zielona nie jest jak się wydaje zza płotu. "Dopracowane" środowiska także zawierają mnóstwo błędów, procesory chyba jeszcze więcej (patrz: rosnące lawinowo objętości errat) a w bardziej skomplikowanym sprzęcie pogubić się jest łatwiej.

Ten robot na 99% nie będzie musiał używać:

➕ o rząd wielkości szybszego ADC z 12 bitami rozdzielczości

➕ 7 x 16bit timerów z dużo lepszą kontrolą (zamiast 2x8bit + 1x16bit)

➕ 6x szybszej pracy na wewnętrznym oscylatorze

➕ 32bit operacji

➕ znacznie lepszego systemu przerwań zewnętrznych

➕ 16 (zamiast 8) możliwych kanałów ADC

➕ znacznie większej pamięci każdego rodzaju

➕ znacznie większej liczby linii komunikacyjnych

Więc dla idei? Bo chyba nie dla oszczędności 4zł? Można wsadzić i ARMa - nie twierdzę, że kategorycznie nie, ale każdy musi to przemyśleć samemu. Na 100% czas dojścia do działające pierwszej konstrukcji na wszystkomającym ARMie będzie dużo dłuższy niż na prostym AVR. Nie można tego nie zauważać i nie doceniać.

Z życia: mój kolega z pokoju, doświadczony inżynier elektronik, dziesiątki projektów na koncie, właśnie postanowił robić projekt na ARMie. Niewielki ATMEL, aplikacja pomiarowo -kontrolna, żaden wyczyn. Poczytał o procesorze, o peryferiach, ucieszył się i zabrał do roboty. Od trzech miesięcy klnie. Tu błąd, tam błąd, to działa, ale tylko w jakimś trybie, to zupełnie nie, błędy w bibliotekach, ograniczenia w gotowych usecase'ach itd. Gdyby to samo zrobił na znanym mu doskonale AVR bez DMA, autoskanowania ADC, event-systemu itp, gotowe urządzenie już dawno siedziałoby w komorze klimatycznej lub zdawało testy na CE a firma zaoszczędziłaby dwie jego miesięczne pensje. W końcu to zrobi, nie wątpię - jesteśmy pro, ale droga przez mękę - to najlepiej co do tego pasuje.

[deshipu]

Oczywiście jak sztucznie ograniczysz zasób narzędzi to jest trudniej.

Zarówno CubeMX jak i SW4STM są darmowe do wszystkich zastosowań, dla jakichś 99% użytkowników jest to wystarczające.

To nie jest "sztuczne" ograniczenie. Darmowego Windowsa i komputer do jego zainstalowania też dostajesz z nimi?

Z AVR-ami nie ma takich problemów po prostu.

[Chumanista]

To jest sztuczne ograniczenie. Komputer jest też niezbędny do programowania AVR, obydwa potrzebne programy działają na Windowsie, OS X i Linuxie, a autor tematu i tak korzysta z Windowsa wnioskując z ikon na dole postów.

[deshipu]

To jest sztuczne ograniczenie. Komputer jest też niezbędny do programowania AVR, obydwa potrzebne programy działają na Windowsie, OS X i Linuxie, a autor tematu i tak korzysta z Windowsa wnioskując z ikon na dole postów.

A za dwa lata programy przestaną być wspierane, na nowym Windowsie nie będą już działać, a autor zostanie z mikrokontrolerem, z którym nie może nic zrobić.

[Chumanista]

deshipu:

programy przestaną być wspierane

Co nie sprawi że nagle przestaną działać. Poza tym szansa że ST nagle przestanie wspierać swoje nowe narzędzia które tak reklamują jest raczej nikła. Raczej też nie zbankrutują jutro czy pojutrze.

na nowym Windowsie nie będą już działać

Nie będzie następnego Windowsa. Poza tym Microsoft zaskakująco dobrze radzi sobie z kompatybilnością wsteczną.

a autor zostanie z mikrokontrolerem, z którym nie może nic zrobić

Nic poza programowaniem go nadal tymi samymi narzędziami których używał. Ale nic z powyższego się nie stanie.

Serio, brzmisz już jakbyś szukał argumentów na to że ziemia jest płaska. Jestem wielkim zwolennikiem FLOSS, ale używanie gorszego oprogramowania ponieważ lepsze jest zamknięte (ale spełnia wszystkie inne wymagania) to masochizm.

marek1707, ta krytyka jest całkiem zasadna. Moja opinia jest taka że za robota, góra dwa i tak AVR przestaną wystarczać. Więc lepiej zacząć teraz, od prostego projektu opanowywanie STM32 niż "inwestować" w uczenie się ślepej uliczki którą są AVR.

Mogę jeszcze wspomnieć o rozwiązaniu pośrednim którym są pełne, działające biblioteki Arduino na STM32F1 (i podobno F2 i F4), powstałe w ramach projektu Maple Mini i dalej rozwijane: https://github.com/rogerclarkmelbourne/Arduino_STM32

To łączy prostotę programowania AVR z możliwościami i rozwojowością STM32.

[deshipu]

Nic poza programowaniem go nadal tymi samymi narzędziami których używał. Ale nic z powyższego się nie stanie.

A to ty masz naszą forumową szklaną kulę. Zastanawiałem się co się z nią stało. No skoro mówisz, że się nie stanie, to wszystko w porządku, w końcu komu możemy ufać, jeśli nie naszym ukochanym korporacjom.

Serio, brzmisz już jakbyś szukał argumentów na to że ziemia jest płaska. Jestem wielkim zwolennikiem FLOSS, ale używanie gorszego oprogramowania ponieważ lepsze jest zamknięte (ale spełnia wszystkie inne wymagania) to masochizm.

Nie będę używał gorszego oprogramowania. Po prostu wybiorę platformę, która jest bardziej otwarta, bo jest dla mnie bezpieczniejsza, bardziej przyszłościowa i do tego pozwala mi ulepszać istniejące narzędzia i dorabiać własne. No i zazwyczaj ma bardziej doświadczoną społeczność do pytania o pomoc, bo można "zajrzeć pod maskę" a nie tylko opierać się na klikaniu "next". Oczywiście każdy musi te i inne czynniki zważyć dla siebie we własnym zakresie i podjąć decyzję, ale osobiście nie uśmiecha mi się trzymanie w domu jakiegoś trupa z nieupdate-owanym Windowsem XP (albo 95), bo to jedyna rzecz, na której jakaś przedpotopowa zamknięta aplikacja działa. Ty mówisz, że to się nie zdarza, ja osobiście mam wielu kolegów, którzy tak właśnie muszą robić i klną na czym świat stoi. Widocznie obracamy się w różnych środowiskach.

Mogę jeszcze wspomnieć o rozwiązaniu pośrednim którym są pełne, działające biblioteki Arduino na STM32F1 (i podobno F2 i F4), powstałe w ramach projektu Maple Mini i dalej rozwijane: https://github.com/rogerclarkmelbourne/Arduino_STM32

To łączy prostotę programowania AVR z możliwościami i rozwojowością STM32.

Sam używałem STM32duino z płytkami za $4 i rzeczywiście, jest to prawie tak wygodne, jak AVR-y (szczególnie kiedy już się wgra bootloader do programowania przez USB i wymieni ten jeden opornik, żeby to działało). Ale po zaprogramowaniu blinka płytka poszła do szuflady, bo nie mam dla niej zastosowania -- jest za słaba na MicroPythona, a nie mam projektów tak dużych, żeby te wszystkie dodatkowe peryferia i moc obliczeniowa się przydały. Gdybym miał, to bym i tak chyba użył Teensy, bo też mam ich nieużywanych w szufladzie trochę i też się je daje z Arduino programować. Tylko... jakaś taka armata na muchę.

[Chumanista]

Dwa dni zajęło mi ustawienie środowiska tak, żeby móc cokolwiek skompilować i wgrać -- praktycznie zerowa dokumentacja na ten temat. Teraz próbuję napisać miganie diodą, ale jest ciężko -- liczba rejestrów, które trzeba poustawiać żeby cokolwiek działało jest straszna i ciężko dojść co się robi źle.

Nie będę używał gorszego oprogramowania.

Hmm?

A to ty masz naszą forumową szklaną kulę.

Nie mam szklanej kuli, podałem powyżej dwa argumenty za tą tezą. Poza tym jest wersja na linuxa, a jeśli dobrze rozumiem tam kompatybilność wsteczna jest praktycznie nieograniczona. Ty tu używasz Linuxa więc chętnie usłyszę czy dobrze rozumiem.

komu możemy ufać, jeśli nie naszym ukochanym korporacjom

Myślę że założenie że ST nie przestanie rozwijać narzędzi w które sporo zainwestowało i które aktywnie rozwijają żeby wspierały jak najwięcej ich produktów to bezpieczne założenie.

jakaś taka armata na muchę

Trochę tak. Ale skoro koszt (pod każdym względem) jest bardzo podobny to moim zdaniem dobrze mieć dodatkowy zapas, szczególnie pamięci (ostatnio zrobiłem projekt na Arduino Nano bo stwierdziłem że przecież wystarczy i już żałuję).

[deshipu]

Dwa dni zajęło mi ustawienie środowiska tak, żeby móc cokolwiek skompilować i wgrać -- praktycznie zerowa dokumentacja na ten temat. Teraz próbuję napisać miganie diodą, ale jest ciężko -- liczba rejestrów, które trzeba poustawiać żeby cokolwiek działało jest straszna i ciężko dojść co się robi źle.

Nie będę używał gorszego oprogramowania.

Hmm?

Tutaj nie mam za bardzo wyboru, decyzję podjęto za mnie. I tak, mógłbym użyć dowolnego innego sterownika silników, albo nawet zrobić sobie swój -- nie jest to skomplikowane. Ale potraktowałem to jako wyzwanie i się bawię. Na pewno nie zdecydowałbym się na to do poważnego projektu, a już na pewno nie poleciłbym początkującemu.

A to ty masz naszą forumową szklaną kulę.

Nie mam szklanej kuli, podałem powyżej dwa argumenty za tą tezą. Poza tym jest wersja na linuxa, a jeśli dobrze rozumiem tam kompatybilność wsteczna jest praktycznie nieograniczona. Ty tu używasz Linuxa więc chętnie usłyszę czy dobrze rozumiem.

Kompatybilność wsteczna pod Linuksem jest wtedy, kiedy dostępne są kody źródłowe i możesz sobie skompilować. Nawet wtedy mogą być konieczne poprawki, ale oczywiście nie ma z tym problemu, bo w końcu masz kody źródłowe.

Niestety nie dotyczy to binarnych blobów.

Natomiast, co ciekawe, binarki Windowsowe mogą być bardziej przenośne -- projekt Wine dba dość mocno o kompatybilność i często da się uruchamiać za jego pomocą rzeczy, które na współczesnych Windowsach już nie działają.

komu możemy ufać, jeśli nie naszym ukochanym korporacjom

Myślę że założenie że ST nie przestanie rozwijać narzędzi w które sporo zainwestowało i które aktywnie rozwijają żeby wspierały jak najwięcej ich produktów to bezpieczne założenie.

Tegoroczna seria przejęć i zmian na rynku to dopiero początek -- nadchodzą burzliwe czasy. Nigdy nie wiemy kto i kiedy wykupi ST (albo kogo oni kupią) i jak dalej będzie wyglądała ich polityka. Poza tym niekoniecznie muszą przestawać rozwijać. Mogą na przykład przestać udostępniać za darmo. Albo nawet zacząć wymagać podpisania NDA. To nie jest wcale taka rzadka praktyka.

A jak masz kod źródłowy i pełną dokumentację na dysku, to nikt ci tego nie zabierze, choćby nawet wybuchła wojna i nałożono by embargo na eksport technologii.

jakaś taka armata na muchę

Trochę tak. Ale skoro koszt (pod każdym względem) jest bardzo podobny to moim zdaniem dobrze mieć dodatkowy zapas, szczególnie pamięci (ostatnio zrobiłem projekt na Arduino Nano bo stwierdziłem że przecież wystarczy i już żałuję).

Tak jak Marek napisał, koszt w złotówkach to tylko niewielki kawałek rzeczywistego kosztu. Najcenniejszy oczywiście zawsze jest czas (i nerwy).

[Chumanista]

marek1707, chciałem zauważyć że właśnie projekt jest ograniczany przez możliwości procesora. Może się powtarzam, ale użycie STM32F103 z bibliotekami Ardiuno STM32 dałoby tu swobodę w doborze czujników, pomiarów, itd. a jednocześnie nie zmieniłoby w znaczący sposób poziomu trudności programowania i dałoby platformę do nauki programowania STM32 w przyszłości.

Można by nawet użyć gotowego modułu z procesorem (~$4) żeby uniknąć konieczności wgrywania bootloadera i znacząco uprościć schemat elektryczny.