welcome: please sign in

Poor Man's CAN

Diese Seite beschreibt die Definition eines Feldbussystems welches von den physikalischen Eigenschaften an CAN angelehnt ist, aber mit den in fast allen Mikrocontrollern integrierten UART Transceivern realisiert werden kann.

Eigenschaften

Hardware Ebene

Eagle Lib

Die Eagle Lib mit den Steckern gibt es im Download-Bereich

Protokoll-Ebene

Aus wiederverwendbarkeitsgründen ist das Protokoll an das CAN Protokoll angelehnt.

Aufbau eines Frames

weitere Spezifikationen

Impementierung

alternatives Protokoll

Der Ansatz dieses Protokolls ist es nicht eine möglichst simple Datenübertragung zu ermöglichen, sondern harten Echtzeitbedingungen zu genügen. Da dieser Entwurf einen nicht unerheblichen Anteil an Protokolldaten erfordert ist die Übertragungsrate spezifisch an die zeitlichen Anforderungen des Zielsystem anzupassen.

Die Kommunikation wird von einem Master verwaltet der die Module zyklisch überprüft. Beim Start des Systems findet eine generelle Abfrage aller Moduladressen statt, um die vorhandenen Module automatisch zu erkennen. Diese Abfrage kann je nach Anforderung wiederholt werden; neu hinzugefügte Module können so erkannt und eingebunden werden. Die Dauer eines Standardzyklus sollte dabei nicht überschritten werden und muss bei entsprechenden Echtzeitanforderungen berücksichtigt werden.

Die eigentliche Datenübertragung verläuft in zwei Runden, dazu werden Statusanfragen an alle bekannten Module gesendet. Die angesprochenen Knoten antworten mit einem Telegramm das als einziges Datenbyte, die Anzahl der reinen Datenbytes enthält die der Knoten senden möchte. Möchte der Knoten keine Daten senden, wird mit 0x00 als Datenbyte geanwortet. Der Master kann so überprüfen ob das Modul noch funktionsfähig ist und ob die Anfrage den Knoten erreicht hat. Aufgrund dieser rücklaufenden Daten, der hinterlegten Priorität und des Alters der Anforderung plant der Master nun die Sendereihenfolge des aktuellen Zeitschlitzes und ruf in dieser die Knoten zur tatschächlichen Datenübertragung auf.

Generell werden die Anfragen des Masters immer mit einem Telegramm des entsprechenden Knotens beantwortet, um die Kommunikation zu bestätigen. Der Master hingegen beantwortet die Sendungen des Slave nicht, sondert fordert bei fehlerhafter Übertragung die Daten zu einem geeigneten Zeitpunkt neu an. Erkennt der Slave selbst einen Fehler in der Übertragung kann diese optional mit dem Senden des EOT-Zeichens (0x04) vorzeitig abgebrochen werden, da dies zwingend zu einen ungültigen Telegramm führt. Sollen Daten von Slave zu Slave übertragen werden, ist keine aktive Bestätigung vom Zielmodul vorgesehen, diese Bestätigung wird nach erfolgter, für den Master gültigen, Übertragung explizit angefordert.

Die Daten müssen grundsätzlich als ASCII übertragen werden und dabei den folgenden Anforderungen entsprechen. Es dürfen pro Datensatz zwischen 0 und 32 Datenbytes enthalten sein, daraus folgt das die Länge eines Datensatzes mindestens 8 und höchsten 40 Byte beträgt. Die Prüfsumme wird berechnet aus allen Zeichen zwischen SOH und ETX als Kette von XOR-Verknüpfungen mit dem Startwert 0x00. Das Ergebnis wird in Halbbytes zerlegt, je der Wert 0x41 addiert und der Nachricht angefügt.

Datentelegramm

1

0x01

SOH - start of heading

2

0x41 - 0x5F

Moduladresse

3

0x41 - 0x5F

Funktionsaufruf (Sendeanforderung, Slave-Slave-Bestätigung, ...)

4

0x02

STX - start of text

4 + n

0x20 - 0x7E

n. Datenbyte

4 + n + 1

0x03

ETX - end of text

4 + n + 2

0x41 - 0x50

Prüfsumme oberes Halbbyte + 0x41

4 + n + 3

0x41 - 0x50

Prüfsumme unteres Halbbyte + 0x41

4 + n + 4

0x04

EOT - end of transmission