Hallo thkais,
gegenwärtig gibt es hier zwei Threads, die das Thema aufwerfen:
viewtopic.php?f=21&t=3373&p=23096&hilit=stretching#p23096viewtopic.php?f=33&t=4270&p=30831&hilit=stretching#p30831Darauf basierend läuft noch 'ne Anfrage von mir nach Waldachtal:
viewtopic.php?f=21&t=4278&p=30901&hilit=stretching#p30901Dass 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:
thkais hat geschrieben: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.