Interrupts beim Leonardo sind ein zentraler Baustein, wenn Projekte wirklich reaktionsschnell werden sollen – ohne dass Ihr Sketch permanent Signale „abfragt“ (Polling). Gerade bei Drehencodern, schnellen Impulssensoren, präziser Tasterauswertung oder Zeitmessungen ist ein Interrupt oft die sauberste Lösung: Der Mikrocontroller unterbricht den normalen Programmablauf, führt eine kurze Interrupt-Service-Routine (ISR) aus und kehrt danach zum Hauptprogramm zurück. Der Arduino Leonardo bietet dabei eine Besonderheit, die im Alltag häufig unterschätzt wird: Er verfügt über 5 externen Interrupt-Pins, die sich direkt für Ereignisse von außen nutzen lassen. Das ist mehr als bei vielen Einsteiger-Boards, bei denen oft nur zwei Pins für externe Interrupts verfügbar sind. Damit Sie diese Möglichkeiten sicher und stabil ausreizen, müssen Sie jedoch wissen, welche Pins am Leonardo tatsächlich für externe Interrupts vorgesehen sind, wie die Arduino-Funktionen attachInterrupt und digitalPinToInterrupt korrekt eingesetzt werden und welche Regeln in einer ISR gelten. In diesem Artikel lernen Sie, welche 5 Pins relevant sind, wie Sie das Trigger-Verhalten (RISING, FALLING, CHANGE, LOW) passend auswählen, wie Sie typische Fehler wie flackernde Zähler, Datenmüll durch Prellen oder zufällige Resets vermeiden und wie Sie Interrupts so programmieren, dass Ihr Projekt auch unter Last (LED-Animationen, USB, serielle Kommunikation) zuverlässig läuft.
Was externe Interrupts beim Leonardo leisten – und wann sie überlegen sind
Ein externer Interrupt reagiert auf eine Pegel- oder Flankenänderung an einem speziellen Pin. Im Unterschied zu Polling ist die Reaktionszeit nicht davon abhängig, wie häufig Ihre loop-Funktion den Pin prüft. Das ist entscheidend, wenn Ereignisse sehr kurz sind oder schnell aufeinander folgen. Typische Praxisfälle sind:
- Drehencoder: Sauberes Zählen von Schritten ohne Aussetzer bei schnellen Drehungen.
- Impulsgeber und Sensoren: Zählen von Lichtschranken, Hall-Sensoren oder Tachosignalen.
- Zeitkritische Taster: Sofortige Reaktion bei sehr kurzen Betätigungen.
- Wake-up- oder Alarm-Ereignisse: Ein Signal soll unabhängig vom restlichen Programmfluss eine Reaktion auslösen.
Arduino stellt dafür die Funktion attachInterrupt bereit. Die offizielle Arduino-Referenz betont außerdem, dass die Pin-Zuordnung je nach Board variiert und dass digitalPinToInterrupt für portable Sketche genutzt werden sollte: Arduino Referenz: attachInterrupt.
Die 5 externen Interrupt-Pins am Leonardo: Pinliste und Besonderheiten
Für den Arduino Leonardo werden häufig die folgenden fünf Digitalpins als externe Interrupt-Pins genannt: 0, 1, 2, 3 und 7. In der Praxis taucht diese Liste in Community- und Pinout-Dokumentationen immer wieder auf, inklusive der Zuordnung zu Interrupt-Nummern: Pin 3 (Interrupt 0), Pin 2 (Interrupt 1), Pin 0 (Interrupt 2), Pin 1 (Interrupt 3) und Pin 7 (Interrupt 4). Eine solche Zuordnung wird beispielsweise in einer Leonardo-Pinout-Beschreibung dokumentiert: Arduino Leonardo Guide mit Interrupt-Pinliste. Auch in einer Arduino-Forum-Diskussion wird explizit erwähnt, dass der Leonardo fünf Pins für externe Interrupts hat (0, 1, 2, 3, 7): Arduino Forum: Leonardo Interrupt Pins 0,1,2,3,7.
Wichtig für die Praxis: Pins 0 und 1 werden häufig gleichzeitig als RX/TX für Serial1 genutzt. Wenn Sie also mehrere Leonardos oder externe UART-Geräte über Serial1 verbinden, sind diese beiden Pins für Interrupt-Aufgaben meist nicht mehr „frei“. Genau deshalb sind die zusätzlichen Interrupt-Pins (2, 3 und 7) beim Leonardo oft die Rettung, wenn das Projekt wächst.
digitalPinToInterrupt: Warum Sie diese Funktion konsequent verwenden sollten
Viele ältere Sketche verwenden direkt Interruptnummern. Das ist beim Wechsel des Boards eine der häufigsten Ursachen für „funktioniert nicht mehr“. Die Funktion digitalPinToInterrupt übersetzt den verwendeten Digitalpin in die passende Interrupt-Referenz – und sorgt damit für bessere Portabilität. Arduino beschreibt das Verhalten klar: digitalPinToInterrupt nimmt einen Pin entgegen und liefert eine passende Interrupt-Zuordnung zurück, sofern dieser Pin Interrupts unterstützt: Arduino Referenz: digitalPinToInterrupt.
- Vorteil: Ihr Code bleibt besser kompatibel zwischen Board-Familien.
- Fehlervermeidung: Falsche Interruptnummern werden seltener „aus Versehen“ verwendet.
- Lesbarkeit: Der Sketch zeigt klar, welcher Pin das Ereignis liefert.
Trigger-Modi verstehen: LOW, CHANGE, RISING, FALLING richtig einsetzen
Beim Anbinden eines externen Interrupts definieren Sie, wann er auslösen soll. Arduino unterstützt je nach Board und Pin typischerweise diese Modi: LOW (Pegel), CHANGE (jede Flanke), RISING (steigende Flanke) und FALLING (fallende Flanke). Der richtige Modus ist nicht nur Geschmackssache – er entscheidet über Stabilität, Entprellung und Fehltrigger.
RISING und FALLING: Die Standardwahl für klare Impulse
Wenn Ihr Signal sauber von LOW nach HIGH bzw. HIGH nach LOW wechselt (z. B. bei Hall-Sensoren oder Logiksignalen), sind RISING oder FALLING meist die robusteste Wahl. Sie lösen pro Ereignis nur einmal aus – und reduzieren damit das Risiko, dass Prellen oder Rauschen mehrere Auslösungen erzeugt.
CHANGE: Ideal für Encoder, aber anfälliger ohne Filter
CHANGE reagiert auf beide Flanken. Das ist praktisch für quadraturkodierte Drehencoder, weil Sie so beide Kanäle (A/B) effizient auswerten können. Gleichzeitig steigt aber die Trigger-Häufigkeit. Ohne saubere Entprellung (hardwareseitig oder softwareseitig) kann CHANGE besonders bei mechanischen Encodern zu Mehrfachzählungen führen.
LOW: Vorsicht bei Dauerpegeln
LOW ist ein Pegelmodus: Solange der Pin LOW ist, kann der Interrupt „immer wieder“ auslösen, abhängig von Implementierung und Interrupt-Handling. Das ist für manche Wake-up-Szenarien sinnvoll, aber für Zähl- und Tasteranwendungen häufig ungünstig, weil es zu einer Flut an ISR-Aufrufen führen kann.
ISR-Regeln: Was in einer Interrupt-Service-Routine erlaubt ist (und was nicht)
Die wichtigste Regel lautet: Eine ISR muss kurz und deterministisch bleiben. Je länger eine ISR läuft, desto stärker stört sie den restlichen Programmablauf – und desto eher entstehen Folgefehler. In der Arduino-Dokumentation wird typischerweise darauf hingewiesen, dass bestimmte Operationen (insbesondere zeitkritische oder blockierende) in Interrupts problematisch sind und dass Variablen, die in ISR und Hauptprogramm genutzt werden, als volatile markiert werden sollten: Arduino Hinweise zu attachInterrupt und ISR.
- Keine langen Wartezeiten: Delay-artige Logik ist in einer ISR fehl am Platz.
- Keine komplexen Aufgaben: LED-Animationen, umfangreiche Berechnungen, Protokoll-Parsing gehören in die loop.
- Nur Flags und Zähler: In der ISR idealerweise nur einen Zähler erhöhen oder ein Flag setzen.
- volatile nutzen: Gemeinsame Variablen zwischen ISR und loop als volatile deklarieren.
volatile und atomarer Zugriff: Warum Zähler manchmal „springen“
Wenn eine Variable sowohl in der ISR als auch im Hauptprogramm verwendet wird, kann der Compiler Optimierungen vornehmen, die aus Sicht der ISR „unsichtbar“ sind. volatile verhindert genau das und sorgt dafür, dass jede Lese- und Schreiboperation tatsächlich im Speicher passiert. Das löst jedoch nur einen Teil des Problems: Bei mehrbytigen Variablen (z. B. 16- oder 32-bit Zählern) kann es passieren, dass das Hauptprogramm die Variable gerade liest, während die ISR sie aktualisiert. Das führt zu inkonsistenten Zwischenzuständen.
Für robuste Systeme ist deshalb der atomare Zugriff wichtig: Entweder Sie kopieren den Zähler in einem kurzen, geschützten Abschnitt in eine lokale Variable oder Sie nutzen passende Mechanismen der Plattform. Ziel ist: Der Wert wird „in einem Stück“ gelesen, ohne dass ein Interrupt dazwischenfunkt.
Taster und Prellen: Interrupts lösen Probleme – aber nicht die Physik
Viele Einsteiger gehen davon aus, dass ein Interrupt einen Taster „automatisch“ sauber macht. In Wirklichkeit prellen mechanische Taster häufig: Beim Drücken und Loslassen entstehen mehrere schnelle Pegelwechsel. Ein Interrupt reagiert darauf gnadenlos und kann aus einem Tastendruck mehrere Ereignisse machen.
- Hardware-Entprellung: RC-Glied oder Schmitt-Trigger kann die Signalflanke beruhigen.
- Software-Entprellung: In der ISR nur Zeitpunkt/Flag setzen, in der loop einen Mindestabstand (Debounce-Zeit) prüfen.
- Geeigneter Trigger: RISING oder FALLING ist meist besser als CHANGE für Taster.
Für viele Projekte ist ein hybrider Ansatz ideal: eine moderate Hardware-Beruhigung plus eine einfache Zeitprüfung im Hauptprogramm. So bleibt die ISR kurz, und Sie vermeiden Mehrfachtrigger zuverlässig.
Drehencoder am Leonardo: Externe Interrupts gezielt ausnutzen
Bei Drehencodern zeigt sich der Nutzen von Interrupts besonders deutlich. Ein Encoder liefert zwei Signale (A und B), die phasenverschoben sind. Damit können Sie Drehrichtung und Schrittanzahl bestimmen. Entscheidend ist: Encoder können sehr schnelle Impulsfolgen erzeugen, die Polling leicht verpasst – besonders wenn Ihr Sketch parallel LEDs aktualisiert oder USB-Kommunikation betreibt. Externe Interrupts auf zwei Pins (z. B. 2 und 3) sind hier eine gängige Wahl, weil Sie beide Kanäle erfassen können, ohne Ihre loop zu überlasten.
- Pinwahl: Zwei Interrupt-Pins für A/B (z. B. 2 und 3), plus gemeinsame Masse und Pull-ups.
- Trigger: Häufig RISING auf Kanal A und B oder CHANGE, je nach Auswerte-Strategie.
- ISR-Aufgabe: Nur Richtung/Counter aktualisieren, keine Ausgabeaktionen ausführen.
Interrupts und USB/HID: Besonderheiten des Leonardo im PC-nahen Einsatz
Der Leonardo ist häufig in HID-Projekten im Einsatz (Tastatur, Maus, Game-Controller). Dabei sollten Sie beachten: USB-Stacks und HID-Reports haben eigene Timing-Anforderungen. Wenn Ihre ISR zu lange läuft oder zu häufig feuert, können Nebenwirkungen auftreten: verzögerte USB-Übertragung, „hakelige“ HID-Ereignisse oder instabile Zustände bei hoher Systemlast. Der richtige Ansatz ist daher: Interrupts sammeln nur Ereignisse, die loop verarbeitet sie in einer kontrollierten Rate. So bleibt Ihr System responsiv, ohne USB zu stören. Grundlage für Boarddetails und Einsatzkontext bietet die offizielle Leonardo-Seite: Arduino Leonardo: Hardware und Eigenschaften.
Mehrere Interruptquellen koordinieren: Prioritäten und Überlast vermeiden
Ein realistisches Projekt hat oft mehr als einen Interrupt: Encoder, Taster, Sensoren. Dann wird Koordination wichtig. Technisch können Interrupts sich gegenseitig „in die Quere kommen“, weil während einer ISR andere Interrupts je nach Systemzustand verzögert werden. In der Praxis bedeutet das: Sie sollten vermeiden, dass ein Pin mit sehr hoher Triggerfrequenz (z. B. schneller Encoder) das System dominiert und andere Ereignisse verdrängt.
- Ereignisse drosseln: Nicht jede Flanke muss sofort eine Aktion auslösen; sammeln Sie nur Zählwerte.
- Update-Raten definieren: Verarbeitung in der loop in festen Intervallen (z. B. alle 5–20 ms).
- Signalqualität erhöhen: Saubere Pull-ups, kurze Leitungen, Schirmung bei Störumgebung.
Praktische Pinstrategie: Welche Interrupt-Pins Sie wofür reservieren sollten
Da der Leonardo fünf externe Interrupt-Pins besitzt, lohnt sich eine klare Pinstrategie. Ein bewährtes Vorgehen ist, Pins 2 und 3 für „kritische“ schnelle Signale zu reservieren (Encoder, Impulsgeber) und Pin 7 für einen Taster oder eine Statusleitung zu nutzen. Pins 0 und 1 sollten Sie bewusst einplanen: Wenn Serial1 benötigt wird, sind diese beiden Pins funktional gebunden.
- Pins 2 und 3: Hochfrequente oder besonders wichtige Ereignisse.
- Pin 7: Zusätzlicher Event-Pin (z. B. Mode-Taster, Reset-Event, Wake-Signal).
- Pins 0 und 1: Nur als Interrupt nutzen, wenn Serial1 nicht gebraucht wird.
Die häufig zitierte Interrupt-Pinliste (0, 1, 2, 3, 7) sowie die Zuordnung der Interruptnummern wird in mehreren Quellen dokumentiert, unter anderem in einer Leonardo-Guide-Zusammenfassung: Leonardo Interrupts: Pin- und Interruptnummern.
Fehlersuche: Wenn Interrupts nicht auslösen oder „spinnen“
Wenn ein Interrupt nicht wie erwartet funktioniert, liegt die Ursache sehr häufig nicht im Grundprinzip, sondern in Details: Pinmodus, Verdrahtung, Trigger, Prellen, falsche Pinzuordnung oder fehlende gemeinsame Masse. Eine systematische Prüfung spart Zeit.
- Pin stimmt wirklich? Nutzen Sie konsequent digitalPinToInterrupt und prüfen Sie, ob der Pin Interrupts unterstützt: digitalPinToInterrupt Referenz.
- Masse verbunden? Ohne gemeinsamen GND sind Flanken oft „zufällig“ oder gar nicht erkennbar.
- Trigger-Modus passend? Ein Sensor, der von HIGH nach LOW schaltet, braucht FALLING statt RISING.
- Prellen vorhanden? Bei Tastern führt CHANGE häufig zu mehrfachen Auslösungen.
- ISR zu lang? Wenn die ISR zu viel macht, entstehen Aussetzer und Folgefehler.
Outbound-Links für vertiefende, verlässliche Informationen
- Arduino Leonardo: Offizielle Hardware-Übersicht und Boarddetails
- Arduino attachInterrupt: Funktionsweise, Modi und Hinweise zu ISR
- Arduino digitalPinToInterrupt: Portables Mapping von Pin zu Interrupt
- Arduino Forum: Diskussion zur Interrupt-Pinliste des Leonardo (0,1,2,3,7)
- Leonardo Guide: Interrupt-Pins und Zuordnung der Interruptnummern
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.

