Neu überarbeitet am 24. Jan. 2009. Neues PC-Programm, neue Decodersoftware.
Jeder Teilnehmer an einem Bussystem braucht zumindest einen Betriebsparameter,
seine Busadresse, wenn er "ansprechbar" sein soll. Ansonsten ist er auf das "Mithören " beschränkt.
Diese Adresse muss bekannt sein, d.h. im Zweifelsfall ermittelbar. Für die D&H Lokdecoder wurde
das Problem so gelöst, dass sie bei geeigneter Inbetriebnahme ohne Aufforderung ihre Kenndaten
aussenden. Ob sich dafür ein Systemteilnehmer interessiert, sprich die Daten empfängt und
auswertet, das ist dem Decoder zunächst egal. Mit dieser Methode ist sichergestellt, dass ein "unbekanntes"
Wesen zu identifizieren ist.
Gleichzeitig wurde den Decodern eine Eigenschaft mitgegeben, die es ermöglicht, den Decoder in
eine Betriebsart zu versetzen in der er Daten aufnehmen und abspeichern kann.
Dieser Automatismus hat aber seinen "Preis", denn er funktioniert nur dann, wenn nur ein einziger
Decoder "auf dem Bus" ist. Wenn mehrere gleichzeitig sprechen hat man mit dem Zuhören nichts als
Schwierigkeiten. Deswegen gibt es aber das Programmiergleis und die Programmierfunktion, die
nur hier und mit einem Decoder funktioniert, der Systembus bleibt dabei aus dem Spiel.
Funktions-Decoder
der ersten Generation hatten zur Einstellung der Adresse eine Hardwarelösung, DIL-Schalter oder Federhaken.
Zusätzliche Parameter gab es nicht.
Meine Servodecoder sind auch hardwareprogrammiert, denn die Daten sind im Programm des
Mikroprozessor festgelegt. Dies ist nicht besonders "elegant", benötigt aber keinerlei Hardware. Ein daraus
resultierender weiterer Nachteil ist, dass die die Parameter bisher nicht auslesbar sind.
Die Voraussetzungen für eine "intelligentere" Lösung ist am SX-Bus gegeben, denn er ist bidirektional, also
sind die Busteilnehmer dialogfähig, sofern Datenfelder und Adressraum zur Verfügung stehen. Dies ist aber
im SX-System nicht ausreichend vorgesehen.
Vereinbart sind Systemkanäle, von Adresse 104 bis 111, die aber mit Funktionen der Zentrale und der
Programmierung von Lok-Decodern vorbelegt sind oder für die Parameterübergabe nach DCC reserviert
bleiben sollen.
Unter der Voraussetzung, dass nur SX-Bus Komponenten geplant sind, kann man natürlich weitere Adressen
zu privaten Systemadressen erklären und Dialoge zur Parameterübergabe definieren.
Die Dialogeröffnung ist damit aber noch nicht ohne weiteres möglich. Das ist der Grund für die "Programmiertaste"
an allen mir bekannten Decodern. Mit diesem Signal wird der Programmier-Mode im Prozessor aktiviert und
ggf. auch beendet.
Als Alternative bleibt nur eine "Kommandoadresse" die von allen Busteilnehmern immer mitgelesen wird.
Das setzt aber die Kenntnis der Adresse voraus, von der man aber nicht in jedem Fall ausgehen kann, und die
dann auch nur an einen Teilnehmer vergeben sein darf. Eine unerwünschte Einschränkung.
Die Datenfelder:
Flexibel einsetzbare Decoder benötigen nicht nur ein Adresse, sondern auch Parameter. Die Servodecoder
brauchen die Stellpositionen und evt. die Stellgeschwindigkeit pro Kanal. Für den Programmiervorgang kann
man einen Adressraum auf dem SX-Bus reservieren. Uwe Magnus wählt in seinen Selbstbauprojekten die
Adresse 0 für die Decoderadresse und aufsteigende Adressen für das "Kommandobyte" und die Parameter.
Das ist kein Problem, wenn diese unteren Adressen frei sind oder aber für Lokdecoder verwendet werden und
die Gleisspannung beim Programmieren ausgeschaltet bleibt.
Die Eingabe von Zahlenwerten ohne geeignete Software auf dem PC kann ein "mühsames" Geschäft sein,
wegen der Binärdarstellung z.B. auf dem Trix Control Handy. Decoderangepasste Software kann natürlich
wesentlich eleganter und weniger fehlerträchtig gestaltet werden durch Einbau von Plausibilitätsprüfungen.
In jedem Fall scheint es sinnvoll zu sein, dass der Decoder beim Aufruf der Programmierfunktion die aktuellen
Daten auf die vereinbarten Adressen legt und bis zum Ende die "online" Busdaten als Parameter verwendet.
Das erleichtert den Test und reduziert die Schreibvorgänge auf dem EEPROM.
Der Decoder W_deco4_para:
Für den 4-Kanal Servodecoder habe ich eine Softwareversion programmiert die das Verändern der
Betriebsparameter über den SX-Bus ermöglicht.
Voraussetzung ist eine "Programmiertaste" die am PORT B , PB7 angeschlossen ist (nach GND-Potential).
PORT B, PB6 ist ein Ausgang, der eine LED ansteuern könnte als Signal "Programmierung in Betrieb"
Verwendet werden die SX-Adressen 0 bis 5 zur Parameterübergabe,
Sie sollten freigehalten werden.
Programmier Ablaufsteuerung:
Für die Programmierung wird die Adresse K001 verwendet. Die Idee ist auf dem "Befehlskanal"
im oberen Halbbyte die Befehlsnummer ( neudeutsch CmdID) und im unteren eine Wertkennung
(ParaID) zu übertragen. D.h. 15 Befehle und 15 Werte können bearbeitet werden.
Bei der Dialogabwicklung ist das Zeitverhalten auf dem SX-Bus und in der Zentrale zu beachten
und die Tatsache, dass die Zentrale mit dem Interface ein passiver Partner ist. Auskunft gibt sie
nur auf Anfrage per Leseauftrag, Aktionen erfolgen nur auf Schreibbefehl. Übertragen wir stets
nur ein Byte. Die Zentrale sendet zum Zeitpunkt des Leseauftrages den aktuellen Inhalt des Bus-
Abbildes im Speicher. Daraus folgt, dass eine aktuelle Decoderinformation erst nach Ablauf der
Zykluszeiten auf dem SX-Bus und in der Zentrale richtig weitergegeben werden können.
Ebenso werden Befehle vom Steuerprogramm erst Zyklen später vom Decoder erkannt, weil ja
die Zentrale zuerst den Befehl auf den Bus legen muss, von dem der Decoder dann liest. Die
Bitsynchronität hilft nur dann, wenn die Zentrale im Synchronteil geschrieben hat bevor der Decoder
liest.
Die Kennung für das PC-Programm, "Decoder im Programmiermode" verwende ich Bit 5 (32, 0x20)
im Zustandskanal der Zentrale K106, d.h. mit Betätigung der Programmiertaste schreibt der Decoder
"rücksichstslos" dieses Bit in der Zentrale, unter der Annahme der Modellbauer weiß was er tut.
Auch im Programmiermode sind die Steuerbits der Basisadresse wirksam, und die "vor Ort" Kontrolle
ist möglich.
Die Eingabe der Programmierdaten mit einem Handsteuergerät ist zwar möglich, aber sehr fehler-
trächtig. Das PC-Programmier-Programm hilft weiter:
Mit diesem Hilfsmittel klappt die Programmierung wesentlich "eleganter". Das Programm ist mit C# geschrieben,
muss installiert werden und benötigt MS .NET2 oder höher.
Nach dem Start listet DecoProg die verfügbaren COM-Schnittstellen auf. Default sind COM1 und 9600Bd gewählt.
Click in die Listenfelder ändert die Auswahl.
Mit "StartLesen" wird die Verbindung zur Zentrale getestet und Bit 5 im Zustandskanal106 auf "32" geprüft.
Wenn diese Voraussetzung erfüllt ist, wird der Decoder aufgefordert seine Basisdaten, Adresse, Halbkanal und
Servogeschwidigkeitswert zu senden. Die entsprechenden Felder in Decoprog werden gefüllt.
Ab sofort sind Bitstellen der Adresse bidirektional wirksam. Die Servonummer ist nicht vorbesetzt, erst nach
Click in der Gruppe "Servonummer" werden die Positionen vom Decoder abgerufen und die "Schieber" getellt.
Änderungen sind "sofort" nach der SX-Gedenkpause wirksam, ebenso die Wahl Fahrzeit und Halbkanal.
Zum Adresswechsel ist die neue Nummer einzugeben und wird nach Rückfrage gesendet und wirksam.
Der "heisse" Button ist das Speichern im EEPROM. Der Decoder startet daraufhin mit neuen Werten,
der Programmiermode ist verlassen.
Mit "Stoplesen" führt DecoProg einen Reset durch.
Servo-Unarten und Erkenntnisse daraus:
Meine Tests habe ich mit "Billig"-Servos ES05 und ES30 gemacht und festgestellt dass die Stromimpulse
beachtliche Größen annehmen (können) die einen 1A-7805-TO220 überfordern.
Gemessen habe ich an 0.8 Ohm vor dem 5Volt Regler. Schon 1 Servo bringt es auf knapp 1A Spitze.
Bei zwei Servos gibt es dann dies Zufälligkeit mit addiertem Spitzenwert:
Vielleicht hilft dieses Wissen dem geneigten Hobbyelektroniker beim Schaltungsentwurf.
Ich gebe dazu keine Empfehlung (mehr)!
Decoder-Software:
Die Kommentare sollten für das Verständnis ausreichen. Die Takt-Interrupt Routine habe ich
um die Geschwindigkeitssteuerung für die Servos erweitert. Für das Abspeichern der
Bitstellen werden ca. 80 Byte verwendet um ausreichend Lebensdauer zu erreichen.
Das AVR Servo-Decoder-Programm für einen ATtiny2313 gibt's hier: w_deco4_para.asm
Die PC Software, gerne auch mit C# Quelle für VS 2005 auf Anfrage per email.
Winfried Steinhart, im Januar 2009