Korrekte I2C Fehlerbehandlung (AVR)

RonS Gast #2303829
Lesenswert?
• ▲
▼ 
Hi,

mir ist die korrekte Reaktion auf ggf. auftretende Fehler in der 
I2C-Kommunikation noch nicht recht klar und auch die Atmel-Doku hilft 
nicht recht weiter.

Background ist hier eine einfache I2C-Single Master App mit 
Transmitter+Receivermodus beim Ansprechen eines HYT939 Sensors.
I/O rein im Interruptbetrieb.

Für die Reaktion auf Fehler wie NACK nach SLA+W/R oder 
Daten-Transmission, illegalem Start/Stop  oder irrelevanter Status-Info 
fand ich bisher zwei verschiedene Möglichkeiten:

Entweder mit

(1) TWCR= (1<<TWINT)|(1<<TWEN)|(1<<TWSTO)

oder z.B. lt. AVR315 Doku mit

(2) TWCR = 
(1<<TWEN)|(0<<TWIE)|(0<<TWINT)|0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC)

Warum mal mit, mal ohne TWI-STOP? Warum TWINT mal 1, mal 0?  Soll das 
Flag etwa rückgesetzt werden? Dann doch bitte nur mit 1 ... ?!
Kann hier mal jemand Klarheit reinbringen? Danke.

RonS
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Harald M. #2304983
Lesenswert?
• ▲
▼ 
Ron,

die AppNote AVR315 setzt ein bestimmtes Verhalten des uC um. Warum das 
so gewählt wurde, wird in dort leider nicht erklärt. Die Situation "NAK 
nach Senden von SLA_R/W" tritt immer auf, wenn der uC versucht, einen 
nicht vorhandenen Slave anzusprechen. Die AppNote sieht ein Verhalten 
vor, bei dem sich der Master danach "totstellt". Es ist sehr gut 
möglich, dass dieses Verhalten für Deine Anwendung ungeeignet ist (für 
meine, jedenfalls, wäre es das).

Nach einem abgebrochenen Sendeversuch kein STO zu senden halte ich für 
gefährlich - in meinen Programmen sende in solchen Fällen immer eines. 
Nur so können die anderen Masters sicher sein, dass der Bus frei ist. 
Andernfalls bleibt der Bus blockiert, bis z.B. in einem der Masters ein 
Time-out-Zähler abgelaufen ist. Interessanterweise sieht die AppNote 
keinen Time-out-Mechanismus vor (oder habe ich was übersehen?).

Auch das Abschalten des TWIE und des TWEA halte ich für problematisch. 
Wenn auch der Empfang interruptgesteuert abgewickelt wird, kann der uC 
danach nämlich nix mehr "hören".

Eigentlich würde es nach einem "NAK nach Senden von SLA_R/W"-Ereignis 
genügen, die Sendung zu beenden (STO senden) und die entsprechende 
Adresse aus dem Slave-Verzeichnis des uC zu löschen. Dazu braucht man 
aber den TWIE und TWEA nicht abzuschalten.

Du musst die AppNote eher als Beispiel lesen, an was man beim Aufstellen 
der Abläufe (wie auf Seite 10 gezeigt) alles beachten muss.

Ciao,

mare_crisium
Antwort Zitieren Bearbeiten Löschen Beitrag melden
RonS Gast #2323419
Lesenswert?
• ▲
▼ 
Ja ich machs in meiner Single Master Transmit/Receive Anwendung jetzt 
grundsätzlich so daß auf jedwede Störung im Kommunikationsablauf / 
unerwartete Statuscodes einfach geSTOPt wird! Bis zur nächsten Messung 
dann einfach TWI-OFF und schließlich wieder Neuinitialisierung. Mein 
TWI-Treiber ist mittlerweile fertig und funktioniert ohne 
Kommunikationsfehler, ich hoffe aber daß dieses Vorgehen im wirklichen 
Fehlerfall dann auch immer angemessen ist ?!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Olaf Gast #2323461
Lesenswert?
• ▲
▼ 
> ich hoffe aber daß dieses Vorgehen im wirklichen
> Fehlerfall dann auch immer angemessen ist ?!

Es gibt Slaves bei denen sich die interne Statemachine bei Stoerungen 
weghaengt. Oft hilft es dann bei einem Fehler mit der SCL-Leitung zu 
wedeln.

Olaf
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