Multitasking: Mehrere Prozesse gleichzeitig laufen lassen ohne delay()

„Multitasking“ auf einem Arduino bedeutet in der Praxis nicht, dass mehrere Programme wirklich parallel laufen wie auf einem PC. Dennoch können Sie auf einem Mikrocontroller wie dem Arduino Mega 2560 sehr wohl mehrere Prozesse gleichzeitig laufen lassen ohne delay() – und genau das entscheidet darüber, ob ein Projekt zuverlässig reagiert oder im Alltag „hängen bleibt“. Wer mit delay() arbeitet, blockiert die Hauptschleife: Während der Wartezeit werden keine Taster abgefragt, keine Sensoren gelesen, keine Netzwerkpakete bearbeitet und keine Motoren sauber nachgeregelt. Das Ergebnis sind verpasste Ereignisse, ruckelnde Bewegungen und scheinbar zufällige Fehlfunktionen. Das Ziel von „Multitasking ohne delay()“ ist daher, Aufgaben in kleine Schritte zu zerlegen und sie zeitgesteuert oder ereignisbasiert auszuführen, ohne den Prozessor anzuhalten. Dabei geht es um ein klares Denkmodell: Jede Aufgabe bekommt ihren eigenen Zeitplan (oder Trigger), läuft kurz und kehrt sofort zurück, damit andere Aufgaben ebenfalls ihre Chance bekommen. In diesem Artikel lernen Sie bewährte Muster kennen – vom klassischen millis()-Timing über Zustandsmaschinen bis hin zu Interrupts und kooperativen Schedulern. Sie erhalten außerdem praxisnahe Strategien, um viele Prozesse gleichzeitig stabil zu betreiben: LED-Blinken, Sensorabfragen, Display-Updates, Kommunikation (UART/I2C/SPI), Logging und Motorsteuerung – alles in einer Loop, ohne Blockaden und ohne „Tricks“, die später schwer zu warten sind.

Warum delay() das Gegenteil von Multitasking ist

delay(ms) stoppt den Programmfluss für eine bestimmte Zeit. In dieser Zeit führt der Controller zwar intern Zeitmessung aus, aber Ihr Sketch tut nichts Produktives. Bei einem einzigen Effekt (z. B. LED blinken) ist das noch tolerierbar. Sobald jedoch mehrere Aufgaben zusammenkommen, wird es kritisch: Ein delay(1000) ist eine Sekunde Blindheit.

• Verpasste Eingaben: Taster, Encoder und Sensor-Impulse werden zu spät oder gar nicht erkannt.
• Kommunikationsprobleme: Serielle Datenpuffer laufen voll oder Pakete werden nicht rechtzeitig verarbeitet.
• Unsaubere Regelung: Motoren, PID-Regler oder Timing-abhängige Abläufe werden instabil.
• Schlechte Benutzererfahrung: Displays frieren ein, Menüs reagieren verzögert.

Der Kernfehler: delay() blockiert. Multitasking im Arduino-Sinn ist hingegen nicht-blockierendes Arbeiten – kurze Arbeitsschritte, die oft wiederholt werden.

Das Grundprinzip: Zeit statt Warten

Der wichtigste Denkwechsel lautet: Sie warten nicht aktiv, sondern prüfen, ob die Zeit für eine Aufgabe gekommen ist. Dafür nutzen Sie Zeitstempel und Zeitdifferenzen. In Arduino-Sketches ist millis() der Standard: Er liefert die Millisekunden seit Programmstart. Mit zwei Zeitpunkten können Sie entscheiden, ob ein Intervall abgelaufen ist.

Formal ist das Prinzip simpel: Wenn t die aktuelle Zeit ist, t₀ der letzte Ausführungszeitpunkt und Δt das gewünschte Intervall, dann gilt:

$t–t₀\ge \mathrm{\Delta t}$

Diese Logik ist robust, weil sie auch mit dem Überlauf von millis() (nach ca. 49 Tagen) korrekt funktioniert, wenn Sie mit unsigned long und Differenzen arbeiten.

