Case studies › Sterownik STM32 · Embedded · Hardware / IoT · 2026

Dwa miesiące pracy. Dwa tygodnie do odbioru.

Producent urządzeń automatyki przemysłowej potrzebował nowego modułu komunikacji do istniejącego sterownika STM32. Wcześniej takie projekty zajmowały w ich zespole około dwóch miesięcy — łącznie z testami i odbiorem. Tym razem trzej inżynierowie klienta zamknęli moduł w dwa tygodnie, z testami HIL. My prowadziliśmy, kod pisali oni i dalszy rozwój też wzięli na siebie. Skala pilota: tak wygląda pierwszy kwartał przy zespole 3–4 osób. Przy 30+ pracujemy falami, zespół po zespole.

2 mc → 2 tygczas dostarczenia

3 inż. z AIzespół po wdrożeniu

unit + HILpokrycie testami

01 / Kontekst klienta

Sterownik w produkcji od 2019. Nowy moduł komunikacji na termin.

Polski producent automatyki przemysłowej projektujący sterowniki dla maszyn pakujących i linii produkcyjnych. Trzon zespołu R&D to trzech inżynierów embedded — dwóch seniorów z ponad 15-letnim stażem w C/C++ na ARM-y, jeden mid z 4 latami. Sam sterownik jest w produkcji od 2019 roku — sprawdzony, certyfikowany, w setkach instalacji.

Wymaganie od klienta końcowego (producent linii butelkowania): moduł komunikacji Modbus RTU + CANopen z mostkiem do nowszego protokołu OPC UA, kompatybilny z istniejącym sterownikiem, bez zmiany pinout-u. Termin: 8 tygodni. Wycena wewnętrzna w firmie: 6–8 tygodni inżyniera plus 2 tygodnie testów HIL.

02 / Kto to prowadził

Dwie osoby, dwa tygodnie, jeden odbiór.

Tomek WojciechowskiLead operacyjny: Bare-metal C/C++17 od 18 lat, embedded STM32 / AVR od pierwszej połowy lat 2000. Setup CI dla firmware-u, pisanie CLAUDE.md dla bare-metal (180 linii reguł — zakazy w ISR, lista funkcji thread-safe, konwencje memory-mapped IO).
Maciej StopaCI / DevOps dla firmware: GitHub Actions z arm-none-eabi, symulatory Modbus RTU i CANopen w Pythonie, integracja host-tests. Wcześniej prowadził pipeline-y dla embedded w jednym z fintech-ów.

03 / Problem · Co naprawdę bolało

Problem nie był techniczny — był pojemnościowy.

Zespół znał stos. Znał sterownik. Znał protokoły. Problem nie był techniczny — problem był pojemnościowy.

Zbyt długi cykl iteracji. Każda zmiana w firmware = kompilacja + flashowanie + ręczne testy na ławce. Brak setupu CI dla firmware-u. Pętla feedbacku trwała 20–40 minut.
Wąskie gardło testów HIL. Jedna ławka testowa, dzielona przez trzech inżynierów.
Wiedza w głowach. Senior, który najlepiej znał warstwę CAN, miał urlop ojcowski w środku zaplanowanych 8 tygodni. Bez niego zespół ledwie szedł.
Obawa przed AI w firmware. Inżynierowie domyślnie zakładali, że „LLM-y nie nadają się do bare-metal". Część prawda, część stereotyp.

04 / Podejście SZRON

Najpierw cykl iteracji, dopiero potem kod modułu.

Diagnoza pokazała, że projekt da się zrobić w 2 tygodnie pod warunkiem, że zespół najpierw rozwiąże problem cyklu iteracji, a dopiero potem siądzie do kodu modułu. Większość zespołów próbuje od razu pisać feature — i traci tygodnie na test/build/flash.

Tydzień 0 — CI dla firmware-u. GitHub Actions z arm-none-eabi, automatyczne testy unit na PC (host) z mockami HAL, statyczna analiza. Pierwsza pętla feedbacku z 30 minut na 4 minuty.
Symulacja zamiast ławki. Skrypty Pythonowe symulujące Modbus RTU master i CANopen NMT — większość ścieżek można sprawdzić bez fizycznego sprzętu.
AI workflow dopasowany do embedded. CLAUDE.md z konkretnymi wytycznymi: nigdy nie generować kodu HAL bez referencji do datasheet, pull request musi zawierać memory map diff, każda funkcja przerwania ISR musi być oznaczona.
Parowanie z każdym inżynierem. Pierwsze 3 dni: po pół dnia z każdym z trzech inżynierów na ich własnych modułach.

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.

