Goblin
04.02.2011, 18:22
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:
http://img515.imageshack.us/img515/5586/tek00000.th.png (http://img515.imageshack.us/img515/5586/tek00000.png)
Der dazugehoerige Code ist:
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...
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:
http://img515.imageshack.us/img515/5586/tek00000.th.png (http://img515.imageshack.us/img515/5586/tek00000.png)
Der dazugehoerige Code ist:
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...