BiDiB, Übertragung über serielle Schnittstelle

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

1. Allgemeines

Das Protokoll BiDiB dient zur Kontrolle einer Modellbahnanlage. Es ermöglicht die Ansteuerung von Loks, Zubehör und sichere Übertragung von Rückmelderinformationen aus der Modellbahnanlage an den steuernden Rechner.

BiDiB kann über verschiedene Übertragungsmedien transportiert werden, dabei wird das Framing und die Sicherung der Nachrichten gewährleistet.

Eine Erläuterung der hier verwendeten Begriffe und der Protokollgrundzüge findet sich im allgemeinen Teil der Protokollbeschreibung, gleiches gilt auch für die Hinweise zur Benutzung und zur Lizenz.

Im folgenden ist der Transport über einen seriellen Link beschrieben, z. B. RS232 oder virtueller COM-Port über USB.

2. Serielle Verbindung

2.1. Übertragungsparameter

Die Kommunikation erfolgt über einen seriellen Port, die Baudrate ist dabei variabel und kann einen Wert 19200 Baud, 115200 Baud oder 1MBaud annehmen. Die weiteren Parameter sind 8 Datenbits, 1 Stopbit, keine Parity (oft als "8N1" bezeichnet). Die tatsächlich verwendete Baudrate ist vom Host zu Beginn durch Abfragen der System-ID festzustellen, bevorzugte Baudrate ist 1MBaud. Der Host hat also maximal drei Baudraten zu probieren.

(Anmerkung zur Baudrate: 1MBaud ist auf gängigen USB-Uarts (wie z. B. FTDI) und auf allen neueren Microprozessoren gut realisierbar, auf älteren Prozessoren ist für die schnelle Rate ein passender Quarz (z. B. 16MHz) erforderlich)

CTS und RTS werden ausgewertet. Auf beiden Seiten (sowohl auf Host als auch beim Interface) sind Fifos vorzusehen, nach einem CTS-off dürfen noch bis zu 8 Byte übertragen werden.

Nach dem Einschalten und Verbinden des BiDiB-Systems meldet sich der Knoten mit MSG_LOCAL_LOGON, die Nachricht kann aber bei der Schnittstelleninitialisierung verloren gehen. Es findet noch keine Datenkommunikation statt, zuerst muss die System-ID des Interfaces erfolgreich gelesen werden (zur Kontrolle der richtigen Baudrate) und im Interface des BiDiB-Systems die Transferfreigabe für Spontannachrichten gesetzt werden.

2.2. Framing, Datensicherung

Ein serielles Paket ist prinzipiell wie folgt aufgebaut:

PACKET ::= MAGIC  MESSAGE_SEQ  CRC  [MAGIC]
MESSAGE_SEQ ::= ε | MESSAGE  MESSAGE_SEQ
MAGIC ::= 0xFE

Ein serielles PACKET beginnt immer mit speziellen Zeichen ([MAGIC]=0xFE) und kann eine oder mehrere Nachrichten (MESSAGE) enthalten. Das ganze Paket ist mit einer CRC (Cyclic Redundancy Check) abgesichert, um Datenfehler bei der Übertragung erkennen zu können. MAGIC-Zeichen, welche innerhalb von Nachrichten auftauchen, werden 'escaped'. Hierzu wird ein ESCAPE Zeichen (=0xFD) eingefügt und das nachfolgende Zeichen mit 0x20 xor-verknüpft. Auch das ESCAPE-Zeichen selbst wird innerhalb der Nachricht escaped. Das heißt: Anstelle des MAGIC wird ein ESCAPE-Zeichen (=0xFD), gefolgt von MAGIC ^ 0x20 = 0xDE gesendet. Anstelle des ESCAPE-Zeichen wird 0xFD + 0xDD gesendet. Das Escaping erfolgt auf dem fertig kodierten PACKET inkl. CRC (d.h. die CRC wird über die Nachricht(en) ohne MAGIC, ohne ESCAPE gebildet).

Die MESSAGE ist vom Host an einen bestimmten Knoten adressiert. In einem Paket können MESSAGES enthalten sein, die an verschiedene Knoten adressiert sind.

CRC bezeichnet das CRC8-Byte; Auf der Senderseite wird das gemäß Polynom x8 + x5 + x4 + 1 über die Nachricht gebildet, beginnend beim ersten Byte der Nachricht, Init=0, nicht invertiert. Empfängerseitig wird die CRC mit dem gleichen Polynom über die gesamte Nachricht inkl. CRC gebildet, das Ergebnis muss 0 sein.

