Mehrere PICs vernetzen: Eigene Kommunikationsprotokolle entwickeln

Mehrere PICs vernetzen: Eigene Kommunikationsprotokolle entwickeln ist ein Schritt, der viele Mikrocontroller-Projekte von „ein Gerät macht alles“ zu einer skalierbaren, wartbaren Systemarchitektur weiterentwickelt. Statt einen einzigen PIC mit immer mehr Aufgaben zu überladen, verteilen Sie Funktionen: Ein Controller übernimmt Sensorik, ein anderer Motorsteuerung, ein dritter eine Anzeige oder Netzwerkschnittstelle. Damit das zuverlässig funktioniert, brauchen Sie ein Kommunikationsprotokoll, das zu Ihren Anforderungen passt: Datenrate, Kabellänge, Störumgebung, Anzahl Teilnehmer, Echtzeitverhalten und Fehlertoleranz. Wer hier planlos „ein paar Bytes über UART“ schickt, landet schnell in Situationen, die schwer zu debuggen sind: unvollständige Frames, verlorene Nachrichten, Deadlocks, Timingprobleme oder schwer nachvollziehbare Zustände nach einem Reset. Ein gutes eigenes Protokoll muss nicht komplex sein – es muss vor allem klar definiert, robust implementiert und sauber dokumentiert sein. In diesem Artikel lernen Sie, wie Sie mehrere PICs sinnvoll vernetzen, welche physikalischen Schnittstellen sich eignen (UART, RS485, I2C, SPI, CAN-ähnliche Ansätze), wie Sie ein Frame-Format designen, Fehler erkennen und Wiederholungen steuern und wie Sie mit Zustandsautomaten, Puffern und Teststrategien eine professionelle Kommunikation aufbauen, die auch nach Monaten noch verständlich ist.

Warum überhaupt mehrere PICs? Typische Systemarchitekturen

Die Vernetzung mehrerer Mikrocontroller ist nicht nur eine Frage von „mehr Leistung“, sondern oft von Struktur. Häufige Motive sind:

• Modularität: Sensorboard, Aktorboard und UI-Board können separat entwickelt, getestet und getauscht werden.
• EMV und Layout: Analoge Sensorik lässt sich räumlich vom „lauten“ Motor- oder PWM-Teil trennen.
• Echtzeit: Zeitkritische Regelungen laufen unabhängig von langsamen Aufgaben wie Display-Updates.
• Skalierbarkeit: Neue Funktionen werden als neues Modul ergänzt, statt den Hauptcontroller zu überfrachten.
• Zuverlässigkeit: Fehler in einem Modul müssen nicht das gesamte System blockieren.

Die wichtigste Entscheidung: Welche Leitungsebene passt zu Ihrem Projekt?

Ein gutes Protokoll beginnt nicht im Code, sondern bei der physikalischen Schnittstelle. Sie bestimmt, wie viele Teilnehmer sinnvoll sind, wie störfest die Verbindung ist und wie komplex die Hardware wird.

• UART (TTL): einfach, günstig, gut für kurze Strecken und Punkt-zu-Punkt.
• RS485 (Differenziell): sehr robust, gut für längere Strecken und mehrere Teilnehmer (Bus), benötigt Transceiver.
• I2C: zwei Leitungen, mehrere Teilnehmer möglich, gut auf kurzen Strecken auf einer Platine, empfindlicher bei langen Kabeln.
• SPI: sehr schnell, aber typischerweise Master/Slave mit separatem Chip-Select pro Slave, eher für kurze Strecken.
• CAN: extrem robust und busfähig, aber mehr Protokoll-/Hardwareaufwand; oft besser als „selbst erfinden“.

Wenn Sie bewusst „eigene Kommunikationsprotokolle entwickeln“ möchten, ist RS485 eine besonders dankbare Basis: Busfähigkeit, Störfestigkeit, einfache UART-Ankopplung und klare Topologie. Für reine Platinenkommunikation kann I2C ausreichend sein, sofern Sie die Grenzen kennen.

Anforderungen sauber definieren: Der Protokoll-Lastenheft-Ansatz

Bevor Sie ein Byte senden, definieren Sie die Anforderungen. Das spart später Debugging-Zeit und verhindert, dass aus einem kleinen Protokoll ein unübersichtliches Sammelsurium wird.

