CAN Controller Implementierung

---

Diese Kapitel beschreibt eine der am häufigsten verwendeten Implementierungen eines CAN Controllers wie er als „Intellectual Property“ in integrierten Schaltungen Verwendung findet. Es sei speziell darauf hingewiesen dass auch andere Implementierungen möglich und verfügbar sind.

Block Diagramm

Das Blockdiagramm gibt einen vereinfachten Eindruck über die einzelnen Blöcke des beschriebenen CAN Controllers.

Figure 24:  CAN Controller Blockdiagram

Das CAN Module Interface dient zur Verbindung des CAN Controllers mit einem externen oder internen Microprozessor-Bus und damit als Interface zwischen den in Hardware bzw. in Software implementierten CAN Funktionen.

Zur Konfiguration der CAN Hardware dient ein Register-Block für die Einstellung der Funktionalität, die Freigabe von Interrupts bzw. für die Grundeinstellung des Dateninterfaces zwischen dem Prozessor und dem „FIFO / Message RAM“ Block.

Dieser dient als Buffer für zu sendende oder empfangene Datenpakete und reduziert die Prozessorlast durch Zwischenspeicherung der Datenpakete.

Der Message Handler überwacht die einwandfreie Übertragung auf Paketebene, während der Bit Stream Processor die Bit-Übertragungs-Ebene implementiert.

Über den Prescaler wird die interne Verarbeitungsgeschwindigkeit des CAN Controllers bezogen auf die Bus-Clock eingestellt. Damit auch die Taktrate der „Time Quanten“ und des CAN Bus Geschwindigkeit.

Die „Bit Timing Logic“ erzeugt das effektive Bussignal für die Senderichtung und die Abtastung für die Empfangsrichtung. Das Schieberegister synchronisiert die Daten in der Sende- und Empfangsrichtung mit dem Oversampling Takt.

CAN Controller Register

Für die CAN Controller Hardware Funktionalität sind in dem hier verwendeten embedded Referenzdesign folgende Register implementiert:

Control Register

Figure25: CAN Controller Control Register

Die Bits 1, 2 und 3 des CAN Control Registers ermöglichen die Freigabe von Interrupts für „Global Interrupt Enable“ (IntEn), „Status Change Interrupt Enable“(SIE ) und „Error Interrupt Enable“ (EIE).

Das Bit 5 , DAR(Disable Automatic Re-transmission) dient zum Ein- bzw. Ausschalten der automatischen Funktion für das erneute Senden von Datenpaketen (siehe ISO 11898, 6.3.3. Recovery Management) bei Verlust der Bus Arbitration bzw. bei erkannten Übertragungsfehlern. Diese Möglichkeit, das Wiederholen von zu sendenen Paketen zu unterdrücken wird auch bei einem „Time Triggered CAN“ verwendet.

Bit 6, CCE(Configuration Change Enable) ermöglicht durch Setzen den Zugriff auf die Konfigurationsregister des CAN Controllers und trägt im nicht gesetzen Zustand zur Betriebssicherheit bei, indem versehentliches Beschreiben der Konfiguration verhindert wird.

Das INIT-Bit (Bit 0) started die Aufnahme bzw. Wiederaufnahme der regulären CAN Bus Aktivität dieser Node durch eine gezielte Wartezeit von 129 Bus Idle States (je 11 rezessive Bits) also insgesamt 129 * 11 Bit Clock Zyklen. Innerhalb dieser Wartezeit synchronisiert sich der CAN Controller auf die Busaktivität auf. Erst nach dieser Wartezeit kann die Node wieder normale Messages senden und empfangen.

Als letztes aktives Bit in diesem Register bleibt das Test-Bit (Bit 7) das den „Test Modus“ aktiviert.

Status Register

Figure 26: CAN Controller Status Register

Während das Control Register verschiedene Einstellungen des Controllers ermöglicht, liefert das Status Register, CAN Bus relevante Informationen an die Software. Die Bits 0,1 und 2 enthalten den LEC - „Last Error Code“ also die Information über den zuletzt aufgetretenen Fehler. Die Kodierung ist in dieser CAN Controller Implementierung wie folgt:

LEC	Beschreibung
000	No Error
001	Stuff Error (Bit Stuffing Fehler aufgetreten)
010	Form Error (Formatierungs Fehler eines Rahmens)
011	ACK Error (Fehlendes Acknowledge eines gesendeten Rahmens)
100	Bit Fehler „1“ ( eine „1“ wurde gesendet, eine „0“ gelesen )
101	Bit Fehler „0“ ( eine „0“ wurde gesendet, eine „1“ gelesen )
110	CRC Error ( errechneter CRC ungleich übermittelter CRC Code )
111	Nicht verwendet

Table 6: Letzter Fehler - Codierung

Bit 3, TxOK(Transmitted Message sucessfully)und Bit 4, RxOK (Received Message sucessfully) werden von der CAN Hardware gesetzt wenn eben diese Bedingungen eintreten. Sind die Bits gleich „0“ wurde seit der letzten Abfrage kein Rahmen gesendet/empfangen.

Bit 5, Epass(Error passive) liefert die Information ob der CAN Controller im „passiven“ (1) bzw. im „aktiven“ (0) Error Mode ist.

Bit 6, EWarn „Error Warning“ Status liefert einen Schwellwert der Anzeigt ob eine Fehlerhäufung auftritt. Das Bit wird gesetzt wenn der „Error Counter“ den Wert 96 überschreitet.

Schliesslich noch Bit 7, Boff   „Bus Off“ Status, das eine Indikation über den Bus Status gibt. Im „Bus Off“ (1) Status ist der CAN Controller im „Off“-Status und hat sich vom CAN Bus abgekoppelt.

Error Counter Register

Figure 27: CAN Controller Error Counter Register

