Funktionsweise
Die Objekt-ID ist immer 11-bittig und adressiert den CAN-Knoten, die sog. Knoten-ID. Wird ein Gerät am CAN-Knoten (z.B. eine Weiche) addressiert, muss ein Extended Frame verwendet werden. Die zusätzlichen 18 Bit spezifizieren die Gerätenummer. Die Knoten-ID muss konfiguriert sein und wird mit einem Magic Byte gesichert im EEPROM abgelegt. Es gibt die Broadcast-ID 2047. Diese adressiert alle CAN-Knoten. Das CAN/RS232-Gateway hat die ID 0. Das Gateway schiebt CAN-Frames vom PC über RS232 an den CAN-Bus. Dies passiert wechselseitig. Da die Busse mit unterschiedlicher Geschwindigkeit laufen, sind jeweils in zwei Richtungen Ringbuffer eingerichtet. Es ist nicht mit einer CAN-Frame-Flutung (z.B. durch Download) zu rechnen, sodass diese Variante ausreichen wird.
Kommandos
Die Firmware des CAN-Knoten hat verschiedene Betriebszustände. Je nach Betriebszustand sind nur bestimmte Kommandos erlaubt. Einige Kommandos lösen einen Wechsel des Betriebszustandes aus. Bestes Beispiel ist das Kommando RESET, das den CAN-Knoten neu startet. Da das aber bedingt durch die Hardware nicht sofort passieren kann, verbleibt der CAN-Knoten noch eine Weile im Betriebszustand 'Resetting'.
Das Zustandsübergangsdiagramm verdeutlicht, welche Betriebszustände es gibt und welche Kommandos pro Betriebszustand erlaubt sind bzw. einen Zustandsübergang auslösen. 
Hier wird eine Liste von Kommandos aufgelistet, die vom Server über den CAN-Bus an die Controller abgesetzt werden. Ist ein Extended Frame nötig, ist in den 18 ergänzten Bits die 16-bittige Unitnumber kodiert.
Weichen
| Kommando |
Code |
Extended Frame nötig |
Parameter |
Bedeutung |
| SETLFT |
0x01 |
ja |
|
Schalte Weiche links/Abzweig |
| SETRGT |
0x02 |
ja |
|
Schalte Weiche rechts/Kreuz |
| GETDIR |
0x03 |
ja |
|
Frage Weichenrichtung |
Gleisabschnitte
| Kommando |
Code |
Extended Frame nötig |
Parameter |
Bedeutung |
| SETRON |
0x11 |
ja |
|
Schalte Gleis ein |
| SETROF |
0x12 |
ja |
|
Schalte Gleis aus |
| GETRBS |
0x13 |
ja |
|
Frage ob Gleis besetzt |
Signale
| Kommando |
Code |
Extended Frame nötig |
Parameter |
Bedeutung |
| SETSGN |
0x21 |
ja |
Symbol |
Schalte Signal auf Symbol |
Konfiguration
Die Konfiguration erfolgt als Block, d.h., beim Betreten des Konfigurationsmodes mit CFGBGN wird solange das Device DNo angesprochen, bis der Konfigurationsmodus verlassen wurde. Zwischendurch sind Stellbefehle verboten, da die Ports evtl. umkonfiguriert werden müssen. Das geschieht jedoch nur nach einem Reset. Nach dem Befehl CFGEND, wird der automatische Watchdog-Reset verhindert, sodass dadurch ein Hardware-Reset ausgelöst wird. Da die Unitnumber in die Extended ID eingepflegt wird, müssen diese Kommandos als Extended Frames versendet werden. Die Kommandos CFGBGN und CFGEND adressieren kein Gerät und können als Standardframe versendet werden.
| Kommando |
Code |
Extended Frame nötig |
Parameter |
Bedeutung |
| CFGBGN |
0x41 |
nein |
Starte Rekonfiguration |
|
| CFGSWN |
0x31 |
ja |
Pin1 Pin2 |
Weiche mit Endabschaltung links/Abzweig geschaltet über Pin1, rechts/Kreuz an Pin2 |
| CFGSWO |
0x32 |
ja |
Pin1 Pin2 |
Weiche ohne Endabschaltung links/Abzweig geschaltet über Pin1, rechts/Kreuz an Pin2 |
| CFGRAI |
0x33 |
ja |
Pin1 Pin2 |
Gleisrelais an Pin1 und Gleisbesetztmeldung an Pin2 |
| CFGPF2 |
0x34 |
ja |
Pin1 Pin2 |
2-flügeliges Formvorsignal an Pins |
| CFGPF3 |
0x35 |
ja |
Pin1 Pin2 Pin3 |
3-flügeliges Formvorsignal an Pins |
| CFGMF2 |
0x36 |
ja |
Pin1 Pin2 |
2-flügeliges Formhauptsignal an Pins |
| CFGMF3 |
0x37 |
ja |
Pin1 Pin2 Pin3 |
3-flügeliges Formhauptsignal an Pins |
| CFGPL2 |
0x38 |
ja |
Pin1 Pin2 |
2-symboliges Vorsignal an Pins |
| CFGPL3 |
0x39 |
ja |
Pin1 Pin2 Pin3 Pin4 |
3-symboliges Vorsignal an Pins |
| CFGSL2 |
0x3a |
ja |
Pin1 Pin2 |
2-symboliges Gleissperrsignal an Pins |
| CFGML2 |
0x3b |
ja |
Pin1 Pin2 |
Blocksignal an Pins |
| CFGML3 |
0x3c |
ja |
Pin1 Pin2 Pin3 |
3-symboliges Einfahrsignal an Pins |
| CFGML4 |
0x3d |
ja |
Pin1 Pin2 Pin3 Pin4 Pin5 |
Ausfahrsignal an Pins |
| CFGLGT |
0x3e |
ja |
Pin1 Schwellwert Profil |
Beleuchtung |
| CFGEND |
0x42 |
nein |
Rekonfiguration beendet. |
|
Die Pinbelegung für Lichtsignale lässt sich hier einsehen.
Firmware Update
Die Firmware der einzelnen Controller kann über den Bus aktualisiert werden. Dabei gilt:
- es kann verschiedene Hardware-Vevisionen in einem System geben, die abgefragt werden können.
- mehrere Controller können gleichzeitig geflasht werden. Dazu werden beliebig viele Devices in den Update-Modus gebracht.
| Kommando |
Code |
Extended Frame nötig |
Parameter |
Bedeutung |
| FLASH_REQ |
0x48 |
nein |
Firmware Sig1 Sig2 Sig3 |
Flashrequest, Firmware-Typ (nicht Version), und ATmega Signaturbytes. Stimmt die Hardware-Signatur nicht, wird mit einem MSG_HARDWARE_MISMATCH geantwortet (s. dort) |
| FLASH_DATA |
0x49 |
nein |
Addr_l Addr_m Addr_h data1 data2 data3 data4 |
24-Bit-Adresse in Bytes, dann 2 oder 4 Datenbytes. Es wird keine Antwort gesendet! |
| FLASH_CHECK |
0x4a |
nein |
checksum |
Alle Datenbytes addiert ergeben die Checksumme, stimmt diese, wird ins Hauptprogrammverzweigt. Als Antwort kommt immer die gesammelte Prüfsumme der FLASH_DATA-Kommandos und die tatsächliche Prüfsumme aus dem Flash-Speicher. |
Sonstiges
| Kommando |
Code |
Extended Frame nötig |
Parameter |
Bedeutung |
| PING |
0x44 |
nein |
Antwortet immer mit MSG_OK |
|
| RESET |
0x45 |
nein |
Neustart über Software |
|
| SET_ID |
0x43 |
nein |
ID |
Setzt die Controller ID neu. Die Konfiguration wird gelöscht. |
| QRYBUF |
0x4b |
nein |
Fragt die Pufferbelegung von Empfangs- und Sendepuffer ab. Eine Antwort hat die Füllstände der jeweiligen Puffern |
|
| QRYERR |
0x4c |
nein |
Fragt den Fehlerzustand des CAN-Busses ab. Es werden drei Antwort-Messages erzeugt. |
|
| GETVER |
0x4d |
nein |
Fragt die Versionsnummer der Firmware ab. Es werden drei Antwort-Messages erzeugt. |
|
| SENSOR |
0x4e |
nein |
Sensortyp Sensorwert |
Sendet Sensordaten. |
Mögliche Antworten / Signale von den Controllern
Die Antworten werden immer als Extended Data Frame versendet. Die Standard ID ist immer 0x7ff. Die Extended ID ist die Controller ID des Absenders. Somit können gleiche Paketantworten durch unterschiedliche Controller nur innerhalb der Arbitrierungsphase kollidieren, was so auch im CAN-Standard vorgesehen ist. So kann wenigstens ein CAN-Controller sein Frame versenden, während die niedriger priorisierten Frames warten müssen. Das CAN-Telegramm für Antworten hat folgendes Format:
| Datenfeld |
Datenbreite |
Bedeutung |
| ID |
11 Bit |
Gateway ID, immer -1, 0x7ff |
| Extended ID |
16 Bit |
Controllernummer |
data[0] |
1 Byte |
Kommando geodert mit MSG_RESULT |
data[1] |
1 Byte |
Antwortcode |
data[2,3] |
2 Bytes |
Gerätenummer |
data[4] |
1-4 Bytes |
optional weitere Information (s.u.) |
Die Antwortcodes schlüsseln sich wie folgt auf:
| Antwort |
Antwortcode |
Bedeutung |
| MSG_OK |
0 |
Erfolgreich ausgeführt |
| MSG_QUEUE_FULL |
1 |
Die Kommando-Queue ist voll. Das Kommando kann nicht entgegengenommen werden |
| MSG_UNKNOWN_CMD |
2 |
Das empfangene Kommando ist unbekannt |
| MSG_PENDING |
3 |
Das durch das Kommando adressierte Gerät hat schon ein Kommando in der Warteschleife |
| MSG_IGNORED |
4 |
Das Kommando wurde ignoriert |
| MSG_QUEUED |
5 |
Das Kommando wurde eingereiht (z.B. bei Weichen) |
| MSG_NOT_CONFIGURED_YET |
6 |
Der Controller hat bisher noch keine Konfiguration erhalten. Kommando ignoriert. |
| MSG_NO_UNITNO_DEFINED |
7 |
Der Controller hat kein Gerät, das die adressierte Unit-Number hat. Kommando ignoriert. |
| MSG_UNITTYPE_WRONG |
8 |
Das Kommando passt nicht zum adressierten Gerät. Kommando ignoriert. |
| MSG_RESET_PENDING |
9 |
Reset ausstehend, Kommandos außer PING werden igoriert, die CAN Message Queue wird solange abgearbeitet, wie der Reset aussteht. |
| MSG_UNITNO_MISSING |
10 |
Unitnumber wurde nicht angegeben. Das passiert durch Standard Frames wobei Extended Frames gefordert sind |
| MSG_UNIT_NOT_FOUND |
11 |
Das unter der angegebenen Unitnumber adressierte Gerät ist nicht konfiguriert. Kommando ignoriert |
| MSG_NOT_IN_CONFIG_MODE |
12 |
Konfigurationskommando wurde empfangen, obwohl Controller sich nicht im Konfigurationsmodus befindet. Kommando ignoriert |
| MSG_BOOTED |
13 |
Startup Meldung |
| MSG_CHECKSUM_ERROR |
14 |
Der Flash-Vorgang wurde mit einer falschen Prüfsumme beendet. |
| MSG_ID_NOT_CHANGED |
15 |
Eine Änderung der ID ist nicht erfolgt, weil diese schon auf den angeforderten Wert gesetzt war. |
| MSG_INFO |
16 |
Die Antwort hat nur informativen Charakter |
| MSG_ID_CHANGE_DISABLED |
17 |
Das Setzen der ID muss gejumpert erfolgen. |
| MSG_HARDWARE_MISMATCH |
18 |
Die Hardware stimmt nicht mit dem Flash-Request überein, zusätzlich werden zwei Bytes zurückgegeben: Die geforderte Hardware und die vorgefundene Hardware. |
| MSG_SWITCH_FAILED |
19 |
Der Schaltvorgang einer Weiche mit Endabschaltung war nicht erfolgreich. |
Es gibt Antwortmeldungen, die noch zusätzliche Informationen enthalten. Das sind speziell die Abfragecodes auf Gerätezustände.
| Kommando |
Antwortcode |
data[4] |
data[5] |
data[6] |
data[7] |
| GETDIR | MSG_RESULT |
MSG_OK |
1 für Weiche links/Abzweig, 2 für rechts/Kreuz |
|
|
|
| SETLFT | MSG_RESULT |
MSG_OK |
Dauer der Schaltzeit in Timerquanten (optional) |
|
|
|
| SETRGT | MSG_RESULT |
MSG_OK |
Dauer der Schaltzeit in Timerquanten (optional) |
|
|
|
| GETRBS | MSG_RESULT |
MSG_OK |
0 für Gleis frei, 1 für Gleis belegt |
|
|
|
| RESET | MSG_RESULT |
MSG_BOOTED |
Das AVR-Register MCUCSR. Dieses enthält den Grund für den Reset. |
|
|
|
| CFGEND | MSG_RESULT |
MSG_OK |
Zahl der konfigurierten Geräte |
|
|
|
| QRYBUF | MSG_RESULT |
MSG_OK |
Empfangspufferbelegung |
Sendepufferbelegung |
|
|
| QRYERR | MSG_RESULT |
MSG_OK |
0 |
Fehlerflags des MCP2525 CANERR-Registers |
|
|
| QRYERR | MSG_RESULT |
MSG_OK |
1 |
CAN-Empfangsfehlerzahl |
|
|
| QRYERR | MSG_RESULT |
MSG_OK |
2 |
CAN-Sendefehlerzahl |
|
|
| QRYERR | MSG_RESULT |
MSG_OK |
3 |
Fehlerflags des MCP2525 CANERR-Registers |
CAN-Empfangsfehlerzahl |
CAN-Sendefehlerzahl |
| GETVER | MSG_RESULT |
MSG_OK |
0 |
Firmware Version |
|
|
| GETVER | MSG_RESULT |
MSG_OK |
1 |
Firmware Revision Lowbyte |
|
|
| GETVER | MSG_RESULT |
MSG_OK |
2 |
Firmware Revision Highbyte |
|
|
| GETVER | MSG_RESULT |
MSG_OK |
3 |
Firmware Version |
Firmware Revision Lowbyte |
Firmware Revision Highbyte |
| FLASH_CHECK |MSG_RESULT |
MSG_OK oder MSG_CHECKSUM_ERROR |
Prüfsumme der FLASH_DATA-Kommandos |
tatsächliche Prüfsumme aus dem Flash-Speicher |
|
|
| SENSOR | MSG_RESULT |
MSG_OK |
Sensortyp |
Sensorwert |
Anzahl betroffener Geräte |
|
Hierbei erfolgt zusätzlich zum Antwortcode der Zustand des Gleises bzw der Weiche. Diese Kommandos können sowohl vom Controller initiiert werden, falls eine Zustandsänderung aufgetreten ist, als auch auf Anfrage hin gemeldet werden.
Signalsymbole
Für das Kommando SETSGN gibt man das originale Signalsymbol der Bahn an. Diese gelten je nach Bauform sowohl für Lichtsignale, als auch für Formsignale.
| Signalcode |
Wert |
Bedeutung |
| SIGNAL_OFF |
0 |
Aus (Kann bei Hauptsignal kombiniert mit Vorsignal vorkommen) |
| SIGNAL_HP0 |
1 |
Hp0 (= Hp00 bei Ausfahrsignal) |
| SIGNAL_HP1 |
2 |
Hp1 |
| SIGNAL_HP2 |
3 |
Hp2 |
| SIGNAL_VR0 |
4 |
Vr0 |
| SIGNAL_VR1 |
5 |
Vr1 |
| SIGNAL_VR2 |
6 |
Vr2 |
| SIGNAL_SH0 |
7 |
Sh0 |
| SIGNAL_SH1 |
8 |
Sh1 (= Hp0/Sh1 bei Ausfahrsignal) |
| SIGNAL_TST |
9 |
Test (Alle Birnchen/LEDs einschalten zur Funktionsüberprüfung) |
Sensortypen
Für das Kommando SENSOR werden Sensorwerte übermittelt, die von unterschiedlichen Sensortypen stammen können.
| Sensortyp |
Wert |
Bedeutung |
| SENSOR_LIGHT |
1 |
Helligkeit |
| SENSOR_TEMP |
2 |
Temperatur |
Bitbreiten / Byte-Bedarf
Hier die benötigten Bytes im (tatsächlich physikalisch übertragenen) Protokoll:
| Item |
Bedeutung |
Bytes |
| Kommando |
|
1 |
| SNo |
Signal-Nr. (kodiert als Extended ID) |
2 |
| GNo |
Gleis-Nr. (kodiert als Extended ID) |
2 |
| RNo |
Signal-Nr. (kodiert als Extended ID) |
2 |
| Pinx |
I/O-Nr. am Controller (device) |
1 |
| Sym |
Signalsymbol |
1 |
Umsetzung des Protokolls und Hardware
Die Umsetzung erfordert zwei Typen von Mikrocontrollern:
- CAN-Knoten, der die Geräte ansteuert
- CAN/RS232 Gateway, der die Verbindung mit dem PC aufnimmt.
Der PC setzt CAN-Frames über die serielle Schnittstelle ab. Die Kodierung erfolgt binär, also nicht im Text/ASCII-Format. Ein Frame wird folgendermaßen übertragen:
| Feld |
Offset |
Datengröße |
Bedeutung |
| length |
0 |
1 Byte |
Anzahl Datenbytes. Diese muss mind. ein Byte haben, max. 8 Bytes |
| status |
1 |
1 Byte |
Bit 4 muss für einen Extended Frame gesetzt sein |
| sid |
2 |
2 Bytes |
Die Standard ID. Diese entspricht der Controller ID |
| eid |
4 |
4 Bytes |
Die Extended ID. Diese entspricht der Unitnumber |
| data |
6 |
1-8 Bytes |
Die Kommandos, wie sie hier beschrieben sind checksum |
Die Kommunikation ist bidirektional. Alles, was das Gateway mit Controller ID 0 erreicht, wird über RS232 im oben genannten Format weitergeleitet. Der Empfang und das Senden geschieht Interrupt-gesteuert über zwei getrennte Ringbuffer, die die zu verarbeitenden Bytes aufnehmen. Ferner existiert ein Ringbuffer für empfangene CAN-Frames. Die Verarbeitung der Frames geschieht im Hauptprogramm. Somit sind die Interruptroutinen sehr kurz. Falls ein Pufferüberlauf auftritt, wird das durch eine LED jeweils für CAN und RS232 signalisiert.
Die Frame Rate über die serielle Schnittstelle und dem CAN-Bus sollte relativ gleich sein. Dazu wird eine Bitrate von 115200 Baud auf RS232 und 125000 Bit/s auf dem CAN-Bus gewählt. In der folgenden Tabelle wird dem Rechnung getragen. Dabei hat der Mikrocontroller die externe Frequenz von 14.7456 MHz.
| Datenbytes |
RS232 |
SPI |
CAN Standard Frame |
CAN Extended Frame |
| 0 |
1920 |
92160 |
2840 |
1953 |
| 1 |
1645 |
83781 |
2403 |
1736 |
| 2 |
1440 |
76800 |
2083 |
1562 |
| 3 |
1280 |
70892 |
1838 |
1420 |
| 4 |
1152 |
65828 |
1644 |
1302 |
| 5 |
1047 |
61440 |
1488 |
1201 |
| 6 |
960 |
57600 |
1358 |
1116 |
| 7 |
886 |
54211 |
1250 |
1041 |
| 8 |
822 |
51200 |
1157 |
976 |
