Wieder mal so ein eher technischer Artikel, also nur für diejenigen die sich für die Details in dem Bereich interessieren.
Dieses Element muss ja irgendwie dazu überredet werden dass die Anzeige-LED blinken.
Wie ich schon geschrieben hatte sind die Elemente mit dem Raspberry ja über einen SPI Bus verbunden. Auf diesem erfolgt der Datenaustausch vom Master zu den einzelnen Slaves, die Antworten der Slaves können nur gesendet werden wenn der Master aktiv dazu auffordert. Wie im IT Bereich üblich erfolgt die Kommunikation byteweise, an dieser Stelle gibt es dann ein spezielles Protokoll aus Nachrichten die aus 1 oder 5 Bytes bestehen können.
Die allgemeine Syntax ist <Befehl> <AddrH> <AddrL> <Wert1> <Wert2> wobei bei manchen Befehlen sowohl Werte als auch Adressinformation entfallen.
Das erste Byte stellt den auszuführenden Befehl dar. Aktuell gibt es folgende Befehle:
Der Raspberry sendet die 1 oder 5 Bytes. In den Befehlsbytes sind immer die beiden höchstwertigen Bits gesetzt, das ist gleichzeitig auch die eindeutige Kennung für ein Befehlsbyte. In den Datenbytes dürfen dann die beiden höchstwertigen nicht beide gesetzt sein, d.h. es sind Werte von 0 bis 191 zulässig.
Dementsprechend können - rein theoretisch - 38884 Elemente adressiert werden, das sollte auch für den größtmöglichen Stelltisch reichen.
Die Daten legen bitweise fest welche LED am Element leuchten soll. Hat das jeweilige Element keine LED an der Position dann passiert halt nichts.
Diese Werte können beliebig miteinander kombiniert werden mit der Ausnahme, dass gelber und roter Gleisstreifen nicht zusammen angesteuert werden können, aber dafür gibt es ja auch keine Notwendigkeit.
Der Wert1 legt fest welche Elemente leuchten wenn der Blinktakt ein ist (letzter gesendeter Befehl 0xC3), der Wert 2 legt fest welche Elemente leuchten wenn der Blinktakt aus ist (letzter gesendeter Befehl 0xC2). Damit kann das Blinken aller Anzeigeelemente realisiert werden (auch wenn das natürlich nicht für alle sinnvoll ist). Die Ansteuerungssoftware (dazu kommt später mehr) muss dann wissen welche Leuchten bei welchem Status (einer Fahrstraße, einer Weiche usw.) auf welchem Element angesteuert werden müssen. Das einzelne Element weiß nichts über Fahrstraßen, Signale oder was auch immer.
Einzige Ausnahme dabei ist das Zählerfeld, das bekommt direkt numerisch den anzuzeigenden Wert:
Links: PushVal 32 17 0 97, rechts PushVal 32 17 2 79; 32 17 ist die Adresse des Elements, 0 97 ist der Wert 97, 2 97 ist der Wert (2 * 128) + 97 = 353.
Alle Logik welche Fahrstrasse wie eingestellt wird, welches Signal und welche Weiche wann gestellt wird und alles andere ist in der Steuersoftware auf dem Raspberry. Die Elemente des Gleisbildpultes sind reine Anzeige und Eingabeelemente. Im Prinzip wie beim Vorbild, nur dass es eben kein Relaisraum sondern stattdessen ein Computer ist der mit den Tasten und Anzeigen interagiert.
Zum Abfragen der Tasten werden die Befehle 0xC8 und 0xC9 verwendet. In beiden Fällen antworten nur die über die Adresse angesprochenen Elemente, alle anderen bleiben stumm. Der Raspberry muss dann also die Antwort der jeweiligen Taste zuordnen. Die Antwortbytes 1 bis 3 sind immer 0, weil da keiner antwortet, denn erst nach dem Eintreffen des 3. Bytes ist ja über die Adresse klar wer gemeint ist.
Bei 0xC8 wird genau ein einzelnes Element abgefragt. Dieses sendet im 4. Byte den aktuellen Status seiner 7 Ausgänge (an denen die LED dran sind) und den Status seines Eingangs, also des angeschlossenen Tasters. Für die Abfrage eines Elementes ist 0xC8 gar nicht so sehr gedacht, sondern eher für die Abfrage eines I/O für Gleisbelegtmelder oder auch für die Abfrage eines Weichendecoders zur aktuellen Weichenstellung etc.
Bei 0xC9 wird eine Gruppe von Elementen abgefragt, und zwar alle 16 Elemente ab der (auf einen durch 16 teilbaren Wert abgerundeten) abgefragten Adresse. Das erste Element sendet seinen Status im ersten (niedrigstwertigen) Bit des 4. Antwortbytes, bis zum 8. Element im letzten (höchstwertigen) Bit des 4. Antwortbytes. Die Elemente 9 bis 16 senden analog im 4. Antwortbyte. Auf diese Weise können mit einem Pollzyklus 16 Tasten abgefragt werden.
Technisch passiert dass, indem jedes Element bei genau dem Bit was relevant ist den auf dem Element befindlichen Rückmeldetransistor durchsteuert, dieser also die DO Datenleitung auf Masse zieht, während alle anderen Elemente den Transistor nicht durchsteuern und damit keinen Einfluss auf die Kommunikation nehmen.
Insgesamt habe ich versucht, sowohl die Kommunikation mit den Einzelelementen als auch die Software auf den PIC der Einzelelemente so simpel wie möglich zu halten. Alle komplexeren Funktionen liegen in der Ansteuersoftware des Raspberry.
Die Kommunikation zu den externen Sensoren, Signalen und Servoansteuerungen wird auch nach diesem Schema aufgebaut. In dem Zusammenhang kommen wahrscheinlich noch ein paar Befehle und neue Attribute dazu. Allerdings kann der Teil gegebenenfalls auch auf dem Raspberry an andere Hardware angebunden werden.
Dieses Element muss ja irgendwie dazu überredet werden dass die Anzeige-LED blinken.
Wie ich schon geschrieben hatte sind die Elemente mit dem Raspberry ja über einen SPI Bus verbunden. Auf diesem erfolgt der Datenaustausch vom Master zu den einzelnen Slaves, die Antworten der Slaves können nur gesendet werden wenn der Master aktiv dazu auffordert. Wie im IT Bereich üblich erfolgt die Kommunikation byteweise, an dieser Stelle gibt es dann ein spezielles Protokoll aus Nachrichten die aus 1 oder 5 Bytes bestehen können.
Die allgemeine Syntax ist <Befehl> <AddrH> <AddrL> <Wert1> <Wert2> wobei bei manchen Befehlen sowohl Werte als auch Adressinformation entfallen.
Das erste Byte stellt den auszuführenden Befehl dar. Aktuell gibt es folgende Befehle:
| Befehl- Byte | Anzahl Bytes | Befehlsinhalt | Datenbytes | Rückgabe |
| 0xC0 | 1 | PushVal - Setze den anzuzeigenden Wert und stelle diesen sofort auch dar | Adresse + Werte | - |
| 0xC1 | 1 | Push - Alle Anzeigeelemente zeigen das Bild zum letzten gesetzten Wert an; mit diesem Kommando kann ein synchrones Umstellen von mehreren Elementen erreicht werden wenn das gewollt ist | - | - |
| 0xC2 | 5 | BlinkAus - Blinktakt aus, alle Elemente stellen das zu Wert1 gehörige Bild dar | - | - |
| 0xC3 | 5 | BlinkEin - Blinktakt ein, alle Elemente stellen das zu Wert2 gehörige Bild dar Mit diesen beiden Taktbefehlen wird das synchrone Blinken aller Elemente erreicht | - | - |
| 0xC4 | 1 | Reset - Alle Werte auf Initialstatus | - | - |
| 0xC5 | 1 | SetVal - Setze den anzuzeigenden Wert, ohne diesen sofort auch darzustellen; das Anzeigebild wird dann mit Push aktiviert | - | - |
| 0xC8 | 5 | Status - Mit diesem Befehl wird der Status eines Elementes abgefragt (Taste gedrückt j/n) | Adresse + Leerbytes | Statuswert |
| 0xC9 | 5 | Gruppenstatus - Mit diesem Befehl wird der Status einer Tastengruppe abgefragt (Tasten gedrückt j/n); da ja jeder Tastendruck nur ein Bit benötigt können hier 16 Tasten in einer aufsteigenden Adressenreihenfolge gemeinsam abgefragt werden | Adresse + Leerbytes | Statuswert |
| 0xD0 | 5 | GetAdresse - Mit diesem Befehl wird die Adresse eines Elementes abgefragt, Details weiter unten | 4 Leerbytes | Adresse |
| 0xD1 | 5 | SetAdresse - Mit diesem Befehl wird die Adresse eines Elementes gesetzt, Details weiter unten | Adresse + Leerbytes | - |
| 0xD2 | 5 | AendAdresse - Adrese ändern, mit diesem Befehl wird die Adresse des angesprochenen Elementes auf eine neue Adresse geändert | Adresse + Neue Adresse | - |
| 0xD3 | 5 | SetAdresse2 - Mit diesem Befehl wird die Adresse aller gesteckten Elementes abgefragt, Details weiter unten | Leerbytes + Neue Adresse | - |
| 0XD4 | 5 | GetAdresse2 - Mit diesem Befehl wird die Adresse eines Elementes gesetzt, Details weiter unten | Leerbytes | Adresse |
| 0xD5 | 5 | Identifikation - Das adressierte Element blinkt mit allem was es zu bieten hat | Adresse + Leerbytes | - |
| 0xD6 | 5 | GetVersion - Abfrage der auf dem Element installierten Softwareversion | Adresse + Leerbytes | Software- |
Der Raspberry sendet die 1 oder 5 Bytes. In den Befehlsbytes sind immer die beiden höchstwertigen Bits gesetzt, das ist gleichzeitig auch die eindeutige Kennung für ein Befehlsbyte. In den Datenbytes dürfen dann die beiden höchstwertigen nicht beide gesetzt sein, d.h. es sind Werte von 0 bis 191 zulässig.
Dementsprechend können - rein theoretisch - 38884 Elemente adressiert werden, das sollte auch für den größtmöglichen Stelltisch reichen.
Die Daten legen bitweise fest welche LED am Element leuchten soll. Hat das jeweilige Element keine LED an der Position dann passiert halt nichts.
| Bit | Funktion |
| 0b10000000 (128) | Der gelbe Gleisstreifen leuchtet |
| 0b01000000 (64) | Der rote Gleisstreifen leuchtet |
| 0b00100000 (32) | Der gelbe Gleisstreifen im Abzweig leuchtet (bei Weichen) oder Zusatz-LED 5 leuchtet (gibt es noch kein Element) |
| 0b00010000 (16) | Der rote Gleisstreifen im Abzweig leuchtet (bei Weichen) oder Zusatz-LED 4 leuchtet (im Signalfeld) |
| 0b00001000 (8) | Der Gleispunkt leuchten |
| 0b00000100 (4) | Zusatz-LED 3 leuchtet |
| 0b00000010 (2) | Zusatz-LED 2 leuchtet |
| 0b00000001 (1) | Zusatz-LED 1 leuchtet |
Diese Werte können beliebig miteinander kombiniert werden mit der Ausnahme, dass gelber und roter Gleisstreifen nicht zusammen angesteuert werden können, aber dafür gibt es ja auch keine Notwendigkeit.
Der Wert1 legt fest welche Elemente leuchten wenn der Blinktakt ein ist (letzter gesendeter Befehl 0xC3), der Wert 2 legt fest welche Elemente leuchten wenn der Blinktakt aus ist (letzter gesendeter Befehl 0xC2). Damit kann das Blinken aller Anzeigeelemente realisiert werden (auch wenn das natürlich nicht für alle sinnvoll ist). Die Ansteuerungssoftware (dazu kommt später mehr) muss dann wissen welche Leuchten bei welchem Status (einer Fahrstraße, einer Weiche usw.) auf welchem Element angesteuert werden müssen. Das einzelne Element weiß nichts über Fahrstraßen, Signale oder was auch immer.
Einzige Ausnahme dabei ist das Zählerfeld, das bekommt direkt numerisch den anzuzeigenden Wert:
Links: PushVal 32 17 0 97, rechts PushVal 32 17 2 79; 32 17 ist die Adresse des Elements, 0 97 ist der Wert 97, 2 97 ist der Wert (2 * 128) + 97 = 353.
Alle Logik welche Fahrstrasse wie eingestellt wird, welches Signal und welche Weiche wann gestellt wird und alles andere ist in der Steuersoftware auf dem Raspberry. Die Elemente des Gleisbildpultes sind reine Anzeige und Eingabeelemente. Im Prinzip wie beim Vorbild, nur dass es eben kein Relaisraum sondern stattdessen ein Computer ist der mit den Tasten und Anzeigen interagiert.
Zum Abfragen der Tasten werden die Befehle 0xC8 und 0xC9 verwendet. In beiden Fällen antworten nur die über die Adresse angesprochenen Elemente, alle anderen bleiben stumm. Der Raspberry muss dann also die Antwort der jeweiligen Taste zuordnen. Die Antwortbytes 1 bis 3 sind immer 0, weil da keiner antwortet, denn erst nach dem Eintreffen des 3. Bytes ist ja über die Adresse klar wer gemeint ist.
Bei 0xC8 wird genau ein einzelnes Element abgefragt. Dieses sendet im 4. Byte den aktuellen Status seiner 7 Ausgänge (an denen die LED dran sind) und den Status seines Eingangs, also des angeschlossenen Tasters. Für die Abfrage eines Elementes ist 0xC8 gar nicht so sehr gedacht, sondern eher für die Abfrage eines I/O für Gleisbelegtmelder oder auch für die Abfrage eines Weichendecoders zur aktuellen Weichenstellung etc.
Bei 0xC9 wird eine Gruppe von Elementen abgefragt, und zwar alle 16 Elemente ab der (auf einen durch 16 teilbaren Wert abgerundeten) abgefragten Adresse. Das erste Element sendet seinen Status im ersten (niedrigstwertigen) Bit des 4. Antwortbytes, bis zum 8. Element im letzten (höchstwertigen) Bit des 4. Antwortbytes. Die Elemente 9 bis 16 senden analog im 4. Antwortbyte. Auf diese Weise können mit einem Pollzyklus 16 Tasten abgefragt werden.
Technisch passiert dass, indem jedes Element bei genau dem Bit was relevant ist den auf dem Element befindlichen Rückmeldetransistor durchsteuert, dieser also die DO Datenleitung auf Masse zieht, während alle anderen Elemente den Transistor nicht durchsteuern und damit keinen Einfluss auf die Kommunikation nehmen.
Insgesamt habe ich versucht, sowohl die Kommunikation mit den Einzelelementen als auch die Software auf den PIC der Einzelelemente so simpel wie möglich zu halten. Alle komplexeren Funktionen liegen in der Ansteuersoftware des Raspberry.
Die Kommunikation zu den externen Sensoren, Signalen und Servoansteuerungen wird auch nach diesem Schema aufgebaut. In dem Zusammenhang kommen wahrscheinlich noch ein paar Befehle und neue Attribute dazu. Allerdings kann der Teil gegebenenfalls auch auf dem Raspberry an andere Hardware angebunden werden.
