Mehrere Leonardos verbinden: Kommunikation via Seriell1

Mehrere Leonardos verbinden ist eine elegante Lösung, wenn ein einzelnes Board an Grenzen stößt oder Sie Aufgaben sauber trennen möchten – etwa Eingaben (Buttons, Encoder), LED-Effekte, Sensorik und PC-HID-Funktionen. Der Arduino Leonardo eignet sich dafür besonders gut, weil er neben USB auch eine zusätzliche Hardware-Seriellschnittstelle besitzt: Seriell1. Genau diese Schnittstelle ist der Schlüssel, wenn Sie zwei oder mehr Leonardos direkt miteinander kommunizieren lassen möchten, ohne den USB-Port zu „blockieren“ oder auf weniger robuste Software-Serielllösungen auszuweichen. Kommunikation via Seriell1 bedeutet in der Praxis: Sie nutzen die UART-Hardware des ATmega32U4 über die Pins RX1/TX1, übertragen strukturierte Datenpakete, synchronisieren Zustände und verteilen Lasten. Das ist ideal für modulare Projekte wie Sim-Racing-Buttonboxen, Stream-Controller, Cockpit-Panels oder komplexe Installationen mit mehreren Teilmodulen. Damit die Verbindung zuverlässig ist, braucht es allerdings mehr als nur zwei Kabel: Sie müssen Pegel, Masseführung, Baudrate, Protokoll und Fehlerfälle sauber planen. In diesem Artikel lernen Sie, wie Seriell1 beim Leonardo funktioniert, wie Sie mehrere Boards korrekt verdrahten, welche Topologien möglich sind (Punkt-zu-Punkt, Stern, Bus mit Treiber), wie Sie ein robustes Nachrichtenformat entwerfen und wie Sie typische Fehler wie Datenmüll, Buffer-Overflows oder „stille“ Verbindungsabbrüche vermeiden.

Seriell vs. Seriell1: Der wichtigste Unterschied beim Leonardo

Beim Arduino Leonardo gibt es zwei „serielle Welten“: Serial ist die USB-Seriellverbindung zum PC, während Serial1 eine echte Hardware-UART auf Pins ist. Das ist ein großer Vorteil gegenüber Boards, bei denen die einzige Hardware-Seriellschnittstelle mit dem USB-Interface gekoppelt ist. Arduino dokumentiert diese Besonderheit beim Leonardo und ATmega32U4-Boards klar: Arduino Leonardo (Hardware-Dokumentation). Für Serial1 gilt außerdem die Standard-Serial-API (begin, read, write usw.), wie in der Referenz beschrieben: Arduino Serial-Referenz (API-Grundlagen).

• Serial (USB): Für Debugging, Log-Ausgaben, PC-Kommunikation.
• Serial1 (Pins): Für Board-zu-Board, Module, externe UART-Geräte.
• Parallel nutzbar: Sie können Debug über USB laufen lassen und gleichzeitig Seriell1 für interne Kommunikation verwenden.

Pinbelegung und Verdrahtung: So verbinden Sie zwei Leonardos korrekt

Seriell1 arbeitet beim Leonardo über die Pins TX1 und RX1. Entscheidend ist die Kreuzung: TX des einen Boards geht auf RX des anderen und umgekehrt. Zusätzlich müssen Sie zwingend die Masse (GND) verbinden, damit beide Boards ein gemeinsames Bezugspotenzial haben.

• Leonardo A TX1 → Leonardo B RX1
• Leonardo A RX1 → Leonardo B TX1
• GND ↔ GND

In typischen 5-V-Leonardo-Setups sind die Pegel kompatibel. Wenn Sie jedoch externe Module oder gemischte 3,3-V/5-V-Systeme anbinden, sollten Sie Pegelanpassung (Level Shifting) prüfen. Eine saubere Masseführung ist in jedem Fall Pflicht, sonst sind „Geisterzeichen“ und instabile Verbindungen sehr wahrscheinlich.

Baudrate wählen: Geschwindigkeit, Stabilität und Puffer im Blick behalten

Die Baudrate bestimmt, wie schnell Sie Daten übertragen. Für viele Projekte reichen 9600 bis 115200 Baud. Höhere Raten funktionieren oft ebenfalls, erhöhen aber die Anforderungen an Leitungsführung, Störsicherheit und saubere Software. Für die Konfiguration nutzen Sie Serial1.begin(baudrate). Die grundlegende Nutzung serieller Schnittstellen wird in der Arduino-Referenz erläutert: Arduino Serial-API.

Übertragungsrate realistisch einschätzen

Viele unterschätzen den Protokoll-Overhead. Bei klassischer UART-Konfiguration (8N1) werden pro Nutzbyte 10 Bit übertragen (1 Startbit, 8 Datenbits, 1 Stopbit). Daraus ergibt sich eine grobe Nutzdatenrate:

$\mathrm{BytesProSekunde}\approx \frac{\mathrm{Baud}}{10}$