Das „Error Counter“ Register enthält separate Zähler für Fehlerereignisse in Empfangs- und Sende-Richtung, sowie ein Flag das den aktuellen Fehler-Modus kennzeichnet.

Übertragungsfehler werden vom „Receive Error Counter“ REC [6:0] bzw. vom „ Transmit Error Counter“ TEC<> [7:0] gezählt.

Überschreitet der Receive Error Counter den in ISO 11898 spezifizierten Level, so wird das „RP“ Bit gesetzt und die Node geht in den „Passive“ Error Mode bei dem nur noch rezessive Bits gesendet werden.

Bit Timing Register

Figure 28: CAN Controller Bit Timing Register

Baud Rate Prescaler

Die Bits [5:0], BRPn des Bit Timing Registers setzen den Baud Rate Prescaler für den „Zeit Quanten Takt“ und müsste daher eigentlich Sampling-Rate-Prescaler heissen. Der Takt wird aus der CAN Controller Clock gewonnen (System Clock), die dem Block von Aussen zur Verfügung gestellt wird. Das Teilverhältnis berechnet sich in diesem spezifischen Fall aus dem eingetragenen Wert plus „1“.

Eine Erweiterung des „Baud Rate Prescalers“ befindet sich im Baud Rate Prescaler Extension Register (siehe 5.2.5 ) mit den Bits BRPE [3..0]. Diese bilden zusammen mit den BRP [5..0] Bits einen Einstellungsbereich von 10 Bit und damit Teilverhältnisse von 1 bis 1023.

Synchronisation Jump Width

Wie in 1.3.4 „Resynchronisation“ beschrieben werden „Zeit Quanten“ je nach Synchronisationsverlauf in eine Bit-Zeit eingefügt oder unterdrückt. Die Anzahl der in einem „Re-Synchronisationsschritt“ eingefügten bzw. unterdrückten „Time Quanta“ wird mit der „Synchronisation Jump Width“, SJW [1:0] in diesem Register festgelegt.

Phase Buffer 1

Die Bits TS1_x  (Bit [11:8] ) legen die Anzahl der Zeit Quanten im Phase Buffer 1 (siehe 1.3.1), also in dem Zeitinterval vor dem Abtastzeitpunkt fest. Werte von 1 .. 15 sind in diesem CAN Controller bei diesem Feld zulässig und werden als „n+1“ Zeit-Quanten interpretiert.

Entsprechend der ISO Norm (siehe 1.3.4.1 Bit Segmentierung) wurde bei dieser Implementierung die Anzahl Zeit-Quanten für das „Propagation Segment“ und das „Phase Buffer 1 Segment“ zusammengezogen und wird durch eine Einstellungsmöglichkeit representiert. Eine separate Einstellungsmöglichkeit für das Propagation Segment ist deshalb nicht vorhanden.

Phase Buffer 2

Die Bits TS2_x (Bit[14:12] ) legen die Anzahl der Zeit Quanten im Phase Buffer 2 (siehe 1.3.1), also in dem Zeitinterval nach dem Abtastzeitpunkt fest. Werte von 0..7 sind in dieser Implementierung des CAN-Ips zulässig und werden wie in den anderen Feldern als „n+1“ Zeit-Quanten interpretiert.

Baud Rate Prescaler Extension Register

Figure 29 : CAN Controller Baud rate Prescaler Register

Die Baud Rate Prescaler Extension Bits stellen die höherwertigen Bits des Baud Rate Prescalers „BRP [9:6]“ dar. Zusammen mit dem PRP lassen sich damit Teilverhält-nisse bis zu 1023 realisieren.

In der hier beschriebenen Realisierung des CAN Controllers wurde festgestellt dass sich durch den eingeschränkten Bereich des Prescalers (nur mit den 6 Bits im Bit Timing Register) keine genaue Justierung auf übliche Baud-Raten (125 kBit, 500 kBit, 1 Mbit) verwirkliche ließ. Deshalb wurde eine zusätzliche Erweiterung implementiert.

Test Register

Figure 30: CAN Controller Test Register

Das Testregister ermöglicht die Aktivierung spezieller Betriebsmodi und die direkte Kontrolle der CAN Bus Leitungen.

Basic Mode

Im BasicCAN Mode (Bit 2) wird bei dieser CAN Controller Implementierung das Datenhandling über ein Transmit (IF1) und ein Receive (IF2) Register Set abgewickelt. Dieser Modus ist der „einfache“ Betriebsmodus des CAN Controllers bei dem die Message ID´s per Software ausgewertet werden müssen.

Der automatische Vergleich der CAN-ID´s über Hardware (Full CAN) ist ausgeschaltet und jede CAN Message, unabhängig von dessen Message Identifier wird eingelesen und über einen Interrupt an das System gemeldet. Die Selektion der Message ID erfolgt danach in Software. Wird dieses Bit mit „1“ geschrieben ist der Basic Mode aktiviert.

Figure 31: Normal Mode

Silent Mode

Das Silent Mode Bit (Bit 3) setzt den CAN-Controller in einen Modus bei dem alle Daten auf dem Bus empfangen aber keine Daten gesendet werden können.

 

Figure 32: Silent Mode

Für den Fall, dass der CAN Core Bits senden muss (ACK etc.), werden diese intern vom Ausgang zum Eingang gerouted aber nicht am Transmit Ausgang ausgegeben. Damit kann ein normaler Betrieb simuliert werden ohne den Bus selbst zu beeinflussen oder zu stören.

Loop Back Mode

Im Loop Back Mode wird das CAN Transmit Signal intern zum CAN Receive Signal gerouted. Der externe Receive Pin wird nicht mehr eingelesen und Daten die vom Physical Layer Baustein kommen sind nicht sichtbar.

 

Figure 33: Loop Back Mode

Wird das „Lback“ Bit (Bit 4) gesetzt ist der Loop Back Mode aktiviert. Loop Back Mode und Silent Mode können auch simultan eingesetzt werden, die Node kann dann nur mit sich selbst kommunizieren.

 

