February 9, 2026

Interrupts beim Arduino Uno: So reagiert dein Board sofort

Interrupts beim Arduino Uno sind eine der effektivsten Methoden, wenn dein Board wirklich „sofort“ reagieren soll – also unabhängig davon, was dein Sketch gerade in der loop() macht. Viele Arduino-Projekte funktionieren problemlos mit klassischer Abfrage-Logik: Du prüfst in loop() einen Taster, liest Sensorwerte und steuerst Ausgänge. Doch sobald Ereignisse sehr kurz sind (z. B. Impulse eines Drehencoders), sehr präzise erfasst werden müssen (z. B. Zählungen, Frequenzen, Taktflanken) oder dein Code zeitweise stark ausgelastet ist (z. B. Display-Updates, serielle Ausgaben, Bibliotheken), stößt Polling schnell an Grenzen. Genau hier kommen Interrupts ins Spiel: Sie unterbrechen den normalen Programmablauf und führen eine spezielle Interrupt-Service-Routine (ISR) aus, sobald ein bestimmtes Ereignis auftritt – zum Beispiel eine steigende Flanke an einem Pin. Das klingt „magisch“, ist aber ein klar definiertes Hardware-Feature des Mikrocontrollers. In diesem Artikel erfährst du verständlich, was Interrupts sind, welche Interrupt-Pins der Arduino Uno bietet, wie du externe Interrupts korrekt einsetzt, welche Regeln in einer ISR zwingend gelten und wie du typische Fehler vermeidest. Ziel ist, dass du Interrupts nicht als komplizierte Profi-Technik siehst, sondern als zuverlässiges Werkzeug für schnelle Reaktionen und präzise Messungen.

Table of Contents

Was ist ein Interrupt und warum reagiert der Arduino damit „sofort“?

Ein Interrupt ist ein Ereignis, das den Mikrocontroller veranlasst, den aktuellen Programmfluss kurz zu unterbrechen. Statt weiter in der loop() oder in einer laufenden Funktion zu arbeiten, springt der Controller in eine spezielle Routine (die ISR). Dort kannst du minimalen Code ausführen, um das Ereignis zu erfassen – zum Beispiel einen Zähler erhöhen oder ein Flag setzen. Anschließend kehrt der Mikrocontroller an die Stelle zurück, an der er unterbrochen wurde, und macht weiter.

Polling (Abfragen): loop() prüft regelmäßig, ob etwas passiert ist. Reaktion hängt davon ab, wie oft geprüft wird.
Interrupt: Hardware meldet das Ereignis sofort. Die ISR läuft auch dann, wenn loop() gerade „beschäftigt“ ist.

Wichtig: „Sofort“ bedeutet in der Praxis „sehr schnell und deterministisch im Rahmen der Hardware“. Es gibt eine geringe Latenz, aber sie ist typischerweise deutlich kleiner als bei Polling-Ansätzen. Für die Arduino-spezifische Nutzung ist die offizielle Referenz zu attachInterrupt() eine gute Grundlage.

Wann lohnen sich Interrupts – und wann nicht?

Interrupts sind nicht automatisch „besser“. Sie sind sinnvoll, wenn du Ereignisse zuverlässig und zeitnah erfassen musst. Wenn deine Anwendung dagegen gemütlich ist (z. B. eine LED bei Tastendruck umschalten, einmal pro Sekunde einen Sensor lesen), ist ein sauberer millis()-Ansatz oft einfacher und stabiler.

Typische Anwendungsfälle, bei denen Interrupts stark sind

Drehencoder: schnelle Impulse, die bei Polling verloren gehen können
Impulszählung: Durchflussmesser, Geigerzähler, Taktgeber, Lichtschranken
Frequenzmessung: kurze Perioden, präzise Flankenerkennung
Not-Aus / Sicherheitsereignis: sofortiges Reagieren, unabhängig von loop()
Wake-up / Ereignis-Trigger: Programmlogik erst starten, wenn ein Signal kommt

