Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Arduino? W porządku, ale co dalej?

06 Jul 2018 19:55 4365 83
NDN
  • #1
    Anonymous
    Anonymous  
    Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
  • NDN
  • #2
    Anonymous
    Anonymous  
  • #3
    jarek_lnx
    Level 43  
    Nie napisałeś ile umiesz naprawdę ale Arduino kojarzy sie z bardzo początkującymi którzy dzięki temu że istnieje Arduino oraz są dostępne gotowe płytki z układami peryferyjnymi a także biblioteki do nich, mogą połączyć to wszystko plątaniną drutów i uruchomić w 0,5h nie znając zbytnio działania użytych scalaków ani nie projektując PCB.
    Jako profesjonalista powinieneś umieć poradzić sobie bez takich ułatwień i stworzyć jedno spójne urządzenie zawierające potrzebne peryferia, oraz zasilanie.

    O ile budowanie komercyjnych urządzeń w oparciu o Arduino wiele sensu nie ma, bo zaprojektowanie własnego "arduino" jako części większego urządzenia to chwila roboty, to już z Raspberry jest nieco inaczej i tu korzyść z użycia gotowego, przetestowanego komputerka może być znacząca, jednak i tu może być potrzeba dołożenia jakichś urządzeń we/wy, zasilania i zamknięcia całości w sensownej obudowie, to co po amatorsku zazwyczaj jest olewane nabiera znaczenia.
  • #4
    Anonymous
    Anonymous  
  • #5
    JacekCz
    Level 40  
    ellavita wrote:
    Jakie platformy polecacie żeby się uczyć? Chodzi mi o coś co przydaje się w życiu zawodowym


    Znać ale tak "do spodu" C i C++, i odpowiem przeciwnie niż pytasz, ABSTRAHUJĄC od konkretnej platformy, na peciecie, najlepiej na 2-3 środowiskach (np windows Microsoft, GCC LInux). Dopiero wtedy jest pełny kontakt z formalnymi niuansami, debuugger pokazuje zmienne (żadne tam serial printy). Kod za któy jesteś w stanie odpowiadać itd...
    Nie wiem jakiego języka używasz na Raspberry, ale też bym poszerzył. Mam swoją własną sentencję, dobrze poznając TRZECI język programowania, naprawde dobrze rozumie się ten pierwszy.

    Dodano po 1 [minuty]:

    jarek_lnx wrote:
    Nie napisałeś ile umiesz naprawdę ale Arduino kojarzy sie z bardzo początkującymi którzy dzięki temu że istnieje Arduino oraz są dostępne gotowe ...


    Podobnie odczuwam, wpisanie w CV Arduino (na głownym miejscu) bardzo rzadko "chwyci"
  • #6
    jarek_lnx
    Level 43  
    nowyARM wrote:
    System, to taka czarna skrzynka i nie wiadomo jak długo będzie wykonywać się określona funkcja. W przypadku uC jest to stosunkowo łatwe do sprawdzenia, w Linux-ie już niekoniecznie. Jaki np jest czas reakcji na przerwanie zewnętrzne? W uC dokładnie wiadomo jaki będzie maksymalny czas a w Linux?
    W większych projektach na mikrokontrolerach i tak często pracuje jakiś system operacyjny (często real time), lub jego namiastka, dająca niektóre funkcje OS-a, przede wszystkim wielozadaniowość, Linux też może być real-time. Dla ekspertów nie ma tam czarnych skrzynek.
  • #7
    Anonymous
    Anonymous  
  • #8
    Anonymous
    Anonymous  
  • NDN
  • #9
    Freddie Chopin
    MCUs specialist
    ellavita wrote:
    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ę co raz mniej ofert pracy w tym kierunku i mam też wrażenie, C/C++ odchodzi w nie pamięć powoli, wszędzie tylko Java Java Java... ale to tylko takie moje spostrzeżenia, może się mylę.

    Mylisz się. "Embedded" to słowo, które kryje w sobie w rzeczywistości dwie dosyć odległe gałęzie. Jest "embedded-mikrokontrolery" i jest "embedded-mikroprocesory". To pierwsze to właśnie AVR, STM32, PIC itd, natomiast to drugie to platformy z Linuxem lub innym tego typu systemem operacyjnym (np. WindRiver czy coś tej klasy). Jedno i drugie jest "embedded", w końcu to słowo znaczy tyle co nic - że coś jest "wbudowane" w urządzenie. Bankomat na którym pewnie działa Windows 95 albo XP też jest "embedded". W "embedded-mikrokontrolery" języki niskopoziomowe - takie jak C i C++ - raczej nigdzie się nie wybierają, miały, mają i będą mieć dominującą pozycję. W "embedded-mikroprocesory" jest już tak jak na desktopie - zależnie od branży języki są różne, ale spokojnie można sobie używać czegoś wysokopoziomowego, choćby Java, Python, ...

    Tak BTW to w firmach które swoje stanowiska koniecznie muszą nazywać po angielsku zamiast po polsku masz wyjątkowo nikłą szansę na łączenie programowania z elektroniką. Firmy takie to w 99% najzwyklejsze korpo, w których jesteś tylko malutkim trybikiem odpowiedzialnym tylko za jedną rzecz, wiec albo za programowanie tego co zaprojektował ktoś inny, albo za projektowanie czegoś co zaprogramują inne osoby.
  • #10
    Anonymous
    Anonymous  
  • #11
    Freddie Chopin
    MCUs specialist
    nowyARM wrote:
    Zależy co rozumieć pod pojęciem "większy projekt". Robiłem różne rzeczy i nie miałem potrzeby korzystania z OS.

    Bezcelowy argument. W końcu system operacyjny definitywnie jest "większym projektem" a przecież nie korzysta z OSa. Technicznie rzecz ujmując nigdy nie ma potrzeby korzystania z OSa, w końcu tenże OS to po prostu zwyczajny kod który wcale nie robi niczego magicznego. Rowy przeciwczołgowe 80 lat temu kopali łopatami a nie koparkami, a tych rowów są setki kilometrów. Każdy program da się zrobić bez OSa oraz z OSem, w C, w C++, w Basicu czy w assemblerze - to tylko kwestia tego jak rozkłada się bilans zysków i strat, oraz czy ewentualne zyski (np. program bare-metal będzie mniejszy o 15% i będzie reagował o 5% szybciej niż program wielowątkowy) są warte ewentualnych strat (ilość miejsc z zależnościami czasowymi jest wielokrotnie większa, cięższa modyfikacja/rozbudowa w przyszłości, więcej kodu to więcej miejsca na błędy, dłuższy czas tworzenia aplikacji), oraz - przede wszystkim - czy mają sens (co z tego że program będzie 15% mniejszy skoro zajmuje 100-200 kB, a układ ma 512 kB pamięci, co z tego że reaguje o 5% szybciej, skoro założenia wymagają reakcji w ciągu 1 ms, a program tak czy siak reaguje w 1/10 tego czasu).
  • #12
    Anonymous
    Anonymous  
  • #13
    Anonymous
    Anonymous  
  • #14
    Anonymous
    Anonymous  
  • #15
    Anonymous
    Anonymous  
  • #16
    Freddie Chopin
    MCUs specialist
    nowyARM wrote:
    Tu akurat OS przegrał bo rozwiązanie bez niego było zdecydowanie tańsze (mniejsze CPU, mniej RAM, FLASH w wtedy były to drogie komponenty).

    Ile (dziesiąt) lat temu to było i jak bardzo jest to bez znaczenia w dzisiejszych czasach?

    nowyARM wrote:
    Gdy jednak, uC z np 128kB jest trzy razy tańszy od tego z 512 a kosztuje dwa razy taniej a uC jest najkosztowniejszym elementem a jest ich niewiele to te 10..15% może być istotne.
    Ważna jest też skala produkcji i koszty opracowania projektu. Jeśli opracowanie będzie zdecydowanie tańsze gdy zostanie użyty OS a skala produkcji jest niewielka to warto użyć OS.

    R-MIK - jest rok 2018, układy i pamięć są "tanie jak barszcz", świat idzie do przodu, do prostych sprzętów ładuje się procesory które są 5x droższe niż dowolny mikrokontroler. Ciężko mi wyobrazić sobie projekt, w którym mikrokontroler jest najdroższym elementem, bo jednak typowy projekt to jednak nie jest mikrokontroler + dioda LED. Na typowej płytce z jaką ja mam do czynienia jest ze 100 elementów pasywnych, minimum 5-10 jakichś układów interfejsowych, zwykle sporo gniazdek itd.

    nowyARM wrote:
    Inna sprawa, wymagania stawiane aplikacji. System "trochę" budzi sie do życia po resecie. W OrangePi jest to ok 40 sekund. Aplikacje bez Linuxa startują w ok sekundę (ETH, USB). Jeśli jest to istotne to OS przegra.

    Ja pisząc "OS" mam na myśli RTOS dla mikrokontrolera, a nie Linuxa. RTOS startuje tak samo szybko jak aplikacja bare-metal. Wyżej pisałeś o cenie układu ze 128 kB pamięci. Ile z nich ma też ETH i USB? Weźmy takie STM32F4 - filtrujesz po USB i ETH (obydwa na raz) -> najmniejszy dostępny ma 512 kB.

    Kiedyś nie używałem RTOSów i pewnie pisałbym tak samo jak Ty teraz. Niemniej jednak gdy pierwszy raz skorzystałem, to od tego czasu chyba tylko ze 2 czy 3 razy zdarzyło mi się zrobić projekt bez RTOSa. Po prostu nie ma sensu się męczyć bez niego jeśli nie istnieją jakieś bardzo istotne przesłanki przeciwko takiej decyzji, których nie da się obejść.
  • #17
    Anonymous
    Anonymous  
  • #18
    Anonymous
    Anonymous  
  • #19
    Anonymous
    Anonymous  
  • #20
    Anonymous
    Anonymous  
  • #21
    Anonymous
    Anonymous  
  • #22
    Anonymous
    Anonymous  
  • #23
    Anonymous
    Anonymous  
  • #24
    JacekCz
    Level 40  
    Freddie Chopin wrote:

    Mylisz się. "Embedded" to słowo, które kryje w sobie w rzeczywistości dwie dosyć odległe gałęzie. Jest "embedded-mikrokontrolery" i jest "embedded-mikroprocesory".


    Zdanie, które co jakiś czas tzreba powtarzać.
    Zupełnie inne dziedziny, tyle tylko że jest zielona płytka drukowana

    Freddie Chopin wrote:
    ... - to tylko kwestia tego jak rozkłada się bilans zysków i strat, oraz czy ewentualne zyski (np. program bare-metal będzie mniejszy o 15% i będzie reagował o 5% szybciej niż program wielowątkowy) są warte ewentualnych strat ...


    +1

    ellavita wrote:

    JacekCz wrote:
    Nie wiem jakiego języka używasz na Raspberry
    Python, ale z Maliną mam raczej małe doświadczenie, wiem że można ją też w C/C++ programować i w przyszłości w tym kierunku będę szedł.


    A mi sie wydaje, że tego wyboru MOŻE dokonać pracodawca/inwestor, i CAŁKIEM może preferować choćby mniejsza ilość linii/funkcjonaność, niezawodność itd... inaczej mówiąc nie zapłaci za 3x dłuższe timeline

    Pytanie założyłeś na gruncie rozwoju profesjonalnego a nie prywatno-hobbystycznego
  • #25
    Anonymous
    Anonymous  
  • #26
    Freddie Chopin
    MCUs specialist
    ellavita wrote:
    Mój błąd ale jak już wcześniej napisałem chciałem porzucic Arduino dla czegoś trudniejszego, jak na przykład STM32 a to juz mikroprocesory, popraw mnie jeśli się mylę.

    https://www.st.com/en/microcontrollers/stm32-32-bit-arm-cortex-mcus.html
    Quote:

    STM32 32-bit ARM Cortex MCUs

    The STM32 family of 32-bit Flash microcontrollers based on the Arm® Cortex®-M processor is designed to offer new degrees of freedom to MCU users. It offers products combining very high performance, real-time capabilities, digital signal processing, and low-power and low-voltage operation, and connectivity, while maintaining full integration and ease of development.
  • #27
    JacekCz
    Level 40  
    ellavita wrote:
    W każdzym bądź razie będe mieć otwarty umysł na inne języki programowania.


    https://www.youtube.com/watch?v=BhDRioyX68I

    Powtórzę myśl podobną jak pisałem. Po pół roku intensywnego używania (czyli nie hello world i nie 10 linii na kursie) rozumie się w stopniu użytecznym profesjonalnie "język nr 2" . Wtedy programista zaczyna oddawać wartość pracodawcy,

    W oryginalnej wypowiedzi użyłem słów "język nr 3", bo rzeczywiście mam takie przekonanie (a po roku "język nr 1")

    Nie zdążysz na rekrutację, chyba że pracodawca będzie zdeterminowany
  • #28
    Anonymous
    Anonymous  
  • #29
    Anonymous
    Anonymous  
  • #30
    tronics
    Level 38  
    Quote:
    Mikroprocesor (CPU) ma ALU, licznik rozkazów itd

    W "itd" obecnie kryje się kontroler pamięci, kontroler pcie, koprocesor arytmetyczny, blok szyfrujący (AES), blok dekodujący strumienie wideo. Różnica zaciera się coraz mocniej w miarę jak rdzenie stają się potężniejsze. Już od dłuższego czasu są wśród producentów mikrokontrolerów dostępne układy hybrydowe (tj. rdzenie Cortex A oraz Cortex M) lub też SoC oparte tylko o Cortex A. W tym momencie coraz mniejsze znaczenie mają stare regułki, bardziej adekwatne byłoby rozdzielenie w zależności od tego jaka jest rola oprogramowania w tych układach (tj. czy jest to bardziej firmware, czy bardziej embedded os, czy bardziej os).
    Na x86 były SoC z serii Vortex86, ale nie były to stricte mikrokontrolery, chociaż miały GPIO. Jest to tak teraz szeroki i głęboki temat, że nie ma sensu go rozwijać w tym temacie.