Jetzt geht's dann mal ans Eingemachte, also ein bisschen konkreter in die technischen Details. Das wird diesmal viel Textbeschreibung und ist vor allem für die technisch interessierten Leser gedacht, für andere könnte es etwas trocken werden.
Wie schon zu sehen war, wird jedes einzelne Element über 6 Kontakte mit Strom und Daten versorgt:
Im blauen Kreis sind die 5 Kontakte für die Programmierung des auf der Platine verbauten Mikroprozessors mittels ICSP. Verwendet wird ein PIC16F15323 vom Microchip. Ich bin in meinem Bastelleben zuerst mit MicroChip in Kontakt gekommen, deswegen diese und keine Atmel. Letzteres wäre aber mit ziemlicher Sicherheit auch gegangen. Hier hab ich übrigens grade meine ganz persönliche Chipkrise, die nächsten PICs sind lieferbar im Mai oder Juni. Aber nicht in 2022 sondern in 2023. Bis dahin kann ich also nur noch verbauen was ich im Vorrat habe, und das ist nicht mehr all zu viel.
Der entscheidende Kontakt ist aber der rot eingekreiste. Der blaue spielt da nur in so fern rein dass deswegen +U und CS (ChipSelect) genau an den beiden Positionen liegen müssen wo sie liegen. Hier gibt es jetzt also 6 Kontakte:
Diese ist sowohl im Raspberry als auch in dem verwendeten PIC in Hardware umgesetzt und somit ganz leicht nutzbar (naja, ganz leicht ist relativ, auch das hat einige Stunden gebraucht bis ich es am laufen hatte).
Warum SPI? Es hätte durchaus auch Alternativen gegeben. Eine erste Alternative wäre z.B. I2C gewesen, das kommt mit 2 statt 4 Datenleitungen aus. Nachteil bei I2C ist das wesentlich genauere erforderliche Timing und die festgelegte Busfrequenz. Mit SPI habe ich hingegen die Möglichkeit, bei Problemen mit Störungen auf den Datenleitungen die Übertragungsfrequenz zu verringern um störungssicherer zu werden. Eine weitere Alternative aus dem Modellbahnbereich wäre LocoNet gewesen, das kommt sogar mit 1 Datenleitung aus. Problem dabei ist aber dass "volles" Loconet mehr Schaltungsaufwand auf JEDER Einzelplatine bedingt hätte und dass die Programmierung deutlich aufwändiger wäre weil es eben nicht schon in der Hardware drin steckt.
Rein Hardwaremäßig gäbe es aber auf jeden Fall die technische Möglichkeit die Platinen so wie sie sind unter Nutzung der DI und DO Leitungen mit einer kleinen Extraschaltung auf der Bodenplatte Loconet-fähig zu machen und auch die Software dafür ist definitiv machbar, nur habe ich für mich entschieden dass ich diesen Aufwand (vorerst) nicht treiben werde.
Nun ist SPI normalerweise für die Kommunikation von (Achtung, da bin ich sprachlich altmodisch) einem Master und einer Reihe von (normalerweise einzeln per ChipSelect angesprochenen) Slaves gedacht. Ich habe aber die Situation dass ich neben dem einen Raspberry als Master eine große Zahl von Elementen als Slaves ansprechen möchte, ohne das ich die alle einzeln per jeweils eigener CS Leitung adressieren könnte. Deshalb bekommt jedes einzelne Element in seiner Software eine eigene Adresse und alle Elemente werden im Übertragungsprotokoll für das Senden über diese Adresse angesprochen.
Da es nun wahrscheinlich Grenzen gibt wie viele Slaves ein Raspberry als SPI Master direkt ansprechen kann habe ich also zwischen den Raspberry und die Einzelelemente eine Transistor-Treiberstufe (eigentlich sogar 2) gesetzt.
Die erste (Bild links) sitzt direkt unten am Raspberry. Gelb eingekreist zwei der Transistoren (zwei weitere sind unter dem 26er Flachbandkabel), zusätzlich ist hier die Einspeisung der Versorgungsspannung für Pult und Raspberry mit drauf. Die zweite Treiberstufe sitzt (momentan) auf der Bodenplatine, wobei die wahrscheinlich in der finalen Version von da weg ebenfalls auf eine eigene Platine wandert. Der vierte Transistor der zweiten Treiberstufe (für die DO Leitung) sitzt dann auf jedem einzelnen Element.
Der Raspberry sendet dann einen Datenstrom auf den Leitungen aus, der aus Kommando, Adresse und Datenwert besteht. Alle Elemente empfangen alle Daten, reagieren aber nur wenn sie selbst adressiert sind. Die Rückmeldedaten über die DO Leitung werden von jedem Element ebenfalls nur dann gesendet wenn das Element adressiert ist. Diese Datenübertragung bedingt, dass (anders als z.B. bei LocoNet) der Zustand der Tasten vom Master gepollt werden muss und die Elemente nicht wirklich aktiv einen Tastendruck senden können. Lediglich die Entprellung der Taster erfolgt vorab schon lokal im PIC des Elements, so dass ein echter Tastenzustand abgefragt werden kann. Bei der aktuellen Tastenanzahl bin ich aber locker noch bei einer Pollrate von deutlich über 100 Abfragen pro Sekunde so dass das Polling keinen negativ spürbaren Effekt auf die Reaktionsgeschwindigkeit des Pultes hat.
Wie schon zu sehen war, wird jedes einzelne Element über 6 Kontakte mit Strom und Daten versorgt:
Im blauen Kreis sind die 5 Kontakte für die Programmierung des auf der Platine verbauten Mikroprozessors mittels ICSP. Verwendet wird ein PIC16F15323 vom Microchip. Ich bin in meinem Bastelleben zuerst mit MicroChip in Kontakt gekommen, deswegen diese und keine Atmel. Letzteres wäre aber mit ziemlicher Sicherheit auch gegangen. Hier hab ich übrigens grade meine ganz persönliche Chipkrise, die nächsten PICs sind lieferbar im Mai oder Juni. Aber nicht in 2022 sondern in 2023. Bis dahin kann ich also nur noch verbauen was ich im Vorrat habe, und das ist nicht mehr all zu viel.
Der entscheidende Kontakt ist aber der rot eingekreiste. Der blaue spielt da nur in so fern rein dass deswegen +U und CS (ChipSelect) genau an den beiden Positionen liegen müssen wo sie liegen. Hier gibt es jetzt also 6 Kontakte:
- +U, die Spannungsversorgung, ich arbeite mit +5 V. Das gibt mir die Möglichkeit bei den LED 2 in Reihe zu schalten, was bei +3.3 V nicht möglich gewesen wäre
- GND, die Masse für die Stromversorgung und als Bezug für alle Datenleitungen
- CS - ChipSelect
- Clk - Clock
- DI - Data In, für Daten vom Raspberry zum Element
- DO - Data Out, für Daten vom Element zum Raspberry (das ist die Info wenn eine Taste gedrückt oder losgelassen wird)
Diese ist sowohl im Raspberry als auch in dem verwendeten PIC in Hardware umgesetzt und somit ganz leicht nutzbar (naja, ganz leicht ist relativ, auch das hat einige Stunden gebraucht bis ich es am laufen hatte).
Warum SPI? Es hätte durchaus auch Alternativen gegeben. Eine erste Alternative wäre z.B. I2C gewesen, das kommt mit 2 statt 4 Datenleitungen aus. Nachteil bei I2C ist das wesentlich genauere erforderliche Timing und die festgelegte Busfrequenz. Mit SPI habe ich hingegen die Möglichkeit, bei Problemen mit Störungen auf den Datenleitungen die Übertragungsfrequenz zu verringern um störungssicherer zu werden. Eine weitere Alternative aus dem Modellbahnbereich wäre LocoNet gewesen, das kommt sogar mit 1 Datenleitung aus. Problem dabei ist aber dass "volles" Loconet mehr Schaltungsaufwand auf JEDER Einzelplatine bedingt hätte und dass die Programmierung deutlich aufwändiger wäre weil es eben nicht schon in der Hardware drin steckt.
Rein Hardwaremäßig gäbe es aber auf jeden Fall die technische Möglichkeit die Platinen so wie sie sind unter Nutzung der DI und DO Leitungen mit einer kleinen Extraschaltung auf der Bodenplatte Loconet-fähig zu machen und auch die Software dafür ist definitiv machbar, nur habe ich für mich entschieden dass ich diesen Aufwand (vorerst) nicht treiben werde.
Nun ist SPI normalerweise für die Kommunikation von (Achtung, da bin ich sprachlich altmodisch) einem Master und einer Reihe von (normalerweise einzeln per ChipSelect angesprochenen) Slaves gedacht. Ich habe aber die Situation dass ich neben dem einen Raspberry als Master eine große Zahl von Elementen als Slaves ansprechen möchte, ohne das ich die alle einzeln per jeweils eigener CS Leitung adressieren könnte. Deshalb bekommt jedes einzelne Element in seiner Software eine eigene Adresse und alle Elemente werden im Übertragungsprotokoll für das Senden über diese Adresse angesprochen.
Da es nun wahrscheinlich Grenzen gibt wie viele Slaves ein Raspberry als SPI Master direkt ansprechen kann habe ich also zwischen den Raspberry und die Einzelelemente eine Transistor-Treiberstufe (eigentlich sogar 2) gesetzt.
Die erste (Bild links) sitzt direkt unten am Raspberry. Gelb eingekreist zwei der Transistoren (zwei weitere sind unter dem 26er Flachbandkabel), zusätzlich ist hier die Einspeisung der Versorgungsspannung für Pult und Raspberry mit drauf. Die zweite Treiberstufe sitzt (momentan) auf der Bodenplatine, wobei die wahrscheinlich in der finalen Version von da weg ebenfalls auf eine eigene Platine wandert. Der vierte Transistor der zweiten Treiberstufe (für die DO Leitung) sitzt dann auf jedem einzelnen Element.
Der Raspberry sendet dann einen Datenstrom auf den Leitungen aus, der aus Kommando, Adresse und Datenwert besteht. Alle Elemente empfangen alle Daten, reagieren aber nur wenn sie selbst adressiert sind. Die Rückmeldedaten über die DO Leitung werden von jedem Element ebenfalls nur dann gesendet wenn das Element adressiert ist. Diese Datenübertragung bedingt, dass (anders als z.B. bei LocoNet) der Zustand der Tasten vom Master gepollt werden muss und die Elemente nicht wirklich aktiv einen Tastendruck senden können. Lediglich die Entprellung der Taster erfolgt vorab schon lokal im PIC des Elements, so dass ein echter Tastenzustand abgefragt werden kann. Bei der aktuellen Tastenanzahl bin ich aber locker noch bei einer Pollrate von deutlich über 100 Abfragen pro Sekunde so dass das Polling keinen negativ spürbaren Effekt auf die Reaktionsgeschwindigkeit des Pultes hat.
