DE10006970B4

DE10006970B4 - Netzwerk-Controller

Info

Publication number: DE10006970B4
Application number: DE2000106970
Authority: DE
Inventors: Jens Dr. Barrenscheen; Tobias Wenzel
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2000-02-16
Filing date: 2000-02-16
Publication date: 2006-04-06
Anticipated expiration: 2020-02-17
Also published as: DE10006970A1

Abstract

Netzwerk-Controller, insbesondere CAN-Controller, zum Anschluß einer an ein Netzwerk anzuschließenden Einrichtung an das Netzwerk, dadurch gekennzeichnet, daß der Netzwerk-Controller statisch und/oder dynamisch so intialisierbar und/oder konfigurierbar ist, daß er sich selbst und die über ihn ans Netzwerk angeschlossene Einrichtung steuern kann, wobei der Netzwerk-Controller in der Lage ist, auf eigene Veranlassung hin bestimmte Aktionen durchzuführen oder anzustoßen.

Description

Die vorliegende Erfindung betrifft eine Vorrichtung gemäß dem Oberbegriff des Patentanspruchs 1, d. h. einen Netzwerk-Controller zum Anschluß einer an ein Netzwerk anzuschließenden Einrichtung an das Netzwerk.

Das Netzwerk kann beispielsweise ein sogenanntes Controller Area Network (CAN) sein; der Netzwerk-Controller ist in diesem Fall ein sogenannter CAN-Controller.

CAN-Controller sind Bausteine, die unter Steuerung durch eine übergeordnete Steuereinrichtung

– aus dem über das CAN (den CAN-Bus) fließenden Datenstrom die Daten extrahieren, die für die über den betreffenden CAN-Controller ans CAN angeschlossene Einrichtung bestimmt sind, und
– die Daten, die von der über den betreffenden CAN-Controller ans CAN angeschlossenen Einrichtung auszugeben sind, auf den CAN-Bus ausgeben.

Die die CAN-Controller steuernden Steuereinrichtungen sind programmgesteuerte Einheiten wie Mikroprozessoren, Mikrocontroller und dergleichen. Sie sind im allgemeinen Bestandteil der über den CAN-Controller ans CAN anzuschließenden Einrichtung und steuern neben dem CAN-Controller zumindest teilweise auch die sie enthaltende Einrichtung.

Da viele CAN-Controller nur mit bestimmten Steuereinrichtungen kombiniert werden können, ist es mitunter schwierig oder gar unmöglich, eine CAN-Controller/Steuereinrichtungs-Kombination zu finden, bei welcher sowohl der CAN-Controller als auch die Steuereinrichtung die an sie gestellten Anforderun gen genau erfüllen, also nicht unterdimensioniert, aber nach Möglichkeit auch nicht überdimensioniert sind.

Es gibt auch Steuereinrichtungen (Mikrocontroller), die bereits ein zum Anschluß einer ans CAN anzuschließenden Einrichtung ans CAN geeignetes (CAN-)Modul enthalten. Die Verwendung eines solchen Mikrocontrollers ermöglicht es, auf einen (separaten) CAN-Controller zu verzichten. Solche Bauteile vermögen die vorstehend genannten Probleme jedoch nicht zu lösen. Im Gegenteil: es ist noch schwieriger, eine Hardware-Auswahl zu treffen, durch welche die gestellten Anforderungen genau erfüllt werden.

Es muß daher nicht selten akzeptiert werden, daß entweder der CAN-Controller (das CAN-Modul) oder die Steuereinrichtung (der Mikrocontroller) erheblich überdimensioniert oder unterdimensioniert sind. Beides ist nachteilig. Ist eine der genannten Komponenten überdimensioniert, so wird die damit auszustattende Einrichtung unnötig teuer, groß und/oder kompliziert; ist eine der genannten Komponenten unterdimensioniert, so müssen eine geringe Leistung oder ein geringer Leistungsumfang in Kauf genommen werden oder anderweitig ausgeglichen werden.

Die genannten Probleme sind besonders nachteilig, wenn die über den CAN-Controller ans CAN anzuschließende Einrichtung nur aus den genannten Gründen nicht schnell und/oder einfach entwerfbar und/oder klein und/oder billig herstellbar ist.

Über Netzwerk-Controller der im Oberbegriff des Patentanspruchs 1 beanspruchten Art und sonstige Netzwerk-Controller gibt es eine Vielzahl von Veröffentlichungen, beispielsweise die WO 92/03881 A1, die DE 43 19 485 C2 , und die DE 42 29 931 C2 . Diesen Veröffentlichungen sind jedoch keine Anregungen zur Lösung der vorstehend erwähnten Probleme entnehmbar.

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, eine Möglichkeit zu finden, durch welche eine über einen Netzwerk-Controller ans Netzwerk anzuschließende Einrichtung unter allen Umständen verhältnismäßig schnell, einfach, klein und/oder billig entwerfbar und herstellbar ist.

Diese Aufgabe wird erfindungsgemäß durch die im kennzeichnenden Teil des Patentanspruchs 1 beanspruchten Merkmale gelöst.

Demnach ist vorgesehen, daß der Netzwerk-Controller statisch und/oder dynamisch so intialisierbar und/oder konfigurierbar ist, daß er sich selbst und die über ihn ans Netzwerk angeschlossene Einrichtung steuern kann, wobei der Netzwerk-Controller in der Lage ist, auf eigene Veranlassung hin bestimmte Aktionen durchzuführen oder anzustoßen.

Dadurch kann auf eine den Netzwerk-Controller steuernde Steuereinrichtung verzichtet werden. Dieser Verzicht ermöglicht es, daß "nur" ein die gestellten Anforderungen erfüllender Netzwerk-Controller, und nicht mehr wie bisher zusätzlich eine den Netzwerk-Controller steuernde Steuereinrichtung gefunden und in die über den Netzwerk-Controller ans Netzwerk anzuschließende Einrichtung integriert werden muß.

Indem der Netzwerk-Controller auch die über ihn ans Netzwerk angeschlossene Einrichtung steuern kann, kann die über den Netzwerk-Controller anzuschließenden Einrichtung ohne eine Steuereinrichtung wie einen Mikroprozessor oder Mikrocontroller auskommen.

Dies erweist sich in zweifacher Hinsicht als vorteilhaft:
einerseits, weil die über den Netzwerk-Controller ans Netzwerk anzuschließenden Einrichtung weniger Bauteile enthält, und andererseits, weil dadurch die Notwendigkeit entfällt, den bislang obligatorischen Mikroprozessor oder Mikrocontroller zu programmieren.

