Elektroda.pl
Elektroda.pl
X
Elektroda.pl
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Arduino? W porządku, ale co dalej?

08 Lip 2018 20:13 2952 83
  • #31
    Użytkownik usunął konto
    Poziom 1  
  • PCBway
  • #32
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #33
    Użytkownik usunął konto
    Poziom 1  
  • #34
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #35
    Taenia_Saginata
    Poziom 31  
    z3planety napisał:
    ciekawe czy jest choć jeden z samochodówki


    Jest.
  • #36
    tplewa
    Poziom 38  
    Marek_Skalski napisał:
    Odpowiadam Autorowi tematu, który rozważa temat pod kątem rozwoju zawodowego.
    Czy warto inwestować energię, czas i środki w poznawanie produktów, które w perspektywie zawodowej nie mogą zostać zastosowane?


    Powiedzmy sobie tak od czegoś trzeba kiedyś zacząć... sama rodzina mikrokontrolerów IMHO na początku jest drugorzędna. Im prostszy tym szybciej ogarniemy, a jak ktoś jest kumaty to przesiadka na inny kończy się za zwyczaj przeczytaniem dokumentacji (przynajmniej tak jest u mnie).

    Jak kolega bawi się arduino i ma trochę płytek to ja na początku próbował bym ogarnąć te AVR-y pisząc normalnie w C ewentualnie można i pokusić się o ASM (wiem to mało potrzebne w praktyce, ale poznanie ASM wiele ułatwia - wiemy jak działa procesor co potem procentuje). Dlaczego tak bo koszt praktycznie zerowy. Jak ogarnie się AVR-y można śmiało przechodzić na inne procki...
  • #37
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #38
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • PCBway
  • #39
    tplewa
    Poziom 38  
    z3planety napisał:
    tplewa napisał:
    Powiedzmy sobie tak od czegoś trzeba kiedyś zacząć.
    Ja jednak twierdzę, że nauka C czy też C++ na uC to nie najlepszy pomysł. Nauczyć się najpierw dobrze poprawnie programować, a uC nie będą stanowiły żadnego problemu.


    Niestety nie do końca. Zauważ że programując w C/C++ część spraw jest uniwersalna, a część zależna od platformy... Z drugiej strony pisanie na mikrokontrolery nie wyklucza pisania np. aplikacji na PC itp. np. w celu łączności z tymi mikrokontrolerami itd. Natomiast co do dobrych nawyków w programowaniu to jest temat rzeka i IMHO platforma nie ma tutaj znaczenia...

    nowyARM napisał:
    tplewa napisał:
    Im prostszy tym szybciej ogarniemy,

    To fakt. Nie podajmy jednak w skrajności i nie proponujmy podstawowych wersji 8051 czy Z-8. AVR, czy "małe" pic to dobry wybór.


    Dlatego właśnie wspomniałem o AVR-ach bo mając płytki arduino ma się praktycznie wszystko co potrzeba - wystarczy pobrać np. AVRStudio i rozpocząć zabawę. Inny mikrokontroler to zawsze jakiś wydatek na programator itd.
  • #40
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #41
    tronics
    Poziom 37  
    @tplewa - nie jest to prawda. Nie ma debuggera. A coś wydajniejszego w cenie arduino to bluepill z STM32F103 czyli jak Marek_Skalski napisał rodzina starsza i na wyginięciu, ale przynajmniej zapoznaje z 32bit MCU i architekturą ARM (ahb, apb, rcc, dma, różnorakie timery i nvic).
    Inne platformy, mocniejsze, gotowe do rozpoczęcia zabawy, w miarę tanie i do tego część z debuggerem (nucleo, discovery, psoc devkit, nxp freedom, olimex), a część jak arduino bez (teensy, feather, rzeczony maple czy jego klon bluepill). Niektóre płytki mają nawet gniazda zgodne z nakładkami do arduino. I część jest wspierana przez IDE Arduino (po dociągnięciu boards).
  • #42
    tplewa
    Poziom 38  
    tronics napisał:
    @tplewa - nie jest to prawda. Nie ma debuggera. A coś wydajniejszego w cenie arduino to bluepill z STM32F103 czyli jak Marek_Skalski napisał rodzina starsza i na wyginięciu, ale przynajmniej zapoznaje z 32bit MCU i architekturą ARM (ahb, apb, rcc, dma, różnorakie timery i nvic).


    A po co ci w tych AVR debugger ? Można pisać i bez niego... Do tego co wy ciągle z tymi STM32 jak by innych procków na tym świecie nie było... Kolejna sprawa co z tego że tanie, ale to zawsze jakiś wydatek. Natomiast w przypadku nauki nie ma większego znaczenia czy się zacznie na AVR czy na STM32... Natomiast znając już dobrze jakieś procki można podejmować świadomy wybór (a nie STM32 bo to na elektrodzie modne). Nie wiem ja zaczynałem od 6502 i Z80, potem 8051 i następnie jak pojawiły się na ryku AVR-y... jakoś nie cierpię z tego powodu (praktycznie swobodnie sobie procki wybieram do projektu nie patrząc na to czy to STM32 tylko na to co mi jest potrzebne np. specyficzne peryferia). Grunt jak pisałem to załapać o co w mikrokontrolerach chodzi, potem przesiadka jest łatwa i bezproblemowa...
  • #43
    tronics
    Poziom 37  
    Cytat:
    Do tego co wy ciągle z tymi STM32

    PSoC devkit to rdzeń Cortex, owszem (starsze miały 8051), natomiast producent to Cypress, a rodziny to PSoC4 i PSoC5 (jest już lub niebawem będzie PSoC6). Jakby nie patrzeć nie jest to STM32 od ST Microelectronic. Freedom to procesory Kinetis. Rdzeń Cortex-M, a jakże. Producent Freescale, a od jakiegoś czasu NXP (po przejęciu/połączeniu). Czyli nie STM32 i nie ST Micro. To samo dotyczy Teensy. Feather od Adafruit to płytki m.in. na AVR, ale też na nRF52 (nordic semiconductor, rdzeń cortex m), na ESP8266, na ESP32 (Espressif) na SAMD21 (Atmel). Olimex to także LPC od NXP. Proszę nie pisać bzdur, że promuję STM32 skoro bardzo wyraźnie opisałem popularne i tanie konstrukcje różnych producentów. A to czy na AVR debugger jest niepotrzebny to wystarczy zobaczyć w ilu tematach gdzie się ma problem z "niewłaściwym działaniem" ten debugger by problem pomógł rozwiązać raz dwa... A bez debuggera można pisać na każdą platformę, jak się nie zakopiesz w błędach własnych, kompilatora czy dokumentacji to będzie działać.
  • #44
    tplewa
    Poziom 38  
    tronics napisał:

    A to czy na AVR debugger jest niepotrzebny to wystarczy zobaczyć w ilu tematach gdzie się ma problem z "niewłaściwym działaniem" ten debugger by problem pomógł rozwiązać raz dwa... A bez debuggera można pisać na każdą platformę, jak się nie zakopiesz w błędach własnych, kompilatora czy dokumentacji to będzie działać.


    Kolego ale co mnie to że jest tam ileś tematów ludzi z problemami (to bardziej kwestia obecnych czasów że ludzie z lenistwa pytają, kiedyś nie było elektrody itp. i też człowiek sobie radził)... Kupę lat pisałem bo nie było i jakoś problemów nie miałem (widać można). Może i to na plus mi wyszło bo można też zerknąć ile ja postów napisałem odnośnie moich problemów z mikrokontrolerami czy jakiś pytań (ja pamiętam dwa jeden dotyczący disassemblacji softu z dsPIC-a i chyba jeden odnośnie wyboru RTOS-a).

    Natomiast dalej uważam że jak ma się platformę do nauki to lepiej się zabrać za naukę na niej niż wymyślać - bo to wiele nie zmieni. Jak to co się ma przestanie wystarczać można celować w inne procki. Powiedzmy sobie szczerze do tego co się robi podczas nauki nie potrzeba super procka, a AVR-y (zwłąszcza nowe tiny itp. jeszcze mogą znaleźć zastosowanie w wielu projektach).
  • #45
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #46
    tronics
    Poziom 37  
    @tplewa

    Pisałeś
    Cytat:
    Inny mikrokontroler to zawsze jakiś wydatek na programator itd.

    Podałem wiele innych spełniających ten warunek (brak dodatkowych wydatków), za co otrzymałem taką odpowiedź
    Cytat:
    Do tego co wy ciągle z tymi STM32 jak by innych procków na tym świecie nie było

    Są PIC, ale nie ma aż tak dużo tanich eval board, a mcu są z reguły "skrojone na miarę", wreszcie gorzej z dostępnymi libsami. Są '51 jakieś dallasy czy efm8. Można? Można. Ale nie ma za bardzo eval board i przyjemnych IDE, że o libsach nie wspomnę. Napisałem co popularne i tanie, a że producentów wielu to do wyboru, do koloru.
    Cytat:
    Natomiast znając już dobrze jakieś procki można podejmować świadomy wybór

    A czy ja to gdzieś negowałem? Wskazałem platformy w porównywalnej cenie do płytek arduino (czy to oryginalnych, czy klonów) a mające większe możliwości. Nie bez powodu wśród oryginalnych arduino są modele na SAMD21. Pytanie autora to "co po arduino" w kierunku rozwoju zawodowego. Czy w obecnych czasach AVR jest równie przyszłościowe co mikrokontrolery oparte o CortexM? Jak słusznie gdzieś kol. nowyARM zauważył lepsze konstrukcje w razie awarii oscylatora z kwarcem zewn. (z czym się akurat spotykałem w jakiś 5% przypadków "martwych" urządzeń na mega2560) ów problem wykryją i wstając zawsze na wewn. oscylatorze będą tą sytuację mogły obsłużyć i zakomunikować. Na starszych AVR i większości 51 będzie zwyczajnie dead (nawet nie pamiętam jak jest w tiny 1 series i nowych mega - podejrzewam, że jak w xmega czyli int rc boot). Nowe AVR z kolei nie są bezpośrednio wspierane w arduino, eval boardy nie są zbyt popularne. Na to trzeba zwracać uwagę. Ja też zaczynałem od 6510 (bo C64), 68k (piękny asm) i 8051 (pamiętałem kompletne ISA i ilość cykli każdej instrukcji w każdej wariacji). Przez AVR też przechodziłem i nadal używam. Co nie znaczy, że nie warto patrzeć dalej, szerzej. A w tym konkretnym przypadku tj. tytułowym "co dalej" to sprawa dla mnie jest jasna. Dalej to nowe rodziny mikrokontrolerów. Można zostać przy Atmelu i oglądać SAM. Można spróbować STM32, bo tanie, dobre, mnogo modeli. Można zainteresować się Cypressem i jego elastycznością. Itp. Itd. Dla przyszłego pracodawcy im ciekawsze projekty (co w pewnym stopniu wymusza nowocześniejsze konstrukcje) tym lepiej.


    Cytat:
    A właśnie czym jest wspomniana architektura ARM ? Czy ogólnie co to jest architektura danego procesora/mikroprocesora?

    Tu można by długo pisać, sama architektura mikrokontrolera to na dobrą sprawę schemat blokowy. Rdzeń + peryferia. Rdzenie ARM stosowane w mikrokontrolerach to z reguły Cortex-M. One są ustandaryzowane i tak poszczególne rodziny to Cortex-M0, M0+, M3, M4, M7. W kolejności od najuboższego (względem listy rozkazów i często "mocy" peryferiów) do najmocniejszego. Rdzeń gada z peryferiami za pomocą AHB lub APB czyli dedykowanych magistrali. Reszta otoczki w zasadzie jest zależna od producenta, jakie timery, ile timerów, jakie uarty, ile ... jakie adc, ile ... itp. itd. Względem AVR z reguły jest (może być wiele z niżej wymienionych, albo tylko np. 1)
    *więcej RAM
    *więcej FLASH
    *więcej peryferiów
    *szybsze peryferia
    *dokładniejsze peryferia
    *większa kontrola nad domenami zegarowymi
    *większa wydajność rdzenia na MHz
    *szybszy zegar bazowy
    *więcej rejestrów do uzyskania tej samej funkcjonalności (więcej trzeba się naklepać)
    *większa różnorodność podobnych peryferiów w zakresie funkcjonalności (procedura dla X nie musi dobrze działać na Y i vice versa).

    A sam rdzeń AVR jest 8 bitowy, z 8 bitowym ALU i 8 bitowymi rejestrami. Rdzeń ARM jest 32 bitowy zatem 4x szerszy. Innymi słowy za każdym razem gdy NIE używasz typu 8 bitowego na AVR kompilator rozbija to na kilka operacji 8 bitowych. W przypadku ARM będzie mogło (mogło! wcale nie musi, zależnie jak się napisze program) być wykonane szybciej. Niemniej 32bitowa architektura ma też swoje minusy - same rozkazy zajmują więcej bajtów więc plik wynikowy może być obszerniejszy (większe zapotrzebowanie na pamięć) - stąd wymyślono Thumb-2 by móc tworzyć bardziej zwarty kod z minimalnym spadkiem wydajności. AVR jako 8 bitowiec nie przeskoczy ani granicy swojej wydajności na takt, ani swojej granicy obsługiwanej pamięci (tu można by zwiększyć, ale znów - kosztem wydajności więc po co?). AVR jak każdy 8 bitowiec ma swoje zastosowania, a to że mikrokontrolery o zubożonej architekturze 32bitowej już się wbijają w to podwórko 8 bitowców dla każdego powinno jedną żaróweczkę w głowie zaświecić.
  • #47
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #48
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #49
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #50
    tplewa
    Poziom 38  
    z3planety napisał:

    Wybacz @tplewa, negoawnie sensowności posiadania sprzętowego debugera jest delikatnie rzecz ujmując niepoważne.


    Kolego nie neguje... ale nie uważam jako konieczności przy nauce. Takie utrudnienie pozwala też inaczej myśleć i radzić sobie w warunkach gdzie nie mamy takiej możliwości.

    Generalnie większość wymienionych tutaj spraw odnośnie procków że mają to i tamto przy nauce podstaw programowania nie ma tutaj większego znaczenia. Natomiast takiego AVR-a łatwiej jest ogarnąć aby pisać używając rejestrów niż Cortex-a... Jak to się załapie potem jest o wiele łatwiej...

    Natomiast kolego co do pracy programistów itp. nie musisz mi mówić powiem ci że np. w PL w sporej części radiowozów policyjnych jeździ sprzęt z H8/300 (na który pisałem soft) - gdzie nie masz debugera i trzeba było sobie radzić... Tutaj zapytam się ile produktów kolegi można spotkać na świecie czy w PL... Bo moich trochę się znajdzie od fotoradarów po inny sprzęt używany w służbach mundurowych... więc nie musi mi kolega tłumaczyć zalet itd.

    Wiem że AVR-y są stosunkowo drogie, ale uważam też że nie jest to zła platforma by zacząć naukę i nie uważam że koniecznie trzeba zaczynać od Cortex-ów.
  • #51
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #52
    tplewa
    Poziom 38  
    z3planety napisał:
    tplewa napisał:
    Natomiast takiego AVR-a łatwiej jest ogarnąć aby pisać używając rejestrów niż Cortex-a...
    Najpierw trzeba poznać C - co jak widać po postach na elektrodzie, jest dużym problemem dla piszących, a uC nie są w tym zbyt pomocne :)


    Kolego czy elektroda jest wyznacznikiem całego świata ? Niech kolega jeden sensowny powód dlaczego nauka C jest niemożliwa na mikrokontrolerach...

    Problem elektrody jest to że ja piszę nie kombinuj - bierz AVRStudio + dokumentację procka i pisz (czyli ucz się bo masz wszystko co potrzeba), a połowa szuka dziury w całym i twierdzi nie kup sobie inne procki itd. no i i tak się nie nauczysz bo musisz umieć C....
  • #53
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #54
    tplewa
    Poziom 38  
    z3planety napisał:
    @tplewa
    tplewa napisał:
    Niech kolega jeden sensowny powód dlaczego nauka C jest niemożliwa
    Ponieważ imputujesz mi stwierdzenia, które nie padły z mojej klawiatury - dyskusja jest niemożliwa.

    To ja zapytam: dlaczego twierdzisz że nauka C na PC-ie jest nimożliwa, a debugger przeszkadza w trakcie debugowania?


    Nie nie przeszkadza... to kolega twierdzi że najpierw należy znać C. Ja twierdzę że nie ma znaczenia. Wspomniałem zresztą że i na PC aby coś pisać więcej należy zapoznać się z specyfiką systemu operacyjnego pod jaki będziemy pisać. Jak wspomniałem jedynie część procedur może być uniwersalna... Do tego na PC poprzez spore zasoby zatraca się coś co nazywa się optymalizacja bo niestety na uC wiele spraw czasem trzeba rozwiązać inaczej, nie da się często użyć opasłych bibliotek itd.

    Do tego nie zgadzam się że najpierw potrzeba poznać C... co to znaczy ? I dalej pytam co złego jest w tym by uczyć się C na AVR-ach ? Czuję że kolega by miał ogromny problem z takim podejściem w czasach gdy ja uczyłem się C... bo nie było elektrody, nie było ogólnie dostępnego internetu... to samo dotyczyło literatury. Za zwyczaj bazowało się na jakiś kserach na których nie wiele było widać załatwianych z różnych uczelni przez starszych znajomych...

    Natomiast koledze też mogę coś poradzić tak patrząc na kolegi pytania... będzie krótko RTFM (np. odnośnie OpenOCD). Jak kolega to ogarnie to potem może doradzać innym...
  • #55
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #56
    _lazor_
    Moderator Projektowanie
    Dodam co nieco od siebie.

    Zależy co chcesz na tych uC robić. Ja uważam uC za narzędzie jak każde, od młotek. Teraz w zależności co chcesz zrobić, to co sobie wyobraziłeś musisz dobrać odpowiednie narzędzia czyli odpowiedni uC z peryferiami, pamięciami, cechami architektury itp.

    Stm32 oprócz powyżej wymienionych zalet ma jeszcze ogromną różnorodność peryferium w różnych uC, oczywiście nie posiada wszystkiego co rynek oferuje, ale ma naprawdę spory wybór.

    Dyskusja na temat co jest lepsze w dalszej nauce zależy od tego co chcesz robić, jakiego typu projektami chcesz się zająć. Są projekty gdzie ATtiny się wspaniale sprawdzi a są projekty gdzie 8 rdzeni dsp i 3 ARM w jednym SoCu ledwo wystarczają.

    Jednak Cortexy M nie zależnie w sumie od kogo są według mnie dobrym wyborem, bo są w miare uniwersalne a i trafią się takie gdzie można robić już znacznie ciekawsze rzeczy. (Np super scalar w serii F7 czy instrukcje dsp w F3 i w górę)
  • #57
    Michal2002
    Poziom 21  
    Moje trzy grosze :
    Ja kiedyś zaczynałem od prostych procesorów 8 bitowych (Z80 , 6502) jako chłopaczek , później miałem długą przerwę, na studiach robiłem na ATmega bo mi zwyczajnie wystarczało.
    Później po prostu zaczęło mi brakować zasobów więc sięgałem po coraz to większe procesory (pojemniejsze) , aż w końcu okazało się ,że jest za wolno no i przyszła pora na ARM. Same procesory obecnie traktuje jako narzędzie , a kiedyś było tak ,że zwyczajnie jak było coś nowego to wolałem zrezygnować a to był błąd.
  • #58
    trol.six
    Poziom 31  
    ellavita napisał:
    Od 3 lat zajmuję się hobbistycznie elektroniką oraz arduino, trochę raspberry pi, esp 8266 / 32s

    To już jest dość czasu by coś umieć.
    ellavita napisał:
    Chodzi mi o coś co przydaje się w życiu zawodowym

    Jeśli jesteś przekonany a masz już jakąś wiedze, to po prostu przeglądaj ogłoszenia i idź. Może już masz wystarczające umiejętności, a ewentualne braki będziesz uzupełniał. Tudzież być może dowiesz się na rozmowie kwalifikacyjnej. Nad wieloma rzeczami działają zespoły, gdzie każdy ma część zadania. Itp itd.
    ellavita napisał:
    Generalnie to chciałbym w przyszłości pracować jako Elektronik - Programista, coś w stylu Embedded Software Developer/Engineer, łączyć elektronikę z programowaniem, to moja pasja, tylko z tego co widzę coraz mniej ofert pracy w tym kierunku i mam też wrażenie, C/C++ odchodzi w niepamięć powoli, wszędzie tylko Java Java Java

    To ucz się tej javy jeśli chcesz i możesz, znam ludzi co potrafią pisać programy w wielu językach. Może C#? To jakie są ogłoszenia zależy od proporcji potrzeb do ilości zainteresowanych. Zastanawiałeś się nad pracą w innych krajach?
  • #59
    edwi-92
    Poziom 11  
    Myślę, że kierunek zawodowy - embedded software developer to dobry kierunek jeżeli to co robisz teraz sprawia Ci przyjemność. Ofert jest mniej, ale też ludzi wyspecjalizowanych w tym kierunku jest też odpowiednio mniej ;-) Także IMHO pchać się w jave/c# tylko dla tego, że jest dużo ofert to zła droga. Weź pod uwagę też to, że dużo ofert = dużo chętnych , dużo chętnych = duża konkurencja :-)
  • #60
    kosciej
    Poziom 11  
    Nauka C na PC pod jakimkolwiek systemem operacyjnym nauczą Cię C... I na tym koniec. Tylko C to z K&R się nauczysz w weekend.

    Na uC inaczej się zarządza pamięcią, przerwaniami, są porty IO, duże ograniczenia (wymieniony AVR jest 8 bitowy...). Stm32 jest fajny, ale IMHO CubeMX, czy HAL już wymaga pewnej wiedzy z C... I koło się zamyka.

    Wg mnie warto poznać podstawy C na PC (przerobić K&R że zrozumieniem) a później od razu iść w uC.