Hallo Thomas,
mich würde mal interessieren, ob Du auch die Software des Decoders selbst programmieren möchtest.
Dazu kenne ich drei Methoden:
Fire-And-Forget DCC (a ca 1 Mio Instructions / sek.): Man versuchts einen schnellen Assembler Code zu schreiben , der periodisch abtastets und die Befehl in der selben Periode (Timer-Routine) ausführt. Dabei kommt man bei "intelligen" Decodern die mehr als Ein/Aus schalten schnell an die Grenzen. In der MoBa Literatur oft mit wenig sinnigen 22 us Abtastinterval implementiert.
Das oft veröffentlichte Fire-And-Forget DCC taugt aus flgendem Grund nix: Die Hauptaufgabe eines DCC Decoders sind Soll-Stellung empfangen und kontinuirlcih über rel. lange Zeitspannen dafür zu sorgen , das sich die Iist Werte der Ausgänge den Sollwerten annähern bis die erreicht sind. Ein Loko hält nich sofort an, sonder das dauert, auch wenn es nur einen Stop-Befehl gibt. Ein guter Weichendecoder beherrscht auch (konfigurierbare) Schaltintervalle, und kann sogar eine Schaltvorgang jederzeit abrechen und mit der Ausführung eines wirdersprüchlcihen Befhels beginnnen. Dazu brauct es wenigstens das zweite Verfahren:
Double-Threaded DCC (ab ca 2 Mio Instructions / sek.): Der auch Loko-taugliche goldene Mittelweg: Man tastet periodisch das Signal in der Timer-Interrupt-Routine ab, und qeued die decodierten Bits in einen FiFo. Die Time-Interrupt-Routine kann dann später auch noch andere wichtige peridische Echtzeit Jobs intelligenter Decoder übernehmen. Das eigentliche Parsen der Befehle passiert dann im Hauptprogramm, welchen Bits für Bits aus dem Fifo holt und in dem man dann "alle Zeit der Welt" für beliebige interpretierende Auswertung hat. Die beste Methode für hochwertiges ungestörtes dcc (und auch mfx). Abtastrate 32 oder 40 us. Ost West-Richung erkennend (HLU), Zeit für AD-Wandlung zwecks Assymetrieauswertng (ABC).
Hochsprachen-Kanonen DCC (ab ca 10 Mio Instructions / sek.): Man programmiert in C, Man tastet nicht , sondern misst den Abstand zwischen den Flankenwechseln. Vorteil, man erkennt auch Flanken anderer Protokolle. Nachteil: Selbst Flanken von Störungen laufen Gefahr den DCC-Bit-Strom zu stören. Empfindliches Verfahren und bei einem wirklichen Multi-Prot-Decoder eine Interpreter-Thread für jedes Protokoll ratsam.
Noch ein Spezialfall zur Zeitintervallberechnung: Diese kann beim Einsatz eine langsamen Optos im Signalweg oder eines ansonsten hochkapazitiven Eingangs von Vortiel sein, das diese evtl. die Flankendauer für den uC soweit reduziert, das keine Flanke sondern nur noch ein wenige us andauernder Impuls ankommt. Dies taugt aber pratiksch nur für langsame Optos, da - wie gesagt - bei diesem Verfahren jede kleinste Störung einen ungedämpften Eingang aus dem Takt wirft.
Wofür der Decoder langfristig einsetzbar ist, entscheidet sich also bereits am Anfang bei der Implementierung der notwendigen Interruptroutine und der Modularität der ersten Version. Wenn keine Real-Time Debugging (ist meist unbezahlbar) zur Verfügung steht, sollte die von Anfang an absolut fehlerfrei sein. Bitte unter widrigsten Umständen testen bis der Arzt kommt
. Der Rest (Features) ist dann eher Fleissarbeit. Eine umfangreiche Doku, was bei dcc alles zu bedenken ist, dindet man unter
www.nmra.org. Wenn Du das alles durchgelesen hast, bist Du gut informiert, welche grundlegenden qualitativen und funktionalen Anforderungen dcc an eine Programm-Gerüst stellt.
Viele Grüße
Frank
