AVR I2C: Worauf Warten bei STOP

[Michael R. (Firma: Brainit GmbH) (fisa)]

Schönen Sonntag allerseits,

ich stell mir gerade folgende zwei Fragen:

a) normalerweise wartet man bei der TWI-Programmierung auf dei 
Fertigstellung einer Operation, indem man das TWINT-bit prüft:

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

In Fleurys Library passiert das auch so, nicht aber beim Senden der 
STOP-Condition, hier wird auf das TWSTO-Bit geprüft:

while (!(TWCR & (1 << TWSTO)));

macht das einen Unterschied, oder ist es egal, und würde mit TWINT 
genauso funktionieren?

Hintergrund: ich möchte in diese Warteschleife ein Timeout einbauen, und 
dafür wäre es natürlich praktisch, wenn ich überall dieselbe 
Warteschleife (also TWINT) verwenden könnte.

Womit wir schon bei Frage b) wären: gibts Erfahrungswerte über ein 
sinnvolles Timeout? Das Timeout sollte so lang wie nötig aber natürlich 
so kurz wie möglich sein. Ich möchte damit verhindern, dass Wackler, 
an/abstecken im betrieb (passiert am Breadboard häufiger) und im 
speziellen amoklaufende Slaves (die SDA und/oder SCL blockieren) 
erkennen, und zumindest einen Fehler per UART ausgeben (momentan bleibt 
er einfach in der Endlosschleife hängen)

Die eigentliche "last resort" Funktion zum harten Resetten des 
I2C-Busses hab ich eh schon fertig (TWI abschalten, händisch 9 Clocks 
ausgeben, händisch STOP erzeugen) nur aufrufen müsst ich sie halt 
auch...

[Marc V. (Firma: Vescomp) (logarithmus)]

Michael Reinelt schrieb:
> while (!(TWCR & (1 << TWSTO)));
>
> macht das einen Unterschied, oder ist es egal, und würde mit TWINT
> genauso funktionieren?

 Macht sehr wohl einen Unterschied, TWINT wird nach senden von
 STOP-Condition NICHT gesetzt.

Michael Reinelt schrieb:
> Womit wir schon bei Frage b) wären: gibts Erfahrungswerte über ein
> sinnvolles Timeout? Das Timeout sollte so lang wie nötig aber natürlich

 Schleife zum Status-Abfragen dauert nur ein paar Cycles, mit Integer
 dauert es höchstens 40mS - und das mit paar zeilen Code.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Marc Vesely schrieb:
> Michael Reinelt schrieb:
>> while (!(TWCR & (1 << TWSTO)));
>>
>> macht das einen Unterschied, oder ist es egal, und würde mit TWINT
>> genauso funktionieren?
>
>  Macht sehr wohl einen Unterschied, TWINT wird nach senden von
>  STOP-Condition NICHT gesetzt.

Uuuups, danke für die Info... nur: woher weisst du das? Die Bibel 
(Datenblatt) ist an der Stelle nicht sehr ergiebig...

> Michael Reinelt schrieb:
>> Womit wir schon bei Frage b) wären: gibts Erfahrungswerte über ein
>> sinnvolles Timeout? Das Timeout sollte so lang wie nötig aber natürlich
>
>  Schleife zum Status-Abfragen dauert nur ein paar Cycles, mit Integer
>  dauert es höchstens 40mS - und das mit paar zeilen Code.
ich kann dir grad nicht folgen... ich versuch mal meine Frage anders zu 
formulieren: reicht ein 16bit-Schleifenzähler, oder sollten es doch 
lieber 32 (24?) bit sein?

[Marc V. (Firma: Vescomp) (logarithmus)]

Michael Reinelt schrieb:
> Uuuups, danke für die Info... nur: woher weisst du das? Die Bibel
> (Datenblatt) ist an der Stelle nicht sehr ergiebig...

 Steht genug:
 "The TWI will not start any operation as long as the TWINT bit in TWCR
 is set. Immediately after the application has cleared TWINT, the TWI
 will initiate transmission of the STOP condition.
 Note that TWINT is NOT set after a STOP condition has been sent."

Michael Reinelt schrieb:
> formulieren: reicht ein 16bit-Schleifenzähler, oder sollten es doch
> lieber 32 (24?) bit sein?

 16 bit reichen vollkommen, etwa so ?
 done=false;
 for (ierr = 0; ierr < 65535; ierr++) { if (TWCR & (1 << TWSTO)
 { done=true; break; } }
 if !done ErrRut(TWSR & 0xF8);

[Michael R. (Firma: Brainit GmbH) (fisa)]

Marc Vesely schrieb:
> Michael Reinelt schrieb:
>> Uuuups, danke für die Info... nur: woher weisst du das? Die Bibel
>> (Datenblatt) ist an der Stelle nicht sehr ergiebig...
>
>  Steht genug:
>  "The TWI will not start any operation as long as the TWINT bit in TWCR
>  is set. Immediately after the application has cleared TWINT, the TWI
>  will initiate transmission of the STOP condition.
>  Note that TWINT is NOT set after a STOP condition has been sent."

Danke danke danke. Den Nebensatz hab ich echt 5 mal überlesen...

> Michael Reinelt schrieb:
>> formulieren: reicht ein 16bit-Schleifenzähler, oder sollten es doch
>> lieber 32 (24?) bit sein?
>
>  16 bit reichen vollkommen, etwa so ?
>  done=false;
>  for (ierr = 0; ierr < 65535; ierr++) { if (TWCR & (1 << TWSTO)
>  { done=true; break; } }
>  if !done ErrRut(TWSR & 0xF8);

Auch danke, dann werd ichs mal mit 16bit probieren. ich war nur etwas 
verunsichert, vor kurzem hatte jemand hier ein problem mit einigermaßem 
extremem Clock-Stretching... nicht dass da dann mein timeout zuschlägt.

[Marc V. (Firma: Vescomp) (logarithmus)]

Michael Reinelt schrieb:
> extremem Clock-Stretching... nicht dass da dann mein timeout zuschlägt.

 Bei 100KHz muss das Stretching mehr als 4000 I2C-Clocks dauern -
 etwas das so lange braucht, hat auf I2C-Bus nichts zu suchen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Marc Vesely schrieb:
> Michael Reinelt schrieb:
>> extremem Clock-Stretching... nicht dass da dann mein timeout zuschlägt.
>
>  Bei 100KHz muss das Stretching mehr als 4000 I2C-Clocks dauern -
>  etwas das so lange braucht, hat auf I2C-Bus nichts zu suchen.

Habs gefunden: Beitrag "Re: Instabiler I²C Bus"

Laut dem beitrag hält der Slave bis zu 26msec SCL auf low (was ich 
extrem finde)

[Michael R. (Firma: Brainit GmbH) (fisa)]

Michael Reinelt schrieb:
> Laut dem beitrag hält der Slave bis zu 26msec SCL auf low (was ich
> extrem finde)

Korrigiere: 66 msec.

[Marc V. (Firma: Vescomp) (logarithmus)]

Michael Reinelt schrieb:
>> Laut dem beitrag hält der Slave bis zu 26msec SCL auf low (was ich
>> extrem finde)
>
> Korrigiere: 66 msec.

 Ja. Dafür kannst du dir aber Mode zur Kommunikation aussuchen und
 dann weisst du auch das du warten must - oder eben nicht warten,
 sondern pollen.