DE102021108794B3

DE102021108794B3 - Serielle datenkommunikation mit in-frame-antwort

Info

Publication number: DE102021108794B3
Application number: DE102021108794.5A
Authority: DE
Inventors: Jens Barrenscheen; Ansgar Pottbäcker
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2021-04-08
Filing date: 2021-04-08
Publication date: 2022-04-28
Anticipated expiration: 2041-04-09
Also published as: US20220327092A1; CN115203112A; US11977508B2

Abstract

Es wird ein Verfahren für einen Slave-Busknoten beschrieben. Gemäß einem Ausführungsbeispiel umfasst das Verfahren das Empfangen eines ersten Frames über einen ersten Datenkanal, wobei der erste Frame mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst. Das Verfahren umfasst weiter das Durchführen einer Funktion abhängig von den im empfangenen ersten Frame enthaltenen Header-Daten und das Generieren eines zweiten Frames, der zweite Header-Daten, zweite Payload-Daten, welche von der durchgeführten Funktion bestimmt werden, sowie eine zweite Prüfsumme umfasst. Diese wird zumindest basierend auf den zweiten Payload-Daten und auf den im empfangenen ersten Frame enthaltenen ersten Header-Daten ermittelt. Das Verfahren umfasst des Weiteren das Senden des zweiten Frames über einen zweiten Datenkanal gleichzeitig mit dem Empfangen des ersten Frames über den ersten Datenkanal. Des Weiteren werden ein korrespondierendes Verfahren für einen Master-Busknoten sowie korrespondierende Busknoten-Schaltungen beschrieben.

Description

