3.25. Grundlagen des CAN-Bus

CAN (Controller Area Network) wurde ursprünglich in den 1980er-Jahren von Bosch entwickelt, um alle elektronischen Steuergeräte in einem Auto über einen einzigen kurzen, gemeinsam genutzten Bus zu verkabeln. Es beherrscht nach wie vor den Kabelbaum im Auto, doch dieselbe Robustheit, das Echtzeitverhalten und das Multi-Master-Design machen es zum De-facto-Feldbus in der Automatisierung, Robotik sowie in landwirtschaftlichen und industriellen Geräten aller Art.

CAN besitzt keinen einzelnen „Controller“ und eine Menge von „Peripheriegeräten“, wie es bei SPI und I2C der Fall ist. Jeder Knoten am Bus ist gleichberechtigt, und jeder Knoten kann senden, sobald der Bus frei ist. Skalierbar wird das durch das Broadcast-mit-Arbitrierung-Design des Busses.

3.25.1. Broadcast mit Prioritätsarbitrierung

Jede Nachricht auf einem CAN-Bus trägt einen Identifier – 11 Bit beim klassischen Standard-Einzelbild, 29 Bit bei der erweiterten Variante. Der Identifier ist keine Adresse; er kennzeichnet, worum es bei der Nachricht geht (Motordrehzahl, Bremspedalstellung, Batteriespannung usw.). Wenn ein Knoten einen Wert senden möchte, gibt er ihn mit dem passenden Identifier versehen per Broadcast aus, und jeder Knoten am Bus sieht diesen Broadcast. Jeder Empfänger filtert den Bus in Hardware, um nur die IDs herauszupicken, die ihn interessieren.

Wenn zwei Knoten gleichzeitig zu senden versuchen, sorgt das elektrische Design des Busses dafür, dass die Nachricht mit dem niedrigeren numerischen Identifier gewinnt, ohne dass Bits verloren gehen.

Der Trick sind die beiden elektrischen Zustände des Busses: dominant (logisch 0) und rezessiv (logisch 1). Die CAN-Leitungen werden durch Abschlusswiderstände auf High (rezessiv) gehalten, wenn kein Knoten sendet; jeder Knoten kann die Leitungen auf Low (dominant) ziehen, indem er über seinen Transceiver Strom liefert. Das Ergebnis ist ein Wired-AND: Sobald auch nur ein einzelner Knoten den Bus dominant treibt, liest die Leitung dominant, und sie liest nur dann rezessiv, wenn jeder Knoten sie freigegeben hat. Dominant gewinnt immer. (Manche Quellen nennen dieselbe Anordnung Wired-OR und behandeln „dominant“ als das aktiv gesetzte Signal statt als das AND der rezessiven Bits – das physikalische Verhalten ist in beiden Fällen identisch.)

Eine einzelne Busleitung, die durch einen Abschlusswiderstand zu Vcc auf High gehalten wird. Drei Knoten (A, B, C) hängen am Bus. Die Ausgangsstufe jedes Knotens ist eine Diode in Reihe mit einem Schalter nach Masse -- die Diode zeigt vom Bus hinunter zum Schalter, sodass das Schließen des Schalters den Bus über die Diode auf Low zieht, aber kein Knoten den Bus auf High treiben kann.

Das Wired-AND in konzeptioneller Form. Echtes CAN führt dieselbe Logik über ein differenzielles Leitungspaar (CAN_H / CAN_L) aus, wobei die Transceiver und Abschlusswiderstände auf beide Leitungen verteilt sind, doch die Regel am Bus bleibt dieselbe: Jeder Knoten kann dominant ziehen, und nur wenn jeder Knoten freigegeben hat, liest der Bus rezessiv.

Die Arbitrierung nutzt diese Asymmetrie direkt aus. Jeder sendende Knoten überträgt seine ID Bit für Bit, MSB zuerst, und beobachtet den Bus während des Sendens. Ein Knoten, der ein rezessives Bit auf die Leitung legt, aber dominant zurückliest, weiß, dass im selben Moment ein anderer Knoten mit niedrigerer ID sendet und diese Bitposition gewonnen hat. Er hört sofort auf, den Bus zu treiben, und lauscht. Der gewinnende Knoten sieht derweil seine eigenen Bits unverändert hinausgehen – aus seiner Sicht ist nichts Ungewöhnliches passiert. Die niedriger nummerierte ID gewinnt, weil ihre dominanten Bits die rezessiven Bits überschreiben, die die höher nummerierten IDs an denselben Positionen sonst gesendet hätten.

Der Verlierer wartet daraufhin, bis der Bus frei wird, und sendet automatisch erneut. Es gibt keine Kollisionen, keine verlorenen Nachrichten – nur eine deterministische Prioritätsreihenfolge.

Das ist der Publish/Subscribe-Stil, der CAN im großen Maßstab funktionieren lässt: Jeder darf senden, jeder darf empfangen, und die IDs machen die Zustellung implizit.

3.25.2. Der physische Bus

Der CAN-Controller des MCU treibt den Bus nicht direkt. Er stellt nur zwei 3,3-V-CMOS-Pins bereit – TX (das Bit, das er senden will) und RX (das Bit, das er auf dem Bus sieht) – und diese Pins führen zu einem separaten Chip, dem CAN-Transceiver oder PHY. Der Transceiver sitzt zwischen dem Controller und den eigentlichen CAN-Leitungen; er ist das Bauteil, das weiß, wie man mit dem Bus spricht.

