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

[teamohnename]

Hallo an alle,
wir haben eine Frage zu der I²C Master Library des RP6’. In der Library von Peter Fleury gibt es z.B. i2c_stop oder i2c_rep_start. Diese Funktionen werden anscheinend von einigen Slaves benötigt. Wie kann man sowas mit der RP6 I2C Master Library machen? Hier ein Code Beispiel, (damit wir einfach verstehen, wie das mit der RP6 Library funktioniert):

[...]
i2c_start_wait(ADR+I2C_WRITE);
i2c_write(0x07);
    
i2c_rep_start(ADR+I2C_READ);
b1 = i2c_readAck();
b2 = i2c_readAck();
b3 = i2c_readNak();
i2c_stop();
[...]

Bei dem Beispiel will der Slave das i2c_rep_start und das i2c_stop wie gesagt unbedingt haben.
Wäre das Beispiel dann in der RP6 Library das?

I2CTWI_transmitByte(ADR,0x07);

I2CTWI_readRegisters(ADR+1, 0x07, sensorBuf, 3);
//Daten in sensorBuf[0] - sensorBuf[2]

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

[Dirk]

@teamohnename:
Im Prinzip ist das Beispiel der RP6 Library so richtig, wobei sogar noch die ADR bei transmit und readRegisters gleich bleiben kann (also nicht ADR+1) und der Parameter 0x07 im readRegisters weg muss.
Die Lib sendet Ack und Nack automatisch. Schau dir die ISRs in beiden Libs an!

[teamohnename]

Hi Dirk,
danke für Deine Antwort.
Was soll da denn anstatt 0x07 (ist das Startregister, was ausgelesen werden soll) stehen? Wenn man das weglässt, meckert der Compiler doch?! Oder haben wir Dich falsch verstanden?
Grüße
teamohnename

[Dirk]

Hi,

dass ab Register 7 gelesen werden soll, hast du ja dem Slave vermutlich ja schon mit I2CTWI_transmitByte(ADR,0x07) mitgeteilt.
Der I2CTWI_readBytes-Befehl (NICHT ..._readRegisters,- das ist ein Bytearray der Lib!) kennt nur 3 Parameter.

Was ist das denn für ein Slave?

[teamohnename]

Hi Dirk,
das ist ein MLX90614 Infrarot Thermometer. Hier der Originalcode.

Folgendes ist jetzt zwar OT, aber egal.
Wir haben den Sensor schon angeschlossen und ein paar Dinge beobachtet:
1) Mit dem Code:

I2CTWI_transmitByte(0x5A,0x07);
I2CTWI_readBytes(0x5A, sensorBuf, 3);
mlx90614_l = sensorBuf[0];

Bekommen wir im Terminal ,,I2C ERROR - TWI STATE: 0x20". Wenn wir aber schreiben:

I2CTWI_transmitByte(0x5A<<1,0x07);
I2CTWI_readBytes(0x5A<<1, sensorBuf, 3);
mlx90614_l = sensorBuf[0];

Kommt der Fehler nicht mehr, sensorBuf ist aber immer 255 (egal ob sensorBuf[0], [1] oder [2]).
Wenn man aber jetzt die I²C Verbindung unterbricht, bleibt der Wert 255 und es gibt keinen Error im Terminal.

Dass mit dem letzten Codebeispiel kein Error mehr erscheint, ist doch ein gutes Zeichen, oder? Hängt das mit dem kein-Error-ohne-Verbindung irgendwie mit dem Programm bzw. der I²C ISR zusammen, sodass das auch normal ist?

Wie sollen wir jetzt weiter vorgehen? Der Sensor scheint sich ja angesprochen zu fühlen. Das Problem ist also nur, dass wir momentan mit dem letzten Codeausschnitt noch keine Daten auslesen können... Vielleicht kann man da auch noch weiteres aus dem Originalcode übersetzen, wir wissen nur nicht wie...

Vielen Dank deshalb weiterhin für Eure Hilfe und
Viele Grüße
teamohnename

EDIT:
Hier nochmal der Code, der wirklich übersetzt werden muss, wobei das Fett geschriebene die I²C Sache ist:

int dev = 0x5A<<1;
int data_low = 0;
int data_high = 0;
int pec = 0;
  
i2c_start_wait(dev+I2C_WRITE);
i2c_write(0x07);
  
// read
i2c_rep_start(dev+I2C_READ);
data_low = i2c_readAck(); //Read 1 byte and then send ack
data_high = i2c_readAck(); //Read 1 byte and then send ack
pec = i2c_readNak();
i2c_stop();
  
//This converts high and low bytes together and processes temperature, MSB is a error bit and is ignored for temps
double tempFactor = 0.02; // 0.02 degrees per LSB (measurement resolution of the MLX90614)
double tempData = 0x0000; // zero out the data
int frac; // data past the decimal point
  
// This masks off the error bit of the high byte, then moves it left 8 bits and adds the low byte.
tempData = (double)(((data_high & 0x007F) << 8) + data_low);
tempData = (tempData * tempFactor)-0.01;
  
float celcius = tempData - 273.15;
float fahrenheit = (celcius*1.8) + 32;

[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