OpenDCC - Zentrale für DCC - Softwareerläuterung

OpenDCC - Zentrale für DCC - Details zur Software

Jumper / Betriebsarten
JP2	JP1	Mode
offen	offen	Betrieb als Zentrale, Befehlssatz für eine Emulation der Intellibox ® von Uhlenbrock. Der Befehlssatz kann auch auf Lenz-Emulation umgestellt werden (per #define in config.h, danach neu übersetzen).
offen	zu	Betrieb als DMX Steuerzentrale, Bedienung durch Tasten (Remote Control noch nicht enabled) (Hinweis: Das wird entfallen, bitte die DMX-Ansteuerung mit dem Decoder realisieren)
zu	offen	Betrieb als HSI88 Interface, Befehlssatz kompatibel zu Littfinski
zu	zu	Testbetrieb: Die LEDs blinken, alle Daten auf der Schnittstelle werden mit 19200 Baud einfach wieder zurückgesendet.

Lenz

www.atmel.com

maximalen Durchsatz

BiDi

FAST CLOCK

HARDWARE.H: Einstellen des Prozessors und Portdefinitionen
CONFIG.H: Einstellen der Betriebsarten, Speichergrößen, usw.
DCCOUT.C: Erzeugung des DCC-Protokolls (DCC Encoder)
DMXOUT.C: Erzeugung des DMX-Protokolls (DMX Encoder)
ORGANIZER.C: DCC-Kommandoverwaltung (Repeat, Refresh)
LENZ_PARSER.C, IBOX_PARSER.C: Übersetzen der PC-Befehle in die entsprechenden internen Aufrufe
LENZ_PROGRAMMER.C, IBOX_PROGRAMMER.C: Abarbeiten von Programmierbefehlen
RS232.C: Schnittstelle zum PC (mit Interrupt + Fifos)
STATUS.C: Zustandsverwaltung, Timertick, Keys und LEDs
S88.C: Auswerten der Rückmelder
XPNET.C: Busmaster für Xpressnet
MAIN.C: Init, Loop

DCC-Erzeugung

Wie sieht DCC überhaupt aus?
Bei DCC wird das Gleissignal immer mit konstanter Spannung, aber wechselnder Polarität übertragen. Durch die Zeitpunkte der Polaritätswechsel wird die Information kodiert, welche an die Lok / Weiche übertragen wird.

Die Codierungsregel ist relativ einfach: zwei Polaritätswechsel nach je 58µs bedeuten 1, zwei Wechsel nach je 116µs bedeuten 0. Da es immer 2 Polaritätswechsel sind, ist das Ausgangssignal (normalerweise) gleichspannungsfrei und die Polarität am Empfänger ist egal. Eine 1 dauert also zweimal 58µs=116µs, eine 0 ist doppelt so lang.

Auf diese Art und Weise wird ein serieller Bitstrom an die Lok gesendet. Um nun dem Empfänger eine Wertung dieser Bits zu ermöglichen, muß der Datenstrom gegliedert werden. Bei DCC geschieht das durch Aufteilung in Preamble, Nutzbytes und Prüfsumme. Die Preamble kennzeichnet jeweils den Beginn einer neuen Nachricht. Preamble, Nutzbytes und Prüfsumme (je 8 Bits) sind jeweils durch eine 0 voneinander getrennt.

Damit die Preamble leicht vom Empfänger leicht erkannt werden kann, muß sie nach einer Regel aufgebaut sein, die im normalen Datenstrom nicht vorkommt. Bei DCC ist die Preamble eine Folge von mind. zwölf 1 Bits. Da ja die Nutzbytes nach 8 Bits durch eine 0 getrennt sind, kommt diese lange 1-Sequenz im normalen Datenstrom nicht vor.

Nach der Preamble kommen zwei bis fünf Nutzbytes (jeweils durch 0 getrennt), welche i.d.R. die Adresse und die Fahrstufe enthalten. Das ursprüngliche DCC-Format sah nur 2 Nutzbytes vor, diese wurde später bis zu 5 Nutzbytes erweitert. An diese Nutzbytes wird die 8-Bit XOR-Summe dieser Nutzbytes als Prüfsumme (checksum) angehängt. Wenn der Empfänger nun die XOR-Summe über die alle empfangenen Bytes bildet, dann muß sich 00000000 ergeben, nur dann ist die Nachricht gültig.

Welche Bedeutung haben die einzelnen Bits?
Mit dem ersten Byte wird eine generelle Aufteilung in Lokbefehle, Zubehördecoder (Accessory Decoder) und Programmierbefehle (Service Mode) vorgenommen. Alle folgenden Bytes sind dann je nach Befehlsgruppe unterschiedlich codiert.

Erstes Byte
0:	00000000:	Die Adresse 0 ist als Broadcast für alle Lokomotiven reserviert.
1-127:	0AAAAAAA:	Beginnt das erste Byte mit einer 0, so handelt es sich um einen Lokfahrbefehl mit kurzer Adresse.
128-191:	10AAAAAA:	Der Bereich (128-191)(einschließlich) ist für Zubehördecoder.
192-231:	11000000-11100111:	Es handelt sich um einen Lokbefehl mit langer Adresse, die weiteren Adressbits folgen dann im nächsten Byte.
232-254:	11101000-11111110:	Dieser Bereich ist reserviert für Erweiterungen.
255:	11111111:	Damit wird keiner adressiert (IDLE).

Im Prinzip beginnt eine DCC-Message immer mit einem (oder zwei Adressbytes), gefolgt von einem (oder mehreren) Befehlsbytes, in denen die jeweilige Aktion bzw. Lokgeschwindigkeit kodiert ist.
Das DCC-Protokoll ist im Laufe der Jahre immer wieder erweitert worden; Dabei haben sich leider verschiedene Darstellungen für die Geschwindigkeit (14,27, 28 und 126 Fahrstufen) etabliert.
Die Bedeutung der weiteren Bytes kann man bei der NMRA nachlesen.

Beispiel 1: Fahrbefehl an Lok 5, Fahrstufe 4 (von 14 Stufen), vorwärts
Es wird ein Befehl mit 3 Byte geschickt:
```
Preamble Startbit  Adressbyte (=0AAAAAAA)
         Startbit  Datenbyte  (=01DCSSSS)
         Startbit  Pr�fsumme
         Stopbit
```
Dabei bedeutet im Adressbyte AAAAAAA [A6 .. A0] die Lokadresse und und im Datenbyte D [Direction=Richtung], C [Lichtfunktion], SSSS [Speed]. Das DCC-Telegramm wird wie folgt zusammengebaut:
```
    Adressbyte = (Lokadresse & 0x7F);
    Datenbyte = 0b01000000 | (speed & 0x0F) | (Richtungsbit << 5);
    Pr�fsumme  = Adressbyte ^ Datenbyte;
```
Das Richtungsbit ist 1 für vorwärts, Null für rückwärts.

Preamble 0 Adressbyte 0 Datenbyte 0 Prüfsumme

11111111111111 0 00000101 0 01100100 0 01100001

Beispiel 2: Weichenansteuerung per DCC
Es wird ein Befehl mit 3 Byte geschickt:
```
Preamble Startbit  Adressbyte 10AAAAAA
         Startbit  Datenbyte  1AAA1BBR
         Startbit  Pr�fsumme
         Stopbit
```
Dabei bedeutet im Adressbyte AAAAAA [A5 .. A0] und im Datenbyte AAA [A8 .. A6], wobei die Adressen A8 bis A6 invertiert übertragen werden. BB ist die lokale Adresse am Decoder (0,1,2,3), R ist das Outputbit, d.h. welche Spule aktiviert werden soll. In der Zentrale wird nun z.B. aus der von PC übermittelten Adressen wie folgt das DCC-Telegramm zusammengebaut:
```
   Adressbyte = 0x80 + (adresse & 0x3F);
   Datenbyte  = 0x80 + (adresse / 0x40) ^ 0x07) * 0x10;
   Pr�fsumme  = Adressbyte ^ Datenbyte;
```
Die Adresse 0 ist als Broadcast reserviert, so dass die erste Weichengruppe bei Adresse 1 liegt. Leider gibt es bei den PC-Protokollen der einzelen Zentralen kleine, aber störende Unterschiede im Adressbereich und in der Interpretation des Outputbits sowie des Activatebits (im obigen Beispiel die 1).

Uhlenbrock (Intellibox) beschreibt wie folgt (und überträgt auch so):
'r' (red = thrown) and ('r' may also be spec'd as '0')
'g' (green = closed) and ('r' may also be spec'd as '1')
Der Adressbereich in der PC Schnittstelle beginnt dagegen entgegen der Dokumentation bei 1. Das heißt, der erste Decoder liegt auf Adressen 1 ... 4; Die Intellibox sendet auch nie den Abschaltbefehl auf das Gleis, auch wenn dieser vom PC aus angefordert wird.

Lenz beschreibt das Richtungsbit als D2 mit folgendem Text:
D2: D2 = 0 bedeutet Ausgang 1 der Weiche gewählt.
D2 = 1 bedeutet Ausgang 2 der Weiche gewählt.

Allerdings läßt es sich nirgends rausfinden, was Ausgang 1 oder 2 bedeutet. An Hand eines Logfiles scheint rot und grün vertauscht zu sein. OpenDCC bildet diese Invertierung (abschaltbar) durch eine CV nach.
Dafür beginnen die Weichenadressen bei Lenz bei der Adresse 0 und den Abschaltbefehl gibt es.

Allgemeine Regeln für die Pakete
- Präambel: Ein Empfänger muß eine Präambel aus mind. 12 Einsern erkennen, eine Preamble mit weniger als 10 Einsern muß er verwerfen; eine Zentrale muß mind. 14 Einser senden. Das Stopbit darf gleichzeitig zur Präambel des nächsten Befehls gehören. Wenn die Zentrale im Programmiermode betrieben wird, dann muß die Präambel 20 Bits lang sein.
- Länge: Solche Pakete können von 3 bis 6 Bytes lang sein, jedoch ist bei allen Paketen das letzte Byte eine XOR-Prüfsumme über die vorherigen Bytes.
- Zeitlicher Abstand: Pakete an den *gleichen* Decoder müssen 5ms Abstand haben. Nach spätestens 30ms muß wieder irgendein DCC Packet gesendet werden, damit die Decoder nicht die Lust verlieren und auf analog umschalten. Mit der Einführung von Railcom besteht für Dekoder die Anforderung, Pakete 'nahtlos' erkennen zu können, d.h. es können zwei Pakete direkt hintereinander an den gleichen Dekoder geschickt werden.

Wie werden nun diese Bits in OpenDCC erzeugt?
Es wird der Timer 1 benutzt, dieser wird im CTC-Mode (Clear Timer on Compare-Match) betrieben, d.h. nach Erreichen des Compare-Wertes beginnt der Timer wieder bei Null. Zugleich wird beim Erreichen des Comparevalues das DCC-Bit per Hardware umgeschaltet. Die Ausgänge der Komparatoren sind mit dem Leistungstreiber verbunden und erzeugen das Gleissignal.

Gleichzeitig mit dem Neustart des Timers wird ein Interrupt ausgelöst, die Interruptroutine trägt die Compare-Werte für das nächste Bit ein, je nach dem ob 0 oder 1 ausgegeben werden soll. Jeder Polaritätswechsel des DCC-Signals erzeugt also einen Interrupt, jeder zweite Interrupt schaltet um ein Bit innerhalb der DCC-Message weiter.

Beginnend mit der Preamble hangelt sich die Interruptroutine nun Bit um Bit durch die DCC-Message, wobei sie auch noch gleich den Overhead des DCC Protokolls (sozusagen Layer 1) mit erledigt, d.h. es wird die Preamble und die Prüfsumme (XOR-Byte) in der ISR errechnet und mit ausgegeben.

Das "nächsthöhere" Programm muß also nur die Nutzbytes zusammenstellen und an DCCOUT übergeben (im Datenarray "next_message"). Die Übergabe ist durch ein Semaphor ("next_message_count") verriegelt - DCCOUT übernimmt nur, wenn dieses Semaphor größer Null ist und decrementiert bei jeder Übernahme dieses Semaphor um 1.

S88.C, Einlesen der Rückmelder

drei

Meldung an den PC erfolgt

STATUS.C, Timertick und Zustandsverwaltung

  LED_RS232_OFF;
     led_pwm.rs232_rest = 20000L / TICK_PERIOD;
     led_pwm.rs232_ontime = 50000L / TICK_PERIOD;
     led_pwm.rs232_offtime = 150000L / TICK_PERIOD;
     break;

ORGANIZER.C, Lokverwaltung und Befehlsverwaltung

OpenDCC

Das Regelwerk des Organizers
f�r Lokfahrbefehle: Lokgeschwindigkeit in den Lokspeicher eintragen. Alle Queues und Buffer nach dieser Lok durchsuchen, ob ev. da noch ein �lteres Kommando an diese Lok wartet - wenn ja, dieses ersetzen. Geschwindigkeit gr��er oder kleiner als die aktuell gefahrene Geschwindigkeit? - falls kleiner: -> Befehl in die High Priority Queue. - falls gr��er (oder Funktion bzw. Accessory): -> Befehl in die Low Priority Queue. Wenn ein Befehl aus einer Queue verarbeitet worden ist, dann kommt er anschlie�end in den Repeat Buffer: Speedbefehle mit 3 Repeats, Accessory-Befehle mit 2 Repeats. Bei der Gleisausgabe gilt dann folgende Reihenfolge: 1. High Priority Queue. wenn diese leer ist: 2. Low Priority Queue. wenn diese leer ist: 3. Repeatbuffer. wenn dieser auch leer ist: 4. Lokspeicher refreshen. (jeweils in der Sequenz: Speed, Funkt1, Speed, Funkt2, Speed, Funkt3, Speed)

Das Regelwerk des Organizers

f�r Lokfahrbefehle: Lokgeschwindigkeit in den Lokspeicher eintragen.

Alle Queues und Buffer nach dieser Lok durchsuchen, ob ev. da noch ein
�lteres Kommando an diese Lok wartet - wenn ja, dieses ersetzen.

Geschwindigkeit gr��er oder kleiner als die aktuell gefahrene Geschwindigkeit?
   - falls kleiner: -> Befehl in die High Priority Queue.
   - falls gr��er (oder Funktion bzw. Accessory):
                    -> Befehl in die Low Priority Queue.

Wenn ein Befehl aus einer Queue verarbeitet worden ist, dann kommt er
anschlie�end in den Repeat Buffer:
    Speedbefehle mit 3 Repeats, Accessory-Befehle mit 2 Repeats.

Bei der Gleisausgabe gilt dann folgende Reihenfolge:
   1. High Priority Queue.   wenn diese leer ist:
   2. Low Priority Queue.    wenn diese leer ist:
   3. Repeatbuffer.          wenn dieser auch leer ist:
   4. Lokspeicher refreshen. (jeweils in der Sequenz:
             Speed, Funkt1, Speed, Funkt2, Speed, Funkt3, Speed)

Anzahl von Lokomotiven und Lokformat

P50X-ASCII	LS {Lok#, [Format], [Steps]} als Format ist nur "2" (=DCC) erlaubt.
P50X-BINÄR	0x86: XLokCfgSet - length 1+3; byte1+byte2 = addr, byte3 = format

Zusammenfassung der Funktionsaufrufe des ORGANIZER
init_organizer(void) organizer_ready(void) do_loco_speed_f(addr, speed, format) Geschwindigkeit und Format einer Lok einstellen do_loco_speed(addr, speed) Geschwindigkeit einer Lok einstellen do_loco_func_grp0(addr, funct) Lichtfunktion do_loco_func_grp1(addr, funct) Funktionen f1-f4 do_loco_func_grp2(addr, funct) Funktionen f5-f8 do_loco_func_grp3(addr, funct) Funktionen f9-f12 do_accessory(addr, output, activate) Weichenschaltbefehl do_all_stop(void) Bremsbefehl

Zusammenfassung der Funktionsaufrufe des ORGANIZER

init_organizer(void)
organizer_ready(void)
do_loco_speed_f(addr, speed, format)   Geschwindigkeit und Format einer Lok einstellen
do_loco_speed(addr, speed)             Geschwindigkeit einer Lok einstellen
do_loco_func_grp0(addr, funct)         Lichtfunktion
do_loco_func_grp1(addr, funct)         Funktionen f1-f4
do_loco_func_grp2(addr, funct)         Funktionen f5-f8
do_loco_func_grp3(addr, funct)         Funktionen f9-f12
do_accessory(addr, output, activate)   Weichenschaltbefehl
do_all_stop(void)                      Bremsbefehl

RS232.C, Kontrolle der seriellen Schnittstelle

PROGRAMMER.C, Servicemode

MAIN.C, Hauptprogramm

DCC Counter: Dieser Interrupt veranlaßt das Neuprogrammieren des Counters 1. Damit werden die Sequenzen für DCC0 und DCC1 auf den Vergleichsausgängen dieses Zählers erzeugt.
Timer Tick: damit werden Tastaturabfragen und Timeouts gesteuert.
UART Rx: Empfangenes Byte wird in Fifo abgelegt.
UART Tx: Ein Byte im Sendefifo wird abgeschickt.

int main(void)
  {

    init_main();                       // all io's
    init_dccout();                     // timing engine for dcc
    init_organizer();                  // engine for command repetition,
                                       // memory of loco speeds and types
    init_rs232();                      // isrs+fifos from/to pc
    init_interrupt();
    init_tick();                       // 5ms timer tick
    init_programmer();                 // dcc programmer
    init_parser();                     // command parser

    set_opendcc_state(RUN_OFF);        // abgeschaltet

    while(1)
     {
       run_state();                    // check short and keys
       run_organizer();                // let run command organizer
       run_parser();                   // check commands from pc
     }
  }

Links

ShowDCC

(Offenbar hat digitoys das tool vom Web entfernt, aber das Internet vergißt nichts, siehe hier.)

Preamble	0	Adressbyte	0	Datenbyte	0	Prüfsumme
11111111111111	0	00000101	0	01100100	0	01100001