Moin, ich benötige mal ein wenig Unterstützung bei einem Elektronikprojekt, da ich mittlerweile seit mehreren Wochen daran sitze, und ich von der Fülle der ganzen Informationen völlig erschlagen bin... Es geht um eine SPI-Schnittstelle, auf dieser wird von einem Gerät kontinuierlich wiederholend alle ca. 50ms ein Datensatz, welcher aus 8 bytes (jeweils wieder mit 2ms abstand) besteht, gesendet. Im Anhang mal 3 Oszi-aufnahmen mit unterschiedlichen Time bases, auf denen sich das Muster ganz gut erkennen lässt. Ich habe nun vor, mit einem Arduino/Atmega328 aus diesem Datenstrom Daten auszulesen - konkret brauche ich aber nur den Inhalt des zweiten und dritten Bytes, der Rest ist irrelevant. Ich habe keinerlei Erfahrung mit Librarys wie SoftwareSerial, könnte die mir in diesem Fall helfen? Oder wie würdet ihr an die Sache herangehen? Vielen Dank schonmal!
Man kann den Arduino mit seiner SPI-Schnittstelle als SPI-Slave betreiben, dann kann er auf der Leitung mithören. Google findet zu "Arduino SPI Slave" ein paar Code-Beispiele. Am Ende hast du natürlich alle Bytes eingefangen, die Auswertung, welche du brauchst und wann die kommen, musst du dann danach noch selber einbauen.
Wenn SPI dann SPI (und nicht Serial). :-) Suche "Arduino SPI". Ein Treffer: https://riptutorial.com/de/arduino/example/17374/grundlagen--initialisieren-sie-den-spi-und-einen-chip-select-pin-und-fuhren-sie-eine-1-byte-ubertragung-durch
Eine Bemerkung noch dazu: > Ich habe nun vor, mit einem Arduino/Atmega328 aus diesem > Datenstrom Daten auszulesen - konkret brauche ich aber > nur den Inhalt des zweiten und dritten Bytes, der Rest > ist irrelevant. Wenn das Peripheriegerät bzw. IC Datenblöcke aus mehreren Bytes sendet, dann musst Du alle diese Daten auch empfangen; man könnte sagen, Du musst auch alle Daten "annehmen". (Ist wie mit der Werbung im Briefkasten). ;-) Die Daten, die Du nicht brauchst, ignorierst Du einfach, nachdem Du sie empfangen hast. "Ignorieren" heisst hier, Du wertest sie einfach nicht aus. Unter Umständen lassen sich die für Dich interessanten Daten auch einzeln abfragen, aber das müsstest Du im Datenblatt des fraglichen ICs nachlesen.
Danke schonmal, ihr habt mir einige entscheidene Impulse geliefert (z.b. SPI /= Seriell) ;-) Mein Master hat allerdings keinen Slave Select-Ausgang, muss ich das "emulieren" oder kann ich den softwaremäßig deaktivieren?
Dennis M. schrieb: > Mein Master hat allerdings keinen Slave Select-Ausgang, muss ich das > "emulieren" oder kann ich den softwaremäßig deaktivieren? Du willst ja nur zuhören und nicht senden. Entsprechend kannst du das dauerhaft tun und musst nicht warten, bis dein Slave über CS angesprochen wird.
Ok, ich muss nochmal nachhaken. Die meisten Beispiele, die ich finde, beschäftigen sich mit dem SENDEN von Daten, nicht aber mit dem Empfangen und auswerten als Slave - dies scheint mit der spi.h gar nicht möglich zu sein..? Einen SPI Sniffer habe ich gefunden, der nutzt allerdings die SS-Leitung zur Erkennung des Transferbeginns und damit zur Syncronisation - diese Leitung habe ich nicht, die Sync müsste einfach über die Erkennung der Pausen erfolgen, da es sonst keine Merkmale gibt...
Dennis M. schrieb: > Ok, ich muss nochmal nachhaken. Die meisten Beispiele, die ich finde, > beschäftigen sich mit dem SENDEN von Daten, nicht aber mit dem Empfangen > und auswerten als Slave - dies scheint mit der spi.h gar nicht möglich > zu sein..? Das Beispiel, dass ich Dir verlinkt habe, zeigt sowohl das senden, als auch das Empfangen.
1 | unsigned char received = SPI.transfer(sent); |
Man muss wissen, dass beim SPI-Bus per Definition ein Senden auch immer ein Empfangen beinhaltet und umgekehrt. Senden ohne Empfangen bzw. das Umgekehrte geht garnicht beim SPI-Bus. Ein "Transfer" bedeutet beides gleichzeitig. Siehe: https://de.wikipedia.org/wiki/Serial_Peripheral_Interface#Protokollablauf_und_Einstellm%C3%B6glichkeiten Wahrscheinlich gibt es mehr spi.h-Dateien als ich Zehen am linken Fuß habe. Welche meinst Du denn? > Einen SPI Sniffer habe ich gefunden, der nutzt allerdings die SS-Leitung > zur Erkennung des Transferbeginns und damit zur Syncronisation - diese > Leitung habe ich nicht, die Sync müsste einfach über die Erkennung der > Pausen erfolgen, da es sonst keine Merkmale gibt... Dein Slave wird gar nicht senden, und auch nicht empfangen, wenn er kein Slave-Select-Signal bekommt. Details siehe den Wikipedia-Artikel und dazu das Datenblatt Deines (noch) unbekannten SPI-ICs.
Dennis M. schrieb: > Danke schonmal, ihr habt mir einige entscheidene Impulse geliefert (z.b. > SPI /= Seriell) ;-) > > Mein Master hat allerdings keinen Slave Select-Ausgang, muss ich das > "emulieren" oder kann ich den softwaremäßig deaktivieren? Mikrocontroller haben in der Regel keine "dedizierten" Slave-Select-Ausgänge für den SPI-Bus. Das Protokoll geht nicht so weit "hoch", dass verschiedene Slaves darin berücksichtigt sind (anders als bei I2C). Daher enthalten die entsprechenden Peripherie-Einheiten von uCs auch weder Pins noch interne Adressregister. Das kann man als Vorteil betrachten, weil so beliebig viele Slaves auf beliebige Weise addressiert werden können, oder als Nachteil, weil einem die Verwaltung nicht abgenommen wird. Kann man sehen wie ein Dachdecker. Ist aber einfach so. Das verlinkte Codebeispiel zeigt übrigens auch, das einfach irgendeine IO-Leitung dafür verwendet wird.
Theor schrieb: > Dein Slave wird gar nicht senden, und auch nicht empfangen, wenn er kein > Slave-Select-Signal bekommt. Details siehe den Wikipedia-Artikel und > dazu das Datenblatt Deines (noch) unbekannten SPI-ICs. Es geht hier um die Verbindung eines Bluetooth-Interfaces mit dem CD-Wechslereingang eines Autoradios. Es gibt eine Clock- , eine DATA Out- und eine DATA-In-Leitung am Autoradio. Die DATA-Out-Leitung arbeitet aber unabhängig der CLK-Leitung - das Signal davon habe ich bereits entschlüsselt. Das IC kann ich leider nicht bestimmen, da die Typenbezeichnung vom Hersteller des Interfaces freundlicherweise abgeschliffen wurde. Das heißt dann im Umkehrschluss vermutlich, dass es sich gar nicht um klassisches SPI handelt... Habt vielleicht jemand eine Idee, wie ich die entsprechenden Daten dennoch entschlüsseln kann?
Dennis M. schrieb: > Theor schrieb: > >> Dein Slave wird gar nicht senden, und auch nicht empfangen, wenn er kein >> Slave-Select-Signal bekommt. Details siehe den Wikipedia-Artikel und >> dazu das Datenblatt Deines (noch) unbekannten SPI-ICs. > > Es geht hier um die Verbindung eines Bluetooth-Interfaces mit dem > CD-Wechslereingang eines Autoradios. Es gibt eine Clock- , eine DATA > Out- und eine DATA-In-Leitung am Autoradio. Die DATA-Out-Leitung > arbeitet aber unabhängig der CLK-Leitung - das Signal davon habe ich > bereits entschlüsselt. > > Das IC kann ich leider nicht bestimmen, da die Typenbezeichnung vom > Hersteller des Interfaces freundlicherweise abgeschliffen wurde. > > Das heißt dann im Umkehrschluss vermutlich, dass es sich gar nicht um > klassisches SPI handelt... Au Mann. Du bist aber auch ein bisschen anstrengend, oder? > Habt vielleicht jemand eine Idee, wie ich die entsprechenden Daten > dennoch entschlüsseln kann? Schon. Ich werfe mal ein paar I-Ging-Stäbchen und frage das "Grosse Ganze" nach dem Typ des Autoradios. :-) Viel Erfolg.
Theor schrieb: > Au Mann. Du bist aber auch ein bisschen anstrengend, oder? > >> Habt vielleicht jemand eine Idee, wie ich die entsprechenden Daten >> dennoch entschlüsseln kann? > > Schon. Ich werfe mal ein paar I-Ging-Stäbchen und frage das "Grosse > Ganze" nach dem Typ des Autoradios. :-) > > Viel Erfolg. Sorry, ich beschäftige mich seit Wochen fast jeden Tag mit dem Thema und habe mein Projekt auch schon zu 90% fertig stellen können, aber mir dröhnt echt langsam der Kopf und ich bin überfordert da ich noch nie so viel mit Microcontrollern und deren Schnittstellen gemacht habe, daher habe ich mich erdreistet, hier nachzufragen... ...Konkret geht es um VW/Audi Werks-Autoradios. Es gab schon unter dem Namen "VWCDPIC" ein Projekt welches die Daten generiert und sendet, die ich lesen und auswerten möchte, leider sind die entsprechenden Seiten mit der Beschreibung des Protokolls nicht mehr online.
...nach einer weiteren Google-Schlacht noch einmal konkret zusammengefasst: -es gibt sehr wenige Beispiele online, in denen der µC verwendet wird, um Daten über SPI zu empfangen - die meisten Codes versenden lediglich Daten. -Die Beispiele, wo Daten empfangen werden, nutzen eine CS-Leitung (die es in meinem Fall nicht gibt), um den Übertragungsbeginn zu erkennen. -In meinem Fall müsste aber der Übertragungsbeginn bzw die einzelnen Bytes durch die Pausen bzw das Timing selbstständig erkannt werden. Daher hat mir alles, was ich bisher fand, nicht wirklich weitergeholfen und ich muss irgendeinen anderen Weg gehen, stehe aber auf dem Schlauch...
:
Bearbeitet durch User
@ Dennis Ich versuche es mal anders: Die drei Oszillogramme aus Deinem ersten Post lassen folgende Vermutungen zu: 1. Die gelbe Linie ist ein Taktsignal. 2. Die blaue Linie stellt das Datensignal da. 3. Die zeitliche Beziehung zwischen Takt- und Datensignal scheint zu sein, dass bei der fallenden Flanke des Taktsignals, das Datensignal gültig ist. Der Ablauf stimmt in mancher Hinsicht mit dem von SPI (bei bestimmten Parametern: CPOL=0, CPHA=1) überein. Die gedankliche Verbindung ist also durchaus plausibel. Wie Du richtig sagst, hat Dein Radio kein SS-Signal. Insofern handelt es sich nicht um eine SPI-Schnittstelle eines Slaves. Der Ansatz, dennoch eine SPI-Schnittstellen-Einheit (wie sie in manchen uCs verbaut ist) zu benutzen, scheint mir nicht unplausibel. K.A. wie weit das führt, aber er scheint mir wert, darüber nachzudenken. Vielleicht kann man das Radio als Master ansehen. In jedem Fall solte man aber ergänzend zusätzliche Informationen zu finden versuchen. Ich verstehe aber nicht, dass Du zu "VWCDPIC" keine Informationen findest. Wie im Anhang zu sehen, gibt es einen Haufen Treffer. Die solltest Du Dir einmal ansehen, denke ich. OK. Soweit so gut. Nun hast Du aber Einwände, bzgl. der Verwendung der SPI-Libraries. Insbesondere: > Die Beispiele, wo Daten empfangen werden, nutzen eine CS-Leitung > (die es in meinem Fall nicht gibt), um den Übertragungsbeginn > zu erkennen. Ein Slave-Select-Signal (nicht Chip-Select) wird nur beim Ansprechen von Slaves als Ausgangssignal verwendet. Code, der dieses Signal setzt, läuft logischerweise in einem Master ab. D.h. falls Du einen Slave betreibst, brauchst Du dieses Signal nicht ausgeben. Dann will ich, wegen der Frage nach Senden und Empfangen nochmal einen meiner obigen Beiträge zitieren: "Man muss wissen, dass beim SPI-Bus per Definition ein Senden auch immer ein Empfangen beinhaltet und umgekehrt. Senden ohne Empfangen bzw. das Umgekehrte geht garnicht beim SPI-Bus. Ein "Transfer" bedeutet beides gleichzeitig." Ich empfehle Dir, Dich nochmal ausführlich mit dem SPI-Protokoll zu beschäftigen.
Theor schrieb: > Vielleicht kann man das Radio als Master ansehen. So wie ich die Definition von SPI verstanden habe, erzeugt der Master zwingend das Taktsignal - und das kommt ja in meinem Fall auch vom Wechsler bzw Wechslerinterface, daher muss ich zwingend einen Slave nachbilden um die Daten vom Wechsler auszuwerten... Oder liege ich da falsch? > Ein Slave-Select-Signal (nicht Chip-Select) wird nur beim Ansprechen von > Slaves als Ausgangssignal verwendet. Code, der dieses Signal setzt, > läuft logischerweise in einem Master ab. D.h. falls Du einen Slave > betreibst, brauchst Du dieses Signal nicht ausgeben. Ich will es ja auch nicht ausgeben, sondern wollte nur anmerken, dass es beim SPI-Standard zur Signalisierung von Übertragungsbeginn und -ende genutzt wird, und ich das in meinem Fall durch das fehlende Signal ja anders lösen müsste, aber habe mich halt gefragt WIE. Aber man könnte ja einfach einen Timer laufen lassen, der bei ca 30ms "Ruhe" auf der Taktleitung auslöst und SS "intern" aktiviert für ca 22ms...
:
Bearbeitet durch User
Dennis M. schrieb: > Theor schrieb: > >> Vielleicht kann man das Radio als Master ansehen. > [...] > Ich will es ja auch nicht ausgeben, sondern wollte nur anmerken, dass es > beim SPI-Standard zur Signalisierung von Übertragungsbeginn und -ende > genutzt wird, und ich das in meinem Fall durch das fehlende Signal ja > anders lösen müsste, aber habe mich halt gefragt WIE. > Aber man könnte ja einfach einen Timer laufen lassen, der bei ca 30ms > "Ruhe" auf der Taktleitung auslöst und SS "intern" aktiviert für ca > 22ms... Meine Güte. Sorry, aber Du kommst mir vor, wie jemand der auf einem Bein vor mir steht, und fragt, wie er das in die Luft erhobene andere Bein wieder auf die Erde bekommt. Nimm mal an, ein SPI-Slave würde ständig ein gültiges Slave-Select Signal bekommen. Wie würde er reagieren, falls er ein Taktsignal sieht?
Beitrag #6123034 wurde vom Autor gelöscht.
Noch ein Hinweis: > Ich will es ja auch nicht ausgeben, sondern wollte nur anmerken, dass es > beim SPI-Standard zur Signalisierung von Übertragungsbeginn und -ende > genutzt wird, Das ist falsch. "Slave-Select" hat die Funktion, die sein Name bedeutet. (https://dict.leo.org/englisch-deutsch/select). Es waehlt den Slave aus , sagt ihm, dass "er jetzt gemeint ist" mit jeglicher Datenübertragung. Es signalisiert nicht den Beginn der Übertragung. Dass da eine Korrelation existiert ist zwar kein reiner Zufall, aber logisch betrachtet, so geht es aus der Protokollbeschreibung, gibt es keinen Zusammenhang, als den dass erst der Empfänger ausgewählt werden muss bevor man anfängt etwas zu senden. Das wäre andernfalls so, als würde man behaupten, das wählen einer Telefonummer signalisiert den Beginn eines Gesprächs. Wenn man mal genauer darüber nachdenkt, ist das nicht so, obwohl das Wählen eine Vorbedingung ist.
Bitte 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.