To jeden z największych dylematów osób wchodzących do branży embedded. Często zadają je również osoby, które już zaczęły pisać pierwsze programy i jakiś procesor wybrały. Nic dziwnego – możecie się zastanawiać czy to była dobra decyzja? czy mogę ją jeszcze zmienić? czy lepiej uczyć się od razu kilku rodzin?

W tym artykule dam Ci jasną odpowiedź. Oraz pokażę całą argumentację dlaczego właśnie tak. Zaznaczam tutaj od razu, że skupiam się na „deeply embedded”. Czyli ścieżce skupiającej się na systemach bare metal albo opartych na RTOSach. Linux Embedded to zupełnie inna bajka.

Krótka odpowiedź

Kiedyś odpowiadałem na to pytanie mniej więcej tak:

To nie ma znaczenia. Wybierz dowolną popularną rodzinę i zacznij się uczyć. Każda z nich jest ok. Możesz wybrać STM32, AVR, ESP32, PIC, LPC – to nie ma znaczenia. Najgorsze, co możesz zrobić, to tracić czas na decyzję zamiast przeznaczyć go na naukę.

Dzisiaj powiedziałbym:

Wybierz STM32. Kup płytkę Nucleo za 50-100 zł i zacznij działać.

Czy poprzednia porada jest już nieaktualna? Nie. Po prostu chcę jeszcze bardziej uprościć wybór i dać gotowe rozwiązanie. W ten sposób na pewno nie popełnisz błędu, a zaoszczędzony czas możesz przeznaczyć na praktykę.

Masz już odpowiedź, na tym możesz zakończyć lekturę 🙂 A jeżeli chcesz poznać również argumentację – zapraszam do dalszej części artykułu.

Jakie mamy cele?

Zastanawiając się nad wyborem procesora do nauki zwykle:

  • Znamy podstawy C.
  • Znamy podstawy elektroniki.
  • Wiemy, że chcemy się dalej uczyć.
  • Chcemy zostać zawodowymi programistami embedded.

Co musimy umieć, aby zdobyć pierwszą pracę w branży embedded? Moim zdaniem 5 najważniejszych umiejętności to:

  1. Programowanie w C.
  2. Znajomość jednej rodziny procesorów + peryferia, układy zewnętrzne itp.
  3. Podstawy elektroniki + obsługa aparatury pomiarowej.
  4. Podstawy Gita.
  5. Doświadczenie z realnym projektem (gdzie pokazujesz znajomość czterech pierwszych punktów).

Nie musisz być z każdego mega ekspertem, musisz znać na tyle żeby sobie radzić.

Oczywiście w ogłoszeniach o pracę znajdziesz najczęściej dużo bardziej wygórowane wymagania. To już temat na zupełnie inną dyskusję. W każdym razie, jak umiesz te 5 rzeczy – możesz składać CV i się nie przejmować. Wstydu nie będzie. Na rozmowie firma sprawdzi na ile się na tym znasz. A potem zadecyduje, czy chce Cię zatrudnić.

No ale wracając do głównego tematu. Wybór odpowiedniej rodziny procesorów pomoże nam spełnić punkt 2 powyższej listy. A pośrednio również punkty 1, 3 i 5.

Jakie dokładnie kompetencje chcemy opanować?

Po pierwsze chcemy nauczyć się obsługiwać popularne peryferia i inne elementy składowe procesora. To jest uniwersalna wiedza, którą później wykorzystamy ucząc się każdej kolejnej rodziny mikrokontrolerów. Chcemy więc nabrać biegłości w obsłudze portów wejścia/wyjścia, Timerów, ADC, UARTa, SPI, I2C, przerwań, czy DMA.

Chcemy również nauczyć się interakcji procesora z zewnętrznymi układami. Będziemy więc do niego podłączać LEDy, wyświetlacze, przyciski, silniki, czujniki, narzędzia do komunikacji, pamięci itp.

