Eingebettete Systeme

Arduino & ESP32. void loop() { digitalWrite(LED, HIGH); delay(1000); }. Das ist Embedded Development. In der Industrie nutzt man ARM Cortex-M Chips, FPGAs (programmierbare Hardware) und Profi-Tools (JTAG Debugger, Oszilloskope).

1. Real-Time (Echtzeit)

Echtzeit heißt nicht "schnell". Es heißt deterministisch. "Die Antwort kommt garantiert in < 5ms."

• Hard Real-Time: Deadline verpasst = Katastrophe (Herzschrittmacher, ABS).
• Soft Real-Time: Deadline verpasst = Qualität sinkt (Video-Stream ruckelt). Normale OS (Windows/Linux) sind nicht echtzeitfähig (der Garbage Collector oder Scheduler kann jederzeit dazwischenfunken).

2. Constraints

Du hast oft nur 4 KB RAM. Du hast kein "malloc" (zu gefährlich, Fragmentierung). Du nutzt statische Speicherzuweisung. Rekursion ist oft verboten (Stack Overflow Gefahr).

1. MISRA C & Safety Standards

In der Produktion von eingebetteten Systemen (Automobil, Medizin) ist Standard-C zu gefährlich. Man nutzt MISRA C. Das ist eine Menge von ca. 140 Regeln, die "gefährliche" C-Features verbieten:

• Kein dynamischer Speicher (malloc) nach der Initialisierung.
• Keine unendlichen Schleifen ohne Timeout-Check.
• Keine Funktionspointer (schwer statisch zu analysieren). Dies schränkt die Freiheit ein, garantiert aber, dass die Software zertifizierbar ist (z. B. nach ISO 26262 für Autos). Ein Absturz wegen eines Memory-Leaks ist in diesen Systemen ein fataler Designfehler, kein "Naja-Bug".

2. WCET (Worst-Case Execution Time)

Für Hard Real-Time Systeme reicht es nicht zu wissen, dass der Code "meistens schnell" ist. Man muss die WCET kennen. Das ist mathematisch schwer, da moderne CPUs durch Caches, Pipelines und Branch Prediction variieren. In der Expert-Ebene nutzt man Static Analysis Tools, die den Maschinencode untersuchen und beweisen: "Egal welcher Pfad durch den Code genommen wird, die CPU wird niemals mehr als 42.000 Zyklen brauchen." Wenn das System mit 100 MHz läuft, weiß man sicher: Die Antwort kommt in maximal 0,42 Millisekunden.

3. Hardware-in-the-Loop (HiL)

Eingebettete Systeme zu testen ist schwer, wenn man kein Flugzeug oder Auto zur Hand hat. Man nutzt HiL-Teststände. Dabei wird der echte Mikrocontroller an einen Simulator angeschlossen. Der Simulator "faked" die Sensoren (z. B. simuliert er die Raddrehzahlen bei einer Vollbremsung) und liest die Aktuatoren des Controllers aus. So kann man tausende Crash-Szenarien sicher im Labor durchspielen, bevor der erste echte Prototyp auf die Teststrecke geht.