Der Bus selbst ist ein differenzielles 5-V-Leitungspaar:

  • CAN_H – die „High“-Leitung des Paares.

  • CAN_L – die „Low“-Leitung.

Im rezessiven Zustand liegen beide Leitungen bei etwa 2,5 V (dem Mittelpunkt der 5-V-Versorgung des Busses). Im dominanten Zustand zieht der Transceiver CAN_H auf etwa 3,5 V hoch und CAN_L auf etwa 1,5 V herunter, wodurch eine Differenz von rund 2 V über das Paar entsteht. Empfänger tasten die Differenz zwischen den beiden Leitungen ab, was das Signal immun gegen Gleichtaktrauschen macht, das über lange Kabelstrecken aufgenommen wird.

Die zweiseitige Aufgabe des Transceivers:

  • Auf der TX-Seite liest er den massebezogenen 3,3-V-TX-Pin des Controllers und treibt entweder CAN_H und CAN_L für dominant auseinander oder gibt beide für rezessiv frei.

  • Auf der RX-Seite liest er das differenzielle CAN_H- / CAN_L-Paar und meldet an seinem RX-Pin einen massebezogenen 3,3-V-Pegel an den Controller zurück.

Zwei 120-Ohm-Abschlusswiderstände, je einer an jedem physischen Ende des Kabels, halten den Bus am rezessiven Mittelpunkt, wenn kein Knoten treibt, und dämpfen Reflexionen, die andernfalls das differenzielle Signal auf langen Strecken verfälschen würden.

3.25.3. Das Datenframe

Ein Standard-CAN-Datenframe sieht auf der Leitung so aus:

Acht Felder in Folge gezeichnet: SOF (1 Bit), ID (11 Bit), RTR (1 Bit), Control (6 Bit), Data (0 -- 8 Bytes), CRC (16 Bit), ACK (2 Bit) und EOF (7 Bit).

Ein Standard-CAN-Datenframe: die Felder SOF, ID, RTR, Control, Data, CRC, ACK und EOF.

Jedes Feld hat eine bestimmte Aufgabe:

  • SOF (Start of Frame). Ein dominantes Bit, das anzeigt, dass ein neues Frame beginnt, und die Bit-Taktung jedes Knotens synchronisiert.

  • ID (Identifier). Der 11-Bit-Identifier, über den der Bus arbitriert. Niedrigere Zahl = höhere Priorität.

  • RTR (Remote Transmission Request). Gesetzt bei einer Anforderung von Daten statt einer Lieferung von Daten; Empfänger mit passender ID antworten, indem sie die Daten selbst senden.

  • Control. Ein 6-Bit-Feld, das die Datenlänge (DLC) und ein paar Verwaltungsbits kodiert.

  • Data. 0 bis 8 Bytes Nutzdaten (CAN Classic; CAN FD erweitert dies auf 64 Bytes).

  • CRC. Insgesamt 16 Bit: eine 15-Bit-CRC über die vorangehenden Felder plus ein 1-Bit-CRC-Begrenzer.

  • ACK. Insgesamt 2 Bit. Im ersten Bit – dem ACK-Slot – gibt der Sender die Leitung frei, und jeder Knoten, der das Frame korrekt empfangen hat, zieht sie auf Low; das zweite Bit ist ein rezessiver Begrenzer. Ein fehlendes ACK sagt dem Sender, dass kein Knoten das Frame gehört hat und er es erneut versuchen sollte.

  • EOF (End of Frame). Sieben rezessive Bits, die das Frame abschließen.

All das wird vom CAN-Controller in Hardware erzeugt und dekodiert; die Software sieht nur die ID, die Daten und ein paar Flags.

3.25.4. Wo CAN einzuordnen ist

Die Designentscheidungen von CAN legen seine Nische fest:

  • Robust. Differenzielle Signalübertragung über ein verdrilltes Paar, eingebaute Fehlererkennung, deterministische Prioritätsarbitrierung und automatische Wiederholungen lassen CAN in elektrisch verrauschten Umgebungen überleben, in denen UART und SPI Daten verfälschen würden.

  • Multi-Master. Jeder Knoten kann jederzeit senden. Es ist kein zentraler Controller erforderlich, und kein Knoten ist ein Single Point of Failure.

  • Bandbreitenbegrenzt. Klassisches CAN ist bei etwa 1 Mbit/s am Limit; CAN FD erweitert dies. CAN ist die richtige Antwort, wenn die Verbindung zwischen Platinen oder Modulen verläuft, oft über mehrere Meter Kabel, mit Zuverlässigkeit als oberster Priorität.

  • Protokolle höherer Schichten. Der nackte CAN-Bus legt nicht fest, was eine ID bedeutet oder wie eine lange Nachricht in Fragmente aufgeteilt wird. Anwendungsschichtprotokolle – CANopen, J1939, ISO-TP/UDS, NMEA 2000 – legen diese Regeln obendrauf. Ein gesondert erwähnenswerter Punkt ist die DBC-Datei: ein herstellerspezifisches Textformat, das festhält, welche IDs welche Bit-genauen Signale auf einem bestimmten Fahrzeug oder System tragen. DBC-Dateien sind ein Metadatenformat, das das Nachrichtenlayout eines Busses beschreibt, und kein Protokoll für sich.

Der Treiber in CAN-Bus im Code kümmert sich um das CAN-Frame auf Leitungsebene; die Zuordnung von IDs zu Bedeutungen ist Aufgabe der Anwendung.