Figure 34: Loop Back und Silent Mode

Tx0 Bit

Bit 5 des Test Register ist das „Tx0“-Bit. Wird dieses Register gesetzt so liegt am Transmit-Ausgang ein “dominanter” Pegel an.

Tx1 Bit

Bit 6 des Test Register ist das “Tx1”-Bit. Durch das Setzen dieses Bits wird der Transmit-Ausgang einen “recessiven” Pegel ausgeben.

Rx Bit

Über das „Rx“ Bit kann ein CAN Bus Data Sample erzeugt werden. Das Bit spiegelt den aktuellen Status des RX-Pins wieder und kann direkt gelesen werden.

Dieses Bit ist verständlicherweise nur „read only“, also nur lesbar.

Message Interface Registersätze

Die im Rahmen diese Dokuments besprochene Implementierung eines CAN Controllers besitzt zwei Sätze von Registern für die Weiterverarbeitung von empfangenen bzw. zu sendenden CAN Nachrichten. Die beiden Registersätze werden dabei als

• IF1 - „Interface Registersatz 1“ und

• IF2 - „Interface Registersatz 2“

bezeichnet. Alle 11 Register innerhalb eines jeden der beiden Registersätze, sind 16 Bit breit. Die eigentliche Aufgabe dieser Registersätze ist je nach Verwendung als Basic CAN oder als Full CAN , unterschiedlich.

Im Basic CANBetrieb (siehe 5.2.6 Test Register) werden die beiden Register Sätze  direkt als Message Buffer verwendet. Es gibt in jede Übertragungsrichtung nur einen Satz von Registern in denen die Daten gespeichert werden. IF1 enthält dabei die „Transmit“ Daten-Register,IF2 die „Receive“ Daten-Register.

  

Figure 35: Basic CAN

Im Full CANBetrieb sind beide Registersätze ohne direkte Zuordnung (receive/transmit) benutzbar und dienen als Transferspeicher und Commando Interface zwischen dem Prozessor und einzelnen Messages im „Message RAM“ (Statisches RAM das pro programmierter Message ID den Inhalt eines kompletten zu sendenden oder bereits empfangenen Rahmens speichert). Dieses „Double buffering“ ist notwendig um zu vermeiden dass Daten teilweise überschrieben werden, falls ein neues Paket geladen oder gespeichert wird bevor die Daten komplett zum Host übertragen wurden.

Figure 36: Full CAN

Jeder Registersatz besteht aus folgenden Registern:

Adresse			Register
IF1	IF2
CAN Base + 0x20	CAN Base + 0x80		Command Request Register
CAN Base + 0x24	CAN Base + 0x84		Command Mask Register
CAN Base + 0x28	CAN Base + 0x88		Mask 1 Register
CAN Base + 0x2C	CAN Base + 0x8C		Mask 2 Register
CAN Base + 0x30	CAN Base + 0x90		Arbitration 1 Register
CAN Base + 0x34	CAN Base + 0x94		Arbitration 2 Register
CAN Base + 0x38	CAN Base + 0x98		Message Control Register
CAN Base + 0x3C	CAN Base + 0x9C		Data A1 Register
CAN Base + 0x40	CAN Base + 0xA0		Data A2 Register
CAN Base + 0x44	CAN Base + 0xA4		Data B1 Register
CAN Base + 0x48	CAN Base + 0xA8		Data B2 Register

CAN Base ist dabei die Basis-Adresse der CAN Registersätze.

Command Request Register

Figure 37 : CAN Controller Command Request Register

DieBits 0..5 , MsgNo[n] werden von derCAN Treibersoftware geschrieben. Sobald eine gültige Message Nummer in das Command Request Register geschrieben wurde wird das Bit 15 , Busy gesetzt und  das komplette „CAN Message Objekt“ wird zwischen dem Message RAM und dem Registersatz übertragen. Die Übertragungsrichtung wird durch das Wr/Rd Bit im Command Mask Register (siehe 5.3.2) bestimmt.

Das schreiben des Command Request Registers wird also der abschliessende Vorgang sein um einen Message Transfer auszulösen. Vorher müssen alle anderen Register eines Message Interface Registersatzes programmiert werden, da sonst keine einwandfreie Funktion gewährleistet ist.

Die MsgNo [5..0] Bits stellen die Adresse der zu schreibenden/lesenden Message- Datenstruktur im Message RAM dar. Es können maximal 32 solche Datenstrukturen im Message RAM angelegt werden.

Da 6 Bits für die Message Nummer verfügbar sind ist eine Redundanz vorhanden die von der Controller Hardware automatisch korrigiert wird. Ungültige – weil zu grosse Message Nummern – werden automatisch auf gültige Message Nummern zwischen 0 und 31 reduziert.

Figure 38: Message Object Addressing

Die Message Number ist nicht zu verwechseln mit der CAN-ID, sie indiziert lediglich einen der 32 möglichen Speichersätze im Message RAM. Die CAN-ID die diesem Speichersatz zugeordnet ist wird über die beiden nachfolgend beschriebenen Arbitration Register gesetzt und als Teil des Message Objekts gespeichert.

Bit 15, Busy wird von der CAN Controller Hardware gesetzt um einen gestarteten Transfervorgang zu markieren. Nach der Transaktion wird das „Busy“ Bit zurück-gesetzt.

Command Mask Register

 

Figure39: CAN Controller Command Mask Register

Die Bits 0 ... 6 haben im Command Mask Register unterschiedliche Bedeutung in Abhängigkeit von der Übertragungsrichtung. Das einzige Bit das seine Bedeutung bei behält ist das Bit 7, Wr/Rddas anzeigt in welche Richtung übertragen werden soll.

Bits [6..0] – schreiben des Message Buffers (Message Object)

