FlexRay-Kommunikationsbaustein, FlexRay-

Kommunikationscontroller und Verfahren zur Botschaftsüber- tragung zwischen einer FlexRay-Kommunikationsverbindung und einem FlexRay-Teilnehmer

Stand der Technik

Die vorliegende Erfindung betrifft einen FlexRay- Kommunikationsbaustein zur Kopplung einer FlexRay- Kommunikationsverbindung, über welche Botschaften übertragen werden, mit einem, dem FlexRay-Kommunikationsbaustein über eine Teilnehmerschnittstelle zugeordneten FlexRay- Teilnehmer.

Die Erfindung betrifft auch ein Verfahren Verfahren zur übertragung von Botschaften zwischen einem FlexRay- Teilnehmer und einer FlexRay-Kommunikationsverbindung, wobei ein FlexRay-Kommunikationsbaustein mit der Kommunikationsverbindung in Verbindung steht und der Teilnehmer über eine Teilnehmerschnittstelle an den Kommunikationsbaustein angeschlossen ist.

Schließlich betrifft die vorliegende Erfindung einen Flex- Ray-Kommunikationscontroller mit einem FlexRay-

Kommunikationsbaustein der genannten Art zur Realisierung des Verfahren der genannten Art.

Die Vernetzung von Steuergeräten, Sensorik und Aktuatorik mit Hilfe eines KommunikationsSystems und eines Bussystems, also einer Kommunikationsverbindung hat in den letzten Jahren beim Bau von modernen Kraftfahrzeugen oder auch im Maschinenbau, insbesondere im Werkzeugmaschinenbereich als auch in der Automatisierung, drastisch zugenommen. Syner- gieeffekte durch Verteilung von Funktionen auf mehrere

Steuergeräte können dabei erzielt werden. Man spricht hierbei von verteilten Systemen. Die Kommunikation zwischen verschiedenen Stationen findet mehr und mehr über ein Bussystem, also ein Kommunikationssystem statt. Der Kommunika- tionsverkehr auf dem Bussystem, Zugriffs- und Empfangsmechanismen sowie Fehlerbehandlung werden über ein Protokoll geregelt. Ein bekanntes Protokoll hierzu ist das FlexRay- Protokoll, wobei im Augenblick die FlexRay- Protokollspezifikation v2.0 oder v2.1 zugrunde liegt. Der FlexRay ist ein schnelles, deterministisches und fehlertolerantes Bussystem, insbesondere für den Einsatz in einem Kraftfahrzeug. Das FlexRay-Protokoll arbeitet nach dem Verfahren des Time Division Multiple Access (TDMA) , wobei den Komponenten also Teilnehmern bzw. den zu über-tragenden Botschaften feste Zeitschlitze zugewiesen werden, in denen sie einen exklusiven Zugriff auf die Kommunikationsverbindung haben. Die Zeitschlitze wiederholen sich dabei in einem festgelegten Zyklus, so dass der Zeitpunkt, zu dem eine Botschaft Ober den Bus übertragen wird, exakt vorausgesagt werden kann und der Buszugriff deterministisch erfolgt. Um die Bandbreite für die Botschaftsübertragung auf dem Bussystem optimal zu nutzen unterteilt FlexRay den Zyklus in einen statischen und einen dynamischen Teil. Die festen Zeitschlitze befinden sich dabei im statischen Teil am An- fang eines Buszyklusses . Im dynamischen Teil werden die

Zeitschlitze dynamisch vergeben. Darin wird nun der exklusive Buszugriff jeweils nur für eine kurze Zeit, sogenannte Minislots, ermöglicht. Nur wenn innerhalb eines Minislots ein Buszugriff erfolgt, wird der Zeitschlitz um die benö- tigte Zeit verlängert. Damit wird Bandbreite also nur verbraucht, wenn sie auch tatsächlich benötigt wird. Dabei kommuniziert FlexRay über zwei physikalisch getrennte Leitungen mit einer Datenrate von je maximal 10 MBit/s. Die beiden Kanäle entsprechen dabei der physikalischen Schicht, insbesondere des OSI (Open Systems Interconnection Reffe- rence Model) Schichtenmodells. Diese dienen nun hauptsächlich der redundanten und damit fehlertoleranten übertragung von Botschaften, können jedoch auch unterschiedliche Botschaften übertragen, wodurch sich dann die Datenrate ver- doppeln würde. FlexRay kann aber auch mit niedrigeren Datenraten betrieben werden.

Um synchrone Funktionen zu realisieren und die Bandbreite durch kleine Abstände zwischen zwei Botschaften zu optimie- ren benötigen die verteilten Komponenten im Kommunikationsnetzwerk, also die Teilnehmer, eine gemeinsame Zeitbasis, die sogenannte globale Zeit. Für die Unsynchronisation werden Synchronisationsnachrichten im statischen Teil des Zyklus übertragen, wobei mit Hilfe eines speziellen Algorith- mus entsprechend der FlexRay-Spezifikation die lokale Uhrzeit einer Komponente so korrigiert wird, dass alle lokalen Uhren zu einer globalen Uhr synchron laufen.

Ein FlexRay-Netzknoten oder FlexRay-Teilnehmer oder Host enthält einen Teilnehmerprozessor, also den Host-Prozessor, einen FlexRay-Controller oder Kommunikationscontroller sowie bei einer Busüberwachung einen Busguardian. Dabei liefert und verarbeitet der Host-Prozessor, also der Teilnehmerprozessor die Daten, die über den FlexRay- Kommunikationscontroller übertragen werden. Für die Kommu-

nikation in einem FlexRay-Netzwerk können Botschaften bzw. Botschaftsobjekte mit z.B. bis zu 254 Datenbytes konfiguriert werden.

Aufgabe ist es nun, einen FlexRay-Kommunikationsbaustein zur Verfügung zu stellen, der in optimaler Weise die Kommunikation in einem FlexRay-Netzwerk unterstützt.

Vorteile der Erfindung

Die Aufgabe wird vorteilhaft gelöst durch einen FlexRay- Kommunikationsbaustein mit sämtlichen Merkmalen des Anspruchs 1, durch einen FlexRay-Kommunikationscontroller nach Anspruch 6 sowie durch ein Verfahren nach Anspruch 7. Der erfindungsgemäße Kommunikationsbaustein ist dadurch gekennzeichnet, dass zur übertragung der Botschaften zwischen Teilnehmer und Kommunikationsverbindung eine Anordnung zur Speicherung der Botschaften vorgesehen ist, wobei die übertragung durch eine Zustandsmaschine derart gesteu- ert ist, dass vorgebbare Sequenzen betreffend Informationen zur Speicherung und übertragung der Botschaften durch die Zustandsmaschine vorgegeben oder abgerufen werden.

Vorteilhaft ist im Kommunikationsbaustein die Zustandsma- schine fest in Hardware verdrahtet und oder sind die Sequenzen fest in Hardware verdrahtet.

Alternativ kann im FlexRay-Kommunikationsbaustein die Zustandsmaschine über die Teilnehmerschnittstelle durch den Teilnehmer auch frei programmierbar sein.

Besonders vorteilhaft ist dass die Informationen den Zugriffstyp und/oder die Zugriffsart und/oder die Zugriffsadresse und/oder die Datengröße und/oder Steuerinformationen zu den Daten und/oder wenigstens eine Information zur Datenabsicherung enthalten.

Diese Vorteile gelten ebenso für die FlexRay-Vorrichtung mit einem Flexray-Kommunikationsbaustein zur Kopplung einer FlexRay-Kommunikationsverbindung über welche Botschaften übertragen werden, wobei die Vorrichtung einen Teilnehmer über eine Teilnehmerschnittstelle mit dem Kommunikationsbaustein verbindet, dadurch gekennzeichnet, dass zur übertragung der Botschaften zwischen Teilnehmer und Kommunikationsbaustein eine Anordnung zur Speicherung der Botschaf- ten vorgesehen ist, wobei die übertragung durch eine Zu- standsmaschine derart gesteuert ist, dass vorgebbare Sequenzen betreffend Informationen zur Speicherung und übertragung der Botschaften durch die Zustandsmaschine vorgegeben oder abgerufen werden.

Ebenso gelten die Vorteile für das Verfahren zur Botschaftsübertragung wobei ein Flexray-Kommunikationsbaustein mit einer FlexRay-Kommunikationsverbindung gekoppelt ist, über welche Botschaften übertragen werden, wobei die Vor- richtung einen Teilnehmer über eine Teilnehmerschnittstelle mit dem Kommunikationsbaustein verbindet, dadurch gekennzeichnet, dass zur übertragung der Botschaften zwischen Teilnehmer und Kommunikationsbaustein diese in einer Anordnung zur Speicherung der Botschaften speicherbar sind, wo- bei die übertragung durch eine Zustandsmaschine derart gesteuert ist, dass vorgebbare Sequenzen betreffend Informationen zur Speicherung und übertragung der Botschaften durch die Zustandsmaschine vorgegeben oder abgerufen werden.

Vorteilhafter weise ist ein FlexRay-Kommunikationsbaustein zur Kopplung einer Flex-Ray-Kommunikationsverbindung als physikalische Schicht gezeigt mit einem, dem Flex-Ray- Kommunikationsbaustein zugeordneten Teilnehmer in einem FlexRay-Netzwerk, über welches Botschaften übertragen wer-

den. Dabei enthält der FlexRay-Kommunikationsbaustein vorteilhafter Weise eine erste Anordnung zur Speicherung wenigstens eines Teils der übertragenen Botschaften und eine zweite Anordnung zur Verbindung der ersten Anordnung mit dem Teilnehmer, sowie eine dritte Anordnung zur Verbindung der FlexRay-Kommunikationsverbindung, also der physikalischen Schicht mit der ersten Anordnung.

Dabei enthält die erste Anordnung vorteilhafter Weise einen Botschaftsverwalter, also Message Handler und einen Botschaftsspeicher, wobei der Botschaftsverwalter die Steuerung bezüglich der Datenpfade der ersten und zweiten Anordnung bezogen auf einen Datenzugriff bezüglich des Botschaftsspeichers übernimmt. Dabei ist der Botschaftsspei- eher der ersten Anordnung zweckmäßiger Weise in ein Kopfsegment und ein Datensegment aufgeteilt ist.

Vorteilhafter Weise enthält die zweite Anordnung zur Anbindung an den Host, also den FlexRay-Teilnehmer bzw. den Host-Prozessor einen Eingangspufferspeicher und einen Ausgangspufferspeicher, wobei entweder der Eingangspufferspeicher oder der Ausgangspufferspeicher oder am besten beide Speicher in einer bevorzugten Ausführungsform jeweils in einen Teilpufferspeicher und einen Schattenspeicher aufge- teilt sind, die jeweils wechselweise nur gelesen und/oder beschrieben werden, wodurch die Datenintegrität gewährleistet wird. Das wechselweise Lesen bzw. Beschreiben des jeweiligen Teilpufferspeichers und zugehörigen Schattenspeichers kann vorteilhafterweise durch Vertauschen des jewei- ligen Zugriffs erzielt werden oder durch Vertauschen des Speicherinhalts .

Dabei ist es vorteilhaft, wenn jeder Teilpufferspeicher und jeder Schattenspeicher derart ausgelegt ist, dass je ein

Datenbereich und/oder ein Kopfbereich zweier FlexRay- Botschaften speicherbar ist.

Zur problemloseren Anpassung an unterschiedliche Teilnehmer oder Hosts enthält die zweite Anordnung einen Schnittstellenbaustein, der aus einem teilnehmerspezifischen Teilbaustein und einem teilnehmerunabhängigen Teilbaustein besteht, so dass zur Teilnehmeranpassung lediglich der teilnehmerspezifische Teilbaustein geändert werden muss und so insgesamt die Flexibilität des FlexRay-

Kommunikationsbausteins erhöht wird. Dabei können die Teilbausteine auch innerhalb des einen Schnittstellenbausteins jeweils in Software, also jeder Teilbaustein als Softwarefunktion realisiert werden.

Entsprechend der redundanten übertragungswege bei FlexRay enthält die dritte Anordnung vorteilhafter Weise einen ersten Schnittstellenbaustein und einen zweiten Schnittstellenbaustein und ist ihrerseits in zwei Datenpfade mit je- weils zwei Datenrichtungen aufgeteilt. Zweckmäßiger Weise enthält die dritte Anordnung auch einen ersten und einen zweiten Pufferspeicher, um den beiden Datenpfaden und den jeweils zwei Datenrichtungen Rechnung zu tragen. Dabei sind auch hier der erste und zweite Pufferspeicher derart ausge- legt, dass wenigstens je ein Datenbereich zweier FlexRay- Botschaften speicherbar ist. Vorteilhafter Weise enthält jeder Schnittstellenbaustein der dritten Anordnung ein Schieberegister und eine FlexRay-Protokoll- Zustandsmaschine .

Durch den erfindungsgemäßen FlexRay-Kommunikationsbaustein kann die FlexRay-Protokollspezifikation, insbesondere v2.0 oder v2.1, vollständig unterstützt werden und es sind damit z.B. bis zu 128 Botschaften bzw. Botschaftsobjekte konfigu- rierbar. Dabei ergibt sich ein flexibel konfigurierbarer

Botschaftsspeicher für die Speicherung einer unterschiedlichen Anzahl von Botschaftsobjekten abhängig von der Größe des jeweiligen Datenfeldes bzw. Datenbereiches der Botschaft. Somit sind also vorteilhafter Weise Botschaften- oder Botschaftsobjekte zu konfigurieren, die unterschiedlich lange Datenfelder besitzen. Der Botschaftsspeicher ist dabei vorteilhafter Weise als FIFO (first in-first out) ausgebildet, so dass sich ein konfigurierbarer Empfangs- FIFO ergibt. Jede Botschaft bzw. jedes Botschaftsobjekt im Speicher kann als Empfangsspeicherobjekt (Receive-Buffer) , Sendespeicherobjekt (Transmit-Buffer) oder als Teil des konfigurierbaren Empfangs-FIFOs konfiguriert werden. Ebenso ist eine Akzeptanzfilterung auf Frame-ID, Channel-ID und Cycle-Counter im FlexRay-Netzwerk möglich. Zweckmäßiger Weise wird somit das Netzwerkmanagement unterstützt. Vorteilhafter Weise sind außerdem maskierbare Modulinterrupts vorgesehen.

Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus den Merkmalen der Ansprüche ebenso wie aus der Beschreibung .

Zeichnung

Die Erfindung wird anhand der nachfolgenden Figuren der Zeichnung näher erläutert. Dabei zeigen:

Figur 1 in schematischer Darstellung den Kommunikationsbaustein und dessen Anbindung an die physikali- sehe Schicht, also die Kommunikationsverbindung und den Kommunikations- oder Host-Teilnehmer;

Figur 2 in einer speziellen Ausführungsform des Kommunikationsbausteins aus Figur 1 sowie dessen Anbin- düng im Detail;

Figur 3 die Struktur eines Botschaftsspeichers des Kommunikationsbausteins nach Figur 1 oder 2;

Figur 4 bis 6 eine schematische Ansicht der Architektur und des Prozesses des Datenzugriffs in Richtung vom Teilnehmer zum Botschaftsspeicher des Kommunikationsbausteins ;

Figur 7 bis 9 eine schematische Ansicht der Architektur und des Prozesses des Datenzugriffs in Richtung vom Botschaftsspeicher des Kommunikationsbausteins zum Teilnehmer;

Figur 10 einen Botschaftsverwalter des Kommunikationsbausteins und die darin enthaltenen Finite-State- Machines schematisch dargestellt;

Figur 11 noch einmal schematisch die Bauteile des Kommuni- kationsbausteins sowie den Teilnehmer und die entsprechenden, durch den Botschaftsverwalter gesteuerten Datenpfade;

Figur 12 die Zugriffsverteilung bezogen auf die Datenpfade in Figur 11;

Figur 13 eine vereinfachte Realisierung der Teilnehmerschnittstelle zwischen dem Kommunikationsbaustein und dem Teilnehmer;

Figur 14 eine erfindungsgemäße Zustandsmaschine abgebildet in einem Flussdiagramm; und

Figur 15 die Zustände der Zustandsmaschine nach Figur 14 für einen konkreten Pufferzugriff.

Beschreibung der Ausführungsbeispiele

Figur 1 zeigt schematisch einen FlexRay-

Kommunikationsbaustein 100 zur Anbindung eines Teilnehmers oder Hosts 102 an eine FlexRay-Kommunikationsverbindung 101, also die physikalische Schicht des FlexRay. Dazu ist der FlexRay-Kommunikationsbaustein 100 über eine Verbindung 107 mit dem Teilnehmer bzw. Teilnehmerprozessor 102 und über eine Verbindung 106 mit der Kommunikationsverbindung 101 verbunden. Zur problemlosen Anbindung zum einen bezogen auf übertragungszeiten und zum anderen bezogen auf die Datenintegrität sind schematisch im Wesentlichen drei Anord- nungen im FlexRay-Kommunikationsbaustein unterschieden.

Dabei dient eine erste Anordnung 105 zur Speicherung, insbesondere Zwischenablage, wenigstens eines Teils der zu übertragenden Botschaften. Zwischen dem Teilnehmer 102 und dieser ersten Anordnung 105 ist über die Verbindungen 107 und 108 eine zweite Anordnung 104 geschaltet. Ebenso ist zwischen Teilnehmer 101 und die erste Anordnung 105 eine dritte Anordnung 103 über die Verbindungen 106 und 109 geschaltet, wodurch ein sehr flexibles Eingeben und Ausgeben von Daten als Teil von Botschaften, insbesondere FlexRay- Botschaften in bzw. aus der ersten Anordnung 105 mit Gewährleistung der Datenintegrität bei optimaler Geschwindigkeit erzielbar ist.

In Figur 2 ist dieser Kommunikationsbaustein 100 in einer bevorzugten Ausführungsform noch einmal detaillierter dargestellt. Ebenso detaillierter dargestellt sind die jeweiligen Verbindungen 106 bis 109. Die zweite Anordnung 104 enthält dabei einen Eingangspufferspeicher oder Eingabepufferspeicher 201 (Input Buffer IBF) , einen Ausgangspuffer- Speicher oder Ausgabepufferspeicher 202 (Output Buffer OBF)

sowie einen Schnittstellenbaustein bestehend aus zwei Teilen 203 und 204, wobei der eine Teilbaustein 203 teilnehmerunabhängig und der zweite Teilbaustein 204 teilnehmerspezifisch ist. Der teilnehmerspezifische Teilbaustein 204 (Customer CPU Interface CIF) verbindet eine teilnehmerspezifische Host-CPU 102, also einen kundenspezifischen Teilnehmer, mit dem FlexRay-Kommunikationsbaustein 100. Dazu ist eine bidirektionale Datenleitung 216, eine Adressleitung 217 sowie ein Steuereingang 218 vorgesehen. Ebenso vorgesehen ist mit 219 ein Interrupt- oder Unterbrechungs- Ausgang. Der teilnehmerspezifische Teilbaustein 204 steht in Verbindung mit einem teilnehmerunabhängigen Teilbaustein 203 (Generic CPU Interface, GIF), d. h. der FlexRay- Kommunikationsbaustein, der auch als FlexRay-IPModul be- zeichnet wird, verfügt über ein generisches, also allgemeines, CPU-Interface, an das sich über entsprechende teilnehmerspezifische Teilbausteine, also Customer CPU Interfaces CIF eine große Anzahl von unterschiedlichen kundenspezifischen Host CPUs anschließen lassen. Dadurch muss abhängig vom Teilnehmer nur der Teilbaustein 204 variiert werden, was einen deutlich geringeren Aufwand bedeutet.

Der Eingabepufferspeicher oder Eingangspufferspeicher 201 und der Ausgangspufferspeicher oder Ausgabepufferspeicher 202 können in einem Speicherbaustein oder aber in getrennten Speicherbausteinen ausgebildet sein. Dabei dient der Eingabepufferspeicher 201 für die Zwischenspeicherung von Botschaften für die übertragung zum Botschaftsspeicher 200. Dabei ist der Eingabepufferbaustein vorzugsweise so ausge- bildet, dass er zwei vollständige Botschaften bestehend aus jeweils einem Kopfsegment oder Header Segment, insbesondere mit Konfigurationsdaten und ein Datensegment oder Payload Segment speichern kann. Dabei ist der Eingabepufferspeicher zweiteilig (Teilpufferspeicher und Schattenspeicher) ausge- bildet, wodurch sich durch wechselweises Schreiben der bei-

den Teile des Eingabepufferspeichers bzw. durch Zugriffswechsel die übertragung zwischen Teilnehmer-CPU 102 und Botschaftsspeicher 200 beschleunigen lässt. Ebenso dient der Ausgabepufferspeicher oder Ausgangspufferspeicher (Out- put-Buffer OBF) für 3 0 die Zwischenspeicherung von Botschaften für die übertragung vom Botschaftsspeicher 200 zur Teilnehmer-CPU 102. Dabei ist auch der Ausgabepuffer 202 so gestaltet, dass zwei komplette Botschaften bestehend aus Kopfsegment, insbesondere mit Konfigurationsdaten und Da- tensegment, also Payload Segment, gespeichert werden können. Auch hier ist der Ausgabepufferspeicher 202 in zwei Teile, einen Teilpufferspeicher und einen Schattenspeicher aufgeteilt, wodurch sich auch hier durch wechselweises Lesen der beiden Teile die übertragung bzw. durch Zugriffs- Wechsel die übertragung zwischen Teilnehmer- bzw. Host-CPU 102 und Botschaftsspeicher 200 beschleunigen lässt. Diese zweite Anordnung 104 bestehend aus den Blöcken 201 bis 204 ist mit der ersten Anordnung 105 wie dargestellt verbunden.

Die Anordnung 105 besteht aus einem Botschaftsverwalter 200 (Message Handler MHD) und einem Botschaftsspeicher 300 (Message RAM) . Der Botschaftsverwalter kontrolliert bzw. steuert den Datentransfer zwischen dem Eingabepufferspeicher 201 sowie Ausgabepufferspeicher 202 und dem Bot- Schaftsspeicher 300. Gleichermaßen kontrolliert bzw. steuert er die Datenübertragung in der anderen Richtung über die dritte Anordnung 103. Der Botschaftsspeicher ist vorzugsweise als single-ported RAM ausgeführt. Dieser RAM- Speicher speichert die Botschaften bzw. Botschaftsobjekte, also die eigentlichen Daten, zusammen mit Konfigurationsund Statusdaten. Die genaue Struktur des Botschaftsspeichers 300 ist in Figur 3 näher dargestellt.

Die dritte Anordnung 103 besteht aus den Blöcken 205 bis 208. Entsprechend den beiden Kanälen des FlexRay Physical

Layer ist diese Anordnung 103 in zwei Datenpfade mit je zwei Datenrichtungen aufgeteilt. Dies wird durch die Verbindungen 213 und 214 deutlich, worin die beiden Datenrichtungen für den Kanal A, RxA und TxA für Empfangen (RxA) und Senden (TxA) sowie für Kanal B, RxB und TxB dargestellt sind. Mit Verbindung 215 ist ein optionaler bidirektionaler Steuereingang bezeichnet. Die Anbindung der dritten Anordnung 103 erfolgt über einen ersten Pufferspeicher 205 für Kanal B und einen zweiten Pufferspeicher 206 für Kanal A. Diese beiden Pufferspeicher (Transient Buffer RAMs: RAM A und RAM B) dienen als Zwischenspeicher für die Datenübertragung von bzw. zu der ersten Anordnung 105. Entsprechend der beiden Kanäle sind diese beiden Pufferspeicher 205 und 206 mit jeweils einem Schnittstellenbaustein 207 und 208 verbunden, die die FlexRay-Protokoll-Controller oder Busprotokoll-Controller bestehend aus einem Sende-/Empfangs- Schieberegister und der FlexRay Protokoll Finite State Maschine, enthalten. Die beiden Pufferspeicher 205 und 206 dienen somit als Zwischenspeicher für die Datenübertragung zwischen den Schieberegistern der Schnittstellenbausteine oder FlexRay Protokoll Controller 207 und 208 und dem Botschaftsspeicher 300. Auch hier werden vorteilhafter Weise durch jeden Pufferspeicher 205 oder 206 die Datenfelder, also das Payload Segment oder Datensegment zweier FlexRay- Botschaften gespeichert.

Weiterhin dargestellt im Kommunikationsbaustein 100 ist mit 209 die globale Zeiteinheit (Global Time Unit GTU) , welche für die Darstellung der globalen Zeitraster im FlexRay, also den Mikrotick μT und den Makrotick MT, zuständig ist. Ebenso wird über die globale Zeiteinheit 209 die fehlertolerante Uhrensynchronisation der Zykluszähler (Cycle Coun- ter) und die Kontrolle der zeitlichen Abläufe im statischen und dynamischen Segment des FlexRay geregelt. Mit Block 210 ist die allgemeine Systemsteuerung (System Universal

Control SUC) dargestellt, durch welche die Operationsmodi des FlexRay-Kommunikationscontrollers kontrolliert und gesteuert werden. Dazu gehören der Wakeup, der Startup, die Reintegration bzw. Integration, Normaloperation (normal Operation) und passive Operation (passive Operation) .

Block 211 zeigt das Netzwerk und Fehlermanagement (Network- und Error Management NEM) , wie in der FlexRay- Protokollspezifikation v2.0 beschrieben. Block 212 schließ- lieh zeigt die Unterbrechungssteuerung (Interrupt Control INT) , welche die Status- und Fehlerunterbrechungsflaggen (status and error interrupt flags) verwaltet und die Unterbrechungsausgänge 219 zur Teilnehmer-CPU 102 kontrolliert bzw. steuert. Der Block 212 enthält außerdem einen absolu- ten und einen relativen Timer bzw. Zeitgeber zur Erzeugung der Zeitunterbrechungen oder Timerinterrupts .

Für die Kommunikation in einem FlexRay-Netzwerk können Botschaftsobjekte bzw. Botschaften (Message Buffer) mit bis zu 254 Datenbytes konfiguriert werden. Der Botschaftsspeicher 300 ist insbesondere ein Botschafts-RAM-Speicher (Message RAM), welcher z.B. bis zu maximal 128 Botschaftsobjekten speichern kann. Alle Funktionen, die die Behandlung bzw. Verwaltung der Botschaften selbst betreffen, sind dem Bot- Schaftsverwalter oder Message Handler 200 implementiert. Dies sind z.B. die Akzeptanzfilterung, Transfer der Botschaften zwischen den beiden FlexRay-Protokoll-Controller- Blöcken 207 und 208 und dem Botschaftsspeicher 300, also dem Message RAM sowie die Kontrolle der Sendereihenfolge und das Bereitstellen von Konfigurationsdaten bzw. Statusdaten.

Eine externe CPU, also ein externer Prozessor der Teilnehmerprozessor 102 kann über die Teilnehmerschnittstelle, mit dem teilnehmerspezifischen Teil 204 direkt auf die Register

des FlexRay-Kommunikationsbausteins zugreifen. Dabei wird eine Vielzahl von Registern verwendet. Diese Register werden eingesetzt, um die FlexRay Protokoll Controller, also die Schnittstellenbausteine 207 und 208 den Botschaftsver- walter (Message Handler MHD) 200, die globale Zeiteinheit (Global Time Unit GTU) 209, den allgemeinen Systemcontroller (System Universal Controller SUC) 210, die Netzwerk- und Fehlermanagementeinheit (Network und Error Management Unit NEM) 211, den Unterbrechungscontroller (Interrupt Controller INT) 212 sowie den Zugriff auf das Message RAM, also den Botschaftsspeicher 300 zu konfigurieren und zu steuern und ebenso den entsprechenden Status anzuzeigen. Zumindest auf Teile dieser Register wird noch in den Figuren 4 bis 6 und 7 bis 9 näher eingegangen. Ein solch be- schriebener, erfindungsgemäßer FlexRay-

Kommunikationsbaustein ermöglicht die einfache Umsetzung der FlexRay-Spezifikation v2.0 bzw. v2.1, wodurch einfach ein ASIC oder ein MikroController mit entsprechender Flex- Ray-Funktionalität generiert werden kann.

In Figur 3 ist detailliert die Aufteilung des Botschaftsspeichers 300 beschrieben. Für die nach der FlexRay- Protokollspezifikation geforderte Funktionalität eines FlexRay-Kommunikationscontrollers wird ein Botschaftsspei- eher für das Bereitstellen von zu sendenden Botschaften

(Transmit Buffer) sowie das Abspeichern von fehlerfrei empfangenen Botschaften (Receive Buffer) benötigt. Ein Flex- Ray-Protokoll erlaubt Botschaften mit einem Datenbereich, also einem Payload-Bereich von 0 bis 254 Bytes. Wie in Fi- gur 2 dargestellt ist der Botschaftsspeicher Teil des Flex- Ray-Kommunikationsbausteins 100. Das nachfolgend beschriebene Verfahren sowie der entsprechende Botschaftsspeicher beschreiben die Speicherung von zu sendenden Botschaften sowie von empfangenen Botschaften, insbesondere unter Ver- Wendung eines Random Access Memory (RAM) , wobei es durch

den erfindungsgemäßen Mechanismus möglich ist in einem Botschaftsspeicher vorgegebener Größe eine variable Anzahl von Botschaften zu speichern. Dabei ist die Anzahl der speicherbaren Botschaften abhängig von der Größe der Datenbe- reiche der einzelnen Botschaften, wodurch zum einen die Größe des benötigten Speichers minimiert werden kann ohne die Größe der Datenbereiche der Botschaften einzuschränken und zum anderen eine optimale Ausnutzung des Speichers erfolgt. Im Folgenden nun soll diese variable Aufteilung ei- nes insbesondere RAM-basierten Botschaftsspeichers für einen FlexRay Communication Controller näher beschrieben werden.

Zur Implementierung wird nun beispielhaft ein Botschafts- Speicher mit einer festgelegten Wortbreite von n Bit, beispielsweise 8, 16, 32 usw., sowie einer vorgegebenen Speichertiefe von m Worten vorgegeben (m, n als natürliche Zahlen) . Dabei wird der Botschaftsspeicher 300 in zwei Segmente aufgeteilt, ein Header Segment oder Kopfsegment HS und ein Datensegment DS (Payload Section, Payload Segment) . Pro Botschaft wird somit ein Headerbereich HB und ein Datenbereich DB angelegt. Für Botschaften 0, 1 bis k (k als natürliche Zahl) werden somit Headerbereiche oder Kopfbereiche HBO, HBl bis HBk und Datenbereiche DBO, DBl bis DBk ange- legt. In einer Botschaft wird also zwischen ersten und zweiten Daten unterschieden, wobei die ersten Daten Konfigurationsdaten und/oder Statusdaten bezüglich der FlexRay Botschaft entsprechen und jeweils in einem Headerbereich HB (HBO, HBl, ..., HBk) abgelegt werden. Die zweiten Daten, die den eigentlichen Daten entsprechen, die übertragen werden sollen, werden entsprechend in Datenbereichen DB (DBO, DBl, ... , DBk) abgelegt. Somit entsteht für die ersten Daten pro Botschaft ein erster Datenumfang (in Bit, Byte oder Speicherworten gemessen) und für die zweiten Daten einer Botschaft ein zweiter Datenumfang (ebenfalls in Bit,

Byte oder Speicherworten gemessen) , wobei der zweite Daten- umfang pro Botschaft unterschiedlich sein kann. Die Aufteilung zwischen Kopfsegment HS und Datensegment DS ist nun im Botschaftsspeicher 300 variabel, d. h. es existiert keine vorgegebene Grenze zwischen den Bereichen. Die Aufteilung zwischen Kopfsegment HS und Datensegment DS ist erfindungsgemäß abhängig von der Anzahl k der Botschaften sowie dem zweiten Datenumfang, also dem Umfang der eigentlichen Daten, einer Botschaft bzw. aller k Botschaften zusammen. Erfindungsgemäß wird nun den Konfigurationsdaten KDO, KDl bis KDk der jeweiligen Botschaft ein Zeigerelement oder Datapointer DPO, DPI bis DPk jeweils direkt zugeordnet. In der speziellen Ausgestaltung wird jedem Kopfbereich HBO, HBl bis HBk eine feste Anzahl von Speicherworten, hier zwei, zugeordnet, so dass immer ein Konfigurationsdatum KD (KDO, KDl, ..., KDk) und ein Zeigerelement DP (DPO, DPI, ..., DPk) zusammen in einem Headerbereich HB abgelegt sind. An diesem Kopfsegment HS mit den Headerbereichen HB, dessen Größe bzw. erster Datenumfang abhängig von der Anzahl k der zu speichernden Botschaften ist, schließt das Datensegment DS zur Speicherung der eigentlichen Botschaftsdaten DO, Dl bis Dk an. Dieses Datensegment (oder Datensection) DS hängt in seinem Datenumfang vom jeweiligen Datenumfang der abgelegten Botschaftsdaten ab, hier z.B. in DBO sechs Worte, DBl ein Wort und DBk 30 zwei Worte. Die jeweiligen Zeigerelemente DPO, DPI bis DPk zeigen somit immer zum Beginn, also auf die Anfangsadresse des jeweiligen Datenbereichs DBO, DBl bis DBk, in denen die Daten DO, Dl bis Dk der jeweiligen Botschaften 0, 1, bis k abgelegt sind. Damit ist die Aufteilung des Botschaftsspeichers zwischen Kopfsegment HS und Datensegment DS variabel und hängt von der Anzahl der Botschaften selbst sowie dem jeweiligen Datenumfang einer Botschaft und damit dem gesamten zweiten Datenumfang ab. Werden weniger Botschaften konfiguriert, wird das Kopf- segment kleiner und der frei werdende Bereich im Bot-

Schaftsspeicher kann als Zusatz zum Datensegment DS für die Speicherung von Daten verwendet werden. Durch diese Variabilität kann eine optimale Speicherausnutzung gewährleistet werden, womit auch die Verwendung kleinerer Speicher mög- lieh ist. Das freie Datensegment FDS , insbesondere dessen Größe, ebenfalls abhängig von der Kombination aus Anzahl k der gespeicherten Botschaften und dem jeweiligen zweiten Datenumfang der Botschaften ist somit minimal und kann sogar 0 werden.

Neben der Verwendung von Zeigerelementen ist es auch möglich, die ersten und zweiten Daten, also die Konfigurationsdaten KD (KDO, KDl, ..., KDk) und die eigentlichen Daten D (DO, Dl, ... , Dk) in einer vorgebbaren Reihenfolge abzu- legen, so dass die Reihenfolge der Kopfbereiche HBO bis HBk im Kopfsegment HS und die Reihenfolge der Datenbereiche DBO bis DBk im Datensegment DS jeweils identisch ist. Dann könnte unter Umständen sogar auf ein Zeigerelement verzichtet werden.

In einer besonderen Ausgestaltung ist dem Botschaftsspeicher ein Fehlerkennungserzeuger, insbesondere ein Parity- Bit-Generator-Element und ein Fehlerkennungsprüfer, insbesondere ein Parity-Bit-Prüf-Element zugeordnet, um die Kor- rektheit der gespeicherten Daten in HS und DS zu gewährleisten, indem pro Speicherwort oder pro Bereich (HB und/oder DB) eine Prüfsumme eben insbesondere als Parity- Bit mit abgelegt werden kann. Andere Kontrollkennungen, z.B. ein CRC (Cyclic Redundancy Check) oder auch Kennungen höherer Mächtigkeit wie ECC ( Error Code Correction) sind denkbar. Damit sind gegenüber einer festgelegten Aufteilung des Botschaftsspeichers folgende Vorteile gegeben:

Der Anwender kann bei der Programmierung entscheiden, ob er eine größere Anzahl von Botschaften mit kleinem Datenfeld

oder ob er eine kleinere Anzahl von Botschaften mit großem Datenfeld verwenden möchte. Bei der Konfiguration von Botschaften mit unter-schiedlich großem Datenbereich wird der vorhandene Speicherplatz optimal ausgenutzt. Der Anwender hat die Möglichkeit einen Datenspeicherbereich gemeinsam für unterschiedliche Botschaften zu nutzen.

Bei der Implementierung des Communication Controllers auf einer integrierten Schaltung kann die Größe des Botschafts- Speichers durch Anpassung der Speichertiefe des verwendeten Speichers an die Bedürfnisse der Applikation angepasst werden, ohne die sonstigen Funktionen des Communication Controllers zu ändern.

Im Weiteren wird nun anhand der Figuren 4 bis 6 sowie 7 bis 9 der Host-CPU-Zugriff, also Schreiben und Lesen von Konfigurationsdaten bzw. Statusdaten und der eigentlichen Daten über die Pufferspeicheranordnung 201 und 202, näher beschrieben. Dabei ist es das Ziel, eine Entkopplung bezüg- lieh der Datenübertragung derart herzustellen, dass die

Datenintegrität sichergestellt werden kann und gleichzeitig eine hohe übertragungsgeschwindigkeit gewährleistet ist. Die Steuerung dieser Vorgänge erfolgt über den Botschaftsverwalter 200, was später noch näher in den Figuren 10, 11 und 12 beschrieben wird.

In den Figuren 4, 5 und 6 werden zunächst die Schreibzugriffe auf den Botschaftsspeicher 300 durch die Host-CPU der Teilnehmer-CPU 102 über den Eingangspufferspeicher 201 näher erläutert. Dazu zeigt Figur 4 noch einmal den Kommunikationsbaustein 100, wobei aus Gründen der übersichtlichkeit nur die hier relevanten Teile des Kommunikationsbausteins 100 gezeigt sind. Dies ist zum einen der für die Steuerung der Abläufe verantwortliche Botschaftsverwalter 200 sowie zwei Kontrollregister 403 und 404, die wie darge-

stellt außerhalb des Botschaftsverwalters 200 im Kommunikationsbaustein 100 untergebracht sein können, aber auch im Botschaftsverwalter 200 selbst enthalten sein können. 403 stellt dabei das Eingangs-Anforderungsregister (Input Buf- fer Command Request Register) dar und 404 das Eingangs- Maskierungsregister (Input Buffer Command Mask Register) . Schreibzugriffe der Host-CPU 102 auf den Botschaftsspeicher 300 (Message RAM) erfolgen also über einen zwischengeschalteten Eingangspufferspeicher 201 (Input Buffer) . Dieser Eingangspufferspeicher 201 ist nun geteilt bzw. gedoppelt ausgelegt, und zwar als Teilpufferspeicher 400 und einem zu dem Teilpufferspeicher zugehörigen Schattenspeicher 401. Damit kann wie nachfolgend beschrieben ein kontinuierlicher Zugriff der Host-CPU 102 auf die Botschaften bzw. Bot- schaftsobjekte respektive Daten des Botschaftsspeichers 300 erfolgen und damit Datenintegrität und beschleunigte übertragung gewährleistet werden. Die Steuerung der Zugriffe erfolgt über das Eingangs-Anforderungsregister 403 und über das Eingangs-Maskierungsregister 404. Im Register 403 sind mit den Zahlen von 0 bis 31 die jeweiligen Bitstellen in 403 hier beispielhaft für eine Breite von 32 Bit dargestellt. Gleiches gilt für das Register 404 und die Bitstellen 0 bis 31 in 404.

