Hallo Leute, ich möchte gerne aus einem AV-Receiver den BUS anzapfen und auslesen. Leider bin ich mir nicht sicher um welche Art bus-typ es sich hier handelt. Im Anhang die entsprechenden Seiten aus dem Datenblatt. Ist es ein SPI Bus? vielen Dank Andre
Im Prinzip SPI, aber offenbar nur eine Richtung (Master->Slave) und kein Select-Signal. Also ein bisschen so, wie wenn du einen 74LS595 an einen SPI-Master hängst.
Danke schon mal! SS gibt es auf Pin 80, wird hardware seitig fest verdrahtet, was mich wundert. Dann werde ich mal in Richtung SPI weiter forschen. Ich kann also ein SPI slave an den BUS hängen und mit lauschen?
André M. schrieb: > Ich kann also ein SPI slave an den BUS hängen und mit lauschen? Besser wäre ein Logic Analyzer oder Digital-Oszilloskop mit ausreichend Speicher. Die Frage ist ja, wie ohne Chip Select die Bitsynchronisation erfolgt.
Jörg W. schrieb: > André M. schrieb: >> Ich kann also ein SPI slave an den BUS hängen und mit lauschen? > > Besser wäre ein Logic Analyzer oder Digital-Oszilloskop mit ausreichend > Speicher. Beides vorhanden, doch noch habe ich das Gerät nicht. Ich möchte die Möglichkeit vorher abklären. > > Die Frage ist ja, wie ohne Chip Select die Bitsynchronisation erfolgt. Im Datasheet wird von einem Latch gesprochen welches wohl ein 16bit Byte abschließt. Verstanden habe ich das jedoch nicht.
André M. schrieb: > Im Datasheet wird von einem Latch gesprochen welches wohl ein 16bit Byte > abschließt. Naja, ein einzelner Störimpuls auf der Taktleitung bringt dann die komplette Mimik durcheinander. Der Sinn des Chip Select bei SPI ist ja nicht nur, dass man auf diese Weise mehr als ein Gerät am Bus haben kann, sondern auch, dass man mit der Aktivierung des CS die interne SPI-Logik freigibt, d.h. danach wird dann das erste Bit erwartet. Sowie CS inaktiv wird, kann alles zurückgesetzt werden, und wenn man bis dahin ein Bit „verzählt“ hat, sind spätestens an diesem Punkt Master und Slave wieder synchron. Bei einem einfachen 74HC595-System hat man sowas zwar auch nicht, aber dort generiert man üblicherweise nach dem Durchschieben aller Bits einen Übernahmeimpuls, der die Daten aus den seriellen Schieberegistern in die parallelen Latches übernimmt. Auch damit hat man einen eindeutigen Synchronpunkt.
André M. schrieb: >> Die Frage ist ja, wie ohne Chip Select die Bitsynchronisation erfolgt. > Im Datasheet wird von einem Latch gesprochen welches wohl ein 16bit Byte > abschließt. Verstanden habe ich das jedoch nicht. Gelatched werden die vorigen 16 Bits, die mit den vorigen 16 steigenden Flanken des CL eingelesen wurden, wenn bei einer fallenden Flanke des CL ein High erkannt wird. Datenbits werden also mit der steigenden Flanke vom CL eingelesen, der Sync mit der fallenden. Nettes Protokoll... ?
Lothar M. schrieb: > André M. schrieb: >>> Die Frage ist ja, wie ohne Chip Select die Bitsynchronisation erfolgt. >> Im Datasheet wird von einem Latch gesprochen welches wohl ein 16bit Byte >> abschließt. Verstanden habe ich das jedoch nicht. > Gelatched werden die vorigen 16 Bits, die mit den vorigen 16 steigenden > Flanken des CL eingelesen wurden, wenn bei einer fallenden Flanke des CL > ein High erkannt wird. > Datenbits werden also mit der steigenden Flanke vom CL eingelesen, der > Sync mit der fallenden. > > Nettes Protokoll... ? Danke, nun habe auch ich verstanden:-). Ist das noch mit SPI vereinbar, oder anders gefragt gibt es eine Arduino lib mit der ich dieses Protokoll auswerten kann?
Hm, auf den ersten Blick eine nette Idee die CS Leitung einzusparen. Allerdings frage ich mich, ob das in der Praxis dann wirklich so dolle ist. Mir fällt spontan nicht ein, wie man einen SIO eines handelsüblichen uC so konfigurieren kann die nötigen "Extra-Nullbits" für die fallenden Flanken zu erzeugen. Wenn man dann per Bit-Banging mit einem Display kommunizieren muss und die Übertragung von Daten-Worten nicht mehr komplett der Hardware überlassen kann, finde ich es nicht mehr so prickelnd. Und extra eine Glue-Logic hinzubasteln, um aus SPI dieses Spezial-Protokoll zu machen, kann es ja auch nicht sein... Update: stelle gerade fest, dass es sich nicht um ein Display handelt... Prinzipiell kann man soetwas natürlich in Software auswerten, die Frage ist allerdings, ob dein uC schnell genug ist. Lt. Spec kann die CLK bis zu 500 KHz schnell sein, das wird dann schon recht anspruchsvoll. Ich würde als erstes mal messen mit welcher CLK Frequenz dieser Bus in deinem Fall betrieben wird.
:
Bearbeitet durch User
Lothar M. schrieb: > Gelatched werden die vorigen 16 Bits, die mit den vorigen 16 steigenden > Flanken des CL eingelesen wurden, wenn bei einer fallenden Flanke des CL > ein High erkannt wird. OK, das Detail war mir dann doch entgangen.
Hat jemand eine Idee wie man diesen Datenstom mit einem Atmel/Arduino einlesen kann?
Wie schnell ist der obige Bus in der "abzuhörenden" Realität getaktet?
:
Bearbeitet durch Moderator
> Ich kann also ein SPI slave an den BUS hängen und mit lauschen?
Es wird dir im weiteren Leben ernorm weiterhelfen wenn du dir klar
machst das SPI kein BUS ist wie z.B I2C oder USB. Es gibt keine
irgendwie ueblichen oder genormten Einstellungen.
SPI ist einfach eine syncrone serielle Datenuebertragung. Und weil das
so ist kann man bei den beteiligten ICs auch immer sehr viel einstellen.
Und deshalb gibt es Einstellungen die gut funktionieren, andere die gar
nicht funktionieren und sogar welche die oft aber nicht immer
funktionieren.
Olaf
Lothar M. schrieb: > Wie schnell ist der obige Bus in der "abzuhörenden" Realität > getaktet? Aktuell habe ich das Gerät noch nicht, doch laut Datenblatt dürfen es nicht mehr als 500 KHz sein.
Olaf schrieb: >> Ich kann also ein SPI slave an den BUS hängen und mit lauschen? > > Es wird dir im weiteren Leben ernorm weiterhelfen wenn du dir klar > machst das SPI kein BUS ist wie z.B I2C oder USB. Es gibt keine > irgendwie ueblichen oder genormten Einstellungen. > Olaf Danke werde ich mir zu Herzen nehmen. Im Datenblatt des betreffenden Bauteils steht jedoch unter Features: " 2-wire serial bus control, corresponding to 3.3/5V "
Jörg W. schrieb: > Die Frage ist ja, wie ohne Chip Select die Bitsynchronisation erfolgt. durch Timing? wo ist denn das CS signal beim WS2801? Da wird ja auch ohne CS nach Pause übernommen egal welcher Schrott übertragen wurde, auch wenn nicht die gewünschten LED leuchten!
:
Bearbeitet durch User
André M. schrieb: > Aktuell habe ich das Gerät noch nicht, doch laut Datenblatt dürfen es > nicht mehr als 500 KHz sein. Auf die Taktfrequenz kommt es aber an. Man könnte das Signal über eine Pin-Change Interrupt einlesen, der würde dann bei 500 Khz mit 1 Mhz ausgelöst werden. Bei einem 16 Mhz uC hätte die Interrupt-Routine also gerade mal 16 Clock-Cycles zur Verfügung... Bei 50 Khz sieht das dann schon realistischer aus... Wenn die Clock wirklich am Maximum liegt, könnte man den uC extern mit 2 Schieberegistern und einem Inverter + Flipflop entlasten.
:
Bearbeitet durch User
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.