In einem Bussystem werden alle Komponenten durch einen sogenannten Bus untereinander verbunden. Der Aufwand für die Verkabelung wird dadurch minimiert, und es können leicht zusätzliche Komponenten angeschlossen werden. Damit dies funktioniert, muss ein Protokoll für diesen Bus definiert sein / verwendet werden.

Bitrate und Leitungslängen

Das CAN Netzwerk kann prinzipiell Bitraten bis zu 1Mbit/s übertragen. Alle CAN-Knoten müssen die Nachricht gleichzeitig verarbeiten können. Die maximale Kabellänge ist daher abhängig von der Bitrate. Die Tabelle zeigt empfohlene Bitraten und die entsprechende maximale Kabellänge.

Bitrate	Kabellänge
10 kbits/s	6,7 km
20 kbits/s	3,3 km
50 kbits/s	1,3 km
125 kbits/s	530 m
250 kbits/s	270 m
500 kbits/s	130 m
1 Mbits/s	40 m

Aufbau einer CAN Nachricht

Eine Nachricht wird in einer für den CAN-Bus eigenen Form verpackt. Diese Verpackung wird als „Frame“ bezeichnet.
Ein Frame besteht aus 7 Kennfeldern:

Start-Condition

Message Identifier (11 oder 29 Bit)

Steuerbits

Daten (0-8 Bytes)

Prüfbits

Acknowledge-Bit

Stop-Condition

CAN 2.0B Frame Aufbau:

Start
1 Bit

Identifier
11 Bit

SRR
1 Bit

IDE
1 Bit

Identifier
18 Bit

RTR
1 Bit

r1
1 Bit

r0
1 Bit

DLC
4 Bit

DATA
0...8 Byte

CRC
15 Bit

ACK
2 Bit

EOF+IFS
10 Bit

Start: dominant, dient der Synchronisation,
Identifier: Information für den Empfänger und Prioritätsinformation für die Busarbitrierung,
SRR: ersetzt im Extended Frame das RTR Bit des Standard Frames,
IDE: zeigt an, dass noch weitere 18 Bits folgen (Extended Identifier)
r1, r0: reservierte Bits.
DLC: enthält die Längeninformation der nachfolgenden Daten,
DATA: enthält die Daten des Telegramms,
CRC: kennzeichnet den Fehlercode für die vorangegangenen Informationen. Die CRC Prüfsumme wird zur Fehlererkennung verwendet,
ACK: enthält Rückmeldung von anderen Teilnehmern bei korrektem Empfang der Nachricht,
EOF: kennzeichnet das Ende des Datentelegramms (7 rezessive Bits),
IFS: kennzeichnet den Zeitraum für das Übertragen einer korrekt empfangenen Nachricht,

Die meisten der im CAN Frame enthaltenen Bits werden von der CAN-Controller Hardware automatisch verwaltet. Für das logische Protokoll (Layer-7) sind nur die Identifier Bits und die Databytes von Bedeutung.

Fehlererkennung im CAN Netzwerk

Das CAN-Protokoll kann Fehler selbst erkennen und signalisieren. Um Fehler zu erkennen, sind im CAN-Protokoll drei Mechanismen auf der Nachrichernebene implementiert:

1. Cyclic Redundancy Check (CRC)
Der CRC sichert die Information des Rahmens , indem sendeseitig redundante Prüfbits hinzugefügt werden. Empfangsseitig werden diese Prüfbits aus den empfangenen Bits neu berechnet und mit den empfangenen Prüfbits verglichen. Bei Nichtübereinstimmung liegt ein CRC-Fehler vor.

2. Frame-check
Dieser Mechanismus überprüft die Struktur des übertragenen Rahmens Die durch Frame-Check erkannten Fehler werden als Formatfehler bezeichnet.

3. ACK-Fehler

