Hilfe bei Signalbestimmung bzw Auswertung mittels Arduino

[Dennis M. (rivadynamite)]

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!

[Sebastian R. (sebastian_r569)]

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.

[Theor (Gast)]

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

[Theor (Gast)]

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.

[Dennis M. (rivadynamite)]

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?

[Sebastian R. (sebastian_r569)]

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.

[Dennis M. (rivadynamite)]

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...

[Theor (Gast)]

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.

  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.

[Theor (Gast)]

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.

[Dennis M. (rivadynamite)]

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?

[Theor (Gast)]

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.

[Dennis M. (rivadynamite)]

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.

[Dennis M. (rivadynamite)]

...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...

[Theor (Gast)]

@ 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.

[Dennis M. (rivadynamite)]

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...

[Theor (Gast)]

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?

[Theor (Gast)]

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.