• Teilnehmerzahl: Wie viele PICs hängen am Bus? Gibt es ein Gateway?
• Topologie: Punkt-zu-Punkt, Bus, Stern (meist vermeiden), Daisy-Chain.
• Datenrate und Latenz: Wie schnell müssen Werte ankommen? Ist „best effort“ ok?
• Nachrichtenmodell: Polling (Master fragt ab) oder Event-basiert (Slaves melden)?
• Fehlertoleranz: Was passiert bei Paketverlust, Reset, Kabelbruch, Störungen?
• Sicherheit: Reicht Integrität (CRC) oder benötigen Sie Authentizität (Token/Signatur)?

Master/Slave oder Multi-Master? Ein Architekturentscheid, der alles beeinflusst

Viele stabile Systeme wählen bewusst Master/Slave, weil es die Buszugriffslogik drastisch vereinfacht. Ein Master bestimmt, wer wann senden darf. Multi-Master kann funktionieren, erhöht aber Aufwand (Arbitration, Kollisionen, Backoff-Mechanismen).

• Master/Slave: einfacher, deterministisch, gut für RS485- und UART-Busse.
• Token-Passing: Multi-Master-ähnlich, aber kontrolliert; ein Token erlaubt Senden.
• CSMA/Backoff: wie „vereinfachtes Ethernet“; auf Microcontrollern oft fehleranfälliger als gedacht.

Frame-Design: So wird aus Bytes ein robustes Protokoll

Ein eigenes Protokoll braucht ein eindeutiges Frame-Format. Das Ziel: Der Empfänger kann auch bei Rauschen, verlorenen Bytes oder Neustarts wieder synchron werden, Frames eindeutig erkennen und Fehler zuverlässig feststellen.

Bewährte Felder in einem seriellen Frame

• Startmarke (Preamble/SOF): z. B. ein spezielles Byte oder eine Bytefolge zur Synchronisation.
• Länge: Anzahl Nutzdatenbytes, damit der Empfänger weiß, wann der Frame endet.
• Adresse(n): Zieladresse und ggf. Quelladresse, wenn mehrere Teilnehmer existieren.
• Typ/Command: Kennzeichnet Nachrichtentyp (Status, Messwert, Konfig, Ack, Fehler).
• Payload: Nutzdaten (Sensorwerte, Zustände, Parameter).
• Prüfsumme/CRC: Fehlererkennung über den Frame.

Beispiel: Minimaler Frame als Konzept (ohne starre Vorgabe)

Ein praxistauglicher Minimalframe könnte konzeptionell so aussehen: SOF | LEN | DST | SRC | TYPE | PAYLOAD… | CRC. Die exakten Feldbreiten hängen von Ihrem Bedarf ab: Adressen als 1 Byte reichen oft bis 255 Knoten, TYPE als 1 Byte erlaubt 256 Nachrichtentypen.

Synchronisation: Startbyte, Längenfeld oder Delimiter?

Sie müssen entscheiden, wie Frames voneinander getrennt werden. Drei gängige Strategien:

• Startbyte + Länge: sehr verbreitet, gut implementierbar, robust, wenn Startbyte eindeutig ist.
• Delimiter (z. B. n): für ASCII-Protokolle; einfach, aber anfälliger für Binärdaten.
• Byte Stuffing (SLIP/COBS): erlaubt beliebige Binärdaten ohne Verwechslungsgefahr mit Start/Ende.

Für binäre Protokolle mit hoher Robustheit ist Byte-Stuffing oft die beste Wahl, weil Sie damit klare Frame-Grenzen erhalten, ohne dass Nutzdaten „verbotene“ Bytes vermeiden müssen. Für Einsteigerprojekte ist Start+Länge ein guter Kompromiss.

Fehlererkennung: Warum CRC in seriellen Netzen Gold wert ist

Eine einfache XOR-Prüfsumme erkennt nicht alle Fehler. In Störumgebungen (Motoren, Relais, lange Leitungen) ist eine CRC deutlich zuverlässiger. Sie müssen keine „perfekte“ CRC erfinden – nutzen Sie eine bekannte CRC-Variante (z. B. CRC-8 oder CRC-16), die gut dokumentiert ist.

CRC-Idee als Berechnungsmodell