TECHNISCHES GEBIET
Die vorliegende Beschreibung betrifft das Gebiet der frame-basierten seriellen Datenkommunikation über serielle Datenbusse wie z.B. SPI (Serial Peripheral Interface), HSSL (High Speed Serial Link), MSB (Microsecond Bus), I2C-Bus (Inter-Integrated Circuit Bus) oder dergleichen.
HINTERGRUND
Serielle Datenkommunikation kommt in einer Vielzahl von Anwendungen zum Einsatz. So können beispielsweise zwischen zwei auf einer Platine angeordneten Chips, zwischen zwei Schaltkreisen innerhalb desselben Chips oder auch zwischen zwei separaten elektronischen Steuergeräten (Electronic Control Units, ECUs) Daten mittels serieller Datenübertragung übertragen werden. Es sind verschiedenste standardisierte (teilweise auch proprietäre Standards) serielle Bussysteme bekannt. Weit verbreitet ist beispielsweise der SPI-Bus. Die Bezeichnung „Bus“ zeigt an, das mehrere Signale oder Leitungen zur Kommunikation erforderlich sind. Bei einem SPI sind das neben den Datenleitungen noch ein Schiebetaktsignal und ein Daten-Frame-Indikationssignal. Diese beiden Signale bestimmen die Datenübertragungsrate der seriell übertragenen Daten und die Länge der Daten-Frames. Bei einem SPI gibt es Varianten mit unterschiedlicher Anzahl an Datenleitungen pro Richtung. Besonders für Anwendungen mit hohen Datenraten werden oft mehrere Datenleitungen pro Richtung verwendet, z.B. 4 oder 8. Im Folgenden werden die Datenleitungen pro Richtung als Datenkanal bezeichnet, unabhängig von der Anzahl der Datenleitungen.
In vielen Anwendungen werden Daten bidirektional und gleichzeitig in beide Richtungen (Full Duplex) übertragen, wobei die Daten üblicherweise in kurzen Sequenzen übertragen werden, die als Daten-Frames (kurz Frames) bezeichnet werden. Ein Frame umfasst eine Menge von Datenbits oder Symbole, wobei die Datenbits bzw. Symbole verschiedene Bedeutung haben können. So kann beispielsweise eine Gruppe (oft als „Feld“ bezeichnet) von Datenbits/Symbole eines Frames eine Kennung (Identifier) darstellen. Eine Kennung kann unter anderem den Absender und/oder das Ziel der Datenübertragung identifizieren. Insbesondere kann die Kennung eine Adresse darstellen, an die Daten geschrieben oder von der Daten gelesen werden sollen. Des Weiteren kann die Kennung ein bestimmtes Kommando enthalten, das festlegt, was mit den zu übertragenen Daten passieren soll (z.B. Lesen oder Schreiben). Ein anderes Feld eines Frames kann z.B. Datenbits/Symbole enthalten, welche die zu schreibenden Daten oder die ausgelesenen Daten repräsentiert. Ein weiteres Feld kann schließlich eine Prüfsumme enthalten, welche eine Fehlererkennung (und ggf. eine Fehlerkorrektur) erlaubt. Die Prüfsumme kann z.B. mittels Zyklischer Redundanzprüfung (Cyclic Redundancy Check, CRC) berechnet werden. Jedoch sind auch andere Methoden bekannt wie z.B. fehlerkorrigierende Codes (Error Correcting Codes, ECC) oder dergleichen.
Bei der Verwendung von Prüfsummen kann die Integrität eines Frames erst dann überprüft werden, wenn der Frame (inklusive dem Prüfsummen-Feld) vollständig empfangen wurde, was bei bekannten Systemen, die In-Frame-Antworten (In-Frame Response, IFR) verwenden, zu Problemen führen kann, weil ein empfangener Frame und der Frame, der eine Antwort auf den empfangenen Frame enthält, in demselben Zeitintervall übertragen werden. In-Frame-Antworten im Zusammenhang einer Datenkommunikation mittels SPI sind an sich bekannt. So beschreibt beispielsweise die Publikation US 20160098371 A1 eine SPI Dasiy-Chain-Kommunikation mit IFRs. Die Publikation US 20090271532 A1 beschreibt die die Absicherung eines Headers eines Datenpakets mittels CRC. Die Erfinder haben sich die Aufgabe gestellt, bekannte Konzepte zur seriellen Datenübertragung mit IFR zu verbessern.
ZUSAMMENFASSUNG
Die genannte Aufgabe wird durch das Verfahren gemäß den Ansprüchen 1 und 12 sowie durch den Busknoten gemäß den Ansprüche 11 und 15 gelöst. Verschiedene Ausführungsformen und Weiterentwicklungen sind Gegenstand der abhängigen Ansprüche.
Gemäß einem Ausführungsbeispiel umfasst ein Verfahren für einen Slave-Busknoten das Empfangen eines ersten Frames über einen ersten Datenkanal, wobei der erste Frame mindestens erste Header-Daten (z.B. mit einer Kennung oder Teil einer Kennung), erste Payload-Daten und eine erste Prüfsumme umfasst. Das Verfahren umfasst weiter das Durchführen einer Funktion abhängig von den im empfangenen ersten Frame enthaltenen Header-Daten und das Generieren eines zweiten Frames, der zweite Header-Daten, zweite Payload-Daten, welche von der durchgeführten Funktion bestimmt werden können, sowie eine zweite Prüfsumme umfasst. Diese wird zumindest basierend auf den zweiten Payload-Daten und auf den im empfangenen ersten Frame enthaltenen ersten Header-Daten ermittelt. Das Verfahren umfasst des Weiteren das Senden des zweiten Frames über einen zweiten Datenkanal gleichzeitig mit dem Empfangen des ersten Frames über die erste Datenleitung.
Gemäß einem weiteren Ausführungsbeispiel umfasst ein Verfahren für einen Master-Busknoten das Generieren eines ersten Frames, der mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst, sowie das Senden des ersten Frames über einen ersten Datenkanal, und - gleichzeitig mit dem Senden des ersten Frames - das Empfangen eines zweiten Frames, der zweite Header-Daten, zweite Payload-Daten sowie eine zweite Prüfsumme umfasst. Das Verfahren umfasst weiter das Validieren der zweiten Prüfsumme basierend auf den zweiten Payload-Daten und weiter basierend auf den im generierten ersten Frame enthaltenen ersten Header-Daten.
Ein weiteres Ausführungsbeispiel betrifft einen Busknoten (eine elektronische Schaltung für einen Busknoten). Demnach weist der Busknoten eine Sende- und Empfangseinrichtung auf, die dazu ausgebildet ist, einen ersten Frames über einen ersten Datenkanal zu empfangen, wobei der erste Frame mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst. Der Busknoten weist des Weiteren eine Steuerlogik auf, die dazu ausgebildet ist, eine Funktion abhängig von der im empfangenen ersten Frame enthaltenen ersten Header-Daten durchzuführen. Ein Frame-Encoder des Busknotens ist dazu ausgebildet, einen zweiten Frame zu generieren, der zweite Header-Daten, zweite Payload-Daten, welche von der durchgeführten Funktion bestimmt werden können, sowie eine zweite Prüfsumme umfasst. Der Frame-Encoder ist weiter dazu ausgebildet, die zweite Prüfsumme basierend auf den zweiten Payload-Daten und weiter basierend auf der im empfangenen ersten Frame enthaltenen ersten Header-Daten zu ermitteln. Die Sende- und Empfangseinrichtung ist weiter dazu ausgebildet ist, den zweiten Frame über einen zweiten Datenkanal gleichzeitig mit dem Empfang des ersten Frames zu senden.
Figurenliste
Nachfolgend werden Ausführungsbeispiele anhand von Abbildungen näher erläutert. Die Darstellungen sind nicht zwangsläufig maßstabsgetreu und die Ausführungsbeispiele sind nicht nur auf die dargestellten Aspekte beschränkt. Vielmehr wird Wert darauf gelegt, die den Ausführungsbeispielen zugrunde liegenden Prinzipien darzustellen. Zu den Abbildungen:

1 illustriert ein Beispiel eines Systems mit zwei Busknoten, die über einen SPI-Bus verbunden sind.
2 illustriert schematisch die framebasierte Full-Duplex-Buskommunikation über einen seriellen Bus.
3 illustriert schematisch das Konzept der In-Frame-Antwort (In-Frame Response, IFR) bei der framebasierten seriellen Buskommunikation.
4 illustriert ein Beispiel eines in einem Slave-Busknoten durchgeführten Verfahrens zur Sicherung der Antwort-Frames mittels Prüfsummen bei Verwendung von In-Frame-Antworten.
5 illustriert ein Beispiel eines in einem Master-Busknoten durchgeführten Verfahrens zur Prüfen der in einem Antwort-Frames enthaltenen Prüfsumme bei Verwendung von In-Frame-Antworten.
6 ist ein Flussdiagramm zur exemplarischen Illustration eines Verfahrens für einen Slave-Busknoten.
7 ist ein Flussdiagramm zur exemplarischen Illustration eines Verfahrens für einen Master-Busknoten.