Ist das Bit 7 eine „1“ ist ein Schreibzugriff vorgesehen. Daher haben die Bits [6..0] folgende Bedeutung.

Bit 0, 1  sind die beiden Flags die den effektiven Transfer von jeweils 32-Bit Worten von den Data-Registern (A1/A2) bzw. Data-Registern (B1/B2) zum Message Buffer freigeben („write“). Bit 0 ermöglicht den Transfer der Datenbytes [7..4], Bit 1 den Transfer von Datenbytes [3..0]. Sind die DataA und DataBBits Null, so werden keine Daten in die entsprechenden Daten-Register (A1,A2,B1,B2) übertragen.

Bit 2, TxReq ist ein Transmit Request Control Bitdas indiziert dass die Message nach der Übertragung in das „Message RAM“ auf die Übertragung über den CAN Bus wartet. Dazu wird das TxReq Bit im adressieren „Message Object“ ebefalls gesetzt. Wurde die Übertragung vom „Message Handler“ ausgeführt ist das Bit = 0.

Bit 3, ClrIPd ist das Clear Interrupt Pending Bit. Bei einer Transaktion bei der ein Message Buffer beschrieben wird , wird dieses Bit ignoriert.

Bit 4, Ctrl ist ein Enable-Bit das den Transfer der Control-Bits für ein Message Object freigibt oder sperrt.

Bit 5, Arb ist ein Enable-Bit das den Transfer der Arbitration Bits, also der Message-ID in das adressierte Message-Object freigibt oder sperrt.

Bit 6, Mask ist ein Enable-Bit das den Transfer der ID-Maske in das adressierte Message Object freigibt oder sperrt.

Bits [6..0] – lesen des Message Buffers (Message Objects)

Ist das Bit 7 eine „0“, so wird ein Lesezugriff ausgeführt. Die Bits [6..0] haben dann folgende Funktion:

Bit 0, 1  sind die beiden Flags die den effektiven Transfer von jeweils 32-Bit Worten vom Message-RAM zu den Data-Registern (A1/A2) bzw. Data-Registern (B1/B2) freigeben („read“). Bit 0 ermöglicht den Transfer der Datenbytes [7..4], Bit 1 den Transfer von Datenbytes [3..0]. Sind die DataA und DataB Bits Null, so werden keine Daten in die entsprechenden Daten-Register (A1,A2,B1,B2) übertragen.

Bit 2, New Dataist im „Read“-Fall ein Control Flag. Durch das Setzen dieses Bits wird das New Data Bit im Message Object gelöscht (auf 0 gesetzt). Damit wird zum Message Handler kommuniziert dass die Datenstruktur vom Prozessor gelesen wurde.

Bit 3, ClrIPd ist das Clear Interrupt Pending Bit. Bei einer Transaktion bei der ein Message Buffer beschrieben wird , wird dieses Bit ignoriert.

Bit 4, Ctrl ist ein Enable-Bit das den Transfer der Control-Bits für ein Message Object freigibt oder sperrt.

Bit 5,Arbist ein Enable-Bit das den Transfer der Arbitration Bits, also der Message-ID in das adressierte Message-Object freigibt oder sperrt.

Bit 6, Mask ist ein Enable-Bit das den Transfer der ID-Maske in das adressierte Message Object freigibt oder sperrt.

Mask 1 Register

Figure40: CAN Controller Mask 1 Register

Messages auf dem CAN Bus können vorselektiert werden. Hat eine Node nur Interesse an bestimmten CAN-IDs oder CAN-ID Adress-Bereichen so kann über eine Maske diese ID oder der gewünschte ID Adress-Bereich selektiert werden.

Das Setzen eines Bits bewirkt die Aktivierung des entsprechenden Bits aus dem Arbitration 1 Register für den Adressvergleich im Message Handler. Ist das Bit = 0 so ist das entsprechende Bit im Arbitration 1 Register irrelevant für den Adressvergleich.

Das Mask 1 Register enthält die in ein CAN Message Object zu übertragenden niedrigerwertigen 16 Bits Mask [15..0] dieser Selektionsmaske. Die restlichen 13 Mask Bits werden im Mask 2 Register abgelegt.

Das Setzen einer Maske bewirkt dass CAN Messages auf dem Bus, die nicht innerhalb der Maske liegen von dieser Node ignoriert werden (nur Full CAN!).

Im Basic CANModus ist eine Vorauswahl über Mask Bits nicht möglich, daher müssen alle empfangenen CAN Rahmen eingelesen und per Software ausgewertet werden.

Mask 2 Register

Figure 41 : CAN Controller Mask 2 Register

Nebend den eben schon beschriebenen höherwertigeren Masken-Bits [28..16] enthält das Mask 2 Register noch zwei Control Flags.

Bit 14, Mdir,dieses Bit unterdrückt die Verwendung des „Dir“ Bits als Kriterium ob eine CAN Message auf dem CAN Bus übernommen wird oder nicht. Ist das Bit gesetzt (1) so wird das „Dir“ Bit für die Akzeptanz einer Message verwendet. Das „Dir“ Bit befindet sich im Arbitration 2 Register.

Bit 15, MXtd, diese Bit maskiert das „Xtd“ Bit im Arbitration 2 Register. Damit wird das Kriterium „11 Bit Identifier“ oder „29 Bit Identifier“ für die Akzeptanz einer CAN Message vom Bus ein- bzw. ausgeschaltet.

Arbitration 1 Register

Figure 42 : CAN Controller Arbitration Register 1

Die Bits [15..0] des Arbitration 1 Registers speichern die niedrigwertigeren 16 Bit der CAN-ID für das durch die „Message Number“ im Control Register selektierten „Message Objects“ wieder. In Abhängigkeit vom „Wr/Rd“ Bit im Command Mask Register wird dieser CAN Identifier aus dem „Message Object“ gelesen oder in ein solches geschrieben.