Erfindungsgemäß erhalten nun beispielhaft die Bitstellen 0 bis 5, 15, 16 bis 21 und 31 des Registers 403 bezüglich der Ablaufsteuerung eine besondere Funktion. So ist in die Bitstellen 0 bis 5 des Registers 403 eine Kennung IBRH (Input Buffer Request Host) als Botschaftskennung eintragbar. E- benso ist in die Bitstellen 16 bis 21 des Registers 403 eine Kennung IBRS (Input Buffer Request Shaddow) eintragbar. Ebenso sind in Registerstelle 15 von 403 IBSYH und in Registerstelle 31 von 403 IBSYS als Zugriffskennungen eingetragen. Ausgezeichnet sind auch die Stellen 0 bis 2 des Registers 404, wobei in 0 und 1 mit LHSH (Load Header See-

tion Host) und LDSH (Load Data Section Host) weitere Kennungen als Datenkennungen eingetragen sind. Diese Datenken- nungen sind hier in einfachster Form, nämlich jeweils als ein Bit ausgebildet. In Bitstelle 2 von Register 404 ist mit STXRH (Set Transmission X Request Host) eine Startken- nung eingeschrieben. Im Weiteren wird nun der Ablauf des Schreibzugriffs auf den Botschaftsspeicher über den Eingangspuffer beschrieben.

Die Host-CPU 102 schreibt die Daten der zu transferierenden Botschaft in den Eingangspufferspeicher 201. Dabei kann die Host-CPU 102 nur die Konfigurations- und Headerdaten KD einer Botschaft für das Headersegment HS des Botschaftsspeichers oder nur die eigentlichen, zu übertragenden Daten D einer Botschaft für das Datensegment DS des Botschaftsspeichers oder beide schreiben. Welcher Teil einer Botschaft also Konfigurationsdaten und/oder die eigentlichen Daten übertragen werden soll, wird durch die speziellen Datenkennungen LHSH und LDSH im Eingangs- Markierungsregister 404 festgelegt. Dabei wird durch LHSH (Load Header Section Host) festgelegt ob die Headerdaten, also die Konfigurationsdaten KD, übertragen werden und durch LDSH (Load Data Section Host) festgelegt, ob die Daten D übertragen werden sollen. Dadurch, dass der Eingangs- Pufferspeicher 201 zweiteilig mit einem Teil des Pufferspeichers 400 und einem dazugehörigen Schattenspeicher 401 ausgebildet ist und ein wechselseitiger Zugriff erfolgen soll sind als Gegenstück zu LHSH und LDSH zwei weitere Da- tenkennungsbereiche vorgesehen, die nun auf den Schatten- Speicher 401 bezogen sind. Diese Datenkennungen in den Bitstellen 16 und 17 des Registers 404 sind mit LHSS (Load Header Section Shadow) und LDSS (Load Data Section Shadow) bezeichnet. Durch diese wird somit der übertragungsvorgang bezüglich des Schattenspeichers 401 gesteuert.

Ist nun das Startbit bzw. die Startkennung STXRH (Set Transmission X Request Host) in Bitstelle 2 des Eingangs- Maskierungsregisters 404 gesetzt, so wird nach erfolgtem Transfer der jeweils zu übertragenden Konfigurationsdaten und/oder eigentlichen Daten in den Botschaftsspeicher 300 automatisch eine Sendeanforderung (Transmission Request) für das entsprechende Botschaftsobjekt gesetzt. D. h. durch diese Startkennung STXRH wird das automatische Senden eines übertragenden Botschaftsobjekts gesteuert, insbesondere gestartet.

Das Gegenstück hierzu entsprechend für den Schattenspeicher ist die Startkennung STXRS (Set Transmission X Request Sha- dow) welches beispielhaft in Bitstelle 18 des Eingangs- Markierungsregisters 404 enthalten ist und auch hier im einfachsten Fall eben als ein Bit ausgebildet ist. Die Funktion von STXRS ist analog der Funktion von STXRH, lediglich bezogen auf den Schattenspeicher 1.

Wenn die Host-CPU 102 die Botschaftskennung, insbesondere die Nummer des Botschaftsobjekts im Botschaftsspeicher 300 in welches die Daten des Eingangspufferspeichers 201 transferiert werden sollen in die Bitstellen 0 bis 5 des Ein- gangs-Anforderungsregisters 403, also nach IBRF-I schreibt werden der Teilpufferspeicher 400 des Eingangspufferspeichers 201 und der zugehörige Schattenspeicher 401 vertauscht bzw. es wird der jeweilige Zugriff von Host-CPU 102 und Botschaftsspeicher 300 auf die beiden Teilspeicher 400 und 401 vertauscht, wie durch die halbkreisförmigen Pfeile angedeutet. Dabei wird z.B. auch der Datentransfer, also die Datenübertragung zum Botschaftsspeicher 300 gestartet. Die Datenübertragung zum Botschaftsspeicher 300 selbst erfolgt aus dem Schattenspeicher 401. Gleichzeitig werden die Registerbereiche IBRH und IBRS getauscht. Ebenso getauscht werden LHSH und LDSH gegen LHSS und LDSS. Gleichermaßen

getauscht wird STXRH mit STXRS. IBRS zeigt somit die Kennung der Botschaft, also die Nummer des Botschaftsobjektes für das eine übertragung, also ein Transfer aus dem Schattenspeicher 401 im Gange ist bzw. welches Botschaftsobjekt, also welcher Bereich im Botschaftsspeicher als letztes Daten (KD und/oder D) aus dem Schattenspeicher 401 erhalten hat. Durch die Kennung (hier wieder beispielsweise 1 Bit) IBSYS (Input Buffer Busy Shadow) in Bitstelle 31 des Ein- gangs-Anforderungsregisters 403 wird angezeigt ob gerade eine übertragung mit Beteiligung des Schattenspeichers 401 erfolgt. So wird beispielsweise bei IBSYS=I gerade aus dem Schattenspeicher 401 übertragen und bei IBSYS=O eben nicht. Dieses Bit IBSYS wird beispielsweise durch das Schreiben von IBRH also Bitstellen 0 bis 5 in Register 403 gesetzt, um anzuzeigen, dass ein Transfer zwischen dem Schattenspeicher 401 und dem Botschaftsspeicher 300 im Gange ist. Nach Beendigung dieser Datenübertragung zum Botschaftsspeicher 300 wird IBSYS wieder zurückgesetzt.

Während der Datentransfer aus dem Schattenspeicher 401 gerade läuft kann die Host-CPU 102 die nächste zu transferierende Botschaft in den Eingangspufferspeicher bzw. in den Teilpufferspeicher 400 schreiben. Mit Hilfe einer weiteren Zugriffskennung IBSYH (Input Buffer Busy Host) beispiels- weise in Bitstelle 15 von Register 403 kann die Kennung noch weiter verfeinert werden. Schreibt die Host-CPU 102 gerade IBRH, also die Bitstellen 0 bis 5 von Register 403 während eine übertragung zwischen dem Schattenspeicher 401 und dem Botschaftsspeicher 300 läuft, also IBSYS=I ist, so wird IBSYH im Eingangs-Anforderungsregister 403 gesetzt.

Sobald der laufende Transfer also die laufende übertragung abgeschlossen ist, wird der angeforderte Transfer (Anforderung durch STXRH siehe oben) gestartet und das Bit IBSYH zurückgesetzt. Das Bit IBSYS bleibt während der ganzen Zeit gesetzt, um anzuzeigen, dass Daten zum Botschaftsspeicher

transferiert werden. Alle verwendeten Bits aller Ausführungsbeispiele können dabei auch als Kennungen mit mehr als einem Bit ausgebildet sein. Vorteilhaft ist die Ein-Bit Lösung aus Speicher- und verarbeitungsökonomischen Gründen.

Der so beschriebene Mechanismus erlaubt es der Host-CPU 102 kontinuierlich Daten in die im Botschaftsspeicher befindlichen Botschaftsobjekte bestehend aus Headerbereich HB und Datenbereich DB zu transferieren, vorrausgesetzt die Zugriffsgeschwindigkeit der Host-CPU 102 auf den Eingangspufferspeicher ist kleiner oder gleich der internen Daten- transferrate des FlexRay-IP-Moduls also des Kommunikationsbausteins 100.

In den Figuren 7, 8 und 9 werden nun die Lesezugriffe auf den Botschaftsspeicher 300 durch die Host-CPU oder Teilnehmer-CPU 102 über den Ausgangspufferspeicher oder Ausgabepufferspeicher 202 näher erläutert. Dazu zeigt Figur 7 noch einmal den Kommunikationsbaustein 100, wobei aus Gründen der übersichtlichkeit auch hier nur die relevanten Teile des Kommunikationsbausteins 100 gezeigt sind. Dies ist zum einen der für die Steuerung der Abläufe verantwortliche Botschaftsverwalter 200 sowie zwei Kontrollregister 703 und 704, die wie dargestellt außerhalb des Botschaftsverwalter 300 im Kommunikationsbaustein 100 untergebracht sein können, aber auch im Botschaftsverwalter 200 selbst enthalten sein können. 703 stellt dabei das Ausgangs-

Anforderungsregister (Output Buffer Command Request Register) dar und 704 das Ausgangs-Maskierungsregister (Output Buffer Command Mask Register) . Lesezugriffe der Host-CPU 102 auf den Botschaftsspeicher 300 erfolgen also über den zwischengeschalteten Ausgangspufferspeicher 202 (Output Buffer) . Dieser Ausgangspufferspeicher 202 ist nun ebenfalls geteilt bzw. gedoppelt ausgelegt, und zwar als Teil- Pufferspeicher 701 und einem zu dem Teilpufferspeicher zu-

gehörigen Schattenspeicher 700. Damit kann auch hier wie nachfolgend beschrieben ein kontinuierlicher Zugriff der Host-CPU 102 auf die Botschaften bzw. Botschaftsobjekte respektive Daten des Botschaftsspeichers 300 erfolgen und damit Datenintegrität und beschleunigte übertragung nun in der Gegenrichtung vom Botschaftsspeicher zum Host gewährleistet werden. Die Steuerung der Zugriffe erfolgt über das Ausgangs-Anforderungsregister 703 und über das Eingangs- Maskierungsregister 704. Auch im Register 703 sind mit den Zahlen von 0 bis 31 die jeweiligen Bitstellen in 703 hier beispielhaft für eine Breite von 32 Bit dargestellt. Gleiches gilt für das Register 704 und die Bitstellen 0 bis 31 in 704.

Erfindungsgemäß erhalten nun beispielhaft die Bitstellen 0 bis 5, 8 und 9, 15 und 16 bis 21 des Registers 703 bezüglich der Ablaufsteuerung des Lesezugriffs eine besondere Funktion. So ist in die Bitstellen 0 bis 5 des Registers 703 eine Kennung OBRS (Output Buffer Request Shadow) als Botschaftskennung eintragbar. Ebenso ist in die Bitstellen 16 bis 21 des Registers 703 eine Kennung OBRH (Output Buffer Request Host) eintragbar. Als Zugriffskennung ist in Bitstelle 15 von Register 703 eine Kennung OBSYS (Output Buffer Busy Shadow) eintragbar. Ausgezeichnet sind auch die Stellen 0 und 1 des Ausgabe-Maskierungsregisters 704, wobei in den Bitstellen 0 und 1 mit RDSS (Read Data Section Shadow) und RHSS (Read Header Section Shadow) weitere Kennungen als Datenkennungen eingetragen sind. Weitere Datenken- nungen sind beispielsweise in den Bitstellen 16 und 17 mit RDSH (Read Data Section Host) und RHSH (Read Header Section Host) vorgesehen. Diese Datenkennungen sind auch hier beispielhaft in einfachster Form, nämlich jeweils als ein Bit ausgebildet. In Bitstelle 9 des Registers 703 ist eine Startkennung REQ eingetragen. Weiterhin ist eine Umschalt-

kennung VIEW vorgesehen die beispielhaft in Bitstelle 8 von Register 703 eingetragen ist.