Dlaczego to się udało — wniosek SZRON

05 / Przebieg projektu · 2 tygodnie do odbioru

Od CI po HIL — dwa tygodnie do podpisu.

Tydzień 1

CI + symulatory + Modbus

GitHub Actions, host testy z mockami, kompletny stos Modbus RTU slave napisany pod testami unit. Pierwsza wersja na sprzęcie pod koniec tygodnia.

Tydzień 2

CANopen + integracja + HIL

Warstwa CANopen z obsługą NMT, PDO i SDO. Integracja z istniejącym kodem sterownika. Pełen cykl testów HIL przeprowadzony przez senior + middle. Odbiór wewnętrzny w piątek.

Tydzień 3 · poza zakresem

Wydanie u klienta końcowego

Producent linii butelkowania podpisał odbiór. Zespół kontynuował rozbudowę o OPC UA samodzielnie — z AI workflow już zaadoptowanym do ich procesu.

06 / Wynik · Mierzony w iteracjach

Mierzony w iteracjach, nie w deklaracjach.

3–4× szybciej2 tygodnie zamiast 6–8 tygodni inżyniera

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

3 z 3 inżynierówużywa Claude Code w dzień 14 — sprawdzone w commitach

Czas dostarczenia2 tygodnie zamiast 6–8: Moduł zamknięty w dwa tygodnie zamiast 6–8 tygodni inżyniera (3–4× szybciej).
Czas pętli feedbackCI host i HIL: 30 min → 4 min na CI host. 20 min → 12 min na HIL.
Pokrycie testamiprotokoły: Warstwy protokołów 92% unit + 100% scenariuszy HIL. Wcześniej w tym repo testy istniały głównie „smoke".
Adopcja AI w zespolemierzona w commitach: 3 z 3 inżynierów używa Claude Code w dzień 14. Nie sprawdzaliśmy „zadowolenia", sprawdzaliśmy commity — wszyscy trzej pushowali z AI workflow w drugim tygodniu.

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) · współpraca z Tomkiem Wojciechowskim i Maciejem Stopą

07 / Stack technologiczny

Bare-metal C/C++17 i FreeRTOS — bez migracji na siłę.

MikrokontrolerSTM32F4: ARM Cortex-M4 168 MHz, 1 MB Flash, 192 kB RAM.
JęzykC17 / C++17: C17 dla warstw bliżej hardware'u, C++17 (bez wyjątków, bez RTTI) dla warstwy protokołów.
RTOSFreeRTOS 10.5: Zachowany ze starego projektu, bez migracji.
ProtokołyModbus RTU + CANopen: Modbus RTU slave (UART z DMA), CANopen (FlexCAN + NMT/PDO/SDO).
BuildCMake + arm-none-eabi: CMake + arm-none-eabi-gcc, ninja, statyczna analiza cppcheck + clang-tidy.
TestyUnity + CMock: Unity (host + target), CMock dla mockowania HAL, własne fixtury HIL w Pythonie.
AI workflowClaude Code: Claude Code z CLAUDE.md (180 linii — głównie reguły dla kodu bare-metal).

08 / Co zostało po nas

Działający moduł, żywe CI i zespół, który przekonał się sam.

Działający moduł komunikacji

Podpisany odbiór klienta końcowego po 3 tygodniach od startu projektu.

Działające CI dla firmware-u

Pipeline, który zespół rozszerza na kolejne moduły.

CLAUDE.md dopasowany do embedded

Żywy dokument, do którego zespół dopisuje kolejne reguły.

Zespół, który przekonał się sam

Najmocniejszy efekt: dwóch seniorów, którzy szli w projekt z założeniem „to nie dla nas", po dwóch tygodniach prowadzi AI workflow dla młodszego kolegi.

Następny case →

Panel sterowania Qt/QML w energetyce

Wszystkie case studies

Trzy piloty w trzech branżach

Wasze firmware'y leżą tygodniami?

Embedded też się da. Tylko inaczej.

30-minutowa rozmowa — pokażemy, gdzie konkretnie zespół embedded traci tempo i co AI naprawdę przyspiesza w bare-metal (a co nie).

Umów diagnozę Inne realizacje