Arbitration 2 Register

Figure 43 : CAN Controller Arbitration Register 2

Die Bits [12..0] des Arbitration 2 Register beinhalten die höherwertigen Bits der referenzierten CAN-ID. Zusammen mit den 16 Bits aus dem Arbitration 1 Register bilden sie die 29 Bit lange CAN Adresse. Wird nur eine 11 Bit CAN-ID verwendet sind diese Bits unbenutzt.

Bit 13, Dirist das „Direction Bit“ das angibt ob dieses „Message Object“ auf dem CAN Bus empfangen  oder gesendet werden soll.

Das „Message Object“ (Datenstruktur im Message RAM) soll gesendet werden wenn dieses Bit = 1 ist und ist auf Empfang wenn diese Bit = 0 ist. Das „Dir“ Bit existiert equivalent im Message Object.

In Empfangsrichtung gibt es zwei mögliche Rahmen die empfangen werdem können, einen Remote Frameund einen Data Frame. Wird ein Remote Frame empfangen der die passende CAN-ID besitzt, so wird das TxReq Bit im „Message Object“ gesetzt und damit dieses Message Object für die Übertragung auf dem Bus freigegeben. Bei einem Data Frame werden die empfangenen Daten in die Datenfelder des Message Objects eingetragen.

Bit 14, Xtdist das Bit das zwischen einem Basic Rahmen und einem Extended Rahmen unterscheidet. Ist das Bit gesetzt, so wird dieses Message Object als Extended Rahmen behandelt (gesendet bzw. empfangen) und mit einer 29 Bit CAN-ID verarbeitet im anderen Fall wird die Basic-Adresse mit 11 Bit verwendet.

Bit 15, MsgVal ist ein „Handshake Bit“ das ein Message Object sozusagen „scharf“ schaltet. Nur wenn diese Bit gesetzt ist wird die Message Handler Hardware ein Message Objekt verarbeiten (auf dem Bus senden oder empfangen).

Es ist Sache der CAN Software die Message Objekte zu verwalten und diese zu aktivieren falls das System es erfordert.

Message Control Register

Figure 44: Message Control Register

Bits [3..0], DLC[n] Data Length Code enthält die Anzahl von Daten-Bits die für das entsprechende Message Objekt relevant sind.

Transmit

Dieses 4 Bit Feld wird bei der Übertragung eines Daten-Rahmens in die entsprechen-den Bits des Control Feldes eines Datenrahmens (siehe 2.2.1) eingetragen.

Receive

Ist das Message Object ein „Receive“-Object so werden die DLC Bits im Message Control Register mit den empfangenen DLC-Bits aus dem „Control Feld“ des empfangenen Datenrahmens überschrieben.

Bit 7, EoB ist ein spezielles Flag das zur Kennzeichnung eines Message Objects als „letztes Objekt“ innerhalb eines FIFO-Buffers dient. In der beschriebenen Implementierung des CAN Contollers kann das Message RAM bzw. ein Teil davon als FIFO für Message Objekte arbeiten. Um das Ende dieses FIFO Buffers zu kennzeichnen wird das Bit „End of Buffer“ verwendet.

Bit 8, TxRqst kennzeichnet ein Message Objekt als „fertig zum Versand“. Der Message Handler wird ein Objekt bei dem das TxRqst Bit gesetzt ist bei nächst möglicher Gelegenheit auf dem Bus übertragen.

Diese Bit ist nicht zu verwechseln mit dem MsgVal Bit im Arbitration 2 Register das ein ganzes Message Objekt als aktiv bzw. passiv markiert.

Bit 9, RmtEn dient als Gate für das automatische Setzen des TxRqst auf Grund eines empfangenen Remote Frames mit der CAN-ID des jeweiligen Message Objects.

Wir erinnern uns, ein Remote Frame ist ein „Request“ also eine Anfrage nach einer spezifischen Information und wird mit der gleichen CAN-ID der gewünschten Message, von einer Node gesendet die diese Information benötigt. Als Antwort wird von der Node die diese CAN-ID benutzt, die gewünschte Message gesendet. Dieser Vorgang kann durch den Message Handler automatisiert werden. Ist das RmtEn Bit gesetzt so sendet der Message Handler automatisch (ohne Einfluss der CAN Software) das im Message RAM liegende Objekt. Ist eine automatische Antwort nicht gewünscht (weil beispielsweise die Daten veraltet sind) so muss das RmtEn Bit zurückgesetzt werden.

Bit 10, RxIE ist ebenfalls ein Enable Bit. Dieses Bit ermöglicht bzw. blockiert das Setzen des IntPend Bits für den Fall dass eine CAN Message empfangen wurde. Über das Interrupt Pending Bit (IntPend) wird signalisiert dass dieses Message Objekt einen Interrupt ausgelöst hat.

Bit 11, TxIE verhält sich äquivalent wie das RxIE Bit jedoch für den Fall dass eine CAN Message erfolgreich über den Bus übertragen wurde.

Bit 12, UMask oder „Use Acceptance Mask“ ist ein Control-Bit das die Verwendung der Mask Informationen (Mask28-0, Mdir, MXtd) freischaltet oder blockiert.

Bit 13, IntPnd ist ein Flag das den Status dieses Message Objekts als „aktiver  Interrupt pending“ kennzeichnet. Ein Message Objekt bei dem das IntPnd Bit gesetzt ist hat entweder einen CAN Rahmen empfangen oder gesendet. Im „Interrupt Register“ wird parallel zum IntPnd Bit das zugeordnete Bit für dieses Message Object gesetzt.

Bit 14, MsgLst , Message Lost ist ein Error Flag das Anzeigt dass der Message Handler in diese Message Object neue Daten gespeichert hat während das „NewData“ Flag immer noch gesetzt war, was bedeutet dass die Daten in diesem Message Objekt überschrieben wurden bevor sie von der CPU gelesen werden konnten. Das MsgLst Flag zeigt diesen Fehler nur in Empfangsrichtung da beim Senden erst geprüft wird ob das letzte Message Objekt bereits gesendet wurde bevor ein Neues geschrieben wird.