Die Host-CPU 102 fordert die Daten eines Botschaftsobjekts aus dem Botschaftsspeicher 300 an, indem sie die Kennung der gewünschten Botschaft, also insbesondere die Nummer des gewünschten Botschaftsobjektes, nach OBRS also in die Bitstellen 0 bis 5 des Registers 703 schreibt. Auch hierbei kann die Host-CPU wie in der Gegenrichtung entweder nur die Status- bzw. Konfigurations- und Headerdaten KD einer Botschaft also aus einem Headerbereich oder nur die eigentlich zu übertragenden Daten D einer Botschaft also aus dem Datenbereich oder auch beide lesen. Welcher Teil der Daten also aus Headerbereich und/oder Datenbereich übertragen werden soll wird hierbei vergleichbar mit der Gegenrichtung durch RHSS und RDSS festgelegt. Das heißt RHSS gibt an, ob die Headerdaten gelesen werden sollen und RDSS gibt an, ob die eigentlichen Daten gelesen werden sollen.

Eine Startkennung dient dazu die übertragung vom Botschaftsspeicher zum Schattenspeicher 700 zu starten. D.h. wird als Kennung wie im einfachsten Fall ein Bit verwendet, wird durch Setzen von Bit REQ in Bitstelle 9 im Ausgabe- Anforderungsregister 703 die übertragung vom Botschafts- Speicher 300 zum Schattenspeicher 700 gestartet. Die laufende übertragung wird wieder durch eine Zugriffskennung, hier wieder im einfachsten Fall durch ein Bit OBSYS im Register 703 angezeigt. Um Kollisionen zu vermeiden ist es vorteilhaft, wenn das Bit REQ nur dann gesetzt werden kann, wenn OBSYS nicht gesetzt ist also gerade keine laufende

übertragung erfolgt. Hier erfolgt dann auch der Botschaftstransfer zwischen dem Botschaftsspeicher 300 und dem Schattenspeicher 700. Der eigentliche Ablauf könnte nun einerseits vergleichbar zur Gegenrichtung wie unter den Figuren 4, 5 und 6 beschrieben gesteuert werden (komplementäre Re-

gisterbelegung) und erfolgen oder aber in einer Variation durch eine zusätzliche Kennung, nämlich eine Umsehaltkennung VIEW in Bitstelle 8 des Registers 703. D.h. nach Ab- schluss der übertragung wird das Bit OBSYS zurückgesetzt und durch Setzen des Bits VIEW im Ausgabe- Anforderungsregister 703 werden der Teilpufferspeicher 701 und der zugehörige Schattenspeicher 700 getauscht bzw. es werden die Zugriffe darauf getauscht und die Host-CPU 102 kann nun das vom Botschaftsspeicher angeforderte Bot- schaftsobjekt also die entsprechende Botschaft aus dem Teilpufferspeicher 701 auslesen. Dabei werden auch hier vergleichbar mit der Gegenübertragungsrichtung in den Figuren 4 bist 6 die Registerzellen OBRS und OBRH getauscht. Gleichermaßen werden RHSS und RDSS gegen RHSH und RDSH ge- tauscht. Als Schutzmechanismus kann auch hier vorgesehen werden, dass das Bit VIEW nur dann gesetzt werden kann, wenn OBSYS nicht gesetzt ist, also keine laufende übertragung stattfindet.

Somit erfolgen Lesezugriffe der Host-CPU 102 auf den Botschaftsspeicher 300 über einen zwischengeschalteten Ausgangspufferspeicher 202. Dieser Ausgangspufferspeicher ist ebenso wie der Eingangspufferspeicher doppelt bzw. zweiteilig ausgelegt um einen kontinuierlichen Zugriff der Host- CPU 102 auf die Botschaftsobjekte die im Botschaftsspeicher 300 abgelegt sind zu gewährleisten. Auch hier werden die Vorteile der hohen Datenintegrität und der beschleunigten übertragung erzielt.

Durch die Verwendung der beschriebenen Eingangs- und Ausgangspuffer wird sichergestellt, dass eine Host-CPU trotz der modulinternen Latenzzeiten unterbrechungsfrei auf den Botschaftsspeicher zugreifen kann.

Zur Sicherstellung dieser Datenintegrität wird die Datenübertragung, insbesondere die Weiterleitung im Kommunikationsbaustein 100 durch den Botschaftsverwalter 200 (Message Handler MHD) vorgenommen. Dazu ist in Figur 10 der Bot- Schaftsverwalter 200 dargestellt. Der Botschaftsverwalter ist in seiner Funktionalität durch mehrere Zustandsmaschi- nen oder Zustandsautomaten, also endliche Automaten, sogenannte Finite-State-Machinen (FSM) darstellbar. Dabei sind wenigstens drei Zustandsmaschinen und in einer besonderen Ausführungsform vier Finite-State-Machinen vorgesehen. Eine erste Finite-State-Machine ist die IOBF-FSM und mit 501 bezeichnet (Input/Output Buffer State Machine) . Diese IOBF- FSM könnte auch je übertragungsrichtung bezüglich des Eingangspufferspeichers oder des Ausgangspufferspeichers in zwei Finite-State-Machinen aufgeteilt sein IBF-FSM (Input Buffer FSM) und OBF-FSM (Output Buffer FSM) , womit maximal fünf Zustandsautomaten (IBF-FSM, OBF-FSM, TBFl-FSM, TBF2- FSM, AFSM) denkbar wären. Bevorzugt ist aber eine gemeinsame IOBF-FSM vorzusehen. Eine wenigstens zweite Finite- State-Machine ist hier im Zuge des bevorzugten Ausführungsbeispiels in zwei Blöcke 502 und 503 aufgeteilt und bedient die beiden Kanäle A und B bezüglich der Speicher 205 und 206, wie zu Fig. 2 beschrieben. Dabei kann eine Finite- State-Machine vorgesehen sein um beide Kanäle A und B zu bedienen oder aber wie in der bevorzugten Form eine Finit- State-Machine TBFl-FSM mit 502 bezeichnet (Transient Buffer 1 (206, RAM A) State Machine) für Kanal A und für Kanal B eine TBF2-FSM mit 503 bezeichnet (Transient Buffer 2 (205, RAM B) State Machine) .

Zur Steuerung des Zugriffs der drei Finite-State-Machinen 501-503 im bevorzugten Ausführungsbeispiel dient eine Arbi- ter-Finite-State-Machine, die sogenannte AFSM, die mit 500 bezeichnet ist. Die Daten (KD und/oder D) werden in einem durch ein Taktmittel, wie z.B. ein VCO (Voltage Controlled

Oszillator) , einen Schwingquarz usw. generierten oder aus diesem angepassten Takt im Kommunikationsbaustein übertragen. Der Takt T kann dabei im Baustein generiert werden oder von außen, z.B. als Bustakt vorgegeben sein. Diese Arbiter-Finite-State-Machine AFSM 500 gibt abwechselnd einer der drei Finit-State-Machinen 501-503, insbesondere jeweils für eine Taktperiode T Zugriff auf den Botschaftsspeicher. D.h. die zur Verfügung stehende Zeit wird entsprechend den Zugriffsanforderungen der einzelnen Zustands- automaten 501, 502, 503 auf diese anfordernden Zustandsautomaten aufgeteilt. Erfolgt eine Zugriffsanforderung von nur einer Finite-State-Machine, so erhält diese 100% der Zugriffszeit, also alle Takte T. Erfolgt eine Zugriffsanforderung von zwei Zustandsautomaten, erhält jede Finite- State-Machine 50% der Zugriffszeit. Erfolgt schließlich eine Zugriffsanforderung von drei Zustandsautomaten so erhält jede der Finite-State-Machinen 1/3 der Zugriffszeit. Dadurch wird die jeweils zur Verfügung stehende Bandbreite optimal genutzt.

Die erste Finite-State-Machine mit 501 bezeichnet, also IOBF-FSM führt bei Bedarf folgende Aktionen aus :

- Datentransfer vom Eingangspufferspeicher 201 zum ausgewählten Botschaftsobjekt im Botschaftsspeicher 300. - Datentransfer vom ausgewählten Botschaftsobjekt im Botschaftsspeicher 300 zum Ausgangspufferspeicher 202.

Die Zustandsmaschine für Kanal A 502, also TBFlFSM, führt folgende Aktionen aus : - Datentransfer vom ausgewählten Botschaftsobjekt im Botschaftsspeicher 300 zum Pufferspeicher 206 von Kanal A.

- Datentransfer vom Pufferspeicher 206 zum ausgewählten Botschaftsobjekt im Botschaftsspeicher 300.

- Suche nach dem passenden Botschaftsobjekt im Botschafts- Speicher, wobei bei Empfang das Botschaftsobjekt (Receive

Buffer) zum Abspeichern einer auf Kanal A empfangenen Botschaft im Rahmen einer Akzeptanzfilterung gesucht wird und beim Senden das nächste auf Kanal A zu sendende Botschaftsobjekt (Transmit Buffer) .

Analog dazu ist die Aktion von TBF2-FSM, also der Finite- State-Machine für Kanal B in Block 503. Diese führt den Datentransfer vom ausgewählten Botschaftsobjekt im Botschaftsspeicher 300 zum Pufferspeicher 205 von Kanal B aus und den Datentransfer vom Pufferspeicher 205 zum ausgewählten Botschaftsobjekt im Botschaftsspeicher 300. Auch die Suchfunktion ist analog zu TBFl-FSM nach einem passenden Botschaftsobjekt im Botschaftsspeicher, wobei bei Empfang das Botschaftsobjekt (Receive Buffer) zum Abspeichern einer auf Kanal B empfangenen Botschaft im Rahmen einer Akzeptanzfilterung gesucht wird und beim Senden die nächste auf Kanal B zu sendende Botschaft oder Botschaftsobjekt (Transmit Buffer) .

In Figur 11 sind nun noch einmal die Abläufe und die übertragungswege dargestellt. Die drei Zustandsmaschinen 501- 503 steuern die jeweiligen Datenübertragungen zwischen den einzelnen Teilen. Dabei ist mit 102 wieder die Host-CPU dargestellt, mit 201 der Eingangspufferspeicher und mit 202 der Ausgangspufferspeicher. Mit 300 ist der Botschaftsspeicher dargestellt und die beiden Pufferspeicher für Kanal A und Kanal B mit 206 und 205. Die Schnittstellenelemente 207 und 208 sind ebenfalls dargestellt. Der erste Zustandsauto- mat IOBF-FSM, mit 501 bezeichnet steuert den Datentransfer ZlA und ZlB, also vom Eingangspufferspeicher 201 zum Botschaftsspeicher 300 und vom Botschaftsspeicher 300 zum Ausgangspufferspeicher 202. Die Datenübertragung erfolgt dabei über Datenbusse mit einer Wortbreite von beispielsweise 32 Bit wobei auch jede andere Bitzahl möglich ist. Gleiches gilt für die übertragung Z2 zwischen dem Botschaftsspeicher

und dem Pufferspeicher 206. Diese Datenübertragung wird durch TBFI-FSM, also 502 die Zustandsmaschine für Kanal A, gesteuert. Die übertragung Z3 zwischen Botschaftsspeicher 300 und Pufferspeicher 205 wird durch den Zustandsautomaten TBF2-FSM, also 503 gesteuert. Auch hier erfolgt der Datentransfer Ober Datenbusse mit einer beispielhaften Wordbreite von 32 Bit, wobei auch hier jede andere Bitzahl möglich ist. Normalerweise benötigt der Transfer eines kompletten Botschaftsobjektes über die genannten übertragungswege meh- rere Taktperioden T. Daher erfolgt eine Aufteilung der ü- bertragungszeit bezogen auf die Taktperioden T durch den Arbiter, also die AFSM 500. In Figur 11 sind also die Datenpfade zwischen denen vom Message Handler 200 kontrollierten Speicherkomponenten dargestellt. Um die Dateninteg- rität der im Botschaftsspeicher gespeicherten Botschaftsobjekte sicherzustellen, sollten vorteilhafterweise zur gleichen Zeit nur auf einem der dargestellten Pfade also ZlA und ZlB sowie Z2 und Z3 gleichzeitig Daten ausgetauscht werden.

In Abbildung 12 ist an einem Beispiel gezeigt, wie die zur Verfügung stehenden Systemtakte T vom Arbiter, also der AFSM 500, auf die drei anfordernden Zustandsautomaten aufgeteilt werden. In Phase 1 erfolgen Zugriffsanforderungen von Zustandsautomat 501 und Zustandsautomat 502, d.h., dass die gesamte Zeit jeweils zur Hälfte auf die beiden anfordernden Zustandautomaten aufgeteilt wird. Bezogen auf die Taktperioden in Phase 1 bedeutet dies, dass Zustandsautomat 501 in den Taktperioden Tl und T3 Zugriff erhält und Zu- Standsautomat 502 in den Taktperioden T2 und T4. In Phase 2 erfolgt der Zugriff nur durch die Zustandsmaschine 501, sodass alle drei Taktperioden, also 100% der Zugriffszeit von T5 bis T7 auf IOBF-FSM entfällt. In Phase 3 erfolgen Zugriffsanforderungen aller drei Zustandsautomaten 501 bis 503, sodass eine Drittelung der Gesamtzugriffszeit erfolgt.

