Mehrere PICs vernetzen: Eigene Kommunikationsprotokolle entwickeln

Mehrere PICs vernetzen ist oft der nächste logische Schritt, sobald ein einzelner Mikrocontroller nicht mehr ausreicht: zu viele Ein- und Ausgänge, getrennte Module (Sensorik, Aktorik, UI), räumlich verteilte Baugruppen oder der Wunsch nach besserer Wartbarkeit. In der Praxis ist die Hardware-Verbindung meist schnell hergestellt – doch die eigentliche Qualität entscheidet sich im Kommunikationsprotokoll. Wer „einfach Bytes schickt“, erlebt früher oder später typische Probleme: verlorene Nachrichten, doppelte Befehle, unklare Zustände nach Reset, sporadische Datenfehler durch Störungen oder Timing-Konflikte, wenn mehrere Knoten gleichzeitig senden. Ein eigenes Protokoll muss nicht kompliziert sein, aber es sollte bewusst entworfen werden: mit klaren Frames, eindeutiger Adressierung, Versionierung, Fehlererkennung und einer Strategie für Timeouts sowie Wiederholungen. Dieser Artikel zeigt, wie Sie ein robustes Kommunikationssystem zwischen mehreren PIC-Mikrocontrollern planen und umsetzen – unabhängig davon, ob Sie UART, RS485, I²C, SPI oder CAN als physikalische Basis verwenden. Der Fokus liegt auf einem pragmatischen Vorgehen, das Einsteiger nicht überfordert, aber auch für fortgeschrittene Projekte skaliert.

Warum ein eigenes Protokoll sinnvoll ist – und wann Sie lieber Standards nutzen

Ein eigenes Protokoll ist dann sinnvoll, wenn Ihre Anforderungen klar und begrenzt sind: wenige Knoten, bekannte Nachrichtenarten, überschaubare Datenmengen und kontrollierte Umgebung. Sie profitieren von geringerem Overhead, maximaler Anpassbarkeit und einfacher Implementierung auf kleinen PICs. Ein Standard lohnt sich dagegen, wenn Interoperabilität, Diagnosewerkzeuge oder langfristige Erweiterbarkeit im Vordergrund stehen.

• Eigenes Protokoll: minimaler Overhead, perfekt zugeschnitten, sehr gut für geschlossene Systeme.
• Standardprotokolle: weniger Eigenentwicklung, vorhandene Tools, klar definierte Spezifikationen (z. B. Modbus RTU über RS485).

Wenn Sie einen etablierten Einstieg für Modbus suchen, ist die offizielle Website eine gute Referenz: Modbus-Organisation und Spezifikationsübersicht. Auch wenn Sie am Ende ein eigenes Protokoll wählen, lohnt sich der Blick auf Modbus als „Benchmark“ für Frame-Aufbau, Adressierung und CRC.

Die physikalische Basis wählen: UART, RS485, I²C, SPI, CAN im Vergleich

Ihr Protokoll sitzt nie im luftleeren Raum. Die physikalische Verbindung bestimmt Reichweite, Störfestigkeit, Topologie und maximale Datenrate. Für mehrere PICs sind fünf Optionen besonders verbreitet:

• UART (Punkt-zu-Punkt): einfach, gut für kurze Strecken zwischen zwei Knoten; für mehrere Knoten nur mit zusätzlicher Buslogik sinnvoll.
• RS485 (UART + Transceiver): robust für längere Leitungen, Multi-Drop-Bus (mehrere Teilnehmer), sehr beliebt in Industrieumgebungen.
• I²C: gut auf einem Board, kurze Distanzen, mehrere Teilnehmer, aber empfindlicher gegenüber Leitungskapazität und Störungen.
• SPI: schnell, aber typischerweise Punkt-zu-Punkt bzw. Master-Slave mit separaten Chip-Selects; für „verteilte“ Systeme eher ungeeignet.
• CAN: sehr robust, Multi-Master, Priorisierung über IDs; höherer Einstieg, dafür automotive-/industrieerprobt.

Für die Entscheidung hilft ein nüchternes Kriterienset: benötigte Kabellänge, EMV-Umgebung, Anzahl Knoten, echte Multi-Master-Anforderung, gewünschte Diagnosefähigkeit und Budget für zusätzliche Transceiver.

Praxisempfehlung für typische PIC-Projekte

• Mehrere PICs auf einer Platine: I²C oder SPI (wenn klare Master-Slave-Struktur).
• Mehrere PICs über Kabel (bis viele Meter): RS485 ist oft der beste Kompromiss.
• Automotive/EMV-intensiv, viele Knoten: CAN ist häufig die robusteste Wahl.