Situationen, in denen Interrupts häufig übertrieben sind

Normale Tasterabfragen mit menschlicher Reaktionszeit
Langsame Sensoren (z. B. Temperatur), die nur gelegentlich gelesen werden
Projekte, bei denen ohnehin ein stabiler millis()-Scheduler genügt

Wenn dein Ziel hauptsächlich „mehrere Dinge parallel“ ist, ist nicht-blockierendes Timing oft der bessere erste Schritt. Eine gute Referenz dafür ist millis().

Welche Interrupt-Möglichkeiten hat der Arduino Uno?

Beim Arduino Uno sind vor allem zwei Kategorien wichtig: externe Interrupts an bestimmten Pins und Pin-Change-Interrupts (Pin-Änderungsinterrupts) über Gruppen von Pins. Einsteiger starten meist mit externen Interrupts, weil sie einfacher zu nutzen und gut dokumentiert sind.

Externe Interrupts: Die „klassischen“ Interrupt-Pins

Beim Arduino Uno sind die externen Interrupts üblicherweise an zwei digitale Pins gebunden: D2 und D3. Diese sind besonders praktisch, weil du sie über attachInterrupt() direkt nutzen kannst.

D2: externer Interrupt (oft als INT0 bezeichnet)
D3: externer Interrupt (oft als INT1 bezeichnet)

Da sich Board-Varianten und Dokumentationen im Detail unterscheiden können, lohnt sich ein Blick in die offizielle Hardware-Seite des Uno: Arduino Uno Rev3 Dokumentation.

Pin-Change-Interrupts: Mehr Pins, aber mehr Komplexität

Pin-Change-Interrupts können auf vielen Pins ausgelöst werden (je nach Port-Gruppierung), reagieren aber auf „Pin hat sich geändert“ und erfordern häufig mehr Eigenlogik, um herauszufinden, welcher Pin in der Gruppe das Ereignis verursacht hat. Für fortgeschrittene Projekte ist das wertvoll, aber als Einstieg sind externe Interrupts meist die bessere Wahl.

attachInterrupt(): Der Standardweg für externe Interrupts

Die Arduino-API macht externe Interrupts sehr zugänglich. Du verknüpfst einen Interrupt mit einer Funktion (ISR) und legst fest, bei welchem Signalwechsel sie ausgelöst wird. Arduino kapselt die Mikrocontroller-Details, sodass du dich auf das Verhalten konzentrieren kannst. Details und Parameter sind in der Referenz zu attachInterrupt() beschrieben.

Auslösebedingungen: RISING, FALLING, CHANGE, LOW

RISING: ISR bei steigender Flanke (LOW → HIGH)
FALLING: ISR bei fallender Flanke (HIGH → LOW)
CHANGE: ISR bei jeder Änderung
LOW: ISR solange Pin LOW ist (mit Vorsicht zu verwenden)

Für viele Sensor-Impulse ist FALLING oder RISING ideal. CHANGE ist nützlich bei Encoder-Signalen oder wenn du beide Flanken auswerten willst, erhöht aber die Anzahl der Interrupts und damit die Last.

Die goldenen Regeln für Interrupt-Service-Routinen (ISR)

Der wichtigste Teil bei Interrupts ist nicht das Aktivieren, sondern das richtige Verhalten in der ISR. Eine ISR soll extrem kurz sein. Viele typische Arduino-Probleme entstehen, weil in der ISR zu viel gemacht wird. Denk an die ISR wie an einen Notizzettel: „Ereignis passiert“ notieren – und die eigentliche Arbeit später in loop erledigen.

Regel 1: ISR so kurz wie möglich

Erhöhe einen Zähler
Setze ein Flag (z. B. eventHappened = true)
Speichere einen Zeitstempel, wenn nötig

Regel 2: Keine blockierenden Funktionen in der ISR