Von allen Empfängern werden die empfangenen Rahmen durch positives Acknowledgement quittiert. Wird am Sender kein Acknowledgement erkannt (ACK-Fehler), so deutet dies auf einen möglicherweise nur von den Empfängern erkannten Übertragungsfehler, auf eine Verfälschung des ACK-Feldes oder auf nicht vorhandene Empfänger hin.

Außerdem sind im CAN-Protokoll zwei Mechanismen zur Fehlererkennung auf der Bitebene implementiert.

4. Monitoring
Jeder Knoten der sendet, beobachtet gleichzeitig den Busspegel. Er erkennt dabei Differenzen zwischen gesendetem und empfangenen Bit. Dadurch können alle globalen Fehler und lokal am Sender auftretenden Bitfehler sicher erkannt werden.

5. Bit-stuffing
Auf der Bitebene wird die Codierung der Einzelbits überprüft. Das CAN-Protokoll nutzt die NRZ-Codierung (Non-Return-to Zero), die eine maximale Effizienz bei der Bitcodierung gewährleistet. Dabei werden die Synchronisationsflanken nach der Methode des Bit-stuffings erzeugt, indem vom Sender nach fünf aufeinanderfolgenden gleichwertigen Bits ein Stuff-Bit mit komplementärem Wert in den Bitstrom eingefügt wird, welches die Empfänger automatisch wieder entfernen.

Werden ein oder mehrere Fehler mit Hilfe der oben beschriebenen Mechanismen von mindestens einem Knoten entdeckt, so wird die laufende Übertragung durch Senden eines "Error flag" abgebrochen. Dadurch wird die Annahme der übertragenen Nachricht durch andere Stationen verhindert und somit die netzweite Datenkonsistenz sichergestellt. Nach Abbruch der Übertragung einer fehlerhaften Botschaft beginnt der Sender automatisch, seine Nachricht erneut zu senden (Automatic Repeat Request).

Tritt ein Fehler mehrmals aufeinanderfolgend auf, führt dies zur automatischen Abschaltung des Knotens

Prinzip des Datenaustausches im CAN Netzwerk

Bei der Datenübertragung in einem CAN Bus werden keine Knoten adressiert, sondern der Inhalt einer Nachricht (z.B. Lok Geschwindigkeit oder Weichenstellung) wird durch einen eindeutigen Identifier gekennzeichnet. Neben der Inhaltskennzeichnung legt der Identifier auch die Priorität der Nachricht fest.

Mit der dann folgenden Akzeptanzprüfung stellen alle Stationen nach korrektem Empfang der Nachricht anhand des Identifiers fest, ob die empfangenen Daten für sie relevant sind oder nicht. Durch die inhaltsbezogene Adressierung wird eine hohe Flexibilität erreicht: Es lassen sich sehr einfach Stationen zum bestehenden CAN-Netz hinzufügen.

Außerdem ergibt sich die Möglichkeit des Multicasting: Eine Nachricht kann von mehreren Teilnehmern gleichzeitig empfangen und ausgewertet werden. Schaltbefehle, die von mehreren Steuergeräten als Information benötigt werden, können über das CAN-Netz so verteilt werden, dass nicht jedes Steuergerät einen eigenen Schaltbefehl benötigt.

Kollisionsprüfung

Jeder Teilnehmer darf Daten ohne besondere Aufforderung irgend eines Masters verschicken. Wie bei Ethernet kann es dazu kommen, dass mehrere Teilnehmer gleichzeitig senden. Die Nachricht mit dem niedrigsten Identifier setzt sich am Bus durch

Der Identifier mit der niedrigsten Binärzahl hat somit die höchste Priorität.

Den Vorgang zur Kollisionsprüfung über den Identifier nennt man „bitweise Arbitrierung“. Entsprechend dem "Wired-and-Mechanismus", bei dem der dominante Zustand (logisch 0) den rezessiven Zustand (logisch 1) überschreibt, verlieren all diejenigen Knoten den Wettstreit um die Buszuteilung, die rezessiv senden, aber auf dem Bus dominant beobachten. Alle "Verlierer" werden automatisch zu Empfängern der Nachricht mit der höchsten Priorität und versuchen erst dann wieder zu senden, wenn der Bus frei wird.

