01 / Kontekst · Ograniczenia, nie życzenia

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. Zanim zaczniemy mówić, „co AI robi", trzeba uczciwie nazwać, w czym pracujemy.

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ę.

I tu pada liczba, która zmienia rachunek opłacalności: w typowym projekcie embedded to właśnie ta warstwa pochłania około 70% czasu projektu — 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.

Najkrócej: AI w embedded to nie generowanie firmware'u od zera — to przyspieszenie wszystkiego, co nie jest „magicznym” kodem hardware'owym: testy, parsery protokołów, dokumentacja rejestrów, kod CRUD-owy na strukturach. Tam jest 70% czasu projektu, nie w ISR-ach.

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. Problem nie był techniczny — zespół znał stos i protokoły. Problem był pojemnościowy: cykl build/flash/test trwał 20–40 minut, jedna ławka HIL na trzech ludzi, a senior od warstwy CAN szedł na urlop w środku terminu.

Najpierw rozwiązaliśmy cykl iteracji — CI z arm-none-eabi, host-testy z mockami HAL, symulatory Modbus i CANopen w Pythonie. Dopiero potem zespół siadł do kodu modułu. Trzej inżynierowie klienta zamknęli go w dwa tygodnie, z testami HIL. My prowadziliśmy, kod pisali oni.

Myślałem, że AI to nie dla nas — siedzimy bliżej krzemu niż chmury. Po dwóch tygodniach mam jednoznaczne zdanie: nie generuje za nas firmware'u, ale ratuje cały kontekst dookoła. Testy, dokumentacja rejestrów, sklejanie parserów. Tam, gdzie zwykle ginęliśmy.

Inżynier R&D embedded — producent automatyki przemysłowej (NDA)

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.

Zobacz przykład: nasz open-source'owy skill STM32 dla Claude Code — kompletny workflow build/flash/debug, który możesz skonfigurować pod własną płytkę i pobrać.

Warsztat: Claude Code dla embedded/C++

Chcesz 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. Zobaczysz, co AI naprawdę przyspiesza w bare-metal, a czego nie tknie. Termin pod Was.

Umów live demo +48 505 091 200