Hallo zusammen, bevor ich für die Galerie der toten Wiki-Seiten schreibe, frage ich hier mal rum, ob mein aktuelles Vorhaben von allgemeinem Interesse ist (also ob ich es nur für mich rudimentär und quer über die Verzeichnisse verstreut dokumentiere oder mir bissel mehr Mühe gebe, damit anderen auch was damit anfangen können). Der RPi2 hat ja bekanntlich (?) 2 SPIs auf dem GPIO, und viele SPI Slaves haben nur einen Chip Select Pin, der dazu auch noch invertiert sein kann. Damit viele viele viele Sensoren abfragen zu wollen, ist... knifflig. Mir schwebt nun zunächst vor, SPI1 vom RPi2 auf einen 74xyz595 zu legen. Der 74595 ist ein SPI-fähiges 8-Bit-Schieberegister mit Latch, sprich, man schiebt entlang eines Takts 8 Bits seriell hinein, und an den Ausgängen Q1-Q8 erscheint der Wert parallel und bleibt erhalten, eben SPI: CLK, MOSI und !CE. Auf diese Weise könnte man 256 Adressen auswählen. Das Timing des Chips ist ein wenig frickelig (siehe z.B. Beitrag "Definierter Einschaltzustand beim 74HC595"), aber ohne großen Aufwand handlebar. 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. Damit lassen sich also schon 16, 64, 256, eigentlich 14, 62, 254 Sensoren auswählen. "Eigentlich", weil mir eine Art supersimples "Metaprotokoll" vorschwebt, das aber erst im nächsten Schritt realisiert werden kann, zu dem weiter unten mehr steht. SPI0 wird als "4-wire" zu allen Slaves durchgeschleift, oder in der Praxis meistens wohl als 3-wire, also !CE, CLK und entweder MOSI oder MISO. Aktoren sind also auch "first class citizens": Aktor auswählen, über SPI die Befehle senden, und schwupps. Unter "Sensoren" und "Aktoren" verstehe ich hier übrigens SPI-fähige Chips, die die eigentlichen Sensoren abfragen oder die eigentlichen Aktoren einstellen. Dabei unterscheide ich zwischen "den Dummen" wie z.B. einem TLC549 als Sensor, und "den Schlauen" wie einem ATtiny45, denen man "noch was beibringen" kann. Wenn denn nämlich das ganze Gepuzzele aus 74595, Vergleicher usw. steht, würde ich das gerne in einen Atmel, z.B. ATtiny40, ATtiny1634, oder einen entsprechenden PIC überführen. Bei einem 4-Bit-Layout würden die Adressen 0x0 und 0xF freigehalten, und der uP würde bei 0x0 bei allen Sensoren und Aktoren ein Reset auslösen und bei 0xF den Aktoren einen gemeinsamen Befehl senden, sofern die Aktoren eben zu "den Schlauen" gehören, z.B. bei einer Haussteuerung "alles aus", bei einem Roboter "Halt!" etc. Um diese Idee von einem "Burst" noch zu steigern, würde ich vor den "Adress-Selektor" noch direkt 3 GPIO-Ports pinnen auf einen 74xzy139, also einen einfachen Bin-auf-Dezimal-Konverter (3-to-8-Demux), der Blöcke von Sensoren/Aktoren auswählt. Genau dann macht so eine "Broadcast-Adresse" (wie halt beim IP) Sinn, dass man im Notfall "durch die Landschaft" einen Befehl brüllen kann, und alle Slaves gehorchen. Im Moment schreibe ich zwar zu Testzwecken an Code, der sich auf einen TLC549 bezieht mit bloß einem 10k-Poti zwischen Kopf und Fuß, um Tests zu schreiben für die Library... Wie gesagt, ich komme aus der Software-Entwicklung, und sowas wie Test-Abdeckung ist mir ein heiliger Gral... Aber das Ziel ist ja benannt ;) Also, interessiert das wen außer mich? Bitte mal melden! LG Carsten
:
Verschoben durch User
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.
:
Bearbeitet durch User
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'.
:
Bearbeitet durch User
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.