Der CANbus ist somit ein Bussystem mit bedarfsabhängiger Buszuteilung.

Auch gleichzeitige Buszugriffe mehrerer Knoten müssen immer zu einer eindeutigen Busvergabe führen. Durch das Verfahren der bitweisen Arbitrierung über die Identifier der zur Übertragung anstehenden Botschaften wird jede Kollision nach einer berechenbaren Zeit eindeutig aufgelöst: Im CAN Standard Format sind es maximal 13 Bitzeiten, im erweiterten Format sind es maximal 33 Bitzeiten.

Schichten der CAN-Software und CAN-Hardware

Die einzelnen Aufgaben des CANBus sind in sogenannten „Schichten“ (Layer) definiert.

Ø 1.Bitübertragungsschicht (Physical Layer). Diese Schicht beschreibt die physikalischen Eigenschaften, wie z.B. Stecker, Kabel, Signalpegel und wie ein Bit auf der Leitung dargestellt wird.

Ø 2.Übertragungsschicht (Transfer Layer)

Ø Die Übertragungsschicht hat die Aufgabe, das spezifizierte Busprotokoll abzuarbeiten. Dazu gehören die Erzeugung eines Übertragungsrahmens (,‚Pakets"), die Anforderung des Busses mit der nötigen Erkennung des Buszustands (frei, belegt) und evtl. die Durch- bzw. Weiterführung des Zugriffs (dezentrale Buszuteilung). Dazu kommen die Aufgaben der Fehlererkennung und Fehleranzeige.

Ø 3.Objektschicht (Object Layer)

Ø Diese Schicht hat als Hauptaufgaben die Botschaftenverwaltung und Zustandsermittlung. Sie entscheidet, welche Botschaften momentan zu übertragen sind. Auf der Empfängerseite nimmt sie eine Botschaftenfilterung anhand der Kennung im Identifikationsfeld vor, d.h. eine Entscheidung, welche Botschaften vom Knoten akzeptiert werden müssen und welche nicht.

Ø 4.Anwendungsschicht (CAN Application Layer CAL)

Ø In dieser Schicht werden die zu übertragenden Daten als Botschaften bereit gestellt und mit einer Kennung versehen, die eine inhaltsbezogene Adressierung ermöglichen. Durch die Wahl der Kennung wird jede Nachricht mit einer festgelegten Priorität versehen.

OpenRailCAN Layer-7 Definition

Wie oben beschrieben kümmert sich die CAN Hardware um die unteren, Hardware nahen Schichten der Kommunikation.

Damit aber eine Modell Bahn tatsächlich gesteuert werden kann, muss auch ein Layer-7 (Application/Anwendung) Layer definiert werden.

Grundsätzlicher ID Aufbau:

Hinweis: Es sind alle 29 ID Bits in Folge dargestellt, die 'CAN' internen Flags sind nicht dargestellt.

Priorität	Command Group	Direction	Bus Id	Device Type
2 Bit	8 Bit	1Bit	16 Bit	3 Bit
Bit 0, 1	Bits 2...9	Bit 10	Bit 11 ... 26	Bit 27, 28, 29

Beschreibung der Bit Gruppen:

Priorität	Gib an wie 'wichtig' die jeweilige Nachricht ist 0b00: Nicht verwendet, zwecks Märklin/ESU Kollisionsvermeidung 0b01: 0b10: 0b11:
Command Group	8 Bit für die jeweilige Kommando Gruppe Beginnend mit 0x80, dient ebenfalls als Unterscheidung zu bisher vorhandenen Kommandos.
Direction	Angabe der Richtung des Datentelegrammes. 0b0: Befehl bzw. Abfrage 0b1: Antwort / Event, kann auch 'ungefragt' auftauchen
Bus Id	Identifikationsnummer des 'Absenders'. Primär notwendig um Kollisionen am Bus zu vermeiden.
Device Type	Art des Gerätes 0b000: System Gerät (Zentrale, Booster, ...) 0b001: Loks 0b010: CAN Dekoder 0b011: CAN Enkoder 0b100: 'Legacy' Dekoder (z.B.: DCC Dekoder) 0b101: 'Legacy' Enkoder (z.B.: S88 Rückmelder) 0b110: Frei 0b111: Frei

Bus ID Vergabe:

Die Bus ID wird bei Anmeldung eines 'Devices' von der Zentrale vergeben.
Dafür gibt es zwei Verfahren:

a) 'Legacy' Devices

