Moin, ich habe ein vorhandenes Autoradio aus meinem Mercedes W201. Diese habe ich gerade instand gesetzt und mir ist etwas interessantes aufgefallen. Der Audioprocessor der verbaut ist(TDA7300), hat 4 Eingänge, es werden aber nur 2 genutzt! Nun habe ich die Idee einen der Eingänge zu verwenden um Bluetooth oder Line In zu realiseren. Zu meinem Verständnisproblem beim Eingangspegel des TDA7300 kommt das Problem der Auswahl des dritten Kanals. Im Anhang eine kleine Beschreibung was ich versuche. Der vorhandene I2C Bus wird vom Mikrocontroller per Software I2C bespielt (der MSM80C154S hat keine HW TWOI). Um nun den Audioprozessor auf den 3ten Kanal umzustellen würde ich einen Controller an den vorhanden I2C Bus anschließen und den Audioprozessor an den neuen Controller anschließen. Hier die erste Frage, ist es möglich 2 I2C Interfaces an einen Mikrocontroller zu realisiren? Hat das jemand schon mal gemacht? Oder sieht da jemand eine andere Lösung? mfg Stephan
Angehängte Dateien:
-
Bild1.png
17 KB
Stephan P. schrieb: > Hier die erste Frage, ist es möglich 2 I2C Interfaces an einen > Mikrocontroller zu realisiren? Guckst du Datenblatt, ob der µC dafür die HW hat. Bit Banging geht natürlich immer.
Ich habe hier kleine NXP ARM M0. Die haben mehrere Hardware I2C Subsysteme, die als Master als auch als Slave betrieben werden können.
Stephan P. schrieb: > Hat das jemand schon mal gemacht? Jein. Gleiche Idee am Sony 3310 (wollte den Aux-Eingang nachrüsten). ATtiny 48, I2C mit Bitbanging (Master und Slave). Das selektive Filtern von I2C-Telegrammen ging ganz gut, weil der Bedienteil-Prozessor Clock-Stretching toleriert. Allerdings habe ich dann mangels Datenblatt des Mulitplexer-ICs von Rohm es nicht hinbekommen, die richtigen Datentelegramme für die Konfiguration des freien Eingangs zu erraten, und damit ist das Projektchen irgendwann mittendrin gestorben.
Schalte deinen Bluetooth Empfänger doch einfach parallel (über einen Mischer aus simplen Widerständen) zu einer anderen analogen Quelle die du stumm schalten kannst. So mache ich das immer bei kompakten Stereoanlagen, wenn mich jemand bittet, einen AUX-Eingang nachzurüsten. Zum Beispiel den CD Player oder den Kassetten Abspieler. Voraussetzung wäre natürlich, das die Endstufe nicht zwangsweise stumm geschaltet wird, wenn die Wiedergabe gerade nicht läuft. Notfalls muss man halt eine leere Dummy Kassette (oder CD) einlegen.
> Oder sieht da jemand eine andere Lösung?
Wenn pfuschen dann richtig. :-)
Haenge dein Oszi auf den Bus und schaue wie oft da Telegramme hin und
her
gehen.
Pruefe ob der Mercedesmaster andauern den eingang einstellt.
Dafuer ist es natuerlich cool wenn man auf bestimmte I2C-kommandos
triggern kann. .-)
Wenn ja dann doof, weil dann muesstest du dich komplett im Bus
dazwischen haengen.
Ich wuerde aber erwarten das er dies nur verstellt wenn du am Radio auch
eine andere Quelle auswaehlt.
Dann schaust du ob es in den Kommandosequenzen oeftest mal eine laengere
Pause nach einem regelmaessigen Kommando gibt. Wenn ja dann haengst du
einfach deinen Controller parallel an den bus, analysierst dieses Paket
in einer State machine und haust danach einfach dein Kommando an den
Slave raus.
olaf
Wolfgang schrieb: > Stephan P. schrieb: >> Hier die erste Frage, ist es möglich 2 I2C Interfaces an einen >> Mikrocontroller zu realisiren? > > Guckst du Datenblatt, ob der µC dafür die HW hat. Bit Banging geht > natürlich immer. Ich habe außer größeren ARM noch keinen µC gefunden der 2 I2C besitzt. Meine Frage ob z.B. ein ATtiny48 wie Walter T. schrieb das hinbekommt. Sprich einmal per HW I2C und einmal per Pin Togglen per SW. Walter T. schrieb: > Stephan P. schrieb: >> Hat das jemand schon mal gemacht? > > Jein. Gleiche Idee am Sony 3310 (wollte den Aux-Eingang nachrüsten). > ATtiny 48, I2C mit Bitbanging (Master und Slave). > > Das selektive Filtern von I2C-Telegrammen ging ganz gut, weil der > Bedienteil-Prozessor Clock-Stretching toleriert. Allerdings habe ich > dann mangels Datenblatt des Mulitplexer-ICs von Rohm es nicht > hinbekommen, die richtigen Datentelegramme für die Konfiguration des > freien Eingangs zu erraten, und damit ist das Projektchen irgendwann > mittendrin gestorben. ATtiny48 war auch meine Wahl. Hast du das schon implementiert (2 I2C Busse)? Stefan ⛄ F. schrieb: > Schalte deinen Bluetooth Empfänger doch einfach parallel (über > einen > Mischer aus simplen Widerständen) zu einer anderen analogen Quelle die > du stumm schalten kannst. So mache ich das immer bei kompakten > Stereoanlagen, wenn mich jemand bittet, einen AUX-Eingang nachzurüsten. > > Zum Beispiel den CD Player oder den Kassetten Abspieler. Voraussetzung > wäre natürlich, das die Endstufe nicht zwangsweise stumm geschaltet > wird, wenn die Wiedergabe gerade nicht läuft. Notfalls muss man halt > eine leere Dummy Kassette (oder CD) einlegen. Andere disablen immer die Kassette. Das will ich aber gerade nicht. Wenn der Audioprozessor schon 4 Eingänge hat, dann kann man die doch nutzen :) Olaf schrieb: >> Oder sieht da jemand eine andere Lösung? > > Wenn pfuschen dann richtig. :-) > > Haenge dein Oszi auf den Bus und schaue wie oft da Telegramme hin und > her > gehen. > > Pruefe ob der Mercedesmaster andauern den eingang einstellt. > Dafuer ist es natuerlich cool wenn man auf bestimmte I2C-kommandos > triggern kann. .-) > > Wenn ja dann doof, weil dann muesstest du dich komplett im Bus > dazwischen haengen. > > Ich wuerde aber erwarten das er dies nur verstellt wenn du am Radio auch > eine andere Quelle auswaehlt. > > Dann schaust du ob es in den Kommandosequenzen oeftest mal eine laengere > Pause nach einem regelmaessigen Kommando gibt. Wenn ja dann haengst du > einfach deinen Controller parallel an den bus, analysierst dieses Paket > in einer State machine und haust danach einfach dein Kommando an den > Slave raus. > > olaf Ich habde da auch schon nachgeschaut. Logicanalyzer angeschlossen und geschaut. Solange man nichts umschaltet ist der Bus ziemlich tot. Bei Kassetten Wiedergabe ist dann viel los auf dem Bus. Ich mag die Lösung aber wenn ich ehrlich bin nicht so.
Stephan P. schrieb: > ATtiny48 war auch meine Wahl. Hast du das schon implementiert (2 I2C > Busse)? Nein, nicht über Hardware. Nur über Bitbanging. Und zwar sehr, sehr dreckig. Der ATtiny muss ja schon, bevor das nächste Byte anfängt, entscheiden, was er mit dem Telegramm macht. Und wenn es eines der Telegramme ist, die er einfach durchlässt, muss das Byte (und das erste Bit der Antwort) ja schon mit dem Slave ausgetauscht sein, bevor er das ACK sendet. Ich habe dazu die Lücke beim Clock Stretching genutzt. Ich glaube nicht, dass das mit dem Hardware-TWI geht.
:
Bearbeitet durch User
> Ich habe außer größeren ARM noch keinen µC gefunden der 2 I2C besitzt. Weil die Leute hier alle nie ueber ihren engen ARM/AVR Horizon hinausschauen. Bei Renesas hab ich vor >15Jahren im R32 schon 9 multiserielle Einheiten gehabt. Die konnten UART, SPI, SSI oder I2C. Olaf
Walter T. schrieb: > Der ATtiny muss ja schon, bevor das nächste Byte anfängt, > entscheiden, was er mit dem Telegramm macht. Das war jetzt etwas unsauber formuliert. Er muss zwischen dem zweitem und dritten Byte, dass er empfängt, entscheiden, was er macht. Das erste Byte (die Adresse) darf er noch zeitgleich übertragen, aber beim zweiten Byte muss er filtern. Ist es ein Befehl, der weggefiltert werden muss, schickt er einfach einen STOP an den Slave. Ist es ein Auslese-Befehl, muss er evtl. die Antwort bitweise modifizieren. Es ist keine Zeit da, komplette Bytes mit Ack/Nack abzuwarten.
> Ist es ein Befehl, der weggefiltert werden muss, > schickt er einfach einen STOP an den Slave. Er koennte auch einfach das eine Bit im Befehl runterziehen und so einen anderen Eingang auswaehlen wenn dafuer Lowpegel zielfuehrend ist. So hab ich mal vor vielen Jahren einen DAT von Sony die Kenntnisnahme von SCMS abgewoehnt. .-) Olaf
Angehängte Dateien:
-
frame1.png
15 KB -
frame2.png
15 KB
Vielen Dank nochmal für weitere Kommentare und die Hilfe. Ich habe es jetzt quick and dirty umgesetzt. Arduino Uno mit HW Schnittstelle als Slave und Bit Banging als Master für den Audio Prozessor. Grundlegend läuft es auch. In SW habe ich einen FIFO implementiert, um keine Daten zu verlieren da ich immer 7 Byte vom µC des Radios bekomme. Senden und empfangen mache ich mit den Arduino Libraries Wire.h (Master, receive per Interrupt) und SoftwareWire.h (Slave, senden in der Main Loop). Soweit so gut. Mein Problem nun das ich im ersten Frame nach reset/start immer nur 6 Byte sende (siehe Bild frame1.png). Im zweiten und allen folgenden Frames werden 7 Byte gesendet (siehe Bild frame2.png). Daten gehen dabei nicht verloren. Das erste Byte ist hier immer das letzte Byte des vorigen Frames. Im Anhang mein Main file und die Implementierung des FIFO. Ich stehe echt auf dem Schlauch wo ich einen Fehler mache. Als Init gebe ich dem Read Index -1 um ein Lesen vor dem ersten Schreiben zu unterbinden. MAX_BUFFER habe ich auf 10. Vielleicht hat hier ja jemand eine Idee. mfg
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.