Die über einen solchen Netzwerk-Controller ans Netzwerk anzuschließende Einrichtung ist dadurch schnell, einfach, klein und/oder billig entwerfbar und herstellbar.

Vorteilhafte Weiterbildungen der Erfindung sind den Unteransprüchen, der nachfolgenden Beschreibung und der Figur entnehmbar.

Die Erfindung wird nachfolgend anhand eines Ausführungsbeispiels unter Bezugnahme auf die Figur näher erläutert.
Die Figur zeigt ein Blockschaltbild des nachfolgend näher beschriebenen Netzwerk-Controllers.
Der Netzwerk-Controller, der nachfolgend näher beschrieben wird, ist ein CAN-Controller, d.h. ein Controller zum Anschluß einer Einrichtung an ein sogenanntes Controller Area Network (CAN), genauer gesagt an einen CAN-Bus.
Es sei jedoch bereits an dieser Stelle darauf hingewiesen, daß hierauf keine Einschränkung besteht. Die nachfolgend näher beschrieben Besonderheiten des CAN-Controllers sind grundsätzlich auch bei beliebigen anderen Netzwerk-Controllern anwendbar.
Der betrachtete CAN-Controller ist ein sogenannter TwinCAN-Controller, d.h. ein CAN-Controller, der die ihn enthaltende Einrichtung an zwei CANs anschließen kann (ein CAN-Controller, der zwei CAN-Busse bedienen kann).
Auch hierauf besteht jedoch keine Einschränkung. Die nachfolgend näher beschrieben Besonderheiten des CAN-Controllers sind auch bei CAN-Controllern anwendbar, die nur mit einem CAN-Bus oder mehr als zwei CAN-Bussen verbunden werden können.
Der Aufbau des vorliegend näher betrachteten CAN-Controllers ist in der Figur dargestellt.
Der CAN-Controller enthält eine CAN-data-link-control-Einheit 1, eine Steuereinheit 2, eine zum Anschluß an einen ersten CAN-Bus vorgesehenen ersten CAN-Knoten 3, einen zum Anschluß an einen zweiten CAN-Bus vorgesehenen zweiten CAN-Knoten 4, eine im betrachteten Beispiel durch eine sogenannte Synchronous-Serial-Channel-Einheit (SSC-Einheit) gebildete serielle Schnittstelle 5, und eine für die gängigen Zugriffsprotokolle ausgelegte parallele Schnittstelle 6. Der CAN-Controller weist eine Vielzahl von Ein- und/oder Ausgabeanschlüssen auf, von welchen in der Figur jedoch nicht alle dargestellt sind.
Der betrachtete CAN-Controller kann wie herkömmliche CAN-Controller

– aus dem über das CAN (den CAN-Bus) fließenden Datenstrom die Daten extrahieren, die für die über den betreffenden CAN-Controller ans CAN angeschlossene Einrichtung bestimmt sind, und
– die Daten, die von der über den betreffenden CAN-Controller ans CAN angeschlossenen Einrichtung auszugeben sind, auf den CAN-Bus ausgeben, und ist darüber hinaus zusätzlich in der Lage,
– auf über den CAN-Bus erhaltene Daten zu reagieren und/oder unter Berücksichtigung derselben weiterzuarbeiten, und/oder
– auf eigene Veranlassung hin bestimmte Aktionen durchzuführen oder anzustoßen.

Dabei können auch Daten zwischen den mehreren CANs (zwischen den mehreren CAN-Bussen), an die der CAN-Controller gleichzeitig anschließbar ist, ausgetauscht werden. Durch Vorsehen geeigneter Strukturen (beispielsweise FIFOs etc.) können auch Daten zwischen CANs ausgetauscht werden, die mit unterschiedlichen Bit-Timings und/oder Baudraten arbeiten.
Der vorliegend betrachtete CAN-Controller ist somit – im Gegensatz zu herkömmlichen CAN-Controllern – in der Lage, daß er die in herkömmlichen Systemen vom CAN-Controller und der diesen steuernden Steuereinrichtung erledigten Aufgaben nun mehr alleine, d.h. ohne Mitwirkung oder Veranlassung durch einer den CAN-Controller steuernde Steuereinrichtung, erfüllen kann.
Der vorliegend betrachtete CAN-Controller wird hierzu insbesondere dadurch befähigt, daß er, genauer gesagt insbesondere die Steuereinheit 2 desselben, statisch und/oder dynamisch so intialisierbar und/oder konfigurierbar ist, daß er sich selbst und die über ihn ans Netzwerk angeschlossene Einrichtung steuern kann.
Die Initialisierung und Konfigurierung des CAN-Controllers erfolgt im betrachteten Beispiel dadurch, daß in ihm enthaltene Register (insbesondere die sogenannten Funktionssteuerregister) und/oder sonstige Speicher entsprechend der vom CAN-Controller zu erfüllenden Funktion beschrieben werden.
Das zur Initialisierung oder Konfigurierung des CAN-Controllers durchzuführende Beschreiben der Register oder sonstigen Speicher erfolgt beim betrachteten CAN-Controller unter Verwendung von Daten, welche der CAN-Controller auf eigene Veranlassung selbständig aus einer Speichereinrichtung auslesen kann.
Die Speichereinrichtung ist im betrachteten Beispiel ein in den Figuren nicht gezeigtes EEPROM, mit welchem der CAN-Controller über die serielle Schnittstelle 5 verbunden ist. Es sei bereits an dieser Stelle darauf hingewiesen, daß es sich bei der Speichereinrichtung auch um eine beliebige andere nichtflüchtige oder flüchtige Speichereinrichtung wie beispielsweise ein ROM, einen Flash-Speicher, ein RAM etc. handeln kann, und daß die Speichereinrichtung auch eine innerhalb des CAN-Controllers vorgesehene interne Speichereinrichtung sein kann.
Wenn der CAN-Controller nach dem Einschalten oder im Ansprechen auf sonstige Ereignisse initialisiert oder (um-) konfiguriert werden muß, beginnt er, aus dem EEPROM seriell Daten auszulesen.
Die im EEPROM gespeicherten Daten werden dabei in vorbestimmten (Daten-)Einheiten ausgelesen und weiterverarbeitet. Diese Dateneinheiten umfassen im betrachteten Beispiel jeweils einen Adreß-Teil, einen Daten-Teil und einen optionalen Test-Teil.
Der Adreß-Teil umfaßt im betrachteten Beispiel zwei Bytes und enthält