Das sind all jene 'Geräte', welche durch 'Fremdprotokolle' (MM1/2, DCC, ...) angesprochen werden. Diese haben üblicherweise eine max. 4 stellige Nummer aber keine eigene UID.
Zu der jeweiligen 'simplen' Nummer wird gem. folgender Tabelle ein Offset addiert, dadurch ergibt sich eine (hoffentlich) eindeutige UID und gleichzeitig auch die jeweilige Bus Id.

UID Word1	UID Word2 Min.	UID Word2 Max	Verfügbare Adressen
0x0000	0x0000	0x00FF	255	MM1/MM2 Loks
0x0000	0x0100	0x2FFF
0x0000	0x3000	0x33FF	1024	MM2 Dekoder
0x0000
0x0000
0x0000

B) CAN Devices

Alle 'echten' CAN Devices haben eine 32Bit UID. Damit diese problemlos vergeben werden kann, wird diese wie folgt vergeben:
In Byte 1 und 2 wird jeweils der Entwickler Name nach folgender Regel Codiert:
Der erste Buchstabe des Nachnamens und der zweite Buchstabe des Vornamens per XOR verknüpft ergeben das erste Byte. Der zweite Buchstabe des Nachnamens und der erste Buchstabe des Vornamens wieder per XOR verknüpft ergeben das 2. Byte.

Beispiel: 'Michael F. Schwarzer'
'S' = 0x53 XOR 'i' = 0x69 ergibt 0x3A
'c' = 0x63 XOR 'M' = 0x4D ergibt 0x2E
Word1 für die UID ist daher 0x3A2E, Word2 kann dann nach obiger Tabelle von jedem Entwickler fortlaufend vergeben werden.

Die jeweilige Bus-Id wird durch die Anmeldung vergeben, dabei werden die unteren 16Bit der UID als 'primäre' Ausgangsbasis verwendet. Sollten diese jedoch mehrfach im jeweiligen lokalen Netz vorkommen, so zählt die Zentrale einfach 'hoch' um so zu einer neuen einmaligen ID zu kommen.

Befehlssatz:

Im Folgenden befindet sich die Beschreibung des Befehlssatzes. Dieser ist in die 'Command Groups' gegliedert.

Genereller Aufbau der Befehle:

ID Command Group	Data Byte 1	Data Byte 2	Data Byte 3	Data Byte 4	Data Byte 5	Data Byte 6	Data Byte 7	Data Byte 8
Befehls Gruppe	Sub Command	[Ziel Id]		Weitere Daten ja nach Befehl

Die Befehlsgruppen sind so aufgebaut, das die jeweiligen CAN Geräte diese als 'Filter' Kriterium verwenden können und somit nicht alle Nachrichten am CAN Bus auswerten müssen. Im ersten Datenbyte werden die 'echten' Befehle codiert, dadurch ist eine flexible Erweiterung des Befehlssatzes möglich, ohne das bestehende Geräte beeinflusst werden.
In den Datenbytes 2 und 3 wird die jeweilige Bus Id des 'Ziel' Gerätes übertragen. Wenn die Zentrale (oder ein PC) die MM2 Weiche 5 schalten will, dann lautet diese Ziel Id 0x3005