Chcemy poznać cały ekosystem otaczający mikrokontrolery – edytor kodu, narzędzia do kompilacji, debugowanie na sprzęcie, biblioteki peryferiów. Chcemy być w stanie szybko tworzyć prototypowe rozwiązania za pomocą wizardów generujących kod z konfiguracją poszczególnych peryferiów. Ale z drugiej strony chcemy też z grubsza wiedzieć co się dzieje i być w stanie naprawić ewentualne błędy.

Tutaj pojawia się kolejne typowe pytanie – Biblioteki HAL czy rejestry? Na początek naucz się HAL (Hardware Abstraction Layer). Dlaczego? Najpierw chcemy szeroko mieć pojęcie o różnych tematach związanych z embedded i nie chcemy poświęcać zbyt dużo czasu na same rejestry i wertowanie dokumentacji. Poza tym większość przykładowego kodu z nich korzysta. Na rejestry przyjdzie czas później.

Wybór pierwszej rodziny procesorów przez chwilę z nami zostanie. Będziemy na nich robić pierwsze przykłady kodu. Będziemy na nich szlifować umiejętności programowania z C, robić przykłady od producentów i pierwsze większe samodzielne projekty.

Chcemy więc, aby wybór mikrokontrolera jak najbardziej pomagał nam je zrealizować.

Jak nie wybierać mikrokontrolera do nauki?

Kiedy wejdziemy na strony producentów mikrokontrolerów, pierwsze co nam przychodzi do głowy to porównywanie parametrów. Jaka cena za pojedynczy procesor? Jaki rdzeń? Jakie taktowanie? Ile RAMu i FLASHa? Ile pinów? Jakie peryferia? Ile Timerów, ADC, UARTów? Jakie tryby low power? Jakie niestandardowe peryferia? I tak dalej.

W ten sposób możemy łatwo wpaść w pułapkę i porównywać nie to, co trzeba. Wszystkie wymienione wyżej parametry to dla nas sprawa drugorzędna. Owszem – podczas wyboru procka do komercyjnego projektu są kluczowe (dlatego producenci je eksponują), ale do nauki już nie.

Jakie kryteria brać pod uwagę przy wyborze mikrokontrolera do nauki?

Prawdziwe wymagania, na które powinniśmy zwrócić uwagę przy wyborze są zupełnie inne. Mogą wydawać się nieintuicyjne, ale jak się chwilę zastanowimy – staną się oczywiste.

Czy hardware jest tani i łatwo dostępny?

W dzisiejszych czasach do nauki potrzebujemy płytki ewaluacyjnej z wyprowadzonymi pinami. Samemu uczyłem się na Atmegach w obudowach przewlekanych i nie miałem płytki ewaluacyjnej. Ale przy dzisiejszych prockach odradzam takie podejście. Nie będziemy przecież samodzielnie lutować procka SMD. Do tego najlepiej jakieś LEDy, przyciski i koniecznie programator/debuger. Najlepiej wybierać proste płytki w przedziale 50-100 zł. Nie muszą zawierać żadnych bajerów. Wyświetlacze, silniki, klawiatury, czujniki itp. możemy sobie później dokupić i podłączyć do wyprowadzonych pinów.

Skoro będziemy się uczyć istnieje ryzyko, że spalimy płytkę. Lepiej spalić płytkę za 50 zł niż za 500 zł. Proste. A jak już spalimy płytkę, chcemy kupić nową w dowolnym sklepie z elektroniką z dostawą na następny dzień niż czekać tydzień na sprowadzenie.

Czy możemy szybko wystartować z nauką?

Potrzebujemy darmowych narzędzi – IDE, kompilatora, bibliotek, przykładów od producenta. Przykłady najczęściej są przygotowane pod popularne płytki. Dlatego możemy je od razu uruchomić bez żadnych modyfikacji. A potem robiąc własne bardziej skomplikowane projekty możemy łatwiej porównać nasze rozwiązanie z przykładem, albo projektem społeczności. To jedna z popularniejszych technik poszukiwania błędów.