Bit 15, NewData, ist ein Flag das gesetzt wird wenn neue Daten vom Message Handler (receive) bzw. von der CAN Software (transmit) in das Message Objekt geschrieben wurden.

Data Interface Register

Figure 45: Data Interface Register

Mit den Daten Interface Registern A1, A2, B1 und B2 pro Block, sind die beiden Interface Register Blöcke IF1 und IF2 komplett. Diese 4 Register speichern die maximal 8 Byte eines CAN Data Frames.

Die Aufteilung in Ax und Bx Register wird durch die Enable-Bits DataA und DataBim Command Mask Register erklärt (siehe 5.3.2). Diese Control Bits erlauben den Transfer der A-Register bzw. B-Register separat frei zu geben. Die A-Register beinhalten dabei die niedrigwertigeren 4 Byte und die B-Register die höherwertigen 4 Byte.

Basic CAN

Die Daten Interface Register fungieren als Empfangs-Puffer ( IF2 ) bzw. als Sende-Puffer ( IF1 ). Das Message RAM wird nicht verwendet deshalb findet auch keine doppelte Pufferung statt und empfangene Rahmen müssen von der CAN Applikationssoftware unmittelbar weiterverarbeitet werden.

Full CAN

Die jeweils 16 Bit breiten  Daten Interface Register dienen zur Übergabe der Daten zwischen der CPU und dem Message RAM in beiden Richtungen. Die von der CPU initierten Lese- bzw. Schreibfunktionen des Message RAM werden dabei in einem Block durchgeführt. Der Transfer erfolgt nur zwischen dem Message RAM und dem jeweils benutzten IF-Register Satz. Aus den Registern werden die Daten dann mit einem direkten Zugriff von der CPU weiterverarbeitet.

Message Objekte

Die hier beschriebene CAN Controller Implementierung benutzt im „Full CAN “ - Modus einen Message Buffer (Message RAM), der als integriertes SRAM ausgeführt ist. Dieser Speicher kann gleichzeitig bis zu 32 Message Objekte aufnehmen. Der Datenaustausch zwischen dem Message RAM und dem steuerenden Microprozessor erfolgt über die bereits beschriebenen Message Interface Register IF1und IF2.

Ein Message Object ist eine Datensstruktur, wahlweise eingerichtet für den Empfang bzw. das Senden einer CAN Message mit einer definierten CAN-ID bzw einem CAN-ID Adress-Bereich.

In einem Message Object werden alle relevanten Daten eines CAN Daten Rahmens gespeichert.

• Base ID [28..18]

• CAN Identifier Extension ID [18..0]

• DLC [3..0]

• Data Field

In Ergänzung dazu werden Flags und Control Bits abgelegt die die Verarbeitung dieses Message Objekts regeln, wie z.B.

• Maskierungs Bits für ID, Direction, Extension

• Steuerungs Bits für automatische Übertragung, Maskierungsfreigabe etc.

• Flags des jeweiligen Message Objekts

• Enable Bits für Interrupt Generierung

Eine komplette Übersicht der Datenstruktur zeigt nachfolgende Grafik.

Figure 46 : Message Object Data Structure

Für jedes der maximal 32 Message Objekte ist eine solche Datenstruktur im Speicher angelegt.

Das MsgVal Bit (Message Valid) kennzeichnet das jeweilige Message Objekt als aktiv. Nur wenn diese Bit gesetzt ist wird die Message Handler Hardware einen Übertragungsvorgang (receive oder transmit) für diese Objekt ausführen.

Das Direction Bit , Dir definiert die Übertragungsrichtung dieses Message Objekts.Ist das Bit gesetzt (1), soll das Objekt übertragen werden, ist es zurückgesetzt (0) wartet der Message Handler bis ein CAN Rahmen mit der richtigen CAN-ID, bzw. den durch die Mask Bits limitierten Akzeptanz-Kriterien, auf dem Bus gesendet wird und übernimmt die Rahmeninformation in das Message Objekt.

Ist in der Datenstruktur das Xtd Bit gesetzt so wird das Message Object als „Extended Rahmen“ referenziert. Dies gilt sowohl für zu sendende als auch für zu empfangende Nachrichten.

Wurden die Datenfelder im Message Object entweder durch den Message Handler (receive) oder durch den Microprozessor überschrieben, so wird das NewDat Bit gesetzt.

Ein weiteres generelles Flag ist das IntPend Bit das anzeigt ob dieses Message Object einen Interrupt ausgelöst hat. Nach der Übertragung oder dem Empfang eines CAN Rahmens durch dieses Message Objekt wird diese Bit gesetzt um anzuzeigen dass dieses Objekt der Aufmerksamkeit der CAN Software bedarf.

Empfängt der Message Handler einen CAN Rahmen dessen Message Objekt seit dem vorhergehenden empfangenen Rahmen nicht ausgelesen wurde, wird als Flag das MsgLst, Message Lost Bit gesetzt. Dieser Mechanismus funktioniert nur in Empfangsrichtung.

Schliesslich noch das RmtEn Bit – ein Controlbit das die automatische Übertragung eines Message Objekts aufgrund eines Remote Requests freigibt.

Diese Flags und Controlbits haben, sofern sie vom Microprozessor gelesen oder geschrieben werden können eine Entsprechung in den Message Interface Registern, die ja als einziges mögliches Interface zum Message RAM dienen.

Message Handler Register

Der im CAN Controller implementierte Message Handler Block besitzt weitere Register die vom steuernden Microprozessor direkt gelesen aber nicht geschrieben werden können. Diese Statusregister werden von der Message Handler State Machine auf den aktuellen Stand gehalten.

