Ich hab mir jetzt mal ein paar Breakout Bricklets besorgt und gelötet.

Einen TF Temperatur Sensor (weil der laut photron per i2c ausgelesen wird)angeschlossen. Das Breakout mit 3.3V, Ground, SDA und SCL am RPi mir den entsprechenden Stellen am i2c Port verbunden. So weit so gut.

Erste Sache die mich überraschte...

i2cdetect -y 1

wirft 2 Adressen aus

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

 

Ein

for i in  48 50 ; do i2cget -y 1 0x$i;done

gibt mir ein

0x18
0xff

aus

Nach ein paar mal ausführen diese Befehls hat sich hauptsächlich der 0x48 wert verändert (mit 23 Grad könnte er an dem verwendeten Ort sogar recht haben) der 0x50 blieb zwar die meiste Zeit auf 0xff wenn man aber in einer höheren Frequenz abfragt (etwa mit watch -n 0,2 ) sieht man auch da Bewegungen.... Sehr wilde Bewegungen die sich für mich nicht so wirklich nachvollziehen lassen.

Wie berechnet man die Nachkomma stelle aus dem 0x50 Wert? Direkte Berechnungen wie bei 0x48 wird es nicht sein... wenn ich Hitze zugebe bleibt schwankt der Wert von 0x50 langsamer und mit nicht so unterschiedlichen Zahlen auf 0xff. Und es braucht Ewigkeiten bis sich das wieder ändert wohingegen der Gradwert sehr schnell wieder fällt.

Die Daten sind 12 Bit im Zweierkomplement.

 

Aber anstatt Reverse Engineering zu betreiben kannst du auch einfach bei uns in den Source Code gucken, ist doch alles Open Source:

https://github.com/Tinkerforge/temperature-bricklet/blob/master/software/src/temperature.c

Siehe temperature_read und two_complement_12_to_16.

 

Oder vielleicht noch einfacher, die Datenblätter der Sensoren die wir nutzen sind immer mit im GIT:

https://github.com/Tinkerforge/temperature-bricklet/blob/master/datasheets/tmp102.pdf?raw=true

 

Sorry aber ich kapiere es immer noch nicht.

Wie krieg ich jetzt aus den 16 bit die ich von i2c bekomme die 12 bit die i2c vom Sensor bekommt wieder raus?

 

 

Zusammenkopiert aus dem Quellcode (ungetestet):

 

#define TEMP_SCALE_MUL 100
#define TEMP_SCALE_DIV 16

int16_t two_complement_12_to_16(const int16_t value) {
if(value & (1 << 11)) {
	return value | 0xF000;
}

return value;
}

uint16_t value = (first8bit <<  | second8bit;
uint16_t result = two_complement_12_to_16(value >> 4)*TEMP_SCALE_MUL/TEMP_SCALE_DIV;

 

In "result" sollten am Ende 100stel Grad stehen.

Und wer bringt mir jetzt C bei?

"<<" ist eine bitweise Verschiebung. "|" und "&" sind bitweise Oder und Und. Alle drei erklärt hier: http://de.wikipedia.org/wiki/Bitweiser_Operator

Ansonsten ist nur noch eine Multiplikation und eine Division im Quellcode.

 

Sprachunabhängig ist die Temperatur-Repräsentation im Datenblatt beschrieben, Seite 6 und 7.

Also anhand meiner ersten Beispielausgabe:

Adresse
0x48     0x50
Werte
0x18     0xff
00011000 11111111

Wären das dauerhaft 24.9375 ˚C

Jetzt bliebe noch die Frage zu klären, warum er nach einem Reset 20 Sekunden die .9375 anzeigt und alle 8 Minuten (bei 5 Abfragen pro Sekunde über i2cget) ein Reset benötigt.

Für die Werte 0x18 und 0xff komme ich auch auf 24,9°C, ja:

>>> ((((0x18 <<  | 0xff)) >> 4)/16.0
24.9375

 

Wobei da vermutlich irgendwas noch nicht stimmt wenn der letzte Wert immer 0xFF ist. Steigt die Temperatur denn wenn du mit dem Finger auf den Sensor packst?

 

Ein Reset sollte auch nicht notwendig sein, ist bei der Temperature Bricklet Firmware nicht implementiert.

Wie beschrieben (Video kann ich erst später von machen), i2c-0x48 arbeitet weiter, i2c-0x50 bleibt nach ~8 Minuten hängen. Von der Datenmenge her müsste i2c das packen... hängt ja alleine dran.

Mit reset meinte ich eigentlich strom-weg - strom-ran. Weil mich das genervt hat von Hand zu stecken, hab ich vor 20 Minuten einen Transistor zum schalten dazwischen gehängt... der läuft auf GPIO27.

Die Abfrage-rate scheint eine Rolle zu spielen bei 0,5 Sekunden hats wesentlich länger gedauert bevor er auf 0xff hängen geblieben ist.

Vielleicht ist watch auch nicht die beste Wahl um so was zu testen.

 

Ich kenne i2cget nicht und mir ist nicht ganz klar was du mit 0x48 und 0x50 machst. Auf jeden Fall ändert sich die Adresse des I2C Teilnehmers nicht, solange du nicht änderst was an SEL angeschlossen ist.

 

Was hast du denn beim Breakout Bricklet an SEL angeschlossen, GND, 3.3V, SDA oder SCL? Im Datenblatt sind die Adressen in Table 12 beschrieben:

1001000 Ground

1001001 V+

1001010 SDA

1001011 SCL

 

Wenn du SEL auf GND legst, möchtest du von I2C Adresse 1001000 und Register Adresse 0 zwei 8 Bit Werte auslesen. Von außen drauf geguckt sieht es so aus als würdest du je 1 Byte von I2C-Adresse 0x48 und 0x50  lesen. Das wäre nicht sinnvoll.

i2cget ist Part von den i2c-tools damit kann man auf einer shell i2c-adressen abfragen.

i2cdetect gibt die "angeschlossenen" i2c-Adressen auf dem Display aus.

Mit

i2cget -y 1 0x48

erhält ich bei mir die ersten 8bit des Temperatur Sensors (ohne Rückfrage ob man sich wirklich sicher ist).

Mit

i2cget -y 1 0x50

erhält ich bei mir die zweiten 8bit des Temperatur Sensors

An SEL hatte ich noch nichts angeschlossen. Weil ich es nicht wusste (Bin ja ein noob in dem ganzen Geschäft) und erst gerne etwas auf der Konsole zum laufen kriege bevor ich mich an einer Umsetzung in einer Programmiersprache mache die ich noch nicht mal annähernd kann.

Also ist es genau so gewesen wie es von aussen aus sieht. :-)

Ah, dann würde ich mal versuchen SEL auf gnd zu legen und

i2cget -y 1 0x48 0
i2cget -y 1 0x48 1

aufzurufen um die beiden Byte auszulesen.