Der Arbiter AFSM verteilt dann die Zugriffszeit beispielsweise so, dass in den Taktperioden T8 und TlI die Finite- State-Machine 501, in den Taktperioden T9 und T12 die Fini- te-State-Machine 502 und in den Taktperioden TlO und T13 die Finite-State-Machine 503 Zugriff erhält. In Phase 4 schließlich erfolgt der Zugriff durch zwei Zustandsautomaten, 502 und 503 auf den beiden Kanälen A und B des Kommunikationsbausteins, sodass eine Zugriffsverteilung der Taktperioden T14 und T16 an Finite-State-Machine 502 und in T15 und T17 an Finite-State-Machine 503 erfolgt.

Der Arbiterzustandsautomat AFSM 500 sorgt also dafür, dass für den Fall wenn mehr als eine der drei Zustandsmaschinen eine Anforderung für einen Zugriff auf den Botschaftsspei- eher 300 stellt, der Zugriff Taktweise und abwechselnd auf die anfordernden Zustandsmaschinen aufgeteilt wird. Diese Vorgehensweise stellt die Integrität der im Botschaftsspeicher abgelegten Botschaftsobjekte, also die Datenintegrität, sicher. Will zum Beispiel die Host-CPU 102 über den Ausgangspufferspeicher 202 ein Botschaftsobjekt auslesen während gerade eine empfangene Botschaft in dieses Botschaftsobjekt geschrieben wird, so wird abhängig davon welche Anforderung zuerst gestartet wurde entweder der alte Stand oder der neue Stand ausgelesen, ohne das die Zugriffe im Botschaftsobjekt im Botschaftsspeicher selbst kollidieren.

Das beschriebene Verfahren ermöglicht der Host-CPU im laufenden Betrieb jedes beliebige Botschaftsobjekt im Bot- Schaftsspeicher zu lesen oder zu schreiben, ohne dass das ausgewählte Botschaftsobjekt für die Dauer des Zugriffs der Host-CPU von der Teilnahme am Datenaustausch auf beiden Kanälen des FlexRay Busses gesperrt wäre (Buffer Locking) . Gleichzeitig wird durch die Taktweise Verschachtelung der Zugriffe die Integrität der im Botschaftsspeicher abgeleg-

ten Daten sichergestellt und die übertragungsgeschwindigkeit, auch durch Ausnutzung der vollen Bandbreite erhöht.

FlexRay ASC-Protokoll Stufe 2

Die bevorzugte Erfindung betrifft nun im Rahmen des vorhergehend beschriebenen ein Verfahren und eine Vorrichtung zur übertragung von Daten zwischen einem Mikroprozessor (HOST) und einer peripheren Einrichtung z. B. zur Kommunikation insbesondere im FlexRay, wie sie unter anderem zur Steuerung von Brennkraftmaschinen verwendet wird. Für diese Datenübertragung stehen of nur begrenzte Ressourcen zur Verfügung, d.h. die Bandbreite ist begrenzt. Das ist typischerweise bei der Verwendung einer seriellen Schnittstelle der Fall. Die asynchrone und/oder synchrone, insbesondere serielle Schnittstelle (ASC) 107 für den FlexRay Controller verbindet die Anordnung 104 bzw. den entsprechenden Teilbaustein 204 über die CPU Schnittstelle 107 als periphere Einheit mit dem Host 102. Die Bedeutung der übertragenen Informationen wird durch ein Protokoll, wie beschrieben bevorzugt (aber nicht ausschließlich) durch das FlexRay- Protokoll festgelegt. üblicherweise umfasst ein solches Protokoll folgende Bestandteile: 1) Ein Flag für die Zugriffsart (Lesen/Schreiben) 2) Eine Adresse für den Zugriffsort

3a) Ein Zähler für die Anzahl der zu übertragenden Datenworte Oder 3b) Ein Flag das festlegt, ob die Adresse nach dem Zugriff erhöht wird und beim nächsten Zugriff damit automatisch bereit steht, und 4) Optional die Größe des Adressinkrements .

Ein Protokollbefehl mit den Bestandteilen 1) bis 4) kann als ein einfaches Kommando bezeichnet werden. Ein solches

Kommando ist gut nutzbar und erweist sich als effizient, falls die zu übertragenden Daten sequenziell abgelegt sind bzw. sequenziell abgelegt werden sollen. Falls die Zugriffe jedoch nicht in sequenzieller Reihenfolge erfolgen können, erzeugen diese einfachen Kommandos einen Overhead, dessen Abarbeitung Speicher- und Rechenressourcen der Host-CPU beansprucht. Als Overhead gelten in der Datenübertragung Daten, die nicht primär zu den Nutzdaten zählen, sondern als Zusatzinformation zur übermittlung oder Speicherung benötigt werden.

Falls nun auf Adressen zugegriffen werden muss, die nicht unmittelbar aufeinander folgen oder deren Abstände unregelmäßig sind, muss mit den einfachen Kommandos immer wieder eine neue Adressinformation übertragen werden.

Falls einzelne Bits bei der übertragung verfälscht werden, so wird mit den einfachen Kommandos entweder auf einen falschen Ort zugegriffen oder sogar Lesen und Schreiben ver- tauscht.

Um einen höheren Datendurchsatz erzielen zu können, wird im Rahmen der Erfindung zur Datenübertragung auf zusätzliche Informationen zugegriffen, wie bspw. : * interne Statusinformationen (z.B. ready/ busy State/ bits) ,

* Informationen über Bit-Felder (z.B. Grenzen),

* vorgegebene Werte (reduzieren Redundanz),

* vorgegebene Sequenzen einfacher Kommandos (reduzieren Redundanz) ,

* Ergebnisse einer CRC-Prüfung, um die Fehlerfreiheit von Kommandos und Adressen sicherzustellen.

Um die Effizienz von Zugriffen außerhalb der Reihe und auch für gemischte Schreib- und Lesezugriffe zu steigern, wird

ein Protokoll erstellt in Form eines fest verdrahteten Ablaufsteuerung (hardwired sequencer) oder mit einer programmierbaren Ablaufsteuerung (programmable sequencer) . Die fest verdrahtete Ablaufsteuerung verbraucht weniger Res- sourcen (z.B. Speicherplatz) und ist kostengünstiger. Außerdem hat sie Vorteile hinsichtlich Zuverlässigkeit und ist einfacher in der Anwendung. Die programmierbare Ablaufsteuerung ist dagegen effizienter und flexibler als die fest verdrahtete.

Praktische Analysen der Datenübertragung mittels FlexRay- Kommunikationsbaustein helfen, die am häufigsten genutzten Sequenzen und die entsprechenden einfachen Kommandos zu identifizieren. Diese werden in der Ablaufsteuerung reali- siert (fest verdrahtet oder programmiert) und können auf einfache Weise aufgerufen werden. Somit sind also mehrere einfache Kommandos zu mindestens einem komplexen Kommando zusammengefasst, wobei jedes komplexe Kommando mit weniger Befehlen aufgerufen werden kann, als die darin enthaltenen einfachen Kommandos. Außerdem benötigt die Abarbeitung der komplexen Kommandos weniger Ressourcen als die Abarbeitung der einzelnen darin enthaltenen einfachen Kommandos .

Ein komplexes Kommando kann gemäß dem Protokoll bspw. die folgenden einfachen Kommandos enthalten:

Komplexes Kommando gemäß Beispiel a)

* übertragen einer gewissen Anzahl (in einem Bitfeld des Kommandos definiert) an Daten in einen vorgegebenen Adress- bereich eines Registers, Inkrementieren der Adresse,

* übertragen einer fest vorgegebenen Anzahl an Daten in einen anderen vorgegebenen Adressbereich eines Registers, Inkrementieren der Adresse,

* Schreiben einiger Bits in eine Adresse eines Regis- ters, wobei die Bitwerte durch das Kommando aus vorgegebe-

nen Bitfeldern extrahiert werden, Auffüllen der restlichen Bits mit vorgegebenen Werten,

* Schreiben einiger Bits in eine Adresse eines anderen Registers, wobei die Bitwerte durch das Kommando aus vorge- gebenen Bitfeldern extrahiert werden, Auffüllen der restlichen Bits mit vorgegebenen Werten,

* Warte auf Beendigung der vorangegangenen Sequenz (Hardware könnte gesperrt sein) .

Komplexes Kommando gemäß Beispiel b)

* Schreiben einiger Bits in eine Adresse eines Registers, wobei die Bitwerte durch das Kommando aus vorgegebenen Bitfeldern extrahiert werden, Auffüllen der restlichen Bits mit vorgegebenen Werten, * Schreiben einiger Bits in eine Adresse eines anderen

Registers, wobei die Bitwerte durch das Kommando aus vorgegebenen Bitfeldern extrahiert werden, Auffüllen der restlichen Bits mit vorgegebenen Werten,

* Warte auf Beendigung der vorangegangenen Sequenz (Hardware könnte gesperrt sein) durch Abfrage eines oder mehrerer Bits,

* Kopieren interner Daten in einen Transfer-Buffer,

* übertragen einer gewissen Anzahl (in einem Bitfeld des Kommandos definiert) an Daten in einen vorgegebenen Adress- bereich eines Registers, Inkrementieren der Adresse,

* übertragen einer fest vorgegebenen Anzahl an Daten in einen anderen vorgegebenen Adressbereich eines Registers, Inkrementieren der Adresse.

Wenn man die Erfindung aus einer übergeordneten Perspektive betrachtet, wird durch ein komplexes Kommando eine Zu- standsmaschine konfiguriert und die Abarbeitung der darin enthaltenen einfachen Kommandos durch die Zustandsmaschine ausgelöst. Das Modell eines Programmierers für ein komple- xes Kommando wäre bspw. ein "Lesebufferspeicher" (read buf-

fer) oder ein "Schreibbufferspeicher und Konfiguration" (write buffer and configuration) . Ein Beispiel für ein komplexes "Lesebufferspeicher und Status"-Kommando ist das nachfolgende, wobei zur Realisierung der gewünschten Funktionalität statt der 16 einfachen Kommandos FlxrEray_Read bzw. FlxrEray_Write im ersten Block, nur ein einziges komplexes Kommando FlxrEray_AscReadOutputBuffer im zweiten Block benötigt wird.

#if (FLXR_INTERFACE_TYPE == Blockl)

// Allokieren Daten aus dem Buffer zum Lesen

// Buffer und Header-Daten (Verwaltung) anfordern while (OuI != (FlxrEray_Read(0x0714) & 0x00008000ul) )

{

}

FlxrEray_Write(0x0710, mask_value) ; FlxrEray_Write (0x0714, cmd_value) ; while ( ( (wait_obsys != OuI) | | (view == IuI)) && ( (FlxrEray_Read(0x0714) & 0x00008000ul) != OuI))

{ r

}

// Buffer sichtbar machen while (OuI != (FlxrEray_Read(0x0714) & 0x00008000ul) ) { r

}

FlxrEray_Write(0x0710, mask_valuel) ; FlxrEray_Write(0x0714, cmd_valuel) ; while ( ( (wait_obsys != OuI) | | (view == IuI)) &&

( (FlxrEray_Read(0x0714) & 0x00008000ul) != OuI)) { }

FlxrEray_ReceivedFrames [msgBudIdx_u32] .headerSection. headerSectionl.valHDRl = FlxrEray_Read (RDHSl );

FlxrEray_ReceivedFrames [msgBudIdx_u32] .headerSection. headerSection2.valHDR2 = FlxrEray_Read(RDHS2) ; FlxrEray_ReceivedFrames [msgBudIdx_u32] .headerSection. headerSection3.valHDR3 = FlxrEray_Read(RDHS3) ;

FlxrEray_ReceivedFrames [msgBudIdx_u32] . reg_MBS .MBS_u32

= FlxrEray_Read (MBS) ; // Falls Frame verloren oder fehlerhaft, Daten nicht kopieren

// Nutzdaten:

FlxrEray_ReceivedFrames [msgBudIdx_u32] .Data[0]

= FlxrEray_Read (RDDSl );

FlxrEray_ReceivedFrames [msgBudIdx_u32] .Data[l] = FlxrEray_Read(RDDS2) ;

FlxrEray_ReceivedFrames [msgBudIdx_u32] .Data [2]

= FlxrEray_Read(RDDS3) ;

FlxrEray_ReceivedFrames [msgBudIdx_u32] .Data [3]

= FlxrEray Read (RDDS4 );

#elif (FLXR_INTERFACE_TYPE == Block2)

FlxrEray_AscReadOutputBuffer (messageTable [msgBudIdx_u32] . index_u8, &FlxrEray_ReceivedFrames [msgBudIdx_u32] .Data[0], 4ul) ;

#endif

