Hallo, ich habe ein Kenwood- Autoradio welches ein externes Display ansteuern kann. Das Protokoll beruht auf den I2C- Standard jedoch leider mit exakt einer Ausnahme welches mir jetzt das Genick bricht :-( Slave: Controller / Master: Autoradio I2C- START (von Radio nach Spezifikation) SLAVE- Adresse bit1-7 + PARITÄTS-BIT bit8 (odd) + ACK bit9 1001101 1 A Leider wird das R/W Bit als Paritätsbit mißbraucht und mein Käfer denkt nun der Master möchte lesen. DATEN (13 Byte) (von Radio ) Bit1-7 ASCII Daten bis 7Fh, Bit 8 dient wieder als Parität Bit 9 ist ACK I2C- STOP (von Radio nach Spezifikation) Gibts es eine Möglichkeit, dass ich die Hardware TWI dennoch verwenden kann (Bitmanipulation !?) Laut Datenblatt sollte es möglich sein, dass ich als SLAVE (SR-Mode) einfach FFh sende. Damit lasse ich den Bus "unberührt". Nach dem shiften der Bits sollte im Daten Register (TWDR) der letzte Stand vom Bus vorhanden sein. Hier das orginal. While data is shifted out, data on the bus is simultaneously shifted in. TWDR always contains the last byte present on the bus. (ATMega 8535, Datenblatt S.180) Leider gibt es dann Probleme mit dem Acknowledge. Kann jemand helfen? Ich hoffe ich konnte das Problem exakt schildern. Am liebesten würde ich den Controller, nachdem er seine Adresse empfangen hat, "manuell" in den SW- Modus setzen. Martin
Hallo Martin,
ein sehr interessantes Projekt!
>Leider gibt es dann Probleme mit dem Acknowledge
Mit dem Hardware-TWI-Master habe ich auch schon viele schlaflose Nächte
verbracht. Er führt manchmal ein nicht nachvollziehbares Eigenleben .
Ich würde, in Deinem konkreten Fall, eine Software-TWI-MASTER-Routine
schreiben. So komliziert ist sie ncht.
Dann weißt Du genau, wan was wo und wie passiert. Und kannst alles nach
Deinen Bedürfnissen anpassen.
Bernhard
Hallo Bernhard, da habe ich genau den richtigen erwischt :-) Anhand Deiner ASM- Files habe ich die ersten Gehversuche im Bereich I2C unternommen. Der Atmel dient in meinem Fall als SLAVE und soll Daten empfangen. Das ärgerliche ist, dass genau 1 Bit alles "kaputt" macht. 1001101 "1" ACK. Ansonsten würde ich das TWI verwenden und sobald mein Controller die richtige Adresse empfangen hat über Software die Flanken auswerten. Somit könnte ich zumindest noch die "Asdress Match Unit" und den Interrupt vom TWI benutzen. Wenn ich es richtig verstehe habe ich nicht die Möglichkeit das "read" vom Master zu bestätigen (ACK) und danach dennoch Daten zu empfangen "write". Denen gehören die Löffel lang gezogen, immer eine extra Wurst. PS: hatte auch ein Blaupunkt Radio an meinem Oszi, die Entwickler halten sich an die Spezifikationen.
>da habe ich genau den richtigen erwischt :-) >Anhand Deiner ASM- Files habe ich die ersten Gehversuche im Bereich >I2C unternommen. Für Risiken und Nebenwirkungen übernehme ich aber keine Haftung ;) Wenn ich es jetzt richtig verstanden habe: 1. Schritt I2C- START (von Radio nach Spezifikation) 2. Schritt SLAVE- Adresse (Bit1-7) + PARITÄTS-BIT (bit8) ( R /W) + ACK (bit9) 3. Schritt DATEN (13 Byte) (von Radio ) ASCII Daten (Bit1-7)+ Parität (Bit 8) + ACK (Bit 9) 4. Schritt I2C- STOP (von Radio nach Spezifikation) >Wenn ich es richtig verstehe habe ich nicht die Möglichkeit das >"read" vom Master zu bestätigen (ACK) und danach dennoch Daten zu >empfangen "write". Nach meiner Meinung kannst Du den 2. Schritt problemlos durch ein ACK Deines µC bestätigen. Oder habe ich was übersehen? Wird im 2. Schrit ein Interrupt ausgelöst ? Bernhard
So wäre der Plan: 1.Schritt I2C START (von Radio) 2. Schritt SLAVE-Adresse (wird von µC mit ACK bestätigt) 3. Schritt Da ich jetzt in den "SLAVE- Transmitter Mode" komme (0xA8 | Own SLA+R has been received;ACK has been returned) deaktiviere ich die TWI und springe in meine eigene Routine. --> Interrupt kann bei richtiger SLAVE- Adresse ausgelöst werden (TWIE) somit muss ich nicht in einer Schleife dauernd das Register abfragen! --> wie gesagt wäre mir es mir lieber ich könnte den µC im 3.Schritt, wenns sein muss mit Gewalt, in den "SALVE- Receiver Mode" bringen. Der Mensch ist von Natur aus faul. Martin
>--> wie gesagt wäre mir es mir lieber ich könnte den µC im 3.Schritt, >wenns sein muss mit Gewalt, in den "SALVE- Receiver Mode" >bringen. Das lässt leider HW-TWI nicht zu, der SLAVE folgt ohne Rücksicht auf Verluste den Befehlen des Masters und der schickte ihn in den "Slave Transmitter Modus". Fällt mir gerade ein, wenn man das R/W-Bit durch eine externe Hardware beeinflusst? Ansonsten kommst Du wohl nicht drumherum, Dir einen Software-Slave zu schreiben ;) Bernhard
Zusätzliche Hardware möchte ich nicht verbauen. Da sind einige Zeilen mehr Code für mich persönlich die bessere Alternative. Da sieht man mal was die "kleinste Informationseinheit" mit dem falschen Wert so alles anstellen kann. --> SOFT-TWI (kombiniert mit HW-TWI) wirds wohl werden. @Bernhard Danke für die Hilfe. Martin
>Danke für die Hilfe. gern geschehen > --> SOFT-TWI (kombiniert mit HW-TWI) wirds wohl werden. Vielleicht sogar komplett ohne HW-TWI, müsste mit einem externen Interrupt zu machen sein. Mach Dir mal gedanken, wir freuen uns jetzt schon auf Deine Veröffentlichung ;) Bernhard
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.