RE: [DDL-ML] Decoder 6080

["Achim Schaefer" <Achim.Schaefer@ndbsoft.de>]

Hallo Roman,

die Seite von Maedig konnte ich soeben auch nicht erreichen. 

>Sowohl beim Motorolaformat als auch beim DCC Format werden normale
>Datenpackete mit Start und Stopbits gesendet. Für das Motorolaformat ist
>auf 
>http://rr-vs.informatik.uni-ulm.de/rr/docs/Maedig/Maedig.html
>eine sehr gute Erklärung. (Konnte Seite heute Abend nicht öffnen, Keine
>Ahnung ob das ein permanentes Problem ist).

Okay, mich erstaunt zwar, dass es anscheinend "passende" Muster gibt, aber
jetzt erinnere mich daran, dass ich vor etlichen Jahren auch einmal ein
Projekt gesehen habe, bei dem die Zeitzeichen-Signale des DCF77-Senders
über eine serielle Schnittstelle ausgewertet wurden, weil bei passend
eingestellter Baudrate auch halbwegs passende Zeichen interpretiert wurden.
Warum soll also das umgekehrte Verfahren nicht auch gehen.

>
>Bei meienr Portierung habe ich einen etwas anderen Ansatz als DDL
>gewählt. Es ist ein Objekt-Orientierter Ansatz. Ich habe zwei Klassen
>entworfen. Die eine Klasse ist erstmal ziemlich dumm. Dieser Werden
>Datenpackete übergeben, die die Klasse nach einer genauen Anweisung
>(Bitrate, Pausezeiten, Wiederholungen, ...) über die serielle
>Schnittstelle schickt. Diese Klasse weiß nichts von Motorola oder DCC
>Format. 
>Eine weitere Klasse nimmt die Konvertierung von Klartextinformationen
>(Loknummer, -richtung, sonderfunktion) in das binäre Format vor.
>Zusätzlich gibt sie jedem binären Packet eine Beschreibung mit, wie es
>übertragen werden soll.
>

Also einfach der heute übliche Programm-Aufbau, auch wenn sich die
wenigsten Programmierer wirklich daran halten *grins* (so etwas darf ich
sagen, bin schließlich auch Programmierer...)

>Bei dieser Entwicklung bin ich auch immer wieder auf die Timing-Probleme
>unter Windows gekommen. Bei der aktuellen Implementierung bin ich
>einfach so frei und versuche den Prozessor für mich zu belegen, in dem
>ich dem Thread, der die Daten verschickt eine sehr hohe Priorität gebe.
>Zumindest beim Motorolaformat bekomme ich so relativ stabile Signale
>hin, die aber immer noch jittern können. 
>
>Durch diese Probleme mußt4e ich immer wieder an einen extra Kontroller
>denken, der die Signalerzeugung übernehmen könnte, ohne daß ein nicht
>kontrollierbares Betriebssystem stört. Um den Aufbau einfach und die
>Software immer noch flexibel zu halten schwebt mir ein Kontroller for,
>der lediglich zwei oder drei Datenpackete mit samt einer kleinen
>Beschreibung speichert. Dieser Kontroller würde einfach diese Daten
>immer wieder aussenden. Der PC nimmt die Konvertierung und den Austausch
>der Datenpackete im Kontroller vor. So ein Aufbau sollte sich für wenige
>Euro umsetzen lassen. Damit wäre es auch Denkbar die Anbindung des
>Kontrollers nicht über serielle Schnittstelle sondern über USB zu
>realisieren. Timingprobleme sollten so beseitigt werden können und der
>PC wird auch nciht übermäßig belastet.

Man könnte das doch in etwa so aufbauen: deine "untere" Klasse, die die
Daten tatsächlich ausgibt, wird durch eine andere ersetzt, die die Daten
direkt (also noch in deinem internen Format) über die Schnittstelle an den
Kontroller ausgibt. Dieser hat eine (kleine) Queue und arbeitet die
empfangenen Befehle ab (in dem er Motorola oder DCC-Datenpakete daraus
generiert) und gibt sie an den Booster weiter...

Für USB spricht die einfachere Konfiguration, dagegen, dass die
Linux-Freunde damit ein Problem haben: USB wird zwar unterstützt, aber wo
soll der notwendige Treiber herkommen? Für Windows gibt es dagegen ein
Elektor-Projekt...

Soweit meine Zeit ausreicht (zum einen das erwähnte Großprojekt, dann die
auf den Aufbau wartende Anlage, nebenbei einen Handball-spielenden Sohn und
bald auch noch einen Enkel...) bin ich gerne bereit, an so etwas
mitzuarbeiten.

mfg

Achim