Clock Stretching?

Tag!

Ich versuche seit 2 Tagen, dem Kompass-Sensor HMC6343 sinnvolle Daten zu entlocken. Das Teil wird per I2C angesprochen und ich benutze die I2CMASTER.s von Peter Fleury. Hat sich bei diversen anderen, aehnlichen Modulen meines Projekts gut bewaehrt. Der HMC macht allerdings Zicken. Es sieht aus, als wuerden nichtmal meine Befehle richtig ankommen. Ich habe heute mal eine Oszi-Analyse gemacht und dabei ist folgendes rausgekommen:

Bild hier  


Der dazugehoerige Code ist:

Code:

---

       
i2c_start(0x32 + I2C_WRITE);
i2c_write(0xE1);
i2c_write(0x04);
i2c_stop()

---

Was bedeuten wuerde, dass ich an die Adresse 0x32 (Adresse des Sensors) den 'Befehl' 0xE1 schicke, was Lesen des EEPROMS bedeutet und zwar aus dem Register 0x04.
Auf dem Oszi-Bild sieht man gut, dass die Signale auf der SDA-Leitung nicht zum Takt passen, der irgendwie verzoegert ist nach dem ersten Byte. Ich habe die Taktrate bereits runtergestellt, vorher waren die Abstaende im Takt zwischen den Bytes noch wesentlich groesser.
Meine Frage nun: Betreibt der Sensor Clock Stretching? Sieht mir fast so aus. Und die Anschlussfrage: Fleury schrieb 2008 in seine News, dass die Lib nun Clockstretching unterstuetzt, wieso also funktionierts nicht? In einem anderen Oszi-Bild (was ich leider gerad nicht da habe) sah man deutlich, dass zwischen 2 Bytes der Takt regelrecht langsamer wurde, ca. auf die Laenge eines Bytes gestreckt. Das Problem war, dass an dieser Stellle waehrend einer Taktphase mehrere Datenbits auf der Datenleitung liefen. Das da nur Muell bei rauskommt, kann man sich ja vorstellen. Die Lib kommt also mit dem Clockstretching offenbar nicht klar...

Ok das Bild scheint verschwunden zu sein, danke Imageshack. Wie dem auch sei, ich hab nochmal etwas rumgebastelt und realisiert, dass Clock Stretching im Write-Befehl ja eigentlich gar nicht vorgesehen ist. Der Grund dafuer, dass meine Daten nicht so ankommen wie gedacht ist, dass (vorrausgesetzt ich clocke langsam genug) beim 3. Byte einfach die Clock aufhoert nach dem 7. Bit. Sobald dann SDA auf High geht, ergibt sich daraus eine Stopp-Bedingung, die Uebertragung ist beendet und total vor die Wand gefahren. Ich hab aber keine Ahnung wieso die so einfach aufhoert. Stretching kann es nicht sein, weil dann der Clock auf Low gehalten werden muesste.
Interrupts passieren auf dem Controller auch keine, der nur mit Software-I2C beschaeftigt. Vorsichtshalber hab ich auch den Sende-Code in CLI und SEI gekapselt:

Code:

---

cli();
i2c_start(0x32 + I2C_WRITE);
i2c_write(0xE1);
i2c_write(0x42)
i2c_stop();
sei();

---

Hier das Bild dazu:

Bild hier  

Achso, und wieso statt dem E1 ein C3 ankommt, hab ich fast schon aufgegeben zu verstehen...

Vorweg: Ich kenn den Fleury-Code nicht.

Mach mal ein Oszigramm OHNE Slave, um zu sehen wie das ungestörte Sendesignal aussieht. Da kommen dann zwar keine ACK's , aber es sollte ein klares nachvollziehbares Bild ergeben. Und du kannst dir das Sende-Timing genau angucken, ob das koscher ist oder nicht.

Clock-Stretching ist immer Sache des jeweiligen Slaves, das kann aber kommen oder nicht, muss egal sein.

Ist es nicht auch so, dass das Clock-Stretching ne reine Hardwaresache ist und sich die Software des Masters nicht drum kümmern muss? Dauert halt die Übertragung einfach bissl länger

Wenn einen Slave Clockstretching macht indem er CLK runterzieht, muss der Master den Pegel der CLK-leitung messen und bis CLK wieder High ist bevor er SDA ändert, oder?

@jaecko: wenn die HW-TWI am werken ist, hast du recht. Bei Soft-TWI ist das, logo, anders
@nflator: richtig.

Ein wirklich sauberer Master muss, wenn er die CLK-Leitung freigibt, immer checken, ob sie tatsächlich oben ist und darf erst dann weitermachen.
Manche tun das nur, wenn es um das ACK-Bit geht (wo normalerweise am ehesten gestretcht wird). Und das ist pfui.
Jedes einzelne CLK-Bit kann beliebig gestretcht werden.

Also ich hab den Chip jetzt mal mit an den Hardware-Bus gehaengt und es funktioniert einwandfrei. Ich werd beizeiten bei der Softwareloesung nochmal ohne Slave messen, ich bin mir aber recht sicher, dass das Ganze einfach vom Code her nicht hinhaut. Bei anderen Slaves hatte ich jedoch nie Probleme mit dem Fleury-Code.

Tja, ist das lästige, dass bei der kommunikation immer wenigstens zwei dabei sind :-)

Hallo,

tu doch einfach mal einen Serienwiderstand in die SCL Leitung.
Dann kannst Du am Oszi sehen, ob Master oder Slave an SCL ziehen, d.h. ob der Slave strecht.

Bernhard