I2C hängt sich auf, wie reset?

Achim S. schrieb:
> Ich hoffe, Du reagierst angemessen auf die üblichen Fehler, wie z.B.
> kein Acknowledge vom Slave.

Ja, ich habe einen "Timer" der mir ein return 1 gibt bei einem 
Fehlschlag.

Achim S. schrieb:
> - Durch soviele Clockimpulse, bis er fertig ist.

Nun ja, wenn sich der Slave wirklich aufhängen würde, dann wäre doch der 
SDA Pin auf LOW und würde dort bleiben, oder? Das ist bei mir nie der 
Fall.

Arduinoquäler schrieb:
> Die Lösung ist, die Ursache des Problems zu beheben und
> nicht den Fehler mit herumpatchen zu übertünchen.

Das ist einfacher gesagt als getan, es gibt viele Störquellen 
(Quadcopter Umgebung) und es ist sicher zuverlässiger, wenn man auch bei 
einem Fehler die weitere Funktion garantieren kann.

Arduinoquäler schrieb:
> Sebastian T. schrieb:
>> scheint dies nicht die Lösung zu sein.
>
> Die Lösung ist, die Ursache des Problems zu beheben und
> nicht den Fehler mit herumpatchen zu übertünchen.

Auch wenn ich dir da im Prinzip recht gebe, kann es immer mal zu einer 
Störung kommen. Die Software muss robust gegen sowas sein und darf das 
nicht mit dauerhaft lahmgelegter Kommunikation quittieren.

Arduinoquäler schrieb:
> Sebastian T. schrieb:
>> Das ist einfacher gesagt als getan,
>
> Dann ist der I2C Bus der falsche Bus für diese Anwendung, oder
> die praktische Umsetzung ist so mangelhaft (ich könnte auch
> sagen scheisse) dass der Bus zu leicht gestört werden kann.

Ok, mal angenommen, es wird so umgebaut, dass er nur noch schwer zu 
stören ist, und es kommt trotzdem mal eine Störung vor. Was dann?

g457 schrieb:
> Es kann auch der Master hängen bleiben

Wenn ich mit dem Debugger das ganze verfolge, dann bleibt der Master 
(STM32) nicht hängen. Ich initialisiere alles neu und versuche etwas zu 
senden, doch der I2C scheint die ganze Zeit busy zu sein. Dann 
wiederholt sich das ganze.

1

while(I2C_GetFlagStatus(I2C2, I2C_FLAG_BUSY)) {

2

    if (--timeout == 0) {

3

      return 1; //es kommt dann immer zu return 1

4

    }

5

  }

Ok, ich habe es hinbekommen, das Problem war, dass ich den TX Stream 
nicht wieder aktiviert hatte mit DMA_Cmd(DMA1_Stream7, ENABLE); beim 
erneuten initialisieren.

Danke und Grüsse,

Sebastian

Arduinoquäler schrieb:
> Rolf M. schrieb:
>> Ok, mal angenommen, es wird so umgebaut, dass er nur noch schwer zu
>> stören ist, und es kommt trotzdem mal eine Störung vor. Was dann?
>
> Ok, mal angenommen, es fliegt aus dem All ein Teilchen ins
> RAM deines Computers und trifft genau eine Speicherzelle
> deines laufenden Kernels ....

Es gibt nicht nur schwarz oder weiß. Nur weil es bestimmte Störungen 
gibt, gegen die man nichts tun kann, heißt das nicht, dass man seine 
Software nicht robust gegen die machen sollte, gegen die man sehr wohl 
was tun kann.
Übrigens sind tatsächlich Systeme, die besonders zuverlässig sein 
müssen, mit Fehlerkorrektur für den RAM ausgestattet.

Arduinoquäler schrieb:
> Rolf M. schrieb:
>> Übrigens sind tatsächlich Systeme, die besonders zuverlässig sein
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> müssen, mit Fehlerkorrektur für den RAM ausgestattet.
   ^^^^^^
>
> Wenn der Windows Kernel läuft, dann tut er das sicherlich an

Ich habe dir da oben mal was markiert, was in totalem Widerspruch zu 
deinem Beitrag steht. Wenn man schon Geld in fehlerkorrigierende 
Hardware reinsteckt, dann konkterkariert man diese Maßnahmen (die ja die 
Verfügbarkeit des Gesamtsystems erhöhen sollen) tunlichst nicht durch 
den Einsatz von Windows.

Ich glaub, wir schweifen etwas vom Thema ab. Was ich sagen wollte (und 
auch gesagt hab) ist, dass ich es für sinnvoll halte, Software 
fehlertolerant auszulegen, also so, dass sie mit Fehlern adäquat umgeht, 
wo das möglich ist. Manch einer mag das "Patchen, Herumpfriemeln, 
Übertünchen" nennen, ich nenne es robustes Software-Design. In der 
Automobilbranche wird sehr viel Aufwand genau in dieses Thema gesteckt, 
denn im Auto darf nicht einfach alles ausfallen bis das nächste Mal die 
Batterie abgeklemmt wird, nur weil auf dem Bus mal ein Bit gekippt ist. 
Vielmehr haben alle Steuergeräte in solchen Fällen auf genau definierte 
Art und Weise zu reagieren.

Klaus schrieb:
> Bei einer "schlechten" HW
> dutzende ADC Werte mitteln und dann an das Ergebnis glauben, Nachrichten
> mehrfach schicken und Mehrheitsentscheidungen treffen ist das eine, eine
> anständige Fehlerbehandlung das andere.

Nun, "Arduinoquäler" fand es ja anscheinend nicht nötig, dass die 
Software damit klar kommt, wenn auf dem I²C mal ein Übertragungsfehler 
passiert und findet es völlig in Ordnung, wenn die Kommunikation dann 
komplett zusammenbricht und nicht mehr funktioniert, bis man das ganze 
von der Versorgung trennt und wieder anschließt. Ich sehe das anders, 
und darauf bezog sich auch meine Antwort.
Natürlich muss man auch die Hardware so bauen, dass Störungen möglichst 
nicht auftreten. Zusätzlich sollte man aber auch die Software dagegen 
absichern, statt einfach zu sagen: "Ich hab ja in der Hardware schon 
alles getan, also können Fehler ja eh nicht mehr auftreten".