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
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
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 ?!
> 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
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.