State Machines (Zustandsautomaten) für saubere PIC-Programme

State Machines (Zustandsautomaten) für saubere PIC-Programme sind eine der zuverlässigsten Methoden, um Firmware für PIC-Mikrocontroller strukturiert, wartbar und fehlerarm aufzubauen. Gerade bei 8-Bit- und kleinen 16-Bit-PICs entstehen viele Projekte zunächst als „loop mit vielen ifs“: Eingänge abfragen, Ausgänge schalten, ein paar Timer prüfen, irgendwo ein Interrupt-Flag auswerten. Solche Programme funktionieren anfangs oft, werden aber mit jeder neuen Funktion unübersichtlicher. Plötzlich gibt es Sonderfälle: Was passiert, wenn ein Taster während eines Motorlaufs gedrückt wird? Wie reagiert das System nach einem Brown-out? Wie werden Timeouts sauber behandelt? Zustandsautomaten lösen dieses Problem, indem sie die Logik in klar definierte Zustände zerlegen und Übergänge nur unter eindeutig beschriebenen Bedingungen erlauben. Das Ergebnis ist nicht nur „schönerer Code“, sondern vor allem ein robusterer: Fehler werden schneller gefunden, unerwartete Zustandskombinationen werden vermieden, und das Systemverhalten bleibt nachvollziehbar – selbst Monate später. In diesem Artikel erfahren Sie, wie Sie State Machines in PIC-Projekten sinnvoll planen, welche Muster in C (z. B. mit XC8) besonders gut funktionieren, wie Sie Zeit und Ereignisse entkoppeln und wie Sie typische Stolperfallen wie blockierende Delays oder „ISR-Spaghetti“ vermeiden.

Was ist ein Zustandsautomat – und warum passt er so gut zu Embedded-Systemen?

Ein Zustandsautomat (Finite State Machine, FSM) beschreibt ein System über eine endliche Menge an Zuständen. Zu jedem Zeitpunkt befindet sich das System in genau einem Zustand (oder in einer klar definierten Kombination, wenn man hierarchische Automaten verwendet). Ereignisse oder Bedingungen lösen Übergänge aus, die das System in einen anderen Zustand bringen. Dadurch wird Verhalten explizit: Statt „irgendwo im Code“ zu verstecken, wann ein Motor starten darf, steht diese Regel als Transition im Modell.

Für PIC-Firmware ist das ideal, weil Mikrocontrollerprogramme typischerweise ereignisgetrieben sind: Taster, Sensoren, Kommunikationspakete, Timer-Überläufe, Fehlerflags. Zustandsautomaten helfen, diese Ereignisse nicht in unkontrollierten if-Ketten zu verarbeiten, sondern in einer klaren Logik, die deterministisch bleibt. Als Hintergrund zum Konzept eignen sich beispielsweise Einführungen in endliche Automaten, etwa über Endliche Automaten (Überblick) oder das englische Pendant Finite-state machine.

Typische PIC-Probleme, die State Machines elegant lösen

Viele Firmwarefehler sind keine „C-Fehler“, sondern Logikfehler: ein Ablauf wird in einer seltenen Reihenfolge ausgelöst, zwei Funktionen konkurrieren um Ressourcen, oder ein Timeout fehlt in einem Sonderfall. State Machines adressieren genau diese Klasse von Problemen.

• Unklare Abläufe: „Start gedrückt“ während Initialisierung oder Fehlerzustand.
• Blockierende Wartezeiten: Delays verhindern die Reaktion auf Ereignisse oder stören Kommunikation.
• Komplexe Fehlerbehandlung: Nach einem Fehler muss das System geordnet stoppen und zurück in einen definierten Zustand.
• Mehrere Funktionen gleichzeitig: Display aktualisieren, Sensoren messen, Kommunikation bedienen – ohne Nebenwirkungen.
• Wartbarkeit: Neue Features führen nicht zu exponentiellem Wachstum von if/else-Strukturen.

Grundprinzip: Zustände sind „Modi“, nicht „Bedingungen“

Ein häufiger Anfängerfehler ist, Zustände mit Bedingungen zu verwechseln. Ein Zustand sollte einen klaren Modus beschreiben, in dem das System eine bestimmte Aufgabe verfolgt oder bestimmte Regeln gelten. Bedingungen sind Auslöser für Übergänge. Ein Beispiel für saubere Zustände:

• IDLE: System wartet, alles sicher aus.
• MEASURE: Sensoren erfassen, Werte validieren.
• CONTROL: Aktor regeln, Grenzwerte überwachen.
• ERROR: Ausgänge in sicheren Zustand, Diagnose, Quittierung.

„Taster ist gedrückt“ ist kein Zustand, sondern ein Ereignis oder eine Bedingung, die in bestimmten Zuständen einen Übergang auslöst.

Die zwei großen Bauformen: Moore- und Mealy-Automaten in der Praxis

In der Theorie unterscheidet man häufig Moore- und Mealy-Automaten. In Embedded-Firmware ist die praktische Bedeutung: Kommen Ausgänge ausschließlich aus dem aktuellen Zustand (Moore), oder hängen Ausgänge zusätzlich direkt von Eingängen/Ereignissen ab (Mealy)?

• Moore-ähnlich: Ausgänge werden beim Eintritt in einen Zustand gesetzt und bleiben stabil, bis der Zustand wechselt. Das ist robust und gut testbar.
• Mealy-ähnlich: Ausgänge reagieren innerhalb eines Zustands auf Eingänge. Das kann schneller reagieren, erfordert aber mehr Sorgfalt, um Flattern zu verhindern.

Für PIC-Projekte ist ein überwiegend Moore-orientierter Ansatz oft sinnvoll, weil er Nebenwirkungen reduziert. Mealy-Elemente nutzen Sie gezielt dort, wo Sie schnelle Reaktion brauchen (z. B. sofortiges Abschalten bei Fehlerbedingung).

Das wichtigste Designziel: Nicht-blockierende Firmware

Saubere Zustandsautomaten funktionieren am besten, wenn Ihr Hauptloop nicht blockiert. Das bedeutet: keine langen delay-Schleifen, keine Busy-Waits auf Flags über viele Millisekunden, keine „Warte bis UART fertig ist“-Loops. Stattdessen arbeiten Sie mit Zeitmarken (Timestamps), Timer-Events oder periodischen Ticks. Der Automat wird in kurzen Zyklen aufgerufen, prüft Ereignisse und entscheidet, ob ein Zustandswechsel nötig ist.

• Statt Delay: „Wenn jetzt – startZeit >= 200 ms, dann weiter“
• Statt Busy-Wait: „Wenn Flag gesetzt, dann Transition“
• Statt endloser Schleifen: „Jeder Loop-Durchlauf macht nur kleine Arbeitsschritte“

Zeit in Zustandsautomaten: Timeouts, Debounce und Periodik

Auf PICs sind Timer-Module und Interrupts zentrale Werkzeuge. Für State Machines ist jedoch entscheidend, dass Sie Zeit als Ereignis behandeln. Ein Zustand kann z. B. ein Timeout besitzen, nach dessen Ablauf automatisch ein Übergang erfolgt. Das ist besonders wichtig für Kommunikation (Antwortzeit), Motorsteuerungen (Anlaufzeit) oder Benutzerinterfaces (Tastendruck-Debounce).

Timeout-Muster

Beim Eintritt in einen Zustand speichern Sie eine Startzeit. Im Zustand prüfen Sie zyklisch, ob die Dauer überschritten wurde. Mathematisch ist das nur eine Differenzprüfung, oft mit Überlauf-sicherer Logik:

$t\_\mathrm{now}-t\_\mathrm{start}\ge T\_\mathrm{timeout}$

Mit einem Tick-Zähler (z. B. Millisekunden) lässt sich das sehr effizient umsetzen, ohne den Ablauf zu blockieren.

Debounce als Zustandsfolge

Entprellen ist ein Paradebeispiel für Zustandsautomaten: Statt „wenn Taste gedrückt, warte 20 ms“ definieren Sie Zustände wie WAIT_PRESS, DEBOUNCE_PRESS, PRESSED, DEBOUNCE_RELEASE. Das macht Ihr UI reaktionsfähig und verhindert, dass andere Aufgaben stehen bleiben.

Der Kern im Code: State-Variable, Event-Flags, Transition-Logik

