Welche Programmiersprache für Embedded Systems?

Die Wahl der Programmiersprache ist eine der frühesten und folgenreichsten Entscheidungen in jedem Embedded-Projekt. Sie beeinflusst nicht nur die Entwicklungsgeschwindigkeit, sondern auch den Zertifizierungsaufwand, die Wartbarkeit und die Fähigkeit, Hardware-Ressourcen effizient zu nutzen. Wer ein IoT Gerät entwickeln lässt oder ein Embedded System für industrielle oder medizinische Anwendungen plant, muss diese Entscheidung bewusst und mit Blick auf die gesamte Produktlebensdauer treffen.

In der Praxis konkurrieren vor allem C, C++ und Rust um die Gunst der Entwicklerteams. Jede dieser Sprachen bringt spezifische Stärken mit, aber auch klare Einschränkungen unter realen Hardware-Constraints. Die folgende Übersicht hilft, die richtige Wahl für das jeweilige Projekt zu treffen.

Table of Contents

C, C++, Rust und Co.: die wichtigsten Sprachen im Überblick

Die drei dominanten Sprachen in der Embedded-Entwicklung sind C, C++ und Rust. Daneben existieren Python (MicroPython/CircuitPython), Ada und assemblersprachliche Anteile für zeitkritische Routinen, die jedoch Nischenanwendungen bedienen.

C: Direkter Hardwarezugriff, minimaler Overhead, breite Toolchain-Unterstützung. Standardsprache für Bare-Metal und RTOS-Umgebungen.
C++: Objektorientierung und Templates ermöglichen abstraktere Architekturen, erhöhen jedoch die Gefahr von verstecktem Overhead durch Ausnahmebehandlung, RTTI und dynamische Allokation.
Rust: Speichersicherheit ohne Garbage Collector, striktes Ownership-Modell. Zunehmend relevant für sicherheitskritische Systeme und Projekte mit hohem Zertifizierungsdruck.
MicroPython: Rapid Prototyping auf ressourcenreichen Microcontrollern. Nicht geeignet für zeitkritische Interrupt-Routinen oder Systeme mit weniger als 256 KB RAM.

Wer ein Embedded System von der Idee bis zur Serienreife entwickelt, sollte die Sprachwahl nicht isoliert betrachten. Toolchain-Reife, verfügbare HAL-Bibliotheken, RTOS-Kompatibilität und das Know-how des Teams sind ebenso entscheidend wie die Sprachsemantik selbst.

Warum C in der Embedded-Entwicklung so dominant ist

C ist auf nahezu jeder Embedded-Plattform die erste Sprache der Wahl, und das aus konkreten technischen Gründen: Compiler wie GCC und LLVM/Clang erzeugen für ARM-Cortex-M-Architekturen deterministischen Maschinencode mit gut vorhersagbarem Stack- und Heap-Verhalten. Für STM32, PIC und NXP-Plattformen existieren ausgereifte HAL-Bibliotheken, CMSIS-Implementierungen und Referenz-Firmware ausschließlich oder primär in C.

Unter RTOS-Umgebungen wie FreeRTOS ist C der native Bürger. Task-Scheduling, ISR-Kommunikation und Mutex-Handling sind direkt in C-APIs abgebildet. Der Overhead ist messbar gering: Ein FreeRTOS-Kernel belegt auf einem STM32F4 typischerweise unter 10 KB Flash bei minimaler Konfiguration.

Der kritische Nachteil: C bietet keine Speichersicherheit auf Sprachebene. Buffer-Overflows, dangling Pointers und undefiniertes Verhalten durch Pointer-Arithmetik sind häufige Fehlerquellen, die in sicherheitskritischen Anwendungen zu Zertifizierungsproblemen führen können. IEC 62443 und IEC 61508 verlangen explizite Maßnahmen gegen solche Fehlerklassen, was den Testaufwand erheblich erhöht. Wer die Hardwareentwicklung outsourcen möchte, sollte sicherstellen, dass der Dienstleister Erfahrung mit den jeweiligen Normen und deren Auswirkungen auf die Sprachwahl mitbringt.

Rust als moderne Alternative für sicherheitskritische Systeme

Rust eliminiert auf Compilerebene eine ganze Klasse von Fehlern, die in C manuell verhindert werden müssen: Use-after-free, doppelte Freigabe und Race Conditions in concurrent Code. Das Ownership-Modell erzwingt zur Kompilierzeit korrekte Speicherverwaltung, ohne einen Garbage Collector zu benötigen. Für Systeme mit strikten Echtzeit-Anforderungen ist das ein messbarer Vorteil.

In der Praxis bedeutet das für sicherheitskritische Embedded-Projekte: Rust kann den Nachweis formaler Speichersicherheit vereinfachen, was bei IEC 62443 Level 2+ oder DO-178C-Projekten die Zertifizierungszeit reduzieren kann. Das Rust-Ökosystem für Embedded, insbesondere embedded-hal, Zephyr-Bindings und RTIC (Real-Time Interrupt-driven Concurrency), hat sich seit 2023 deutlich stabilisiert.

