Implementierung des CAN-Protokolls

Die Kommunikation ist für alle Implementierungen des CAN-Protokolls identisch. Es gibt natürlich Unterschiede in der Implementierung der reinen Übermittlung der Nachricht, die außerhalb des Mikrocontrollers durch den CAN-Chip stattfindet.

CAN Controller mit Nachrichtenpufferung

CAN standard frame format (CAN Specification 2.0A)
CAN standard frame format (CAN Specification 2.0A)

CAN Controller mit Nachrichtenpufferung (früher basicCAN Chips) haben die Logik um eine protokollgetreue Übermittlung der Daten zu gewährleisten in Hardware implementiert. Die Administration der Sende- und Empfangsdaten und die Akzeptanzfilterung kann aber nur zu einem bestimmten Anteil vom CAN Controller übernommen werden.

Normalerweise haben CAN Controller mit Nachrichtenpuffern je zwei Ein- und zwei Ausgangspuffer. Die 8-bit Code und Mask Register erlauben eine beschränkte Akzeptanzfilterung (8 MSB des Identifiers). Dementsprechendes Setzen dieser 8 bits erlaubt es also Identifiergruppen oder gezielte Identifier oder in Ausnahmefällen alle Identifier auszuwählen. Wenn mehr als 8 ID-MSBs nötig sind, um zwischen Nachrichten zu unterscheiden, muss der Mikrocontroller die weitere Auswahl über Softwaremechanismen übernehmen. CAN Controller mit Nachrichtenpufferung können einen erhöhte Mikrocontrollerbelastung durch die Nachrichtenfilterung verursachen, aber sie benötigen weniger Platz auf der Platine und verursachen auch geringere Produktionskosten. Prinzipiell können sie aber jede Art von Nachricht im Netzwerk verarbeiten.

CAN Controller mit Objektspeicherung

CAN Objekte bestehen im Prinzip aus drei Komponenten:

  • Identifier (ID)
  • Längenangabe (DLC)
  • Datenteil

CAN Controller mit der Möglichkeit der Objektspeicherung (früher FullCAN) funktionieren gleich wie CAN Controller mit Nachrichtenpufferung, können aber auch gezielt Objekte handhaben. Wenn mehrere gleichzeitige Anfragen anliegen können sie beispielsweise entscheiden, welches Objekt zuerst übermittelt werden soll. Sie führen genauso auch Akzeptanzfilterung für eingehende Objekte durch. Die Schnittstelle zu folgendem Mikrocontroller ist an ein RAM angebunden. Zu übermittelnde Daten werden in den dafür vorgesehenen Speicherbereich im RAM geschrieben und empfangene Daten werden ebenso aus dem RAM wieder ausgelesen. Der Mikrocontroller muss so nur wenige bits handhaben (z.B. Sendeanfrage).

CAN Controller mit Objektspeicherung wurden hauptsächlich dazu entwickeln möglichst viel Arbeit aus dem Mikrocontroller auszulagern und ihn so zu entlasten. Diese CAN Controller benötigen mehr Platz auf der Platine und sind außerdem teurer in der Anschaffung. Zusätzlich ist die Anzahl der anbindbaren Chips begrenzt.

Bild: Physikalische CAN Verbindung nach ISO11898
Physikalische CAN Verbindung gemäß ISO 11898

Mittlerweile gibt es schon CAN Controller, die beide Varianten unterstützen. Sie benutzen die Objektspeicherung, haben aber mindestens einen davon als Nachrichtenpuffer konzeptioniert. Daher ist es nicht länger nötig sich zwischen den beiden zu entscheiden (basicCAN oder fullCAN).

CAN Slave Controller für Ein-/Ausgabefunktionen

Neben CAN Controllern, die alle Funktionen des CAN Protokolls unterstützen gibt es auch noch CAN Chips, die keinen Mikrocontroller mehr benötigen. Diese CAN Chips werden SLIO genannt (serial link I/O) und sind nur CAN Slaves, die von einem CAN Master gesteuert werden müssen.

Physikalische CAN Verbindung

Alle Datenraten ( bis zu 1 Mbit/s ) benötigen eine ausreichende Kurvensteilheit, die nur über den Einsatz von Stromzuführern realisiert werden kann. Eine geringe Anzahl von physischen Verbindungen sind grundsätzlich möglich, es wurde aber von Nutzern und Herstellern aus der Gruppe "CAN in Automation" empfohlen Treiberbausteine gemäß ISO 11898 zu verwenden. Eingebettete Treiberchips gemäß ISO 11898 sind von vielen Herstellern verfügbar (Bosch, NXP, Siliconix und Texas Instruments). Die Internationale Gemeinschaft der Nutzer und Hersteller (CiA) spezifiziert aber auch mehrfach mechanische Verbindungen (Kabel und Verbinder).