Konzeptionell lässt sich eine CRC als Rest einer Polynomdivision beschreiben. Für die Praxis reicht die Darstellung: CRC wird über alle Framebytes (ohne CRC-Feld) berechnet und am Ende angehängt. Beim Empfänger wird erneut berechnet und verglichen. Als symbolisches Modell:

$\mathrm{CRC}=f\left(\mathrm{FrameBytes}\right)$

Wichtig ist weniger die Mathematik als die Disziplin: gleiche Parameter (Polynom, Initialwert, XOR-Out, Bitreflexion) auf allen Geräten.

Als Hintergrund zur CRC-Logik und Parametrisierung ist die CRC Catalogue (reveng) eine sehr nützliche Referenz, um Varianten eindeutig zu identifizieren.

Zustandsautomaten statt „if-Spaghetti“: Parser robust implementieren

Der Frame-Parser ist das Herzstück. Viele Fehler entstehen, wenn Empfangsdaten direkt „on the fly“ ausgewertet werden, ohne klaren Zustand. Ein Zustandsautomat (State Machine) liest Byte für Byte und wechselt kontrolliert zwischen Zuständen wie: WAIT_SOF → READ_LEN → READ_HEADER → READ_PAYLOAD → READ_CRC → VALIDATE → DISPATCH.

• Resync-Fähigkeit: Bei Fehlern zurück zu WAIT_SOF, nicht „weiter hoffen“.
• Timeouts: Wenn ein Frame nicht fertig wird, verwerfen und neu synchronisieren.
• Längenprüfung: LEN darf nie größer sein als Ihr Buffer.
• CRC-Prüfung: Erst nach erfolgreicher CRC Nachricht verarbeiten.

Puffer und Interrupts: Empfang ohne Datenverlust

Wenn mehrere PICs kommunizieren, kommt es häufig zu Bursts. Ein stabiler Empfang benötigt daher Pufferung. Bewährt sind Ringbuffer, die im RX-Interrupt befüllt werden, während die Hauptlogik später Frames daraus baut.

• RX-Interrupt: jedes Byte sofort in einen Ringbuffer schreiben.
• Parser im Main Loop: Bytes entnehmen, Zustandsautomat laufen lassen.
• Überlaufbehandlung: Wenn Buffer voll: Zähler erhöhen, ggf. Frames verwerfen, Fehlerstatus setzen.

Buffergröße pragmatisch dimensionieren

Damit der Ringbuffer nicht überläuft, muss er Bursts aufnehmen können. Ein einfaches Kapazitätsmodell:

$N\ge R\mathrm{\_byte}\cdot t\mathrm{\_block}$

Hier ist R_byte die durchschnittliche Byte-Rate und t_block die maximale Zeit, in der Ihre Firmware keine RX-Bytes verarbeitet (z. B. durch andere zeitkritische Abschnitte). Das Modell hilft, die Größenordnung realistisch zu wählen.

Buszugriff bei mehreren Teilnehmern: Senden ohne Kollisionen

Wenn Sie einen Bus (z. B. RS485) mit mehreren Teilnehmern haben, müssen Sie klären, wer wann senden darf. Für robuste Systeme gibt es drei bewährte Ansätze:

• Master Polling: Master fragt nacheinander Slaves ab; Slaves senden nur als Antwort.
• Zeitfenster (TDMA-light): feste Slots pro Teilnehmer; erfordert stabile Zeitbasis.
• Token: ein Token wird weitergereicht; nur Tokeninhaber darf senden.

Für Einsteiger und stabile Systeme ist Master Polling oft unschlagbar, weil es Kollisionen praktisch ausschließt. Event-basierte Meldungen sind dennoch möglich, indem Slaves Ereignisse puffern und bei nächster Anfrage melden.

Acknowledgements und Retries: Wann braucht man Quittungen?

Ein typischer Fehler ist es, „immer ACK“ zu machen, ohne Regeln. Ein gutes Protokoll definiert klar:

• Welche Nachrichten sind kritisch? z. B. Schaltbefehle oder Konfigänderungen.
• Welche dürfen verloren gehen? z. B. regelmäßige Messwerte, die gleich wiederkommen.
• Retry-Strategie: wie oft wird wiederholt, in welchen Abständen, mit welchem Backoff?
• Sequenznummern: verhindern doppelte Ausführung bei wiederholten Frames.

