[Vorab-Frage nach Interesse] RPi2 - SPI Multiplexer

Mit dem RPi ist Echtzeit oft nicht gewährleistet und z.B. allein ein 
MCP23S17 kostet mehr als etliche MCUs mit Timern, ADCs und anderer 
umfangreicher Peripherie.

Da Du danach fragst: Für mich ist das Nix.

Torsten C. schrieb:
> Mit dem RPi ist Echtzeit oft nicht gewährleistet

"Echtzeit" ist ja immer eine Frage der Definition ;-)

Für mich ist der RPi eher "Großhirn", gerade mit einem *bian als OS. 
Linux und Interrupts, das ist ja so "echtzeitig" wie die Zeitung von 
gestern, selbst mit superoptimierten Kernel-Treibern.

Kleinhirn und Reflexe überlasse ich kleinen uCs. Unsereins, wenn er 
geschubst wird, denkt ja auch nicht erst nach "Oh, ein Impuls von 
hinten, liebes linkes Bein, bewege dich bitte einen Schritt vor!", 
sondern tut es einfach.

Mir geht es einfach darum, eine große Zahl von Sensoren abfragen bzw. 
Aktoren instruieren zu können, ohne dabei die ganze GPIO-Leiste zu 
belagern. Mit der mir vorschwebenden Lösung wären über maximal 9 Drähte 
über 2.000 Sensoren / Aktoren ansteuer- und abfrag- bzw. instruierbar. 
Natürlich nicht in Echtzeit, das ist ja auch gar nicht Sinn der Sache.

LG
Carsten

"Großhirn und Reflexe" sind eine gute Metapher. :-)

Ich kann mir keine Anwendung vorstellen, bei der ein solcher SPI-
Multiplexer sinnvoll ist. Falls es auch anderen so geht: Hast Du ein 
paar Beispiele?

Zu den Anwendungen ein paar Fragen:

* Welche Leitungslängen wären für die jeweilige Anwendung nötig, also
  wie sind die Slaves verteilt?

* Welche Taktrate (SCLK) ist für die jeweilige Anwendung mindestens
  nötig, also wie oft sollen alle 2.000 Slaves pro Sekunde angesprochen
  werden?

* Über 2.000 Tristate-Ausgänge aufeinander: Welche Treiber nimmst Du?

Für Funk-Mesh-Netzwerke, RS485, CAN, LIN, ... (ggf. mehrere) kenne ich 
im Gegensatz dazu massenhaft Anwendungen, die auch auch mit 2.000 
Slaves denkbar sind.

Daher meine Frage nach Deinen angedachten Anwendungen und den o. g. 
'Parametern'.

Carsten, ich wollte die Idee jetzt nicht tot reden.
Hast Du Urlaub oder andere Pläne?

Hallo Torsten,

Urlaub wäre schön :D Ich war einfach mit anderem Gedöns busy, etwa mit 
meiner kleinen Vorführung, wie praktisch es ist, einem "schlauen" RPi 
mit Fingerchen im Internet Steuerungsaufgaben der Art "Arbeitstag vs. 
arbeitsfreier Tag" zu überlassen statt einer tumben Zeitschaltuhr, die 
nur "Wochentag" kann. An Feiertagen können Heizung, Warmwasser, 
Parkplatzbeleuchtung ja ruhig aus bleiben, auch wenn es ein Dienstag 
ist.

Die Demo ist übrigens in großem Verblüffen geendet, als ich mit der 
Spracheingabe angefangen habe ^^

Aber um hier meine Gedanken mal zusammenzufegen... Ich habe freilich 
nicht vor, 2.000 Sensoren abzufragen, schon gar nicht über große 
Distanzen. Dafür gibt es bessere Technologien und Protokolle als simples 
SPI, das hast du ja selbst gesagt.

Mein hauptsächliches Anliegen ist, ganz einfache, echt günstige 
Sensoren(module, damit meine ich Kombinationen aus dem eigentlichen 
Sensor, also z.B. einem Fotowiderstand oder einem Temperaturfühler der 
Sorte KTY81-xxx, und einer SPI-fähigen "Fassade" (ist ein Begriff aus 
der Software-Entwicklung) wie dem guten, alten TLC549 oder einem 
ATtiny45) abfragen zu können. Wenn ich ATtinys oder ähnliche Kollegen 
benutze, könnte ich mir zwar ein eigenes Protokoll ausdenken, damit der 
Käfer sich angesprochen fühlt, bevor er Daten rausrückt, aber zB der 
TLC549 kennt ja nur eine Form von "Chip Select", und das wars.

Dass es da Industrie-Zeug gibt, das CE und VDE und Tüv und Co hat und 
auch über 200 m in einem Umfeld voller EM-Störungen funktioniert, weiß 
ich. Nur sind die entsprechenden Sensoren meist 1) abschreckend teuer, 
2) abschreckend groß und 3) in 95% der Fälle unnötig. Einen 
Selfmade-Sensor mit einem temperaturbeständigen "Gehäuse" aus 
medizinischem (also gesundheitlich unbedenklichem) Silikon und passender 
4-wire Zuleitung kriege ich für ein paar Euros hin und stecke es dann 
als "Kerntemperaturfühler" in den Braten in der Röhre und lasse die 
Aktoren (Schütz mit seeeehr langsamer, ständig nachgeführter PWM) die 
Heizspiralen ansteuern.

