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

[oberallgeier]

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

Hmmmmm. Soweit ich es sehe, huscht diese "while (Bedingung)"-Version aber eifrig durch unsere Wohnzimmer. Z.B. bei PFleurys I²C-Routine, vermutlich auch bei anderen. Wie kommerzielle Routinen aussehen weiß ich nicht. Die Konsequenzen dieses Abfrageroutine waren mir mit meiner eher geringen Programmiererfahrung garnicht klar. Egal - jetzt klappts für meine Bedürfnisse ganz gut. Übrigens ist in der FleuryLibrary auch im stop-Befehl (und anderen) eine solche while-Schleife . . .

[Klebwax]

Nun ja, der Teufel steckt wie überall im Detail.

Nehmen wir mal ein UART. Dort wird oft gewartet, bis ein Byte fertig gesendet ist. Dies könnte man auch mit einem Delay erledigen, dazu sollte man aber schlauerweise die Zeit über die Baudrate ausrechnen. Besser ist natürlich, den UART selbst zu benutzen, also auf den Status zu warten. Kann es einen externen Grund geben, daß das Status-Bit nicht kommt? Nein, ein UART sendet auch in eine defekte Hardware. Kann es einen internen Grund geben, daß das Bit nicht kommt? Schon, wenn man vergisst, den UART zu intialisieren. Will man diesen Fall in seine Fehlerbehandlung mit einbeziehen (wenn man z.B. eine Library schreibt, totale Noobs sie einsetzen um sie dann Schrott zu nennen) wäre ein Timeout eine Möglichkeit (es gibt aber mehr). Ist man sicher, daß dieser Fall nicht eintritt, ist es sicher legitim ohne timeout zu loopen.

Wie intensiv man sich solchen Überlegungen widmen sollte, hängt natürlich vom Projekt ab. Ob die Software bei einem kleinen Robotor hängt, oder ob ein 400kg Kettenfahrzeug (aus einem anderen Thread) außer Kontrolle gerät macht schon einen Unterschied.

MfG Klebwax

[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.