Poza tym potrzebujemy dobrej dokumentacji, tutoriali, przykładów od producenta. Co z tego, że kupimy tanią chińską płytkę, jeżeli kompletnie nie będziemy umieli jej używać. A nawet jak uda się ją uruchomić, to czas stracony na błądzenie mogliśmy spożytkować dużo lepiej.

Jak duża jest społeczność użytkowników?

Napisaliśmy kod i nie działa. Co robimy? Najpierw szukamy błędu w naszym kodzie i sprawdzamy połączenia na płytce. Potem przeglądamy przykładowe projekty, pytamy wujka Google, przeglądamy fora, pytamy na grupach FB czy na Discordzie. Im większa społeczność tym większa szansa, że znajdziemy rozwiązanie problemu w internecie. Oczywiście pod warunkiem, że wiemy jak opisać nasz problem.

Bardzo często mamy również problemy z konfiguracją projektu, z narzędziami, z debugerem, IDE i szeroko rozumianą konfiguracją. Każdy ma z tym problemy na początku. Niezależnie od wybranego producenta procesorów. Im większa społeczność, tym łatwiej znaleźć rozwiązanie.

Później, kiedy zaczynamy pisać własne projekty szukamy gotowych bibliotek. Na popularne rodziny procesorów biblioteki zwykle mają gotowe porty razem z szerokim wyborem przykładów, a nawet projektów wykorzystujących bibliotekę w praktyce.

Duża społeczność użytkowników powoduje podczas nauki efekt kuli śnieżnej. Oszczędzamy czas na każdym kroku, bo ktoś ze społeczności zadbał już wcześniej o rozwiązania naszych problemów.

Podsumowanie

Nasze prawdziwe wymagania dotyczące rodziny procesora na start są związane z optymalizowaniem czasu nauki. STM32 spełnia je idealnie. Dlatego jest dobrym wyborem na start. AVR, PIC czy ESP32 pewnie też je spełniają i też będą dobre. Ale na dzień dzisiejszy polska społeczność STM32 jest największa. Kiedyś największa była społeczność AVR i wszyscy zaczynali od AVR. Aktualnie jest to STM32 i jeżeli je wybierzemy, na pewno nie popełnimy błędu.

Dlatego najłatwiej wystartować z STM32. Pisać projekty w C na bibliotekach HAL. Jako pierwszy edytor wybrać STM32 Cube. Robić przykłady. Najpierw proste na pojedynczych peryferiach. Potem je coraz bardziej rozbudowywać, eksperymentować, bawić się programowaniem. Realizować kilka zadań na raz, dodać przerwania, może RTOSa, może jakieś zewnętrzne biblioteki. Zrobić projekt i pochwalić się nim na GitHubie.

A co z Arduino, DSP, Linuxem Embedded, FPGA? Ze znajomością innych rodzin procesorów? Z programowaniem w Asemblerze, C++, Ruscie? Co z AUTOSARem i innymi frameworkami dedykowanymi pod poszczególne nisze? To wszystko jest ważne, to wszystko nam pomoże i na pewno warto uczyć się tych rzeczy. Ale wszystko w swoim czasie. Najpierw musimy wyrobić sobie fundamenty, a wtedy dalsza nauka idzie szybciej.

Jednym z takich fundamentów na pewno jest nauka mikrokontrolerów. Większość osób wiążących przyszłość z embedded o tym wie i solidnie się do niego przykłada. Drugim fundamentem jest język C. Tutaj mam wrażenie, że zwykle uczymy się podstaw. A potem wiedzę o języku uzupełniamy przy okazji robienia projektów.

Jakich języków się uczyć w embedded i w jakiej kolejności? To kolejne często zadawane pytanie na które odpowiem kolejnym razem.

Jak wejść do branży embedded w 2024 roku?

Na koniec jeszcze zapraszam na webinar „Jak wejść do branży embedded w 2024 roku”. Jeżeli zainteresował Cię ten wpis i wiążesz swoją przyszłość z branżą embedded – na pewno Ci się spodoba.

Zapisz się TUTAJ aby nie przegapić startu.