System Command Group (0x80)

Die Command Group 0x80 fasst alle Systembefehle zusammen und muss von jedem Busteilnehmer implementiert werden.

Alles Aus (0x00, 0x00)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x80

0x00

0x80

0x00

Ziel-Id

0x80

0x00

Ziel UID

Wenn DLC = 1 (Kommando ohne Ziel ID), dann wird gesamtes System gestoppt. Alle Ausgänge werden 'Stromlos' geschalten.
Wenn DLC = 3, dann wird das Gerät mit der 'Ziel-Id' ausgeschalten.
Wenn DLC = 5, dann wird das Gerät mit der 'Ziel-UID' ausgeschalten (In erster Linie als Kompatibilität zum CS1/CS2 Protokoll gedacht).

Alles EIN (0x00, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x80

0x00

0x80

0x00

Ziel-Id

0x80

0x00

Ziel UID

Wenn DLC = 1 (Kommando ohne Ziel ID), dann wird gesamtes System eingeschalten.
Ab sofort können alle 'gültigen' Geräte Ihre Ausgänge gemäß dem nächsten Kommando schalten.
Wenn DLC = 3, dann wird das Gerät mit der 'Ziel-Id' eingeschalten.
Wenn DLC = 5, dann wird das Gerät mit der 'Ziel-UID' eingeschalten (In erster Linie als Kompatibilität zum CS1/CS2 Protokoll gedacht).

Überlast (0x00, 0x0A)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x80

0x0A

Type

0x80

0x0A

Type

Port

Wenn DLC = 2 (Kommando ohne Ziel ID), dann handelt es sich um einen 'allgemeinen' Überlast Zustand.
Wenn DLC = 3, dann ist der Ausgang 'Port' überlastet.
Type gibt die Art der Überlast an:
0x00 bedeutet 'Nix'
0x01 bedeutet 'Zu hoher Strom'
0x02 bedeutet 'Zu hohe Temperatur'

Lok Control Command Group (0x81)

Die Command Group 0x81 fasst alle Lok Steuer Befehle zusammen und muss von allen Boostern und Fahrpulten implementiert werden.

Lok(s) Nothalt (0x81, 0x00)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x81

0x00

0x81

0x00

Ziel-Id

0x81

0x00

Ziel UID

Wenn DLC = 1 (Kommando ohne Ziel ID), dann erfolgt ein 'Nothalt' aller Loks.
Wenn DLC = 3, dann erfolgt ein 'Nothalt' der durch 'Ziel-Id' angegeben Lok.
Wenn DLC = 5, dann erfolgt ein 'Nothalt' der durch 'Ziel-UID' angegeben Lok.

Lok Speed (0x81, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x81

0x01

Ziel-Id

0x81

0/1

0x01

Ziel-Id

Speed

Wenn DLC = 3, dann wird die Geschwindigkeit der Lok mit 'Ziel-Id' angefragt.
Wenn DLC = 5 und D = 0, dann wird die Geschwindigkeit der Lok mit 'Ziel-Id' wird auf den übergeben Wert gesetzt.
Wenn DLC = 5 und D = 1, dann Antwortet die Lok mit 'Ziel-ID' auf die Abfrage nach Ihrer Geschwindigkeit.
Wenn DLC = 7, die Geschwindigkeit der Lok mit 'Ziel-UID' wird auf den übergeben Wert gesetzt.

Lok Speed (0x81, 0x02)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x81

0x02

Ziel UID

0x81

0/1

0x02

Ziel UID

Speed

Wenn DLC = 5, dann wird die Geschwindigkeit der Lok mit 'Ziel-UID' angefragt.
Wenn DLC = 7 und D = 0, dann wird die Geschwindigkeit der Lok mit 'Ziel-UID' wird auf den übergeben Wert gesetzt.
Wenn DLC = 7 und D = 1, dann Antwortet die Lok mit 'Ziel-UID' auf die Abfrage nach Ihrer Geschwindigkeit.

Lok Funktion Schalten (0x81, 0x03)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x81

0x03

Ziel-Id

0x81

0/1

0x03

Ziel-Id

Status für Fx0 bis Fx31

Wenn DLC = 3, dann wird der Funktionsstatus der Lok mit 'Ziel-Id' abgefragt
Wenn DLC = 7 und D = 1, dann antwortet die Lok auf eine Status Abfrage. Die 32 Bit in den Datenbytes 4 bis 7 enthalten dabei den jeweiligen Status der Funktionen.
Wenn DLC = 7 und D = 0, dann werden die Funktionen auf den jeweils angegebenen Status geschalten.

Lok Funktion Schalten (0x81, 0x04)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x81

0x04

Ziel-Id

FxNr

0x81

0/1

0x04

Ziel-Id

FxNr

Wert

Wenn DLC = 3, dann wird der Funktionswert der Lok mit 'Ziel-Id' abgefragt und der Funktion 'Nr.' abgefragt.
Wenn DLC = 7 und D = 1, dann antwortet die Lok auf eine Funktionswert abfrage.
Wenn DLC = 7 und D = 0, dann wird die Lokfunktion 'FxNr' der Lok 'Ziel-Id' auf den angegebenen Wert gesetzt.
Wobei Wert = 0x00 immer 'Aus' bedeutet, Werte ungleich 0x00 sind vom jeweiligen Lok Dekoder abhängig. Für 'normale' DCC und MM Lok Dekoder bedeutet dies einfach Funktion 'Ein'.

Dekoder Command Group (0x88)

Die Command Group 0x88 fasst die Dekoder Befehle zusammen. Damit sind alle stationären Geräte gemeint, welche Ausgänge schalten können (z.B.: Weichen, Servos, Drehscheiben, etc.). Diese können sowohl direkt am CAN Bus hängen, oder per Track Prozessor angesprochen werden.

Alle dekoder aus (0x88, 0x00)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x88

0x00

Schaltet alle Dekoder aus.

Alle dekoder EIN (0x88, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x88

0x01

Schaltet alle Dekoder ein.

Alle dekoder Restore (0x88, 0x02)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x88

0x02

Alle Dekoder schalten Ihre Ausgänge auf die 'letzte' bekannte Position.

dekoder schalten (0x88, 0x03)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x88

0/1

0x03

Ziel-Id

Pos

Schaltet die Dekoder Ausgänge in Pos(ition), die 'Interpretation' der Position ist dabei vom Dekoder abhängig.
Der Dekoder kann (muss aber nicht) den Empfang bzw. die Durchführung des Befehles quittieren.

Enkoder Command Group (0x89)

Die Command Group 0x89 fasst die Enkoder Befehle zusammen. Damit sind alle stationären Geräte gemeint, welche 'Eingänge' haben (Rückmelder).
Dies können ganz simple S88 Rückmelder sein, aber auch komplexe RailCom / mfx Empfänger.

Alle enkoder aus (0x89, 0x00)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x89

0x00

Es werden alle Enkoder ausgeschalten.

Alle enkoder ein (0x89, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x89

0x01

Alle Enkoder aktivieren Ihre Eingänge. Je nach Konfiguration warten sie nun auf eine Abfrage oder beginnen selbstständig Änderungen zu senden. Wobei sich nach dem Einschalten die Enkoder Eingänge auf Ihrem 'Default' Zustand liegen.

Alle enkoder restore (0x89, 0x02)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x89

0x02

enkoder Abfrage (0x89, 0x10)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x89

0x10

Ziel-Id

Abfrage des Enkoders mit der 'Ziel-Id'.

enkoder Status (0x89, 0x10)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x89

0/1

4 ... 7

0x10

Ziel-Id

Status 0 ... 31

Dekoder 'Ziel-Id' sendet den Status seiner Eingänge 0 bis 31.
Wenn 'D=1', dann handelt es sich um eine Antwort aufgrund einer Anfrage.
Wenn 'D=0', dann sendet der Enkoder ein 'Event', also eine Änderung seiner Eingänge.

System Management (0x90)

In der System Management Group (0x90) enthält alle Befehle, welche zur System Verwaltung notwendig sind.

Ping (0x90, 0x00)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x90

0x00

Ziel-UID

0x90

0x00

Ziel-UID

Vers

Prüft ob das Gerät mit der UID am Bus vorhanden ist. Wenn das Gerät vorhanden ist, dann antwortet es mit Angabe seiner Versions Nummer.

Find (0x90, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0x90

0x01

Versucht ein neues Gerät am Bus zu finden.

Programm Flash (0xF0)

Über die Befehle in der 'Flash' Group können die Controller mit einer neuen Software geflasht werden, bzw. Daten direkt in die Data Rom's geschrieben werden.

Flash Cancel (0x90, 0x00)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0xF0

0x00

Jeder Flash Vorgang wird abgebrochen.

Flash INIT (0x90, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0xF0

0x01

Ziel-Id

Vers

0xF0

0x01

Ziel-UID

Vers

Das Gerät mit der 'Ziel-Id' / 'Ziel-UID' wird in den Flash Mode versetzt. Sobald sich das Gerät im 'Flash-Mode' befindet, antwortet es auf keine 'None-Flash' Kommandos mehr.

Flash Acceppted (0x90, 0x01)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0xF0

0x01

Ziel-Id

Ziel-UID

Vers

Das Gerät mit der Ziel-Id/Ziel-UID hat den 'Flash-Mode' akzeptiert. Die rückgemeldete Version ist dabei die im Gerät vorhandene Software Version.

Flash Size (0x90, 0x02)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0xF0

0x01

Ziel-Id

Flash Start

Flash Size

0xF0

0x01

Ziel-Id

Flash Size

CntMax

Sendet die Anzahl die 'Start Adresse' und die Anzahl der 'Flash Bytes' an das Gerät.
Als Antwort sendet das Gerät die mögliche Anzahl an Bytes zurück. Ist diese Grösser/Gleich, dann passt die neue Software in den Controller, wenn sie kleiner ist, dann muss abgebrochen werden. Wenn das Ziel Gerät zu wenig Speicher hat, dann werden alle folgenden Kommandos mit Ausnahme des 'Flash-Cancel' ignoriert. 'CntMax' gibt dabei an, wie viele Transfers das Gerät in einem Durchgang erlaubt.

Flash Data (0x90, 0x04)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0xF0

0x04

Ziel-Id

Cnt

Byte1

Byte2

Byte3

Byte4

0xF0

0x04

Ziel-Id

Cnt

Byte1

Byte2

Byte3

Byte4

Damit werden jeweils bis zu 4 Bytes an das 'Ziel-Gerät' gesendet. Das Gerät antwortet mit exakt dem selben Daten ('D' ist aber '1').
Nach Empfang der Bestätigung dürfen die nächsten 4 Bytes gesendet werden.
Der 'Cnt' Zähler wird je 4Byte inkrementiert, somit können 1k je Zyklus übertragen werden.

Flash Checksum (0x90, 0x05)

Prio

Cmd

DLC

DB1

DB2

DB3

DB4

DB5

DB6

DB7

DB8

0xF0

0x04

Ziel-Id

Cnt

CRC

0xF0

0x04

Ziel-Id

0x00

CRC

Nach der 'maximalen' Transfer Anzahl des Zielgerätes muss eine Checksumme gesendet werden. Sobald das 'Ziel-Gerät' für die nächsten Transfers bereit ist, antwortet es mit der (hoffentlich) gleichen Checksumme und einem Counter 0x00.