Kein delay()
Keine langen Berechnungen
Keine langsamen Bibliotheksaufrufe

Regel 3: Serial.print in der ISR vermeiden

Serielle Ausgaben sind langsam und können in Interrupt-Kontexten zu Problemen führen. Wenn du debuggen willst, setze in der ISR nur ein Flag oder erhöhe einen Zähler und gib den Wert später in loop() aus. Für serielles Debugging ist der Einstieg über Serial in der Arduino Language Reference empfehlenswert.

Regel 4: Gemeinsame Variablen richtig behandeln

Wenn eine Variable sowohl in der ISR als auch in loop() genutzt wird, muss sie als volatile deklariert werden. Sonst kann der Compiler optimieren, sodass loop() Änderungen „nicht sieht“ oder Werte falsch cached. Außerdem kann es bei mehrbyteigen Datentypen (z. B. unsigned long) zu inkonsistenten Reads kommen, wenn loop() die Variable gerade liest, während die ISR sie aktualisiert.

volatile für gemeinsam genutzte Flags und Zähler
Bei größeren Typen: Werte in loop() kurz „atomar“ kopieren (Interrupts kurz sperren), dann weiterverarbeiten

Regel 5: Debouncing und Signalqualität berücksichtigen

Interrupts reagieren sehr sensibel. Das ist gewünscht, kann aber bei mechanischen Tastern oder „rauschigen“ Signalen zu vielen unerwünschten Auslösungen führen. Für Taster braucht es daher Entprellen (hardwareseitig oder softwareseitig). In vielen Fällen ist Polling mit millis()-Entprellen für Taster sogar die bessere Lösung. Interrupts sind stärker, wenn das Signal sauber und kurz ist (Encoder, Optokoppler, Hall-Sensor).

Praktisches Muster: ISR setzt Flag, loop verarbeitet die Logik

Ein robustes Vorgehen ist, in der ISR nur ein Ereignis zu markieren und die eigentliche Verarbeitung in loop() zu erledigen. So bleibt deine Anwendung stabil, und du kannst komplexe Dinge (Berechnungen, Ausgaben, Display) ohne Interrupt-Stress umsetzen.

ISR: Flag setzen oder Zähler erhöhen
loop(): Flag abfragen, dann Logik ausführen und Flag zurücksetzen

Dieses Muster ist besonders gut, wenn du „sofort“ reagieren willst, aber trotzdem saubere Projektstruktur brauchst.

Interrupts vs. millis(): Was ist wann die richtige Wahl?

In Maker-Projekten ist es hilfreich, die Stärken klar zu trennen:

millis(): ideal für regelmäßige Aufgaben, Zeitpläne, Multitasking ohne Blockieren
Interrupts: ideal für plötzliche Ereignisse, schnelle Impulse, präzise Zählungen

In vielen Projekten kombiniert man beides: millis() organisiert Aufgaben (Sensor lesen, Display aktualisieren), Interrupts erfassen Ereignisse (Impuls zählt, Encoder bewegt). Dadurch bleibt dein Arduino reaktiv und gleichzeitig strukturiert.

Konkrete Beispiele, bei denen Interrupts auf dem Uno glänzen

Damit du die Technik nicht nur theoretisch verstehst, hilft ein Blick auf typische Maker-Szenarien. Der Mehrwert ist in der Praxis immer derselbe: Du verpasst keine kurzen Ereignisse.

Drehencoder: Präzise Schritte zählen, ohne Impulse zu verlieren

Drehencoder liefern je nach Drehgeschwindigkeit sehr kurze Impulse. Bei Polling kann loop() zu langsam sein, besonders wenn du nebenbei ein Display aktualisierst oder viel debugst. Interrupts erfassen die Flanken zuverlässig. Oft setzt man den Interrupt auf einen Kanal und liest den zweiten Kanal in der ISR oder direkt danach, um die Drehrichtung zu bestimmen.

