Embedded · IoT · firmware
AI dla programistów embedded i firmware, na Waszym sprzęcie.
Embedded to inna gra. AI też gramy tu inaczej. To nie TinyML ani sieć neuronowa na mikrokontrolerze, tylko agent (Claude Code), który pracuje z Waszym zespołem przy firmware: buduje, testuje i pilnuje konwencji. Nie obiecujemy, że AI napisze Wam firmware. Przyspieszamy pracę, która nigdy nie była „magicznym” kodem hardware'owym: testy, parsery protokołów, dokumentację rejestrów. Reszta to nadal Wy, datasheet i ławka testowa.
Dlaczego embedded to inna gra.
Większość narzędzi AI projektowano pod web i backend (repozytorium, internet pod ręką, szybki cykl build-run); w embedded żadne z tych założeń nie obowiązuje na ślepo.
- Toolchainy Keil, STM32CubeIDE, arm-none-eabi
- Kompilacja, flashowanie i debug przez sprzętowy programator. Pętla feedbacku liczona w minutach, nie w sekundach. AI nie „uruchomi” za Was kodu, dopóki nie zbudujecie szybszego cyklu (host-testy, mocki HAL).
- Hardware-in-the-loop ławka testowa, oscyloskop, analizator
- Część prawdy o systemie żyje wyłącznie na fizycznej ławce. Jedna ławka dzielona przez kilku inżynierów to realne wąskie gardło. Model językowy go nie usunie, ale potrafi przesunąć większość testów do symulacji.
- Brak lub ograniczony internet urządzenie i czasem proces dev
- Tam, gdzie kod nie może wyciekać poza sieć firmy, liczą się modele lokalne i workflow działający offline. AI musi zmieścić się w tych ramach, a nie odwrotnie.
- Bezpieczeństwo i safety certyfikacja, krytyczne ścieżki
- W kodzie, który steruje maszyną, nie ma „wygeneruj i zapomnij”. Każda linia przechodzi review, statyczną analizę i testy jak każda inna, niezależnie od tego, kto ją napisał.
Co AI realnie robi w embedded.
Zacznijmy od tego, czego AI nie robi. Nie generuje firmware'u od zera. Nie zastąpi inżyniera, który czyta datasheet, rozumie timing przerwań i wie, dlaczego ten konkretny rejestr trzeba zapisać dwa razy. Kod w ISR, dobór peryferiów, walka z erratą układu — to dalej praca człowieka przy sprzęcie.
To, co AI realnie przyspiesza, to cała warstwa dookoła tego twardego rdzenia. Testy unit na hoście z mockami HAL. Parsery protokołów: Modbus, CANopen, ramki CAN bus, telemetria OBD-II. Dokumentacja rejestrów i mapy pamięci. Kod CRUD-owy na strukturach konfiguracyjnych, serializacja, walidacja danych z magistrali. Skrypty symulujące master/slave, żeby nie blokować ławki na każdą zmianę.
W typowym projekcie embedded to właśnie ta warstwa pochłania około 70% czasu projektu, a nie kod w przerwaniach. Jeśli AI zdejmuje większość tej pracy, inżynier zostaje z czasem na to, co faktycznie wymaga jego głowy.
Jak to wyglądało na realnym module STM32.
Producent automatyki przemysłowej potrzebował nowego modułu komunikacji Modbus RTU + CANopen do sterownika STM32, który jest w produkcji od 2019 roku. Wycena wewnętrzna: 6–8 tygodni inżyniera plus 2 tygodnie testów HIL. Najpierw rozwiązaliśmy cykl iteracji (CI z arm-none-eabi, host-testy z mockami HAL, symulatory protokołów w Pythonie), a dopiero potem trzej inżynierowie klienta zamknęli moduł w dwa tygodnie. My prowadziliśmy, kod pisali oni.
Toolchain i obszary, w których siedzimy.
- C / C++ / STM32 bare-metal i RTOS
- C17 bliżej hardware'u, C++17 (bez wyjątków, bez RTTI) na warstwę protokołów. STM32 na ARM Cortex-M, HAL/LL, FreeRTOS bez migracji na siłę.
- Build i testy CMake, arm-none-eabi, Unity
- CMake + arm-none-eabi-gcc, ninja, statyczna analiza cppcheck i clang-tidy. Unity + CMock do mockowania HAL, własne fixtury HIL w Pythonie.
- Protokoły komunikacja przemysłowa
- Modbus RTU (UART z DMA), CANopen (NMT/PDO/SDO), CAN bus, OBD-II, RS232/485. Parsery i symulatory master/slave do testów bez sprzętu.
- Qt / QML i ARM Linux HMI i edge
- Panele HMI w Qt 6 / QML z backendem C++, daemony systemd i telemetria na ARM Linux tam, gdzie projekt wychodzi poza mikrokontroler. Szerzej: modernizacja systemów przemysłowych.
- Regulacje CRA
- Od 11 września 2026 producenci muszą zgłaszać aktywnie wykorzystywane podatności w swoich urządzeniach: terminy CRA dla producentów embedded.
- AI workflow dopasowany do bare-metal
- Reguły w CLAUDE.md pisane pod sprzęt: nigdy kod HAL bez referencji do datasheet, PR z memory map diff, oznaczone funkcje ISR, lista funkcji thread-safe.
AI, które pilnuje MISRA C — nie omija jej.
Dla przemysłu, energetyki, kolei i systemów sygnalizacji zgodność z MISRA C to nie formalność, tylko warunek wejścia. Zbudowaliśmy workflow, w którym agent sprawdza kod, wygenerowany i ludzki, pod kątem reguł MISRA jeszcze przed review. To zamienia AI z ryzyka certyfikacyjnego w dodatkową linię obrony.
Ten workflow, razem z regułami CLAUDE.md pod STM32/Zephyr/Qt i serwerem MCP do datasheetów, przekazujemy zespołom na jednodniowym warsztacie, na Waszym sprzęcie, bez dotykania Waszego repo. Wycenę warsztatu podajemy po demo, mailem w 48 h, razem z wyliczeniem dofinansowania z KFS.
Zobacz przykład: nasz open-source'owy skill STM32 dla Claude Code, kompletny workflow build/flash/debug, który skonfigurujecie pod własną płytkę i pobierzecie.
30 minut live demo. Bez NDA.
Agent na żywo, na kodzie open-source z Waszej domeny: Modbus, CANopen, SCPI, OCPP, co u Was gra. Zobaczycie, co AI przyspiesza w bare-metal, a czego nie tknie. Termin pod Was.