Kenwood Protokoll --> I2C

Martin Gast #337097
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Bernhard S. #337098
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin Gast #337099
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernhard S. #337100
Lesenswert?
• ▲
▼ 
>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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin Gast #337101
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernhard S. #337102
Lesenswert?
• ▲
▼ 
>--> 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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin Gast #337103
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren