Ein Leitfaden für Fortgeschrittene zu Kommunikationsprotokollen in Mikrocontrollern

Wichtigste Erkenntnisse

• Die Entfernung und die Anzahl der Knoten entscheiden über die Wahl des Protokolls, lange bevor der Durchsatz eine Rolle spielt. Legen Sie daher zunächst die physikalische Schicht fest und passen Sie die Firmware anschließend daran an.
• SPI, UART, I2C und CAN tauschen jeweils eine Ressource gegen eine andere ein, und die richtige Wahl ist diejenige, deren Kosten Ihr Design verkraften kann.
• Früh festgelegte Protokollgrenzen sorgen dafür, dass ein eingebetteter Controller zwischen verschiedenen Entwicklungsumgebungen und Toolchains portierbar bleibt, anstatt ihn an eine bestimmte Platine zu binden.

Die Wahl eines Kommunikationsprotokolls für einen Mikrocontroller ist eine hardware Entscheidung, die man einmal trifft und mit der man dann über die gesamte Lebensdauer des Produkts leben muss.

Die Anzahl der Pins, die Kabellänge, die Anzahl der Knoten und die Fehlerbehandlung ändern sich alle gleichzeitig, und wenn hier Fehler auftreten, äußern sich diese in Form von sporadischen Störungen, die niemand reproduzieren kann. Ein Fahrzeug der Oberklasse verfügt heute über rund 150 elektronische Steuergeräte, bei denen es sich jeweils um Mikrocontroller handelt, die Daten austauschen müssen, ohne dass dabei auch nur ein Frame verloren geht.

SPI, UART, I2C und CAN haben sich durchgesetzt, weil jedes dieser Protokolle ein anderes Problem löst. SPI sorgt für hohen Durchsatz bei geringer Pin-Anzahl, I2C spart Pins auf Kosten der Geschwindigkeit, und CAN nutzt zusätzliche Chipfläche, um auch in einem störungsbehafteten Gehäuse zuverlässig zu funktionieren. Passen Sie das Protokoll an die tatsächlichen Einschränkungen Ihres Designs an, dann wird die darüber liegende Firmware einfacher.

So funktioniert die serielle Kommunikation in einem Mikrocontrollersystem

Bei der seriellen Kommunikation werden Daten Bit für Bit über wenige Leitungen übertragen, wobei die Bandbreite der parallelen Übertragung zugunsten der Anzahl der Pins und des Platzes auf der Platine geopfert wird. Jedes Protokoll auf einem Mikrocontroller baut auf diesem Grundprinzip auf und regelt dabei die Taktsteuerung, die Geräteauswahl und die Fehlerbehandlung.

Ein typisches Cortex-M-Bauteil verfügt über mehrere USART-Blöcke, zwei oder drei SPI-Blöcke, einige I2C-Blöcke und oft einen CAN-Controller. Diese teilen sich die Pins über einen Multiplexer, sodass das für einen Sensor gewählte Protokoll darüber entscheidet, welche Pins verfügbar bleiben.

Fünf Eigenschaften bestimmen, wie sich ein Bus verhält, sobald die Platine bestückt ist.

• Taktung, da ein synchroner Bus eine Taktleitung führt, während ein asynchroner Bus von einer vorgegebenen Bitrate ausgeht.
• Adressierung, die festlegt, wie viele Geräte sich die Leitungen teilen.
• Topologie, die Punkt-zu-Punkt-Verbindungen im Gegensatz zu Multidrop-Bussen umfasst, die sich über ein Chassis erstrecken.
• Elektrische Reichweite, da Single-Ended-Signale über große Entfernungen hinweg an Stärke verlieren, während Differenzpaare diese ohne Einbußen überstehen.
• Fehlerbehandlung, d. h. was der Chip tut, wenn eine Prüfsumme fehlschlägt.

Klären Sie diese fünf Punkte zunächst ab, bevor es um Datenübertragungsraten geht. Keine Firmware kann eine physikalische Schicht beheben, die nicht für die jeweilige Aufgabe ausgelegt war.

Warum SPI die Nase vorn hat, wenn es vor allem auf den reinen Durchsatz ankommt

SPI ist ein synchroner Vollduplex-Bus, der mit Frequenzen im zweistelligen Megahertz-Bereich arbeitet, da der Controller den Takt liefert und keine Adressierung im Frame enthalten ist. Vier Leitungen übertragen den Takt, zwei Datenleitungen und ein Chip-Select-Signal, und jedes Peripheriegerät benötigt einen weiteren Select-Pin.

Anzeigeanwendungen verdeutlichen diesen Kompromiss. Ein 320 × 240-Pixel-Farb-TFT mit 30 Bildern pro Sekunde benötigt Megabyte an Pixeldaten pro Sekunde, die SPI bei 40 MHz problemlos übertragen kann, während I2C bei 400 kHz mehrere Minuten pro Bild benötigen würde.

