I2C-Befehle unterbrechen

[Che Guevara]

Hi,

bevor ich jetzt mit dem basteln und programmieren anfange, wollte ich mal fragen, was passiert wenn mehrere I2C-Befehle (Start, Send, Receive, Stop) durch andere I2C-Befehle unterbrochen werden?
Hintergrund:
Auf einem ATXMega32A4 wird mit 800Hz eine Routine aufgerufen, die einen Sensor über I2C abfrägt. Jetzt möchte ich in der Mainloop einen anderen I2C-Slave abfragen, weiß aber nicht so genau, was passiert wenn z.b. in der Mainloop schon die Adresse des einen Slave gesendet wurde und dann der Interrupt reinkommt und den anderen Slave anspricht? Den Interrupt disablen ist leider nicht möglich, da es eine Software für meinen Quadrocopter ist und dieser Interrupt die Regelschleife darstellt. Beide Slaves hängen an der selben Schnittstelle (TWIC).

Wäre nett, wenn jemand da mal was schreiben könnte

Gruß
Chris

[Kampi]

Hey,

ich denke mal, dass es dann zu einem komischen Verhalten der Busteilnehmer führen kann.
Der Fall der am wenigsten schlimm wäre wäre der, wenn der Slave dann einfach nur ein Error ausgibt, weil er den Befehl nicht versteht.
Wenn der Fall eintritt das schon ein Slave adressiert wurde, kannst du keinen anderen Slave adressieren, da der Slave ein Ack auf den Bus gibt wenn er adressiert wurde.
Der Fall würde dann etwa so ablaufen:
Slave 1 wird adressiert und bestätigt diese. Er wartet nun auf Befehle
Du willst Slave 2 adressieren und der Slave 1 würde diese Adresse u.U. als Befehl werten
Slave 1 reagiert auf den Befehl und Slave 2 wird nicht adressiert

[TheDarkRose]

Interrupt setzt ein Flag -> I2C Kommunikation wird erst im Mainloop durchgeführt.

[Che Guevara]

Hi,

@Kampi,
genau so dachte ich mir das auch, aber ich war nicht sicher, obs da nicht irgendeine Art Sicherung gibt...

@TheDarkRose,
du meinst, ich solle in der ISR nur ein Flag setzen und das ganze Programm dann in den Mainloop stecken und auf das Flag warten? So hatte ich es vorher, bis ich gemerkt hatte, dass ich da das Timing nicht so sauber hinbekomme... Deswegen ist es jetzt so und ich werde es auch so belassen.

Gruß
Chris

[Kampi]

@Kampi,
genau so dachte ich mir das auch, aber ich war nicht sicher, obs da nicht irgendeine Art Sicherung gibt...

Hey,

hardwaremässig gibt es keine Sicherung (zumindest weiß ich nichts davon).
Du musst sowas durch deine Software umgehen.

[Che Guevara]

Hm ok, dann werd ich mir mal was überlegen... Danke für eure Antworten!

Gruß
Chris

[Klebwax]

Hi,

@Kampi,
genau so dachte ich mir das auch, aber ich war nicht sicher, obs da nicht irgendeine Art Sicherung gibt...

Wenn du I2C in Hardware nutzt, gibt es schon gewisse Sicherungen, ein Byte, daß gerade auf den Bus geschoben wird, kann man nachträglich nicht mehr ändern. Das rettet aber nicht den ganzen Frame.

@TheDarkRose,
du meinst, ich solle in der ISR nur ein Flag setzen und das ganze Programm dann in den Mainloop stecken und auf das Flag warten? So hatte ich es vorher, bis ich gemerkt hatte, dass ich da das Timing nicht so sauber hinbekomme... Deswegen ist es jetzt so und ich werde es auch so belassen.

Das mit dem Flag kann auch nicht gehen. Die Mainloop müßte schneller als die Interrupte sein, sonst verliert man Interrupte.

Die einzige Möglichkeit ist umgekehrt. Man muß sich das Timing ganz genau ansehen und die I2C Übertragungen so auf die Interrupte verteilen, daß sie nicht ineinander laufen. Das erfordert sorgfältige Planung.

MfG Klebwax

[for_ro]

Hallo Chris,
reicht denn 1/800 s nicht, um den zweiten Sensor abzufragen? Ist doch eigentlich jede Menge Zeit. Allerdings musst du davon noch die Ausführungszeit der I2C Befehle im Interrupt abziehen.
Wenn das reicht, musst du die I2C Kommunikation nur unmittelbar nach dem Interrupt machen, wie oben geschrieben mittels eines Flag.
Wenn nicht, bleibt noch die Möglichkeit, einzelne Teile der gesamten Kommunikation zwischen den interrupts durchzuführen, so wie Klabwax das vorgeschlagen hat.