Für die Abarbeitung der einzelnen einfachen Kommandos sind insgesamt 16 Zugriffe erforderlich, wohingegen zur Abarbeitung des einen komplexen Kommandos lediglich ein Zugriff erforderlich ist. Die komplexen Kommandos entsprechen ge- wissermaßen einer Art Funktion, wobei im Rahmen der Funktion nicht einfach nacheinander alle einzelnen einfachen Kommandos ausgeführt werden. Vielmehr wird die Abarbeitung der einzelnen einfachen Kommandos unter Heranziehung von (praktisch ermitteltem oder theoretischem) Wissen über die Se- quenz derart optimiert und die optimierte Fassung als komplexes Kommando abgelegt, dass Aufruf und Abarbeitung des komplexen Kommandos weniger Ressourcen (Rechenleistung und Speicherplatz) der Host-CPU und weniger Zeit benötigen als der Aufruf und die sequenzielle Abarbeitung aller einzelnen einfachen Kommandos.

Ein Beispiel für ein komplexes "Schreibbufferspeicher und Status"-Kommando ist das nachfolgende, wobei zur Realisierung der gewünschten Funktionalität statt der zwölf einfa- chen Kommandos FlxrEray_Read bzw. FlxrEray_Write im ersten Block, nur ein einziges komplexes Kommando FlxrE- ray_AscWriteInputBuffer im zweiten Block benötigt wird.

#if (FLXR_INTERFACE_TYPE == MLI) // übertragen Eingangspufferregister in Botschaftsspeicher FlxrEray_Write (WRHSl , FlxrE- ray_TransmitFrames [i_u32] .headerSection.headerSectionl .valH DRl ) ;

FlxrEray_Write(WRHS2, FlxrE- ray_TransmitFrames [i_u32] .headerSection.headerSection2.valH

DR2); FlxrEray_Write(WRHS3, FlxrE- ray_TransmitFrames [i_u32 ] . headerSection . headerSection3. valH DR3) ;

// Nur zur übertragung der Dummy-Nutzdaten if (IuI == cfg)

{

// Schreibe Dummy-Daten Bereich FlxrEray_Write (WRDSl, FlxrE- ray_TransmitFrames [i_u32] . Data[0] ) ; FlxrEray_Write(WRDS2, FlxrE- ray_TransmitFrames [i_u32] . Data[l] ) ;

FlxrEray_Write(WRDS3, FlxrE- ray_TransmitFrames [i_u32] .Data [2] ) ; FlxrEray_Write (WRDS4, FlxrE- ray TransmitFrames [i u32] . Data [3] ) ; } -

// Warte immer bis IBSYH (Host Buffer) = ¹ O', weil das IBCR ein neues Kommando nicht annehmen kann, so lange es '1' ist while (OuI != (FlxrEray_Read (IBCR) & 0x00008000ul) ) {

}

// Setze die Kommando-Maske FlxrEray Write (IBCM, value) ;

// Programmiere den Ziel-Botschaftsspeicher und starte übertragung FlxrEray_Write(IBCR, ibrh & Ox3Ful) ; // Warte auf IBSYH (Host), falls erforderlich while ( (wait_ibsyh != OuI) && ( (FlxrEray_Read(IBCR) &

0x00008000ul) != OuI) ) { }

// Warte auf IBSYS (Schattenspeicher) , falls erforderlich while ( (wait_ibsys != OuI) && ( (FlxrEray_Read(IBCR) &

0x80000000ul) != OuI) ) { r

}

#elif (FLXR_INTERFACE_TYPE == ASC) FlxrEray_AscWriteInputBuffer (bufferlndex,

&FlxrEray_TransmitFrames [i_u32] . Data[0] , 4ul) ; #endif

Für die Abarbeitung der einzelnen einfachen Kommandos sind insgesamt 12 Zugriffe erforderlich, wohingegen zur Abarbeitung des einen komplexen Kommandos lediglich ein Zugriff erforderlich ist. Auch bei diesem Beispiel wird die Abarbeitung der einzelnen einfachen Kommandos derart optimiert, dass Aufruf und Abarbeitung des komplexen Kommandos weniger Ressourcen (Rechenleistung und Speicherplatz) der Host-CPU und weniger Zeit benötigen als der Aufruf und die sequen- zielle Abarbeitung aller einzelnen einfachen Kommandos.

Durch das auf den speziellen Anwendungsfall FlexRay zugeschnittene Protokoll ist es möglich, sehr effizient auf die Sende- und Empfangsbuffer bezüglich der Hostschnittstelle 102-107-104 zuzugreifen. Der Schnittstellenbaustein, der dabei vorgesehen ist, besteht - wie bereits genannt - aus den Teilen 203 und 204. Dabei werden Ergebnisse einer detaillierten Transaktionsanalyse so eingesetzt, dass die häufigsten komplexen Aktionen auf ein einfaches Kommando, bestehend aus einigen wenigen Komponenten abgebildet wer- den.

Weiterhin kann das Kommando durch einen CRC bzw. Parity so abgesichert werden, dass eine Verfälschung von Lese- in Schreibzugriff bzw. der Adresse mit großer Wahrscheinlich- keit noch vor der Ausführung des Kommandos entdeckt und eine fehlerhafte Ausführung oder eine Fehlerfortpflanzung damit verhindert wird.

Dabei ergeben sich nun diverse Vorteile:

Zum einen wird der Zugriff schneller, weil das vorliegende Protokoll das Wissen über die Anordnung der Daten, die Art der Zugriffe und die entsprechenden Adressen in Form eines weiteren Zustandsautomaten, der fest verdrahtet wird auf- weist, so dass Anordnung der Daten, die Art der Zugriffe und/oder die entsprechenden Adressen automatisch bereitgestellt werden können, so dass diese nicht mehr vom Host geliefert und damit nicht mehr über Schnittstelle 107 bzw. detailliert über Verbindung 216 bis 218 übertragen werden müssen.

Des weiteren kann auch die Zugriffsart (Lesen/Schreiben) schon fest in diese Vorrichtung ein-gebaut werden, wie bereits erwähnt, muss also ebenfalls nicht mehr übertragen werden.

Anstelle dessen werden diese fest vorgegebenen Sequenzen bezüglich der genannten Informationen (Datenanordnung, Zugriffsart, und/oder Adressen) nur noch abgerufen und mit zusätzlichen Werten ausgestattet.

Um nun eine solche vorgegebene Sequenz abzurufen, wird das Protokoll mit folgendem Bestandteil erfindungsgemäß erweitert: Dazu wird ein Wert für die Art der Sequenz, die abgerufen wird, eingeführt, der beispielhaft "Access Type Marker, ATM" genannt wird und den Zugriffstyp beschreibt, der nachfolgend noch beschrieben wird.

Das vorliegende Protokoll verwendet weiterhin Information zur Absicherung der Daten z.B. einen CRC bzw. eine Parity, wobei diese Absicherungsinformation mindestens über den Kommandoteil (z. B. die ersten 3 Byte) gebildet wird, um sicherzustellen, dass eine eventueller übertragungsfehler nicht zu einer Adressverfälschung oder einer änderung der Zugriffsart (Lesen/Schreiben) führt. Verfälschungen im Datenbereich lassen sich bei Bedarf durch Rücklesen erkennen; das ist für Adressen bzw. die Zugriffsart oder den "Access Type Marker" nicht möglich. Diese Absicherung z.B. als ein CRC oder eine Parity kann weiterhin auch über den ersten Teil der Sequenz, also das Kommando (z. B. 6 Bit CRC) erfolgen.

Beispiele für einen Sequenzteil mit beispielhafter Angabe der Bitanzahl

Folgende Eigenschaften sind beispielhaft für das Protokoll dieser Schnittstelle, genannt Customer CPU Interface (PROTOKOLL) : * Halbduplex 8-bit Synchroner Betrieb

* 9,38 MBaud, Synchronisation, keine Paritätsprüfung

* Bus Takt Frequenz (BCLK) 32 MHz

* Eine Interrupt-Anforderungsleitung

* CRC über das Kommandowort * Prüfung der Byte Synchronisation

* Wiederherstellung der Synchronisation durch den Host

* Asynchroner Reset

Das hier beschriebene Protokoll kann z.B. für eine serielle Schnittstelle serielle Sende- und Empfangsdaten in 32 Bit Lese- und Schreibzugriffe umwandeln, die über Synchrone Transaktionen auf die internen Register des Customer CPU Interface (CIF) , das RAM des Kommunikationsbaustein-Kerns (des sog. Cores) und dessen Register in einem z.B. 11-oder 12-Bit Adressraum lesen oder schreiben.

Figur 13 zeigt eine vereinfachte Struktur des ASC Customer CPU Interface 204 zum Senden und Empfangen bestimmter vorgebbarer Kommandos zur Realisierung der Datenübertragung zwischen der Kommunikationsverbindung 101 und dem Teilnehmer 102. Der Empfang erfolgt in einer Empfangseinheit 800 durch ein Schieberegister 802 bei der steigenden Flanke eines TXD-Taktsignals 804. Nach 8 Taktzyklen wird das Ergebnis in ein Register rx_hold 806 übernommen und ein rdy- Signal gesetzt, um der Zustandsmaschine 808 mitzuteilen, dass in dem rx_hold-Register 806 eine neue Botschaft enthalten ist. Der Test auf Byte Synchronisation (byte sync

check) in Funktionsblock 818 erfolgt ebenfalls zu diesem Zeitpunkt .

Eine Sendeeinheit 810 legt Bit ^f 0 ^f aus seinem Shift- Register 811 an eine RXD-Leitung 814, sofern die Sendeeinheit 810 aktiv ist. Mit jeder fallenden Flanke des TXD- Taktsignals 804 werden die Empfangsdaten in das Schieberegister 812 übernommen und die Daten in dem Register 812 um ein Feld weiter verschoben (ein sog. Shift ausgeführt) . Nach 8 Takten wird das rdy-Signal gesetzt und die Zustands- maschine 808 kann neue Daten aus einem tx_hold-Register 816 in das Schieberegister 812 laden.

Der Adressdekoder in Funktionsblock 820 unterscheidet zwi- sehen einem internen CIF-Register 822 und einem externen Speicher des Kommunikationsbausteins 100. Die Zustandsma- schine 808 liest zunächst 3 Bytes des Kommandos, bevor sie mit der Auswertung des Kommandos beginnt. Die Bits des CRC werden in einem Block 826 überprüft. Abhängig von dem Kom- mando wird ein Schreib- oder Lesevorgang, ein Adress-

Zugriff oder ein einfacher Buffer Zugriff ausgelöst. In einem Funktionsblock "end stuff" 824 wird das Ende eines Zugriffs des Kommunikationsbaustein-Cores erkannt, welcher das ASC-Kommando blockiert, und dann ein letztes Füllbyte != 0x00 zurückgeliefert. Im Fehlerfall (CRC 826 oder Byte

Synchronisation 818) geht die Zustandsmaschine 808 in einen Reset Zustand (resync) 828, löst optional einen Interrupt Request (IRQ) 830 aus und wartet auf die Neusynchronisation (resync) 828 durch die Host-CPU 102.

Das Zustandsdiagramm in Figur 14 zeigt vereinfacht die möglichen übergänge:

Die Zustandsmaschine 808 befindet sich nach dem Reset im IDLE Zustand. Falls ein Sendefehler erkannt wird (Byte Syn-

chronisationsfehler (Byte Sync Error) oder CRC Fehler (CRC Error) ) , so wird die Zustandmaschine 808 in den PRE_RESYNC Zustand gezwungen.

Die vereinfachten Aktionen in den jeweiligen Zuständen sind:

* IDLE Starte Empfänger, beende laufenden Zugriff des Kommunikationsbaustein-Cores, Lösche alle Zähler, etc.

* PRE_RESYNC Empfänger und Sender abschalten, Lokale Sig- nale und Zustände löschen bzw. zurücksetzen

* RESYNC_GAP Warten auf das Ende der Neusynchronisation durch den Host

* CMDl Warten auf den Empfang des ersten Bytes des Kommandowortes * CMD2 Warten auf den Empfang des zweiten Bytes des Kommandowortes

* CMD3 Warten auf den Empfang des letzten Bytes des Kommandowortes. Prüfe CRC. atm, rw, Buffer_id, addr, word_cnt und Nutzdaten (payload) werden ausgewertet. Abhän- gig von atm und rw wird der Rücksetz-Zustand (return State) gesetzt und die Füllbytes werden gestartet oder das erste Wort wird aus dem Kommunikationsbaustein-Core ausgelesen

* STUFF Sende 0x00 zum Host. Wiederhole das solange eray obusy high ist. (Anmerkung: E-Ray ist die interne Be- Zeichnung des Kommunikationsbausteins 100 durch die Anmelderin)

* LOAD Beende den laufenden Lesezugriff aus dem Kommunikationsbaustein-Core. Aktiviere Sender 810.

* DAV Daten sind verfügbar, Kopiere das erste Byte in das tx hold-Register 816. Erhöhe addr.

* READl Kopiere das zweite Byte in das tx_hold- Register 816.

* READ2 Kopiere das dritte Byte in das tx_hold- Register 816.

* READ3 Kopiere das letzte Byte in das tx_hold- Register 816.

* READ4 Verringere word_cnt falls > 0

* SBAR Lesen eines einzelnen Buffers (Single Buffer Access Read) . Setze die Adresse (addr) auf 0x700 (Header) .

* WRITE 1 Beende den laufenden Schreibzugriff auf den Kommunikationsbaustein-Core . Kopiere der erste Byte aus dem Register rx_hold_yy.

* WRITE2 Kopiere der zweite Byte aus rx_holdyy. * WRITE3 Kopiere der dritte Byte aus rx_hold_yy.

* WRITE4 Kopiere der letzte Byte aus rx_hold_yy. Schreibe das Wort in den Kommunikationsbaustein-Core. Erhöhe die Adresse (addr) , verringere Wortzähler (word_cnt) falls > 0 oder aktiviere IBCM/IBCR Zugriffe und schalte Empfänger 800 ein.

* SBAW Beende laufenden Schreibzugriff auf Kommunikationsbaustein-Core. Setze die Adresse (addr) auf 0x0500 (Header) .

Falls ein Buffer-Lesezugriff auf einen Einzelbuffer (Single Buffer Access Read) erfolgt, müssen drei Kommunikationsbaustein-Core Zugriffe erfolgt sein, während Füllbytes ( ^f 0 ^f ) zum Host gesendet werden. Nach einem Buffer-Schreibzugriff (Single Buffer Access Write)auf einen Einzelbuffer muss die ASC-Schnittstelle zwei Core-Zugriffe ausführen.

Figur 15 zeigt die Zustandsmaschine 808 für die Kommunikationsbaustein-Core Zugriffe (Single Buffer Access Read, Write) .

Um die Gültigkeit der Kommandos zu prüfen, wird das Kommandowort mittels eines 6 Bit CRC (Cyclic Redundancy Check) überprüft. Das Kommandowort ist 24 Bit lang und besteht aus 18 Bits Kommando und 6 Bit CRC * D [17:0] Daten des Kommandowortes

* CRC [5:0] CRC des Kommandowortes

Für den CRC wird bspw. folgendes mit 0 initialisierte Polynom verwendet: x ⁶ +x ⁵ +x ⁴ +x+l .

Eine parallele Implementierung wird verwendet und führt zu folgenden Gleichungen:

CRCO = D17 ^A D15 ^A D14 ^A D13 ^A D9 ^A D8 ^A D5 ^A D4 ^A D3 ^A D1 ^A DO; CRCl = D17 ^A D16 ^A D13 ^A D1O ^A D8 ^A D6 ^A D3 ^A D2 ^A DO; CRC2 = D17 ^A D14 ^A D11 ^A D9 ^A D7 ^A D4 ^A D3 ^A D1; CRC3 = D15 ^A D12 ^A D1O ^A D8 ^A D5 ^A D4 ^A D2; CRC4 = D17 ^A D16 ^A D15 ^A D14 ^A D11 ^A D8 ^A D6 ^A D4 ^A D1 ^A DO; CRC5 = D16 ^A D14 ^A D13 ^A D12 ^A D8 ^A D7 ^A D4 ^A D3 ^A D2 ^A DO;

Adresszugriff

* atm[l:0] Zugriffstype (Access Type Marker) "00"

* rw Lese- ( ^f l ^f ) oder Schreibzugriff ( ^f 0 ^f ) * addr[8:0] Startadresse, beginnt an einer 32 Bit Wortgrenze, 2 Kilobyte Adressraum

* word cnt[5:0] Anzahl der zu transferierenden Worte-1

* CRC [5:0] CRC über das Kommandowort

Falls rw = ^f 0 ^f ist, wartet das Protokoll auf 4* (word_cnt + 1) Bytes, um diese beginnend mit der Adresse (addr) als 32 Bit Worte in den Kommunikationsbaustein-Core zu schreiben. Falls rw = ^f l ^f ist, liest die ASC-Schnittstelle das erste 32-bit Wort aus dem Kommunikationsbaustein-Core von der Adresse (addr) . Das dauert länger als die normale Verzögerung eines Sendezyklus zwischen den Bytes. Daher muss der Host das Umschalten der Richtung der RxD-Leitung (von Senden auf Empfangen) um mindestens 2 TxD-Zyklen verzögern. Alle folgenden Bytes werden ganz normal übertragen. Die ASC-Schnittstelle sendet 4* (word_cnt + 1) Bytes an die

Host-CPU. Nach Beendigung der übertragung wartet die ASC- Schnittstelle auf das nächste Kommando.

Wie oben erwähnt werden nun beispielhaft Zugriffstypen be- schrieben:

Einzelbufferzugriff (Single Buffer Access)

Falls die Host-CPU über das Protokoll von der ASC- Schnittstelle lesen will, muss die ASC-Schnittstelle den entsprechenden Buffer von dem Kommunikationsbaustein-Core anfordern. Die Antwort auf diese Anforderung dauert einige Zeit und ist nicht zu einem bestimmten Zeitpunkt fertig. Der Zeitpunkt hängt von der momentanen Auslastung des Kom- munikationsbaustein-Core ab. Um dem Host anzuzeigen, dass die Daten noch nicht zum Transfer bereit stehen, sendet die ASC-Schnittstelle Füllbytes (0x00) während sie auf die Daten wartet. Sobald die Daten bereitstehen, sendet die ASC- Schnittstelle das letzte Füllbyte != 0x00. Das nächste Byte ist dann schon das niederwertigste Byte des zu übertragenden ersten Datenwortes .

Nur Header

* atm[l:0] Zugriffstype (Access Type Marker) "10"

* rw Lese- ( ^f l ^f ) oder Schreibzugriff ( ^f 0 ^f )

* Buffer_ID [5 : 0] Start Adresse an einer 32-bit Wortgrenze, 2 KByte Adressraum

* stxrh Falls der Buffer geschrieben wird, setze Transmission Request Host (STXRH) im IBCM

* rsv reserviert, all ^f 0 ^f

* CRC [5:0] CRC über das Kommandowort

Falls rw = ^f 0 ^f ist, wartet das Protokoll der ASC- Schnittstelle auf 4*4 (header) Bytes, um diese beginnend mit

der Adresse 0x0500 (Header Input Buffer) als 32 Bit Worte in den Kommunikationsbaustein-Core zu schreiben. Nach dem letzten Schreibzugriff erfolgen folgende Aktionen durch das Protokoll :

1. Schreiben atm (LHSH) und stxrh auf Adresse 0x0510 (IBCM)

2. Schreiben der Buffer_ID auf Adresse 0x0514 (IBCR)

Falls rw = ^f l ^f ist, fängt das Protokoll der ASC- Schnittstelle an, Füllbytes (0x00) an den Host zu senden. Die ASC-Schnittstelle benötigt diese Zeit, um den entsprechenden Header vom Kommunikationsbaustein-Core anzufordern. Während diese Füllbytes gesendet werden, erfolgen folgende Aktionen durch das Protokoll:

1. Schreiben atm (header) auf Adresse 0x0710 (OBCM)

2. Schreiben der Buffer_ID und REQ auf Adresse 0x0714 (OBCR)

3. Warten bis eray_obusy wieder low wird. Während eray obusy high ist, kopiert der Kommunikationsbaustein-Core den entsprechenden Header in den Ausgangsbuffer.

4. Schreibe VIEW auf Adresse 0x0714 (OBCR)

Nun ist der entsprechende Header im Ausgangsbuffer verfügbar. Nachdem die Füllbytes gesendet wurden, sendet das Pro- tokoll der ASC-Schnittstelle 4*4 (header) Bytes an den Host. Nachdem dieses Kommando fertig ist, wartet das Protokoll der ASC-Schnittstelle auf das nächste Kommando.

Nur Nutzdaten

* atm[l:0] Zugriffstype (Access Type Marker) "01"

* rw Lese- ( ^f l ^f ) oder Schreibzugriff ( ^f 0 ^f )

* Nutzdaten [5:0] Anzahl der 32-bit Worte+1

* Buffer ID [5:0] Start Adresse an einer 32-bit Wortgrenze, 2 KByte Adressraum

* stxrh Falls der Buffer geschrieben wird, setze Transmission Request Host (STXRH) im IBCM

* rsv reserviert, all ^f 0 ^f

* CRC [5:0] CRC über das Kommandowort

Falls rw = ^f 0 ^f ist, wartet die ASC-Schnittstelle auf 4* (Nutzdaten+1) Bytes um diese beginnend mit der Adresse 0x0400 (Input Buffer) als 32 Bit Worte in den Kommunikati- onsbaustein-Core zu schreiben. Nach dem letzten Schreib- zugriff erfolgen folgende Aktionen durch das Protokoll der ASC-Schnittstelle :

1. Schreibe atm (LDSH) und stxrh auf Adresse 0x0510 (IBCM)

2. Schreibe die Buffer_ID auf Adresse 0x0514 (IBCR)

Falls rw = ^f l ^f ist, sendet die ASC-Schnittstelle Füllbytes (0x00) an den Host. Das Protokoll der ASC-Schnittstelle benötigt diese Zeit, um die entsprechenden Nutzdaten vom Kommunikationsbaustein-Core anzufordern. Während die Füll- bytes gesendet werden, erfolgen folgende Aktionen durch das Protokoll der ASC-Schnittstelle:

1. Schreibe atm (Nutzdaten) auf Adresse 0x0710 (OBCM)

2. Schreibe die Buffer_ID und REQ auf Adresse 0x0714 (OBCR) 3. Warte bis eray_obusy wieder low wird.

Während eray obusy high ist, kopiert der Kommunikationsbaustein-Core die entsprechenden Nutzdaten in den Ausgangsbuffer. 4. Schreibe VIEW auf Adresse 0x0714 (OBCR)

Nun sind die entsprechende Nutzdaten im Ausgangsbuffer verfügbar. Nachdem die Füllbytes gesendet wurden, sendet das Protokoll 4* (Nutzdaten+1) Bytes an den Host. Nachdem dieses Kommando fertig ist, wartet das Protokoll der ASC- Schnittstelle auf das nächste Kommando.

Nutzdaten and Header

* atm[l:0] Zugriffstype (Access Type Marker) "H" * rw Lese- ( ^f l ^f ) oder Schreibzugriff (O')

* Nutzdaten [5:0] Anzahl der 32-bit Worte+1

* Buffer_ID [5 : 0] Start Adresse an einer 32-bit Wortgrenze, 2 KByte Adressraum

* stxrh Falls der Buffer geschrieben wird, setze Transmission Request Host (STXRH) im IBCM

* rsv reserviert, all '0'

* CRC [5:0] CRC über das Kommandowort

Falls rw = '0' ist, wartet das Protokoll der ASC- Schnittstelle auf 4* (Nutzdaten + 1) Bytes, um diese beginnend mit der Adresse 0x0400 (Input Buffer) als 32 Bit Worte in den Kommunikationsbaustein-Core zu schreiben, und auf 4*4 (header) Bytes, um diese beginnend mit der Adresse 0x0500 (Header) als 32 Bit Worte in den Kommunikationsbau- stein-Core zu schreiben. Nach dem letzten Schreibzugriff erfolgen folgende Aktionen durch das Protokoll:

1. Schreibe atm (LHSH, LDSH) und stxrh auf Adresse 0x0510 (IBCM) 2. Schreibe die Buffer_ID auf Adresse 0x0514 (IBCR)

Falls rw = '1' ist, sendet das Protokoll der ASC- Schnittstelle Füllbytes (0x00) an den Host. Das Protokoll benötigt diese Zeit, um die entsprechenden Nutzdaten und Header vom Kommunikationsbaustein-Core anzufordern. Während die Füllbytes gesendet werden, erfolgen folgende Aktionen durch das Protokoll:

1. Schreibe atm (Nutzdaten and Header) auf Adresse 0x0710 (OBCM)

2. Schreibe die Buffer_ID und REQ auf Adresse 0x0714 (OBCR)

3. Warte bis eray_obusy wieder low wird.

Während eray_obusy high ist, kopiert der Kommunikationsbau- stein-Core die entsprechenden Nutzdaten und Header in den Ausgangsbuffer.

4. Schreibe VIEW auf Adresse 0x0714 (OBCR)

Nun sind der entsprechende Nutzdaten und Header im Ausgangsbuffer verfügbar. Nachdem die Füllbytes gesendet wur- den, sendet das Protokoll der ASC-Schnittstelle

4* (Nutzdaten+1+4 (header) ) Bytes an den Host. Nachdem dieses Kommando fertig ist, wartet die ASC-Schnittstelle auf das nächste Kommando.

Erneute Synchronisation (Resynchronisation)

Dies ist kein Kommando, dem ein bestimmtes Kommandowort zugeordnet ist. Die Host-CPU kann die ASC-Schnittstelle in den Resynchronisationszustand zwingen, indem die RxD- Leitung für mindestens 29 TxD-Zyklen auf low gezogen wird, ohne dass die TxD-Leitung tatsächlich angesteuert werden muss. Im Normalbetrieb (Host-CPU sendet) wird die RxD- Leitung high werden, wenn jedes Byte gesendet wurde.

Die ASC-Schnittstelle wird die laufende Operation anhalten, interne Signale und Zustände löschen und auf das nächste Kommando, das von der Host-CPU zu übertragen ist, warten.