CAN - Controller Area Network
Alexander Bernauer
Datenschleuder #83, Seite 24-27
1983 wurde die Entwicklung von CAN bei Bosch begonnen und dauerte drei Jahre. Eine Kooperation mit Intel ergab 1987 den ersten CAN Chip. Kurz darauf folgten andere Hersteller wie Philips mit eigenen ICs. 1991 veröffentlichte Bosch seine bis heute gültige CAN 2.0 Spezifikation. Diese beschreibt die unteren zwei Layer des OSI Referenzmodells in einem monolythischen Ansatz. Zur Standardisierung der von vielen Seiten entwickelten Application Layer für CAN wurde im Folgejahr die "CAN in Automation" (CiA), eine internationale Interessensgruppe aus Herstellern und Anwendern, gegründet. Im selben Jahr wurde das CAN Application Layer (CAL) Protokoll von der CiA veröffentlicht. Dieses und andere Protokolle wie das 1995 veröffentlichte CANOpen, ermöglichen eine abstrakte Programmierung und flexible Konfiguration des Netzwerkes. Ebenfalls 1992 wurden die ersten Autos von Mercedes-Benz mit CAN Netzwerken ausgestattet. Seit 1993 ist die CAN 2.0 Spezifikation ein ISO Standard.
CAN ist ein Multimaster Bus. Keiner der Teilnehmer hat für den Busbetrieb spezielle Aufgaben und somit exisitert kein single point of failure. Die Knoten sind typischerweise Sensoren und Aktoren, die an einem Microcontroller mit CAN Interface angeschlossen sind. Tritt ein definiertes Ereignis ein, wie z.B. das Drücken eines Knopfes durch einen Benutzer, das Überschreiten einer Schwelle für einen Meßwert oder der Ablauf eines Timers, so broadcastet der entsprechende Knoten eine Nachricht auf dem Bus. Für die Knoten, die nicht an dieser Nachricht interessiert sind, sind Hardwarefilter vorgesehen, um die langsamen CPUs nicht mit dieser Aufgabe zu belasten. Eine Nachricht besteht im wesentlichen aus einem Identifier und 0 bis 8 Datenbytes. Für die Länge des Identifiers gibt es zwei Standards. CAN 2.0A definiert die sog. standard Frames mit 11 Bit Identifier und CAN 2.0B die sog. extended Frames mit 29 Bit Identifier. Eine Nachricht trägt keine Informationen über ihre Herkunft und ist somit anonym. Vielmehr besitzt sie nur eine vom Identifier abhängige Bedeutung, die per Systemdesign festgelegt wird.
Für die Verdrahtung existieren zwei unterschiedliche Möglichkeiten. Im unsymmetrischen Modus gibt es einfach eine Masseleitung und eine Signalleitung. Zum Einsatz kommt er vor allem dort, wo Kosten gespart werden müssen, weil man billige Leitungstreiber verwenden kann. Man kann sich sogar die Masseleitung sparen und z.B. die Karrosserie als Bezugspotential verwenden, was üblicherweise im Chassis-Bereich getan wird. Allerdings ist das störungsanfällig und taugt daher nur für geringe Busgeschwindigkeiten. Die maximalen Transferraten erreicht man nur im differentiellen Modus. Dort entscheidet das Vorzeichen der Differenzspannung zwischen den beiden Leitungen CAN High und CAN Low über den Wert des Bits. Wenn diese Leitungen nebeneinander geführt werden, so wirken sich lokale Störungen auf beide gleich aus wobei die Differenz erhalten bleibt. In jedem Fall muss der Bus an beiden Enden mit Widerständen abgeschlossen werden um Reflekionen zu vermeiden. Alle Teilnehmer sind über Stichleitungen mit dem Bus verbunden. Zu jeder Bitzeit muss der Bus an den Orten aller Teilnehmer das gleiche Bit tragen, damit die Mechanismen für den Buszugriff funktionieren können. Aus den Signallaufzeiten und den Verzögerung der Empfänger- und Senderhardware folgt damit die maximal zulässige Buslänge in Abhängigkeit der Busgeschwindigkeit. Bei 1 MBit/s ergeben sich maximal 30 m. Wenn man auf 40 kBit/s runtergeht kann man Buslängen von bis zu 1 km erreichen. Allgemein sagt die Worst-Case Design Regel dass Buslänge x Bitrate < 40m x 1Mbit/s sein muss. Auch die Länge der Stichleitungen ist durch die Bitrate begrenzt. So ergibt sich für den High Speed CAN eine maximale Länge von 5 Metern. Die Anzahl der Teilnehmer ist durch den Standard nicht begrenzt. Allerdings kann man mit den üblichen Leitungstreibern maximal 32 Teilnehmer versorgen. Mit teurerer Hardware können derzeit bis zu 128 Teilnehmer an einem Bus betrieben werden.
Der Buszugriff geschieht im CSMA/CD+CR Verfahren. Jeder Knoten darf wann immer er will senden (Multiple Access), sobald er eine Pause auf dem Bus entdeckt (Carrier Sense). Wenn zur gleichen Zeit ein zweiter Knoten eine Nachricht senden möchte, so wird das erkannt (Collission Detection). Im Gegensatz zum bekannten Ethernet kommt es dabei allerdings zu einer nicht destruktiven Collission Resolution. Das bedeutet, dass sich die Nachricht mit der höheren Priorität durchsetzt und der Sender der anderen Nachricht sofort zum Empfänger wird. Grundlegend für diesen Mechanismus ist eine spezielle Leitungskodierung. Im Prinzip ist es eine Non-Return-to-Zero (NRZ) Kodierung. Wenn allerdings ein Knoten eine 1 und ein anderer eine 0 schreibt, dann liegt auf dem Bus eine 0. Man sagt, dass die 1 rezessiv und die 0 dominant ist. Im Fall einer Kollission erkennt einer der Sender, dass er überschrieben wird, indem er während der sog. Arbitrierungsphase beim Schreiben jedes Bit gleichzeitig ließt und vergleicht. Der andere Sender bemerkt die Kollission nicht und sendet weiter, so dass sich seine Nachricht durchsetzt. Die Arbitrierungsphase geht über den kompletten Identifier, so dass Nachrichten mit kleinen Identifiern hohe Priorität haben. Das gleichzeitige Senden von zwei Nachrichten mit dem selbem Identifier ist verboten und muss durchs Systemdesign verhindert werden.
Zur Synchronisation der Busteilnehmer dient ein einzelnes, dominantes Startbit vor dem Identifier einer Nachricht. Zusätzlich wird jeder Flankenwechsel zur weichen Synchronisation verwendet. Dadurch kann man billige und ungenaue Quarze verwenden. Um sicherzustellen, dass genug Flankenwechsel vorkommen, wird nach fünf gleichen Pegeln zwangsweise ein Flankenwechsel eingebaut. Man nennt das die Bit Stuffing Regel. Das zusätzliche Bit dient nur der Synchronisation und enthält keinerlei Informationen.
Im CAN 2.0A Frame folgen dem Identifier sieben Controll Bits. Das erste davon ist das Remote Transfer Request (RTR) Bit. Eine Nachricht mit gesetztem RTR darf keine Daten besitzten. Vielmehr ist diese Nachricht eine Aufforderung zu antworten. Die Antwort ist eine normale CAN Nachricht mit gleicher ID und nicht gesetztem RTR. Damit kann man z.B. einen Sensor pollen, falls man keine regelmäßigen Updates der Meßwerte braucht. Das RTR Bit gilt als gesetzt, wenn es den Wert 1 hat. Da die Arbitrierungsphase das RTR Bit einschließt, wird ein Request von der Antwort überschrieben falls beide gleichzeitig gesendet werden. Das nächste Controll Bit dient zur Unterscheidung des verwendeten Nachrichtenformats. Dabei steht eine 0 für standard und eine 1 für extended Frames. Die letzten 4 Bits heißen Data Length Code (DLC) und geben die Anzahl der Datenbytes an, die direkt danach folgen. Alle Werte zwischen 0 und 8 sind zugelassen. Auch eine Nachricht ohne Datenbytes kann nämlich allein durch ihr Auftauchen auf dem Bus eine Information sein. Eine anschließende 15 Bit CRC Summe dient zur Erkennung von Übertragungs- und Empfangsfehlern. Sie erlaubt das Entdecken von bis zu 6 Einzelfehlern und 15 Bit Burstfehlern. Die nächsten zwei Bit sind der Acknowledge Slot. Jeder Knoten, der die Nachricht mit korrektem Format empfangen hat, sendet in dieser Zeit ein 0. Der Sender schreibt ein 1 und erwartet, die 0 zu lesen. Geschieht das nicht, so hat niemand die Nachricht empfangen. Abgeschlossen wird ein Frame mit sieben rezessiven Bits, dem End Of Frame (EOF). Dabei wird absichtlich die Bit Stuffing Regel verletzt, so dass jeder diese Marke eindeutig erkennen kann. Als letztes kommen noch 3 rezessive Inter Frame Bits. Sie geben den Teilnehmer die nötige Zeit, um die Nachricht in den Empfangspuffer zu schreiben und sich auf die nächste Nachricht vorzubereiten. Sollte einem Teilnehmer ausnahmsweise diese Pause nicht ausreichen, so kann er ein Overload Frame senden. Dieses besteht aus 6 dominanten Bits und verzögert einfach den Anfang der nächsten Nachricht. CAN 2.0B Frames beginnen auch mit einem Start Bit. Darauf folgen die ersten 11 Bit des Identifiers. An der Bitposition, an der standard Frames das RTR Bit haben, steht allerdings immer eine 1. Anschließend kommt das IDE Bit, welches zur Identifikation des Frame Formates hier auch den Wert 1 hat. Jetzt folgen die letzten 18 Bit des Identifiers und das RTR Bit. Nach zwei weiteren Bits, die reserviert sind und immer den Wert 0 haben, sind extended Frames mit standard Frames wieder identisch.
Ein Design Ziel von CAN war es, dass möglichst viele Fehler bereits von der Hardware erkannt und behandelt werden. Damit spart man Rechenleistung in den CPUs und aufwändige Protokolle in höheren Layern. Zwei der fünf möglichen Fehler können vom Sender entdeckt werden. Das erste ist ein Bitfehler. Dieser liegt vor, wenn außerhalb der Arbitrierungsphase und des ACK Slots das gelesene Bit nicht mit dem geschriebenen übereinstimmt. Das zweite ist ein Acknowledge Fehler. Dieser liegt vor, wenn der Sender im ACK Slot keine 0 ließt. Die restlichen drei möglichen Fehler können von den Empfängern erkannt werden. Zuerst kann ein Knoten eine Verletzung der Bit Stuffing Regel erkennen. Geschieht das außerhalb des EOF Feldes, so ist das offensichtlich ein Empfangsfehler. Außerdem kann ein Teilnehmer feststellen, dass die berechnete Prüfsumme nicht mit der Empfangenen übereinstimmt. Zu letzt kann eine allgemeine Verletzung des Nachrichten Formats erkannt werden. Das geschieht z.B. wenn die 6 rezessiven Bits des EOF ausbleiben oder auch, wenn ein Teilnehmer standard Frames erwartet, aber extended Frames empfängt. In jedem der fünf Fehlerfälle kommt es zur selben Fehlerbehandlung. Der jenige, der einen Fehler erkannt hat, sendet ein Error Frame auf den Bus, um alle anderen von dem Fehler in Kenntnis zu sezten. Das Error Frame besteht aus 6 dominanten Bits und überschreibt somit alles andere auf dem Bus. Auch hier wird absichtlich die Bit Stuffing Regel verletzt, um das Signal eindeutig erkennbar zu machen. Wenn ein Knoten selber keinen Fehler erkennt, aber ein Error Frame empfängt, so reagiert er auf die vermeintliche Verletzung der Bit Stuffing Regel mit dem Senden eines Error Frames. Das bedeutet zwar, dass ein Error Frame auf bis zu 12 Bits anwachsen kann, hat aber den Vorteil, dass jeder Busteilnehmer ein Error Frame sendet und damit im Fehlerzustand ist. Da jeder Teilnehmer im Fehlerfall die empfangene Nachricht verwirft, wird somit garantiert, dass eine CAN Nachricht entweder von allen oder von keinem angenommen wird. Das ist sehr wichtig für die Synchronisation der Busteilnehmer. Nach dem Error Frame wird die Nachricht einfach erneut gesendet.
Hat ein Knoten einen permanenten Fehler, wie z.B. einen defekten Eingang, so würde er den kompletten Bus ständig mit Error Frames beschreiben und somit lahm legen. Um das zu verhindern, hat man eine Selbstdiagnose der Busteilnehmer spezifiziert. Jeder CAN Baustein besitzt zwei Error Counter, einen für den Empfang (REC) und einen für das Senden (TEC). Kommt es zu Fehlern, so werden diese Zähler incrementiert. Wenn die Fehler wieder ausbleiben, so werden die Zähler mit der Zeit wieder decrementiert. Überschreitet einer der beiden Zähler eine Schwelle, so verhält sich der Teilnehmer Error Passive. Das bedeutet, dass er zwar ganz normal am Busgeschehen teilnimmt, aber im Fehlerfall nur noch passive Error Frames sendet. Diese bestehen aus 6 rezessiven Bits und stören damit den restlichen Bus nicht. Überschreitet der TEC eine zweite Schwelle, so geht der Baustein Bus Off. Er nimmt nicht mehr am Geschehen teil und kann aus diesem Zustand nur durch einen Benutzereingriff wieder zurückgesetzt werden. Die Regeln zum Erhöhen und Erniedrigen der Zähler sind äußerst komplex. Beispielhaft sollen hier die folgenden, vergleichsweise einfachen Regeln erläutert werden. Wenn ein Sender einen ACK Fehler erkennt, so bedeutet das, dass niemand seine Nachricht korrekt empfangen hat. Wenn kein Bitfehler vorliegt und nicht alle anderen Teilhemher Bus Off sind, so ist seine Verbindung zum Bus sehr wahrscheinlich unterbrochen. Als Konsequenz wird der TEC erhöht. Ist die Verbindung wirklich unterbrochen, so wird der Baustein sehr bald Bus Off gehen und diesen Zustand nach oben melden. Ein zweiter einfacher Fall liegt vor, wenn ein Baustein immer eine Differenz in der CRC Summe erkennt. Insbesondere, wenn er diesen Fehler immer als erster bemerkt liegt die Vermutung nahe, dass es sich um ein lokales Problem handelt. Sollte das der Fall sein, so wird sich der Baustein ziemlich schnell Error Passive verhalten und den Bus nicht weiter stören. Zu beachten ist, dass im Error Passive Zustand die nachrichtenbasierte Synchronisation der Teilnehmer nicht mehr gewährleistet ist, da der Baustein im Fehlerfall die Nachricht verwirft, diese aber nicht neu gesendet wird.
Ein Chip, der nur CAN 2.0A Frames kennt, kann nicht an einem Bus betrieben werden, auf dem CAN 2.0B gesprochen wird. Neben Bausteinen, die beide Formate können, gibt es solche, die sich CAN 2.0B passiv verhalten. Das bedeutet, dass sie zwar selber keine extended Frames lesen und schreiben können, beim Empfang aber auch keine Error Frames senden. Die Erweiterung auf 29 Bits für den Identifier war nötig, um trotz grober Filter genügend Flexibilität für Unterteilung der Nachrichten in Kategorien zu haben. Dafür bezahlt man allerdings mit einer geringeren Nettodatenrate. Mit standard Frames kommt man bei 1 MBit/s und 8 Datenbytes auf ein Maximum von 576,6 kBits/s netto. Mit extended Frames kommt man nur auf maximal 488,5 kBit/s. Da eine Nachricht ohne Daten auch einen Informationsgehalt besitzt, sind diese Zahlen nicht sehr repräsentativ.
Fast jeder Hardwarehersteller hat eigene CAN Lösungen in seinem Sortiment. So gibt es z.B. Microcontroller mit integriertem CAN Interface oder aufgebohrte PALs, die man remote über CAN steuern kann. Um eine bestehende Hardware Zugang zu einem CAN Bus zu ermöglichen eigenen sich sogenannte stand alone CAN Controller, wie z.B. der SJA1000 von Philips. Er ist eine komplette Implementierung der CAN 2.0 Spezifikation mit einem parallelen Interface. Üblicherweise wird er wie externes RAM an einen Microcontroller angeschlossen. Man kann ihn allerdings auch an den Druckerport anschließen, und so mit dem Computer Zugang zu einem CAN Bus erlangen. Ausgangsseitig spricht der SJA1000 TTL. Deshalb braucht man noch einen CAN Transceiver, der die Spannungen umwandelt. Abgesehen von noch ein paar Widerständen und Kondensatoren ist nicht mehr Hardware nötig. Alles zusammen bekommt man für unter 10 Euro. Auf dem Schaltplan sind noch zwei Varistoren und eine Spule eingezeichnet. Die Varistoren bieten einen Schutz vor Überspannung und die Spule verbessert die Signalqualität bei hohen Bitraten. Für ein einfaches Setup braucht man diese Komponenten allerdings nicht.
Im Control Register kann man vier mögliche Interrupts maskieren. Diese sind ein Receive Interrupt, ein Transmit Interrupt, ein Error Iterrupt und ein Data Overrun Interrupt. Die ersten beiden werden ausgelöst, wenn eine Nachricht fehlerfrei empfangen bzw. gesendet wurde. Ein Error Interrupt tritt auf, wenn einer der beiden Error Counter (TEC oder REC) die erste Schwelle überschreitet. Ein Data Overrun liegt vor, wenn der Controller keine Puffer mehr frei hat, um eine empfangene Nachricht zu speichern. Der SJA1000 besitzt nämlich einen 64 kB Ringpuffer für empfangene Nachrichten. Die Empfangsregister beinhalten immer den Wert der ältesten Nachricht. Hat man eine Nachricht ausgelesen, teilt man dem Controller mit, dass er zur nächsten Nachricht weitergehen soll. Das geschieht durch das Setzen eines Bits im Command Register. Dort kann man auch das Senden einer Nachricht, die man zuvor in die Senderegister geschrieben hat, auslösen. Falls einige Interrupts maskiert sind oder man generell keine Interrupts behandeln möchte oder kann, bietet das Interrupt Register die Möglichkeit, den Controller zu pollen. Zu guter letzt gibt es noch das Status Register, das Informationen über Fehlerereignisse und den Zustand der Sende- und Empfangspuffer enthält. Um den Controller konfigurieren zu können, muss er im Reset Modus sein. Dazu zieht man entweder die /RST Leitung auf Masse oder setzt das erste Bit im Controll Register auf 1. In diesem Zustand kann man u.a. die Empfangsfilter und die Baudrate einstellen.
Alexander Bernauer
Datenschleuder #83, Seite 24-27
Article:
CAN ist ein Standard für echtzeitfähige Bussysteme. Mitte der Achtziger wurde er in den ersten Luxuslimusinen eingebaut und ist heutzutage aus keinem modernen Automobil mehr wegzudenken. Typischerweise existieren in einem Auto mehrere getrennte CAN Busse mit unterschiedlichen Geschwindigkeiten. Ein Low Speed CAN (ISO 11519-2) mit maximal 10 kBit/s erlaubt Funktionalitäten im sog. Chassis-Bereich. Dazu gehört u.a. das Ein- und Ausschalten von Lichtern und Blinkern, das Verstellen der Sitzposition und der Außenspiegel, die Türverriegelung und andere Komfortfunktionen. Ein zweiter Low Speed CAN erlaubt den Austausch von höherem Informationsaufkommen mit bis zu 40 kBit/s. An diesem Bus hängen u.a. die Anzeigen des Amaturenbretts und die Klimatisierung. Echtzeitkritische Systemem kommunizieren über einen High Speed CAN (ISO 11898-2) mit bis zu 1 MBit/s, der maximalen Transferrate für CAN. Zu diesem Sytemen gehören z.B. die Motorsteurung und die Stabilitätskontrolle.1983 wurde die Entwicklung von CAN bei Bosch begonnen und dauerte drei Jahre. Eine Kooperation mit Intel ergab 1987 den ersten CAN Chip. Kurz darauf folgten andere Hersteller wie Philips mit eigenen ICs. 1991 veröffentlichte Bosch seine bis heute gültige CAN 2.0 Spezifikation. Diese beschreibt die unteren zwei Layer des OSI Referenzmodells in einem monolythischen Ansatz. Zur Standardisierung der von vielen Seiten entwickelten Application Layer für CAN wurde im Folgejahr die "CAN in Automation" (CiA), eine internationale Interessensgruppe aus Herstellern und Anwendern, gegründet. Im selben Jahr wurde das CAN Application Layer (CAL) Protokoll von der CiA veröffentlicht. Dieses und andere Protokolle wie das 1995 veröffentlichte CANOpen, ermöglichen eine abstrakte Programmierung und flexible Konfiguration des Netzwerkes. Ebenfalls 1992 wurden die ersten Autos von Mercedes-Benz mit CAN Netzwerken ausgestattet. Seit 1993 ist die CAN 2.0 Spezifikation ein ISO Standard.
CAN ist ein Multimaster Bus. Keiner der Teilnehmer hat für den Busbetrieb spezielle Aufgaben und somit exisitert kein single point of failure. Die Knoten sind typischerweise Sensoren und Aktoren, die an einem Microcontroller mit CAN Interface angeschlossen sind. Tritt ein definiertes Ereignis ein, wie z.B. das Drücken eines Knopfes durch einen Benutzer, das Überschreiten einer Schwelle für einen Meßwert oder der Ablauf eines Timers, so broadcastet der entsprechende Knoten eine Nachricht auf dem Bus. Für die Knoten, die nicht an dieser Nachricht interessiert sind, sind Hardwarefilter vorgesehen, um die langsamen CPUs nicht mit dieser Aufgabe zu belasten. Eine Nachricht besteht im wesentlichen aus einem Identifier und 0 bis 8 Datenbytes. Für die Länge des Identifiers gibt es zwei Standards. CAN 2.0A definiert die sog. standard Frames mit 11 Bit Identifier und CAN 2.0B die sog. extended Frames mit 29 Bit Identifier. Eine Nachricht trägt keine Informationen über ihre Herkunft und ist somit anonym. Vielmehr besitzt sie nur eine vom Identifier abhängige Bedeutung, die per Systemdesign festgelegt wird.
Für die Verdrahtung existieren zwei unterschiedliche Möglichkeiten. Im unsymmetrischen Modus gibt es einfach eine Masseleitung und eine Signalleitung. Zum Einsatz kommt er vor allem dort, wo Kosten gespart werden müssen, weil man billige Leitungstreiber verwenden kann. Man kann sich sogar die Masseleitung sparen und z.B. die Karrosserie als Bezugspotential verwenden, was üblicherweise im Chassis-Bereich getan wird. Allerdings ist das störungsanfällig und taugt daher nur für geringe Busgeschwindigkeiten. Die maximalen Transferraten erreicht man nur im differentiellen Modus. Dort entscheidet das Vorzeichen der Differenzspannung zwischen den beiden Leitungen CAN High und CAN Low über den Wert des Bits. Wenn diese Leitungen nebeneinander geführt werden, so wirken sich lokale Störungen auf beide gleich aus wobei die Differenz erhalten bleibt. In jedem Fall muss der Bus an beiden Enden mit Widerständen abgeschlossen werden um Reflekionen zu vermeiden. Alle Teilnehmer sind über Stichleitungen mit dem Bus verbunden. Zu jeder Bitzeit muss der Bus an den Orten aller Teilnehmer das gleiche Bit tragen, damit die Mechanismen für den Buszugriff funktionieren können. Aus den Signallaufzeiten und den Verzögerung der Empfänger- und Senderhardware folgt damit die maximal zulässige Buslänge in Abhängigkeit der Busgeschwindigkeit. Bei 1 MBit/s ergeben sich maximal 30 m. Wenn man auf 40 kBit/s runtergeht kann man Buslängen von bis zu 1 km erreichen. Allgemein sagt die Worst-Case Design Regel dass Buslänge x Bitrate < 40m x 1Mbit/s sein muss. Auch die Länge der Stichleitungen ist durch die Bitrate begrenzt. So ergibt sich für den High Speed CAN eine maximale Länge von 5 Metern. Die Anzahl der Teilnehmer ist durch den Standard nicht begrenzt. Allerdings kann man mit den üblichen Leitungstreibern maximal 32 Teilnehmer versorgen. Mit teurerer Hardware können derzeit bis zu 128 Teilnehmer an einem Bus betrieben werden.
Der Buszugriff geschieht im CSMA/CD+CR Verfahren. Jeder Knoten darf wann immer er will senden (Multiple Access), sobald er eine Pause auf dem Bus entdeckt (Carrier Sense). Wenn zur gleichen Zeit ein zweiter Knoten eine Nachricht senden möchte, so wird das erkannt (Collission Detection). Im Gegensatz zum bekannten Ethernet kommt es dabei allerdings zu einer nicht destruktiven Collission Resolution. Das bedeutet, dass sich die Nachricht mit der höheren Priorität durchsetzt und der Sender der anderen Nachricht sofort zum Empfänger wird. Grundlegend für diesen Mechanismus ist eine spezielle Leitungskodierung. Im Prinzip ist es eine Non-Return-to-Zero (NRZ) Kodierung. Wenn allerdings ein Knoten eine 1 und ein anderer eine 0 schreibt, dann liegt auf dem Bus eine 0. Man sagt, dass die 1 rezessiv und die 0 dominant ist. Im Fall einer Kollission erkennt einer der Sender, dass er überschrieben wird, indem er während der sog. Arbitrierungsphase beim Schreiben jedes Bit gleichzeitig ließt und vergleicht. Der andere Sender bemerkt die Kollission nicht und sendet weiter, so dass sich seine Nachricht durchsetzt. Die Arbitrierungsphase geht über den kompletten Identifier, so dass Nachrichten mit kleinen Identifiern hohe Priorität haben. Das gleichzeitige Senden von zwei Nachrichten mit dem selbem Identifier ist verboten und muss durchs Systemdesign verhindert werden.
Zur Synchronisation der Busteilnehmer dient ein einzelnes, dominantes Startbit vor dem Identifier einer Nachricht. Zusätzlich wird jeder Flankenwechsel zur weichen Synchronisation verwendet. Dadurch kann man billige und ungenaue Quarze verwenden. Um sicherzustellen, dass genug Flankenwechsel vorkommen, wird nach fünf gleichen Pegeln zwangsweise ein Flankenwechsel eingebaut. Man nennt das die Bit Stuffing Regel. Das zusätzliche Bit dient nur der Synchronisation und enthält keinerlei Informationen.
Im CAN 2.0A Frame folgen dem Identifier sieben Controll Bits. Das erste davon ist das Remote Transfer Request (RTR) Bit. Eine Nachricht mit gesetztem RTR darf keine Daten besitzten. Vielmehr ist diese Nachricht eine Aufforderung zu antworten. Die Antwort ist eine normale CAN Nachricht mit gleicher ID und nicht gesetztem RTR. Damit kann man z.B. einen Sensor pollen, falls man keine regelmäßigen Updates der Meßwerte braucht. Das RTR Bit gilt als gesetzt, wenn es den Wert 1 hat. Da die Arbitrierungsphase das RTR Bit einschließt, wird ein Request von der Antwort überschrieben falls beide gleichzeitig gesendet werden. Das nächste Controll Bit dient zur Unterscheidung des verwendeten Nachrichtenformats. Dabei steht eine 0 für standard und eine 1 für extended Frames. Die letzten 4 Bits heißen Data Length Code (DLC) und geben die Anzahl der Datenbytes an, die direkt danach folgen. Alle Werte zwischen 0 und 8 sind zugelassen. Auch eine Nachricht ohne Datenbytes kann nämlich allein durch ihr Auftauchen auf dem Bus eine Information sein. Eine anschließende 15 Bit CRC Summe dient zur Erkennung von Übertragungs- und Empfangsfehlern. Sie erlaubt das Entdecken von bis zu 6 Einzelfehlern und 15 Bit Burstfehlern. Die nächsten zwei Bit sind der Acknowledge Slot. Jeder Knoten, der die Nachricht mit korrektem Format empfangen hat, sendet in dieser Zeit ein 0. Der Sender schreibt ein 1 und erwartet, die 0 zu lesen. Geschieht das nicht, so hat niemand die Nachricht empfangen. Abgeschlossen wird ein Frame mit sieben rezessiven Bits, dem End Of Frame (EOF). Dabei wird absichtlich die Bit Stuffing Regel verletzt, so dass jeder diese Marke eindeutig erkennen kann. Als letztes kommen noch 3 rezessive Inter Frame Bits. Sie geben den Teilnehmer die nötige Zeit, um die Nachricht in den Empfangspuffer zu schreiben und sich auf die nächste Nachricht vorzubereiten. Sollte einem Teilnehmer ausnahmsweise diese Pause nicht ausreichen, so kann er ein Overload Frame senden. Dieses besteht aus 6 dominanten Bits und verzögert einfach den Anfang der nächsten Nachricht. CAN 2.0B Frames beginnen auch mit einem Start Bit. Darauf folgen die ersten 11 Bit des Identifiers. An der Bitposition, an der standard Frames das RTR Bit haben, steht allerdings immer eine 1. Anschließend kommt das IDE Bit, welches zur Identifikation des Frame Formates hier auch den Wert 1 hat. Jetzt folgen die letzten 18 Bit des Identifiers und das RTR Bit. Nach zwei weiteren Bits, die reserviert sind und immer den Wert 0 haben, sind extended Frames mit standard Frames wieder identisch.
| ||||
| Historisch gewachsen gibt es zwei unterschiedliche Implementierungen des CAN 2.0 Standards: FullCAN und BasicCAN. Sie unterscheiden sich vorallem die Empfangsfilter betreffend. BasicCAN verwendet eine Maske und einen Code. Die Maske gibt an, welche Bits des Identifiers signifikant für die Filterung sind. Der Code gibt an, welchen Wert die einzelnen Bits haben müssen. Nur wenn alle signifikanten Bits den Wert der Codebits haben wird die Nachricht akzeptiert. Da man mit jedem Bit, das man als nicht-signifkant definiert, zwei neue Identifier durch den Filter lässt, kann man in vielen Fällen nicht engmaschig genug filtern und muss softwaremäßig nacharbeiten. Das kostet aber teure Prozessorzeit. FullCAN kennt keine Masken. Vielmehr gibt es mehrere Empfangspuffer, für die jeweils ein Code angegeben werden kann. Ein softwaremäßiges Nachfiltern entfällt damit. Allerdings ist die maximale Anzahl der Nachrichten, die man empfangen kann, durch die Anzahl der Empfangspuffer beschränkt. Mittlerweile gibt es CAN Chips, die beide Arten und auch neuere Techniken der Filterung beherrschen, so dass die irreführenden Begriffe FullCAN und BasicCAN veraltet sind. |
Ein Design Ziel von CAN war es, dass möglichst viele Fehler bereits von der Hardware erkannt und behandelt werden. Damit spart man Rechenleistung in den CPUs und aufwändige Protokolle in höheren Layern. Zwei der fünf möglichen Fehler können vom Sender entdeckt werden. Das erste ist ein Bitfehler. Dieser liegt vor, wenn außerhalb der Arbitrierungsphase und des ACK Slots das gelesene Bit nicht mit dem geschriebenen übereinstimmt. Das zweite ist ein Acknowledge Fehler. Dieser liegt vor, wenn der Sender im ACK Slot keine 0 ließt. Die restlichen drei möglichen Fehler können von den Empfängern erkannt werden. Zuerst kann ein Knoten eine Verletzung der Bit Stuffing Regel erkennen. Geschieht das außerhalb des EOF Feldes, so ist das offensichtlich ein Empfangsfehler. Außerdem kann ein Teilnehmer feststellen, dass die berechnete Prüfsumme nicht mit der Empfangenen übereinstimmt. Zu letzt kann eine allgemeine Verletzung des Nachrichten Formats erkannt werden. Das geschieht z.B. wenn die 6 rezessiven Bits des EOF ausbleiben oder auch, wenn ein Teilnehmer standard Frames erwartet, aber extended Frames empfängt. In jedem der fünf Fehlerfälle kommt es zur selben Fehlerbehandlung. Der jenige, der einen Fehler erkannt hat, sendet ein Error Frame auf den Bus, um alle anderen von dem Fehler in Kenntnis zu sezten. Das Error Frame besteht aus 6 dominanten Bits und überschreibt somit alles andere auf dem Bus. Auch hier wird absichtlich die Bit Stuffing Regel verletzt, um das Signal eindeutig erkennbar zu machen. Wenn ein Knoten selber keinen Fehler erkennt, aber ein Error Frame empfängt, so reagiert er auf die vermeintliche Verletzung der Bit Stuffing Regel mit dem Senden eines Error Frames. Das bedeutet zwar, dass ein Error Frame auf bis zu 12 Bits anwachsen kann, hat aber den Vorteil, dass jeder Busteilnehmer ein Error Frame sendet und damit im Fehlerzustand ist. Da jeder Teilnehmer im Fehlerfall die empfangene Nachricht verwirft, wird somit garantiert, dass eine CAN Nachricht entweder von allen oder von keinem angenommen wird. Das ist sehr wichtig für die Synchronisation der Busteilnehmer. Nach dem Error Frame wird die Nachricht einfach erneut gesendet.
Hat ein Knoten einen permanenten Fehler, wie z.B. einen defekten Eingang, so würde er den kompletten Bus ständig mit Error Frames beschreiben und somit lahm legen. Um das zu verhindern, hat man eine Selbstdiagnose der Busteilnehmer spezifiziert. Jeder CAN Baustein besitzt zwei Error Counter, einen für den Empfang (REC) und einen für das Senden (TEC). Kommt es zu Fehlern, so werden diese Zähler incrementiert. Wenn die Fehler wieder ausbleiben, so werden die Zähler mit der Zeit wieder decrementiert. Überschreitet einer der beiden Zähler eine Schwelle, so verhält sich der Teilnehmer Error Passive. Das bedeutet, dass er zwar ganz normal am Busgeschehen teilnimmt, aber im Fehlerfall nur noch passive Error Frames sendet. Diese bestehen aus 6 rezessiven Bits und stören damit den restlichen Bus nicht. Überschreitet der TEC eine zweite Schwelle, so geht der Baustein Bus Off. Er nimmt nicht mehr am Geschehen teil und kann aus diesem Zustand nur durch einen Benutzereingriff wieder zurückgesetzt werden. Die Regeln zum Erhöhen und Erniedrigen der Zähler sind äußerst komplex. Beispielhaft sollen hier die folgenden, vergleichsweise einfachen Regeln erläutert werden. Wenn ein Sender einen ACK Fehler erkennt, so bedeutet das, dass niemand seine Nachricht korrekt empfangen hat. Wenn kein Bitfehler vorliegt und nicht alle anderen Teilhemher Bus Off sind, so ist seine Verbindung zum Bus sehr wahrscheinlich unterbrochen. Als Konsequenz wird der TEC erhöht. Ist die Verbindung wirklich unterbrochen, so wird der Baustein sehr bald Bus Off gehen und diesen Zustand nach oben melden. Ein zweiter einfacher Fall liegt vor, wenn ein Baustein immer eine Differenz in der CRC Summe erkennt. Insbesondere, wenn er diesen Fehler immer als erster bemerkt liegt die Vermutung nahe, dass es sich um ein lokales Problem handelt. Sollte das der Fall sein, so wird sich der Baustein ziemlich schnell Error Passive verhalten und den Bus nicht weiter stören. Zu beachten ist, dass im Error Passive Zustand die nachrichtenbasierte Synchronisation der Teilnehmer nicht mehr gewährleistet ist, da der Baustein im Fehlerfall die Nachricht verwirft, diese aber nicht neu gesendet wird.
Ein Chip, der nur CAN 2.0A Frames kennt, kann nicht an einem Bus betrieben werden, auf dem CAN 2.0B gesprochen wird. Neben Bausteinen, die beide Formate können, gibt es solche, die sich CAN 2.0B passiv verhalten. Das bedeutet, dass sie zwar selber keine extended Frames lesen und schreiben können, beim Empfang aber auch keine Error Frames senden. Die Erweiterung auf 29 Bits für den Identifier war nötig, um trotz grober Filter genügend Flexibilität für Unterteilung der Nachrichten in Kategorien zu haben. Dafür bezahlt man allerdings mit einer geringeren Nettodatenrate. Mit standard Frames kommt man bei 1 MBit/s und 8 Datenbytes auf ein Maximum von 576,6 kBits/s netto. Mit extended Frames kommt man nur auf maximal 488,5 kBit/s. Da eine Nachricht ohne Daten auch einen Informationsgehalt besitzt, sind diese Zahlen nicht sehr repräsentativ.
Fast jeder Hardwarehersteller hat eigene CAN Lösungen in seinem Sortiment. So gibt es z.B. Microcontroller mit integriertem CAN Interface oder aufgebohrte PALs, die man remote über CAN steuern kann. Um eine bestehende Hardware Zugang zu einem CAN Bus zu ermöglichen eigenen sich sogenannte stand alone CAN Controller, wie z.B. der SJA1000 von Philips. Er ist eine komplette Implementierung der CAN 2.0 Spezifikation mit einem parallelen Interface. Üblicherweise wird er wie externes RAM an einen Microcontroller angeschlossen. Man kann ihn allerdings auch an den Druckerport anschließen, und so mit dem Computer Zugang zu einem CAN Bus erlangen. Ausgangsseitig spricht der SJA1000 TTL. Deshalb braucht man noch einen CAN Transceiver, der die Spannungen umwandelt. Abgesehen von noch ein paar Widerständen und Kondensatoren ist nicht mehr Hardware nötig. Alles zusammen bekommt man für unter 10 Euro. Auf dem Schaltplan sind noch zwei Varistoren und eine Spule eingezeichnet. Die Varistoren bieten einen Schutz vor Überspannung und die Spule verbessert die Signalqualität bei hohen Bitraten. Für ein einfaches Setup braucht man diese Komponenten allerdings nicht.
| ||||
| ||||
| Das Datenblatt des SJA1000 ist sehr empfehlendswert, da es den Controller ausführlich beschreibt. Deshalb folgt hier nur ein kleiner Überblick über die Möglichkeiten und die Bedienung. Der SJA1000 besitzt zwei verschieden Modi. Der BasicCAN Modus ist ein Kompatibiltätsmodus zum PCA82C200, einem älteren Baustein von Philips. In diesem Modus verhält sich der Baustein CAN 2.0B passiv. Im sogenanten PeliCAN Modus kann er aktiv CAN 2.0B sprechen und bietet noch weitere Features an, wie z.B. die automatische Baudratenerkennung und einen listen only Modus - beides sehr praktisch, wenn man ein unbekanntes Netz analysieren möchte. Um mit dem Controller zu kommunizieren, werden 8-bit Werte in seine Register geschrieben und daraus gelesen. Je nach Modus existieren 31 oder 39 Register mit eindeutigen 8-bit Adressen. |
Im Control Register kann man vier mögliche Interrupts maskieren. Diese sind ein Receive Interrupt, ein Transmit Interrupt, ein Error Iterrupt und ein Data Overrun Interrupt. Die ersten beiden werden ausgelöst, wenn eine Nachricht fehlerfrei empfangen bzw. gesendet wurde. Ein Error Interrupt tritt auf, wenn einer der beiden Error Counter (TEC oder REC) die erste Schwelle überschreitet. Ein Data Overrun liegt vor, wenn der Controller keine Puffer mehr frei hat, um eine empfangene Nachricht zu speichern. Der SJA1000 besitzt nämlich einen 64 kB Ringpuffer für empfangene Nachrichten. Die Empfangsregister beinhalten immer den Wert der ältesten Nachricht. Hat man eine Nachricht ausgelesen, teilt man dem Controller mit, dass er zur nächsten Nachricht weitergehen soll. Das geschieht durch das Setzen eines Bits im Command Register. Dort kann man auch das Senden einer Nachricht, die man zuvor in die Senderegister geschrieben hat, auslösen. Falls einige Interrupts maskiert sind oder man generell keine Interrupts behandeln möchte oder kann, bietet das Interrupt Register die Möglichkeit, den Controller zu pollen. Zu guter letzt gibt es noch das Status Register, das Informationen über Fehlerereignisse und den Zustand der Sende- und Empfangspuffer enthält. Um den Controller konfigurieren zu können, muss er im Reset Modus sein. Dazu zieht man entweder die /RST Leitung auf Masse oder setzt das erste Bit im Controll Register auf 1. In diesem Zustand kann man u.a. die Empfangsfilter und die Baudrate einstellen.
No comments:
Post a Comment