Zitat Zitat von oberallgeier Beitrag anzeigen
Hängt der Bus wegen eines Teilnehmers (I²C-Adressaten), dann ist auch die Kommunikation mit anderen I²C-Baugruppen nicht möglich. Wäre es also vergebliche Mühe einen solchen Deadlock als Problem anzusehen und eine Lösung zu überlegen?

Ich meine schon. Wenn der Master hängt, dann hängt ja schließlich die ganze Apparatur - egal welche es auch ist. Wenn ein solches Hängenbleiben in der I²C-Routine verhindert werden kann, dann könnte wenigstens noch eine Störungsmeldung oder Ähnliches vom Master ausgegeben werden, es liegt ja nach der Abfrage ein entsprechendes 0/1-Signal vor. Daher die Frage ob es eine Lösung gibt und wie die aussieht?
1. Daß der I2C Bus kein Timeout hat, ist eine prinzipielle Schwäche. Dies ist beim SMBus "nachgerüstet" worden. Da wird von einer minimalen Busfrequenz von 10k ausgegangen.

2. Auf eine Statusänderung ohne Timeout zu warten, ist eigentlich ein grober Programmierfehler. Ich muß aber zugeben, aus reiner Faulheit mache ich das auch oft. Auf einem PC ist das häufig nicht ganz so schlimm, neue Console aufmachen und Task killen. Es bleibt aber Schlamperei und ich mach das auch nur, wenn es keiner sieht.

Außer einem Hardwarefehler gibt es noch andere Ursachen für einen hängenden I2C Bus. Häufig passiert sowas beim Debuggen, Breakpoint irgendwo in der Mitte des I2C Codes, Programm wird neu gestartet oder neu geladen und ein Slave hängt. Nach einem Powercycle geht alles wieder. Da kommt man raus, wenn man 8 (oder waren es 9?) mal mit SCL wackelt und dann ein Stop ausgibt.

Was du tust, mußt du aus Systemsicht entscheiden. Was soll dein System tun, wenn durch einen Hardwarefehler der I2C Bus hängt? Diesen Fall kann man möglicherweise auch schon früher erkennen. Am Anfang die Pins für SCL und SDA als Input schalten, und schauen ob beide High sind. Wenn ja ist das ein gutes Zeichen, wenn nein, brauchst du einen Plan B. Wenn dein Bus später (im Betrieb) hängt, brauchst du auch einen Plan. Macht es Sinn, den Bus noch mal zu initialisieren (siehe oben) oder sollte das System in eine Art Notbetrieb gehen oder sich ausschalten.

Da du der Chef in deinem System bist, und ein I2C Timeout Sache des Masters ist, würde ich mir nicht viele Gedanken um die Länge des Timeouts aus I2C Sicht machen. Hier ist eigentlich wieder die Systemsicht gefragt. Ein Beispiel: ein Roboter fährt, ein Kollisionssensor wird über I2C abgefragt. Wie lange kann man auf die Antwort vom Sensor warten, bevor man eine Notbremsung einleitet. Das wären für mich so Kriterien für das längste Timeout.

MfG Klebwax