DE10341514A1

DE10341514A1 - CAN-Controllermodul

Info

Publication number: DE10341514A1
Application number: DE10341514A
Authority: DE
Inventors: Siegfried Schoemaker; Marcus Dombrowski
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2003-09-04
Filing date: 2003-09-04
Publication date: 2005-04-14

Abstract

Die Erfindung betrifft ein CAN-Controllermodul (1), umfassend einen Mikroprozessor (2), einen CAN-Controller (3) und einen CAN-Transceiver (4), wobei der Mikroprozessor (2) mit einer seriellen Schnittstelle (5) ausgebildet ist, über die der Mikroprozessor (2) mit einer externen Recheneinheit (6) verbindbar ist, wobei der Mikroprozessor (2) mit einem Betriebssystem geladen ist, wobei das Betriebssystem derart ausgebildet ist, dass der Mikroprozessor (2) über die serielle Schnittstelle (5) konfigurierbar ist, sowie eine Vorrichtung zur Konfigurierung eines solchen CAN-Controllermoduls (1).

Description

Die Erfindung betrifft ein CAN-Controllermodul gemäß dem Oberbegriff des Patentanspruchs 1 sowie eine Vorrichtung zur Konfigurierung eines CAN-Controllermoduls.
In modernen Kraftfahrzeugen nimmt der Einsatz von vernetzten Steuergeräten kontinuierlich zu. Eines der am häufigsten eingesetzten Bussysteme ist dabei der CAN-Bus. Dabei wird im Wesentlichen ein CAN-Knoten im Netzwerk durch ein Steuergerät gebildet. Ein Steuergerät umfasst einen Mikroprozessor, einen CAN-Controller und einen CAN-Transceiver.
Die Aufgabe des Mikroprozessors in der CAN-Kommunikation ist lediglich das Auswerten und Generieren von Botschaften durch Beschreiben bzw. Auslesen von Registern des CAN-Controllers. Der CAN-Controller wickelt das gesamte CAN-Protokoll autark ab und leitet lediglich die Botschaften an den Mikroprozessor weiter, die dieser auch benötigt. Erreicht wird dieses durch Programmierung des CAN-Controllers mit verschiedenen Bus- und Filterparametern. Der CAN-Transceiver ist die physikalische Schnittstelle zum Übertragungsmedium, dem Kupferleitungspaar. Der CAN-Transceiver sendet und empfängt demnach auf physikalischer Ebene CAN-Botschaften. Er wandelt die massebezogenen Signale des Controllers in die auf den Leitungen messbaren rezessiven und dominanten Standarddifferenzpegel um und umgekehrt.
Darüber hinaus sind vereinzelt Steuergeräte bekannt, bei denen der Mikroprozessor mit einer seriellen Schnittstelle ausgebildet ist. Diese als RS-232 ausgebildete Schnittstelle kann dann für Diagnosezwecke mit einem Rechner verbunden werden.

Ein generelles Problem bei derartigen Bussystemen ist die elektromagnetische Verträglichkeit EMV. Dabei kann es zu unerwünschten Spannungs- und Stromspitzen auf der Busleitung kommen. Ursache hierfür können beispielsweise Reflexionen an nicht angepassten Endstellen sein oder externe Störquellen, die HF-Energie abstrahlen. Eine weitere Ursache sind beispielsweise unsymmetrische Differenzsignale.

Die EMV-Eigenschaften eines CAN-Netzwerkes im Kraftfahrzeug werden durch verschiedene Parameter beeinflusst. Ausschlaggebend sind u.a. die Eigenschaften der eingesetzten CAN-Transceiver, die Terminierung des Busses, die Ausdehnung und Ausführung der CAN-Verdrahtung und natürlich der Einsatz zusätzlicher, EMV-relevanter Bauteile, wie z.B. Gleichtaktdrosseln. Je größer die Gesamtausdehnung des Netzwerks, desto kritischer sind seine EMV-Eigenschaften. In der Automobilindustrie werden im PKW häufig aus wirtschaftlichen und praktischen Gründen Baum- oder Sterntopologien verwendet, deren Struktur somit stark von der in der ISO 11898 beschriebenen abweicht. Die Busterminierung weicht bei Kfz-CAN-Bussen ebenfalls oft von der Norm ab. Die beiden Busabschlusswiderstände von je etwa 120Ω werden in einem Steuergerät als zentraler Busabschluss von ca. 66Ω zusammengeführt. Alle anderen CAN-Knoten sind mit einem vergleichsweise hochohmigen Abschluss von ca. 2,6 kΩ an die CAN-Leitungen angebunden. Dieses Konzept des zentralen Busabschlusses vereinfacht die Anbindung zusätzlicher CAN-Knoten bei höher ausgestatteten Kraftfahrzeugen, wodurch ein erheblicher wirtschaftlicher Vorteil entsteht. Den Abschlussknoten bildet ein in jeder Ausstattungsvariante vorhandenes Steuergerät, z.B. das Motorsteuergerät.