Nach den Paket schließt sich ein MAGIC an, dies kann auch gleichzeitig der Beginn des nächsten Paketes sein. Wenn kein weiteres Paket zum Senden bereit ist, so wird trotzdem die MAGIC übertragen. Anhand des Empfangs eines MAGIC-Zeichens erkennt der Empfänger das Ende der Nachricht und führt die CRC-Prüfung durch.

Zwischen zwei MAGIC-Zeichen dürfen nicht mehr Zeichen übertragen werden, als die jeweilige max. Längenkapazität (siehe MSG_PKT_CAPACITY) erlaubt, Escaping wird hierbei nicht mitgezählt.

Unter bestimmten Bedingungen kann ein leeres Paket entstehen. In diesen Fall wird MAGIC 0x00 MAGIC (wobei 0x00 der CRC-Wert ist) oder MAGIC MAGIC übertragen.

2.3. Aufbau und Kontrolle der Verbindung

Prinzipiell wird bei BiDiB jede Verbindung zwischen zwei Teilnehmern aufgebaut und im Betrieb auf Verlust der Verbindung überwacht. Zum Auf-/Abbau der Verbindung dienen die lokalen Nachrichten MSG_LOCAL_LOGON und MSG_LOCAL_LOGOFF, zur Überwachung der Verbindung kann MSG_LOCAL_PING verwendet werden.

Hinweis: Da es sich bei der seriellen Verbindung um eine Punkt-zu-Punkt-Verbindung handelt, ist beim Verbindungsaufbau auch der direkte Beginn mit MSG_SYS_GET_MAGIC seitens des Hosts erlaubt.

Für die Linkkontrolle gelten folgende Regeln:

  • Wenn der Knoten für mehr als 5s keine Nachricht vom Host empfangen hat, nimmt er einen Verbindungsabbruch an. Es spielt dabei keine Rolle, ob die Nachricht an den Knoten selbst oder an einen Unterknoten adressiert war. Der Host sollte also max. 4s Zeit zwischen zwei Nachrichten verstreichen lassen.
  • Wenn keine sonstigen Nachrichten transportiert werden, können und sollen zum Aufrechthalten des Verbindungsstatus MSG_LOCAL_PING (und die zugehörige MSG_LOCAL_PONG) als leere Nachrichten verwendet werden.
  • Empfängt der Knoten eine Nachricht MSG_LOCAL_LOGON_REJECTED, so hat der Host die Verbindung beendet.
  • Empfängt der Host eine MSG_LOCAL_LOGOFF, so wird der verbundene Knoten die Verbindung abbrechen, etwa bei einem Neustart.
  • Eine Wiederaufnahme ist jederzeit möglich und sollte mit MSG_SYS_GET_MAGIC und der Übermittlung der Systemzeit eingeleitet werden.

2.4. Protokoll, lokale Nachrichten

Es gelten die allgemeinen Ausnahmeregeln für lokale Nachrichten.