Protokollanforderungen definieren: Ohne Lastenheft kein sauberes Design

Bevor Sie ein einziges Byte formatieren, definieren Sie Ihre Anforderungen schriftlich – kurz, aber konkret. Das spart später viel Zeit und verhindert „Protokoll-Wildwuchs“.

• Topologie: Wer ist Master, wer ist Slave, oder ist es Multi-Master?
• Adressierung: Wie viele Knoten, feste IDs oder dynamisch?
• Datenvolumen: Wie viele Nachrichten pro Sekunde, wie groß sind Payloads?
• Latenz: Welche Reaktionszeiten sind erforderlich (z. B. < 10 ms)?
• Zuverlässigkeit: Reicht „Best Effort“ oder brauchen Sie bestätigte Zustellung (ACK)?
• Fehlerszenarien: Was passiert bei Reset eines Knotens, Kabelbruch, Störung, Bus-Blockade?
• Versionierung: Wie erweitern Sie das Protokoll später abwärtskompatibel?

Diese Punkte bestimmen, ob Sie z. B. eine reine Befehls-/Antwortstruktur bauen oder ein ereignisgetriebenes Publish/Subscribe-Prinzip.

Frame-Aufbau: So wird aus „Bytes“ ein robustes Telegramm

Ein gutes Frame-Format ist eindeutig, leicht zu parsen und robust gegen Störungen. Für PIC-Projekte hat sich ein klarer Aufbau bewährt:

• Startmarke (SOF): hilft beim Resynchronisieren, z. B. 0x7E.
• Adresse: Ziel (und optional Quelle).
• Typ/Command: Nachrichtentyp, Befehl oder Service-ID.
• Länge: Payload-Länge, um variable Daten zu erlauben.
• Payload: Nutzdaten.
• Prüfsumme/CRC: Fehlererkennung.
• Endmarke (optional): bei manchen Designs hilfreich, oft aber nicht nötig.

Warum eine Längenangabe fast immer lohnt

Mit einer Länge können Sie Nachrichten flexibel erweitern, ohne neue Framing-Regeln zu erfinden. Parser werden stabiler: Sie lesen exakt so viele Bytes, wie angekündigt, und können bei Timeouts sauber abbrechen.

Byte-Stuffing: Wenn Startmarken im Payload vorkommen

Wenn Ihre Startmarke (z. B. 0x7E) im Payload auftreten kann, brauchen Sie eine Escaping-Strategie. Ein klassischer Ansatz ist „Byte Stuffing“: Ein Escape-Byte (z. B. 0x7D) kündigt an, dass das nächste Byte transformiert wurde. Das Konzept ist u. a. aus HDLC-ähnlichen Verfahren bekannt und gut geeignet für UART/RS485-Frames.

Adressierung und Rollen: Master-Slave, Token, Multi-Master

Die meisten Systeme mit mehreren PICs sind faktisch nicht Multi-Master, auch wenn „alle senden können“ verlockend klingt. Multi-Master braucht Busarbitration oder ein Token, sonst entstehen Kollisionen.

• Master-Slave: Ein Knoten fragt ab oder verteilt Befehle; Slaves antworten nur auf Anfrage. Sehr stabil und einfach.
• Master mit Events: Slaves dürfen Ereignisse melden, aber nur in definierten Zeitfenstern oder über separate Leitung.
• Token-Passing: Ein Token wandert; nur der Tokenhalter darf senden. Gut für RS485, wenn mehrere aktiv senden müssen.
• CAN (Multi-Master nativ): Arbitration ist im Bus integriert; Protokoll-Logik kann schlanker sein.

Wenn Sie RS485 nutzen, ist Master-Slave oft die stabilste Lösung: ein fester Polling-Zyklus mit klaren Timeouts. Multi-Master ist möglich, aber deutlich anspruchsvoller.

Fehlererkennung: Checksumme oder CRC – was ist sinnvoll?

Für kurze Nachrichten und „saubere“ Umgebungen kann eine einfache Checksumme ausreichen. Für robuste Systeme, längere Leitungen oder EMV-intensiven Betrieb ist CRC die bessere Wahl. CRC ist nicht „magisch“, aber deutlich stärker gegen Mehrbitfehler und typische Störmuster.

Einfache Checksumme: schnell, aber begrenzte Sicherheit

Eine Summen-Checksumme ist leicht zu berechnen, erkennt aber bestimmte Fehlerbilder schlecht (z. B. Byte-Tausch). Das Prinzip:

$\mathrm{checksum}=\left(\sum _{i=0}^{n–1}{\mathrm{byte}}_i\right)mod256$

CRC16 als praxistauglicher Standard für UART/RS485