Bei der Neuentwicklung von Steuergeräten bzw. des Netzwerkes stellt sich das technische Problem, die EMV beim Entwurf zu berücksichtigen. Dabei hat es sich jedoch erwiesen, dass häufig theoretische Vorüberlegungen bzw. Optimierung einzelner Steuergeräte bezüglich der EMV nicht den gewünschten Erfolg zeigen, wenn diese real im Kraftfahrzeug verbaut wurden. Allerdings stehen die Steuergeräte selbst erst zu einem relativ späten Zeitpunkt für EMV-Untersuchungen im Kraftfahrzeug zur Verfügung. Dies kann dann zu aufwendigen Nachbesserungen an den Steuergeräten führen, die gegebenenfalls den Serieneinsatz hinauszögern.

Der Erfindung liegt daher das technische Problem zugrunde, ein CAN-Controllermodul zu schaffen, mittels dessen frühzeitig die EMV-Eigenschaften eines Steuergerätes zuverlässig ermittelbar sind.

Die Lösung des technischen Problems ergibt sich durch die Gegenstände mit den Merkmalen der Patentansprüche 1 und 8. Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen.

Hierzu ist das Betriebssystem des Mikroprozessors derart ausgebildet, dass der Mikroprozessor über die serielle Schnittstelle konfigurierbar ist, wobei die Konfigurierung mittels eines auf einem externen Rechner befindlichen Konfigurationstool erfolgt. Mittels eines Initialisierungsprogramms erfolgt dann die Initialisierung des CAN-Controllers durch den Mikroprozessor. Das CAN-Controllermodul ist somit ein freiprogrammierbares Steuergerät-Dummy. Mittels dieses SG-Dummys lässt sich somit ein noch in der Entwicklung befindliches Steuergerät nachbilden. Dies stellt einen erheblichen zeitlichen Vorteil da, da bereits frühzeitig reale Tests im Kraftfahrzeug durchführbar sind. Dabei wird ausgenutzt, dass das Grundkonzept eines Steuergerätes bereits meist sehr früh in der Entwicklung steht, wobei andererseits diese Minimal-Version für die EMV-Untersuchungen bereits ausreichend ist. Neben den beschriebenen Feldversuchen können somit auch einfach einzelne EMV-relevante Komponenten frühzeitig untersucht werden.

Ein anderes Anwendungsgebiet des freiprogrammierbaren CAN-Controllermoduls ist seine Verwendung als einfacher Botschaftengenerator. Bei verschiedenen Anwendungen im Kraftfahrzeugbereich, auch außerhalb der EMV, ist es erforderlich, bestimmte CAN-Botschaften in einem Netzwerk zu simulieren. Beispielsweise lassen sich moderne Steuergeräte auf dem Labortisch nur programmieren, wenn sie über den CAN-Bus bestimmte Signale erhalten. Diese Signale werden von anderen Steuergeräten im Fahrzeug geliefert, stehen aber auf dem Labortisch nur zur Verfügung, wenn auch diese Steuergeräte in das CAN-Netzwerk eingebunden werden. Dies lässt sich vermeiden, indem ein SG-Dummy so programmiert wird, dass er die erforderlichen Botschaften mit den benötigten Signalen zyklisch liefert.

Vorzugsweise sind mindestens die Identifier der zu sendenden CAN-Botschaften konfigurierbar und besonders bevorzugt zusätzlich die Zykluszeiten und/oder die Payload der Botschaften.

In einer weiteren bevorzugten Ausführungsform ist mindestens der CAN-Transceiver lösbar auf seiner ihm zugeordneten Leiterplatte angeordnet. Dies ermöglicht einen einfachen vergleichenden EMV-Test mit unterschiedlichen CAN-Transceivern. Des Weiteren ermöglicht dies auch eine Verwendung des CAN-Controllermoduls in CAN-High-Speed- als auch in CAN-Low-Speed-Systemen. Letzteres kann auch dadurch erreicht werden, dass beide Transceiver auf der Leiterplatte angeordnet sind und eine Umschaltmöglichkeit vorgesehen ist. Des Weiteren ist es auch möglich, den Transceiver komplett mit Leiterplatte auszutauschen.