SPI verzichtet auf eine interne Protokoll-Disziplin. Es sieht weder eine Bestätigung noch eine Fehlerbehebung vor, sodass ein Peripheriegerät, das eine Takt Vorteil verpasst, stillschweigend unlesbare Daten zurückgibt und Ihre Firmware diese mit ihrem eigenen CRC abfangen muss. Auch die Übertragungslänge spielt eine Rolle, da ein 40-MHz-Takt über eine Länge von 30 Zentimetern Flachbandkabel so stark schwankt, dass Daten verfälscht werden können.

„Es sieht weder eine Fehlererkennung noch eine Wiederherstellung vor, sodass ein Peripheriegerät, das eine Takt Vorteil verpasst, stillschweigend ungültige Daten zurückgibt und Ihre Firmware dies mithilfe ihrer eigenen CRC abfangen muss.“

Wie UART Punkt-zu-Punkt-Verbindungen ohne Takt signalverarbeitet

UART verbindet genau zwei Geräte über zwei Leitungen ohne gemeinsamen Takt, daher müssen sich beide Seiten vorab auf eine Bitrate einigen. Aufgrund dieser Einfachheit ist es die erste Schnittstelle, die Ingenieur:innen auf neuen hardware einrichten, und die letzte, die sie wieder entfernen.

Fast jedes Modul, das Sie kaufen, unterstützt diese Schnittstelle. Ein GNSS-Empfänger überträgt Positionsdaten mit 9600 Baud, und eine Debug-Konsole über eine USB-Brücke liefert Ihnen bereits wenige Minuten nach dem „ Antrieb “ eines neuen Boards lesbare Ausgaben.

Die Grenzen werden deutlich, sobald man ein drittes Gerät hinzufügt. Da UART keine Adressierung unterstützt, erfordert eine Erweiterung über eine einzelne Verbindung hinaus den Einsatz von RS-485-Transceivern und ein Adressierungsschema, das Sie nun verwalten müssen. Die Taktgenauigkeit stellt eine weitere Einschränkung dar, da der Empfänger die Mitte jedes Bits abtastet und nur eine Abweichung von etwa 2 % toleriert. Aus diesem Grund verursacht ein interner RC-Oszillator bei höheren Übertragungsraten Probleme, während dies bei einem Quarzoszillator nicht der Fall ist.

Warum sich I2C für Sensornetzwerke mit begrenzter Pin-Anzahl eignet

I2C ermöglicht den Anschluss zahlreicher Geräte über zwei Leitungen, indem jedem Gerät eine 7-Bit-Adresse zugewiesen wird, anhand derer der Controller das jeweilige Gerät auswählt. Dank Open-Drain-Ausgängen mit Pull-up-Widerständen kann jedes Gerät eine Leitung auf dem Low-Pegel halten, wodurch Bestätigungen und Taktdehnung ohne zusätzliche Pins funktionieren.

Gerade bei Sensor-Clustern macht sich dies bezahlt. Ein Handmessgerät könnte einen Temperatursensor, einen Beschleunigungsmesser, einen kleinen EEPROM-Speicher und einen Stromverbrauchsmesser an denselben zwei Pins unterbringen.

Diese Bequemlichkeit bringt jedoch zwei Fehlerquellen mit sich. Identische Bauteile werden oft mit derselben festen Adresse ausgeliefert, sodass drei identische Drucksensoren einen Multiplexer benötigen – und das in der Prototypenphase festzustellen, ist kostspielig. Die Buskapazität stellt eine weitere Grenze dar, da die Spezifikation einen Standardbus auf 400 pF begrenzt und dicht bestückte Leiterplatten diesen Wert überschreiten, woraufhin der Betrieb bei 400 kHz nicht mehr möglich ist.

Wie CAN die Zuverlässigkeit verteilter Steuerungen bei elektrischen Störungen gewährleistet

CAN überträgt Nachrichten über ein differentielles verdrilltes Kabelpaar, sodass elektrisches Rauschen beide Adern gleichermaßen betrifft und sich am Empfänger aufhebt. Die Knoten werden nicht einzeln adressiert. Jede Nachricht enthält eine Kennung, die gleichzeitig ihre Priorität festlegt, und das „ hardware “ löst Kollisionen auf, ohne dass der siegreiche Frame verloren geht.

Dieses Design hat sich in der Serienproduktion bewährt: Jährlich werden mehr als 2 Milliarden CAN-Knoten in Fahrzeugen und Industriemaschinen verkauft. Ein elektrischer Antriebsstrang verdeutlicht, warum das so ist. Das Batteriemanagement, der Wechselrichter, das Ladegerät und das Kombiinstrument sind meterweit voneinander entfernt an einem verdrillten Kabelpaar angeschlossen, und eine Fehlermeldung der Batterie hat bei der Priorisierung Vorrang vor einer routinemäßigen Temperaturaktualisierung.