Ein guter Einstieg in das Konzept ist das offizielle Arduino-Beispiel „Blink Without Delay“: Blink Without Delay.

Der klassische Ansatz: Mehrere Timer in einer Loop

Der häufigste Weg zu „Multitasking ohne delay()“ ist ein Satz unabhängiger Timer. Jede Aufgabe bekommt ihren eigenen Zeitstempel: LED blinkt alle 500 ms, Sensor wird alle 2000 ms gelesen, Display wird alle 250 ms aktualisiert, Logging passiert alle 10 Sekunden. Jede Aufgabe prüft in der Loop, ob sie „dran“ ist, erledigt kurz ihre Arbeit und kehrt zurück.

• Vorteil: Sehr gut nachvollziehbar, leicht zu debuggen.
• Nachteil: Bei vielen Aufgaben kann der Code unübersichtlich werden, wenn er nicht strukturiert ist.

Wichtig ist, dass jede Aufgabe schnell fertig wird. Eine Aufgabe, die 200 ms blockiert, ist praktisch eine delay(200) mit anderem Namen.

Kooperatives Multitasking: Jede Aufgabe arbeitet in „kleinen Häppchen“

In Arduino-Projekten ist „Multitasking“ fast immer kooperativ: Aufgaben teilen sich freiwillig die CPU. Das funktioniert nur, wenn jede Aufgabe sich kooperativ verhält – also keine langen Schleifen ohne Ausstieg, keine blockierenden Wartezeiten auf Hardware und keine unnötigen Verzögerungen.

• Kleine Schritte: Lieber 10× je 1 ms arbeiten als 1× 10 ms am Stück.
• Kurze kritische Abschnitte: Wenn Sie Interrupts sperren müssen, dann so kurz wie möglich.
• Regelmäßige Rückkehr in loop(): Die Loop ist Ihr „Scheduler“, der allen Aufgaben Zeit gibt.

Zustandsmaschinen: Der Profi-Ansatz für komplexe Abläufe

Viele Projekte bestehen nicht nur aus periodischen Tasks, sondern aus Abläufen: „Starte Motor“, „warte auf Endschalter“, „stoppe“, „messe“, „sende“, „zeige Ergebnis“. Wenn Sie solche Abläufe mit delay() oder blockierenden while-Schleifen bauen, verlieren Sie Multitasking. Die Lösung sind Zustandsmaschinen (State Machines): Ein Prozess wird in Zustände zerlegt, und jeder Loop-Durchlauf führt genau den kleinen Schritt aus, der zum aktuellen Zustand gehört.

Typische Zustände und Übergänge

• IDLE: Nichts zu tun, auf Ereignis warten (Taster, Timer, Sensor).
• RUNNING: Aktor aktiv, Zeit überwachen, Bedingungen prüfen.
• WAITING: Nicht blockierend warten, z. B. bis ein Timeout abläuft oder ein Signal kommt.
• ERROR/RECOVERY: Fehlerbehandlung, Neustart, Rücksetzen in sicheren Zustand.

Der Vorteil: Sie können mehrere Zustandsmaschinen parallel betreiben, ohne dass eine die andere blockiert. Der Code wird dadurch häufig sogar besser wartbar, weil Abläufe explizit modelliert sind.

Ereignisgetrieben arbeiten: Polling vs. Interrupts

Für manche Signale ist zeitgesteuertes Polling ausreichend (z. B. Temperatur alle 2 Sekunden). Für andere Signale müssen Sie Ereignisse sofort erfassen (z. B. Impuls eines Regenmessers, Encoder-Schritt, schnelle Flanken). Hier kommen Interrupts ins Spiel.

Wann Interrupts sinnvoll sind

• Impulszählung: Anemometer, Regenmesser, Durchflussmesser.
• Encoder: Drehencoder bei schnellen Drehungen.
• Zeitkritische Signale: Externe Trigger, die nicht verpasst werden dürfen.

