-         

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 36

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

  1. #1

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

    Anzeige

    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):

    Code:
    [...]
    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?

    Code:
    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
    Geändert von teamohnename (18.02.2012 um 20:43 Uhr)

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.791
    @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!
    Gruß
    Dirk

  3. #3
    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
    Geändert von teamohnename (27.02.2012 um 16:36 Uhr)

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.791
    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?
    Gruß
    Dirk

  5. #5
    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:
    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:

    Code:
    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:
    Code:
    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;
    Geändert von teamohnename (21.02.2012 um 18:51 Uhr)

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.791
    @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
    Gruß
    Dirk

  7. #7
    Erfahrener Benutzer Roboter Genie Avatar von SlyD
    Registriert seit
    27.11.2003
    Ort
    Paderborn
    Alter
    32
    Beiträge
    1.514
    Teste es mal mit I2CTWI_readRegisters - wegen dem repeated start.

  8. #8
    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.
    Geändert von teamohnename (22.02.2012 um 14:40 Uhr)

  9. #9
    *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.
    Klicke auf die Grafik für eine größere Ansicht

Name:	IMG_1726.jpg
Hits:	6
Größe:	81,0 KB
ID:	21590Klicke auf die Grafik für eine größere Ansicht

Name:	IMG_1727.jpg
Hits:	6
Größe:	101,8 KB
ID:	21591Klicke auf die Grafik für eine größere Ansicht

Name:	IMG_1728.jpg
Hits:	5
Größe:	96,8 KB
ID:	21592


    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
    Geändert von teamohnename (22.02.2012 um 20:20 Uhr)

  10. #10
    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:
    Code:
    I2CTWI_readRegisters(0x5A<<1,0x07, sensorBuf, 3);
    Code:
    //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:
    Klicke auf die Grafik für eine größere Ansicht

Name:	Bild_1.jpg
Hits:	4
Größe:	92,1 KB
ID:	21601Klicke auf die Grafik für eine größere Ansicht

Name:	Bild_2.jpg
Hits:	5
Größe:	89,8 KB
ID:	21602Klicke auf die Grafik für eine größere Ansicht

Name:	Bild_3.jpg
Hits:	3
Größe:	72,6 KB
ID:	21603

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

Seite 1 von 4 123 ... LetzteLetzte

Ähnliche Themen

  1. LCD library von Peter Fleury ÄÖÜ fehlt
    Von Woftschik im Forum C - Programmierung (GCC u.a.)
    Antworten: 21
    Letzter Beitrag: 18.04.2009, 15:31
  2. LCD an Mega8 mit Lib von Peter Fleury
    Von Mr Bean im Forum C - Programmierung (GCC u.a.)
    Antworten: 6
    Letzter Beitrag: 04.10.2007, 09:01
  3. 4x20 LCD und Peter Fleury
    Von hansbausn im Forum C - Programmierung (GCC u.a.)
    Antworten: 11
    Letzter Beitrag: 27.01.2006, 18:06
  4. Anfängerproblem mit i2c und Peter Fleury
    Von hansbausn im Forum C - Programmierung (GCC u.a.)
    Antworten: 5
    Letzter Beitrag: 20.11.2005, 18:26
  5. Peter Fleury LCD Lib Problem mit LCD
    Von Cybrix im Forum C - Programmierung (GCC u.a.)
    Antworten: 13
    Letzter Beitrag: 30.09.2005, 11:05

Berechtigungen

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