I2C Clock Stretching mit LPC213x / LPC214x

[Klaus (Gast)]

Hallo zusammen,

ich möchte einen LPC2138 als I2C Slave mit Clock Stretching betreiben.

Der I2C soll über eine IRQ Routine gesteuert werden. Dem Datenblatt des 
LPC2138 (Kapitel 11, Abschnitt 6.5, Seite 135) entnehme ich, dass man 
zum Clock Stretching einfach das SI flag nicht löschen muss. Die SCL 
Line wird dann solange auf GND gehalten.

Nun meine Fragen:

Würde dann bei Clock Stretching nicht nach Beendigung des I2C Interrupts 
unmittelbar wieder ein I2C Interrupt ausgelöst, da das SI flag ja noch 
gesetzt ist?

Mein Programm ist darauf angewießen, dass die main() Schleife immer 
wieder mal etwas Rechenzeit bekommt, bis die Daten verarbeitet wurden 
welche am I2C benötigt werden. Wenn ständig wieder ein I2C Interrupt 
ausgelöst würde, wäre das System ja praktisch lahmgelegt
er?

Habt ihr Tipps wie mit Interrupt trotzdem arbeiten könnte?


Besten Dank für Eure Hilfe
Klaus

[Peter D. (peda)]

Nein, sowas macht man nicht.
Damit würde ja der I2C-Bus totgelegt und der Master könnte nichts 
anderes mehr machen.

Wenn man nicht mehr auf I2C-Pakete antworten will, setzt man das 
ACK/NACK-Bit auf NACK.
Der Master merkt das und muß es dann später nochmal versuchen.


Peter

[marvin m. (Gast)]

Wenn Deine Main zu wenig Zeit hat, Daten zu verarbeiten während 
gleichzeitig Daten über I²C reinkommen, dann hast Du ein anderes 
Problem...
Bei den üblichen 100kBit/s hast Du zwischendrin massig Zeit, 
Berechnungen durchzuführen.

[Klaus (Gast)]

Hallo, Danke für Eure Antworten.

Vielleicht sollte ich das Problem ausführlicher erklären:

Ich kann nicht einfach ACK oder NAK senden, da ich einen I2C <-> Funk 
Übersetzer entwickle. D.h. die Gegenseite muss mir die Antwort (ACK oder 
NAK) liefern. Für mein System sind die Bytes die über den I2C Bus gehen 
und die Antworten darauf ohne jede Bedeutung. Für die zwei 
Kommunikationspartner die über den Adapter kommunizieren, soll es quasi 
so aussehen als würden sie direkt miteinander über den I2C Bus sprechen. 
Nur dass eben die Kommunikation über I2C <-> Funk Adapter geleitet wird.

Und bis ich die Gegenseite kontaktiert habe und diese ihre Antwort 
liefern konnte, muss ich als I2C Slave irgendwie Zeit rausschlagen. 
Daher Clock Stretching.

Jetzt ist die Sache nur die, dass die main() Schleife zyklisch einen 
Zustandsautomat aufruft, der u.a. Nachrichten-Puffer verwaltet und zum 
Beispiel empfangene Nachrichten verarbeitet. Wenn dieser Automat nun 
nicht mehr aufgerufen werden würde, könnte der I2C Interrupt-Handler nie 
Daten erhalten.

Die Frage ist also, wäre das wirklich so: Wenn man Clock Stretching 
verwendet, wird beim LPC2138 sofort wieder ein I2C Interrupt ausgelöst 
weil das SI Flag nicht gelöscht wurde ?

[Peter D. (peda)]

Klaus wrote:

> Ich kann nicht einfach ACK oder NAK senden, da ich einen I2C <-> Funk
> Übersetzer entwickle.

Wenn Du nen I2C implementierst, mußt Du es können, darauf beruht ja der 
ganze I2C.


> Für die zwei
> Kommunikationspartner die über den Adapter kommunizieren, soll es quasi
> so aussehen als würden sie direkt miteinander über den I2C Bus sprechen.

Es wird nie so gehen, als währen die 2 I2C-Teilnehmer direkt miteinander 
verbunden. Du mußt erhebliche Abstriche in Kauf nehmen.

Du mußt Dir entweder ein strenges Protokoll ausdenken oder das ganze 
wird extrem langsam.
Z.B. die Teilnehmer arbeiten ausschließlich als Multimaster-Transmitter.
D.h. der eine schickt die Anforderung an die Funkstrecke. Diese puffert 
sie und sendet sie wiederholt solange an den anderen bis es geklappt 
hat.
Und der andere antwortet genauso, bloß umgekehrt.


> Und bis ich die Gegenseite kontaktiert habe und diese ihre Antwort
> liefern konnte, muss ich als I2C Slave irgendwie Zeit rausschlagen.
> Daher Clock Stretching.

Ja, das ist dann die arschlangsame Version (wenige 100 Bit/s).

Funkstrecken sind wie USB, einzelne Bits und Bytes können sie nur sehr 
langsam, sie wollen lieber längere Pakete übertragen.
Es muß ja ständig zwischen Empfang und Senden umgeschaltet werden und 
das kostet viel Zeit.


Peter