Oder wie wäre es mit einer etwas "intelligenteren", "selbst-bewussten" 
Licht-Steuerung? Unsereins geht doch in einen Raum und drückt auf den 
Lichtschalter, und was wir erwarten, ist, dass das Licht an geht, es 
also heller wird im Raum. Folgende Probleme könnten auftreten: ES -- der 
FI hat ausgelöst; der Schalter ist defekt; das Leuchtmittel ist defekt; 
die Leuchte selbst hat einen Defekt. ICH -- meine vegetativen Nerven im 
Arm oder in den Fingerspitzen oder mein Sehsinn funktionieren nicht.

Für eine "selbst-bewusste" Licht-Steuerung, die ihre Aktoren überwacht 
und auch sowas wie "Sinne" hat, wäre das ICH: "Die Steuerspannung ist 
nicht da/zu niedrig", "das Ansteuer-Relais ist defekt", "das Schütz ist 
defekt". In Umgebungen mit erhöhten Anforderungen etwa auch "einer 
meiner Fotosensoren ist defekt".

Das heißt also, dass ich nicht einfach einen GPIO-Pin auf einen 
Transistor, den Transistor auf ein Relais, das Relais auf ein Schütz, 
das Schütz auf die Leuchtmittel schalte, sondern ein Relais mit zwei 
Schließern verwende, dessen 2. Schließer eine Rückmeldung liefert, dass 
geschaltet wurde (=Relais funktioniert), ein Schütz mit einer 
Rückmeldung, dass geschaltet wurde (=Schütz funktioniert), einen 
Fotosensor, der meldet, dass es heller geworden ist (=Leuchte und 
Leuchtmittel funktionieren), oder ein Shunt, an dem der Strom gemessen 
wird so, dass erkennbar ist, ob alle Leuchtmittel auch leuchten. Für 
manche Dinge reichen digitale Werte, für manche sind analoge samt 
Führungsgrößen (Helligkeit ohne eingeschaltete Leuchten zB) nötig.

Nochmal, das Projekt ist deswegen IM MOMENT und FÜR MICH ein 
RPi2-Projekt, weil ich gerade einen RPi2 in der Mangel habe, um mich mit 
all diesen Technologien vertraut zu machen. Später ist es vielleicht ein 
ausgewachsener PC oder ein Arduino oder was-weiß-ich.

Letztlich ist das Thema einfach ein "SPI x SPI"-Bus-Protokoll, Auswahl 
eines SPI-fähigen Bauteils über SPI, und Datenübertragung vom/zum 
Bauteil ebenfalls über SPI. Wie "echtzeitig" das werden kann über 
wieviele Meter spielt dabei für mich JETZT erstmal gar keine Rolle. Die 
Probleme fangen ja schon damit an, dass ich den 74139 nur als LS, nicht 
als HC bekommen habe ;-)

LG
Carsten

Verstehe ich das richtig, und die Shift-Register sind nur für die 
Adressierung da? Und es werden 2 SPI Schnittstellen dafür genutzt,
eine für Adressierung und die andere für Daten?

> Mit einem 4-, 6- oder 8-Bit-Vergleicher, je nach Bedarf, und
> entsprechend 4x/6x/8x2-Jumpern oder -DIP-Schaltern lässt sich die Adresse
> des Slaves einstellen.

Würde ich so nicht machen.
Wenn ich schon 595 als Adressierer benutzen würde, dann würde ich die 
Ausgänge direkt als Chip Select Leitungen benutzen und da nicht noch 
komplizierte Adressdekoder dazu einsetzen. Die 595 kommen auf eine 
Platine, die kaskadierbar ist. Brauch ich mehr Chip Select Leitungen, 
dann kommt eben ein weiteres 595 Modul dazu, dass mir 8 weitere Chip 
Select dazu bringt. Den anderen SPI schleife ich ebenfalls über die 
Module, so dass jedes Modul über 8 komplette 4-Wire-SPI Anschlüsse 
verfügt.

Karl H. schrieb:
> Wenn ich schon 595 als Adressierer benutzen würde, dann würde ich die
> Ausgänge direkt als Chip Select Leitungen benutzen und da nicht noch
> komplizierte Adressdekoder dazu einsetzen. Die 595 kommen auf eine
> Platine, die kaskadierbar ist. Brauch ich mehr Chip Select Leitungen,
> dann kommt eben ein weiteres 595 Modul dazu

Wie gesagt, ich komme aus der Software-Architektur, und da ist das 
Vereinheitlichen DIE oberste Maxime. So gesehen würde ich eher "das Bein 
für die Zehen raushängen" und die Kaskadierbarkeit als Maxime 
hinstellen. Man könnte sich ein kaskadierendes Protokoll ausdenken, in 
dem Adressen und Daten "wandern". Nice!