Einschränkungen bestehen trotzdem: Die Toolchain-Reife für exotische Microcontroller-Familien ist noch lückenhaft. Für PIC-Architekturen fehlen stabile Rust-Compiler-Backends. Außerdem ist die Lernkurve für Teams, die aus C kommen, nicht trivial. Projekte, die auf schnelle Iteration und Time-to-Market angewiesen sind, und bei denen das Team keine Rust-Erfahrung mitbringt, riskieren Verzögerungen von mehreren Wochen allein durch Onboarding. Das ist ein realer Kosten- und Zeitfaktor, der in der Projektplanung berücksichtigt werden muss.

Entscheidungskriterien: die richtige Sprache für das Projekt wählen

Die Sprachwahl hängt von mindestens vier Parametern ab: Zielplattform, Zertifizierungsanforderungen, Teamkompetenz und Wartungshorizont.

Zielplattform und Ressourcen

Auf Microcontrollern mit weniger als 64 KB Flash und 8 KB RAM ist C die einzige praktikable Option. C++ ist ab 128 KB Flash sinnvoll einsetzbar, wenn auf Ausnahmebehandlung und RTTI explizit verzichtet wird. Rust benötigt für einen minimalen no_std-Build typischerweise 20 bis 40 KB Flash mehr als ein äquivalentes C-Programm, abhängig von der Nutzung von Panic-Handler und Formatierungsroutinen.

Zertifizierungsdruck

Für Medizinprodukte nach IEC 62304 und industrielle Systeme nach IEC 61508 SIL2+ ist der Nachweis von Speichersicherheit ein explizites Anforderungsmerkmal. C erfordert dafür umfangreiche statische Analysen (z. B. Polyspace, PC-lint) und Code-Reviews. Rust verschiebt einen Teil dieses Nachweises auf den Compiler, reduziert aber nicht den Dokumentationsaufwand. Ada/SPARK ist in diesem Kontext die formalste Option, aber mit erheblichem Tooling-Aufwand verbunden.

Teamkompetenz und Wartung

Eine Sprachwahl, die das interne Team überfordert, erzeugt technische Schulden. Wenn das Produkt nach der Entwicklung von einem anderen Team gewartet wird, ist die Verbreitung der Sprache im Markt ein relevanter Faktor. C-Entwickler sind deutlich einfacher zu finden als Rust-Embedded-Entwickler, was Wartungskosten und Abhängigkeiten beeinflusst.

Häufige Fehler bei der Sprachwahl in Embedded-Projekten

Der häufigste Fehler ist die Übernahme der Sprachwahl aus einem vorherigen Projekt ohne Analyse der neuen Constraints. Ein Team, das erfolgreich einen BLE-Sensor in C entwickelt hat, nimmt C automatisch auch für ein sicherheitskritisches medizinisches Wearable. Das kann funktionieren, erhöht aber den Zertifizierungsaufwand messbar und erzeugt Risiken, die frühzeitig adressiert werden sollten.

Ein weiterer Fehler: C++ in ressourcenbeschränkten Umgebungen ohne explizite Compiler-Flags einzusetzen, die RTTI, Ausnahmebehandlung und dynamische Allokation deaktivieren. Ohne -fno-exceptions -fno-rtti und ein angepasstes new-Operator-Verhalten kann der Overhead in sicherheitskritischen Kontexten zu nicht-deterministischem Verhalten führen, das erst spät im Entwicklungsprozess sichtbar wird.

Schließlich wird der Einfluss der Sprachwahl auf die Zertifizierungsstrategie regelmäßig unterschätzt. Wer ein IoT Produkt zur Serienreife bringen möchte und die Zertifizierungsanforderungen erst nach der Sprachauswahl analysiert, riskiert, Teile der Firmware neu schreiben zu müssen. CE, FCC und produktspezifische Normen wie EN 60601 für Medizinprodukte haben direkte Auswirkungen auf akzeptable Entwicklungspraktiken und damit auf die Sprachwahl.

Wie Oxeltech bei der Embedded-Sprachwahl und Entwicklung hilft

Wir bei Oxeltech begleiten Projekte von der frühen Architekturentscheidung bis zur zertifizierten Serienproduktion. Die Sprachwahl ist für uns kein isolierter Schritt, sondern Teil einer integrierten Analyse aus Hardware-Constraints, Zertifizierungsanforderungen und Projektzielen.

Technische Beratung zur Sprachwahl: Wir analysieren Zielplattform, RTOS-Anforderungen und Zertifizierungsumfang und empfehlen konkret, ob C, C++ oder Rust für das Projekt geeignet ist, und unter welchen Bedingungen.
Firmware-Entwicklung auf ARM-Cortex, STM32, NXP und PIC: Unsere Entwickler arbeiten mit FreeRTOS und Zephyr und haben Erfahrung mit sicherheitskritischen Projekten in Medizintechnik und industrieller Automatisierung.
Zertifizierungsunterstützung: Wir begleiten Projekte durch CE-, FCC- und IEC-Zertifizierungsprozesse und berücksichtigen regulatorische Anforderungen bereits in der Architektur- und Sprachentscheidung.
Vollständige Hardwareentwicklung: Von Schaltplan und PCB-Layout bis zur Serienproduktion liefern wir integrierte Hardware-Software-Lösungen aus einer Hand.

Wenn ein konkretes Embedded-Projekt ansteht, bei dem die richtige Technologiestrategie entscheidend ist, sprechen Sie uns an. Wir analysieren die Anforderungen und zeigen auf, welcher Entwicklungsweg realistisch, kosteneffizient und zertifizierungssicher ist.