Re: [DDL-ML] Decoder 6080

[Roman Lauer <lauerr@gmx.de>]

Hallo,

Ich habe mich in den letzten Wochen mit der Portierung von DDL auf
Windows und in Delphi beschäftigt. Damit mußte ich mich auch
zwangsläufig mit den verschiedenen Protokollen und wie sie über die
serielle Schnittstelle erzeugzt werden, beschäftigen. 

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).

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.

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.

MfG

Roman Lauer


Wolfgang Kissner wrote:
> 
> Hallo Achim,
> 
> >NEIN! Die serielle Schnittstelle liefert normalerweise (wenn man sie
> >bestimmungsgemd_ betreibt) ein ganz anderes Datenformat. Da in diesem
> >Format Start- und Stop-Bits vorgesehen sind, die in dieser Form weder bei
> >M* noch bei DCC vorkommen, gehe ich davon aus, dass DDL usw. die
> >TxD-Leitung des UART direkt manipuliert.
> 
> Das stimmt nicht ganz. Ich habe mit die Quelle von DDL zwar nicht angesehen
> aber die Idee, mit der seriellen Schnittstelle DCC-Signal zu erzeugen, kommt
> aus der Mac-Welt. DCC-Telegramme kann man bei einer bestimmten
> Übertragungsrate unter Einbeziehung von Start- und Stopbits durch
> Generierung normaler Zeichenketten erzeugen. Das läuft zwar an der
> zugelassenen Toleranzgrenze aber es funktioniert. Vermutlich baut DDL auf
> diesem Verfahren auf; aber das kann Torsten wohl besser beantworten.
> 
> mfG
> Wolfgang Kissner