Eine praxistaugliche Minimalstruktur besteht aus drei Bausteinen: einer Zustandsvariable, einem Event-Speicher (Flags oder Queue) und einer Funktion, die pro Zyklus den Automaten ausführt. Die Zustandsvariable ist meist ein enum, damit Werte lesbar bleiben. Events können als Bitmasken geführt werden (schnell und RAM-sparend) oder als Ringbuffer (wenn Ereignisse nicht verloren gehen dürfen).

• State: aktueller Zustand (z. B. STATE_IDLE).
• Events: z. B. EV_BUTTON, EV_TIMEOUT, EV_RX_PACKET.
• Transition: klare Regeln „wenn Event X im State Y, dann State Z“.

Wichtig: Ein Event sollte idealerweise nur einmal konsumiert werden. Das verhindert, dass ein Event mehrfach zu Übergängen führt, wenn es über mehrere Loop-Zyklen gesetzt bleibt.

Switch-Case-Pattern: Der Klassiker für PIC-Firmware

Das verbreitetste Muster ist ein switch(state), in dem jeder Zustand einen eigenen Block besitzt. Dieses Pattern ist auf PICs effizient, gut lesbar und leicht zu debuggen.

• Entry-Aktionen: beim Zustandswechsel einmal ausführen (z. B. Ausgänge setzen, Timer starten).
• Do-Aktionen: zyklisch ausführen (z. B. Messwert prüfen).
• Exit-Aktionen: selten nötig, aber möglich (z. B. Ressourcen freigeben).

Ein typischer Fehler ist, Entry-Aktionen jedes Mal im Zustand auszuführen. Das führt zu wiederholten Initialisierungen. Abhilfe: Entweder ein „enter“-Flag pro Zustand oder eine zentrale Transition-Funktion, die beim Wechsel die Entry-Aktionen triggert.

Tabellengetriebene Automaten: Wenn Zustände und Übergänge wachsen

Wenn ein Projekt viele Zustände und viele Ereignisse hat, wird ein switch-case schnell lang. Dann kann ein tabellengetriebener Ansatz helfen: Sie definieren Übergänge als Datenstruktur (State, Event, NextState, Action). Das ist besonders attraktiv, wenn Sie Konsistenz prüfen möchten oder wenn mehrere Gerätevarianten unterschiedliche Übergangstabellen nutzen.

• Vorteil: Übergänge sind als Daten sichtbar, leichter zu reviewen.
• Vorteil: Actions können als Funktionszeiger oder IDs geführt werden.
• Nachteil: Funktionszeiger sind auf kleinen PICs nicht immer „gratis“; Code kann komplexer werden.

In vielen PIC-Projekten ist ein hybrider Ansatz ideal: switch-case für Hauptzustände, tabellengetrieben für Unterlogik (z. B. UI-Menüs).

Hierarchische State Machines: Komplexität reduzieren, nicht erhöhen

Bei größeren Systemen lohnt sich das Prinzip der hierarchischen Automaten (Statecharts). Dabei gibt es Oberzustände, die gemeinsame Regeln für Unterzustände definieren. Beispiel: Ein Oberzustand „RUN“ umfasst Unterzustände „RUN_MEASURE“, „RUN_CONTROL“, „RUN_REPORT“. Fehlerbehandlung oder globale Events (Not-Aus) können im Oberzustand abgefangen werden, ohne in jedem Unterzustand kopiert zu werden.

Das Konzept ist bekannt aus Statecharts und Modellierungssprachen; als Einstieg eignet sich z. B. Statecharts (Überblick). Für PIC-Firmware müssen Sie es nicht „akademisch“ implementieren: Oft reicht bereits ein zweites State-Level (mainState + subState), um Code deutlich aufzuräumen.

Events sauber einsammeln: Interrupts als Producer, State Machine als Consumer

Ein sehr robustes Architekturprinzip ist: Interrupts sammeln nur Ereignisse ein, die Zustandsmaschine verarbeitet sie im Hauptloop. Dadurch bleibt die ISR kurz, das Timing stabil und Sie vermeiden, dass komplexe Logik im Interrupt-Kontext schwer debugbar wird.

