TL;DR: Müssen die Treiber, die ich verwende offiziell bidirektionales SPI unterstützen, oder kann ich das durch geeignete Verdrahtung auch simulieren? Erstmal: Ist mein erster Beitrag in diesem Forum. Bin mir also nicht sicher, ob es das richtige Format ist. Bitte gerne anmerken, dann verschiebe ich das entsprechend. Ich möchte das Signal meines höhenverstellbaren Schreibtischs (zwischen Bedienpanel und Motor) modifizieren. Ich konnte bereits herausfinden, dass die beiden Komponenten über bidirektionales SPI (andere Namen: 3 Wire SPI / half-duplex SPI) kommunizieren und konnte das Signal decoden. Meine Ergebnisse habe ich hier veröffentlicht: https://github.com/tim-hilt/standing-desk-reverse-engineering Der nächste Schritt wäre für mich das Signal mit einer man in the middle Attacke auf der einen Seite zu lesen, anzupassen und an die andere Komponente weiterzuleiten. Ich möchte das ganze nebenläufig ausführen. Leider scheint bidirektionales SPI aber in den meisten Projekten nicht unterstützt zu sein (TinyGo, MicroPython, Rust Embedded HAL...). In Zephyr gibt es einen SPI Half Duplex Mode (https://docs.zephyrproject.org/latest/hardware/peripherals/spi.html#c.SPI_HALF_DUPLEX), allerdings nicht für den Raspberry Pi Pico, den ich eigentlich dafür einsetzen wollte (https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/spi/spi_rpi_pico_pio.c#L168-L172). Ich habe noch ein bisschen weiter gesucht und diesen Post auf StackOverflow gefunden: https://arduino.stackexchange.com/questions/66076/read-write-with-half-duplex-spi Die Antwort scheint zu bedeuten, dass man gar nicht unbedingt Support für bidirektionales SPI benötigt, sondern MOSI und MISO nur geeignet verbinden muss. Ich würde ungern die Steuerung meines Schreibtischs oder meinen Mikrocontroller zerstören. Bin sehr verwirrt über die verschiedenen Optionen und weiß nicht, wie ich hier weiter vorgehen sollte. Kann mir da jemand weiterhelfen?
Was ist "bidirektionales SPI"? Ich dachte es gibt einen Meister und die ganzen anderen ICs werden von ihm befragt? Hardy
Wenn du eine Antwort deiner Targets benötigst, dann ja - ansonsten nicht. Und was heisst 'offiziell' in diesem Zusammenhang? Da ist nichts genehmigungspflichtig.
Tim H. schrieb: > Müssen die Treiber, die ich verwende offiziell bidirektionales > SPI unterstützen, oder kann ich das durch geeignete Verdrahtung auch > simulieren? Kann man theoretisch durch Hardware "simulieren". Allerdings nicht nur durch Änderung der Verdrahtung, ein paar zusätzliche Bauelemente braucht's schon. Genauer: zwei Dioden und ein Widerstand. Das Ganze nennt sich dann "wired OR". Das braucht man pro Draht der Verbindung, wenn die Sache wirklich vollständig bidirektional ist, ansonsten braucht's das nur für die Datenleitung. Ich würde mal tippen, dass hier das Szenario vorliegt, bei dem nur die Datenleitung angefaßt werden muss. D.h.: Takt und CS kommen immer vom Controller, Daten hingegen können in beide Richtungen fließen. Der Nachteil dieser Lösung ist: Beide "Teilnehmer" empfangen auch das, was sie selber senden. Sie müssen darauf vorbereitet sein, das zu ignorieren. So, wie die Kommunikation hier gestrickt ist, würde ich mal vermuten: kein Problem. Genau dafür dürfte es die Senderkennung im ersten Byte geben. Diese gibt dem Empfänger die Möglichkeit, zu unterscheiden, ob da der Peer gesprochen hat oder er selber. Unbedingt nötig wäre dieses Byte aber nicht, es erlaubt bloß, dass der Teilnehmer sich nicht selber merken muß, dass er das nächste eingehende Telegramm ignorieren muss, weil er es selber gesendet hat. Er sieht das, wenn er ein eingehendes Telegram auswertet. > Die Antwort scheint zu bedeuten, dass man gar nicht unbedingt Support > für bidirektionales SPI benötigt, sondern MOSI und MISO nur geeignet > verbinden muss. So ist das auch. Du musst nur noch herausfinden, welches im konkreten Fall der "dominante Pegel" ist. Davon hängt ab, wie rum die Diode einzubauen ist und ob der Widerstand vom Signal nach GND oder VDD gehört.
Bidirektional heißt in dem Fall, dass MOSI und MISO auf dem gleichen Draht laufen. Die Datenübertragung läuft bei SPI normalerweise im Vollduplexverfahren. Beide Parteien Können gleichzeitig lesen und schreiben. Durch das wegkürzen eines Drahtes kann bei bidirektionalem SPI nur eine Partei zur gleichen Zeit sprechen.
Matthias S. schrieb: > Wenn du eine Antwort deiner Targets benötigst, dann ja - ansonsten > nicht. Und was heisst 'offiziell' in diesem Zusammenhang? Da ist nichts > genehmigungspflichtig. „Offiziell“ heißt in dem Fall, dass die Halduplexfunktion extra implementiert ist. Inoffizielle Unterstützung wäre dann durch extra Hardware und Softwareseitiger Nutzung von Vollduplex SPI. Sorry für die Verwirrung, vielleicht hab ich’s nicht gut genug erklärt.
Ob S. schrieb: > Kann man theoretisch durch Hardware "simulieren". Allerdings nicht nur > durch Änderung der Verdrahtung, ein paar zusätzliche Bauelemente > braucht's schon. Genauer: zwei Dioden und ein Widerstand. Das Ganze > nennt sich dann "wired OR". Alles klar, vielen Dank. Dann such ich mal weiter nach den Stichworten "wired OR" und sehe mal, wohin mich das führt. > Ich würde mal tippen, dass hier > das Szenario vorliegt, bei dem nur die Datenleitung angefaßt werden > muss. D.h.: Takt und CS kommen immer vom Controller, Daten hingegen > können in beide Richtungen fließen. Korrekt. Der Motorcontroller ist dabei der Master und das Bedienpanel der Slave. > Der Nachteil dieser Lösung ist: Beide "Teilnehmer" empfangen auch das, > was sie selber senden. Sie müssen darauf vorbereitet sein, das zu > ignorieren. Super Hinweis! Vielen Dank! > Du musst nur noch herausfinden, welches im konkreten > Fall der "dominante Pegel" ist. Davon hängt ab, wie rum die Diode > einzubauen ist und ob der Widerstand vom Signal nach GND oder VDD > gehört. Kannst du mir hierzu noch mehr sagen? "Dominanter Pegel" sagt mir leider erstmal nichts. Schonmal danke bis hierhin!
Tim H. schrieb: > Kannst du mir hierzu noch mehr sagen? "Dominanter Pegel" sagt mir leider > erstmal nichts. Schonmal danke bis hierhin! Ist einfach. Wenn du schon herausgefunden hast, dass der Motorcontroller der Master ist, brauchst du nur am Bedienteil (bei abgetrenntem Motorcontroller!) den Pegel der Datenleitung messen. Wenn der High ist, ist der dominante Pegel Low und umgekehrt.
Angehängte Dateien:
-
schematic.png
57 KB
Vielen Dank für die Erklärung. Ich hab nachgemessen und am Bedienteil ist das Signal high, wenn es einfach nur mit 5V verbunden ist. Hab mir den Schaltplan mal ein bisschen zusammengeschustert, ist im Anhang. Ist das so korrekt?
Tim H. schrieb: > Vielen Dank für die Erklärung. Ich hab nachgemessen und am Bedienteil > ist das Signal high, wenn es einfach nur mit 5V verbunden ist. Hab mir > den Schaltplan mal ein bisschen zusammengeschustert, ist im Anhang. Ist > das so korrekt? Nein. Die Hälfte der Dioden sind überflüssig. Einfach jeweils MOSI und MISO verbinden. Nur diese Verbundstelle muß dann per Diode zum "Bus" hin entkoppelt werden.
Ob S. schrieb: > Tim H. schrieb: >> Vielen Dank für die Erklärung. Ich hab nachgemessen und am Bedienteil >> ist das Signal high, wenn es einfach nur mit 5V verbunden ist. Hab mir >> den Schaltplan mal ein bisschen zusammengeschustert, ist im Anhang. Ist >> das so korrekt? > > Nein. Die Hälfte der Dioden sind überflüssig. Einfach jeweils MOSI und > MISO verbinden. Nur diese Verbundstelle muß dann per Diode zum "Bus" hin > entkoppelt werden. Das war teilweise Quatsch. Ich bin wohl schon etwas zu angeheitert. Korrekt ist: Eine der Dioden muß jeweils entfallen (durch eine simple Brücke ersetzt werden). Welche, hängt von der Richtung der Verbindung ab. Richtung Motorcontroller ist der der Master, also muß die Diode beim "Zwischencontroller" bei MOSI entfallen, entsprechend Richtung Bedienteil bei MISO.
Angehängte Dateien:
-
schematic.png
56 KB
Ob S. schrieb: > Das war teilweise Quatsch. Ich bin wohl schon etwas zu angeheitert. > Korrekt ist: Eine der Dioden muß jeweils entfallen (durch eine simple > Brücke ersetzt werden). Welche, hängt von der Richtung der Verbindung > ab. Richtung Motorcontroller ist der der Master, also muß die Diode beim > "Zwischencontroller" bei MOSI entfallen, entsprechend Richtung > Bedienteil bei MISO. Ich hab mich schon gewundert :D Bin natürlich auch eher ein Elektronik-Noob. Schau dir gerne meinen angepassten Entwurf nochmal an. Passt's so? Ist die Richtung der Dioden korrekt? Kann mir die Logik leider nicht selber herleiten. Musst auch nicht direkt antworten :D EDIT: Hab nochmal drüber nachgedacht und denke, ich müsste die Dioden nochmal drehen, oder?
:
Bearbeitet durch User
Hast Du Dir mal die Timings angeschaut? Ich frage das weil der SPI Slave im µC üblicherweise sehr lange braucht um die Daten auswerten zu können. Dedizierte Hardware kann oft schon im nächsten Takzyklus die Antwort senden, das ist mit µC ohne signifikante Wartezeiten unmöglich. Damit wäre das dann ein FPGA und kein µC Projekt mehr. Außerdem ist "LSB First" bei SPI eher selten anzutreffen. Werte die Daten mal mit "MSB first" aus - eventuell machen dann die Positionsdaten mehr Sinn.
Danke für deine Antwort! Timings hab ich noch nicht angeschaut. Gut zu wissen, dass Performance da ein Problem sein könnte, werde ich im Hinterkopf behalten. Das decoding hat ja bereits funktioniert. Nur mit LSB first machen die Daten Sinn, deshalb verstehe ich deinen Kommentar leider nicht wirklich!
Jim M. schrieb: > Hast Du Dir mal die Timings angeschaut? > > Ich frage das weil der SPI Slave im µC üblicherweise sehr lange braucht > um die Daten auswerten zu können. > > Dedizierte Hardware kann oft schon im nächsten Takzyklus die Antwort > senden, das ist mit µC ohne signifikante Wartezeiten unmöglich. Damit > wäre das dann ein FPGA und kein µC Projekt mehr. > > Außerdem ist "LSB First" bei SPI eher selten anzutreffen. Werte die > Daten mal mit "MSB first" aus - eventuell machen dann die Positionsdaten > mehr Sinn. Alles, was du sagst, ist irgendwie richtig. Aber trotzdem falsch. Weil nämlich ein Pi Pico verwendet werden soll. Dessen PIOs können solche Probleme wunderbar lösen. Auch das Problem des Halbmultiplex übrigens. Allerdings: man muss die Dinger programmieren. Der TO hört sich nicht so an, als wenn er dazu in der Lage wäre. Übrigens: die dedizierten SPI-Einheiten des Pico sind in ihren Features recht eingeschränkt und obendrein nicht gerade gut dokumentiert. Ob sie möglicherweise trotzdem reichen würden, hängt natürlich auch vom Timing ab. Bevor man daran geht, irgendwas zu bauen und zu programmieren, sollte man auf jeden Fall mal eine Aufzeichnung der Originalkommunikation machen, um zu sehen, was da so abläuft. Dann kann man viel besser abschätzen, ob das mit den Features der SPI-Einheiten möglich ist, oder ob man tatsächlich die PIO bemühen muss. Im Wesentlich hängt es eigentlich nur von der Taktrate ab. Ich kann mir nicht vorstellen, dass in der konkreten Awendung mit hohen Takten gearbeitet wird. Das wird sich wohl eher so im Bereich 10^4Hz abspielen. Und das wäre dann ein Bereich, wo es noch ohne jegliche Hardwareunterstützung abgeht, das könnte man noch rein mit Bitbanging in Software erledigen.
> Allerdings: man muss die Dinger programmieren. Der TO hört sich nicht so an, als
wenn er dazu in der Lage wäre.
Brutally honest :D aber stimmt schon! Das ist mein erstes embedded
Projekt, seid gnädig mit mir!
Für TinyGo gibts schon eine (schlechte) Abstraktion für pio. Die wäre
zwar nutzbar, allerdings kann man in TinyGo keine SPI Slaves
programmieren. Für Zephyr ist gerade schon jemand dran das zu
finalisieren. Mal abwarten!
:
Bearbeitet durch User
Was spricht dagegen die paar Zeilen selbst zu schreiben ? Steht ja im Datenblatt wie das Timing sein muss. Kostet nur eine Viertel Stunde
Ich bin davon ausgegangen, dass ich Nebenläufigkeit brauche um gleichzeitig auf beiden Seiten zu lesen und wenn’s was zu lesen gibt direkt an der anderen Seite rausschreiben. Deshalb hab ich direkt bei Plattformen gesucht, die Nebenläufigkeit mitliefern. Ist das nicht der Fall?
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.