-
Die Erfindung betrifft einen Basic-CAN-Controller für Anwendungen im Kraftfahrzeug .
-
Die Integration des CAN in Linux oder andere moderne, insbesondere eingebettete Betriebssysteme stellt dabei aufgrund des Treibermodells andere Anforderungen an die Benutzung und die interne Struktur des CAN-Controllers als zu Beginn der CAN-Controller Entwicklung 1987.
-
Durch die aktuellen Erweiterung des CAN-Standards mit einer Vergrößerung der Payload von 8 auf 64 Byte bei CAN FD wird zusätzlicher, in der Regel teurer Speicherplatz auf dem CAN-Controller benötigt.
-
Grundsätzlich können zwei CAN-Controller-Architekturen unterschieden werden:
- Basic-CAN:
- Der Basic-CAN-Controller weist eine einfache Filterung mit typischerweise einem Filter für den Empfang von CAN-Nachrichten, sog. CAN-Frames, sowie wenig Speicherplatz für CAN-Nachrichten auf. Dies resultiert in einer hohen CPU-Belastung, da die Filterung primär durch Software erfolgt. Ferner ist die Hardware-Komplexität relativ zu den Kosten gering.
- Full-CAN:
- Der Full-CAN-Controller umfasst mehrere Nachrichtenfilter mit zugehörigem Speicherplatz für CAN Nachrichten, was zu einer geringeren CPU-Belastung führt, da die Filterung primär durch die Hardware erfolgt. Ferner ist das Verhältnis Hardware-Komplexität zu Kosten größer.
-
Beispiele für entsprechende CAN-Controller sind der NXP SJA1000 als ein Beispiel für einen Basic-CAN-Controller, der Infineon 82C900 als ein Beispiel eines Full-CAN-Controllers und der Bosch M_CAN als ein Beispiel eines weiteren Full-CAN-Controllers mit CAN FD, wobei der Zusatz FD für flexible Datenrate nach ISO 11898-2:2015 steht.
-
Die Architekturkonzepte der Basic-CAN-Controller und Full-CAN-Controller sind geprägt von Anwendungsentwicklungen für CAN-Steuergeräte von vor 20 Jahren. Die Nachrichtenfilter mit zugehörigem Speicherplatz sind insbesondere für verschiedene Tasks auf einem Steuergerät interessant, welchem exklusive Sende- und Empfangs-CAN-Identifier zugewiesen wurden.
-
In aktuellen Steuergeräten sorgt eine zentrale Software für die Verteilung des CAN-Datenstroms in einem Single-Input-Stream. Insbesondere wenn mehrere Steuergerätefunktionen in ein zentrales Steuergerät integriert werden, wie dies beispielsweise bei einem Body-Controller BCM, einem zentralen FAS-Steuergerät zFAS, etc. der Fall ist, sind die bisherigen Strukturen der Full-CAN-Controller ungeeignet: Die Anzahl der Nachrichtenfilter mit zugehörigem Speicherplatz ist aus Kostengründen stark limitiert und eine Verwendung von „offenen“ Nachrichtenfiltern erhöht die CPU-Last, wie es vom kostengünstigeren Basic-CAN-Controller bekannt ist.
-
Es wurden verschiedene Konfigurationsmöglichkeiten für den Full-CAN-Controller implementiert, mit denen die Nachrichtenfilter mit zugehörigem Speicherplatz zusammengeschaltet werden können. Dadurch kann bei der Reduzierung der Filter-Anzahl der zur Verfügung stehende Speicherplatz als Empfangspuffer, üblicherweise bezeichnet als RX FIFO, genutzt werden. Aufgrund der reduzierten Filtermöglichkeiten ist dieses Konzept für aktuelle CAN-Anwendungssoftware aber weiterhin unzureichend und es müsste zur Reduzierung der CPU-Last für jeden Anwendungsfall eine optimale Ausnutzung der zur Verfügung stehenden Controller-Eigenschaften erarbeitet werden, was in der Realität aber entfällt. Im Fall von CAN FD müssen die Empfangspuffer bis zu 64 Byte Payload, d.h. Nutzdaten, aufnehmen, wodurch eine effiziente Konfiguration und Nutzung des Controller-Speichers nochmals deutlich erschwert wird.
-
Die Druckschrift
DE 10 2005 012 374 B4 betrifft eine Vorrichtung zum Identifizieren von für einen Busteilnehmer relevanten Nachrichten in einem Datenbussystem mit einer Mehrzahl an Busteilnehmern, wobei die für einen Busteilnehmer relevanten Nachrichten anhand eines Identifikationsdatums identifiziert werden, mit
- - zumindest einer Speichereinrichtung mit Speicherzellen,
- - einer Nachrichtenermittlungseinrichtung, die dazu ausgebildet ist, aus einer ihr zugeführten Nachricht ein Identifikationsdatum zu ermitteln und der zumindest einen Speichereinrichtung zumindest teilweise als Adresssignal zuzuführen, und
- - einer Leseeinrichtung zum Auslesen von Daten aus der zumindest einen Speichereinrichtung, die gemäß dem Adresssignal die dem Adresssignal zugeordnete Speicherzelle ausliest, und
- - einer Einrichtung zum Bearbeiten des Identifikationsdatums, die das Identifikationsdatum in einen ersten und einen zweiten Teil aufteilt, wobei die Einrichtung zum Bearbeiten des Identifikationsdatums
- - den ersten Teil des Identifikationsdatums der zumindest einen Speichereinrichtung als Adresssignal zuführt,
- - den zweiten Teil des Identifikationsdatums zumindest einer Dekodiereinrichtung zuführt, wobei die Dekodiereinrichtung anhand des zweiten Teils des Identifikationsdatums den Inhalt der dem Adresssignal zugeordneten Speicherzelle auswertet, um anhand des ausgelesenen logischen Zustands die Relevanz der Nachricht für den Busteilnehmer zu bestimmen.
-
Die Druckschrift
DE 10 2005 033 700 B4 beschreibt ein CAN-System mit mehreren CAN-Modulen sowie einem die CAN-Module verbindenden CAN-Bus, bei dem zwischen wenigstens einem CAN-Modul und dem CAN-Bus eine Filtereinrichtung geschaltet ist, mit der über den CAN-Bus transportierte, an das wenigstens eine CAN-Modul gerichtete CAN-Nachrichten gefiltert werden, wobei die Filtereinrichtung die Filterung in Abhängigkeit wenigstens einer frei parametrisierbaren Filterbedingung durchführt.
-
Die Druckschrift
US 7,975,120 B2 betrifft ein Verfahren zur Zuweisung eines Speichers, der mit einem CAN Controller verbunden ist, mit den Schritten
- - Empfangen eines Datenpakets enthaltend einen Identifier und Daten,
- - dynamisches Zuweisen eines Message-Puffers innerhalb des Speichers zum Einreihen des Datenpakets in eine Warteschlange, und
- - Erzeugen eines Zeigers, der auf den Message-Puffer zeigt, wobei auf den Zeiger über eine statische Lokalisierung in dem Speicher zugegriffen wird.
-
Die Firmenschrift „STMicroelectronics: RM0090 Reference Manual. 2013 (Doc ID 018909 Rev 4). Titelseite, S. 664 - 707“ beschreibt einen Basic CAN-Controller mit einer zwischen einer CAN-Protocol-Engine und einem RX-FIFO angeordneten Filterbank bestehend aus hintereinander seriell angeordneten Filterelemente, wobei eine einkommende Nachricht nacheinander die Filterelemente durchläuft und abgespeichert wird, wenn eine Übereinstimmung des Identifiers der CAN-Nachricht mit der entsprechenden ID des Filters vorliegt. Ergibt sich keine Übereinstimmung des Identifiers der Nachricht mit einer der Identifier der Filterelemente, so wird die Nachricht nach dem kompletten Durchlauf der Filterbank entsorgt.
-
Der Erfindung liegt die Aufgabe zugrunde, einen Basic-CAN-Controller mit einer verbesserten Handhabung des empfangenen CAN-Datenstroms zu schaffen.
-
Diese Aufgabe wird gelöst durch einen Basic-CAN-Controller mit den Merkmalen des Anspruchs 1. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
-
Der erfindungsgemäße Basic-CAN-Controller umfasst
- - einen CAN-Transceiver zum Verbinden des Basic-CAN-Controllers mit einem CAN-Bus,
- - eine CAN-Protocol-Engine zum Kodieren eines CAN-Frames in einen Bitstrom zur Übertragung auf dem CAN-Bus und zum Dekodieren eines vom CAN-Bus empfangenen Bitstroms in ein CAN-Frame,
- - einen TX-FIFO zum Speichern von zu übertragenden CAN-Frames,
- - ein Host-Control-Interface zur Kommunikation von Steuerinformationen zwischen CAN-Protocol-Engine und einem Hostrechner,
- - einen RX-FIFO zum temporären Speichern der empfangenen CAN-Frames vor der Übertragung an den Hostrechner,
- - eine Filterbank, die zwischen der CAN-Protocol-Engine und dem RX-FIFO angeordnet ist, wobei
- - die Filterbank zwei oder mehr Filterelemente aufweist, die Filterelemente parallel zueinander in der Filterbank angeordnet sind,
- - jedes Filterelement der Filterbank einen Bereich für eine ID-Maske und einen Bereich für einen CAN-Identifier zur Filterung von CAN-Frames umfasst,
- - jedem Filterelement eine ID-Maske zugewiesen ist,
- - im Filterelement eine Verknüpfung des CAN-Identifiers eines empfangenen CAN-Frames mit der ID-Maske des jeweiligen Filterelements erfolgt, und
- - ein Weiterleiten des empfangenen CAN-Frames an das RX-FIFO nur dann erfolgt, wenn der CAN-Identifier des CAN-Frames mit der ID-Maske von mindestens einem der Filterelemente der Filterbank kompatibel ist.
-
Der erfindungsgemäße erweiterte Basic-CAN-Controller ist eine Erweiterung des kostengünstigen Basic-CAN-Controllers um eine vergleichsweise große Menge von einfachen Nachrichtenfiltern unter Beibehaltung des bisherigen gemeinsamen Nachrichtenspeichers für Empfangsnachrichten, dem RX-FIFO. Die Hardware des erweiterten Basic-CAN-Controllers unterstützt eine große Anzahl von einfachen Filtern, die es ermöglichen die vom Steuergerät benötigten CAN-Identifier dediziert zu filtern und dabei die CPU-Belastung für die Verwendung in aktuellen CAN-Anwendungsfällen zu minimieren.
-
Vorzugsweise erfolgt in jedem Filterelement eine logische UND-Verknüpfung zwischen dem ID-Value des CAN-Identifiers des empfangenen CAN-Frames und der ID-Maske des jeweiligen Filterelements.
-
Ein Filterelement mit ID-Value und ID-Maske gibt beispielsweise ein empfangenes CAN-Frame mit einem RX-ID-Value an den RX-FIFO weiter, wenn gilt:
- (ID-Value UND ID-Maske) ist gleich (RX-ID-Value UND ID-Maske).
-
Weiter bevorzugt ist die ID-Maske jedes Filterelements der Filterbank im ID-Maskenbereich fest vorgegeben. Wenn bekannt ist, dass ein bestimmter CAN-Controller nur für eine vorgegebene Aufgabe eingesetzt wird, so vermindert einerseits eine fest einprogrammierte ID-Maske zwar die Flexibilität des CAN-Controllers und erhöht andererseits die Betriebssicherheit, da ein fehlerhafter Veränderung der ID-Maske ausgeschlossen werden kann.
-
Vorzugsweise ist die ID-Maske jedes Filterelements der Filterbank im ID-Maskenbereich veränderbar und wird im ID-Maskenbereich gespeichert. Mit anderen Worten, die ID-Maske eines Filterelements kann per Programmierung geändert werden, so dass der CAN-Controller flexibel einsetzbar ist.
-
Weiter bevorzugt weist das RX-FIFO eine Mehrzahl bzw. Vielzahl von Speicherbereichen fester Größe zur temporären Speicherung der von den Filterelementen der Filterbank gefilterten CAN-Frames auf. Dies entspricht einem RX-FIFO mit üblicher Speicherverwaltung, so dass dies eine kostengünstige Lösung darstellt.
-
Vorzugsweise weist das RX-FIFO eine Mehrzahl von Speicherbereichen variabler Größe zur temporären Speicherung der von den Filterelementen der Filterbank gefilterten CAN-Frames auf, wobei jeder Speicherbereich einen festen Bereich zum Speichern eines Headers des CAN-Frames und einen Datenbereich variabler Größe zum Speichern der Nutzdaten des CAN-Frames aufweist, und wobei die Größe des Datenbereichs des jeweiligen Speicherbereichs des RX-FIFOS an die Nutzdaten des gefilterten CAN-Frames angepasst wird.
-
Auf diese Weise wird der Speicherbereich des RX-FIFOs für Empfangsnachrichten speicherplatzökonomisch ausgestaltet, indem die CAN-Nachrichten aufeinanderfolgend abgelegt werden können. Das ist insbesondere bei einem zu erwartenden Mix-Betrieb von Standard-CAN mit maximal 8 Byte Nutzdaten (Payload) und CAN-FD mit maximal 64 Byte Nutzdaten vorteilhaft.
-
Der Header des CAN-Frames kann neben den üblichen Meta-Daten von CAN-Frames wie dem CAN-Identifier, der Botschaftslänge oder CAN-spezifischen Bitwerten vorzugsweise einen Zeitstempel-Wert enthalten, der zum Empfangszeitpunkt vom CAN-Controller erfasst und gespeichert wird.
-
Die Vorteile des Konzepts des erweiterten Basic-CAN-Controller sind:
- - Geringe Komplexität des Filter Konzepts, woraus sich eine geringe Chipfläche mit geringen Kosten der CAN-Controller-Hardware ergibt,
- - geringe Interrupt-Last für die Host-CPU zur Laufzeit, da nur genau die benötigten CAN-Identifier gefiltert werden,
- - Anpassung der Anforderungen in der Controller Architektur an aktuelle Software-Entwicklungen auf eingebetteten Systemen, wie beispielsweise Single Input Stream, zentrale CAN-Nachrichtenverarbeitung und zentrale CAN-Nachrichtenverteilung,
- - effiziente Nutzung des internen Speichers für empfangene Nachrichten unterschiedlicher Länge, und
- - einfache Programmierung, da es um das bekannte Basic-CAN-Konzept handelt und die zusätzliche Konfiguration der vielen Filter auf einfache Weise erfolgt.
-
Eine bevorzugte Ausgestaltung der Erfindung wird nachfolgend anhand der Zeichnungen erläutert. Dabei zeigt
- 1 einen Basic-CAN Controller nach dem Stand der Technik,
- 2 einen Full-CAN Controller nach dem Stand der Technik,
- 3 einen erweiterten Basic-CAN Controller, und
- 4 eine Variante des erweiterten Basic-CAN Controllers der 3.
-
In 1 ist in schematischer Darstellung ein Basic-CAN-Controller mit seinen wesentlichen Elementen dargestellt, wie er beispielsweise in dem oben genannten Basic-CAN-Controller SJA1000 von NXP realisiert ist. Da sich im Bereich der CAN-Busse die englische Bezeichnung der einzelnen Elemente durchgesetzt hat, wird diese in der folgenden Beschreibung beibehalten. Die Verbindung zum zweidrahtigen CAN-Bus (nicht dargestellt) erfolgt über einen CAN-Transceiver 1, der vom Bus die codierten Signale abgreift bzw. diese auf den Bus legt. Der CAN-Transceiver 1 wiederum ist mit einer CAN-Protocol-Engine 2 verbunden, die den empfangenen Bitstrom dekodiert bzw. den zu sendenden Bitstrom entsprechend dem CAN-Protokoll kodiert. Zu diesem Zweck umfasst die CAN-Protocol-Engine 2 einen Bitstrom-Encoder 4 und einen Bitstrom-Decoder 5, wobei eine Steuerlogik 3 den Betrieb überwacht und steuert.
-
Eine CAN-Nachricht, welche hier durchgehend als CAN-Frame bezeichnet wird, umfasst einen vorausgestellten CAN-Identifier, der im Standard-Frame-Format 11 Bit und im Extended-Frame-Format 28 Bit aufweist, dem außer bei einem RTR-Frame (Remote Transmission Request) Nutzdaten nachfolgen, beispielsweise 8 Byte. Dabei kennzeichnet CAN-Identifier, der auch als Objekt-Identifier bezeichnet wird, üblicherweise den Inhalt des CAN-Frames. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung und Druck jeweils ein eigener CAN-Identifier zugewiesen sein. Es können mehrere Parameter unter einem CAN-Identifier vereint sein, solange die Summe der Daten die maximal mögliche Länge des Datenfeldes, also 8 Byte bei CAN oder 64 Byte bei CAN FD, nicht überschreitet. Die Empfänger entscheiden anhand des CAN-Identifiers, ob die Nachricht für sie relevant ist oder nicht. Zudem dient der CAN-Identifier auch der Priorisierung der CAN-Nachrichten bzw. CAN-Frames. Als ID-Value wird der „Wert“ des CAN-Identifiers bezeichnet
-
Der in 1 dargestellte Basic-CAN-Controller umfasst einen Filter 10, wodurch die Möglichkeit besteht empfangene CAN-Frames zu filtern, d.h. zu akzeptieren oder auszusortieren. Um eine Filterung durchführen zu können, weist der Filter 10 eine ID-Maske 11 auf, die mit den CAN-Identifier 12 über beispielsweise eine UND-Funktion logisch verknüpft wird. Hat der Filter 10 einen CAN-Frame akzeptiert, so wird dieser in einen Empfangs-Speicherbereich verschoben, welches RX-FIFO 18 bezeichnet wird. Das RX-FIFO 18 im Beispiel der 1 umfasst vier Speicherbereiche 13, 14, 15 und 16, in denen jeweils ein CAN-Frame abgespeichert werden kann, welches den jeweiligen CAN-Identifier, Flags und Daten umfasst. Ferner ist das abgespeicherte CAN-Frame gegebenenfalls mit einem Datum, also einem Timestamp, versehen. In der einfachsten Ausbaustufe besteht das RX-FIFO 18 aus nur einem Speicherbereich 13, was zwangsläufig dazu führt, dass mit dem Erhalt und Abspeichern eines gefilterten und damit zulässigen CAN-Frames über das Host-Control-Interface 6 ein Interrupt an den Host-Rechner (nicht dargestellt) gesendet werden muss, damit das im Speicherbereich 13 gespeicherte CAN-Frame vor dem Eintreffen eines nächsten zulässigen CAN-Frames vom Host-Rechner übernommen wird. Ist daher der Host-Rechner überlastet und kann trotz Erhalt eines Interrupts vom Host-Control-Interface 6 die aktuelle CAN-Nachricht aus dem Speicherbereich 13 nicht abholen, so wird gegebenenfalls die aktuelle gespeicherte CAN-Nachricht durch die nächste zulässige CAN-Nachricht überschrieben. Durch die Verwendung eines entsprechend großen RX-FIFOs 18 mit mehreren Speicherbereichen 13, 14, 15, 16 kann diese Möglichkeit herabgesetzt werden.
-
Au der linken Seite der 1 ist der Sende-Speicherbereich dargestellt, der als das TX-FIFO 9 bezeichnet wird, welches den FIFO-Speicher für die auszugebenden CAN-Frames zeigt. Dabei umfasst das TX-FIFO, wobei TX für „Transmit“ steht, zwei Speicherbereiche 7, 8 zur vorübergehenden Speicherung der zu übertragenden CAN-Frames mit CAN-Identifier, Flags und Daten.
-
Die 2 zeigt einen Full-CAN Controller, wie er beispielsweise im oben genannten Full-CAN-Controller 82C900 von Infineon realisiert ist, wobei gleiche Bezugszeichen in üblicher Weise identische Komponenten bezeichnen.
-
Die Verbindung zum zweidrahtigen CAN-Bus (nicht dargestellt) erfolgt wie beim Basic-CAN-Controller über den CAN-Transceiver 1, der vom Bus die codierten Signale abgreift bzw. die codierten Signale auf den Bus legt. Der CAN-Transceiver 1 erhält den Bitstrom bzw. schickt den empfangenen Bitstrom in die CAN-Protocol-Engine 2, die den empfangenen Bitstrom dekodiert bzw. den zu sendenden Bitstrom entsprechend dem CAN-Protokoll kodiert. Zu diesem Zweck weist die CAN-Protocol-Engine 2 einen Bitstrom-Encoder 4 und einen Bitstrom-Decoder 5 auf, wobei eine Steuerlogik 3 den Betrieb der CAN-Protocol-Engine 2 überwacht und steuert. Ferner ist die CAN-Protocol-Engine 2 mit einem Host-Control-Interface 6 verbunden, welches die Verbindung zu einem Host-Rechner (nicht dargestellt) herstellt, um beispielsweise mittels einer Interrupt-Generierung dem Host-Rechner den Erhalt eines CAN-Frames anzuzeigen.
-
Ein empfangenes CAN-Frame wird in dem Full-CAN-Controller einem RX-Nachrichtenpuffer 26 zugeführt, der eine vorgegebene Anzahl von Filter-Speicherelementen 27, 28, 29 und 30 aufweist. In der 2 sind vier Filter-Speicherelemente 27, 28, 29, 30 angegeben, jedoch ist die Anzahl der Filter-Speicherelemente 27, 28, 29, 30 nur beispielhaft zu verstehen und an die an den CAN-Controller gestellten Anforderungen anpassbar.
-
Jedes Filter-Speicherelement 27, 28, 29, 30 des RX-Nachrichtenpuffers 26 umfasst einen Filter 10, bestehend aus der Verknüpfung zwischen dem ID-Value 11 des CAN-Identifiers und der ID-Maske 12, sowie einen nachfolgenden Speicherbereich 13, 14, 15, 16, in welchem der gefilterte CAN-Frame mit ID-Value, Flags, Daten und (optional) Zeitstempel abgespeichert wird und zur Abholung durch den Host-Rechner (nicht dargestellt) bereitgestellt wird. Zwar wird durch die Verwendung mehrerer Filter 10 im jeweiligen Filter-Speicherelement 27, 28, 29, 30 die Verwendung mehrerer, voneinander unabhängiger ID-Masken möglich, jedoch ist die Bereitstellung der empfangenen CAN-Frames an den Host-Rechner zeitkritisch und ein Interrupt muss innerhalb der Zeit abgearbeitet werden, innerhalb derer ein Filter-Speicherelement 27, 28, 29, 30 mit einem nächsten zulässigen CAN-Frame überschrieben werden könnte. Ist beispielsweise das erste Filter-Speicherelement 27 mit einem zulässigen CAN-Frame belegt, was bedeutet, dass ein ankommendes CAN-Frame einen zur ID-Maske 11 passenden ID-Value aufweist, so wird dem Host-Rechner per Interrrupt mitgeteilt, dass ein CAN-Frame zur Abholung ansteht. Wird nun der Interrupt innerhalb eines vorgegebenen Zeitraums, der beispielsweise vom einem Messzyklus vorgegeben ist, nicht schnell genug abgearbeitet, so kann innerhalb des vorgegebenen Zeitraums ein nächstes CAN-Frame mit einem zur ID-Maske 11 passenden ID-Value 12 zur Speicherung an dem speziellen Filter-Speicherelement 27 anstehen, wodurch das abgespeicherte vorherige CAN-Frame überschrieben wird und somit verloren geht. Bei volatilen Daten mit hoher Wiederholrate, wie beispielsweise einer Motordrehzahl, kann das Risiko von überschriebenen und damit veralteten Inhalten in einem Filterelement bewusst als Kommunikationsparadigma eingesetzt werden.
-
Die Sendeseite des Full-CAN-Controllers der 2 umfasst eine TX-Sendepuffer 20, der mehrere CAN-Frame-Speicherbereiche 21, 22, 23 und 24 aufweist, in welche vom Hostrechner CAN-Frames zur Versendung abgelegt werden können. Nachfolgend dem TX-Sendepuffer 20 ist ein Prioritätsselektor 25 angeordnet, der CAN-Frames mit höherer Priorität bevorzugt sendet. Dabei wird die Priorität über den ID-Value festgelegt. Das vom Prioritätsselektor 25 zur Sendung bestimmte CAN-Frame wird dann von der CAN-Protocol-Engine 2 über den CAN-Transceiver 1 auf den CAN-Bus (nicht dargestellt) gelegt.
-
3 zeigt eine erste Ausführungsform eines erweiterten Basic-CAN-Controllers in schematischer Darstellung. Ein CAN-Transceiver 1 ist mit einem nicht dargestellten CAN-Bus verbunden und greift Signale vom CAN-Bus ab bzw. legt entsprechende Signale auf den CAN-Bus. Im Fall empfangener Signale werden diese in der CAN-Protocol-Engine 2, umfassend eine Steuerlogik 3, einen Bitstream-Encoder 4 und einen Bitstream-Decoder 5, vom Bitstream-Decoder 5 dekodiert und in einen CAN-Frame umgewandelt.
-
Der ID-Value eines empfangenen CAN-Frames wird einer RX-Filterbank 31 zugeführt, die aus mehreren parallel angeordneten einzelnen Filterelementen 32, 33, 34, 35 besteht, wobei die Anzahl der parallel angeordneten Filterelementen 32, 33, 34, 35 von der Anwendung des erweiterten CAN-Controllers abhängt und mindestens zwei beträgt, d.h. die Anzahl der Filterelemente ist gleich oder größer zwei. Ein Filterelement 32, 33, 34, 35 der RX-Filterbank besteht aus einem ID-Value-Bereich 12 und einem ID-Masken-Bereich 11, so dass als Funktion der ID-Maske des ID-Masken-Bereichs 11 entschieden wird, ob der ID-Value des empfangenen CAN-Frame für den speziellen CAN-Controller zulässig ist oder nicht. Durch die parallele Anordnung mehrerer Filterelemente 32, 33, 34, 35 ist der CAN-Controller deutlich flexibler und selektiver. Mit anderen Worten, der CAN-Controller ist hinsichtlich der Definition des Spektrums der CAN-Frames flexibler und spezifischer.
-
Wird ein CAN-Frame von der RX-Filterbank 31 durchgelassen, d.h. der CAN-Frame ist für diesen CAN-Controller und damit den Host-Rechner zulässig, so wird der CAN-Frame mit den Attributen ID-Value, Flags, Daten und Zeitstempel einem RX-FIFO 18 bestehend aus den Speicherbereichen 13, 14, 15, 16 zugeführt, wobei die Anzahl der Speicherbereiche 13, 14, 15, 16 eine Funktion der Anwendung und der zeitlichen Rahmenbedingungen ist und größer oder gleich zwei ist. Dabei hat jeder Speicherbereich eine vorgegebene konstante Länge zur Aufnahme des CAN-Frames.
-
Dem Host-Rechner wird per Interrupt der Eingang neuer CAN-Frames mitgeteilt. Der RX-FIFO 18 dient als Puffer und neu eingehende CAN-Nachrichten werden in einem freien Speicherbereich unterhalb eines belegten Speicherbereichs abgelegt. Sind beispielsweise die Speicherbereiche 15 und 16 des RX-FIFOs 18 belegt, so wird der nächste zulässige CAN-Frame in den Speicherbereich 14 abgelegt. Der Host-Rechner liest CAN-Frames aus dem RX-FIFO 18 von oben herab aus, d.h. beginnend aus dem Speicherbereich 16 des RX-FIFOs 18, falls dieser den obersten Speicherbereich des RX-FIFOs 18 darstellt,
Sendeseitig ist der CAN-Controller der 3 identisch zu dem Basic-CAN-Controller der 1, so dass zur Erläuterung des Sende-Speicherbereichs TX-FIFO 9 mit den Speicherbereichen 7, 8 auf die obige Beschreibung verwiesen wird. Ferner entspricht das Host-Control-Interface 6 demjenigen der 1.
-
4 zeigt eine zweite Ausführungsform des erweiterten Basic-CAN-Controller der 3, wobei die Funktionalitäten der gemeinsamen Komponenten CAN-Transceiver 1, der die Verbindung zu dem nicht dargestellten CAN-Bus herstellt, CAN-Protocol-Engine 2, TX-FIFO 9 und Host-Control-Interface 6 nicht erneut behandelt werden, sondern auf die vorherigen Erläuterungen verwiesen werden.
-
In gleicher Weise wie der Basic-CAN-Controller der 3 ist auch in dieser Ausführungsform eine Filterbank 31 vorgesehen, die eine Vielzahl von parallel angeordneten Filterelementen 32, 33, 34 und 35 aufweist, wobei die Anzahl der Filterelemente 32, 33, 34, 35 größer oder gleich zwei ist. Die Filterelemente 32, 33, 34, 35 umfassen eine ID-Maskenbereich 11 und einen ID-Value-Bereich 12, so dass beispielsweise mit einer UND-Verknüpfung des Werts des aktuellen CAN-Frames mit der vorgegebenen ID-Maske erfolgt, so dass nur CAN-Frames mit einem zulässigen ID-Value das entsprechende Filterelement 32, 33, 34, 35 passieren können und die gefilterten CAN-Frames nachfolgend in den Speicherbereichen 13, 14, 15, 16 des RX-FIFOs 18 abgelegt werden. Dabei ist das RX-FIFO 18 in der üblichen Weise organisiert, d.h. wenn ein neues CAN-Frame in das RX-FIFO 18 abgelegt wird, so wird dies direkt unterhalb des zuletzt gespeicherten CAN-Frames abgelegt. Mit anderen Worten, die CAN-Frames im RX-FIFO 18 müssen rechtzeitig vom Host-Rechner abgerufen werden, damit kein Überschreiben des untersten Speicherbereichs 13 auftritt und somit ein CAN-Frame verloren geht.
-
Der Unterschied zu dem erweiterten Basic-CAN-Controller der 3 liegt in der Organisation des RX-FIFOs 18. Während in dem RX-FIFO 18 der 3 für jedes CAN-Frame mit seinem ID-Value, Flags, Daten und (optional) Zeitstempel ein identischer Speicherbereich zur Verfügung gestellt wird, wird im RX-FIFO 18 der 4 für jeden CAN-Frame ein der Länge des CAN-Frames entsprechender Speicherbereich 13, 14, 15 oder 16 zugewiesen.
-
Dies wird durch die links vom RX-FIFO 18 dargestellte schematische Speicherbelegung verdeutlicht, wobei Pfeile auf den Beginn des jeweiligen, rechts dargestellten Speicherbereichs 13, 14, 15 und 16 hinweisen. Jeder Speicherbereich 13, 14, 15, 16 in der kontinuierlichen Darstellung beginnt mit einem Headerbereich HD, in dem der ID-Value, Flags, Zeitstempel (Timestamp, optional) und sonstige gegebenenfalls notwenige Information abgespeichert werden, wobei der Headerbereich HD eine konstante Länge aufweist. Nachfolgend dem Headerbereich HD folgt ein variabler Datenbereich D1, D2, D4 und D8, der die Nutzdaten des CAN-Frames enthält, wobei die Länge des jeweiligen Datenbereichs D1, D2, D4, D8 an die Nutzdaten des CAN-Frames angepasst ist. So umfasst der Datenbereich D1 eine Länge von 1 Byte, der Datenbereich D2 eine Länge von 2 Byte, der Datenbereich D4 eine Länge von 4 Byte und der Datenbereich D8 eine Länge von 8 Byte. Bei einem Mix-Betrieb von Standard-CAN mit maximal 8 Byte Nutzdaten und CAN-FD mit maximal 64 Byte Nutzdaten kann der Datenbereich in einem Speicherbereich 13, 14, 15, 16 daher zwischen 1 Byte und 64 Byte betragen.
-
Im Beispiel der 4 weist daher der im Speicherbereich 16 abgelegte CAN-Frame einen Datenbereich D2 mit einer Länge von 2 Byte, der im Speicherbereich 15 abgelegte CAN-Frame einen Datenbereich D1 mit einer Länge von 1 Byte, der im Speicherbereich 14 abgelegte CAN-Frame einen Datenbereich D8 mit einer Länge von 8 Byte und der im Speicherbereich 13 abgelegte CAN-Frame einen Datenbereich D4 mit einer Länge von 4 Byte auf. Auf diese Weise wird eine optimale Anpassung des RX-FIFOs 18 an die jeweilige Anzahl der Nutzdaten eines CAN-Frames erreicht und Leerdaten müssen vom Hostrechner nicht übernommen werden, wie dies bei festen Bereichsstrukturen des RX-FIFOs 18 der Fall ist. Ferner ist ein Pfeil 19 in 4 eingezeichnet, der symbolisch die Leserichtung des RX-FIFOs 18 darstellt.
-
Für einen optimierten Zugriff des Host-Rechners auf die Inhalte des RX-FIFOs kann es erforderlich sein, den Headerbereich auf bestimmte Startadressen im RX-FIFO einzuschränken. Damit kann eine Anpassung, ein sogenanntes Alignment, für einen effizienten 32/64 Bit Zugriff für den Host-Prozessor ermöglicht werden. Durch ein solches Alignment können zur Verbesserung des Datendurchsatzes ungenutzte Bytes im Datenbereich entstehen.
-
Bezugszeichenliste
-
- 1
- CAN Transceiver
- 2
- CAN Protocol Engine
- 3
- Steuerlogik
- 4
- Bitstream Encoder
- 5
- Bitstream Decoder
- 6
- Host Control Interface
- 7
- CAN-Frame-Speicherbereich
- 8
- CAN-Frame-Speicherbereich
- 9
- TX-FIFO
- 10
- Filter
- 11
- I D-Maskenbereich
- 12
- ID-Identifier-Bereich
- 13
- CAN-Frame-Speicherbereich
- 14
- CAN-Frame-Speicherbereich
- 15
- CAN-Frame-Speicherbereich
- 16
- CAN-Frame-Speicherbereich
- 18
- RX-FIFO
- 19
- Leserichtung
- 20
- TX-Nachrichtenpuffer
- 21
- CAN-Frame-Speicherelement
- 22
- CAN-Frame-Speicherelement
- 23
- CAN-Frame-Speicherelement
- 24
- CAN-Frame-Speicherelement
- 25
- Prioritätsselektor
- 26
- RX-Nachrichtenpuffer
- 27
- CAN-Filter-Speicherelement
- 28
- CAN-Filter-Speicherelement
- 29
- CAN-Filter-Speicherelement
- 30
- CAN-Filter-Speicherelement
- 31
- RX-Filterbank
- 32
- Filterelement
- 33
- Filterelement
- 34
- Filterelement
- 35
- Filterelement
- HD
- Header mit ID-Value, Flags, Timestamp etc
- D1
- Daten - Länge 1 Byte
- D2
- Daten - Länge 2 Byte
- D4
- Daten - Länge 4 Byte
- D8
- Daten - Länge 8 Byte