Das Silizium übernimmt Aufgaben, die andernfalls von der Firmware übernommen würden. CAN-Controller kümmern sich um CRC-Prüfungen, Bestätigungen und Neuübertragungen, und ein Knoten, der immer wieder ausfällt, trennt sich selbst vom Bus. Der Preis dafür liegt in der Nutzdatengröße und der Planung, da klassische Frames 8 Byte umfassen und CAN FD diese Größe auf 64 Byte erhöht, und jede Kennung muss bereits vor dem Schreiben der Firmware zugewiesen werden.

Auswahl des richtigen Protokolls für die Anforderungen Ihrer Anwendung

Beginnen Sie mit der physikalischen Einschränkung, über die Sie nicht verhandeln können – in der Regel die Entfernung oder die Anzahl der Knoten –, und betrachten Sie erst danach den Durchsatz. Eine Verbindung, bei der innerhalb einer Maschine 2 Meter Kabel überbrückt werden müssen, schließt SPI und I2C bereits aus, noch bevor die Geschwindigkeit überhaupt zur Sprache kommt.

Gemischte Systemarchitekturen sind die Regel. Ein Motorsteuergerät liest die Daten seines Positionssensors über SPI aus, konfiguriert einen Leistungsmonitor über I2C, stellt einen UART für Servicetechniker bereit und übermittelt Daten über CAN an das Fahrzeug. Die Teams bei OPAL-RT sehen sich mit derselben Kombination konfrontiert, wenn der Code für eingebettete Steuerungen von einem Prototyp auf dem Prüfstand auf Labor hardware s übertragen wird, wo die Kompatibilität der Toolchain verhindert, dass die Portierung zu einer Neuprogrammierung wird.

Häufige Fragen zu Kommunikationsprotokollen für Mikrocontroller – klar und verständlich beantwortet

Was ist der Hauptunterschied zwischen SPI und I2C?

Der Hauptunterschied zwischen SPI und I2C besteht darin, dass SPI Pins zugunsten der Geschwindigkeit opfert, während I2C Geschwindigkeit zugunsten der Pins opfert. SPI benötigt pro Peripheriegerät eine Select-Leitung mit einer Frequenz von mehreren zehn Megahertz, während bei I2C zwei Leitungen von vielen adressierten Geräten gemeinsam genutzt werden, wobei die Frequenz bis zu 3,4 MHz beträgt.

Lohnt sich der Einsatz von CAN auf einer einzelnen Leiterplatte?

Selten. CAN macht sich erst dann bezahlt, wenn die Knoten unter elektrischen Störungen mehrere Meter voneinander entfernt sind und auf einer Platine SPI oder I2C dieselben Daten mit weniger Halbleitermaterial übertragen. Eine Ausnahme bildet eine Platine, die in ein bestehendes CAN-Netzwerk eingebunden wird.

Welches Protokoll sollten Sie auf neuen hardware als Erstes aktivieren?

UART, fast immer. Eine funktionierende serielle Konsole liefert dir eine ausgegebene Ausgabe, mit der du alles andere debuggen kannst, und benötigt dafür nur zwei Pins und eine korrekte Takteinstellung.

Wo sich die Einhaltung von Protokollen über den gesamten Produktlebenszyklus hinweg auszahlt

Die Wahl des Protokolls erweist sich als Fehlentscheidung, wenn sie für den Prototyp statt für das Endprodukt getroffen wird. Teams, die sich allein aufgrund der Pin-Verfügbarkeit für einen Bus entscheiden, verbringen Jahre damit, Multiplexer, Wiederholungslogik und Abschirmungen hinzuzufügen, um ein Design zu stützen, das ein Differenzpaar eigentlich schon bewältigen könnte.

Ingenieur:innen , die dieses Problem nicht haben, betrachten den Bus als Teil der Systemarchitektur. Sie zählen Knoten und Kabellängen, bevor sie Bauteile auswählen, planen die Kosten für die Pins ein, die von den Auswahlleitungen belegt werden, und erstellen eine Kennungszuordnung, bevor die Firmware gestartet wird. Das ist alles nicht besonders glamourös, aber es ist wesentlich kostengünstiger, als einen sporadisch auftretenden Fehler in einer Produktionslinie zu beheben.

OPAL-RT sieht den Nutzen darin, wie reibungslos sich eingebettete Steuerungsfunktionen zwischen verschiedenen Entwicklungsumgebungen übertragen lassen, da sich ein Design mit klaren Protokollgrenzen über verschiedene Toolchains hinweg portieren lässt, ohne dass jemand die Schnittstellenschicht neu schreiben muss. Eine fundierte Protokollauswahl ist stille Ingenieurskunst, die sich darin zeigt, dass Platinen auf Anhieb funktionieren und Busse auch lange nach dem Weggang derjenigen, die sie ausgewählt haben, zuverlässig bleiben.

„Die ‚ Ingenieur:innen ‘, die dieses Problem nicht haben, betrachten den Bus als Teil der Systemarchitektur.“