Logon/Logoff

  • MSG_LOCAL_LOGON:

    Mit dieser Nachricht wird die Anmeldung durch den Knoten eingeleitet, er möchte sich vom Host kontrollieren lassen. Es folgen 7 Byte:

    MSG_LOCAL_LOGON Parameter
    ParameterBeschreibung
    UID[7] Die Unique-ID des Knotens.

    Hinweis: Der Knoten sendet diese Nachricht einmalig, bei nicht aktiver Schnittstelle seitens des Host kann (und wird) diese Nachricht verloren gehen. Sinnvoll ist diese Nachricht z.B. nach Ende eines lokalen Betriebes, wenn sich der Knoten wieder seitens des Host kontrollieren lassen will.

    Das Businterface antwortet mit MSG_LOCAL_LOGON_ACK oder MSG_LOCAL_LOGON_REJECTED oder beginnt mit der Abfrage der MAGIC.

  • MSG_LOCAL_LOGON_ACK:

    Mit dieser Nachricht wird ein LOGON durch das Interface bestätigt. Typischerweise folgt dann eine weitere Nachricht MSG_SYS_GET_MAGIC. Es folgen 8 Byte:

    MSG_LOCAL_LOGON_ACK Parameter
    ParameterBeschreibung
    NODE Die lokale BiDiB-Adresse, unter der das Interface den Knoten eingebucht hat, oder 0 falls das Interface (z. B. im Host) keine eigene Busebene darstellt.
    UID[7] Die Unique-ID des Knotens.

    Hinweis: NODE wird dabei nicht für das Routing benötigt (direkte Verbindung). Sie ist nur für Debugging im Knoten bestimmt.

    Nur wenn die empfangene Unique-ID identisch zu der internen Unique-ID des Knotens ist, ist die Anmeldung gültig. (Da hier eine direkte Verbindung vorliegt, wäre UID nicht zwingend erforderlich, jedoch ist die MSG_LOCAL_LOGON_ACK auf allen Implementierung entsprechend kodiert).

  • MSG_LOCAL_LOGON_REJECTED:

    Mit dieser Nachricht wird ein LOGON durch das Interface abgelehnt beziehungsweise ein bestehende Kontrollverhältnis wieder aufgelöst. Es folgen 7 Byte:

    MSG_LOCAL_LOGON_REJECTED Parameter
    ParameterBeschreibung
    UID[7] Die Unique-ID des betroffenen Knotens.

    Der Knoten quittiert dies mit MSG_LOCAL_LOGOFF. Nach dem Ende des Kontrollverhältnisses kann nun der Knoten optional die Buskontrolle seiner Unterstruktur übernehmen und z.B. lokalen Betrieb (='Fahren ohne PC') ermöglichen.

  • MSG_LOCAL_LOGOFF:

    Mit dieser Nachricht meldet sich ein Knoten vom Interface ab und unterliegt damit nicht mehr der Kontrolle durch den Host. Es folgen 7 Byte:

    MSG_LOCAL_LOGOFF Parameter
    ParameterBeschreibung
    UID[7] Die Unique-ID des Knotens.

Linkkontrolle

  • MSG_LOCAL_PING:

    Es folgt kein Parameter. Der Knoten antwortet mit MSG_LOCAL_PONG.

Synchronisation

  • MSG_LOCAL_SYNC:

    Mittels MSG_LOCAL_SYNC-Nachrichten wird die Systemzeit übertragen (falls hostseitig gewünscht). Diese Nachricht wird regelmäßig in Abständen kleiner als 32,3 s gesendet (unter Annahme eines 30ppm-Quarz im Knoten ergibt sich in dieser Zeitspanne eine maximale Drift von 1 ms). Der in der Nachricht enthaltene Timestamp bezieht sich jeweils auf das Ende des vorangegangenen MAGIC-Zeichens. Dieser Zeitpunkt lässt sich häufig vom Treiber ermitteln, indem MAGIC als Event-Character eingestellt wird.

    Es erfolgt keine Antwort.

Avatarmode (Optional, nur für physisch eng gekoppelte Baugruppen)

Da die serielle Verbindung oft die einzige Verbindung einer Ebene ist, kann die nächsthöhere Ebene einen Stellvertreterbetrieb etablieren (z.B. um den Knoten im Netz verfügbar zu machen). Bei Stellvertreterbetrieb tritt diese Verbindungsebene nach außen nicht als sichtbare Verbindungsinstanz auf. Zur einfacheren Implementierung des Stellvertreterbetriebes kann optional ein direkter Datenaustausch zwischen Stellvertreter und Knoten erfolgen, dieser muss mittels lokaler Nachrichten erfolgen. Dadurch wird die Sequenzfolge der übergeordnete Verbindung nicht beeinflusst.

  • MSG_LOCAL_BIDIB_DOWN:

    Wrappernachricht (vom Host Richtung Knoten), es folgt die nur lokal zu beantwortende BiDiB-Nachricht. Der Knoten antwortet mit MSG_LOCAL_BIDIB_UP (ebenfalls eine lokale Wrappernachricht) und der Antwort auf die lokale Anfrage.

    Hinweise:
    Stellvertreternachrichten sind nicht verpflichtend, weder für Host noch für den Knoten
    Als sinnvoll hat sich die Implementierung für folgende lokalen Anfragen herausgestellt:
    MSG_SYS_GET_MAGIC,MSG_SYS_GET_P_VERSION, MSG_SYS_GET_UNIQUE_ID, MSG_SYS_GET_SW_VERSION, MSG_SYS_PING, MSG_GET_PKT_CAPACITY, MSG_STRING_SET, MSG_STRING_GET.