– Vorschriften für die Verwendung der im Daten-Teil enthaltenen Daten (diese Vorschrift besteht im betrachteten Beispiel aus der Adresse des Registers oder Speichers, in welches bzw. in welchen die im Daten-Teil enthaltenen Daten geschrieben werden sollen; zusätzlich oder alternativ könnte die Vorschrift aber beispielsweise auch einfache Verarbeitungen der im Daten-Teil enthaltenen Daten befehlen),
– eine Angabe darüber, aus wie vielen Bytes der Daten-Teil besteht, und
– eine Angabe darüber, ob neben dem Adreß-Teil und dem Daten-Teil zusätzlich ein Test-Teil vorhanden ist, anhand dessen überprüft werden kann, ob die aus dem EEPROM ausgelesenen Daten fehlerfrei ausgelesen und übertragen wurden.

Der Daten-Teil umfaßt im betrachteten Beispiel zwischen 1 und 4 Bytes; die darin gespeicherten Daten werden in das Register oder in den Speicher geschrieben, das bzw. der durch die im Adreß-Teil angegebene Adresse spezifiziert wird.
Der CAN-Controller liest aus dem EEPROM eine Dateneinheit nach der anderen aus, überprüft diese gegebenenfalls unter Verwendung des Test-Teils desselben auf Richtigkeit, und schreibt die im Daten-Teil enthaltenen Daten in die internen Register oder Speicher des CAN-Controllers, die im Adreß-Teil spezifiziert sind.
Die Decodierung der Adresse und das Einschreiben von Daten an die durch die Adresse spezifizierte Stelle innerhalb des CAN-Controllers erfordert nur eine äußerst einfache Logik, die sich mit minimalem Aufwand problemlos in den CAN-Controller integrieren läßt.
Bei dieser Art von Initialisierung bzw. Konfigurierung ist es im Gegensatz zu bisher nicht mehr erforderlich, die Initialisierung oder Konfigurierung des CAN-Controllers durch eine den CAN-Controller steuernde Steuereinrichtung wie etwa einen Mikroprozessors oder Mikrocontroller vorzunehmen oder anzustoßen; der CAN-Controller kann sich auf eigene Veranlassung selbständig alleine initialisieren oder konfigurieren.
Falls eine Veränderung der Daten, mit denen die Register oder Speicher des CAN-Controllers zu beschreiben sind, und/oder der Reihenfolge, in der dies geschehen soll, erforderlich ist, muß lediglich das EEPROM umprogrammiert oder ausgetauscht werden; am CAN-Controller sind keine Eingriffe erforderlich.
Eine wie beschrieben erfolgende Initialisierung oder Konfigurierung des CAN-Controllers kann auch komplexere Vorgänge umfassen. Insbesondere in solchen Fällen erweist es sich als vorteilhaft, wenn der CAN-Controller über ein die Initialisierung oder Konfigurierung steuerndes Initialisierungs-Steuerregister verfügt, welches während der Initialisierung oder Konfigurierung des CAN-Controllers wie die anderen bei der Initialisierung oder Konfigurierung des CAN-Controllers beschreibbaren Register und Speicher beschreibbar ist.
Der vorliegend betrachtete CAN-Controller enthält ein solches Initialisierungs-Steuerregister.
Die in diesem Initialisierungs-Steuerregister gespeicherten Daten enthalten

– die Adresse, unter Verwendung welcher die die Konfigurationsdaten enthaltende Speichereinrichtung (im betrachteten Beispiel das EEPROM) bei Bedarf zu adressieren ist,
– ein Instruktionswort, welches der die Konfigurationsdaten enthaltenden Speichereinrichtung bei Bedarf zu übermitteln ist, und
– verschiedene Steuerinformationen insbesondere zum Ablauf der Initialisierung oder Konfigurierung, wobei die Steuerinformationen im betrachteten Beispiel vorgeben,
– ob die Initialisierung zu beenden ist,
– ob die Initialisierung durch einen erneuten Zugriff auf die Speichereinrichtung (unter Verwendung der im Initialisierungs-Steuerregister gespeicherten Adresse und des im Initialisierungs-Steuerregister gespeicherten Instruktionswortes) fortzusetzen ist, und
– ob und gegebenenfalls wie die serielle Schnittstelle 5 zu konfigurieren oder umzukonfigurieren ist.

Es dürfte einleuchten, daß das Initialisierungs-Steuerregister mannigfaltige weitere Informationen und Anweisungen für die Initialisierung oder die Konfigurierung enthalten kann. Da das Initialisierungs-Steuerregister durch die in der Speichereinrichtung gespeicherten Daten beschreibbar ist, kann der Ablauf der Initialisierung oder Konfigurierung ohne Ausführung eines Programmes, also denkbar einfach, aber dennoch vollkommen flexibel festgelegt werden.
Durch die beschriebene Art und Weise der Konfigurierung oder Initialisierung des CAN-Controllers ist es sogar möglich, daß ohne spezielle Anpassung des Aufbaus und/oder des Betriebs des CAN-Controllers – beliebig große und oder beliebig organisierte Speichereinrichtungen zum Speichern der zum Initialisieren oder Konfigurieren benötigten Daten zum Einsatz kommen können; gegebenenfalls zu beachtende Besonderheiten der verwendeten Speichereinrichtung können durch zu Beginn der Initialisierung oder Konfigurierung und/oder durch vor dem Auftreten der Besonderheiten erfolgende Einträge in das Initialisierungs-Steuerregister berücksichtigt werden.
Unabhängig davon kann auch vorgesehen werden, den Ablauf der Initialisierung oder Konfigurierung von bestimmten Ereignissen oder Zuständen innerhalb oder außerhalb des CAN-Controllers (beispielsweise vom Pegel eines dem CAN-Controllers zugeführten Signals) abhängig zu machen.
Der vorliegend betrachtete CAN-Controller kann auch unter Verwendung von ihm über das CAN übermittelten CAN-Nachrichten initialisiert oder konfiguriert werden. Diese Struktur gestattet es, zunächst unter Verwendung von im EEPROM oder einer sonstigen Speichereinrichtung gespeicherten Konfigurationsdaten eine Grund-Initialisierung vorzunehmen, und anschließend unter Verwendung von über das CAN erhaltene CAN-Nachrichten eine weiterführende Initialisierung oder Konfigurierung vorzunehmen. Die Grund-Initialisierung kann dann eine sehr einfache, universelle (nicht applikationsspezifische) Initialisierung oder Konfigurierung sein; sie kann sich beispielsweise auf den Bitstreamprozessor und ein Nachrichtenobjekt beschränken; die applikationsspezifische Initiali sierung kann ja in der weiterführenden Initialisierung (über CAN-Nachrichten) erfolgen. Dadurch können an das CAN angeschlossene Einrichtungen von einer zentralen Stelle aus, und damit äußerst schnell und einfach wunschgemäß (um-)konfiguriert werden.
Beim betrachteten CAN-Controller sind Sicherheitsvorkehrungen implementiert, durch welche verhinderbar ist, daß der CAN-Controller versehentlich oder mißbräuchlich über CAN-Nachrichten initialisiert oder konfiguriert wird. Diese Sicherheitsvorkehrungen bestehen im betrachteten Beispiel im Vorsehen eines CAN-Initialisierungs-Steuerregisters, dessen Inhalt angibt, ob und gegebenenfalls unter welchen Voraussetzungen eine Initialisierung oder Konfigurierung über das CAN erfolgen kann bzw. darf.
Das CAN-Initialisierungs-Steuerregister enthält im betrachteten Beispiel

– die Nummer des Nachrichtenobjekts, das ein Initialisieren oder Konfigurieren des CAN-Controllers bewirken können soll,
– eine Information darüber, ob ein Initialisieren oder Konfigurieren des CAN-Controllers über CAN-Nachrichten zugelassen ist, und
– ein Codewort, das die CAN-Nachricht, durch die der CAN-Controller initialisierbar oder konfigurierbar ist, enthalten muß, damit der CAN-Controller im Ansprechen auf die betreffende CAN-Nachricht tatsächlich initialisiert oder konfiguriert wird.

Ein Initialisieren oder Konfigurieren des CAN-Controllers über eine CAN-Nachricht erfolgt nur, wenn dies prinzipiell zulässig ist, und wenn eine CAN-Nachricht empfangen wird, welche die im CAN-Initialisierungs-Steuerregister definierten Bedingungen erfüllt. Dabei kann auch das CAN-Initialisierungs-Steuerregister selbst initialisiert oder (um-)konfiguriert werden.
Sowohl bei der Initialisierung oder Konfigurierung des CAN-Controllers unter Verwendung von aus einer Speichereinrichtung geholten Daten, als auch bei der Initialisierung oder Konfigurierung des CAN-Controllers über das CAN (darüber versandte CAN-Nachrichten) erschöpft sich die Initialisierung oder Konfigurierung des CAN-Controllers im Beschreiben von internen Registern oder sonstigen Speichern des CAN-Controllers.
Eine derartige Initialisierung oder Konfigurierung läßt sich mit minimalem Aufwand durchführen. Sie kann ohne Verwendung einer den CAN-Controller steuernden Steuereinrichtung erfolgen; zur Durchführung genügt im allgemeinen eine vergleichsweise einfach aufgebaute Logik, beispielsweise eine sogenannte state machine.
Die herkömmliche Initialisierung oder Konfigurierung von CAN-Controllern, das heißt die Initialisierung oder Konfigurierung unter Steuerung durch eine den CAN-Controller steuernde Steuereinrichtung, ist – insbesondere bedingt durch die Notwendigkeit, eine entsprechende Steuereinrichtung wie etwa einen Mikroprozessor oder Mikrocontroller vorsehen und programmieren zu müssen – erheblich aufwendiger.
Nach erfolgter Initialisierung oder Konfigurierung arbeitet der CAN Controller, genauer gesagt insbesondere die diesen und gegebenenfalls die über diesen mit dem CAN verbundene Einrichtung steuernden Bestandteile, also vor allem die Steuereinheit 2 desselben steuernden Bestandteile desselben abhängig vom Inhalt der bei der Initialisierung oder Konfigurierung beschriebenen Register oder sonstigen Speicher. Auch hierfür ist "nur" eine einfache Logik, beispielsweise eine oder mehrere state machines erforderlich.
Vorzugsweise sind sämtliche Register und Speicher des CAN-Controllers, welche einen Einfluß auf die Arbeitsweise des CAN-Controllers haben oder haben können, nach wenigstens einer der vorstehend beschriebenen Möglichkeiten initialisierbar oder konfigurierbar.
Der betrachtete CAN-Controller ist darüber hinaus aber auch auf die herkömmliche Art und Weise, d. h. über eine den CAN-Controller steuernde Steuereinrichtung initialisierbar oder konfigurierbar. Genauer gesagt ist er wahlweise auf die vorstehend beschriebene Art und Weise oder unter Steuerung durch eine Steuereinrichtung wie einen Mikroprozessor oder einen Mikrocontroller initialisierbar oder konfigurierbar.
Der betrachtete CAN-Controller weist hierzu zwei Steueranschlüsse C1 und C2 auf, über welche einstellbar ist, wie er initialisiert oder konfiguriert werden soll. Dabei ist

– über den Steueranschluß C1 einstellbar, ob die Initialisierung oder Konfigurierung über die serielle Schnittstelle 5 oder die parallele Schnittstelle 6 erfolgt, und
– über den Steueranschluß C2 einstellbar, ob der CAN-Controller im Fall, daß die Initialisierung oder Konfigurierung über die serielle Schnittstelle 5 erfolgt, mit einer den CAN-Controller steuernden Steuereinrichtung oder mit einer die Konfigurationsdaten speichernden Speichereinrichtung verbunden ist.

