I²C und der Deadlock bei Atmel 8Bitter mega. Ein Lösungsvorschlag

[oberallgeier]

... UART ... oft gewartet ... könnte man ... Delay ... über die Baudrate ausrechnen ...

Ne Abstimmumg der Wartezeit mit der Kommunikationsgeschwindigkeit hatte ich beim I²C schon versucht - die oben erwähnte Warteschleife mithilfe des TWBR dimensioniert. Da ja Störungen nur sehr schwer realistisch zu simulieren sind, weiß ich nicht ob das besser ist.

Dummerweise hatte ich mich sowieso zu früh über meine for(..-Schleifenlösung gefreut.

... Auf eine Statusänderung ohne Timeout zu warten, ist eigentlich ein grober Programmierfehler ...

Das würde ich auch so sehen. Aber (wie gesagt, ich hatte zu schnell meine Deadlocklösung gepostet) Atmel siehts anders, Beispiel Wait for TWINT Flag set :

... while (!(TWCR & (1<<TWINT))) ; ...

Und ich denke, dass diese Leute schon deutlich besser C können als ich. Dumm! Nun glaube ich die Lösung zum Deadlock bei I²C eher in der Art wie Robert es vorschlägt - einen Störfall in dieser Umgebung besser mit einer externen Maßnahme, z.B. einem äußeren Limit, abfangen . . .

Schade, der Schnellschuss war zu früh, läuft u.a. auf meinen eigenen Ratschlag raus: rtfm. Und eben VORHER lesen, dann posten.