• ISR macht: Flag setzen, Daten puffern, Timestamp speichern.
• Mainloop macht: Event auswerten, Zustand wechseln, Actions ausführen.
• Vorteil: deterministischer, weniger Race Conditions.

Bei gemeinsam genutzten Variablen achten Sie auf volatile und auf atomare Zugriffe (z. B. bei 16-/32-Bit-Zählern auf 8-Bit-PICs). Wo nötig, lesen Sie mehrbyteige Werte mit kurzen kritischen Abschnitten oder mit „double read“-Techniken.

Fehlerzustände und Recovery: Warum ERROR ein eigener Zustand sein sollte

Viele Firmwarefehler eskalieren, weil es keinen klaren Fehlerzustand gibt. Stattdessen wird „irgendwo“ ein Fehlerflag gesetzt, und das System läuft weiter. Ein sauberer Zustandsautomat definiert Fehler explizit:

• Fehler erkennen: Timeout, Sensor ungültig, Kommunikationsfehler, Überstrom.
• Sicherer Zustand: Ausgänge abschalten oder in definierte Position.
• Diagnose: Fehlercode speichern, Anzeige/LED setzen, optional Log senden.
• Recovery: Quittierung, automatischer Retry oder Neustartpfad.

Das sorgt dafür, dass sich das System nicht in „halb kaputten“ Zwischenzuständen bewegt. Gerade bei Motoren, Pumpen oder Heizungen ist das nicht nur „sauber“, sondern sicherheitsrelevant.

Debugging-Vorteile: Breakpoints auf Zustände statt auf „zufällige Zeilen“

Mit einer State Machine wird Debugging deutlich effizienter. Sie können Breakpoints auf Zustandswechsel setzen, Watch-Fenster auf die State-Variable und Event-Flags legen und den Verlauf nachvollziehen. In MPLAB X IDE ist es besonders hilfreich, die State-Variable dauerhaft zu beobachten, weil Sie sofort sehen, ob der Automat „hängt“ oder in einen unerwarteten Zustand springt.

• Symptom: System reagiert nicht → prüfen, ob State gewechselt hat.
• Symptom: Event kommt nicht an → prüfen, ob ISR das Flag setzt und ob es konsumiert wird.
• Symptom: seltene Fehler → Daten-Breakpoint auf State-Variable kann zeigen, wer sie ändert.

Typische Stolperfallen und wie Sie sie vermeiden

• Zu viele Zustände: Wenn jeder Sonderfall ein eigener Zustand wird, verlieren Sie Übersicht. Besser: klare Hauptzustände, Sonderfälle als Events/Guards.
• Fehlende Guards: Übergänge sollten Bedingungen prüfen (z. B. „nur wenn Sensor valid“), sonst entstehen ungültige Pfade.
• Entry-Aktionen im Loop: Initialisierung muss einmalig beim Eintritt passieren, nicht bei jedem Durchlauf.
• Events gehen verloren: Bei kurzen Pulsen Events in der ISR puffern oder latches verwenden, nicht nur „Momentzustand“ abfragen.
• ISR macht zu viel: Komplexe Logik im Interrupt führt zu Timingproblemen und schwerer Wartbarkeit.

Bewährte Best Practices für saubere PIC-Zustandsautomaten

• Einheitliches Naming: STATE_* für Zustände, EV_* für Ereignisse, ACT_* für Aktionen.
• Ein Punkt der Wahrheit: Zustandswechsel über eine zentrale Funktion, die Entry/Exit sauber behandelt.
• Kurze Zustandsblöcke: jeder Zustand bleibt überschaubar; komplexe Arbeit in Hilfsfunktionen auslagern.
• Timeouts überall dort, wo etwas „hängen“ kann: Kommunikation, Sensorstart, Motorbewegung.
• Dokumentation als Zustandsdiagramm: Ein einfaches Diagramm spart enorme Einarbeitungszeit.

Outbound-Links für Vertiefung und Toolchain

• MPLAB X IDE (Microchip) – Entwicklungsumgebung
• MPLAB XC Compiler – XC8/XC16/XC32
• Endlicher Automat – Grundlagen
• Finite-state machine – englische Referenz
• Statecharts – hierarchische Zustandsmodelle

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.