Embedded · IoT · firmware

Embedded to inna gra. AI też gramy tu inaczej.

Nie obiecujemy, że AI napisze Wam firmware. Obiecujemy, że zdejmie z Was 70% pracy, 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.

01 / Kontekst · Ograniczenia, nie życzenia

Dlaczego embedded to inna gra.

Tomek przy stanowisku elektronicznym z płytką STM32 i oscyloskopem, obok laptop z terminalem AI

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.

ToolchainyKeil, 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 interneturzą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 safetycertyfikacja, 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ł.

02 / Realizm · Co AI faktycznie zmienia

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.

03 / Dowód · Sterownik STM32 w produkcji

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.

2 mc → 2 tygczas dostarczenia modułu (3–4× szybciej)

30 → 4 minpętla feedback na CI host (20 → 12 min na HIL)

3 z 3 inż.używa AI workflow w dzień 14 — sprawdzone w commitach

Zobacz cały case

04 / Stack · Z czym pracujemy

Toolchain i obszary, w których siedzimy.

C / C++ / STM32bare-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 testyCMake, 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łykomunikacja 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 LinuxHMI i edge: Panele HMI w Qt 6 / QML z backendem C++, daemony systemd i telemetria na ARM Linux tam, gdzie projekt wychodzi poza mikrokontroler.
AI workflowdopasowany 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.

05 / Safety · MISRA i zgodność

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. Dla zatwierdzającego budżet: 7 500 zł netto za grupę do 10 osób, z dofinansowaniem KFS/BUR dla MŚP realnie od ~1 500 zł.

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.

Warsztat: Claude Code dla embedded/C++

Chcecie to zobaczyć na kodzie ze swojej branży?

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.

Umów live demo +48 505 091 200