DETAILLIERTE BESCHREIBUNG
1 illustriert ein Beispiel eines Systems mit zwei Busknoten, die über einen SPI-Bus verbunden sind. Die hier beschriebenen Ausführungsbeispiele sind jedoch nicht auf einen SPI-Bus beschränkt, sondern die im folgenden Beschriebenen Konzepte können auch auf beliebige andere serielle Busssysteme wie z.B. HSSL (High Speed Serial Link), MSB (Microsecond Bus), I2C-Bus (Inter-Integrated Circuit Bus) oder dergleichen angewendet werden.
Der in 1 gezeigte Busknoten 10 wird im Folgenden als Controller oder als Master-Busknoten bezeichnet, der die Buskommunikation kontrolliert. Der Busknoten 10 kann beispielsweise ein Mikrocontroller mit einem SPI-Interface 11 und mindestens einem Prozessor 12 sein, der dazu ausgebildet ist, in einem Speicher enthaltene Softwareinstruktionen auszuführen, um die hier beschriebenen Konzepte, Funktionen und Verfahrensschritte umzusetzen. Programmierbare Mikrocontroller mit SPI-Interface sind an sich bekannt und werden daher hier nicht detaillierter beschrieben. Es versteht sich jedoch, dass der Busknoten 10 nicht notwendigerweise einen Prozessor zum Ausführen von Software-Instruktionen aufweisen muss. Zusätzlich oder stattdessen kann auch eine festverdrahtete oder einmal-programmierbare (one-time programmable, OTP) Logik eingesetzt werden.
Das SPI-Interface 11 des Busknotens 10 ist mit einem korrespondierenden SPI-Interface 21 eines weiteren Busknotens 20 über mehrere Busleitungen verbunden, die im Falle eines SPI-Busses üblicherweise mit CSN (Chip Select), SCK (Serial Clock), MOSI (Master Out Slave In) und MISO (Master In Slave Out) bezeichnet sind. Die über die jeweiligen Busleitungen übertragenen Signale werden ebenfalls mit CSN, SCK, MOSI und MISO bezeichnet. Der Master-Busknoten legt die Zeitpunkte fest, zu denen Frames gesendet werden (Aktivierung von CSN) und auch die Datenübertragungsrate (Erzeugung von SCK). Zudem definiert der Master-Busknoten auch, ob Daten gelesen oder geschrieben werden (jeweils vom Master-Busknoten aus gesehen).
In einigen Anwendungen kann das Signal CSN als optional betrachtet werden und wird insbesondere dann verwendet, wenn mehrere Slave-Busknoten mit einem Master-Busknoten verbunden sind. In anderen Anwendungen ist CSN unverzichtbar, z.B. kann CSN mit in ein Safety Konzept eines Bausteins einfließen. SCK bezeichnet ein Schiebetaktsignal, das vom Master-Busknoten 10 für die Synchronisation der Datenübertragung auf den Datenkanälen MISO und MOSI ausgegeben wird. Der Datenkanal MOSI (mit mindestens einer Datenleitung) dient der Datenübertragung vom Master-Busknoten 10 zum Slave-Busknoten 20, und der Datenkanal MISO (mit ebenfalls mindestens einer Busleitung) dient der Datenübertragung in die andere Richtung. Bei einer Full-Duplex-Datenübertragung werden auf beiden Datenkanälen, MOSI und MISO, gleichzeitig und synchron zum Schiebetaktsignal SCK Daten übertragen.
Üblicherweise erfolgt die serielle Datenübertragung basierend auf Frames (MOSI-Frames von Busknoten 10 zum Busknoten 20; MISO-Frames von Busknoten 20 zum Busknoten 10). Die Struktur eines Frames wird später noch genauer erläutert. Im Busknoten werden die vom SPI-Interface 21 empfangenen Daten D_IN an einen Frame-Decoder/Encoder 22 weitergegeben. In der anderen Richtung liefert der Frame-Decoder/Encoder 22 die zu übertragenden Daten D_OUT an das SPI-Interface. Der Frame-Decoder/Encoder 22 ist dazu ausgebildet, einerseits die in einem MOSI Frame enthaltenen Daten „auszupacken“ und zu validieren und die zu sendenden Rohdaten in einem MISO Frame zu „verpacken“ und zu sichern.
Das Validieren und Sichern von in einem Frame enthaltenen Daten umfasst üblicherweise das Berechnen oder Verifizieren einer Prüfsumme (checksum). In den hier beschriebenen Ausführungsbeispielen wird zur Berechnung und Verifizierung von Prüfsummen die zyklische Redundanzprüfung (cyclic redundancy check, CRC) verwendet, wobei auch andere Algorithmen zur Ermittlung und Verifizierung von Prüfsummen möglich sind. Im einfachsten Fall besteht die Prüfsumme aus einem oder mehreren Paritäts-Bits. Verschiedene CRC-Verfahren oder CRC-Polynome und andere Methoden zum Ermitteln und Verifizieren von Prüfsummen sind an sich bekannt und werden daher hier nicht im Detail erläutert. Im Allgemeinen fügt der Frame-Decoder/Encoder 22 jenen (Roh-) Daten D_READ, die in einen (zu sendenden) Frame verpackt werden, eine Prüfsumme hinzu, und verifiziert die in einem (empfangenen) Frame enthaltene Prüfsumme, um die Integrität der empfangenen Daten (z.B. eine Adresse ADDR, D_WRITE) zu überprüfen.
Im Falle eines Schreib-Zugriffs schreibt Busknoten 10 Daten D_WRlTE an Adresse ADDR im Busknoten 20. Dafür müssen D_WRITE und ADDR in einem oder mehreren MOSI-Frames übertragen werden. Im Falle eines Lese-Zugriffs liest Busknoten 10 Daten D_READ von einer Adresse ADDR von Busknoten 20. Dafür müssen die Adresse ADDR in mindestens einem MOSI-Frame und die gelesenen Daten D_READ in mindestens einem MISO-Frame übertragen werden. Die Adresse ADDR kennzeichnet eine Stelle in den Modulen oder Speicherbereichen des Busknotens 20, an der Daten geschrieben oder gelesen werden können.
Die in einem MOSI-Frame im (Slave-) Buskoten 20 empfangenen Daten sind im vorliegenden Beispiel mit D_WRITE und ADDR bezeichnet und werden einer Steuerlogik 23 zugeführt. Die in einem MISO-Frame vom Busknoten 20 gesendeten Daten werden von der Steuerlogik 23 an den Frame-Decoder/Encoder 22 ausgegeben und sind in dem vorliegenden Beispiel mit D_READ bezeichnet. Der Aufbau eines Frames und die Bedeutung der darin enthaltenen Daten wird später noch detaillierter erklärt (vgl. 3). Die Steuerlogik 23 kann z.B. über einen internen Datenbus 25 auf einen Speicher 25 sowie auf ein oder mehrere Module X, Y, Z zugreifen. Ein Modul kann eine beliebige Datenquelle oder Datensenke sein. In einem einfachen Beispiel ist ein Modul ein einfacher Halbleiterschalter, der über ein bestimmtes Kommando ein- oder ausgeschaltet werden kann oder der auf Anfrage einen Wert für den über den (geschlossenen) Schalter fließenden Strom liefert. Ein Modul kann auch ein Sensor sein, der regelmäßig aktualisierte Messwerte (z.B. eine Temperatur) liefert.
2 illustriert schematisch die framebasierte Full-Duplex-Datenübertragung über einen seriellen Bus, wobei sowohl über den MOSI-Datenkanal als auch über den MISO- Datenkanal jeweils eine Sequenz von Frames übertragen werden. Die über den MOSI- Datenkanal übertragenen Frames F1 (d.h. die darin enthaltenen Daten) können in dem dargestellten Beispiel als Kommandos interpretiert werden, beispielsweise als Schreib- und Lese-kommandos (z.B. „write A“, „read B“, etc). Die über den MISO- Datenkanal übertragenen Frames F2 enthalten die Antworten auf die jeweiligen Kommandos (z.B. die von einem Register ausgelesenen Daten).
Die Frames F1 und F2 werden synchron zu einem Taktsignal (das vom Busknoten 10 erzeugt und an die SCK-Leitung ausgegeben wird) und gleichzeitig übertragen. Unter „gleichzeitig“ wird bei den hier beschriebenen Beispielen verstanden, dass die zwei Frames (vom und zum Master) sich zumindest zeitlich überlappen. In einem Ausführungsbeispiel wird in einem bestimmten Zeitintervall, in dem ein MOSI-Frame übertragen wird, gleichzeitig auch ein MISO-Frame übertragen. Insbesondere im Falle eines SPI ist die Übertragung isochron, da beide Frames (abgesehen von unvermeidbaren Laufzeit-Effekte) im Wesentlichen zum selben Zeitpunkt beginnen und enden.
In Systemen mit einer Next-frame-Response- (NFR) Struktur wird daher die Antwort auf ein in einem MOSI-Frame übertragenes Kommando erst in einem zeitlich darauffolgen MISO-Frame übertragen. Die MISO-Frames F2 eilen den korrespondierenden MOSI-Frames F1 zeitlich um mindestens eine Frame-Dauer nach. In manchen Anwendungen ist dieser Zeitversatz jedoch unerwünscht, weshalb ein Konzept entwickelt wurde, welches als In-Frame-Antwort (In-Frame Response, IFR) bekannt ist. Ein Beispiel hierfür ist in 3 dargestellt.
Wie in 3 dargestellt umfasst jeder Frame (MOSI- und MISO-Frames) mindestens ein erstes Feld mit Header-Daten, ein zweites Feld mit Payload-Daten und ein drittes Feld mit einer Prüfsumme. Der Slave-Busknoten (z.B. Busknoten 20) kann abhängig von den in einem MOSI-Frame F1 enthaltenen Daten eine bestimmte Funktion durchführen. Diese kann z.B. von den Header-Daten abhängen. Beispielsweise bezeichnen die Header-Daten eine Adresse (z.B. eine Register-Adresse) für eine Schreib- oder Leseoperation. Ein Teil der Header-Daten (in einem einfachen Fall nur ein Bit) zeigt an, ob eine Schreib- oder Leseoperation durchzuführen ist. Die Information betreffend die durchzuführende Funktion/Operation kann aber auch als Teil der Adresse betrachtet werden. Im Falle einer Schreiboperation sind die zu schreibenden Daten in dem Payload-Datenfeld des MOSI-Frames F1. Im Falle einer Lese-Operation können die Payload-Daten des MOSI-Frames F1 auch Dummy-Daten sein (z.B. eine Sequenz von Nullen). Die Prüfsumme im Prüfsummenfeld des MOSI-Frames F1 (MOSI CRC) sichert die im Header-Feld und im Payload-Feld enthaltenen Daten des MOSI Frames. Das heißt für das dargestellte Beispiel, dass die CRC-Prüfsumme (MOSI CRC) im Master-Busknoten 10 basierend auf den Header-Daten und den Payload-Daten berechnet wird.
Bei einer In-Frame-Antwort führt der Slave-Busknoten 20 die vom Master-Busknoten angeforderte Funktion (z.B. eine Leseoperation) bereits durch, sobald die Header-Daten des MOSI-Frames F1 empfangen wurde. Zu diesem Zeitpunkt ist der MOSI CRC noch nicht ausgewertet. Die Antwort (z.B. die aus einem Register an der Stelle ADDR gelesenen Daten D_READ) wird im Payload-Feld des MISO-Frames F2 geschickt, noch während der korrespondierende MOSI-Frame F1 empfangen wird. Die Header-Daten des MISO-Frames F2 können Dummy-Daten (z.B. eine Sequenz von Nullen) sein, von den aktuell empfangenen MOSI-Header-Daten abhängen oder z.B. eine Statusinformation sein, welche den aktuellen Status des Busknoten 20 anzeigen (z.B. unabhängig von der aktuell durchgeführten Operation). In einem Beispiel werden die im MOSI-Frame F1 aktuell empfangenen Header-Daten (ADDR) bitweise in das Header-Datenfeld des MISO-Frames F2 kopiert (Statusinformation gleich MOSI-Header-Daten). Die Prüfsumme im Prüfsummenfeld des MISO-Frames F2 (MISO CRC) schützt die Payload-Daten des MISO-Frames F2 und optional auch die Header-Daten des MISO-Frames F2. Das heißt für das dargestellte Beispiel, dass die CRC-Prüfsumme (MISO CRC) im Slave-Busknoten 20 (z.B. im Frame Decoder/Encoder 22) basierend auf den Payload-Daten und optional auch basierend auf den Header-Daten des MISO-Frames F2 berechnet wird.
Bereits an dem in 3 dargestellten zeitlichen Ablauf kann man erkennen, dass zu dem Zeitpunkt, zu dem der Slave-Busknoten 20 die Header-Daten (z.B. die Adresse ADDR für eine Leseoperation) des MOSI-Frames F1 empfangen hat, die angeforderte Funktion (z.B. die Leseoperation) sofort durchführen muss, noch bevor objektiv die Möglichkeit besteht, die Prüfsumme (MOSI CRC) zu verifizieren, um die vom Slave-Busknoten 20 empfangenen Daten zu validieren. Zu einem Zeitpunkt, zu dem der Frame Decoder/Encoder 22 im Slave-Busknoten 20 - möglicherweise - feststellt, dass der empfangene Frame F1 fehlerhaft ist, wurde der Frame F2 mit der Antwort bereits an den Master-Busknoten 20 zurück gesendet. Im Falle, dass die Verifizierung der Prüfsumme (MOSI CRC) fehlschlägt (z.B. durch einen Übertragungsfehler der Leseadresse ADDR), würde der Slave-Busknoten 20 erst im Nachhinein bemerken, dass die Antwort auf eine „falsch verstandene Frage“ gesendet wurde. Der Slave-Busknoten 20 kann den Master-Busknoten 10 aber erst mit dem nächsten MISO-Frame F2 über die fehlerhafte Prüfsumme informieren, was den Vorteil der In-Frame-Antwort zumindest teilweise wieder zunichtemachen würde. In den folgenden 4 und 5 wird ein neues Konzept erläutert, welches es ermöglich, dass der Master-Busknoten 10 bereits anhand jenes MISO-Frames, der die In-Frame-Antwort enthält, beurteilen kann, ob der Slave-Busknoten 20 die richtige Funktion ausgeführt hat (und die Frage „richtig verstanden“ hat).
4 illustriert das Verifizieren der im MOSI-Frame F1 enthaltenen Prüfsumme (MOSI CRC) sowie das Generieren/Berechnen der im MISO-Frame F2 zu sendenden Prüfsumme (MISO CRC) in einem Slave-Busknoten 20 (vgl.. 1). Der im Busknoten 20 enthaltene Frame-Decoder/Encoder 22 kann funktional in zwei Teile zerlegt werden, die im Folgenden als Frame-Decoder 221 und Frame-Encoder 222 bezeichnet sind. Der Frame-Decoder 221 empfängt die Daten D_IN eines empfangenen MOSI-Frames und extrahiert daraus die darin enthaltenen Header-Daten (z.B. Adresse ADDR für Schreibzugriff), Payload-Daten (z.B. das zu schreibende Datenwort D_WRITE) und Prüfsumme (MOSI-CRC). Der Frame-Decoder 221 ist weiter dazu ausgebildet, die empfangene Prüfsumme zu verifizieren. Wird ein Prüfsummen-Fehler detektiert, dann wird z.B. kein Schreibvorgang auf eine Adresse ausgeführt, aber beispielsweise ein vorbestimmter Wert in einem Fehlerregister angezeigt. Bei der Verifikation der Prüfsumme wird diese basierend auf den Header-Daten und den Payload-Daten des empfangenen MOSI-Frames F1 berechnet und mit der empfangenen Prüfsumme im Prüfsummenfeld verglichen. Bei Abweichungen zwischen der berechneten und der empfangenen Prüfsumme wird ein Fehler signalisiert. Die vollständige Prüfung und der Schreibvorgang mit (mittels CRC) abgesicherten Daten kann erst nach dem Empfang des kompletten MOSI-Frames stattfinden (z.B. nach der Deaktivierung des CSN Signals).
Im vorliegenden Beispiel wird vor dem Durchführen der Schreiboperation der Inhalt des adressierten Registers ausgelesen (Datenwort D_READ) und das gelesene Datenwort D_READ wird als In-Frame-Antwort auf das Schreib-Kommando zurück an den Busknoten 10 (Master-Knoten) geschickt. Direkt nach dem Empfang der Zieladresse ADDR im MOSI-Headerdatenfeld (noch vor der Prüfung des MOSI CRC) führt die Steuerlogik 23 eine Leseoperation an der empfangenen Adresse ADDR aus und übergibt die dort gelesenen Daten an den Frame-Encoder 222. Der Frame-Encoder 222 empfängt das Datenwort D_READ (z.B. von der Steuerlogik 23) sowie Statusinformationen und generiert daraus den zu sendenden MISO/Antwort-Frame F2, wobei die MISO Header-Daten die Statusinformation und die MISO Payload-Daten das Datenwort D_READ repräsentieren. Der Frame-Encoder 222 ist dazu ausgebildet, eine Prüfsumme basierend auf den MOSI-Header-Daten (Adresse) des gerade empfangenen MOSI-Frames F1, den MISO-Payload-Daten des gerade aktuellen MISO-Frames F2 und optional auch basierend auf den MISO-Header-Daten des gerade aktuellen MISO-Frames F2 zu berechnen. Der berechnete Prüfsummenwert MISO CRC wird in das Prüfsummenfeld des aktuellen MISO-Frames F2 geschrieben und über den Bus an den Master-Busknoten 10 übertragen. Wie bereits erwähnt, der empfangene MOSI-Frame F1 und der Antwort-Frame F2 (MISO-Frame) werden parallel im selben Time-Slot übertragen. Bei einem SPI-Interface erfolgt die Übertragung der MOSI- und MISO-Frames parallel (gesteuert durch die gemeinsamen Signals CSN und SCK). Bei anderen Übertragungs-Interfaces können MOSI und MISO Frames gegeneinander zeitversetzt übertragen werden. Sobald ein Slave-Busknoten eine Aktion auf einen nur teilweise empfangenen MOSI Frame auslöst (noch vor der Prüfung des kompletten MOSI Frames) können die hier beschriebenen Mechanismen zur Absicherung des MISO Frames angewendet werden.
Anders als bei bekannten Konzepten werden - wie in 4 schematisch dargestellt - im antwortenden Slave-Busknoten 20 bei der Berechnung der Prüfsumme zur Sicherung des MISO/Antwort-Frames F2 die im gerade empfangenen MOSI-Frame F1 enthaltenen Header-Daten berücksichtigt. Dabei verwendet der Slave-Busknoten Daten zur Erstellung der MISO-Prüfsumme, die aus den zeitgleich oder überlappend übertragenen aktuellen Frames von zwei unterschiedlichen Sendern stammen.
Der Master-Busknoten 10 empfängt mit seinem SPI-Interface 11 (siehe 1) einen MISO/Antwort-Frame F2 (vom Slave-Busknoten gesendete Daten D_OUT) und führt die Verifizierung der im empfangenen MISO/Antwort-Frame F2 enthaltenen Prüfsumme (MISO CRC) durch, basierend auf den MOSI Header-Daten (Adresse), die zuvor zur Generierung des zeitgleich oder überlappend zum MISO-Frame F2 übertragenen MOSI-Frames F1 verwendet wurden, sowie basierend auf den MSIO-Payload-Daten des gerade empfangenen MISO/Antwort-Frames F2 und optional basierend auf den MISO-Header-Daten des gerade empfangenen MISO/Antwort-Frames F2. Dies ist im unteren Teil der 5 dargestellt. Der obere Teil der 5 illustriert die Sicherung eines zu sendenden MOSI-Frames F1 im Master-Busknoten 10, wofür die Prüfsumme (MOSI CRC) basierend auf den MOSI-Header-Daten (Adresse) und auf den MOSI-Payload-Daten des betreffenden Frames auf herkömmliche Weise berechnet wird.
Der Master-Busknoten 10 kann bei der Verifizierung der Prüfsumme des empfangenen MISO/Antwort-Frames F2 bereits erkennen, ob der Slave-Busknoten 20 die MOSI Header-Daten (die z.B. die Adresse für eine Schreib- oder Leseoperation enthalten) des korrespondierenden MOSI-Frames F1 korrekt empfangen hat. Wäre das nicht der Fall, dann wären die im Slave-Busknoten 20 empfangenen Header-Daten (des MOSI-Frames F1) nicht dieselben, die im Master-Busknoten 10 für die Generierung des MOSI-Frames verwendet wurden (in diesem Fall hätte der Slave-Busknoten 20 den Master-Busknoten 10 „falsch verstanden“). Da die empfangenen MOSI-Header-Daten bei der Prüfsummenberechnung im Slave-Busknoten und die beabsichtigten MOSI-Header-Daten bei der Prüfsummen-verifizierung im Master-Busknoten berücksichtigt werden, kann der Master-Busknoten bei der Verifizierung der Prüfsumme eines empfangenen MISO/Antwort-Frames sofort erkennen, ob der Slave-Busknoten 20 die Header-Daten des korrespondierenden MOSI-Frames (und damit die Information über die auszuführende Funktion/Operation) korrekt empfangen hat.
Ein Beispiel des hier beschriebenen Konzepts wird im Folgenden anhand der Flussdiagramme in den 6 und 7 zusammengefasst. Das Flussdiagramm in 6 illustriert ein Verfahren für einen Slave-Busknoten (vgl. 1, Busknoten 20). Demnach umfasst das Verfahren das Empfangen eines ersten Frames (MOSI-Frames) über einen erste Datenkanal (MOSI-Datenkanal). Dieser MOSI-Frame enthält mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme (siehe 6, Schritt S1). Das Verfahren umfasst weiter das Durchführen einer Funktion abhängig von der im bereits empfangenen Teil des ersten Frame enthaltenen Header-Daten (siehe 6, Schritt S2) und das Generieren eines zweiten Frames (Antwort/MISO-Frame). Dieser enthält zweite Header-Daten, zweite Payload-Daten, welche von der durchgeführten Funktion (z.B. einer Lese-Operation) bestimmt werden, sowie eine zweite Prüfsumme. Diese zweite Prüfsumme wird zumindest basierend auf den zweiten Payload-Daten und auf den im gerade empfangenen MOSI-Frame enthaltenen ersten Header-Daten ermittelt (siehe 6, Schritt S3). Des Weiteren umfasst das Verfahren das Senden des MISO-Frames über einen zweiten Datenkanalgleichzeitig mit dem Empfangen des MOSI-Frames über den ersten Datenkanal (siehe 6, Schritt S4).
In die zweite Prüfsumme können zusätzlichen auch die zweiten Header-Daten mit einfließen, um den MISO-Frame vollständig durch die Prüfsumme abzusichern. Da in die Prüfsummenberechnung auch die Header-Daten des gerade empfangenen MOSI-Frames mit einfließen, kann der Master-Busknoten (vgl. 1, Busknoten 10) beim Empfang des Antwort/MISO-Frames prüfen, ob der Slave-Busknoten die Header-Daten des MOSI-Frames korrekt empfangen hat.
Der MISO-Frame wird in demselben Zeitintervall gesendet, in dem der MOSI-Frame empfangen wird (gleichzeitig, d.h. im selben Zeitintervall oder überlappend). Die Payload-Daten des MISO-Frames können daher eine In-Frame-Antwort auf den MOSI-Frame darstellen. Bei einem SPI-Interface werden der MOSI-Frame und der MISO-Frame üblicherweise synchron zu einem gemeinsamen Taktsignal empfangen bzw. gesendet. Die erwähnte vom Slave-Busknoten durchgeführte Funktion kann einen Speichzugriff umfassen, wobei die Header-Daten des MOSI-Frames die Adresse eines Speicherelements enthält, auf das bei der Durchführung der Funktion im Slave-Busknoten zugegriffen wird. Die Funktion kann insbesondere eine Lese- oder Schreiboperation sein. Im Falle einer Leseoperation können die Payload-Daten im Antwort-Frame (MISO-Frame) die gelesenen Daten sein oder von diesen abhängen. Im Falle einer Schreiboperation sind die Payload-Daten im empfangenen MOSI-Frame die in den Speicher zu schreibenden Daten oder die in den Speicher zu schreibenden Daten hängen von den Payload-Daten des empfangenen MOSI-Frames ab. Vor dem Schreibzugriff kann der (später überschriebene) Inhalt des Speichers gelesen werden und als In-Frame-Antwort an den Master-Busknoten zurückgeschickt werden. Alternativ können die Payload-Daten des Antwort-Frames auch den sendenden (Slave-) Busknoten identifizieren oder Statusinformationen beinhalten. Die zurückgesendeten Statusinformationen können auch die zuvor empfangene Adresse enthalten.
Wenn der MOSI-Frame vom Slave-Busknoten vollständig empfangen wurde kann die im MOSI-Frame enthaltene ersten Prüfsumme basierend auf den empfangenen ersten Header-Daten und den empfangenen ersten Payload-Daten validiert werden. Zu diesem Zeitpunkt ist die durch den MOSI-Frame ausgelöste Funktion bereits ausgeführt und die entsprechenden Daten als In-Frame-Antwort bereits an den Master-Busknoten vollständig zurück übertragen worden, bzw. mit deren Übertragung begonnen worden.
Das Flussdiagramm in 7 illustriert ein korrespondierendes Verfahren für einen Master-Busknoten. Das Verfahren umfasst demnach das Generieren eines ersten Frames (MOSI-Frames), der mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst (siehe 7, Schritt M1). Das Verfahren umfasst weiter das Senden des MOSI-Frames über einen ersten Datenkanal (siehe 7, Schritt M2) und - gleichzeitig mit (parallel zu) oder leicht zeitversetzt mit dem Senden des MOSI-Frames - Empfangen eines zweiten Frames (MISO-Frames), der zweite Header-Daten, zweite Payload-Daten sowie eine zweite Prüfsumme umfasst (siehe 8, Schritt M3). Des Weiteren umfasst das Verfahren das Validieren der zweiten Prüfsumme im Master-Busknoten basierend auf den zweiten Payload-Daten und weiter basierend auf den im zuvor generierten MOSI-Frame enthaltenen ersten Header-Daten (zur Übertragung beabsichtigte Daten). In einem Ausführungsbeispiel können bei der Validierung der zweiten Prüfsumme auch die zweiten Header-Daten berücksichtigt werden (sofern diese auch im Slave-Busknoten berücksichtigt werden).

