Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku?

tmf 28 May 2022 19:24 2259 26
Computer Controls
  • Witam was w kolejnym cyklu, który tym razem będzie dedykowany osobom, które dopiero rozpoczęły lub chcą rozpocząć przygodę z mikrokontrolerami. Stąd też przedstawiam zupełnie podstawowe informacje, które mam nadzieję pomogą początkującym. W tym odcinku w 30 minut chciałbym odpowiedzieć na pytanie „Jak zacząć przygodę z mikrokontrolerami najprościej i ponosząc minimalne koszty?”.
    Oczywiście nie ma jednego przepisu dobrego dla wszystkich, natomiast chciałem się podzielić swoimi przemyśleniami i doświadczeniami w tym zakresie. To co wydaje mi się najistotniejsze to prostota i minimalizacja liczby potencjalnych problemów, które mimo, że zazwyczaj proste, mogą osobę początkującą skutecznie zniechęcić. Stąd też takie a nie inne rekomendacje z mojej strony.
    Jak zwykle ciekaw jestem waszych opinii i przemyśleń, a szczególnie opinii osób początkujących – co stwarza wam problemy i o czym chcielibyście usłyszeć?
    Czy próbowaliście nowe mikrokontrolery AVR serii DA, DB itd.? Korzystaliście z ATMega4809 i podobnych? Czy płaska przestrzeń adresowa, z jednolitym adresowaniem FLASH, EEPROM i SRAM jest wg was dużym atutem, czy bez znaczenia?
    BTW, proszę nie robić w tym wątku wojny co jest lepsze – nie taki jest cel.



    Cool? Ranking DIY
    [28-30.06.2022, targi] PowerUP EXPO 2022 - zasilanie w elektronice. Zarejestruj się za darmo
    About Author
    tmf
    Moderator of Microcontroller designs
    Offline 
  • Computer Controls
  • #2
    spec220
    Level 25  
    Witam.
    Obejrzałem artykuł. Faktycznie na razie wstęp dla bardzo początkujących.
    Generalnie sama obszywka takich modułów to jak dla mnie małe piwo, ale żeby przeskoczyć próg programowania, to chyba musiałbym sobie dołożyć jakiejś pamięci twardej do głowy...
    Kiedyś tam pobrałem jakieś środowisko IDE i na tym się skończyło. Chciałem zacząć od tiny13 (zrobić dotykowy kontroler taśmy LED) Ale dałem sobie siana.

    Kumpel kiedyś przyniósł do mnie moduł raspberry pi. To o tyle było ciekawe, że można było podłączyć do monitora po HDMI oraz programować porty graficznie. Ale ta nakładka jakoś mnie nie przekonała. To była raczej jakaś zabawka dla przedszkolaków, a nie poważne narzędzie graficzne w którym kod C rysujesz a nie piszesz...
    Narzędzia które mam tj. wspomniałeś obsługują dawno przestarzałą technologię, ale plusem jest to, że czy teraz, czy za rok siadam i programuję. Ważne jest tylko ażeby pod własne bloki zrobić rzetelny opis.
    Same sterowniki na potrzebę chwili w technologii THT, to i flamastrem idzie obleć. heh

    Tutaj przykład. Jeden do zabawy z enkoderem i żarówkami, a drugi do testów...
    Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku? Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku? Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku? Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku?
    Tego drugiego tymczasowo zamierzam użyć do obsługi zgrzewarki ogniw, bo ta co kupiłem z Chin strzeliła po pierwszym spawie...
    Zrobię swój programik + jakieś moje bajery...
  • Computer Controls
  • #3
    tmf
    Moderator of Microcontroller designs
    spec220 wrote:
    Generalnie sama obszywka takich modułów to jak dla mnie małe piwo, ale żeby przeskoczyć próg programowania, to chyba musiałbym sobie dołożyć jakiejś pamięci twardej do głowy...

    I to się da ogarnąć. Mam pommysł na kilka filmików, w których pokażę jak właśnie zrobić coś od podstaw mając MCU i notę katalogową układu/scalaka, który chcemy podłączyć.
    Takie gotowe moduły typu Curiosity mają głównie tą zaletę, że siadasz, programujesz i nie musisz się martwić czy wszystko dobrze podłączyłeś, skonfigurowałeś itd.
  • #4
    398216 Usunięty
    Level 43  
    tmf wrote:
    Mam pommysł na kilka filmików, w których pokażę jak właśnie zrobić coś od podstaw mając MCU i notę katalogową układu/scalaka, który chcemy podłączyć.
    Jestem za. Ostatnio w dziale dużo artykułów dla zaawansowanych - jakby zapomniano, że najpierw trzeba się podstaw nauczyć.
  • #5
    khoam
    Level 41  
    tmf wrote:
    Czy próbowaliście nowe mikrokontrolery AVR serii DA, DB itd.? Korzystaliście z ATMega4809 i podobnych?

    Może trzeba było choć nieco wspomnieć o dostępności Arduino Core dla tych MCU? Projekt MegaCoreX cały czas jest rozwijany i nie wymusza użycia Arduino IDE ani też gotowych, chińskich modułów o nazwie "Arduino" ;)
  • #6
    JohnKaldachar
    Level 5  
    Weź AVR w góry :-). Tak z nim rozpoczniesz przygodę. Później się zobaczy.
  • #7
    spec220
    Level 25  
    tmf wrote:
    Takie gotowe moduły typu Curiosity mają głównie tą zaletę, że siadasz, programujesz i nie musisz się martwić czy wszystko dobrze podłączyłeś, skonfigurowałeś itd.

    Taki gotowy moduł jak dla mnie, to w zasadzie mniej roboty z lutowaniem... Wstępna konfiguracja/ ustawienie bitów, czy też wgrywanie gotowego bootloadera z poziomu programatora po SPI (teraz są nowsze protokoły) też nie jest niczym nadzwyczajnie skomplikowanym. Większy problem stanowi sam projekt w którym możesz popełnić błąd. Tzw. skonstruowałeś coś własnego co teoretycznie na kartce papieru działa, ale w rzeczywistości trzeba wprowadzać poprawki. Ale to jest standard.

    Natomiast jeśli rozchodzi się o programowanie w C, to nie tyle jest ono problematyczne, co problem stanowi zawodna ludzka pamięć do zapamiętywania tekstu... Jak byś znalazł metodę jak skutecznie zapamiętywać polecenia C, czy też C++, tak aby za miesiąc tego nie zapomnieć, to by było super. Samo robienie programu metodą graficzną/ drabinkową, niczym się nie różni od metody pisanej. Oczywiście mowa tu o logice samego myślenia oraz wyobraźni względem celu jaki chcemy osiągnąć.

    Powiem więcej. Po tym jak obejrzałem ten film, C jest prostszy od metody graficznej, bo wszystko za ciebie robi. Pokazałeś migającą diodę o nic się nie martwiąc. Nie przejmujesz się tym, że jest coś takiego jak główna pętla programowa/ systemowa, tylko klepiesz tyle ile tylko się da na jeden cykl programowy (C sam za ciebie podzieli stosy), nie przejmujesz się tym, że wymuszasz działanie dzielenia prze "0". Nie przejmujesz się tym, że jest coś takiego jak kolejność wykonywania działań/ pętli (są tacy co twierdzą, że to nie ma znaczenia), i nie przejmujesz się tym co było wyraźnie widać na filmie, że dioda wisi w tzw. jednej głównej pętli, i nic się nie dzieje. Czyli w C jak popełnisz błąd gdzieś w którymś momencie gdzie program zawiśnie na jakiejś pętli która odwołuje się sama do siebie blokując przejście programu do kolejnych procesów, to po prostu nic się nie dzieje :?: ...
    W graficznym programowaniu od wszystkiego co wymieniłem wyżej jest reset procka... Naprawdę można zrobić obszerny program, a czegoś nie dopatrzysz/ dokładnie sprawdzisz i masz reset powiedzmy za jakiś czas użytkowania w którym program natrafił na "wiszącą pętlę" , albo przekroczył ilość dopuszczalnych zadań w jednym cyklu głównej pętli. W C takich problemów nie ma. Przynajmniej widać to na filmie.
    Puściłeś LED-a w jednej zakleszczonej pętli i jest ok. W graficznym byłby reset od zwisu samo odwołania. Każde mignięcie LED trzeba przerzucić do następnego biegu programowego. No ale to jest jak wspomniałeś stara architektura procków gdzie jeszcze były w miarę przyzwoite nakładki graficzne...

    Tutaj poniżej przykład tego co pokazałeś na filmie. Też dioda miga tak szybko, że tego nie widać okiem. Różnica polega na tym, że w pierwszym przypadku procek wysypie reset od samo odwołania pętli w jednym cyklu całego programu. W drugim każde mrugniecie odbywa się co całą główną pętlę systemową, i jest prawidłowo, a w trzecim wprowadziłem miganie 50/50 co 0,5s czyli 1Hz.

    Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku?

    To pokazuje, że C jest prostsze, bo w moim przypadku już na start można popełnić błąd. A taki błąd można popełnić gdziekolwiek, oraz w sposób trudny do wychwycenia. Może on wystąpić np. przy odwołaniu na jakimś działaniu arytmetycznym powiązanym z pętlą która zawiśnie . W C tego oczywiście nie ma. Przynajmniej tyle wywnioskowałem z filmu...
  • #8
    tmf
    Moderator of Microcontroller designs
    khoam wrote:
    Może trzeba było choć nieco wspomnieć o dostępności Arduino Core dla tych MCU?

    Prawdę mówiąc nawet nie wiedziałem, że już na te MCU są porty. To dobrze. Ciekawi mnie, czy na tym MCU VMT jest we FLASH, czy nadal jest kopiowane do SRAM, co jest zmorą C++ na AVR.
    398216 Usunięty wrote:
    Jestem za. Ostatnio w dziale dużo artykułów dla zaawansowanych - jakby zapomniano, że najpierw trzeba się podstaw nauczyć.

    Też tak myślę. Tym bardziej, że zaawansowani raczej nie potrzebują poradników :)

    Dodano po 12 [minuty]:

    spec220 wrote:
    Taki gotowy moduł jak dla mnie, to w zasadzie mniej roboty z lutowaniem... Wstępna konfiguracja/ ustawienie bitów, czy też wgrywanie gotowego bootloadera z poziomu programatora po SPI (teraz są nowsze protokoły) też nie jest niczym nadzwyczajnie skomplikowanym.

    To prawda. Ale na początku to może sprawiać problemy i jest zniechęcające. A fusebity na starych AVR, które umożliwiały zablokowanie zegara są zmorą. Na nowszych (od XMEGA do nowych ATMega, AVR Dx) już tego problemu praktycznie nie ma.
    spec220 wrote:
    Natomiast jeśli rozchodzi się o programowanie w C, to nie tyle jest ono problematyczne, co problem stanowi zawodna ludzka pamięć do zapamiętywania tekstu... Jak byś znalazł metodę jak skutecznie zapamiętywać polecenia C, czy też C++

    W tym języku jest zaledwie kilkanaście poleceń/słów kluczowych. Natomiast świetną robotę robi IDE z systemem podpowiedzi. Bez tego byłoby istotnie trudno zapamiętać te kilka tysięcy definicji z pliku IO.h dla każdego procka. Tu przy okazji, w końcu Microchip, a wcześniej Atmel też pomogli, ujednolicając strukturę i nazewnictwo układów peryferyjnych. Dzięki czemu timet na XMEGA ma praktycznie takie same rejestry i definicje jak na nowej ATMega, czy AVR Dx.
    spec220 wrote:
    Czyli w C jak popełnisz błąd gdzieś w którymś momencie gdzie program zawiśnie na jakiejś pętli która odwołuje się sama do siebie blokując przejście programu do kolejnych procesów, to po prostu nic się nie dzieje

    Dzieje się - program utknie w tym punkcie. Natomiast pętla nie jest wywołaniem rekurencyjnym (a myślę, że o to ci chodzi), w efekcie nie dochodzi do przykrych rzeczy typu przepełnienie stosu. Tu z kolei bardzo pomaga debugger - łatwo można wykryć takie problemy i łatwo można ustalić gdzie program utknął.
  • #9
    khoam
    Level 41  
    tmf wrote:
    Ciekawi mnie, czy na tym MCU VMT jest we FLASH, czy nadal jest kopiowane do SRAM, co jest zmorą C++ na AVR.

    https://www.elektroda.pl/rtvforum/viewtopic.php?p=18472215#18472215
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=18472264#18472264
    :)
  • #10
    spec220
    Level 25  
    tmf wrote:
    Dzieje się - program utknie w tym punkcie. Natomiast pętla nie jest wywołaniem rekurencyjnym (a myślę, że o to ci chodzi), w efekcie nie dochodzi do przykrych rzeczy typu przepełnienie stosu. Tu z kolei bardzo pomaga debugger - łatwo można wykryć takie problemy i łatwo można ustalić gdzie program utknął.

    No to ja mam symulator PC, oraz podgląd zmiennych w czasie rzeczywistym po UART, czy tam RS232... Bez tego, to bym się zamęczył...
    Co do nowszych procków, to też nie dobrze jak utknie w martwym punkcie. W moim przypadku nawet jakby się zdarzył błąd, i doszłoby do przepełnienia stosu który wywoła automatyczny reset, to taka sytuacja niejednokrotnie ratuje sprawę, bo sterownik wznowi pracę gdzie niekoniecznie musi ponownie natrafić na ten sam bug.

    tmf wrote:
    A fusebity na starych AVR, które umożliwiały zablokowanie zegara są zmorą.

    Przyznam się szczerze, że tylko raz zablokowałem ATmega168, bo oczywiście przekombinowałem. Rozdzielczość timerów jest zsynchronizowana z główną pętlą systemową i wynosi jedynie 10ms. Chciałem wyciągnąć trochę więcej i zrobiłem głupotę. Nie sądziłem że to zablokuje procka. Rezonator wstawiłem 16MHz, a w bitach ustawiłem bodajże 4MHz. Chciałem go przetaktować aby przyśpieszyć program. Nie zadziałało. :D Kombinowałem później z 8MHz i te inne poradniki google, ale chyba "zdechł na amen" W ogóle brak komunikacji po SPI. Może po JTAG by poszło, ale wątpię, bo nie było ustawione w fusach.

    tmf wrote:
    Natomiast świetną robotę robi IDE z systemem podpowiedzi

    No właśnie ja kiedyś ściągnąłem jakieś IDE gdzie nie było niczego. Myślałem, że będzie podobnie jak w graficznym.
    Jak widzisz w poście #7 masz z boku listę dostępnych działań. Są skróty klawiszowe, ale tu jest o tyle fajnie że działa metoda przeciągnij i upuść. Podobnie jak w Windows.
    I co ważne jest system podpowiedzi pod F1 w języku polskim. Nie trzeba tekstu przeciągać do tłumacza google aby zrozumieć o co się chodzi...
    Tutaj przykład;

    Jak zacząć przygodę z mikrokontrolerami AVR w 2022 roku?
  • #11
    tmf
    Moderator of Microcontroller designs
    khoam wrote:
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=18472215#18472215
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=18472264#18472264

    Tak, ale sam fakt, że MCU ma jedną, płaską przestrzeń adresową nie implukuje bezpośrednio, że wspiera to kod startowy c++ i sam avr-g++. VMT to wewnętrzna struktura budowana przez kompilator i o ile nie zmieniono kodu, to na nowych AVRach, pomimo płaskiej przestrzeni ciągle VMT może być kopiowane do SRAM. Muszę to sprawdzić, niestety, pomimo sporej popularności Arduino, wydaje się, że avr-g++ jest mocno zapuszczony.
    Natomiast przy stałych, kompilator poprawnie je umieszcza we FLASH, niestety, jest za to odpowiedzialna relatywnie prosta część frontendu kompilatora, co znacznie ułatwia jego dostosowanie. Jak lata temu próbowałem zwrócić uwagę na problem VMT, to tylko mnie zjechali, bo ogólnie developerzy gcc nie rozumieli w czym jest problem :)
  • #12
    khoam
    Level 41  
    tmf wrote:
    Muszę to sprawdzić, niestety, pomimo sporej popularności Arduino, wydaje się, że avr-g++ jest mocno zapuszczony.

    Nie udało mi się odnaleźć informacji na temat VMT w dokumentacji avr-g++. Wygląda na to, że zalecanym przez Microchip kompilatorem C/C++ jest komercyjny IAR Embedded Workbench, w szczególności dla nowych AVR. Nie dziwi mnie brak wsparcia ze strony Microchip dla avr-gcc i avr-g++.
  • #13
    tmf
    Moderator of Microcontroller designs
    khoam wrote:
    Nie dziwi mnie brak wsparcia ze strony Microchip dla avr-gcc i avr-g++.

    Niestety, mają też swój, płatny kompilator i przypuszczam, że raczej nie będą skłonni rozwijać darmowego avr-gcc, bo to przecież strzelanie sobie w kolano. Na szczęście ciągle znajdują się osoby, które się w to angażują i nowsze wersje avr-gcc powstają. Tu trzeba też oddać honor firmie Microchip bo większość łatek do gcc udostępniła i jakiś czas temu wsparła kwotą kilku tys. dolarów donację na przerobienie backendu gcc na mode CC, bez czego avr wyleciałby z listy wspieranych mikrokontrolerów w nowszych wersjach gcc. Z drugiej strony pewnie nie zrobili tego bezinteresownie, bo przecież ich kompilator jest oparty na gcc, więc pewnie taniej wesprzeć freelancera niż zapłacić własnym inżynierom wielokrotnie więcej za to samo.
  • #14
    khoam
    Level 41  
    @tmf Sprawdziłem i niestety nawet w najnowszej wersji avr-gcc nie ma wsparcia dla VTABLES we flash i wygląda na to, że długo jeszcze nie będzie. Generalnie avr-gcc określa się mianem "trupa pod respiratorem".
  • #15
    ppc
    Level 16  
    Pytanie powinno brzmieć "Po co zaczynać przygodę z mikrokontrolerami AVR w 2022?". Jaką przewagę ma ta rodzina MCU nad innymi nad innymi po za (niestety wciąż) popularnością? Już nawet cena nie jest atrakcyjna. Mam flashbacki ze studiów, gdzie jeszcze 10 lat temu na PW uczono programowania 8051 w assemblerze jako wprowadzenie do świata MCU. Docent się nauczył, to i reszta musiała, chociaż zastosowanie praktyczne żadne.
  • #16
    khoam
    Level 41  
    ppc wrote:
    Mam flashbacki ze studiów, gdzie jeszcze 10 lat temu na PW uczono programowania 8051 w assemblerze jako wprowadzenie do świata MCU. Docent się nauczył, to i reszta musiała, chociaż zastosowanie praktyczne żadne.

    Trochę się z tym nie zgodzę. Sam zaczynałem "wiek" temu uczenie się programowania na PDP w asemblerze :) Później było 8080, Z80 (tu przerzuciłem się na C). Niczego nie żałuję. Uważam, że AVR nadaje się dobrze do rozpoczęcia przygody w embedded jak każdy inne, dostępne obecnie MCU. Pytanie, czy robimy to w celach hobbystycznych, czy planujemy na tym zarabiać kasę. Niezależnie od tego warto znać więcej niż jedną rodzinę MCU i nie podchodzić do tego ortodoksyjnie. Dla mnie osobiście ważniejsza jest jakość ekosystemu programowania (toolchain, IDE, dokumentacja) niż same logo na procku.
  • #17
    mkpl
    Level 37  
    Jest rok 2022 AVR dawno za mną a ze względu na ceny i dostępność przesiadam się na 8051 w wykonaniu firmy STC.
    Może warto zrobić jakieś artykuły o tych procesorach? Kosztują ~3zł a mają możliwości zbliżone do AVR'a - w prostych projektach idealne.
  • #18
    tmf
    Moderator of Microcontroller designs
    Ceny odgrywają rolę przy produkcji seryjnej. Dla hobbysty różnica 3 zł vs. 30 zł jest raczej bez znaczenia, bo to niemalże jednorazowy wydatek. To co ma znaczenie wg mnie, to zacytuję:
    khoam wrote:
    Dla mnie osobiście ważniejsza jest jakość ekosystemu programowania (toolchain, IDE, dokumentacja) niż same logo na procku.

    Ja bym jeszcze do tego dodał - wsparcie. Bo hobbysta może liczyć tylko na innych hobbystów, w efekcie warto wejść w coś co jest mniej więcej popularne i jest szansa na uzyskanie pomocy.
    Natomiast oczywiście każdy ma własne cele i przesłanki do podjęcia decyzji. Jak pisałem na początku - poradnik jest dla tych, którzy wybrali AVR, bez wnikania w przyczyny.
    To co potencjalnie miało do tej pory znaczenie w świecie AVR to relatywnie wysoka w porównaniu do innych rodzin cena narzędzi. Na szczęście wraz z wypuszczeniem SNAPa, czy dev kitów typu Xplained lub Curiosity sytuacja się zmieniła na korzyść hobbystów i za przystępną cenę można mieć świetne zabawki na start. Tu w końcu AVRy trochę dogoniły konkurencję i warto w związku z tym zmienić stare nawyki i porzucić prehistoryczne narzędzia typu USBAsp.
  • #19
    KJ
    Level 31  
    Ja bym w sumie zadał pytanie czy w 2022 roku warto w ogóle wchodzić w AVRy. Mam wrażenie ze ten rdzeń jest dziś równie przestarzały jak był dla mnie Z80 kiedy zaczynałem przygodę z avrem jakieś ~20 lat temu. Acz na pierwszy kontakt z programowaniem może faktycznie warto ze względu na relatywna prostotę tych układów w porównaniu z takim stm32 ESP czy innym Psoc5 i brak zjawiska jak ja to zwykłem określać klęski urodzaju :D
  • #20
    victoriii
    Level 18  
    Uzywanie przestarzalych architektur i ukladów ma sens jak cena odpowiada przestarzalosci, np STC jest raczej przestarzale, ale cena jest atrakcyjna, a AVR to bardziej dwudziestoletni Maluch za cene nowego BMW.
    Jesli chodzi o skomplikowanie nowoczesnych procesorów, to mam wrazenie ze jest to ukryte za dostarczonymi bibliotekami.
    Gdybym mial polecac cos prostego na poczatek to raczej polecilbym 8051 bo wyglada na to ze 8051 jest popularny i jeszcze wiele lat bedzie na rynku a AVR to raczej niszowa sprawa chyba.
  • #21
    KJ
    Level 31  
    Fakt - rzadko się je widuje w komercyjnych produktach. Kiedyś za popularnością wśród amatorów stał Bascom dziś stoi arduino. 8051 jest chyba nieśmiertelne podobnie jak x86 w PC. Ciekawą rodziną od Atmela/Microchipa są też ATSAM-y acz w tej chwili bieda z dostępnością.
  • #22
    victoriii
    Level 18  
    AVR byl dawniej popularny w chinskich produktach zdalnie sterowanych, ale od kiedy Chinczycy zaczeli robic wlasne ARMy i inne albo PADAUKi albo STC to ta nisza tez zniknela bo AVR nie byl ani dobry ani tani.
    Zastanawiam sie czy 8051 nie zostalo jakos otwarte przez Intela albo patenty wygasly i dlatego jest tak chetnie stosowane...

    Ja zaczynalem z AVR w 1998/1999 roku i wtedy po kilku latach na AT89C2051 to bylo objawienie, wreszcie pojawilo sie cos nowoczesnego! Ale to bylo ponad 20 lat temu a czas nie stoi w miejscu.
  • #23
    KJ
    Level 31  
    Dla mnie takim objawieniem jest od jakiegoś czasu Psoc5 od cypressa :D ale ja zdecydowanie za długo tkwiłem w AVRach :P No i tych procków też nie ma :/
  • #24
    victoriii
    Level 18  
    PSoC faktycznie jest ciekawy. Kiedy ja sie tym zainteresowalem to nie robili jeszcze z rdzeniem ARM i kompilator byl platny tak ze to mnie odrzucilo, a teraz robie glownie uklady cyfrowe a wydaje mi sie ze PSoC blyszczy glownie tam gdzie sa wysokie i customowe wymagania analogowe. Dodatkowo PSoC wydaje mi sie nie jest popularny w Chinach, a w Farnellach itp ceny sa jak zawsze zaporowe.

    Mój ostatni kontakt z AVR to 2012 ;)
  • #25
    tmf
    Moderator of Microcontroller designs
    Panowie, to jest wątek dla początkujących. Na samym początku napisałem, że ten temat jest poświęcony AVR, a nie dyskusji nad wyższością jednych Świąt nad innymi. Więc proszę przenieść tą ciekawą dyskusję do oddzielnego wątku.
    Sugerowanie, aby początkujący rozpoczęli od PSoC jest co najmniej dziwne i chyba tylko kogoś zniechęci, '51 był popularny i ciągle jest w przemyśle, ale ze względu na architekturę, dostępne płytki rozwojowe i toolchainy też nie jest najlepszą opcją na początek. A potem to i tak tylko ARM. Na dzisiaj mamy 3 rozwiązania dla początkujących:
    - AVR - bardzo proste i dobre dla osób od kompletnie zielonych, do całkiem zaawansowanych, szeroka gama możliwości.
    - ARM - wyższy próg wejścia, raczej dla osób, które mają pewność, że mikrokontrolery to ich droga życiowa, bardzo szeroka gama możliwości,
    - ESP/ESP32 - świetny dla hobbystów, relatywnie niski dzięki Arduino próg wejścia, ae ciągle mało materiałów i tutoriali poza Arduino, mała rodzina i narzędzia mogłyby być lepsze. Ale dla kogość kto chce wystartować z WiFi, BT, najlepsza opcja.
  • #26
    khoam
    Level 41  
    tmf wrote:
    ale ciągle mało materiałów i tutoriali poza Arduino, mała rodzina i narzędzia mogłyby być lepsze.

    Bez przesady. Akurat nie-arduinowej dokumentacji do ESP jest znacznie, znacznie więcej (Link). Natomiast pisanie bezpośrednio z użyciem ESP-IDF to mniej, więcej taki sam próg wejścia, jak z STM32 i Cube HAL. Narzędzia do debugowania ESP to praktycznie te same, jak w wypadku ARM.
  • #27
    Simon79
    Level 19  
    Ciekawy tutorial, mimo iż nie jestem początkujący (pierwszy procesor AT90S2313 zaprogramowałem jakieś 20 lat temu :) ). Obecnie jeśli coś sobie grzebię w kabelkach to albo jest to nieszczęsne arduino nano lub uno albo zapas atmeg 8 i 88 z czasów BASCOM'a.
    Zachęcił mnie Kolega do wyciągnięcia z szuflady ATTINY817 XPLAINED MINI. Czekam na kolejne odcinki.

    mkpl wrote:
    Jest rok 2022 AVR dawno za mną a ze względu na ceny i dostępność przesiadam się na 8051 w wykonaniu firmy STC.
    Może warto zrobić jakieś artykuły o tych procesorach? Kosztują ~3zł a mają możliwości zbliżone do AVR'a - w prostych projektach idealne.

    Zaintrygowały mnie te STC, mógłby Kolega podać, które wersje MCU konkretnie kosztują ~3zł ?