Die Organisation der im Message Handler implementierten Register ist, bis auf das Interrupt Identifier Register, jeweils eine Zuordnung von einem Bit pro Message Objekt. Die Register sind wie alle Anderen 16 Bit breit, sodass für die Zuordnung jeweils 2 Register benötigt werden.

Interrupt Identifier Register

Figure 47 : Interrupt Identifier Register

Im Gegensatz zu den anderen, im Message Handler implementierten Registern, enthält das Interrupt Identifier Register keine bitmässige Zuordnung zu den Message Objekten sondern einen Wert nach der folgenden Tabelle:

Wert	Status
0x0000h	Kein Interrupt anstehend
0x0001h – 0x0020h	Interrupt von Message Objekt Nummer
0x0021h – 0x7FFFh	- Nicht belegt -
0x8000h	Status Interrupt anstehend
0x0801h – 0xFFFFh	- Nicht belegt -

Table 7 : Interrupt Identifier Übersicht

Dieses Register beinhaltet immer den aktiven Interrupt mit der höchsten Priorität. Bei mehreren anstehenden Interrupts folgt die Prioritätsverteilung nachfolgender Tabelle:

Source	Interrupt Nummer	Priorität
Status Interrupt	0x8000h	höchste
Message Object 1	0x0001h	zweithöchste
Message Object 2	0x0002h	dritthöchste
----------	----------	----------
Message Object 31	0x001Fh	zweitniedrigste
Message Object 32	0x0020	niedrigste

Table 8: Interrupt Prioritäten

Der Status Interrupt wird durch das Lesen des Status Registers zurückgesetzt. Für die Message Objekt Interrupts muss das IntPend Bit (siehe 5.3.7) in jedem spezifischen Message Objekt vom Microprozessor zurückgesetzt werden. Erst wenn alle Interrupts abgearbeitet und die entsprechenden IntPend Bits zurückgesetzt sind wird das Interrupt Identifier Register den Wert 0x0000h zeigen.

Interrupt Pending Register

Figure 48: Interrupt Pending Register

Die beiden Interrupt Pending Register bilden eine gewisse Redundanz zum Interrupt Identifier Register. In diesen beiden Registern wird für einen anstehenden Interrupt jedes einzelnen Message Objekts ein dediziertes Bit gesetzt.

Die Bitzuordnung entspricht der Reihenfolge der Message Objekte, also Bit 0 entspricht dem Message Objekt 1, Bit 1 dem Message Objekt 2 usw., damit können 32 Message Objekte zugeordnet werden. Ist ein Bit im Interrupt Pending Register gesetzt so ist das Bit im Message Objekt ebenfalls gesetzt und das Message Objekt wartet auf die Aktualisierung durch den Microprozessor bzw. die CAN Software.

Message Valid Register

Figure 49: Message Valid Register

Die Zuordnung der beiden Message Valid Register ist identisch zum Interrupt Pending Register, dementsprechend ist das niedrigwertigste Bit das MsgVal Bit des Message Objekt 1, etc.

Die Message Valid Bits kennzeichnen die einzelnen Message Objekte als aktiv oder passiv. Passive Message Objekte werden vom Message Handler nicht bearbeitet, stehen aber weiterhin im Message RAM. Wird das MsgVal Bit über das Arbitration 2 Register (siehe 5.3.6) gesetzt ist das Message Objekt wieder aktiviert und wird vom Message Handler bearbeitet (gesendet bzw. empfangen) vorausgesetzt die Akzeptanz Bedingungen sind hinreichend erfüllt.

Transmission Request Register

Figure 50: Transmission Request Register

Ein weiteres Paar von Registern ermöglicht den direkten Zugriff auf alle TxRqst Bits.

Auch bei diesen Registern ist die Zuordnung gleich „niedrigstwertiges Bit“ entspricht niedrigster Message Objekt Nummer.

Die Transmit Request Bits können entweder vom Microprozessor über das TxRqst Bit im Message Control Register gesetzt werden falls das entsprechende Message Objekt komplett für die Übertragung in das Message Objekt eingetragen wurde oder aber auch durch den Message Handler falls ein Remote Rahmen mit der passenden CAN-ID empfangen wurde und das RmtEn Bit innerhalb diese Message Objekts gesetzt ist.

New Data Register

Figure 51: New Data Register

Das letzte Registerpaar mit einer bitweisen Zuordnung pro Message Objekt sind die New Data Register. Sie spiegeln wie die vorher behandelten Register die Gesamtheit aller NewDatFlags innerhalb der 32 Message Objekte wieder. Auch die Zuordnung entspricht der gewohnten Weise.

Wir erinnern uns, die NewDat Flags in den einzelnen Message Objekten werden gesetzt wenn über die Message Interface Register bzw. durch den Message Handler die Datenfelder in den entsprechenden Message Objekten geändert wurden.

Vorteile der Message Handler Register

Die Message Handler Register vereinfachen im Full CAN Modus die Komplexität der CAN Software durch direkten Zugriff auf alle Statusflags der einzelnen Message Objekte, zum einen durch Vermeidung des komplexen Zugriffs über die Message Interface Register, zum anderen durch direkten Zugriff auf alle Flags eines Typs. Damit ist programtechnisch das Abprüfen von anstehenden Aktionen sehr simpel und es wird sehr wenig Rechenleistung benötigt.

Im Basic CAN Modus trifft dieser Vorteil natürlich nicht zu da jeweils nur ein Message Objekt innerhalb der Message Interface Register gespeichert werden kann und es praktisch nur eine Interrupt- Quelle pro Registersatz gibt.

Die Message Handler Hardware

Die ein- und ausgehenden Messages auf dem CAN Bus werden von einer eigenen Hardware im CAN Controller überwacht und verarbeitet. Dazu wurde eine Ablaufsteuerung (State-Machine) implementiert die folgende Aufgaben wahrnimmt:

• Datentransfer zwischen Message Interface Registern und Message RAM (schreiben eines Message Objekts von der CPU)

• Datentransfer zwischen Message RAM und Message Interface Registern (lesen eines Message Objekts von der CPU)

• Datentransfer zwischen dem Schiebregister und dem Message RAM (empfang eines CAN Rahmens)

• Datentransfer zwischen dem Message RAM und dem Schiebergister (senden eines CAN Rahmens)

• Datentransfer zwischen Schieberegister und Akzeptanz-Filter (Transfer der empfangenen CAN Rahmen zum Filter)

• Vergleich der Message Objekte mit empfangenen Rahmen (Filterung der empfangenen CAN Rahmen zur Vorselektion)

• Verarbeitung von Transmit Requests (Senden bereitstehender Message Objekte mit automatischen Neuversenden bei Bus-Arbitrations-Verlust)

• Interrupt Aufbereitung und Handling

Daten Transfer zur CPU

Die Datentransfers zwischen der CPU und einzelnen Message Objekten im Message RAM werden von der CPU initiert. Alle Transfers werden über die Message Interface Registersätze abgewickelt, ein direkter Zugriff auf das Message RAM ist zu keinem Zeitpunkt möglich.

Da der uneingeschränkte Zugriff auf das Message RAM von der Message Handler Hardware zur Message Filterung usw. gewährleistet sein muss, ist diese Hardware auch für die Transfers der Daten zwischen den Message Interface Registern und den einzelnen Message Objekten im Message RAM zuständig.

Ein Transfer (sowohl schreiben wie lesen) wird durch das Schreiben der Message Nummer MsgN[x] in das Command Request Register (siehe 5.3.1) ausgelöst. Die Richtung des Transfers ergibt sich aus dem Wr/RdBit im Command Mask Register (siehe 5.3.2 ).

Ein Datentransfer von / zu einem Message Objekt erfolgt immer für das gesamte Message Objekt falls der Zugriff über die Access Enable Bits: Mask, Ctrl, Arbbzw. die Data Transfer Enable Bits DataA und DataB nicht eingeschränkt wird.

Daten Transfer Schieberegister

Die Message Handler State-Machine kontrolliert auch die Datentransfers zwischen den Recieve- und Transmit-Schieberegistern. Jedes Message Objekt mit gesetztem MsgVal Bit wird vom Message Handler bearbeitet. Das Dir Bit (Direction Bit) gibt dabei die Übertragungsrichtung vor und das Xtd Bit (Extended Bit) entscheidet über die Verwendung eines 11 Bit bzw. eines 29 Bit Identifiers für den Übertragungsrahmen.

Receive

Jeder eingehende Datenrahmen wird vom Message Handler zur Überprüfung der Akzeptanz-Kriterien gelesen und bei einer Übereinstimmung der Kriterien in das entsprechende Message Objekt übernommen. Gleichzeitig werden die entsprechenden Flags gesetzt um eine Weiterverarbeitung zu ermöglichen (z.B. NewDat, IntPend etc.) und der Interrupt Identifier wird auf den aktuellen Stand gebracht falls das Message Objekt mit dem empfangenen Rahmen eine höhere Priorität besitzt.

Transmit

Message Objekte die mit dem TxRqst Flag als übertragungsbereit gekennzeichnet sind werden vom Message Handler entsprechend ihrer Priorität bei nächster Gelegenheit gesendet. Der Ablauf der Bus Arbitration und ein daraus resultierender eventueller Abbruch der Übertragung, sowie die automatische Neuübertragung nach einem Abbruch werden ebenfalls von der Hardware durchgeführt.

Funktion im Basic CAN Modus

Die eben beschriebene Funktionalität bezieht sich weitgehend auf den Full CAN Modus. Im Basic CANMode wird vom Message Handler keine Filterfunktion und keine Vorselektion durchgeführt. Jeder ankommende Rahmen wird eingelesen und in den Message Interface Register Satz IF2 eingetragen.

Receive

Filterfunktion und Verarbeitung müssen von einem CAN Software Stack durchgeführt werden. Die Information von CAN Rahmen mit nicht übereinstimmenden CAN-IDs wird nach der Prüfung verworfen. Diese Methode erlaubt die Implementierung von sehr komplexen Filterstrukturen erfordert aber andererseits wesentlich mehr Rechenleistung vom Microprozessor.

Im Basic CAN Modus werden neben den Daten Rahmen auch Remote Rahmen per Software ausgewertet um gegebenenfalls einen Request durch das Senden eines Datenrahmens zu beantworten. Eine automatische Übertragung wie im Full CAN Mode ist hier nicht möglich da ja die Message Objekte nicht zur Verfügung stehen sondern die entsprechende Message vom Microprozessor erst in den Message Interface Register Satz IF1 eingetragen werden muss.

Transmit

Das Beschreiben des Message Interface Register Satzes IF1 und das Setzen des TxRqst Bits aktivieren die Übertragung der im Register Satz gespeicherten Informationen über den CAN Bus.

Bus Arbitrierung und Abbruch der Übertragung bei Verlust der Arbitrierung werden weiterhin vom Message Handler ausgeführt.

Copyright

Copyright 2017 by Dipl.Ing.(FH) Franz Henkel

Dieses Dokument sowie dessen Inhalt, insbesondere Texte, Fotografien und Grafiken, unterliegt dem Copyright (© 2017) und sind nur mit einer schriftlicher Zustimmung des Autors, Dipl.Ing.(FH) Franz Henkel zur vollständigen oder auszugsweisen Weiterverwendung in Form einer gedruckten oder elektronischen Kopie oder Replikation bzw. einer vollständigen oder auszugsweisen Bereitstellung des Inhalts in schriftlicher, gedruckter oder elektronischer Form, zu verwenden.

 

Zum Teil 1 der CAN-Bus Einführung