Interrupts sind jedoch kein „Multitasking“-Ersatz, sondern ein Werkzeug zur Ereigniserfassung. Gute Praxis: Im Interrupt nur minimal arbeiten (z. B. Zähler erhöhen, Flag setzen). Die eigentliche Verarbeitung passiert später in der Loop. Das verhindert lange ISR-Laufzeiten, die andere Funktionen stören könnten.

Zur Referenz der Interrupt-Funktionen und Einschränkungen eignet sich die Arduino-Dokumentation zu attachInterrupt(): attachInterrupt() Referenz.

Nicht-blockierende Kommunikation: Serial, I2C und SPI richtig planen

Kommunikation wirkt oft harmlos, ist aber eine der häufigsten Quellen für „versteckte delays“. Ein typischer Fehler ist das Warten auf vollständige Pakete: „Lese, bis ein Zeilenende kommt“ – und wenn es nicht kommt, steht das Programm. Besser ist ein inkrementeller Parser, der Byte für Byte arbeitet und einen Puffer füllt, ohne zu blockieren.

• Serial: Mit Serial.available() prüfen, ob Daten da sind, und dann schrittweise lesen.
• I2C: Sensoren in festen Intervallen auslesen, nicht in langen Schleifen „darauf warten“.
• SPI: Transfers sind schnell, aber Geräte teilen sich den Bus – Chip-Select diszipliniert verwalten.

Gerade auf dem Mega ist es sinnvoll, die mehreren Hardware-UARTs strategisch zu nutzen: Debug-Ausgaben auf Serial, ein Modul auf Serial1, ein weiteres auf Serial2, usw. So vermeiden Sie Engpässe und reduzieren Parsing-Komplexität.

Scheduling-Strategien: Von einfachen Timern bis zu Task-Frameworks

Wenn ein Projekt wächst, wollen Sie nicht 20 Timer-Blöcke per Hand pflegen. Dann lohnt eine saubere Struktur oder ein leichtgewichtiges Scheduler-Konzept. Das kann eine eigene Task-Liste sein (Array aus Tasks mit Intervall und Callback) oder eine etablierte Bibliothek.

Ein einfaches Task-Modell

Ein Task hat typischerweise:

• Intervall: Wie oft soll der Task laufen?
• Letzter Lauf: Zeitstempel der letzten Ausführung.
• Funktion: Code, der kurz arbeitet und zurückkehrt.
• Optional Priorität: Kritische Tasks werden zuerst geprüft.

So entsteht ein „kooperativer Scheduler“, der Aufgaben zyklisch aufruft. Der Vorteil ist die bessere Skalierbarkeit und die Möglichkeit, Tasks zentral zu aktivieren/deaktivieren.

Wann ein RTOS sinnvoll wird

Ein echtes Betriebssystem (RTOS) ist auf AVR-Boards möglich, aber nicht immer sinnvoll. Auf einem Mega 2560 kann ein RTOS helfen, wenn Sie viele logisch getrennte Aufgaben haben, die klar priorisiert werden müssen. Der Preis ist zusätzlicher Overhead und höhere Komplexität. Oft reicht kooperatives Scheduling vollkommen aus – insbesondere, wenn Sie Zustandsmaschinen konsequent einsetzen.

Typische Praxisbeispiele: So sieht Multitasking ohne delay() im Alltag aus

Um das Konzept greifbar zu machen, hilft ein Blick auf typische Parallelaufgaben in realen Projekten. Das Ziel ist immer gleich: Jede Teilaufgabe erledigt ihren Schritt schnell, und keine blockiert andere.

• LED-Status und Fehlercodes: Blinkmuster laufen unabhängig von Sensoren und UI.
• Sensor-Messung: Temperatur alle 2 s, Druck alle 1 s, Strommessung alle 100 ms.
• Display-Update: UI wird z. B. alle 250 ms aktualisiert, nicht bei jedem Loop.
• Logging: Daten werden gesammelt und gebündelt geschrieben (z. B. alle 10 s), um IO zu minimieren.
• Aktoren: Relais/Servos reagieren sofort auf Ereignisse oder Kommandos.
• Kommunikation: Serielle Eingänge werden kontinuierlich gepuffert und geparst.