In einer weiteren bevorzugten Ausführungsform sind zwischen dem CAN-Transceiver und dem physikalischen Busanschluss Entstörungselemente angeordnet, wobei die Entstörungselemente lösbar auf einer zugeordneten Leiterplatte angeordnet sind. Die Leiterplatte für die Entstörungselemente kann entweder die Leiterplatte mit dem CAN-Transceiver oder eine separate Leiterplatte sein. Die Entstörungselemente sind beispielsweise Gleichtaktdrosseln, Busabschlusswiderstände, Stütznetzwerke, Kondensatoren und Varistoren. Somit können auch einzelne Entstörungselemente hinsichtlich ihrer Auswirkungen auf die EMV getestet werden, was bei üblicherweise in Hybridtechnik aufgebauten Steuergeräten nicht mehr möglich ist, insbesondere wenn diese auch noch mit Kunststoff vergossen werden.

In einer weiteren bevorzugten Ausführungsform sind der Mikroprozessor und/oder der CAN-Controller in einem separaten Gehäuse angeordnet, vorzugsweise aus Weißblech, wodurch störende HF-Einkopplungen und -Emissionen unterdrückt werden.

Die Erfindung wird nachfolgend anhand eines bevorzugten Ausführungsbeispiels näher erläutert. Die Fig. zeigen:

1 ein schematisches Blockschaltbild eines CAN-Controllermoduls für High-Speed-CAN-Anwendungen (Stand der Technik),

2 ein schematisches Blockschaltbild eines freiprogrammierbaren CAN-Controllermoduls mit Anbindung an einen externen Rechner und eines CAN-Analyse- und Simulationsmoduls,

3 ein Struktogramm des Hauptprogramms des Mikroprozessors,

4 eine Tabelle verwendeter Variablen,

5 ein Struktogramm einer Interrupt-Service-Routine und

6 ein Ablaufdiagramm der Kommunikation zwischen Mikroprozessor und externem Rechner.