CRC16 (wie bei Modbus RTU) ist in Embedded-Systemen weit verbreitet. Wenn Sie eine bewährte Referenz wollen, ist Modbus RTU ein gutes Beispiel, weil CRC16 dort fest definiert ist: Modbus Spezifikationen (CRC16, Frame-Struktur). Sie müssen nicht „Modbus sprechen“, um dessen CRC-Ansatz als robuste Grundlage zu übernehmen.

Zuverlässigkeit: ACK, Retries, Sequenznummern und Idempotenz

Fehlererkennung allein reicht nicht. Ihr Protokoll braucht eine Strategie, was bei Fehlern passiert. Drei Konzepte sind besonders wichtig:

• ACK/NACK: Empfänger bestätigt (oder lehnt ab). Ohne ACK wissen Sie nicht, ob eine Nachricht angekommen ist.
• Timeout + Retry: Der Sender wartet maximal X Millisekunden und sendet ggf. erneut.
• Sequenznummern: verhindern doppelte Ausführung bei Retries.

Sequenznummern sind besonders wichtig, wenn ein Befehl Nebenwirkungen hat (z. B. „Relais einschalten“). Ohne Sequenznummer kann ein Retry denselben Befehl nochmals ausführen. Mit Sequenznummer kann der Empfänger erkennen: „Diese Nachricht habe ich schon verarbeitet“.

Idempotente Kommandos: Ein unterschätzter Stabilitätsfaktor

Wenn Sie Kommandos so gestalten, dass Wiederholungen nicht schaden, wird Ihr System deutlich robuster. Beispiel: Statt „toggle“ (umschalten) senden Sie „set state = ON/OFF“. Dann ist ein Retry harmlos, weil das Zielzustand-Command idempotent ist.

Timing und Bandbreite: Protokolle scheitern oft an falschen Annahmen

Viele Designs unterschätzen, wie viel Overhead entsteht: Start/Stop bei UART, Byte-Stuffing, CRC, Antwortframes, Wartezeiten. Machen Sie eine grobe Budgetrechnung, um realistische Polling-Zyklen und Latenzen zu planen.

Wenn Ihre physikalische Baudrate B beträgt (bit/s), ergibt sich ein idealer Byte-Durchsatz von:

$R\mathrm{byte}\approx \frac{B}{10}$

Der Faktor 10 ist eine typische Annäherung für 8N1-UART (1 Startbit + 8 Datenbits + 1 Stopbit). In der Praxis sinkt der nutzbare Durchsatz weiter durch Protokoll-Overhead und Wartezeiten. Diese einfache Rechnung hilft, unrealistische Erwartungen früh zu korrigieren.

Synchronisation und Reset-Verhalten: Was passiert, wenn ein Knoten neu startet?

In realen Systemen wird es Resets geben: Brown-Out, Watchdog, Firmware-Update, Steckverbinderprobleme. Ihr Protokoll muss das verkraften.

• Handshake/Hello: Nach Reset meldet sich ein Knoten mit Version und Fähigkeiten.
• Heartbeat: Periodische Lebenszeichen, um Ausfälle zu erkennen.
• Re-Sync: Mechanismus, um Frames nach Leitungsstörung wieder sauber zu finden (SOF/Timeout).
• Safe Defaults: Aktoren gehen nach Kommunikationsverlust in einen sicheren Zustand.

Gerade in Aktorik-Systemen ist „Fail-Safe“ entscheidend: Kommunikation darf nicht die einzige Sicherheitsinstanz sein.

Sicherheit im lokalen Embedded-Netz: Authentizität und Missbrauch vermeiden

Auch wenn das System „nur intern“ ist, lohnt es sich, grundlegende Sicherheitsprinzipien zu beachten. Schon einfache Maßnahmen verhindern ungewollte Steuerbefehle durch Fehlverkabelung, Störsignale oder falsche Knoten.

• Whitelist von Knoten-IDs: nur bekannte Geräte akzeptieren.
• Message Authentication (leichtgewichtig): z. B. ein einfacher Schlüssel und MAC-Tag (HMAC ist stark, aber oft zu schwer für sehr kleine PICs).
• Konfigurationsschutz: kritische Befehle nur nach „Unlock“-Sequenz zulassen.

Wenn Sie sich an etablierten Sicherheitsprinzipien orientieren möchten, bietet die OWASP-Übersicht für IoT eine gute Einordnung, welche Fehler in vernetzten Geräten typisch sind: OWASP Internet of Things Projekt.

Debugging und Testbarkeit: Protokolle müssen beobachtbar sein

Ein Protokoll, das sich nicht debuggen lässt, wird teuer. Planen Sie von Anfang an Diagnosen ein:

• Log-Frames: Fehlercodes, Statistik, Reset-Gründe.
• Counter: CRC-Fehler, Timeouts, Retries, RX-Overflows.
• Sniffer-Möglichkeit: bei RS485 z. B. passiv mithören, bei UART mit Logic Analyzer.
• Testmodus: Loopback oder Simulation von Paketen, um Parser zu prüfen.

Ein klar definierter Debug-Frame („Type = DIAG“) ist oft Gold wert, weil Sie damit Zustände aus dem Feld zurückbekommen, ohne das Protokoll zu verbiegen.

Implementierungsstrategie auf dem PIC: State Machines, Ringpuffer, klare Schichten

Auf 8-Bit-PICs ist eine robuste Implementierung weniger eine Frage der „cleveren Tricks“ als der Struktur.

• RX per Interrupt + Ringpuffer: Bytes gehen nicht verloren, Parser läuft im Main Loop.
• Parser als Zustandsautomat: SOF finden, Header sammeln, Länge lesen, Payload sammeln, CRC prüfen.
• Transport vs. Anwendung trennen: Treiber (UART/RS485) getrennt vom Protokoll (Frames) getrennt von der Anwendung (Kommandos).
• Timeouts pro Zustand: Wenn ein Frame unvollständig bleibt, sauber verwerfen und resynchronisieren.

Warum „im Interrupt parsen“ meist eine schlechte Idee ist

Interrupts sollten kurz sein. Parsing, CRC und Kommandologik kosten Zeit und erhöhen das Risiko, andere zeitkritische Aufgaben zu stören. Bewährt ist: ISR sammelt Bytes, Main Loop verarbeitet Frames.

Beispiel-Blueprint: Ein schlankes, skalierbares Frame-Format

Für viele PIC-Netzwerke (UART/RS485) funktioniert ein Format wie dieses sehr gut:

• SOF: 0x7E
• Dst: 1 Byte (Zieladresse)
• Src: 1 Byte (Quelladresse)
• Type: 1 Byte (Command/Response/Event/Diag)
• Seq: 1 Byte (Sequenznummer)
• Len: 1 Byte (Payload-Länge)
• Payload: 0..255 Bytes
• CRC16: 2 Bytes

Dieses Layout ist bewusst kompakt und trotzdem erweiterbar. Type/Versionierung können Sie später verfeinern (z. B. obere Bits für Protokollversion). Für sehr kleine Anwendungen können Sie Src oder Seq weglassen, sollten aber dann die Konsequenzen kennen (z. B. weniger Robustheit bei Retries).

Dokumentation und Versionierung: Ihr Protokoll ist ein Produkt

Ein Protokoll ohne Dokumentation ist nach wenigen Monaten kaum noch sicher erweiterbar. Halten Sie mindestens fest:

• Frame-Spezifikation: Bytepositionen, Endianness, CRC-Definition.
• Nachrichtenkatalog: Typen, IDs/Kommandos, Payload-Format, Antwortverhalten.
• Timing: Timeouts, Retry-Strategie, Polling-Raten.
• Kompatibilitätsregeln: Was passiert, wenn Versionen gemischt werden?

Für eine saubere Spezifikationskultur lohnt es sich, sich an etablierten Internet-Standards zu orientieren. Ein gutes Beispiel für das Format und die Klarheit technischer Spezifikationen sind RFC-Dokumente der IETF: RFC Editor (IETF Standards und RFCs). Sie müssen kein RFC schreiben – aber Sie können deren Struktur als Vorbild für Eindeutigkeit nutzen.

Praxis-Checkliste: Mehrere PICs vernetzen ohne typische Anfängerfehler

• Physikalik zuerst: RS485-Transceiver, Terminierung, Masseführung, EMV – bevor Sie „Protokollbugs“ suchen.
• Frame klar definieren: SOF, Länge, CRC, eindeutige Parserlogik.
• Timeouts überall: Kein Zustand darf endlos warten.
• Retries mit Sequenznummer: doppelte Ausführung vermeiden.
• Idempotente Befehle: „set state“ statt „toggle“.
• Filter und Rollen: Wer darf senden? Wer antwortet? Keine implizite Multi-Master-Annahme.
• Debug-Frames: Counter und Statusmeldungen einplanen.
• Dokumentation pflegen: Nachrichtenkatalog, Versionierung, Kompatibilitätsregeln.

Weiterführende Outbound-Links für fundierte Umsetzung

• Modbus als Referenz für serielle Protokolle (RTU/CRC/Frame-Design)
• Modbus Spezifikationen (Frame-Struktur und CRC16-Definition)
• OWASP IoT: typische Sicherheitsrisiken in vernetzten Geräten
• RFC Editor: Vorbild für klare technische Spezifikationen

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.