Du meinst natürlich das Gerät welches mir die Bitfolgen schicken soll um meine Entwicklung zu testen. Klarerweise muss diese Bitfolge, also die unterschiedlichen Amplidudenlängen, programmierbar sein.
Ich habe die Tabelle und die Darstellung aus #1 so verstanden:
- Jedes Bit beginnt mit einer fallenden Flanke endet vor der fallenden Flanke des nächsten Bits
- die Zeiten beider Pegel sollen symmetrisch sein
- 'ne "1" soll insgesamt 116µs dauern, 'ne "0" 200µs (plusminus Toleranzen, klar) - oder meinst Du mit "unterschiedlichen Amplitudenlängen" noch was anderes?
Du willst jetzt irgendwelche … äh … Slave Geräte entwickeln und/oder testen, die über diesen Weg angesprochen werden können.
Du willst also irgendwelche Binären Telegramme (auf einem immer noch nicht näher genannten Weg) erzeugen, in Dein AWG/Gateway/Mikrocontroller einspeisen, der die TTL-Bits in diese... äh … frequenzmodulierten (Dino, wie heißt das korrekt?) Bits umwandelt, und diese (über eine Push-Pull-Endstufe) ausgibt.
Du hast eine eher spezielle Anforderung, die aber eigentlich nicht sonderlich schwer umzusetzen ist - warum also nicht selbst das Gateway umsetzen?
Mein Vorschlag aus #4 (den auch Dino aufgegriffen hat) war, daß Du im einfachsten Fall dein Bit-Telegramm am PC in irgendein Terminalprogramm eintippst und absenden läßt. Sinnigerweise vorrausgehend die Anzahl der Telegramm-Bits mitsenden.
Der Controller liest aus dem ersten empfangenen Byte also die Anzahl der zu sendenden Bits aus (und ggf auch die Anzahl der zu empfangenen Bytes); ab dem zweiten Byte werden alle beim Empfang zwischengespeichert, bei hinreichend hoher Baudrate (über den Daumen ab 11kBaud) kannst Du sofort nach Empfang des zweiten Bytes (das erste Telegramm-Byte) loslegen lassen.
erstes Bit aus dem Byte schieben und entsprechend die beiden Compare Register schreiben (eins für die steigende Flanke, eins für den Überlauf = fallende Flanke). Den eigentlichen Timer einen Takt vor den Überlauf setzen und starten, dann den Ausgangstreiber aktivieren (bzw die Gegentaktendstufe).
Das alles im UART-Empfangs-IRQ.
Im CompareB-IRQ wird jetzt jedesmal ein Bit weitergeschoben (und ggf vorher das nächste Byte aus dem Puffer geladen), und die Compare-Register für das nächste auszugebende "Bit" vorbereitet. Bei PWM erfolgt der Schreibzugriff auf die Compare-Register gepuffert Änderungen die hier im CompareB-IRQ gemacht werden, werden erst beim Überlauf (CompareA) wirksam. Also das nächste Bit.
Bei Überlauf des Bitzählers (das letzte Bit wird also gerade ausgegeben, die steigende Flanke wurde gerade erzeugt) wird der das Bein vom PWM abgekoppelt und fest auf high gelegt, und außerdem der CompareA-IRQ (Timerüberlauf) scharfgemacht.
Im CompareA-IRQ wird die Gegentakt-Endstufe abgeschaltet, und der Timer angehalten, anschließend entschärft sich der IRQ selbst.
Bei 'nem effektiven Timertakt von 1MHz (also 8MHz und Vorteiler=8) ist es nicht sonderlich überraschend, daß für 'ne "1" 115 ins CompareA und 57 ins CompareB des 8Bit-Timers zu laden sind; für'ne "0" entsprechend 199 bzw 99.
Clever könnte das festlegen der Compares etwa so ablaufen:
115 mit LDI in ein Rechenregister laden
bei gesetztem nächsten Bit in Telegramm-Byte mit SBRS die das folgende LDI skippen
199 in dasselbe Rechenregister laden
Telegramm-Byte schieben
Rechenregister nach CompareA ausgeben
Rechenregister schieben
Rechenregister nach CompareB ausgeben
7 Takte
Wenn jedes Telegramm mit elf einsen beginnt, muß man das natürlich nicht unbedingt jedesmal durch den UART jagen.
Ja. Das Signal transportiert sowohl die Energie für die Motoren als auch die Befehle für die Decoder. Daher sind es in der Regel symmetrische Signale. Gleichgerichtet ergibt es eine "schönes" DC Spannung und die positive Halbwelle verwendend kommen die Nullen und Einsen für die Datenübertragung daher.
und
Die Decoder hängen zwar am Gleissignal, werden jedoch mit DC Spannung fremdversorgt. Digitalstrom ist teuer. Es kommen nur die Befehle vom DCC Gleissignal.
Wie ist das jetzt konkret zu verstehen?
Die gesamte Anlage wird bereits über irgendein DCC-Master-Gerät gesteuert, und Du willst jetzt mit Deinem Entwicklungswerkzeug-Gerät zusätzliche Steuersignale erzeugen?
Oder wird der vorhandene Master dazu getrennt?
Oder soll die Entwicklung und Testung getrennt von der Anlage erfolgen (also nur der Slave am (noch nicht vorhandenen Gateway/AWG/Controller-Werkzeug)?)
Brauchst Du beim letzten Fall dann überhaupt 'ne zusätzliche Gegentakt-Endstufe, oder könnte der Controller das Signal direkt erzeugen?