Durchfluss- und Drehzahlsensoren: Impulse als Messgröße

Viele Durchflusssensoren und Tachometer arbeiten mit Impulsen pro Umdrehung oder pro Volumen. Hier ist Interrupt-Zählung ideal: Du erhöhst bei jedem Impuls einen Zähler und berechnest in loop() aus Zählern und Zeitintervall die Rate. So ist die Messung stabil, selbst wenn loop() stark beschäftigt ist.

Not-Aus oder Sicherheitsabschaltung

In Projekten mit Motoren, Relais oder mechanischen Teilen ist ein Not-Aus sinnvoll. Ein externer Interrupt kann im Ernstfall sofort einen sicheren Zustand triggern (z. B. Motor aus), bevor loop() überhaupt wieder an der Tasterabfrage ankommt. Wichtig ist dabei, in der ISR minimal zu bleiben und das System anschließend kontrolliert zu stabilisieren.

Häufige Fallstricke und wie du sie erkennst

Viele Probleme mit Interrupts haben wiederkehrende Muster. Wenn du sie kennst, sparst du dir viel Fehlersuche.

Zu viele Interrupts: „Warum wird mein Projekt langsam?“

Wenn dein Interrupt sehr häufig auslöst (z. B. CHANGE bei rauschigem Signal), verbringt der Mikrocontroller viel Zeit in ISRs. Das kann loop() spürbar ausbremsen. Lösung: sauberes Signal, richtige Flanke wählen, ggf. Hardware-Entstörung, ISR kurz halten.

ISR macht zu viel: „Warum hängt alles oder verhält sich komisch?“

Serial.print, lange Berechnungen oder Wartefunktionen in der ISR sind typische Ursachen. Halte die ISR strikt minimal und verschiebe alles „Schwere“ in loop().

Volatile vergessen: „Warum sieht loop() die Änderungen nicht?“

Ohne volatile kann loop() scheinbar „alte“ Werte sehen. Gerade bei Flags ist das ein Klassiker. Nutze volatile für Variablen, die in ISR und loop geteilt werden.

Prellen und Störungen: „Warum wird mein Interrupt mehrfach ausgelöst?“

Mechanische Taster und unsaubere Signale triggern mehrfach. Für Taster ist meist Entprellen nötig oder ein Wechsel zurück zu Polling mit millis(). Bei Sensorimpulsen helfen saubere Pull-ups, richtige Verdrahtung, ggf. Schmitt-Trigger oder RC-Filter.

Interrupts richtig testen und debuggen, ohne den Ablauf zu stören

Interrupt-Debugging ist anders als normales Debugging. Wenn du in der ISR druckst oder zu viel machst, verfälschst du das Verhalten. Besser ist ein indirekter Test:

In der ISR nur einen Zähler erhöhen oder Flag setzen
In loop() in Intervallen den Zähler ausgeben
Signalquelle bewusst variieren (z. B. Encoder langsam/schnell drehen)

Der serielle Monitor ist dafür ideal, wenn du Ausgaben dosierst. Grundlagen findest du in der Serial-Referenz: Serial.

Best Practices für stabile Interrupt-Projekte auf dem Arduino Uno

Nutze externe Interrupts auf den dafür vorgesehenen Pins (z. B. D2/D3 beim Uno) für klare Ereignisse.
Wähle die Auslösebedingung bewusst: RISING/FALLING statt CHANGE, wenn möglich.
Halte die ISR ultrakurz: Flag/Zähler/Zeitstempel, sonst nichts.
Markiere gemeinsam genutzte Variablen als volatile und kopiere größere Werte in loop atomar.
Entstöre Signale: Pull-ups, saubere Masseführung, kurze Leitungen, ggf. Hardware-Filter.
Kombiniere Interrupts mit millis()-Zeitsteuerung für ein reaktives, strukturiertes System.

Weiterführende Informationsquellen

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.