Immer wieder wer­den wir gefragt, was wir eigentlich bei Logi­ma so machen. “Gerätezen­tri­erte Soft­ware” ste­ht auf unser­er Web­seite — aber was steckt konkret dahin­ter?

Dieser Beitrag gibt einen Ein­blick in ein Gebi­et, das bei uns in den let­zten Jahren immer mehr an Bedeu­tung gewon­nen hat: die pro­fes­sionelle Firmwa­reen­twick­lung für STM32-Mikro­con­troller.

Hier eine beschrei­bung eines unser­er let­zten Pro­jek­te.

Die Aufgabe: Firmware für ein Medizinprodukt

Firmware zu schreiben, die auf einem Micro­con­troller läuft, ist eine tolle Sache. Firmware zu entwick­eln, die zuver­läs­sig in einem anspruchsvollen Umfeld – mit Mul­ti­thread-Betrieb, Echtzeitmes­sun­gen, mehreren Kom­mu­nika­tion­spro­tokollen und hohen Qual­ität­san­forderun­gen – ihren Dienst tut, ist eine ganz andere, aber dafür umso span­nen­dere Her­aus­forderung.

Es muss auch nicht jede Soft­ware zer­ti­fiziert sein. Firmware, die in einem Medi­z­in­pro­dukt steckt, schon. Und auch das bieten wir an. Das bedeutet: Doku­men­tierte Architek­turentschei­dun­gen, nachvol­lziehbare Testver­fahren (inklu­sive Unit-Test), sta­tis­che Code­analyse — und das alles auf einem Mikro­con­troller mit 512 KB Flash und 128 KB RAM. Damit kann das Pro­dukt am Ende nach der Med­ical Device Reg­u­la­tion (MDR) zuge­lassen wer­den.

Das klingt vielle­icht wieder­sprüch­lich, aber es ist eine Her­aus­forderung die wir gerne ange­hen.

Die Plattform: STM32 mit ARM Cortex-M4

Wir entwick­eln für den STM32G4 — einen leis­tungsstarken ARM Cor­tex-M4 mit 170 MHz, Hard­ware­fließkom­maein­heit (FPU) und erweit­erten Periph­eriemöglichkeit­en. Mit der STM32CubeIDE und dem ARM GCC Tool­chain entste­ht aus unserem C++-Quellcode eine fer­tige Binär­datei für den Micro­con­troller.

Gle­ichzeit­ig nutzen wir Visu­al Stu­dio für die Entwick­lung — zum einen für die Unit-Test und automa­tisierten Sys­temtests und zum anderen wegen der besseren Erfahrung und Unter­stützung beim Schreiben des Codes (Intel­lisense und Co.).

Echtzeitbetrieb mit FreeRTOS

Embed­ded-Sys­teme sind sel­ten ein­fach. Sig­nale müssen gemessen, Pro­tokolle beant­wortet und Para­me­ter überwacht wer­den — gle­ichzeit­ig. Dafür nutzen wir FreeR­TOS über die CMSIS-RTOS V2-Schnittstelle.

Threads, Mutexe, Queues, Sem­a­phoren und Stream­Buffer — das sind die Werkzeuge, mit denen wir die Neben­läu­figkeit hand­haben. Wir haben dabei klare Regeln: In Inter­rupts steckt nur min­i­male Logik. Die eigentliche Arbeit übernehmen Task-Queues. Crit­i­cal Sec­tions sind die Aus­nahme, nicht die Regel.

C++20 — mit Augenmaß

Wir schreiben die Firmware in C++20, da uns das echte Vorteile bringt: Les­barkeit, Wiederver­wen­dung, Test­barkeit.

Gle­ichzeit­ig gel­ten klare Gren­zen: Keine Excep­tions (zu viel Over­head), kein unkon­trol­liertes STL (dynamis­che Alloka­tion). Dynamis­che Spe­icherver­wal­tung find­et auss­chließlich in der Ini­tial­isierungsphase statt — danach nicht mehr.

Wir ori­en­tieren uns kon­se­quent an den C++ Core Guide­lines und nutzen die Guide­lines Sup­port Library (GSL) für mehr Typ- und Spe­ich­er­sicher­heit.

Gle­ichzeit­ig nutzen wir C17 für für den HAL-nahen Plat­tform­code. Das ist eine bewusste, architek­tonisch begrün­dete Entschei­dung: Dort, wo C++ keine Vorteile bringt, bleibt es bei C. Und dort, wo mod­ernes C++ hil­ft — bei Typ­sicher­heit, Abstrak­tion oder Kapselung — nutzen wir es kon­se­quent.

Kommunikation: Mehrere Protokolle, eine Firmware

In unserem Pro­jek­tein­satz imple­men­tierten wir mehrere serielle Kom­mu­nika­tion­spro­tokolle — ein Lega­cy-ASCII-Pro­tokoll für Abwärt­skom­pat­i­bil­ität, ein mod­ernes binäres Pro­tokoll und einen Impulsmodus für Direk­tmes­sung. Die Firmware erken­nt und bedi­ent alle drei.

Solche Mehrfach-Pro­tokol­lun­ter­stützung ist typ­isch für Mess­geräte, die in beste­hende Sys­tem­land­schaften inte­gri­ert wer­den müssen. Wir haben gel­ernt, wie man das sauber mod­u­lar auf­baut — ohne dass es zur Spaghet­ti-Architek­tur wird.

Qualität, die dokumentiert ist

Firmware für reg­ulierte Märk­te braucht Nach­weise. Wir liefern sie:

• Unit-Tests mit GoogleTest, die direkt in Visu­al Stu­dio laufen
• Inte­gra­tionstests, die mehrere Schicht­en durch­stechen
• Sys­temtests auf echter Hard­ware — hochau­toma­tisiert, direkt aus der Kom­man­dozeile aus­führbar
• Sta­tis­che Code­analyse mit den Microsoft Native Code Ana­lyz­ers, einge­bun­den in den Build-Prozess
• Doxy­gen-Doku­men­ta­tion für alle rel­e­van­ten Schnittstellen
• Build-Serv­er die automa­tisiert den Code com­pilieren und die Tests aus­führen, um sicherzustellen, dass Änderun­gen auch auf anderen Sys­te­men nachvol­lziehbar funk­tion­ieren.

Jede Entschei­dung, die die Architek­tur bee­in­flusst, wird als Archi­tec­ture Deci­sion Record (ADR) fest­ge­hal­ten. So weiß jed­er im Team — und auch zukün­ftige Entwick­ler — warum etwas so ist, wie es ist.

Was uns dabei wichtig ist

Embed­ded-Entwick­lung ist im Kern nichts anderes als Soft­wa­reen­twick­lung — mit densel­ben Anforderun­gen an Wart­barkeit, Tests und Qual­ität, nur unter deut­lich engeren Rah­menbe­din­gun­gen.

Unser Ansatz: solides Soft­ware-Handw­erk in die Embed­ded-Welt zu brin­gen. Mit klar­er Struk­tur, prag­ma­tis­ch­er Diszi­plin und dem Anspruch, Code zu hin­ter­lassen, den wir auch in mehreren Jahren noch ver­ste­hen.

Übri­gens set­zen wir auch in anderen Soft­ware­pro­jek­ten mit kleineren Con­trollern Qual­itäts­stan­dards um, beispiel­sweise mith­il­fe von Unit-Tests, auch wenn wir nur C und nicht C++ als Pro­gram­mier­sprache nutzen.

Sie entwick­eln ein Gerät und braucht jeman­den, der die Firmware dazu schreibt? Melden Sie sich — wir freuen uns auf das Gespräch: logima.net/contact