Einfaches Retry-Modell

Wenn ein Sender bis zur Zeit t kein ACK erhält, wird erneut gesendet. Die Wartezeit kann konstant oder ansteigend (Backoff) sein. Ein einfaches lineares Backoff-Modell:

$T\mathrm{\_wait}=T\mathrm{\_base}+k\cdot n$

n ist die Anzahl der bisherigen Retries. In der Praxis ist es oft sinnvoll, nach wenigen Versuchen aufzugeben und einen Fehlerstatus zu melden, statt den Bus dauerhaft zu blockieren.

Datenmodell und Kompatibilität: Versionierung gehört ins Protokoll

Eigene Protokolle scheitern häufig nicht technisch, sondern organisatorisch: Nach einer Firmwareänderung verstehen sich Module plötzlich nicht mehr. Deshalb ist Versionierung wichtig, selbst im DIY-Kontext.

• Protokollversion im Header: erlaubt kompatible Weiterentwicklung.
• Capabilities-Handshake: Module können beim Start melden, was sie unterstützen.
• Abwärtskompatibilität: alte Felder nicht „umdeuten“, sondern neue Typen hinzufügen.
• Dokumentation als Wahrheit: Ein Protokoll ohne Spezifikation ist langfristig nicht wartbar.

ASCII vs. Binär: Was ist besser für PIC-Netzwerke?

ASCII-Protokolle sind hervorragend zum Debuggen: Sie können im Terminal mitlesen und testen. Binärprotokolle sind effizienter, schneller und leichter eindeutig zu prüfen (CRC, feste Längen). In vielen Projekten ist eine Hybridstrategie sinnvoll.

• ASCII: gut für Konsole, Debug, einfache Befehle; mehr Overhead, Parsingaufwand.
• Binär: effizient, robust, klare Frames; Debugging braucht Tools/Decoder.
• Hybrid: Debug über ASCII, Betrieb über Binär oder beides parallel auf verschiedenen Schnittstellen.

Testen wie im professionellen Umfeld: Simulation, Fuzzing, Log-Decoder

Wenn Sie ein eigenes Protokoll entwickeln, ist Testbarkeit ein Qualitätsmerkmal. Sie müssen nicht „Enterprise“-Tools einsetzen, aber ein paar Prinzipien zahlen sich sofort aus:

• Referenz-Decoder am PC: Ein kleines Tool/Script, das Frames dekodiert und validiert.
• Replay-Tests: Aufgezeichnete Busdaten wieder einspeisen und prüfen, ob die Firmware stabil reagiert.
• Fuzzing-light: absichtlich fehlerhafte Frames (falsche Länge, CRC, zufällige Bytes) senden und prüfen, ob das System sauber resynchronisiert.
• Logging: Fehlerzähler (CRC-Fails, Timeouts, Overflows) als Diagnosewerte verfügbar machen.

Dokumentation des Protokolls: Klarheit statt Bauchgefühl

Ein robustes Protokoll ist immer auch ein Dokument. Selbst wenn Sie allein entwickeln, sollten Sie mindestens festhalten:

• Physikalische Ebene: UART/RS485/I2C, Baudrate/Timing, Pegel, Terminierung.
• Frameformat: Feldreihenfolge, Längen, Endianness, erlaubte Werte.
• Nachrichtentypen: TYPE-Liste, Payload-Struktur pro Typ.
• Fehlerbehandlung: Timeouts, Retries, Buszugriffsregeln, Resetverhalten.
• Versionierung: Protokollversion, Migrationsregeln.

Als Inspiration für strukturierte Protokoll- und Schnittstellendokumentation kann die formale Denkweise in Standards helfen, etwa bei RFC-Dokumenten (nicht um zu kopieren, sondern um Klarheit und Eindeutigkeit zu übernehmen).

Empfohlene Ausgangspunkte und Informationsquellen

• CRC-Varianten eindeutig vergleichen: CRC Catalogue
• TCP/IP- und Protokolldenken (für klare Spezifikation): RFC Editor
• Microchip Datenblätter und Peripheriedetails (UART/SPI/I2C): Microchip Dokumentensuche
• Entwicklungsumgebung: MPLAB X IDE und MPLAB XC8

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.