Das Entscheidende: Sie entkoppeln „wie oft etwas gemessen/angezeigt wird“ von „wie schnell das System reagieren muss“. Eine UI muss nicht 1000× pro Sekunde zeichnen, aber ein Not-Aus-Taster sollte praktisch sofort wirken.

Die häufigsten Fehler beim Umstieg weg von delay()

Viele Entwickler ersetzen delay() durch millis() und wundern sich, dass das Projekt trotzdem „stockt“. Der Grund: Blockade kann auch in anderer Form auftreten. Diese Liste hilft, die Klassiker zu vermeiden.

• Blockierende while-Schleifen: „Warte, bis…“ ohne Timeout ist ein verstecktes delay().
• Zu große Arbeitspakete: Sensor-Auswertung oder String-Building dauert zu lange am Stück.
• Unkontrollierte Serial-Ausgaben: Zu viele Debug-Prints bremsen und verfälschen Timing.
• Speicherfragmentierung: Häufige String-Konkatenation führt zu instabilem Verhalten über Zeit.
• Interrupt-Missbrauch: Zu viel Logik in ISR führt zu Störungen, Jitter, seltenen Hängern.
• Fehlende Zeitfenster: Kein Timeout bei Kommunikation oder Sensoren führt zu endlosem Warten.

Timeouts als Sicherheitsnetz: Nicht warten, sondern begrenzen

Ein robustes Multitasking-System braucht Timeouts. Wenn eine Komponente nicht antwortet (Sensor defekt, Modul offline), darf das nicht das komplette Programm blockieren. Ein Timeout ist die technische Umsetzung von „Wir warten maximal X Millisekunden, dann gehen wir in einen Fehlerzustand oder versuchen es später erneut“.

Das ist wieder eine einfache Differenzlogik. Wenn Sie ab Startzeit t₀ maximal Δtmax warten wollen, gilt:

$t–t₀\ge \mathrm{\Delta t}max$

Timeouts sind besonders wichtig bei serieller Kommunikation, Netzwerkzugriffen (über Shields) und bei mechanischen Abläufen (Endschalter, Türkontakte, Bewegungen).

Timing-Qualität: Jitter reduzieren und Aufgaben sinnvoll takten

Nicht jede Aufgabe braucht die gleiche Frequenz. Wenn Sie alles „so schnell wie möglich“ ausführen, erzeugen Sie unnötige Last und machen es schwer, stabile Zeitfenster einzuhalten. Gute Praxis ist eine bewusste Taktung.

• Schnell (1–10 ms): Encoder-Abfrage (wenn nicht per Interrupt), Motor-Steps, zeitkritische Flags.
• Mittel (50–500 ms): UI-Update, Debounce-Logik, einfache Statuschecks.
• Langsam (1–10 s): Temperatur, Luftdrucktrend, Datenlogging, Netzwerkstatus.

Wenn Sie Messwerte glätten, tun Sie das ebenfalls nicht in riesigen Schleifen, sondern inkrementell: Z. B. pro Sekunde einen Wert in einen Ringpuffer schreiben und daraus Mittelwerte berechnen, statt „alle 60 Werte neu zu summieren“.

Debuggen ohne den Takt kaputtzumachen

Debug-Ausgaben über Serial sind wertvoll – aber sie verändern das Timing. Wenn Sie Multitasking-Probleme analysieren, nutzen Sie Debug bewusst:

• Schaltbare Debug-Levels: Nur bei Bedarf viel ausgeben, sonst minimal.
• Event-basiert loggen: Nicht jeden Loop-Durchlauf, sondern Zustandswechsel und Fehler.
• Messpunkte: Zeitstempel an kritischen Stellen (Start/Ende einer Task) helfen, „Zeitfresser“ zu finden.

Bewährte Hilfsmittel und weiterführende Quellen

• Blink Without Delay: offizielles Beispiel für nicht-blockierendes Timing
• millis(): Zeitmessung in Arduino-Sketches
• attachInterrupt(): Ereignisse zuverlässig erfassen
• micros(): Feintiming für sehr kurze Zeitfenster

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.