In der 1 ist ein Steuergerät 1 für ein High-Speed-CAN-Bussystem dargestellt. Das Steuergerät 1 umfasst einen Mikroprozessor 2, einen CAN-Controller 3 und einen CAN-Transceiver 4. Dabei sind der Mikroprozessor 2 und der CAN-Controller 3 als integrierte Lösung dargestellt. Es sind jedoch auch Ausführungen möglich, wo beide als separate Halbleiterelemente ausgebildet sind. Zwischen den Ein- bzw. Ausgängen des CAN-Controller 3 und dem CAN-Transceiver 4 sind zwei Widerstände R_{CAN_RX} und R_{CAN_RX} zur Pegelanpassung angeordnet. Zwischen den Eingängen CAN_H und CAN_L des CAN-Transceivers 4 und den physikalischen Busleitungen CAN_H bzw. CAN_L ist eine Gleichtaktdrossel L_CM, die insbesondere die Störfestigkeit im Frequenzbereich von 15-25 MHz verbessert. Des Weiteren ist zwischen Betriebsspannung V_CC und Masse ein erster Spannungsteiler R_S1, R_S2 und zwischen CAN_H und CAN_L ein zweiter Spannungsteiler R_T1, R_T2 angeordnet, deren gemeinsamer Mittelabgriff über einen Kondensator C_SPLIT gegen Masse geschaltet ist. Die Funktion des ersten Spannungsteilers ist die Unterstützung des rezessiven Spannungspegels auf der Datenleitung CAN_H bzw. CAN_L. Der zweite Spannungsteiler stellt einen geteilten Busabschlusswiderstand dar, wobei über den Kondensator C_SPLIT ein AC-Grounding von den Datenleitungen und den Betiebsspannungsleitungen erreicht wird. Des Weiteren können optional die beiden Datenleitungen CAN_H und CAN_L noch direkt über die Kondensatoren C_EMV1 bzw. C_EMV2 gegen Masse geschaltet sein. Weiter sind noch zwei Varistoren V_ESD1 und V_ESD2 dargestellt, die einen Schutz gegen elektrostatische Entladungen gewährleisten. Schließlich ist noch ein Kondensator C_SCH eingezeichnet, der zwischen einem Schirm der verdrillten Datenleitungen und Masse geschaltet ist. Alle diese Bauelemente stellen EMV-Entstörungselemente dar. Üblicherweise wird ein derartiges Steuergerät 1 in Hybrid-Technik aufgebaut und gegebenenfalls mit Kunststoff vergossen, so dass die einzelnen Elemente nicht mehr einfach austauschbar sind.
In der 2 ist nun schematisch eine erfindungsgemäße Vorrichtung zur Konfigurierung eines CAN-Controllermoduls 1' dargestellt, wobei aus Gründen der Übersicht die Entstörungselemente nicht dargestellt sind. Das CAN-Controllermodul 1' umfasst wieder einen Mikroprozessor 2, einen CAN-Controller 3 und einen CAN-Transceiver 4, der mit den Datenleitungen CAN_H und CAN_L verbunden ist. Der Mikroprozessor 2 ist über eine serielle Datenschnittstelle 5, vorzugsweise eine RS-232-Schnittstelle, mit einem externen Rechner 6, der beispielsweise als PC ausgebildet ist, verbunden. Zwischen den beiden Schnittstellen 5, 7 kann dabei ein nicht dargestelltes Spannungspegel-Anpass-Modul angeordnet sein. Der externe Rechner 6 ist mit einer Eingabeeinheit 8 und einer weiteren Schnittstelle 9 ausgebildet. Über die weitere Schnittstelle 9 ist der externe Rechner 6 mit einem CAN-Analyse- und Simulationsmodul 10 verbunden. Derartige CAN-Analyse- und Simulationsmodule sind beispielsweise unter dem Handelsnamen CANoe oder CANalyzer der Firma Vector bekannt.
Diese bekannten CAN-Analyse- und Simulationsmodule stellen umfangreiche Funktionen zur Analyse und Beeinflussung des Datenverkehrs in einem CAN-Netzwerk zur Verfügung. Neben einer statistischen Auswertung der Buslast können auch einzelne CAN-Botschaften gezielt untersucht werden und beispielsweise bestimmte Signale über der Zeit grafisch dargestellt werden. Eine wichtige Funktion ist dabei das Loggen des Datenverkehrs in eine ASCII-Datei. Diese Dateien können dann von dem CAN-Analyse- und Simulationsmodul an den externen Rechner 6 übertragen werden, wo diese ausgewertet und zur Konfigurierung des CAN-Controllermoduls verwendet werden können. Mittels diesser Log-Dateien kann insbesondere eine Payload für die Botschaften im freiprogrammierbaren CAN-Controllermodul erstellt werden. Dabei sei angemerkt, dass mit diesen CAN-Analyse- und Simulationsmodulen eine sogenannte Rest-Bus-Simulation durchführbar ist, wobei ein Teil der Knoten eines zu untersuchenden Netzwerkes durch den PC des CAN-Analyse- und Simulationsmoduls ersetzt wird, indem dieser die fehlenden Botschaften in das Netzwerk sendet. Allerdings sind diese CAN-Analyse- und Simulationsmodule sehr teuer.
Des Weiteren enthalten moderne CAN-Analyse- und Simulationsmodule einen Datenbankeditor. Mit Hilfe dieses Editors kann für ein Netzwerk eine Datenbasis erstellt werden, auf die dann bei der Analyse zugegriffen werden kann. Die Datenbasis enthält z.B. Zuordnungen von Klartextnamen zu den numerischen Identifiern der CAN-Botschaften. Auch die einzelnen Signale, die in den CAN-Botschaften übermittelt werden, also praktisch die Daten der Botschaften, erhalten mit Hilfe der Datenbanken aussagekräftige Namen. Es können auch zusätzliche Informationen, wie Umrechnungsformeln zu physikalischen Größen o.ä., in die Datenbasen aufgenommen werden. Die Datenbasis-Dateien liegen dabei meist sehr früh in der Entwicklungsphase eines neuen Steuergerätes vor. Mittels dieser Datenbasen kann somit ein Steuergerät bereits frühzeitig nachgebildet werden.
Bevor nun die Arbeitsweise der Vorrichtung gemäß 2 näher beschrieben wird, sollen zuvor noch einige Vorüberlegungen angestellt werden. Damit der Mikrocontroller 2 mit dem Konfigurationstool des Rechners 6 kommunizieren kann, muss dessen Betriebsprogramm entsprechend programmiert werden. Dies kann beispielsweise über ein sogenanntes Entwicklungsboard erfolgen, was die Hersteller der Mikrocontroller zur Verfügung stellen. Dazu verfügt der Mikroprozessor beispielsweise über einen Flash-Speicher, der das Betriebsprogramm aufnimmt und seriell bei in das Board eingesetztem Clip programmiert werden kann. Des Weiteren umfasst der Mikrocontroller 2 einen nichtflüchtigen Datenspeicher, der beispielsweise als EEPROM und/oder SRAM ausgebildet ist und zur Abspeicherung der Daten des Konfigurationstools dient. Mittels des Konfigurationstools können nun CAN-Botschaften erstellt und editiert werden. Dabei kann bedarfsweise auf die Datenbasen und Log-Daten des CAN-Analyse- und Simulationsmoduls zurückgegriffen werden. Diese CAN-Botschaftenlisten können dann über die serielle Schnittstelle zum Mikroprozessor übertragen und dort im nichtflüchtigen Speicher gespeichert werden. Auf dem Mikrocontroller läuft dann ein Programm ab, das neben der seriellen Kommunikation zum Rechner 6 die im EEPROM gespeicherten CAN-Botschaften zyklisch über den CAN-Controller auf den CAN-Bus sendet. Die Zykluszeiten sind dabei bis zu einer maximalen Zykluszeit frei konfigurierbar. Vorzugsweise ist dieses Programm derart ausgebildet, dass beim Empfang eines Zeichens über die serielle Schnittstelle dieses automatisch in einen Konfigurationsmodus umschaltet und nach erfolgter Programmierung dieses wieder verlässt.
Über die Eingabeeinheit 8 und/oder die Schnittstelle können nun Daten zur Erstellung einer CAN-Botschaftenliste in das Konfigurationstool eingelesen werden, wobei neben der Anzahl und der Nummer der Identifier auch die Payload und die Zykluszeiten einstellbar sind. Damit kann mittels des CAN-Controllermoduls eine einfache Rest-Bus-Simulation durchgeführt werden.
Ein besonders wichtiges Einsatzgebiet sind jedoch die EMV-Untersuchungen. Hierzu kann ein geplantes CAN-Netzwerk bereits im Vorfeld der Entwicklung auf EMV-Eigenschaften untersucht werden. Dazu wird jedes geplante Steuergerät im Netzwerk durch ein freikonfigurierbares CAN-Controllermodul ersetzt, wobei diese jeweils mit ihren zugehörigen CAN-Botschaften konfiguriert werden. Die CAN-Controllermodule werden dann physikalisch in einem Kraftfahrzeug an den Stellen eingebaut, wo später die fertigen Steuergeräte eingebaut werden sollen. Somit lässt sich bereits frühzeitig ein Feldversuch hinsichtlich der EMV-Eigenschaften des geplanten CAN-Netzwerkes durchführen.
Des Weiteren können auch Entstörungselemente wie Gleichtaktdrosseln oder Kondensatoren erprobt werden, und zwar im Feldversuch wie zuvor beschrieben oder aber mittels der bekannten Messaufbauten im Labor wie beispielsweise TEM-Zelle. Dabei wird ausgenutzt, dass vorzugsweise alle EMV relevanten Elemente des CAN-Controllermoduls lösbar auf ihren zugeordneten Leiterplatten angeordnet sind und so für vergleichende Messungen ausgetauscht werden können.
Dabei sei generell angemerkt, dass prinzipiell bestimmte Konfigurierungen des CAN-Controllermoduls bei der Programmierung des Betriebsprogramms des Mikroprozessors durchführbar wären. Allerdings hätte dies jeweils Umprogrammierungen des Flash-Speichers zur Folge, falls das Controllermodul anderweitig eingesetzt werden soll. Da die Anzahl der Flash-Umprogrammierungen begrenzt und im übrigen relativ zeitintensiv ist, hätte diese Vorgehensweise einige Nachteile. Des Weiteren sei an dieser Stelle angemerkt, dass die Ausführungen für ein CAN-Controllermodul generell auf Controllermodule anderer Bussysteme, wie beispielsweise LIN-, FlexRay- oder MOST-Bussysteme, übertragbar sind.
Vorzugsweise wird die CAN-Botschaftenliste beim Aussenden des Mikroprozessors über die serielle Schnittstelle zum externen Rechner zurückübertragen, was eine Kontrolle der Programmierung ermöglicht. Des Weiteren ist der Mikroprozessor mit einem Watchdog- Timer ausgebildet, der bei Störungen durch Störfestigkeitsmessungen eines Neustarts des Mikroprozessors initiert.
Übliche Zykluszeiten für CAN-Botschaften bei CAN-High-Speed-Anwendungen liegen zwischen sieben und einigen 100 ms. Dies kann dazu ausgenutzt werden, um einen internen Timer des Mikroprozessors derart zu programmieren, dass dieser nach beispielsweise jeder Millisekunde das Hauptprogramm mittels eines Interrupts unterbricht. Die Interrupt-Service-Routine (ISR) sollte die Millisekunden mitzählen und mit den im Speicher abgelegten Zykluszeiten für die einzelnen CAN-Botschaften vergleichen. Bei einer Übereinstimmung kommt es dann zur Aussendung der betreffenden Botschaft durch ein Unterprogramm. So kann das Hauptprogramm ständig den Eingangspuffer der seriellen Schnittstelle abfragen und automatisch in eine Programmier-Routine verzweigen. Damit wird ein Schalter eingespart, der das Gerät in den Programmiermodus schaltet, und der Bedienkomfort erhöht.
In der 3 ist ein Struktogramm des Hauptprogramms des Mikroprozessors dargestellt. Der Initialisierungsblock wird einmalig nach dem Prozessorstart ausgeführt. Hier werden Konstanten, Variablen und Subroutinen deklariert und der Watchdog-Timer sowie weitere Kontrollregister des Mikrocontrollers programmiert. Der interne Timer 1 wird so eingestellt, dass nach Ablauf einer Millisekunde der sogenannte Compare1A-Interrupt ausgelöst wird. Dafür werden zwei spezielle Register mit einem Wert geladen. Das Register OCR1AH nimmt das Highbyte und das Register OCR1AL das Lowbyte auf. Erreicht der Timer 1 diesen Wert, wird der besagte Interrupt ausgelöst und der Timer zurückgesetzt. Bei einem Arbeitstakt von 3,686 MHz dauert ein Takt
Zum Erreichen einer Millisekunde müssen also
Takte gezählt werden. Dieser Wert ist mit einem 16 Bit-Timer, wie dem hier verwendeten Timer 1, ohne zusätzlichen Vorteil zu erreichen. Der Vorteil ist, in der Lage den Prozessortakt bei Bedarf durch 8, 64, 256 und 1024 vorzuteilen, womit auch größere Zeiten im Vergleich zum Prozessortakt erreicht werden können.
Die Initialisierung des CAN-Controllers wird durch ein eigenes Unterprogramm mit dem Namen „InitSJA" durchgeführt. Darin wird der Controller zuerst in den Reset-Modus versetzt und anschließend verschiedene Kontrollregister beschrieben. Zum besseren Verständnis der später erläuterten Unterprogramme ist eine Erklärung des Speicherkonzeptes innerhalb des Programms erforderlich. 4 listet die verwendeten Variablen sowie ihren Speicherort innerhalb des Mikrocontrollers in ihren Verwendungszweck auf. Leider ist es aus hardware-technischen Gründen häufig nicht möglich, bei Lese- und Schreibzugriffen direkt Variablen als Quellen oder Ziel anzugeben, die nichtflüchtig im EEPROM gespeichert sind. Deshalb sind die Puffer-Variablen „Wordbuf", „Bytebuf" und Ln" erforderlich. Die Daten der CAN-Botschaften sind als einzelne Felder nichtflüchtig im EEPROM gespeichert. Die Felder reichen dabei bis zur Konstante „maxmsgs", die die maximale Anzahl zu verarbeitender Botschaften durch den SG-Dummy festlegt. Der Zugriff auf diese einzelnen Daten geschieht über den Feldnamen und der Variable „Msgnr" als Index. Z.B. sendet das
Msgnr = 4
Bytebuf = Epayloado[Msgr☐
Print Bytebuf
den Inhalt des ersten Inhaltsbytes von CAN-Botschaften vier über die serielle Schnittstelle aus.
Nach den einmaligen Initialisierungen springt das Programm in eine Endlosschleife, in der ständig der Empfangspuffer der seriellen Schnittstelle abgefragt wird. Wird ein Zeichen empfangen, so werden Watchdog und Compare1A-Interrupt maskiert und das Programm befindet sich somit im Programmiermodus. Der Programmiermodus wird durch Setzen eines Portpins, an den eine gelbe LED angeschlossen wird, angezeigt. Je nach empfangenem Zeichen wird nun entweder eine CAN-Botschaftenliste eingelesen oder ausgesendet, oder einfach ein Versionshinweis zum Mikrocontrollerprogramm mit der Anzahl der gespeicherten CAN-Botschaften gesendet. Zum Einlesen bzw. Aussenden der einzelnen Botschaften wird je ein Unterprogramm „SerRxMsg" bzw. SerTxMsg" verwendet, das in einer Schleife entsprechend der Anzahl der zu übertragenen Nachrichten oft ausgerufen wird. Für den Datenaustausch über die serielle Schnittstelle wurde ein Handshake auf Applikationsebene entwickelt, bei dem der Empfänger jeweils die nächste Information vom Sender abfragt. Kommt es bei diesem Handshake zu einem Fehler, so wird ein Ausgangspin gesetzt, so dass durch eine rote LED ein Kommunikationsfehler angezeigt wird. Bei der nächsten einwandfreien Übertragung wird diese LED wieder gelöscht.
Nach Ablauf einer Millisekunde erzeugt Timer1 einen Interrupt und das Programm verzweigt in eine Interrupt-Service-Routine ISR. 5 zeigt den Ablauf der ISR. Es werden zunächst für den Ablauf der ISR alle Interrupts maskiert. Nach dem inkrementieren des Zeitzählers „Timecount" erfolgt in einer Schleife die Suche nach zu diesem Zeitpunkt auszusendenden Botschaften. Eine Modulo-Division gewährleistet die zyklische Aussendung derselben Botschaft auch an Vielfachen ihrer Zykluszeit. Müssen zu diesem Zeitpunkt Botschaften ausgesendet werden, so wird in die dafür vorgesehene Subroutine „TxCANMsg" verzweigt und dieser die Nummer der auszusenden Botschaft mittels der globalen Variable „MsgNr" übergeben.
Nach Abfrage aller gespeicherten Botschaften wird auf das Erreichen der maximalen Zykluszeit getestet und „Timecount" gegebenenfalls zurückgesetzt. Botschaften mit einer längeren Zykluszeit als durch die Konstante „maxcycle" gegeben, werden jetzt ausgesendet. Durch ein Setzen von „maxcycle" auf den Wert 1000 werden alle Botschaften mindestens einmal pro Sekunde ausgesendet. Das ist sinnvoll, weil die Verweildauer eines elektromagnetischen Feldes konstanter Frequenz und Feldstärke bei EMV-Messungen häufig eine Sekunde beträgt. Beim Erreichen von „maxcycle" wird außerdem ein Ausgangspin, an den die Betriebsanzeige in Form einer grünen LED angeschlossen ist, getoggelt. Somit blinkt diese LED im Normalbetrieb mit einer Frequenz von einem halben Hertz.
Auf eine Besonderheit der Subroutine „TxCANMsg" muss noch hingewiesen werden. Sie greift erst dann auf den CAN-Controller zu, wenn dieser einen leeren Sendepuffer signalisiert, d.h. die vorige Nachricht auf dem CAN-Bus ausgesendet wurde. Sollte dies nach einer kurzen Warteschleife nicht der Fall sein, so wird wieder die rote LED zur Anzeige eines Kommunikationsfehlers geschaltet, wie auch schon bei der Kommunikation über die serielle Schnittstelle, und das Programm fortgesetzt. Im Normalbetrieb werden CAN-Botschaften durch den Controller schnell genug ausgesendet, ohne dass es zu diesem Fehler kommt. Ist der SG-Dummy aber beispielsweise an keinen terminierten Bus mit mindestens einem anderen Teilnehmer angeschlossen, tritt dieser Fall ein.
Aus 3 ist bereits ersichtlich, dass die Mikrocontrollersoftware beim Empfang eines Zeichens über die serielle Schnittstelle in einen Programmiermodus schaltet. Je nach empfangenem Zeichen wird entweder lediglich ein Versionshinweis mit der Anzahl der aktuell gespeicherten Botschaften ausgesendet, oder eine Botschaftenliste empfangen bzw. ausgesendet. Für den Empfang bzw. die Aussendung der Botschaftenliste wurde ein Handshake auf Applikationsebene entwickelt. Der Grundgedanke dabei ist, dass der jeweilige Empfänger mittels eines in beiden Programmen definierten Schlüsselwortes nach einem bestimmten Datum der gerade zu übertragenen Botschaft fragt. Der Sender wertet dieses Schlüsselwort aus und antwortet mit dem entsprechenden Datum. Alle Daten werden als Strings übertragen, die Identifier sowie die einzelnen Botschaftsinhalte in hexadezimaler Form. Am Beispiel der Übertragung einer Botschaftenliste vom Recner 6 zum SG-Dummy soll dieses Handshake im Folgenden erläutert werden. 6 zeigt den zeitlichen Ablauf dieser Kommunikation.
Der Rechner 6 fordert den SG-Dummy mit der Aussendung des Buchstaben „r" auf, eine Botschaftenliste zu empfangen. Der Mikrocontroller fragt mit dem Schlüsselwort „msgcount?" nach der Anzahl der zu übertragenen Botschaften, diese Anzahl teilt der Rechner ihm mit der Variable „m_iMsgCount" mit. Damit steht die Anzahl der Aufrufe des Unterprogramms „SerRxMsg" im Mikrocontroller fest. Dieses Programm wickelt das Handshake für jede einzelne Botschaft ab. Es fragt jetzt nacheinander alle Daten der aktuell übertragenen Botschaft ab. Dazu gehören die Botschaftsnummer, der Identifier, die Zykluszeit, die Datenfeldlänge und die acht Datenbytes. Jedes Datum wird mit einem eigenen Schlüsselwort angefordert. Sind diese Daten übertragen und gespeichert, wird dies dem Rechner mit dem String „ACK!" quittiert. Nach der Beendigung von „SerRxMsg" wird es sofort erneut aufgerufen, um die nächste Botschaft zu empfangen. Dieser Vorgang wiederholt sich, bis schließlich alle Botschaften übermittelt sind. Das Mikrocontrollerprogramm schaltet anschließend wieder in den normalen Betriebsmodus und der SG-Dummy beginnt sofort, die gerade gespeicherten Botschaften über den CAN-Bus auszusenden.
Die Übertragung der aktuell im SG-Dummy gespeicherten Botschaftsliste zum Rechner funktioniert ähnlich. Sie wird durch den Empfang des Zeichens „t" initiiert. Sind alle Botschaften übermittelt, signalisiert der Mikrocontroller dies durch den String „fertig!".

Claims

CAN-Controllermodul, umfassend einen Mikroprozessor, einen CAN-Controller und einen CAN-Transceiver, wobei der Mikroprozessor mit einer seriellen Schnittstelle ausgebildet ist, über die der Mikroprozessor mit einer externen Recheneinheit verbindbar ist, wobei der Mikroprozessor mit einem Betriebssystem geladen ist, dadurch gekennzeichnet, dass das Betriebssystem derart ausgebildet ist, dass der Mikroprozessor (2) über die serielle Schnittstelle (5) konfigurierbar ist.
CAN-Controllermodul nach Anspruch 1, dadurch gekennzeichnet, dass mindestens die Identifier der zu sendenden CAN-Botschaften konfigurierbar sind.
CAN-Controllermodul nach Anspruch 2, dadurch gekennzeichnet, dass mindestens die Zykluszeiten und/oder die Payload der Identifier konfigurierbar sind.
CAN-Controllermodul nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass mindestens der CAN-Transceiver (4) lösbar auf seiner ihm zugeordneten Leiterplatte angeordnet ist.
CAN-Controllermodul nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Mikroprozessor (2) zwischen High-Speed- und Low-Speed-Modus umschaltbar ist.
CAN-Controllermodul nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass zwischen dem CAN-Transceiver (4) und dem physikalischen Busanschluss Entstörungselemente angeordnet sind, wobei die Entstörungselemente lösbar auf einer zugeordneten Leiterplatte angeordnet sind.
CAN-Controllermodul nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Mikroprozessor (2) und/oder der CAN-Controller (3) mit einem separaten Gehäuse abgeschirmt sind.
Vorrichtung zur Konfigurierung eines CAN-Controllermoduls nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Vorrichtung über eine serielle Schnittstelle (7) mit dem Mikroprozessor (2) verbunden ist und mit einem Konfigurationstool ausgebildet ist, wobei über das Konfigurationstool der Mikroprozessor (2) konfigurierbar ist.
Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, dass mindestens die Identifier durch das Konfigurationstool eingebbar sind.
sVorrichtung nach Anspruch 9, dadurch gekennzeichnet, dass mindestens die Zykluszeiten und/oder die Payload durch das Konfigurationstool eingebbar sind.
Vorrichtung nach einem der Ansprüche 8 bis 10, dadurch gekennzeichnet, dass mittels des Konfigurationstools zwischen High-Speed- und Low-Speed-Anwendungen umgeschaltet werden kann.
Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Vorrichtung mit einer weiteren Schnittstelle (9) ausgebildet ist, mittels derer Datenbasen und/oder Log-Dateien eines CAN-Analyse- und Simulationsmoduls (10) einlesbar und in Konfigurationsdaten konvertierbar sind.