Jak wygląda codzienna praca embedded developera? Co musi on mieć na swoim biurku? I jak zacząć pracę na tym stanowisku? Między innymi o tym rozmawiamy z Maciejem Fabią, Inżynierem systemu wbudowanego i Liderem Technicznym w ASSA ABLOY.
Cześć! Opowiedz, proszę, jak wyglądała Twoja ścieżka kariery jako embedded developera? Co skłoniło Cię do wyboru tej specjalizacji?
Cześć! Z elementami branży embedded pierwszy raz spotkałem się w trakcie studiów na kierunku Automatyka i Robotyka na AGH w Krakowie. Na zajęciach z elektroniki zdarzało się, iż oprócz prostych elementów cyfrowych, takich jak bramki, przerzutniki, pojawiał się prosty mikrokontroler 8051 Intela. Mogłem wtedy przyjrzeć się temu, czego nie widać przy pisaniu programów uruchamianych na zwykłym komputerze – to np. sprawdzanie stanu nóżek mikrokontrolera, w jaki sposób działają przerwania i wiele innych. Programy były tak proste, iż zapisywaliśmy je nie w języku C, a w asemblerze, mającym bezpośrednie przełożenie na kod maszynowy mikrokontrolera. Nie był to efektywny sposób pisania kodu, ale odsłaniał, jak wygląda program w postaci zrozumiałej dla maszyny.
W trakcie późniejszych lat studiów miałem choćby okazję napisać symulator wybranego przez siebie mikrokontrolera — wybór padł na układ z popularnej rodziny AVR ATmega. Spowodowało to, iż coraz pewniej czułem się w dziedzinie embedded i traktowałem ją jako priorytet przy poszukiwaniu pierwszej pracy.
Mój wybór padł na firmę z branży HVAC. W niej mogłem wreszcie przyczynić się do utworzenia produktów elektroniki użytkowej, trafiających do domu klienta. Objąłem pozycję juniora, regulara, i ostatecznie team leadera. Pod kątem technicznym zajmowałem się m.in. utworzeniem gałęzi produktów low-power zasilanych bateryjnie, oraz komunikacją bezprzewodową.
W związku ze stale rosnącym zapotrzebowaniem na rozwiązania bezprzewodowe, szczególnie IoT (Internet of Things), postanowiłem skupić się na tych obszarach. Przeszedłem na pozycję Senior Firmware Engineera u producenta mikrokontrolerów ARM ze zintegrowanym modułem radiowym 2.4 GHz. Rozwijałem publiczne SDK, umożliwiające komunikację bezprzewodową m.in. dzięki protokołów Bluetooth i Zigbee.
Następnym, i jak na razie ostatnim krokiem w mojej karierze była pozycja Firmware Engineera, zmieniona ostatnio na Tech Leada, w firmie dostarczającej produkty IoT w branży access control.
Co Ci się najbardziej podoba w Twojej obecnej pracy? Czy są jakieś specyficzne jej aspekty, które sprawiają, iż jest dla Ciebie satysfakcjonująca?
O ile programy i strony internetowe przeznaczone dla klasycznych komputerów mogą się wydawać nieco abstrakcyjne, to w branży embedded produkt jest bardziej namacalny, np. smart watch, termostat pokojowy. Bardzo satysfakcjonujący jest też moment, gdy pierwsze egzemplarze produktu trafiają do klientów.
A jak przygotowywałeś się do pierwszej pracy w embedded? Czego się uczyłeś?
W ramach przygotowania do interview zrobiłem sobie powtórkę z języka C/C++ oraz podstaw elektroniki. Gdy zostałem już przyjęty, sporo zaglądałem do dokumentacji bibliotek i narzędzi — pozwoliło mi to poznać wiele zagadnień i problemów, nie ograniczając się tylko do tych, które wystąpiły u mnie na biurku.
Czy istnieje w ogóle możliwość nauki w domu, biorąc pod uwagę, iż embedded może wymagać dostępu do różnych sprzętów?
Jak najbardziej, większość producentów mikrokontrolerów oferuje zestawy uruchomieniowe (development kits), pozwalające pisać i testować kod na wybranym układzie scalonym. Dzięki temu omija nas cały proces projektowania płytki PCB, która zawierałaby dany układ wraz z całą niezbędną elektroniką. Ceny zestawów najczęściej nie przekraczają 100-200 zł.
Do połączeń między płytkami wystarczą standardowe przewody połączeniowe, a do szybkiego połączenia kilku dodatkowych elementów elektronicznych można użyć płytki stykowej. Tak więc możliwa jest nauka w domu również wtedy, gdy nie posiadamy lutownicy.
Jakie umiejętności teoretyczne i praktyczne są najważniejsze dla osoby, która chce rozpocząć karierę jako embedded developer? Czy istnieją konkretne technologie, których warto się nauczyć?
Najważniejsza jest znajomość odpowiedniego języka programowania. W zdecydowanej większości projektów jest to język C, rzadziej C++. Możliwe są też inne, np. wspomniany asembler, a choćby Python czy Java, ale warto się skupić na C, szczególnie na początku.
W systemach embedded, zamiast klasycznych systemów operacyjnych znanych nam z komputerów osobistych, mają zastosowanie systemy operacyjne czasu rzeczywistego — RTOS’y. Warto poznać bliżej któryś z nich, ja poleciłbym FreeRTOS ze względu na dużą popularność oraz przystępną dokumentację.
Oprócz mikrokontrolera, do którego wgramy nasz program, na płytce PCB znajdują się różne elementy elektroniczne, dlatego przyda się znajomość podstaw elektroniki. Mikrokontroler bardzo często połączony jest z innymi chipami dzięki standardowych interfejsów komunikacyjnych, np. UART, SPI, z pewnością warto zrozumieć, w jaki sposób działa każdy z nich.
Kiedy rozpoczynamy pracę z nową płytką, na pewno otrzymamy też jej schemat, przedstawiający wszystkie znajdujące się na niej elementy i połączenie między nimi. Z niego dowiemy się, z czym łączy się poszczególne piny mikrokontrolera — a może ich być choćby powyżej 100! Kolejną umiejętnością, na szczęście raczej łatwą do opanowania, jest więc czytanie schematów układów.
Na koniec wymienię obsługę multimetru, żeby być w stanie zmierzyć napięcia, opory na naszej płytce.
Czym różni się praca embedded developera od pracy „zwykłego” deva?
Każdy developer, w sytuacji, gdy coś nie działa, bierze pod uwagę, iż w programie jest błąd. Embedded developer często spotka się z inną, bardziej prozaiczną przyczyną takiego stanu rzeczy — zwarciem między ścieżkami, źle przylutowanym pinem i wieloma podobnymi. Takie sytuacje zdarzają się najczęściej, gdy pracujemy z wczesnym prototypem, dużo rzadziej, gdy jest to już dojrzały produkt.
Poza tym mikrokontrolery, w porównaniu do komputerów, charakteryzują się mocno ograniczonymi zasobami. Ich częstotliwość pracy i wielkość pamięci są wielokrotnie mniejsze. Czasem zdarza się, iż po dodaniu nowych funkcjonalności zabraknie pamięci. Wtedy konieczna jest zmiana rozwiązania na takie, które zużywa mniej zasobów, albo optymalizację programu.
Krótko mówiąc, embedded developer musi sobie radzić z oprogramowaniem, jak i sprzętem, w środowisku o ograniczonych zasobach.
A czym się wyróżnia testowanie w embedded?
Testy automatyczne wymagają zestawienia setupu testowego, czyli naszego produktu połączonego z komputerem wykonującym testy. Przed adekwatnymi testami, pamięć mikrokontrolera jest czyszczona, następnie jest do niej wgrywany testowany software. Wykonywanie testu, a potem weryfikacja jego rezultatów, również wymagają komunikacji z urządzeniem — na szczęście można ją zrealizować na wiele sposobów, np. przez port szeregowy lub bezprzewodowo.
Znacznie większym wyzwaniem jest odtworzenie w środowisku testowym tego, co zwykle robi klient — np. zbliżenie karty dostępu do urządzenia.
Choć może to być zaskakujące, możliwe są też testy automatyczne z pominięciem produktu — są uruchamiane w symulatorze, który ma za zadanie możliwie jak najdokładniej zasymulować docelowe urządzenie. Takie rozwiązanie nie powinno jednak pociągać za sobą rezygnacji z testów z użyciem rzeczywistego produktu.
Stosunkowo najmniej różnią się testy manualne, oczywiście również one są przeprowadzane na produkcie.
Jakie są najczęstsze wyzwania, z jakimi się spotykasz w pracy, i jak je przezwyciężasz?
W embedded można spotkać się z różnorodnymi wyzwaniami, w dużym stopniu zależnymi od projektu. Czasami może to być identyfikacja bugów na pograniczu software’u i sprzętu, wymagająca nie tylko debugowania, ale sprawdzenia, czy mikrokontroler zrealizował swoje zadanie, np. używając analizatora logicznego. Innym razem — optymalizacja kodu, aby uzyskać więcej wolnej pamięci.
Z drugiej strony, wiele wyzwań jest analogicznych jak w innych branżach — konieczność szybkiego wdrożenia się po dołączeniu do projektu, gwałtownie zbliżające się deadline’y itp.
Podobno biurko embedded developera wygląda bardzo ciekawie Jakie sprzęty i narzędzia są Ci niezbędne do efektywnej pracy?
Oczywiście mam na biurku produkt, na którym w tej chwili pracuję. Nie ma założonej obudowy, tak abym miał dostęp do jego płytek PCB i znajdujących się na nich łączek. Po dokonaniu zmian w programie jego nową wersję wgrywam do mikrokontrolera na płytce dzięki programatora.
Obok stoi zasilacz laboratoryjny, służący do zasilania produktu, i dalej urządzenie do pomiaru zużycia prądu — niezastąpione w pracy z gadżetami zasilanymi bateryjnie.
Urządzeniem pomiarowym o szerokich możliwościach jest oscyloskop, wizualizujący przebiegi napięciowe — wystarczy przyłożyć końcówkę jego sondy do interesującego miejsca na płytce PCB. Nieco podobnym urządzeniem jest analizator stanów logicznych, pomagający podejrzeć dane, które wysyła lub odbiera mikrokontroler.
Zawsze mam też sporo przewodów, kabli i łączek, jakieś elementy elektroniczne i wspomniane wcześniej development kity. Niekiedy gdzieś w okolicy biurka stoi choćby drukarka 3D.
Jednak jeżeli potrzebuję skorzystać z lutownicy, muszę się udać do firmowego laboratorium.
Na zakończenie, co poradziłbyś osobom, które planują rozpocząć karierę jako embedded developer? Jakie miałbyś wskazówki dla tych, którzy dopiero zaczynają się interesować tą dziedziną?
Warto poświęcić czas na własne, choćby niezbyt skomplikowane projekty, eksperymentować z zestawami uruchomieniowymi, tak żeby równolegle nabywać umiejętności praktyczne, ale również poszerzać swoją wiedzę o danym mikrokontrolerze i jego układach peryferyjnych. jeżeli ktoś dopiero zaczyna przygodę z embedded, powinien rozważyć kursy on-line wprowadzające do embedded, żeby łagodnie wejść w temat, a jednocześnie zrozumieć podstawy.
Można też od czasu do czasu przejrzeć kod źródłowy jakiegoś dostępnego w internecie projektu embedded i w ten sposób uczyć się od doświadczonych developerów. Pozwoli to nie tylko poszerzać wiedzę techniczną, ale też nabrać dobrych nawyków w pisaniu czytelnego kodu.
Maciej Fabia. Inżynier systemu wbudowanego/Lider Techniczny w ASSA ABLOY. Od 13 lat pracuje w branży embedded. Fan rozwiązań low-power i komunikacji bezprzewodowej.
Zdjęcie główne pochodzi z Unsplash.com.
