Erkennung TWI Ende

[Matthias (Gast)]

Hallo Gemeinde,

EIne I2C Stopp-Condition generiert man ja mit folgendem Code:

//-- send stop condition --------------------
TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);

Aber wie kann ich jetzt feststellen, ob die Stop-Condition vollständig 
durchgeführt worden ist, also ob der Bus wieder frei ist und ich mit 
einer neuen Übertragung beginnen kann??

Vielen Dank im Voraus...

[Jörg X. (Gast)]

"[...]TWINT is NOT set after a STOP condition has been sent."(atmega48 
datasheet "using the twi")
klingt schlecht

"When the STOP condition is executed on the bus, the TWSTO bit is 
cleared automatically" (selbes Datenblatt "register description")
klingt nach: Das TWSTO-Bit pollen
a`la:

while(TWCR & (1<<TWSTO));
//leserlicher:
while(TWCR & (1<<TWSTO)){
    }

hth. Jörg

[Matthias (Gast)]

Ok. danke Jörg.

[Peter D. (peda)]

Matthias wrote:

> Aber wie kann ich jetzt feststellen, ob die Stop-Condition vollständig
> durchgeführt worden ist, also ob der Bus wieder frei ist und ich mit
> einer neuen Übertragung beginnen kann??

Gar nicht.

Setze einfach das Startbit und gut.
Du kannst es sogar gleichzeitig mit dem Stopbit setzen.

Ein Start wird erst erzeugt, sobald der Bus als frei erkannt wurde.


Peter

[Jörg X. (Gast)]

@  Peter Dannegger (peda):

Mir ist erst nach meinem Post die Frage eingefallen, ob man das 
überhaupt feststellen muss (und ich wollte nicht doppel-posten ;)

[klaus (Gast)]

Peter Dannegger schrieb:
> Gar nicht.
>
> Setze einfach das Startbit und gut.
> Du kannst es sogar gleichzeitig mit dem Stopbit setzen.
>
> Ein Start wird erst erzeugt, sobald der Bus als frei erkannt wurde.
>
>
> Peter

Hmm... das hat bei mir nicht funktioniert.

Also genauer:

Ohne Prüfung ob das Stopbit nach dem Setzen wieder gelöscht wurde, führt 
das zu Fehlern in der Übertragung. (00 == Busfehler)

Wenn ich in einer while Schleife auf das Löschen des Bits warte ist das 
auch problematisch. Wenn man den Bus nämlich etwas "quält", kann es sein 
dass das Bit nie gelöscht wird. Vermutlich weil der Controller nicht in 
der Lage war die Stopcondition richtig zu generieren. Müsste das dann 
nicht wenigstens auch zu einem Busfehler führen?

[N. N. (drnicolas)]

Ich habe die Doku zum TWI gerade nicht vorliegen.

Da ich aber gerade mit dem TWI herumgefluicht habe, hier meine 
Erfahrungen

Meines Wissens ist es nicht erforderlich nach dem TWI_STO-Befehl auf 
dessen Vollzug zu warten.

Was wohl geht, sind diese repeated-starts.

Ansonsten ist es meines Wissens illegal nach START und Senden der 
Baustein-adresse sofort wieder STOp zu senden.
Beim Emulieren wartet man dann beim nächsten START bis in alle Ewigkeit 
auf den Vollzug.

Ich hatte jüngst die Situation, dass ich bei der initialisierung auf das 
korrekte Vorhandensein aller TWI-bausteine testen wollte udn somit alle 
Adressen durchgetestet habe.

[Klaus W. (Firma: privat) (texmex)]

Nicolas Nickisch schrieb:

> Meines Wissens ist es nicht erforderlich nach dem TWI_STO-Befehl auf
> dessen Vollzug zu warten.
>
> Was wohl geht, sind diese repeated-starts.

Richtig, das habe ich jetzt auch herausgefunden!
Wenn man TWSTA setzt bevor TWSTO zurückgesetzt wurde,
wird statt einer Startcondition eine repeated Startcondition
erzeugt. Also mit anderen Worten die Stopcondition "abgebrochen" bevor 
sie überhaupt auf dem BUS erscheint und stattdessen eine Startcondition
erzeugt.

> Ansonsten ist es meines Wissens illegal nach START und Senden der
> Baustein-adresse sofort wieder STOp zu senden.
> Beim Emulieren wartet man dann beim nächsten START bis in alle Ewigkeit
> auf den Vollzug.

Offenbar nicht nur beim Emulieren. TWSTO wird dann nämlich auch nicht 
mehr zurückgesetzt.
Das ist natürlich dann wie erwähnt etwas gefährlich, wenn man mit einer 
while Schleife darauf wartet.

> Ich hatte jüngst die Situation, dass ich bei der initialisierung auf das
> korrekte Vorhandensein aller TWI-bausteine testen wollte udn somit alle
> Adressen durchgetestet habe.


viele Grüße,
Klaus