Claims

Ein Verfahren, das folgendes aufweist: Empfangen eines ersten Frames (F1) über einen ersten Datenkanal, wobei der erste Frame (F1) mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst; und Durchführen einer Funktion abhängig von der im empfangenen ersten Frame (F1) enthaltenen Header-Daten; Generieren eines zweiten Frames (F2), der zweite Header-Daten, zweite Payload-Daten, welche von der durchgeführten Funktion bestimmt werden, sowie eine zweite Prüfsumme umfasst, welche zumindest basierend auf den zweiten Payload-Daten und auf den im aktuell empfangenen ersten Frame (F1) enthaltenen ersten Header-Daten ermittelt wird; und Senden des zweiten Frames (F2) über einen zweiten Datenkanal gleichzeitig mit dem Empfangen des ersten Frames (F1) über den ersten Datenkanal.
Das Verfahren gemäß Anspruch 1, wobei der zweite Frame (F2) in demselben Zeitintervall gesendet wird, in dem der erste Frame (F1) empfangen wird.
Das Verfahren gemäß Anspruch 1 oder 2, wobei der erste Frame (F1) und der zweite Frame (F2) synchron zu einem Taktsignal empfangen bzw. gesendet werden.
Das Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die ersten Header-Daten eine Adresse eines Speicherelements enthält, und die Funktion auf den durch die Adresse bezeichneten Teil des Speichers angewandt wird.
Das Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die ersten Header-Daten eine Adresse eines Speichers beinhalten, und die Funktion das Lesen von Daten aus dem durch die Adresse bezeichneten Speicherelement umfasst, und wobei die zweiten Payload-Daten von den gelesenen Daten abhängen.
Das Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die ersten Header-Daten eine Adresse eines Speichers enthält, und die Funktion das Schreiben von Daten in das durch die Adresse bezeichnete Speicherelement umfasst, und wobei die geschriebenen Daten die ersten Payload-Daten sind oder von diesen abhängen.
Das Verfahren gemäß Anspruch 6, wobei vor dem Schreiben der Daten, die in dem durch die Adresse bezeichneten Teil des Speichers gespeicherten Daten gelesen werden, und wobei die zweiten Payload-Daten die gelesenen Daten sind oder von diesen abhängen.
Das Verfahren gemäß einem der Ansprüche 1 bis 7, wobei die zweite Payload-Daten den Sender des zweiten Frames identifiziert und/oder Statusinformationen umfasst.
Das Verfahren gemäß einem der Ansprüche 1 bis 8, das weiter aufweist: Validieren der ersten Prüfsumme basierend auf den empfangenen ersten Header-Daten und den empfangenen ersten Payload-Daten.
Das Verfahren gemäß einem der Ansprüche 1 bis 9, wobei die im zweiten Frame (F2) enthaltene zweite Prüfsumme basierend auf den zweiten Header-Daten, den zweiten Payload-Daten und basierend auf den im empfangenen ersten Frame (F1) enthaltenen ersten Header-Daten ermittelt wird.
Das Verfahren gemäß einem der Ansprüche 1 bis 10, wobei die zweiten Header-Daten von den ersten Header-Daten abhängen.
Ein Busknoten, der aufweist: eine Sende- und Empfangseinrichtung (21), die dazu ausgebildet ist, einen ersten Frame (F1) über eine ersten Datenkanal zu empfangen, wobei der erste Frame (F1) mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst; eine Steuerlogik (23), die dazu ausgebildet ist, eine Funktion abhängig von der im aktuell empfangenen ersten Frame (F1) enthaltenen ersten Header-Daten durchzuführen; und einen Frame-Encoder (222), der dazu ausgebildet ist, einen zweiten Frame (F2) zu generieren, der zweite Header-Daten, zweite Payload-Daten, welche von der durchgeführten Funktion bestimmt werden, sowie eine zweite Prüfsumme umfasst, wobei der Frame-Encoder (222) weiter dazu ausgebildet ist, die zweite Prüfsumme basierend auf, den zweiten Payload-Daten und weiter basierend auf den im empfangenen ersten Frame (F1) enthaltenen ersten Header-Daten zu ermitteln; und wobei die Sende- und Empfangseinrichtung (21) weiter dazu ausgebildet ist, den zweiten Frame (F2) über einen zweiten Datenkanal gleichzeitig mit dem Empfang des ersten Frames (F1) über den ersten Datenkanal zu senden.
Ein Verfahren, das folgendes aufweist: Generieren eines ersten Frames (F1), der mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst; Senden des ersten Frames (F1) über einen erste Datenkanal, und gleichzeitig mit dem Senden des ersten Frames (F1): Empfangen eines zweiten Frames (F2), der zweite Header-Daten, zweite Payload-Daten sowie eine zweite Prüfsumme umfasst; und Validieren der zweiten Prüfsumme basierend auf den zweiten Payload-Daten und weiter basierend auf den im generierten ersten Frame (F1) enthaltenen ersten Header-Daten.
Das Verfahren gemäß Anspruch 13, wobei die zweite Prüfsumme basierend auf den zweiten Header-Daten, den zweiten Payload-Daten und weiter basierend auf den für den generierten ersten Frame (F1) generierten ersten Header-Daten validiert wird.
Ein Busknoten, der aufweist: eine Sende- und Empfangseinrichtung, die dazu ausgebildet ist, einen ersten Frame (F1) über einen ersten Datenkanal zu senden, wobei der erste Frame (F1) mindestens erste Header-Daten, erste Payload-Daten und eine erste Prüfsumme umfasst, und die dazu ausgebildet ist, über einen zweiten Datenkanal einen zweiten Frame (F2) zu empfangen, der zweite Payload-Daten, sowie eine zweite Prüfsumme umfasst; einen Frame-Decoder (222), der dazu ausgebildet ist, die zweite Prüfsumme basierend auf den zweiten Payload-Daten und weiter basierend auf den im ersten Frame (F1) enthaltenen ersten Header-Daten zu überprüfen; und wobei die Sende- und Empfangseinrichtung (21) weiter dazu ausgebildet ist, den zweiten Frame (F2) über einen zweiten Datenkanal gleichzeitig mit dem Senden des ersten Frames (F1) über den ersten Datenkanal zu empfangen.
Ein Busknoten, der aufweist: mindestens einen Prozessor (112) und einen Speicher, der Instruktionen enthält, die, wenn sie auf dem Prozessor (112) ausgeführt werden, den Busknoten dazu veranlassen, das Verfahren gemäß einem der Ansprüche 1 bis 11 und 13-14 auszuführen.
Ein nicht-flüchtiges Speichermedium mit Software-Instruktionen, die wenn sie auf einem Prozessor (112) eines Busknotens (10) ausgeführt werden, den Busknoten dazu veranlassen, das Verfahren gemäß einem der Ansprüche 1 bis 11 und 13-14 auszuführen.