Es erweist sich als vorteilhaft, wenn bei allen Arten der Initialisierung oder Konfigurierung, d.h. sowohl bei der Initialisierung oder Konfigurierung unter Verwendung von aus einer Speichereinrichtung ausgelesenen Daten, als auch bei der Initialisierung oder Konfigurierung über das CAN, als auch bei der Initialisierung oder Konfigurierung unter Steuerung durch eine den CAN-Controller steuernde Steuer einrichtung wie bei der erstgenannten Möglichkeit verfahren wird, also dem CAN-Controller Dateneinheiten zugeführt werden, von welchen jeweils ein bestimmter Teil in ein durch einen anderen Teil der betreffenden Dateneinheiten spezifiziertes Register oder einen sonstigen Speicher des CAN-Controllers geschrieben werden.
Falls der CAN-Controller über eine diesen steuernde Steuereinrichtung initialisiert oder konfiguriert wird, und über die serielle Schnittstelle 5 mit dieser Steuereinrichtung verbunden ist, können die Anschlüsse der parallelen Schnittstelle 6 als I/O-Ports konfiguriert und benutzt werden.
Diese I/O-Ports lassen sich dazu verwenden, den CAN-Controller mit bestimmten Komponenten des den CAN-Controller enthaltenden Systems zu verbinden.
Die I/O-Ports ermöglichen es aber auch, den CAN-Controller als I/O-Erweiterung des diesen enthaltenden Systems zu verwenden; der CAN-Controller kann dadurch für das ihn enthaltende System Daten oder Signale ausgeben oder empfangen.
Die I/O-Ports können aber auch für Sonderfunktionen benutzt werden, beispielsweise zur Veranlassung des Sendens einer bestimmten Nachricht, oder um interne Größen (z. B. das Bit-timing) nach außen zu führen.
Unabhängig davon, wofür die I/O-Ports verwendet werden, kann vorgesehen werden, über CAN-Nachrichten zu steuern, wann über die I/O-Ports Daten oder Signale ausgegeben oder empfangen werden sollen.
Zusätzlich oder alternativ kann vorgesehen werden, den Pegel von über die I/O-Ports ausgegebenen Signalen durch entsprechende CAN-Nachrichten einstellen zu lassen.
Eine weitere Besonderheit des betrachteten CAN-Controllers besteht darin, daß dieser einen Oszillator enthält und mit dessen Hilfe seinen eigenen Takt erzeugen kann.
Der CAN-Controller verfügt darüber hinaus über einen Taktausgabeanschluß (Clockout-Pin), über welchen der im CAN-Controller intern erzeugte Takt den mit dem CAN-Controller kooperierenden Einrichtungen, insbesondere der über den CAN-Controller ans CAN angeschlossenen Einrichtung, als Systemtakt zur Verfügung gestellt werden kann; der CAN-Controller enthält vorzugsweise eine Teilerschaltung, unter Verwendung welcher der vom internen Oszillator des CAN-Controllers erzeugte Takt wunschgemäß geteilt werden kann.
Der Clockout-Pin ist vorzugsweise konfigurierbar, so daß er für den Fall, daß der vom CAN-Controller erzeugte Takt nicht als Systemtakt verwendet wird, anderweitig verwendet werden kann. Im betrachteten Beispiel ist der Clockout-Pin, genauer gesagt der diesem vorgeschaltete Schaltungsteil so konfigurierbar, daß der Clockout-Pin auch als Anschluß zur Ausgabe eines Interrupt Request Signals verwendet werden kann.
Der betrachtete CAN-Controller verfügt demzufolge auch über eine Einrichtung zur Erzeugung von Interrupt Request Signalen. Die von dieser Einrichtung erzeugten Interrupt Request Signale können über den Clockout-Pin ausgegeben werden, wenn und so lange dieser nicht zur Ausgabe eines im CAN-Controller erzeugten Taktes benötigt wird.
Der CAN-Controller kann aber auch von außerhalb (beispielsweise von einer den CAN-Controller steuernden Steuereinrichtung) mit einem Takt versorgt werden. Im betrachteten Beispiel kann der CAN-Controller den benötigten Takt wahlweise wie vorstehend beschriebenen selbst erzeugen oder einen ihm von außen zugeführten Takt verwenden.
Eine weitere Besonderheit des betrachteten CAN-Controllers besteht darin, daß er sich selbst in eine Power-Down-Betriebsart, in welcher der Oszillator ausgeschaltet ist, und in eine Sleep-Betriebsart versetzen kann, in welcher der Oszillator eingeschaltet bleibt, aber die Taktausgabe gesperrt wird. Im Fall, daß das den CAN-Controller enthaltende System einen vom CAN-Controller erzeugten Takt als Systemtakt verwendet, kann nicht nur der CAN-Controller selbst, sondern zusätzlich oder alternativ auch das diesen enthaltende System durch den CAN-Controller in die Power-Down-Betriebsart oder die Sleep-Betriebsart versetzt werden.
Diese Funktionalität kann beim betrachteten CAN-Controller über CAN-Nachrichten geschaltet werden.
Das Aufwecken des CAN-Controllers und/oder des diesen enthaltenden Systems, das heißt das Zurückbringen des CAN-Controllers oder des Systems in die Normal-Betriebsart, erfolgt im betrachteten Beispiel ebenfalls über CAN-Nachrichten oder durch Anlegen vorbestimmter Signale an ausgewählte Eingangsanschlüsse des CAN-Controllers. Zum Aufwecken des CAN-Controllers und/oder des diesen enthaltenden Systems ist eine Aufweck-Steuervorrichtung vorgesehen, die mit den Eingangsanschlüssen des CAN-Controllers, über welche dieser in die Normal-Betriebsarten zurückversetzbar ist, verbunden ist, und abhängig von den über diese Eingangsanschlüsse eingegebenen Signalen den Oszillator und die Ausgabe der von diesem erzeugten Taktsignale ein- oder ausschaltet.
Die Betriebsart, in welcher sich der CAN-Controller und/oder das diesen enthaltende System befinden soll, wird in Abhängigkeit von einem Takt-Steuerregister festgelegt, dessen Inhalt durch die entsprechenden CAN-Nachrichten veränderbar ist.
Das Vorhandensein eines eigenen Oszillators im CAN-Controller und die Möglichkeit, den CAN-Controller und/oder das diesen enthaltende System über CAN-Nachrichten in die Power-Down-Betriebsart oder die Sleep-Betriebsart zu versetzen, erlauben eine vereinfachte Systempartitionierung: bislang mußten CAN-Nachrichten, die die Einnahme der Power-Down-Betriebsart oder der Sleep-Betriebsart befahlen, softwaregesteuert in einer den CAN-Controller steuernden Steuereinrichtung analysiert und ausgeführt werden; im betrachteten Beispiel sind das Erkennen und das Reagieren auf entsprechende CAN-Nachrichten hardwaremäßig durch eine entsprechende Logik im CAN-Controller realisiert. Entsprechendes gilt für das Aufwecken des CAN-Controllers und/oder des diesen enthaltenden Systems.
Beim betrachteten CAN-Controller sind Sicherheitsvorkehrungen implementiert, durch welche verhinderbar ist, daß der CAN-Controller und/oder das diesen enthaltende System versehentlich oder mißbräuchlich in die Power-Down-Betriebsart oder die Sleep-Betriebsart versetzt wird. Diese Sicherheitsvorkehrungen bestehen im betrachteten Beispiel im Vorsehen eines Power-Down-Steuerregisters, dessen Inhalt angibt, ob und gegebenenfalls unter welchen Voraussetzungen das Versetzen des CAN-Controllers und/oder des diesen enthaltenden Systems in die Power-Down-Betriebsart oder die Sleep-Betriebsart über CAN-Nachrichten erfolgen kann bzw. darf.
Das Power-Down Steuerregister enthält im betrachteten Beispiel

– die Nummer des Nachrichtenobjekts, das ein Versetzen des CAN-Controllers und/oder des diesen enthaltenden Systems in die Power-Down-Betriebsart oder die Sleep-Betriebsart bewirken können soll,
– eine Information darüber, ob ein Versetzen des CAN-Controllers und/oder des diesen enthaltenden Systems in die Power-Down-Betriebsart oder die Sleep-Betriebsart gestattet ist, und
– ein Codewort, das die CAN-Nachricht, durch die der CAN-Controller und/oder das diesen enthaltende System in die Power-Down-Betriebsart oder die Sleep-Betriebsart versetzbar ist, enthalten muß, damit der CAN-Controller und/oder das diesen enthaltende System tatsächlich in die Power-Down-Betriebsart oder die Sleep-Betriebsart versetzt wird.

