Frage zu RP6 I2C Library: Funktionen der Lib von Peter Fleury?

[Dirk]

@teamohnename:
Der MLX90614 braucht ja wohl sehr genau die Befehlsfolge, die du auch schon angegeben hast. Ob die RP6-I2C-Lib die SMBus-kompatibel genau so sendet, kann ich nicht sicher sagen.

Was man probieren könnte:

1. Den I2C-Takt auf 50 kHz heruntersetzen
2. Als Adresse für den MLX90614 0x00 probieren
3. SlyD (den Autor der RP6-Libs) fragen, ob man die Befehlsfolge so mit der RP6-Lib hinbekommt

[SlyD]

Teste es mal mit I2CTWI_readRegisters - wegen dem repeated start.

[teamohnename]

Hallo Dirk und SlyD,
I2C Takt haben wir jetzt erstmal auf 50kHz heruntergesetzt.
Wir haben jetzt alle Variablen (sensorBuf und die Variable, in die sensorBuf übergeben wird) als int32_t deklariert. Jetzt ist der Wert nicht mehr 255, sondern -1. Auch, wenn wir als Adresse 0x00 probieren.
Mit I2CTWI_readRegisters haben wir es auch schon probiert, ohne Erfolg.
Wie gesagt, wenn wir den Sensor selbst (wir benutzen übrigens die 3.3V Version, da nur die in Deutschland zu haben war, mit einem 3,3V Spannungswandler und einem Pegelwandler, bei dem aber alles zu funktionieren scheint (3,3V Pegel (auch I2C) auf dem Oszilloskop kontrolliert)) aus dem Steckboard entfernen, wird nicht mehr in sensorBuf geschrieben, wir bekommen I2C Error 0x20 im Terminal. Sobald wir den Sensor wieder reinstecken, verschwindet der Fehler aber und wir bekommen als Wert wieder -1.
Deutet die -1 eventuell auf einen Overflow hin? Das wird übrigens mit writeIntegerLCD ausgegeben. Das darf ja bis zu int16_t Variablen benutzt werden...

Danke und
Viele Grüße
teamohnename

EDIT:
Gerade im Datenblatt gelesen:

8.4.6 Commands
RAM and EEPROM can be read both with 32x16 sizes. If the RAM is read, the data are divided by two, due
to a sign bit in RAM (for example, TOBJ1 - RAM address 0x07h will sweep between 0x27ADh to 0x7FFF as the
object temperature rises from -70.01°C to +382.19°C).

Der Wert in Register 0x07 schwankt also, so wie ich das verstanden habe, zwischen Dezimal 10157 und 32767, von daher müsste das ja locker in eine int16_t Variable passen...


EDIT2:
Schade. Dann werden wir wohl oder übel die Library von Peter Fleury ausprobieren müssen.

[teamohnename]

*push*
Hallo,
Das Portieren der Lib von Peter Fleury ist uns nun doch etwas zu schwer...

Wir fragen noch ein letztes Mal, danach werden wir wohl oder übel aufgeben müssen:
Woran kann das liegen?
Nochmal: Es gibt anscheinend keine Hardware Fehler (wenn man den Sensor aus dem Steckbrett entfernt, gibt es I2C Error 0x20). Der Sensor scheint also nach der ersten Anfrage (nachdem also 0x07 gesendet wurde) zu antworten. Danach scheint es aber Probleme zu geben. Wir können die Ergebnisse anscheinend nicht richtig aus dem Sensor auslesen (egal, welches Register ausgelesen werden soll, das Ergebnis ist immer -1, dabei ist aber ein seltsames ,,flackern" (als wenn da ganz schnell eine Zeile von unten nach oben an und aus geht) bei der -1 zu beobachten, das ist nicht so, wenn normal etwas aufs Display ausgegeben wird).

Falls es keine Lösung gibt , trotzdem danke für Eure Hilfe bis jetzt und
Viele Grüße
teamohnename

EDIT:
Hier ein paar Bilder vom Oszilloskop. Einmal ein ganzer Block, dann der Anfang, dann das Ende. ABer wahrscheinlich könnt ihr damit auch nicht so viel anfangen. Geld ist SCL, Blau ist SDA.



EDIT2:
gerade hier gelesen:

laut datenblatt kann der sensor kein read oder write byte, sondern nur
word.

Was bedeutet das?
In dem Topic scheint der Ersteller ein ähnliches oder das gleiche Problem zu haben, wie ich, es wird vom Ersteller aber keine Antwort gepostet...
Was meint ihr?

EDIT3:
gerade im Datenblatt gelesen:

8.4.2 Differences with the standard SMBus specification (reference [1])
There are eleven command protocols for standard SMBus interface. The MLX90614 supports only two of
them. Not supported commands are:
• Quick Command
• Byte commands - Sent Byte, Receive Byte, Write Byte and Read Byte
• Process Call
• Block commands – Block Write and Write-Block Read Process Call
Supported commands are:
• Read Word
• Write Word

Das bestätigt das obere Zitat.
Was bedeutet das denn jetzt im Klartext? Was ist ein ,,word"? Eine 16bit Variable? Vielleicht sogar eine 32bit Variable?

Kommen wir dem Ziel damit näher?

Viele Grüße
teamohnename

[teamohnename]

Hallo an alle,
sorry für den Dreifachpost, ich rechtfertige das jetzt damit, dass ich neue, eventuell ausschlaggebende Ergebnisse habe und ein paar Feststellungen gemacht habe:
1) Auf den vorherigen Bildern vom Oszilloskop war noch die Kommunikation mit einem anderen Slave drauf, was ich vergessen hatte, im Code auszukommentieren. Jetzt sieht das ganz anders aus!
2) Das Ergebnis auf dem Scope ist nicht gleich, wenn die Adresse 0x00 (Bild 1) oder 0x5A<<1 (Bild 2) ist, das Ergebnis ist aber bei folgendem Code gleich:

I2CTWI_readRegisters(0x5A<<1,0x07, sensorBuf, 3);

//I2CTWI_transmitByte(0x5A<<1,0x07);
I2CTWI_readBytes(0x5A<<1, sensorBuf, 3);

(Bild 1)
3) Nach wie vor fehlt die Hälfte der Signale, wenn der Sensor herausgezogen wird (Bild 3). Der scheint also wirklich zu antworten, wird dann aber anscheinend nicht richtig ausgelesen... Wie man auf Bild 1-3 sieht, sind bei SDA (blau) zum Schluss drei ,,Ausschläge" (I²C Acks des Sensors?), dazwischen ist alles 0. Ich glaube, dass dort das MSB, das LSB und das PEC sein sollten. Die sind aber alle 0. Bei Adresse 0x00 stimmt das auch anscheinend alles exakt mit dem Diagramm im Datenblatt überein, bis auf die drei Daten, die eben alle 0 sind.
Und nochmal, was meint ihr, woran könnte das liegen? Die Ursache ist ja anscheinend geklärt, jetzt müssen wir nur noch herauskriegen, wie wir das Problem beseitigen können?!

Hier die Bilder:


Vielen, vielen Dank für Eure Hilfe und
Viele Grüße
teamohnename

[markusj]

Die zeitliche Auflösung der Aufnahmen erlaubt leider keine Beurteilung dessen, was dort tatsächlich an Daten ausgetauscht wurde. Eigentlich bräuchte man zu Vergleichszwecken einmal die Kommunikation (im Detail) mit der RP6-Lib und mit der Fleury-Bibliothek.

Außerdem stocherst du noch immer im Nebel rum. Es wäre keine große Kunst, sich genau anzusehen was der Code von Fleury im vergleich zur RP6-Lib anders macht.

mfG
Markus

[teamohnename]

Hallo,
ja, das gebe ich zu, die zeitliche Auflösung ist mies, war aber eben nur einfacher abzufotografieren. Leider kann ich das Oszilloskop nur momentan noch nicht an den PC anschließen, ich muss also abfotografieren...
Ich habe das ganze jetzt mit einem ATmega8 und der Library von Fleury getestet, dort funktioniert das nahezu perfekt - nahezu. Bei der Adresse 0x00 funktioniert (mit dem Mega8!) alles perfekt, komplett wie im Datenblatt, die Werte ändern sich, wenn man z.B. mit der Hand über dem Sensor ist. Bei 0x5A sieht das aber schon anders aus - anscheinend wird richtig initialisiert, aber das, was da zurückkommt, ist die Adresse, also 0x5A (im Bild vorsichtshalber erstmal als ,,???" gekennzeichnet)...
In Sachen RP6 kann ich da allerdings nichts draus deuten - ich bekomme immer noch 0 zurück, obwohl das sehr ähnlich aussieht, bis auf die Sendepause nach dem Repeated Start...
Naja, hier jetzt vernünftige Fotos. Ich hoffe, dass da jetzt alles passt, ich habe auch etwas kommentiert, wo ich vermute, was was bedeutet.
Die Adresse ist bei einem Foto 0x5A und bei einem anderen Foto 0x55, das liegt daran, dass ich es immerhin zusätzlich mit einem Mega8 geschafft habe, die Adresse des Sensors zu ändern (natürlich mit einem anderen Code, Adresse muss aber so oder so früher oder später geändert werden).
Bitte schaut Euch die Fotos nochmal an, auch wenn wir damit weiterhin im Nebel stochern - wer weiß...

Bild 1 = ATmega8, Adresse 0x00
Bild 2 = ATmega8, Adresse 0x5A
Bild 3 = RP6, Adresse 0x00
Bild 4 = RP6, Adresse 0x55

A = Ack
RS = Repeated Start
W = Write
R = Read

Vielen Dank und
Viele Grüße
teamohnename