Bei 115200 Baud sind das näherungsweise 11520 Byte/s. Wenn Sie zusätzlich Header, Checksummen, Delimiter und Wiederholungen verwenden, sinkt die effektive Nutzrate weiter. Für Steuerdaten (Zustände, Events) ist das meist völlig ausreichend; für große Datenmengen (z. B. Pixelstreams) sollten Sie die Architektur überdenken.

Topologien: Punkt-zu-Punkt, Stern oder Bus?

Seriell1 ist in der Standardform eine Punkt-zu-Punkt-Verbindung. Sobald Sie „mehrere Leonardos“ verbinden möchten, stellt sich die Frage nach der Topologie. Drei Modelle sind in der Praxis häufig:

• Punkt-zu-Punkt (2 Boards): Einfach, robust, ideal für Master/Slave.
• Stern (1 Master, mehrere Slaves): Master hat für jeden Slave eine eigene serielle Verbindung – beim Leonardo nur begrenzt möglich, weil er nur eine Hardware-UART hat (weitere Ports müssten über SoftwareSerial oder externe UARTs realisiert werden).
• Bus mit Treiber (RS-485): Mehrere Teilnehmer an einem gemeinsamen Leitungsbus, adressiert über Protokoll; erfordert einen RS-485-Transceiver pro Board.

Für mehr als zwei Leonardos ist RS-485 oft die professionellste Lösung, weil sie eine echte Mehrpunktleitung ermöglicht, robust gegen Störungen ist und längere Kabel zulässt. Wenn Sie hingegen nur zwei Module koppeln (z. B. „Input-Board“ und „LED/HID-Board“), bleibt Punkt-zu-Punkt über Serial1 meist die beste Wahl.

Protokoll statt „Plain Text“: Warum Struktur wichtiger ist als Komfort

Viele Projekte starten mit dem Senden von Textzeilen („CMD:VALUEn“). Das ist okay für Debugging, wird aber schnell fehleranfällig, wenn das System wächst. Besser ist ein einfaches, klar definiertes Protokoll: feste Rahmen, eindeutige Start-/Endmarken, Längenfeld, Prüfsumme und Adressierung (falls mehrere Knoten). Das macht die Kommunikation reproduzierbar und erleichtert Fehlersuche.

• Framing: Wie erkennen Sie Paketgrenzen, wenn Bytes verloren gehen?
• Länge: Wie viele Bytes gehören zum Paket?
• Typ: Welcher Nachrichtentyp ist das (Event, Status, Heartbeat)?
• Integrität: Wie erkennen Sie Bitfehler (Checksum/CRC)?

Ein pragmatisches Paketformat

Für viele DIY-Projekte reicht ein kompaktes Binärformat, zum Beispiel:

• Startbyte: 0xAA
• Adresse: 1 Byte (Slave-ID)
• Typ: 1 Byte (z. B. 0x01 Event, 0x02 Status)
• Länge: 1 Byte (Payload-Länge)
• Payload: N Bytes
• Checksum: 1 Byte (z. B. XOR oder Summe modulo 256)

So können Sie bei Datenmüll im Stream relativ schnell wieder synchronisieren, weil Sie auf das Startbyte warten und dann anhand der Länge genau wissen, wie viele Bytes folgen.

Flow Control und Buffer: Warum Nachrichten verloren gehen können

UART wirkt auf den ersten Blick simpel: schreiben, lesen, fertig. In Wirklichkeit arbeiten Mikrocontroller mit Empfangspuffern. Wenn der Empfänger nicht schnell genug liest, läuft der Puffer voll und Bytes gehen verloren. Das passiert besonders dann, wenn Sie im Code blockierende Funktionen nutzen (lange Delays, aufwendige LED-Updates, komplexe Berechnungen) oder wenn Sie zu große Pakete ohne Pausen senden.

• Kurze, häufige Pakete: Besser als seltene, sehr große Pakete.
• Nicht blockieren: Kein langes Warten im Loop, sondern Zustandsautomaten nutzen.
• Backpressure: Empfänger kann bestätigen (ACK), Sender wartet vor dem nächsten Paket.

Ein simples ACK/NACK-System kann die Zuverlässigkeit drastisch erhöhen: Sender verschickt Paket, Empfänger prüft Checksum und antwortet mit ACK. Kommt kein ACK, sendet der Sender erneut. Das ist besonders nützlich, wenn Ihre Verbindung in einem störbehafteten Setup läuft (lange Leitungen, gemeinsame Versorgung mit LEDs/Motoren).

Synchronisation: Heartbeat, Timeout und Wiederanlauf

Bei modularen Systemen ist eine häufige Realität: Ein Board startet neu, ein Kabel sitzt locker, ein USB-Port liefert kurzzeitig zu wenig Spannung. Wenn Ihr Kommunikationsprotokoll diese Fälle nicht abfängt, wirkt das System „instabil“. Ein Heartbeat-Mechanismus hilft: Der Slave sendet periodisch ein Lebenszeichen oder der Master fragt periodisch ab. Bleibt der Heartbeat aus, kann der Master in einen sicheren Zustand wechseln (z. B. LEDs auf neutral, Eingaben ignorieren, Reconnect versuchen).

Timeout logisch definieren

Ein Timeout basiert auf der Zeit seit der letzten gültigen Nachricht. Formal:

$\text{Verbindung ok, wenn }t–t_{\mathrm{lastMsg}}<T$

Mit T als Timeout-Grenze (z. B. 500 ms oder 2000 ms). Der passende Wert hängt von Ihrer Update-Rate ab. Wer alle 50 ms einen Status sendet, kann ein kleines Timeout wählen; wer nur bei Events sendet, sollte Heartbeats ergänzen.

Praxisarchitektur: Rollenverteilung zwischen mehreren Leonardos

Damit „Mehrere Leonardos verbinden“ einen echten Nutzen bringt, ist eine klare Rollenverteilung entscheidend. Typische sinnvolle Aufteilungen sind:

• Input-Leonardo: Liest Buttons, Encoder, Potis, entprellt und sendet Events.
• Output-Leonardo: Steuert WS2812B/Displays und setzt Statusanzeigen, ggf. mit aufwendigen Animationen.
• HID-Leonardo: Sendet Tastatur-/Joystick-HID zum PC und nimmt Events von Input entgegen.

Gerade wenn WS2812B eingesetzt werden, kann das LED-Board zeitweise Interrupts blockieren und damit Encoder-Auswertung stören. Eine Trennung in ein Input-Board (saubere Interrupt-Logik) und ein LED-Board (Animationen) kann die Bedienqualität massiv verbessern.

Leitungen, Störungen und Reichweite: Wann UART an Grenzen kommt

Eine direkte UART-Verbindung (Serial1) ist für kurze Distanzen im gleichen Gehäuse oder auf dem gleichen Panel ideal. Für längere Leitungen steigt die Störanfälligkeit, weil UART typischerweise single-ended arbeitet. In solchen Fällen ist ein differenzielles System wie RS-485 empfehlenswert. Wenn Sie im Gehäuse bleiben, helfen oft schon diese Maßnahmen:

• GND sauber führen: Möglichst niederohmig, keine „dünnen“ Massen als Flaschenhals.
• TX/RX verdrillen: Mit GND oder als Paar (je nach Aufbau) zur Reduktion von Einstreuung.
• Kurze Leitungen: Reduziert Reflexionen und EMV-Probleme.
• Getrennte Versorgung für Lasten: LEDs/Motoren nicht direkt aus derselben schwachen Quelle speisen.

Debugging ohne Chaos: Serial (USB) parallel zu Serial1 nutzen

Ein großer Vorteil am Leonardo ist, dass Sie Debug-Ausgaben über USB-Serial laufen lassen können, während die interne Kommunikation über Serial1 läuft. So können Sie Protokollzustände, Paketcounts, Fehlerquoten und Zeitouts beobachten, ohne die Verbindung zu stören. Grundlagen zur seriellen Kommunikation (Read/Write/Available) finden Sie in der Arduino-Referenz: Arduino Serial-Referenz.

• Logging-Kanäle trennen: Serial für Logs, Serial1 für internen Bus.
• Binary nicht in Text mischen: Entweder klar getrennt oder klar gekapselt, sonst wird Debug unlesbar.
• Zähler einbauen: Pakete gesendet/empfangen, Checksummenfehler, Retries.

Typische Fehlerbilder und schnelle Gegenmaßnahmen

• Nur Hieroglyphen im Empfang: Baudraten stimmen nicht überein oder Masse fehlt.
• Gelegentliche Aussetzer: Puffer läuft voll, zu große Pakete, blockierende Codeabschnitte.
• Verbindung „hängt“ nach Reset eines Boards: Kein Re-Sync/Framing, fehlender Heartbeat, keine Paketgrenzen.
• Falsche Datenzuordnung: Kein Adressfeld oder keine Nachrichtentypen – Events werden verwechselt.
• Instabil bei LED-Effekten: Interrupt-Blockaden durch LED-Timing; Aufgaben trennen oder Update-Rate reduzieren.

Kompatible Erweiterungen: Wenn Seriell1 nicht reicht

Wenn Sie mehr als zwei Leonardos verbinden möchten und trotzdem bei serieller Kommunikation bleiben wollen, gibt es praktikable Erweiterungen:

• RS-485-Bus: Mehrpunktfähig, robust, für längere Leitungen geeignet.
• Externe UART-Expander: Zusätzliche serielle Ports über I2C/SPI (aufwendiger, aber möglich).
• I2C als Bus: Für kurze Distanzen und mehrere Slaves – erfordert aber anderes Protokolldesign und Adressmanagement.

Für reine Leonardo-zu-Leonardo-Verbindungen im gleichen Gehäuse bleibt Serial1 dennoch oft der sweet spot: einfach, schnell, stabil – wenn Protokoll und Stromversorgung stimmen.

Outbound-Links für verlässliche Vertiefung

• Arduino Leonardo: Pinout, USB-Details und Besonderheiten von Serial/Serial1
• Arduino Serial-Referenz: begin(), available(), read(), write()
• Arduino Serial.begin(): Baudrate und serielle Initialisierung
• UART-Grundlagen: Funktionsprinzip und Rahmenformat (Start/Stopbits)
• RS-485: Mehrpunktfähige serielle Kommunikation für längere Strecken

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.