I2C - Sensordaten können nur einmal korrekt gelesen werden

[Stefan7]

Guten Tag,

Ich habe einen IOW24-Dongle, mit dem ich über I2C einen Sensor auslesen möchte.
Zum Auslesen des Sensors muss ein Byte mit der Adresse (7Bit) und dem gesetzten Read/Write Bit (Bit8, LSB) an den Sensor geschickt werden.

Der Sensor stellt 8Byte Daten zur Verfügung. Nach dem Einstecken des IOW24 am USB Port können jeweils 1 Mal diese 8 Bytes gelesen werden. (egal ob 8 Byte auf einmal oder 8 mal 1 Byte)
Irgendwie scheint er automatisch zur nächsten Speicherstelle zu springen, sobald ich erneut ein Byte auslese. Wenn ich also 8 mal ein Byte lese, dann erhalte ich zuerst das 1., dann das 2., dann ... und am Schluss das 8.Byte.
Werden danach weitere Bytes gelesen, so erhalte ich immer 0x32 anstatt eines sinnvollen Wertes.

Wenn ich das gleiche mit einem USB zu I2C Device von NI mache, dann liest er immer nur das 1. Byte, wenn ich nur ein Byte lese. Hier wird also nicht automatisch zum nächsten Byte gewechselt.

Wenn ich die KO-Bilder vergleiche, fällt mir auf, dass beim NI-Device ein Clock-Puls mehr auf der Clock-Leitung zu sehen ist. Es könnte also etwas mit dem Stopbit zu tun haben...?!

Leider weiss ich aber nicht was hier das Problem sein könnte.
Kann mir jemand helfen?

Vielen Dank und Gruss
Stefan

[Christoph Jung]

Man muss natürlich immer sagen WAS man lesen will. Also man muss den Pointer setzten wo man anfangen will daten auszulesen. Darum warscheinlich der "Fehler", dass er nach dem achten Byte das neunte nimmt. Einfach einmal 0x00 schreiben und er sollte dann wieder am Anfang stehen.

Welche Software wird denn genutzt um mit dem IO-Warrior zu kommunizieren? LabView, ProfiLab oder etwas anderes?

Was das mit dem Clock-Signal auf sich hat kann ich leider nicht sagen.

[Stefan7]

Danke für die schnelle Antwort.

Das klingt eigentlich logisch, dass ich zuerst den Pointer richtig setzen muss.
Ich habe das kurz ausprobiert, 0x00 zu schreiben, doch dann erhalte ich einen Error und er liest nichts mehr.

Falls ich noch irgendwo 0x00 schreiben müsste, dann müsste doch der Adapter von NI das auch tun und dann wiederum müsste ich es auf dem KO-Bild sehen, oder nicht?

Ich benutze LabView um mit dem IO-Warrior zu kommunizieren.
Das Verhalten ist übrigens mit dem Simple-I2C Tool genau gleich wie mit dem LabView Programm.

[Christoph Jung]

Was der Adapter von NI macht kann ich nicht sagen, den kenn ich nicht. Und ich kann leider auch nicht viel zu den Diagrammen sagen, da ich eher der Softwerker bin. Interessant wäre was genau geschrieben wird, bzw. die Reihenfolge.

[Stefan7]

Ich habe im LabView geschaut, welche Werte an die Funktion IowKitWrite übergeben werden. Das sieht wie folgt aus:

0x03
0x01
0x45
0x00
0x00
0x00
0x00
0x00

Die Sensoradresse ist 34 Dezimal, d.h. 0x22. Da die Adresse nur 7 Bit lang ist und das 8.Bit=1 sein muss (Read Modus) würden die 0x45 stimmen.

Nun ist die Frage ob auch die 0x03 und 0x01 stimmen...?

[Christoph Jung]

Naja auf jedenfall ist das die Lesefunktion des I²C. Ein Byte soll gelesen werden auf Adresse 0x45.
Man könnte mal mit dem IOW24 (?) einen schreibvorgang nach den 8Byte lesen machen

0x02
0xC1
0x44
0x00 (der 0x01)

Und dann noch einmal lesen. Dann sollte er von vorne beginnen.

Ich habe inzwischen mit der Demo von ProfiLab versucht das Beispiel zu IO-Warrior auszuführen (liegt bei den Beispielen von ProfiLab) aber da regt sich nichts. Ich glaube die Demo kann nicht mit der Hardware kommunizieren oder ich stelle mich extrem blöd an.

Haben Sie denn schon ein einfache Simple-IO Beispiel mit schlaten der IOs versucht? Also zum testen, ob die DLL sich aufhängt.

[Stefan7]

Wenn ich nach dem Lesevorgang die erwähnten Bytes schreibe und dann nochmals lese, so scheint es wirklich zu funktionieren. Dann liest er nochmals das Richtige, jedoch funktioniert es nur noch ein weiteres Mal.

Ich habe das versucht in einer Schlaufe zu machen, aber das hat leider nicht funktioniert...
Müsste ich da noch andere Bytes schreiben?

Nein, ein simples IO Beispiel habe ich nicht gemacht, denn ich habe nur den I2C-Dongle, da kann ich die IO's nicht wirklich benutzen.
Dass sich die dll aufhängt glaube ich aber nicht, denn mit dem KO kann ich noch Signale messen und das LabView Programm funktioniert auch noch richtig. Wenn sich die dll aughängt, dann stürzt manchmal auch LabView ab.

[Guido Körber]

Welcher Sensor ist das denn der da angesprochen wird?

Im Allgemeinen funktionieren I2C Slaves so, dass sie selber den internen Adresspointer hochzählen wenn man liest, aber es gibt auch immer Ausnahmen die sich irgendwie anders verhalten.

[Stefan7]

Es ist ein hauseigener Sensor, der sich gemäss den I2C Spezifiaktionen von Philips V2.1 http://i2c2p.twibright.com/spec/i2c.pdf verhält.

Ich weiss aber nicht, was mit dem internen Adress-Pointer geschieht.
Anbei ein Ausschnitt aus dem Datenblatt.
Wenn das aber nur von der Einstellung des Sensors abhängt, dann müssten sich ja der IOW24 und das Gerät von NI gleich verhalten...

[Guido Körber]

scheint so, als wenn sich da doch irgend welche minimalen Abweichungen im Verhalten am I2C ergeben. Um herauszufinden was da genau passiert wäre es notwendig den Sensor besser zu kennen. Gibt es Kommandos in Schreibrichtung, also zu Sensor?

[Stefan7]

Nein, ausser dem erwähnten "Read" Befehl gibt es keine Befehle, die an den Sensor geschickt werden können.
Im Datenblatt steht aber, dass der Sensor nach dem Start die erste Messung selber initiiert und die Daten im Ausgangsbuffer zur Verfügung stellt. Danach werden nach jedem Read Befehl Daten gelesen und in den Buffer gelegt. Möglicherweise wird also der Read Befehl nicht richtig erkannt und dadurch intern keine Messung ausgelöst?!

[Guido Körber]

Könnte sein, dass sich der Sensor daran stört wie wir die Transaktion beenden. Das wäre aber sehr ungewöhnlich, tatsächlich der erste Fall bei dem wir so was hätten. Die Implementierung wurde ja absichtlich so gemacht, da es eigentlich keine Probleme damit gibt.

Können Sie da auf detailiertere Informationen zum Sensor zurück greifen?