Ein Versetzen des CAN-Controllers und/oder des diesen enthaltenden Systems in die Power-Down-Betriebsart oder die Sleep-Betriebsart über eine CAN-Nachricht erfolgt nur, wenn dies prinzipiell zulässig ist, und wenn eine CAN-Nachricht empfangen wird, welche die im Power-Down-Steuerregister definierten Bedingungen erfüllt.
Eine weitere Besonderheit des vorliegend betrachteten CAN-Controllers besteht darin, daß die Flankensteilheit der Ausgangssignale des CAN-Controllers einstellbar ist; hierfür existiert ein spezielles Steuerregister, daß auf eine der vorstehend erwähnten Arten initialisierbar oder konfigurierbar ist.
Eine weitere Besonderheit des vorliegend betrachteten CAN-Controllers besteht darin, daß dieser ein internes RAM zum Zwischenspeichern der empfangenen und/oder auszugebenden CAN-Nachrichten aufweist. Herkömmliche CAN-Controller benutzen hierfür Flip-Flops. Die Veränderung eines RAM anstelle von Flip-Flops ist vorteilhaft, weil sich ein RAM erheblich kleiner realisieren läßt als Flip-Flops.
Insbesondere, aber nicht ausschließlich, wenn ein RAM anstelle eines Flip-Flops verwendet wird, erweist es sich als vorteilhaft, wenn das Auslesen des internen Speichers des CAN-Controllers durch eine externe Einheit durch zwei kurze aufeinanderfolgende Zugriffe auf den CAN-Controller erfolgt, wobei der erste Zugriff das Lesen anstößt, und wobei im zweiten Zugriff die durch den ersten Zugriff angeforderten und zwischenzeitlich zur Abholung bereitgestellten Daten abgeholt werden. Die Bereitstellung der durch den ersten Zugriff angeforderten und daraufhin aus dem RAM ausgelesenen Daten erfolgt in einem extra vorzusehenden schnellen Pufferspeicher (einem Zwischenregister). Die zwei zum Auslesen des RAM durchzuführenden Speicherzugriffe können, da nicht auf das relativ langsame Auslesen von Daten aus dem RAM gewartet werden muß, sehr schnell durchgeführt werden, wodurch die die Daten anfordernde Einheit durch den zweimaligen Zugriff auf den CAN-Controller zum Auslesen von Daten nicht zusätzlich belastet wird.
Durch den Umstand, daß zum Auslesen von Daten zwar jeweils mehrere, aber immer nur sehr kurze Zugriffe auf den CAN-Controller erfolgen (müssen), läßt sich auch die sogenannte Interruptlatenzzeit erheblich verringern.
Zwischen den zwei Zugriffen zum Auslesen des RAM kann der CAN-Controller normal weiterarbeiten; er muß nicht darauf warten, daß die bereitgestellten Daten abgeholt werden. Dabei können auch andere Anforderungen von außerhalb des CAN-Controllers vorgesehenen Einheiten abgearbeitet werden (sofern dabei nicht ebenfalls das CAN-RAM ausgelesen werden soll).
Beim betrachteten CAN-Controller ist es alternativ möglich, das Auslesen von Daten aus dem RAM wie üblich durch nur einen einzigen und dementsprechend lang andauernden Zugriff auf den CAN-Controller durchzuführen.
Im betrachteten CAN-Controller ist einstellbar, ob das Auslesen von Daten aus dem CAN-RAM durch einen einzigen (langen) Zugriff oder durch zwei mit Abstand aufeinanderfolgende (kurze) Zugriffe erfolgt.
Das Auslesen von Daten aus dem CAN-RAM weist abhängig von der gewählten Art des Auslesens verschiedene Besonderheiten auf. So darf sich der Inhalt des Zwischenregisters, in welchem die Daten in beiden Fällen zur Abholung bereitgestellt werden, im einen Fall (bei einem einzigen Zugriff) während des Zugriffs ändern, wohingegen er sich im anderen Fall (bei mehreren Zugriffen) während der Zugriffe nicht ändern darf. Unabhängig davon erfolgt auch die Abarbeitung von Interrupt Requests abhängig von der Art des Auslesens des CAN-RAM: wenn das Auslesen des CAN-RAM über einen doppelten Zugriff auf den CAN-Controller erfolgt, muß, wenn zwischen den beiden Zugriffen auf einen Interrupt Request reagiert werden muß, nach der Abarbeitung der Interrupt Service Routine dafür gesorgt werden, daß im Zwischenregister die vor der Ausführung der Interrupt Service Routine angeforderten Daten stehen.
Dies kann beispielsweise dadurch geschehen, daß die dem CAN-RAM beim ersten Zugriff zugeführte Adresse in einem speziellen Adreßregister oder einer sonstigen Speichereinrichtung gespeichert wird, und daß die im CAN-RAM unter dieser Adresse gespeicherten Daten automatisch erneut ausgelesen und zur Abholung im Zwischenregister bereitgestellt werden, wenn vor dem zweiten Zugriff auf das CAN-RAM ein anderer Zugriff, beispielsweise ein Zugriff durch eine Interrupt Service Routine auf das CAN-RAM erfolgt ist.
Entsprechendes gilt selbstverständlich auch dann, wenn der zwischen den ersten unter dem zugeordneten zweiten Zugriff auf das CAN-RAM erfolgende weitere Zugriff nicht von einer Interrupt Service Routine, sondern von anderswo stammt.
Der vorliegend betrachtete CAN-Controller weist darüber hinaus die Besonderheit auf, daß er in der Lage ist, Informationen über seinen momentanen Zustand auszugeben, und zwar vorzugsweise unabhängig voneinander für beide CAN-Knoten. Die genannten Informationen sind beispielsweise Informationen über die momentane Stelle in einer CAN-Nachricht, Informationen über den abgetasteten Wert, und/oder Informationen über den Abtastzeitpunkt. Im betrachteten Beispiel enthalten die Informationen die CAN-Bits in "destuffter" Form, also die realen Nettodaten.
Dies ermöglicht es, den CAN-Controller mit Hilfe externer Schaltungen zu überwachen oder zu debuggen (nach darin enthaltenen Fehlern zu suchen). Dadurch kann beispielsweise nachvollzogen werden, wie eine CAN-Nachricht über den CAN-Bus geschickt wird, und wo Fehler auftreten.
Ein wie beschrieben aufgebauter CAN-Controller kann ohne Steuerung durch eine Steuereinrichtung wie einen Mikroprozessor oder Mikrocontroller betrieben werden. Der CAN-Controller kann sowohl sich selbst als auch die über ihn ans CAN angeschlossene Einrichtung steuern. Dies gilt auch dann, wenn die vom CAN-Controller gesteuerte Einrichtung eine eigene Steuereinrichtung enthält. Durch die vorstehend beschriebenen Besonderheiten des vorliegend betrachteten CAN-Controllers ist dieser in der Lage, als Master des ihn enthaltenden Systems tätig zu werden, wodurch er beliebige andere Systemkomponenten, insbesondere auch üblicherweise selbst als Master arbeitende Systemkomponenten wie Mikroprozessoren und Mikrocontroller steuern kann.
Der beschriebene CAN-Controller ist herkömmlichen CAN-Controllern in vielfacher Hinsicht überlegen: er ermöglicht eine vereinfachte Systemstruktur bei erweiterter Funktionalität.

1: CAN-data-link-control-Einheit
2: Steuereinheit
3: erster CAN-Knoten
4: zweiter CAN-Knoten
5: serielle Schnittstelle
6: parallele Schnittstelle
C1, C2: Steueranschlüsse
CLOCKOUT: Taktausgabeanschluß

Claims

Netzwerk-Controller, insbesondere CAN-Controller, zum Anschluß einer an ein Netzwerk anzuschließenden Einrichtung an das Netzwerk, dadurch gekennzeichnet, daß der Netzwerk-Controller statisch und/oder dynamisch so intialisierbar und/oder konfigurierbar ist, daß er sich selbst und die über ihn ans Netzwerk angeschlossene Einrichtung steuern kann, wobei der Netzwerk-Controller in der Lage ist, auf eigene Veranlassung hin bestimmte Aktionen durchzuführen oder anzustoßen.
Netzwerk-Controller nach Anspruch 1, dadurch gekennzeichnet, daß die Initialisierung oder Konfigurierung des Netzwerk-Controllers durch ein Beschreiben von in diesem enthaltenen Speichern erfolgt.
Netzwerk-Controller nach Anspruch 2, dadurch gekennzeichnet, daß die bei der Initialisierung oder Konfigurierung des Netzwerk-Controllers beschreibbaren Speicher des Netzwerk-Controllers Register des Netzwerk-Controllers sind.
Netzwerk-Controller nach Anspruch 2 oder 3, dadurch gekennzeichnet, daß die bei der Initialisierung oder Konfigurierung des Netzwerk-Controllers beschreibbaren Speicher des Netzwerk-Controllers Funktionssteuerregister des Netzwerk-Controllers sind.
Netzwerk-Controller nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, daß der Netzwerk-Controller abhängig vom Inhalt der beim Initialisieren oder Konfigurieren beschreibbaren Speicher arbeitet.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß diejenigen Teile des Netzwerk-Controllers, über welche dieser und die über ihn ans Netzwerk angeschlossene Einrichtung gesteuert werden, durch eine oder mehrere state machines gebildet werden.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller dazu ausgelegt ist, sich selbst zu initialisieren oder zu konfigurieren.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller dazu ausgelegt ist, sich auf eigene Veranlassung hin zu initialisieren oder zu konfigurieren.
Netzwerk-Controller nach Anspruch 7 oder 8, dadurch gekennzeichnet, daß die Initialisierung oder Konfigurierung des Netzwerk-Controllers unter Verwendung von in einer Speichereinrichtung gespeicherten Daten erfolgt, welche der Netzwerk-Controller bei Bedarf auslesen kann.
Netzwerk-Controller nach Anspruch 9, dadurch gekennzeichnet, daß die Speichereinrichtung eine nichtflüchtige Speichereinrichtung ist.
Netzwerk-Controller nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß die Speichereinrichtung eine zur seriellen Ausgabe von Daten ausgelegte Speichereinrichtung ist.
Netzwerk-Controller nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, daß von den aus der Speichereinrichtung ausgelesenen Dateneinheiten jeweils ein Teil in einen durch einen anderen Teil der betreffenden Dateneinheit spezifizierten Speicher des Netzwerk-Controllers geschrieben wird.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Initialisierung oder Konfigurierung des Netzwerk-Controllers in Abhängigkeit von einem Initialisierungs-Steuerregister erfolgt.
Netzwerk-Controller nach Anspruch 13, dadurch gekennzeichnet, daß durch das Initialisierungs-Steuerregister festgelegt wird, wann die Initialisierung oder Konfigurierung zu beenden ist.
Netzwerk-Controller nach Anspruch 13 oder 14, dadurch gekennzeichnet, daß durch das Initialisierungs-Steuerregister festgelegt wird, ob und gegebenenfalls wie die Initialisierung fortzusetzen ist.
Netzwerk-Controller nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, daß das Initialisierungs-Steuerregister während der Initialisierung einmal oder mehrmals unter Verwendung von aus der Speichereinrichtung ausgelesenen Daten beschreibbar ist.
Netzwerk-Controller nach einem der Ansprüche 7 bis 16, dadurch gekennzeichnet, daß der Netzwerk-Controller alternativ oder zusätzlich unter Steuerung durch eine dem Netzwerk-Controller übergeordnete Steuereinrichtung initialisierbar oder konfigurierbar ist.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß durch Anlegen entsprechender Signale (C1, C2) an den Netzwerk-Controller einstellbar ist, ob der Netzwerk-Controller sich selbständig unter Verwendung von in einer Speichereinrichtung gespeicherten Daten initialisieren oder konfigurieren soll, oder ob er unter Steuerung durch eine übergeordnete Steuereinrichtung initialisierbar oder konfigurierbar sein soll.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Initialisierung oder Konfigurierung des Netzwerk-Controllers wahlweise über eine serielle (5) oder eine parallele (6) Schnittstelle des Netzwerk-Controllers erfolgt.
Netzwerk-Controller nach Anspruch 19, dadurch gekennzeichnet, daß im Fall, daß der Netzwerk-Controller über die serielle Schnittstelle (5) mit der die Konfigurations-Daten speichernden Speichereinrichtung oder der übergeordneten Steuereinrichtung verbunden ist, die parallele Schnittstelle (6) als I/O-Port(s) konfigurierbar ist.
Netzwerk-Controller nach Anspruch 20, dadurch gekennzeichnet, daß durch Nachrichten, die dem Netzwerk-Controller über das Netzwerk zugeführt werden, einstellbar ist, wann und/oder welche Signale oder Daten über die I/O-Ports eingelesen und/oder ausgegeben werden, und/oder wie auf erhaltene Signale oder Daten zu reagieren ist.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller unter Verwendung von dem Netzwerk-Controller über das Netzwerk zugeführten Nachrichten initialisierbar oder konfigurierbar ist.
Netzwerk-Controller nach Anspruch 22, dadurch gekennzeichnet, daß die Initialisierung oder Konfigurierung des Netzwerk-Controllers unter Verwendung von dem Netzwerk-Controller über das Netzwerk zugeführten Nachrichten nur durchgeführt wird, wenn dies durch einen entsprechenden Eintrag in einem Netzwerk-Initialisierungs-Steuerregister freigegeben ist.
Netzwerk-Controller nach Anspruch 22 oder 23, dadurch gekennzeichnet, daß die Initialisierung oder Konfigurierung des Netzwerk-Controllers unter Verwendung von dem Netzwerk-Controller über das Netzwerk zugeführten Nachrichten nur durchgeführt wird, wenn die Nachricht, durch welche eine Initialisierung oder Konfigurierung durchgeführt werden soll, in einem Netzwerk-Initialisierungs-Steuerregister definierte Bedingungen erfüllt.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller einen Oszillator zur Erzeugung eines vom Netzwerk-Controller benötigten Taktsignals enthält.
Netzwerk-Controller nach Anspruch 25, dadurch gekennzeichnet, daß der Netzwerk-Controller das intern erzeugte Taktsignal über einen Taktausgabeanschluß (CLOCKOUT) ausgibt.
Netzwerk-Controller nach Anspruch 26, dadurch gekennzeichnet, daß der Taktausgabeanschluß (CLOCKOUT) so konfigurierbar ist, daß er wahlweise zur Ausgabe des im Netzwerk-Controller er zeugten Taktsignals oder zur Ein- und/oder Ausgabe anderer Signale und/oder Daten verwendbar ist.
Netzwerk-Controller nach einem der Ansprüche 25 bis 27, dadurch gekennzeichnet, daß der Netzwerk-Controller anstelle des intern erzeugten Taktsignals ein ihm von außen zugeführtes Taktsignal als Taktsignal verwenden kann.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller sich selbst und/oder das ihn enthaltende System in eine Power-Down-Betriebsart oder in eine Sleep-Betriebsart versetzen kann.
Netzwerk-Controller nach Anspruch 29, dadurch gekennzeichnet, daß die Power-Down-Betriebsart durch ein Abschalten des internen Oszillators des Netzwerk-Controllers eingeleitet wird.
Netzwerk-Controller nach Anspruch 29 oder 30, dadurch gekennzeichnet, daß die Sleep-Betriebsart durch ein Sperren der Ausgabe der vom internen Oszillator des Netzwerk-Controllers erzeugten Taktsignale eingeleitet wird.
Netzwerk-Controller nach einem der Ansprüche 29 bis 31, dadurch gekennzeichnet, daß das Einleiten und/oder das Verlassen der Power-Down-Betriebsart und/oder der Sleep-Betriebsart durch an den Netzwerk-Controller angelegte Signale und/oder durch dem Netzwerk-Controller über das Netzwerk zugeführte Nachrichten veranlaßbar sind.
Netzwerk-Controller nach einem der Ansprüche 29 bis 32, dadurch gekennzeichnet, daß ein Betriebsart-Wechsel auf Veranlassung durch eine dem Netzwerk-Controller über das Netzwerk zugeführte Nachricht nur erfolgt, wenn dies durch einen entsprechenden Eintrag in einem Power-Down-Steuerregister freigegeben ist.
Netzwerk-Controller nach einem der Ansprüche 29 bis 33, dadurch gekennzeichnet, daß ein Betriebsart-Wechsel auf Veranlassung durch eine dem Netzwerk-Controller über das Netzwerk zugeführte Nachricht nur erfolgt, wenn die Nachricht, auf deren Veranlassung ein Betriebsart-Wechsel durchgeführt werden soll, im Power-Down-Steuerregister definierte Bedingungen erfüllt.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Initialisierung und Konfigurierung des Netzwerk-Controllers die Initialisierung und Konfigurierung eines Steuerregister umfaßt, in Abhängigkeit von welchem die Flankensteilheit von aus dem Netzwerk-Controller ausgegebenen Signalen eingestellt wird.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller zur Zwischenspeicherung von über das Netzwerk empfangenen oder an das Netzwerk auszugebenden Nachrichten ein internes RAM aufweist.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das Auslesen eines zur Zwischenspeicherung von über das Netzwerk empfangenen oder an das Netzwerk auszugebenden Nachrichten vorgesehenen Speichers des Netzwerk-Controllers durch eine externe Einrichtung durch zwei aufeinanderfolgenden Zugriffe erfolgt, wobei der erste Zugriff das Lesen anstößt, und wobei im zweiten Zugriff die durch den ersten Zugriff angeforderten und zwischenzeitlich zur Abholung bereitgestellten Daten abgeholt werden.
Netzwerk-Controller nach Anspruch 37, dadurch gekennzeichnet, daß dann, wenn zwischen den zwei zusammengehörenden Zugriffen ein oder mehrere weitere Zugriffe auf den Speicher erfolgen, nach der Abarbeitung des mindestens einen weiteren Zugriffs dafür gesorgt wird, daß die durch den ersten Zugriff angeforderten Daten gegebenenfalls erneut zur Abholung bereitgestellt werden.
Netzwerk-Controller nach Anspruch 37 oder 38, dadurch gekennzeichnet, daß das Auslesen des zur Zwischenspeicherung von über das Netzwerk empfangenen oder an das Netzwerk auszugebenden Nachrichten vorgesehenen Speichers alternativ auch durch einen einzigen Zugriff erfolgen kann.
Netzwerk-Controller nach Anspruch 39, dadurch gekennzeichnet, daß am oder im Netzwerk-Controller einstellbar ist, ob das Auslesen des zur Zwischenspeicherung von über das Netzwerk empfangenen oder an das Netzwerk auszugebenden Nachrichten vorgesehenen Speichers durch einen Zugriff oder durch zwei aufeinanderfolgende Zugriffe erfolgt.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller Informationen über seinen momentanen Zustand ausgeben kann.
Netzwerk-Controller nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Netzwerk-Controller gleichzeitig an mehrere Netzwerke anschließbar ist.
Netzwerk-Controller nach Anspruch 42, dadurch gekennzeichnet, daß der Netzwerk-Controller so aufgebaut ist, daß über ihn Daten zwischen den Netzwerken, an die er angeschlossen ist, ausgetauscht werden können.