-         

Ergebnis 1 bis 9 von 9

Thema: Clock Stretching?

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253

    Clock Stretching?

    Anzeige

    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:




    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...

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253
    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:



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

  3. #3
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    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
    #ifndef MfG
    #define MfG

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.10.2009
    Beiträge
    120
    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?

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    @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.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253
    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.

  8. #8
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Tja, ist das lästige, dass bei der kommunikation immer wenigstens zwei dabei sind
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  9. #9
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    03.04.2005
    Beiträge
    181
    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

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •