TXT und clock-stretching

[thkais]

Hallo,

das Thema "clock stretching" ist ja immer wieder mal aktuell und bisher lautete die Aussage: Es wird nicht unterstützt.
Abgesehen davon, dass laut I²C-Spezifikation clock-stretching nicht "mandatory" sondern "optional" ist, wollte ich der Sache auf den Grund gehen um evtl. auch eine Lösung zu finden. Ich habe nun einige Messungen gemacht und bin zum Ergebnis gekommen, dass der TXT sehr wohl das clock-stretching unterstützt. In meinen Augen verhält er sich absolut konform zu den I²C-Spezifikationen (Link im PDF).
Die Messungen habe ich zu einem PDF zusammengefasst: http://ft-fanpage.de/TXT/TXT_clock_stretching.pdf

Weiterhin scheint der TXT nach 1s clock-stretching einen Timeout zu generieren, dies ist so eigentlich nicht richtig (laut Spec darf das clock stretching ewig dauern) aber sinnvoll, um bei einem hängenden I²C-Slave eine Fehlerbehandlung machen zu können.
Dieses Verhalten und das Verhalten bei clock-stretching auf Bit-Ebene werde ich als nächstes untersuchen.

[Defiant]

I2C Clock stretching...die Raspberry Pi User können ein Lied davon singen...

An dieser Stelle muss man daran denken, dass der I2C-Userspace Treiber auf smbus ausgelegt ist. Kann der Timeout daher kommen?
Das Verhalten mit dem Timeout hab ich btw auf mehreren ARM-µC (TI OMAP/Sitara, NXP i.MX6/7, Xilinx Zynq7000) beobachtet, könnte also gewollt sein.

EDIT: Ich habe dein PDF überflogen, die 10ms Verzögerung verwundern mich und die halte ich mit dem Verweis auf ein Nicht-RT-OS nicht erklärbar. Kannst du mehr zum Messaufbau sagen?

[thkais]

Hallo Defiant,

woher genau die 10ms kommen, kann ich nicht sagen - kann auch von RoboPro her sein, der einzige Punkt der tatsächlich in der Beschreibung des Messaufbaus fehlt: Der TXT wurde online angesteuert, d.h. da könnte auch noch eine Verzögerung durch Windows oder USB auf PC-Seite beteiligt sein. Da sollten Messungen im Download-Modus aufschlussreich sein.
Die 10ms stören aber m.E. nicht sonderlich, denn es stand die Behauptung im Raum, der TXT würde clock-stretching garnicht unterstützen. Dies ist meinen Messungen zufolge nicht der Fall.
Und den Timeout nach 1s halte ich wie erwähnt für sinnvoll - welches Device stretcht SCL um 1s ?
Ansonsten sollte der Messaufbau klar sein, oder welches Detail fehlt dir?

[H.A.R.R.Y.]

Hallo thkais,

gegenwärtig gibt es hier zwei Threads, die das Thema aufwerfen:
viewtopic.php?f=21&t=3373&p=23096&hilit=stretching#p23096
viewtopic.php?f=33&t=4270&p=30831&hilit=stretching#p30831

Darauf basierend läuft noch 'ne Anfrage von mir nach Waldachtal:
viewtopic.php?f=21&t=4278&p=30901&hilit=stretching#p30901

Dass Du nun noch einen Thread extra aufmachst, fördert die Übersicht für meinen Geschmack nun nicht so sehr. Aber sei es drum (es wirft mir ja nur meinen vorbereiteten ft:pedia-Artikel durcheinander).

BTT:

Abgesehen davon, dass laut I²C-Spezifikation clock-stretching nicht "mandatory" sondern "optional" ist, wollte ich der Sache auf den Grund gehen

Die I²C-Spec 6.0 ist ja schön und gut. Table 2 auf Seite 8 zeigt was Mandatory, Optional oder n/a ist. Auch gut.
Beim Clock stretching steht in beiden Master-Modi "O" für Optional, geziert von einer Fußnote:
"[2] Clock stretching is a feature of some slaves. If no slaves in a system can stretch the clock (hold SCL LOW),
the master need not be designed to handle this procedure."
Beim Slave ist die Sache klar: der darf, muss aber nicht ("O").
Bei den Master-Modi ist der Satz durchaus so zu verstehen, dass clock-stretching entbehrlich ist, wenn im abgeschlossenen Produkt keiner der angeschlossenen Slaves clock-stretching macht. Andersherum ist es der Master zwingend für clock-stretching vorzubereiten, wenn wenigstens ein Slave im Produkt das verwendet. Für ein offenes Bussystem - offen für eigene Erweiterungen, wie z.B. TX / TXT - erscheint es mir zwingend nötig dem Master clock-stretching beizubringen! Also nix mit "optional".

Der TXT ist nun offensichtlich doch besser als sein Ruf (s.o.) und es wird Zeit, dass mal jemand falschen Behauptungen entgegentritt, wenn dem so ist.

Grundsätzlich: Tolle Arbeit und ich finde das großartig was Du für uns da nachforschst. Herzlichen Dank!

Mir fehlt die Info: Welches OS verwendest Du für den TXT und welches RoboPro?

Nun zu Deinem pdf mit den Messungen:
Messung 1 zeigt das clock-stretching nach dem 9. Bit - also nach dem ACK-Bit. Ein typischer µC als Slave macht das stretching aber nach dem 8. Bit, also vor dem ACK-Bit, weil er genau jetzt erst die Adresse prüfen kann. Erst danach kann er mit ACK oder NACK antworten.
Eventuell ist der Slave auch von der langsameren Sorte und macht ein clock-stretching schon nach dem START-Zyklus bis er für das Adressbyte bereit ist.
Bei den Datenpaketen im Schreibzugriff würde ich das ähnlich sehen, das ACK geht erst vom Slave retour wenn die Applikation das Byte abgeholt hat. Beim Lesezugriff habe ich gegenwärtig keine Idee, wie das da sein könnte.
Könntest Du den TXT eventuell in dieser Hinsicht untersuchen?
Du wolltest ja noch das Verhalten auf Bitebene untersuchen (also irgendwo mitten im Byte), und da könntest Du das gleich mit aufzeichnen?

Die Geschichte mit dem Timeout:
Wenn SDA auf '0' klemmt, versucht der Master das mit 9 SCL-Pulsen zu kurieren. Wenn SCL auf '0' klemmt, dann war für den SM-Bus was mit 25ms im Äther. Ist aber auch egal, den Timeout halte ich ebenfalls für sehr sinnreich. 1s für einen abgestürzten Slave ist sehr generös und kein Slave sollte da überhaupt in die Nähe kommen!

Grüsse
H.A.R.R.Y.

[thkais]

Hallo Harry,

man muss dem TXT kein clock-stretching mehr beibringen - es ist vorhanden. Ergo ist die Diskussion, ob mandatory oder nicht, obsolet - es war mir nur aufgefallen.

Der verwendete Slave ist - wie im PDF erwähnt - ein µC mit Hardware-I²C, bei dem die Adressdekodierung bereits in HW stattfindet. Das dürfte erklären, warum das Stretching erst nach dem ACK kommt. Eine eingehende Erklärung wie die HW-I²C bei dem µC funktioniert, würde die Dokumentation sehr aufblähen - man sieht anhand der Bilder ja exakt, was der Slave wann macht, ich kann aber gerne das Datenblatt des µC verlinken.
Edit: Zumindest habe ich in diesem Fall keinen Einfluss auf den Zeitpunkt des Stretchings, das macht die HW des µC.

Wenn du einen Artikel vorbereitet hast - hast du dich nur auf die bisherigen Erkenntnisse gestützt oder eigene Messungen gemacht?
Für die Untersuchungen auf Bit-Ebene werde ich einen Software-I²C verwenden, damit man quasi überall eingreifen kann.
Ich nutze die aktuelle originale Firmware 4.2.4 mit dem zugehörigen RoboPro. Es ist zu erwarten, dass auch die community-FW nicht anders reagieren wird.

Edit:
Ich bin mit den Ausführungen von Reivilo nicht einverstanden. Er geht davon aus, dass der Slave von sich aus ein Clock-Stretching initiiert. Das ist aber definitiv nicht konform zum I²C Standard, denn prinzipiell startet der Master jedewede Kommunikation, d.h. der Slave darf SCL erst dann "übernehmen", wenn der Master ein Low vorgegeben hat.Das Delay, das Reivilo gemessen hat (1 Sekunde) und woraufhin er dem TXT das clock-stretching absprach, wurde durch einen Slave verursacht, der außerhalb eines Start/Stop Frames SCL von sich aus auf Low legte.
Außerhalb eines Start/Stop Frames gibt es aber nur eine gültige Operation: Ein Start-Bit, das durch den Master eingeleitet wird.
Durch einen außerhalb des Start/Stop Frames auf low gelegtes SCL scheint der TXT in eine Art Fehlerbehandlung zu gehen, und legt SDA im Sekundentakt auf Low/High, um irgendwie ein Start-Bit durchzubekommen. Ob dieses Verhalten vom OS-Treiber oder von RoboPro kommt (im RoboPro Programm ist ein 1-Sekunden Delay im Fehlerfall eingebaut) werde ich noch prüfen.

[MasterOfGizmo]

Im Prinzip kann der Client SCL immer dann festhalten, wenn der Master es auf low gezogen hat. Das ist auch bei anderen als den Bits der Start- und Stopsignalisierung möglich. Beim Ack kann das der R-Pi auch, aber bei Datenbits stolpert er beim Clock-Stretching. Der Test des OP würde also auch beim R-Pi gutgehen.

[H.A.R.R.Y.]

Hallo zusammen,

aha, jetzt kommt mal so langsam Licht ins Dunkel. Wie der Mythos des "kann kein clock-stretching" in die Welt gesetzt wurde und was dann tatsächlich doch geht.

Ich bin jedenfalls sehr neugierig auf thkais weitere Testergebnisse.

Grüsse
H.A.R.R.Y.

[thkais]

Moin,

Der Test des OP würde also auch beim R-Pi gutgehen.

Das kann ich nicht nachprüfen - da lasse ich dir gerne den Vortritt.

Dann muss der TO wohl nochmal nachlegen:
http://ft-fanpage.de/TXT/TXT_clock_stretching_2.pdf
Diesmal mit einer etwas einfacheren Übertragungsvariante, aber m.E. aussagekräftig. (Habe gerade nicht so richtig den Zug, einen SW-I²C Slave zu basteln, der neben den Eingriffsmöglichkeiten in das Timing auch noch Schreiben und repeated-Start beherrscht...)

Bevor ich mir noch Nächte um die Ohren schlage, würde mich mal interessieren:
- Hat schonmal jemand einen I²C-Slave an den TXT angeschlossen, der nachweislich Clock-Stretching nutzt?
- Mit welchem Ergebnis?
Oder wird dieses Thema eigentlich nur theoretisch diskutiert

[H.A.R.R.Y.]

Hallo thkais,

das Thema ist für mich zwar zur Zeit noch theoretisch, demnächst aber von praktischer Bedeutung. Schau mal bitte in Dein PN-Fach.

Mit Deiner 2ten Messreihe betrachte ich die Thematik nun als erschöpfend beantwortet. Der TXT kann das mit dem clock-stretching immer und überall und läßt sich nicht wirklich davon beeindrucken. Danke, dass Du Dir die Nacht um die Ohren gehauen hast.

Gruß
H.A.R.R.Y.