DHT12 über I2C mit Raspberry auslesen

[Florian T. (florian_t462)]

Hallo,
nachdem ich bisher immer als Gast hier eine Lösung für 
Elektronikprobleme gefunden habe, habe ich nun ein Problem, für das ich 
keine Lösung finde.

Ich wollte mit einem RaspberryPi3 (bzw. später produktiv mit einem Wemos 
D1 mini) einen AOSONG DHT12 auslesen, den ich von Aliexpress erworben 
habe. Bisher bekam ich bei I2C-Sensoren immer sinnvolle Messungen 
geliefert, wenn ich diese mit den I2C-Tools auslese. Doch leider liefert 
der Sensor immer nur 0xFF als Rückgabe bei der Auslesung mittels

i2cget 1 0x5c 0x00

Hat jemand Erfahrung mit dem Auslesen des Sensors? Muss man ihn evtl. 
irgendwie aus dem Standby wecken? Angeschlossen ist er direkt am 
I2C-Port des Raspberry ohne zusätzliche Pull-Up-Widerstände.

Von der Seite mit den Löchern aus gesehen, ist er wie folgt 
angeschlossen:

DHT   - Raspberry
Pin 1 - 3,3V
Pin 2 - SDA / GPIO 2
Pin 3 - GND
Pin 4 - SCL / GPIO 3

Vielen Dank im Voraus,
Florian

[Condi (Gast)]

Keine Ahnung ob es was damit zu tun hat, aber im Datenblatt steht:

r.I2C Address for 0xB8(DEV SEL); I2C

[Mick (Gast)]

Probier das hier mal aus: https://github.com/mcauser/micropython-dht12
Evtl. hilft dir der Quellcode sonst auch ein bisschen weiter.

[K2k (Gast)]

Ist das Dein einziger Sensor? Evtl. probier mal einen anderen, ich habe 
schon kaputte Teile gehabt.

BTW: die Pullups hast Du richtig gewählt? Häufig werden die zu gross 
dimensioniert.

[Mick (Gast)]

Beim Raspberry Pi sind keine Pull Ups nötig. Diese sind bereits 
"eingebaut".

[Florian T. (florian_t462)]

Hallo,
Vielen Dank schonmal für die Antworten. Die Adresse 0xB8 entspricht der 
von mir verwendeten meines Wissens, sind nur andere Schreibweise (um ein 
Bit verschoben). Das MicroPython-Script hatte ich auf dem Wemos schon 
ausprobiert, am Wemos wird der Sensor gar nicht gefunden (ohne und mit 
5,6KOhm Pull-Up), auf dem Raspberry wird er als 0x5C gefunden mittels

i2cdetect 1

Weitere DHT12 habe ich leider nicht rumfliegen, Kommunikation mit 
anderen I2C-ICs klappte aber bisher immer ohne Probleme (BMP280, 
MPU9250, TSL2561).

Kann es denn sein, dass er gefunden wird unter der Adresse, aber er 
dennoch kaputt ist? Ein Dump mittel

i2cdump 1 0x5c

 liefert nur 0xFF für alle Unteradressen.

[K2k (Gast)]

Mick schrieb:
> Beim Raspberry Pi sind keine Pull Ups nötig. Diese sind bereits
> "eingebaut".

... und sind viel zu gross. Bei 400kHz und 3.3V brauchst Du weniger als 
1k

[K2k (Gast)]

Florian T. schrieb:
> am Wemos wird der Sensor gar nicht gefunden (ohne und mit
> 5,6KOhm Pull-Up),

5.6k ist viel zu gross. Bei 400kHz und 3.3V brauchst Du weniger als
1k

[Natron (Gast)]

K2k schrieb:
> 5.6k ist viel zu gross. Bei 400kHz und 3.3V brauchst Du weniger als
> 1k

Diese Aussage ist völliger Blödsinn!

[K2k (Gast)]

Natron schrieb:
> Diese Aussage ist völliger Blödsinn!

http://www.ti.com/lit/an/slva689/slva689.pdf

[Florian T. (florian_t462)]

Egal ob Blödsinn oder nicht, ich hab es einfach mal getestet und am 
Raspberry nochmal je einen Pullup von 1k zusätzlich zwischen SDA/SCL und 
3,3V gesteckt. Somit ist er dann ja insgesamt, zusammen mit den 
integrierten, unter 1k - auch wenn das Datenblatt vom DHT12 (z.B. hier: 
http://www.robototehnika.ru/file/DHT12.pdf) 1k-10k als PullUp fordert. 
Leider hat sich nichts im Verhalten geändert - er wird gefunden, 
ausgegeben wird aber nur 0xFF, was ja irgendwie schon zu einem Dauer-Up 
am I2C-Port passen würde. Aber irgendeine Regung muss der Sensor ja doch 
machen, sonst würde man ihn ja nicht mittels i2cdetect finden, oder?

[bingo (Gast)]

Die DHT gehen gerne kaputt (meist sehr schnell). Ich habe >20 vom DHT22 
verbaut und nehme lieber diesen als den DHT12, weil der DHT12 die 
Luftfeuchte sehr (!) ungenau misst (20-30% Abweichung sind normal). Das 
Protokoll ist zwar anders (eine Art 1-wire, aber anders als beim 
DS18B20), aber es gibt sowohl für den Raspberry als auch Arduino fertige 
Libraries.

[bingo (Gast)]

K2k schrieb:
> Natron schrieb:
>> Diese Aussage ist völliger Blödsinn!

Das ist kein Blödsinn. Die Pullups für I2C werden meist zu gross 
gemacht. Das funktioniert oft, liegt aber ausserhalb der 
I2C-Spezifikation.

SDA und SDC brauchen eigentlich eine STROM-Quelle (keine 
SPANNUNGS-Quelle), der Strom muss zwischen 3 und 12 mA liegen, siehe 
I2C-Spezifikation.

Nehmen wir erst mal einen statischen Betrieb an:

Die Versorgung läuft auf 3.3 V, der Transistor im IC, der den Bus auf LO 
ziehen muss, hat einen Spannungsabfall von ca 0.3 V, über dem Pullup 
müssen also 3 V abfallen, für 3 mA brauchst Du also 1 kOhm, für 12 mA 
250 Ohm.

Nun hat der Bus aber eine Taktfrequenz, 100 kHz, 400 kHz oder sogar 
mehr:

Da spielen die Kapazitäten vom Pin der ICs, der Lötstellen und der 
Leiterbahn eine Rolle. Die Rechteckimpulse werden verschliffen und 
fallen bzw. steigen zu langsam, weil die Kapazität Energie speichert und 
die Spannung langsam ansteigt bzw. abfällt. Also muss der Pullup kleiner 
gemacht werden, damit die Flankenzeiten der Spezifikation eingehalten 
werden. Und die Leiterbahnen müssen so kurz wie möglich sein. Am 
Breadboard können das für den Pullup bei 3.3 V locker unter 1 kOhm sein.

[Marc V. (Firma: Vescomp) (logarithmus)]

bingo schrieb:
> weil der DHT12 die
> Luftfeuchte sehr (!) ungenau misst (20-30% Abweichung sind normal).

 Das ist meistens bei schnellen Temperaturänderungen der Fall. Nach
 einiger Zeit wird die Luftfeuchte wieder (einigermassen) genau
 angezeigt.

[Florian T. (florian_t462)]

Vielen Dank für die Hinweise! Da ich es mit dem kleineren Pull-Up ja 
schon unerfolgreich ausprobiert habe, werde ich es nochmal mit einem 
neuen Sensor versuchen - vllt. dann auch gleich mit dem DHT22. Ich werde 
dann nochmal berichten, wenn Aliexpress geliefert hat - also wohl so in 
2-4 Wochen :)

[Hans (Gast)]

Hallo Florian,

das gleiche Problem hatte ich gerade auch.
Mein Takt war zu schnell.
Als ich vor dem auslesen den Proz.Takt mal auf 1Mhz gesetzt habe, zeigte 
er auch Werte an. (Ich schreibe in Assembler)

Komischer Weise zeigt er mir aber immer die selben Werte an.
Erst wenn ich die VCC kurz unterbreche ändern sich die Werte ggf.
Muss das so sein? Weiß dazu jemand was?

[Patrick J. (ho-bit-hun-ter)]

Hi

Mir wäre neu, daß ein DHT22 mittels I2C oder per 1-wire-Lib (z.B. vom 
DS18B20)  ausgelesen werden kann.

Das Protokoll nennt sich auch 1-wire, ist aber anders aufgebaut.

Habe den DHT22 per Assembler, allerdings in einem ATtiny45, 'zu Fuß' 
ausgelesen.
Näheres verrät bestimmt das Datenblatt (müsste jetzt auch nachschauen), 
wie sich 0- und 1-Bit unterscheiden, ist aber kein Hexenwerk.

MfG

[Reiner W. (reiner_w)]

Patrick J. schrieb:
> Das Protokoll nennt sich auch 1-wire, ist aber anders aufgebaut.

Genau.
Allerdings kann der DHT12 auch mit dem propritären 1-wire wie der DHT22 
ausgelesen werden. Laut Datenblatt sollte das identisch sein. SDA 
fungiert dabei als Daten-Leitung und SCL geht auf GND (Datenblatt S.11)
Habs grad probiert. Es wird zwar kein Fehler erzeugt (Parity ok) aber 
die Daten sind falsch (Temp ca verdoppelt und Hum +100) Also, so 
komplett identisch scheint nicht zu sein.
Muss mir das mal mit dem Analyzer anschauen.

[Reiner W. (reiner_w)]

Also, wie zuvor schon geschrieben, beherrscht der DHT12 auch das 
propritäre 1-Wire Protokoll.

Allerdings mit 2 Besonderheiten:

1. Das Startsignal Tbe muss ca. 18ms betragen! Damit liegt es zwar noch 
im Toleranzbereich des DHT22, der war aber schon mit 1ms zufrieden, 
weshalb die Lib ggf. an dieser Stelle angepasst werden muss.

2. Gravierender ist allerdings, dass sich das Datenformat der 40 
Datenbits geändert hat.
Beim DHT22 wird Hum*10 und Temp*10 jeweils als int16 in der Form
HumHightByte,HumLowByte,TempHightByte,TempLowByte,ParityByte
gesendet.
Der DHT12 sendet statt eines int16 jeweils den Vor- und Nachkomma-Wert 
jeweils als Byte.
Also 
HumIntegerByte,HumDecimalByte,TempIntegerByte,TempDecimalByte,ParityByte

Die Vorzeichen-Position für die Temperatur ist identisch.

Damit läßt sich die jeweilige Lib eigentlich recht simpel anpassen.

[Hans (Gast)]

Hallo Reiner,

du scheinst dich mit den Dingern recht gut auszukennen.
Ich habe einen DHT12 über I2C an einem Atmel hängen.
Die ausgelesenen Werte werden sind ok.
Bei folgenden Auslesungen werden allerdings immer die selben Werte 
angezeigt, selbt wenn ich die Umgebungstemperatur durch anpusten oder so 
verändere.
Erst wenn ich die Spannungsversorgung kurz unterbreche, bekomme ich 
andere Werte angezeigt. Weitere Auslesungen bringen dann wieder die 
gleichen,neuen Werte.
Hast du eine Idee woran das liegen könnte?
Muss man dem Teil so eine Art reload Befehl senden?
Im Datenblatt habe ich dazu nichts finden können.
Da ich in Assembler schreibe und die Sketche nicht lesen/verstehen kann, 
kann ich auch nicht in der Library nachvollziehen wie es da gemacht 
wird.


Gruß Hans

[Reiner W. (reiner_w)]

Hallo Hans,

da kann ich nicht helfen. Ich habe sie mit dem eigenen 1-wire Protokoll 
am Laufen. Da reagieren sie wie gewünscht. Auch schnell und plausibel 
beim Pusten.
Die Werte sind ok, exakte Vergleichsmessungen habe ich aber nicht 
gemacht.
Hab gestern nur auf die Schnelle eine eigne PSoC-Lib für den DHT11/22 um 
den
DHT12 erweitert. Unter Beachtung der oben genannten Probleme arbeiten 
die jetzt seit einigen Stunden absolut einwandfrei. (Hab allerdings nur 
2 Exemplare getestet)
Ob es bei der I2C Ansteuerung irgend welche Probleme gibt kann ich auch 
nicht sagen. Allerdings wird der DHT12 in den verfügbaren Beispielen 
meist im I2C Mode betrieben und da hab ich auf die Schnelle nichts über 
Probleme gelesen.
Ganz allgemein hab ich allerdings festgestellt, dass man die 2sec Pause 
einhalten sollte, sonst driften die Werte weil sich das Teil dann 
langsam erwärmt.
Und alle DHTs reagieren allergisch, auf der Datenleitung. Bei mir stoppt 
z.B. die Übertragung, wenn ich noch die Strippe vom Analyzer dran habe 
und dieser gar nicht eingeschaltet ist. Da reicht dann schon die 10cm 
Strippe.
Ansonsten hab ich noch keinen DHT in die ewigen Jagdgründe...;-)

Reiner

[Reiner W. (reiner_w)]

Falls es noch von Interesse ist.
Ich hab die Teile jetzt auch mal mit i2c ausgelesen (unter PSoC 4).
Eigentlich kein Problem und läuft reibungslos, sofern man sich an das 
Diagramm auf Seite 7 des DS hält.
Also Write 0x00 gefolgt von einem BufferRead von 5 bytes.

Dabei muss nur Folgendes beachtet werden:
- max i2c clock 400kHz (ich habs mit 100kHz betrieben)
- Slave Adr im data sheet im 8bit Format angegeben b8. Viele Libs/i2c 
Komponenten wollen die Slave Adr im 7bit Format. Das wäre dann die 5c.
- Nur ein device pro i2c Bus (fixe slave Adr)

Hans schrieb:
> Muss man dem Teil so eine Art reload Befehl senden?

Nein. Nur die 2sec Pause zwischen den Lesungen sollten eingehalten 
werden.

Florian T. schrieb:
> Muss man ihn evtl.
> irgendwie aus dem Standby wecken?

Nein

Ansonsten tun sie auch am i2c bus was sie sollen und erweisen sich (bis 
jetzt) als robust und unkompliziert.

Reiner

[Hans (Gast)]

Hey Reiner,

danke, dass du dir die Mühe gemacht hast.
Die Bedingungen erfülle ich alle, trotzdem will es nicht so.
Mir gehen die Ideen aus.
Fürs erste leg ich das Ding mal zur Seite.
Vielleicht machts irgendwann Klick.
Ich hatte mich nur so am Rande mal damit beschäftigt, ich brauch das 
Ding nicht wirklich für eine Anwendung.
Sollte ich irgendwann mal dahinter kommen, werde ich die Lösung hier 
posten.

Gruß Hans

[Reiner W. (reiner_w)]

Hans schrieb:
> Sollte ich irgendwann mal dahinter kommen, werde ich die Lösung hier
> posten.

Ja, wie gesagt ich habe in PSoC implementiert und kann dir da nicht 
wirklich weiterhelfen.
Allerdings hab ich grad mal so Q&D mäßig was für den Arduino 
zusammengezimmert, von dem ich zugegebenermaßen nicht wirklich viel 
verstehe;-( Da war ich dann schon fast erschrocken, dass das auf Anhieb 
klappt;-(
Ich denke, damit kannst du wenigstens schnell mal testen, ob dein DHT12 
noch lebt.

Ich hab's mit nem NANO getestet.
Aufbau ist extrem simpel:

DHT12 - NANO
VDD --- 5V
SDA --- A4
GND --- GND
SCL --- A5

Widerstände oder sonstige Bauteile sind nicht nötig bei kurzen Strippen
zwischen DHT12 und Arduino.
Die Werte werden auf der Konsole ausgegeben (siehe Bild)

Hier der Code:

// Demonstrates use of the Wire library reading data from the
// DHT12 over i2c
// Created 29.09.2017 by R.W. based on Tutorial SRFxx Sonic Range Finder Reader https://www.arduino.cc/en/Tutorial/SFRRangerReader

// This example code is in the public domain.


#include <Wire.h>

void setup() {
  Wire.begin();                // join i2c bus (address optional for master)
  Serial.begin(9600);          // start serial communication at 9600bps
}

void loop() {

  unsigned char buf[5] = {0};   // 5 bytes to receive

  delay(2000);                  // 2 sec pause befor next read
  
  // step 1: instruct sensor to read echoes
  Wire.beginTransmission(0x5c); // transmit to device
  // the address specified in the datasheet is 0xB8
  // but i2c adressing uses the high 7 bits so it's 0x5c
  
  Wire.write(byte(0x00));      // sets register pointer to the first register (0x00) Humidity integral digits
  Wire.endTransmission();      // stop transmitting

  // step 2: request reading from sensor
  Wire.requestFrom(0x5c, 5);    // request 5 bytes from slave device #0x5c

  // step 3: receive reading from sensor
  if (5 <= Wire.available())
  { // if 5 bytes were received
    buf[0] = Wire.read();  // hum ineger
    buf[1] = Wire.read();  // hum decimal
    buf[2] = Wire.read();  // temp integer
    buf[3] = Wire.read();  // temp decimal
    buf[4] = Wire.read();  // parity
  }

  unsigned char tmp = (buf[0] + buf[1] + buf[2] + buf[3]) & 0xff;
  if ( tmp != buf[4])  // parity error
  {
    Serial.println("Parity Error");   // print the error
  }
  else
  {
    Serial.print("Humidity in %RL  :");
    Serial.print("\t");          //tab
    Serial.print(buf[0], DEC);   //interger of hum
    Serial.print(".");           
    Serial.print(buf[1], DEC);   //decimal of hum
    Serial.println("");          //NL

    char vz = '+';       
    if (buf[3] & 0x80)          //temp sign is first bit  
    {
       vz = '-';
       buf[3] = buf[3] & 0x7F;  //clear first bit
    }
    
    Serial.print("Temperature in ºC:");   
    Serial.print("\t");         //tab
    Serial.print(vz);           //sign
    Serial.print(buf[2], DEC);  //integer of temp without sign
    Serial.print(".");          
    Serial.print(buf[3], DEC);  //decimal of temp
    Serial.println("");   //NL
    Serial.println("");   //NL   
  }
}

Ach ja, das ist nichts produktives, schon wegen dem Delay. Aber zum fix 
mal testen sollte es reichen.

Reiner

[Hans (Gast)]

Mensch Reiner du machst dir aber Mühe.
Danke.
Als könntest du Hellsehen, ist mein AVR ein Arduino Nano.
Mit deinem Q&D Sketch macht der Sensor was er soll.
Was zu erwarten war.
Der Sketch benutzt andere Signalleitungen als meine Variante.
Sollte daran liegen...?
Eher nicht oder...hat der Bootloader da im Hintergrund irgendwo die 
Finger auf meinen Leitungen???
Das wäre nichts neues, denn zuerst verwendete ich D12(SDA)+D13(SCL) und 
da ging garnichts.
Erst als ich D13 auf D11 umgeschrieben hatte ging was.

Schon blöd das der Bootloader im Betrieb nicht transparent zu sein 
scheint.
Ich habe bisher aber auch noch keine Doku gefunden wie der Bootloader 
funktioniert, bzw. warum er eben nicht transparent ist.
Da sucht man stundenlang einen Fehler, und ist es garnicht schuld.

Ich werde meine Variante mal auf A4/5 umschreiben und berichten.

[Hans (Gast)]

Dann passieren zwar Veränderungen, aber als Werte kommt nur Blödsinn 
raus.
Da scheint irgendwo ein grundsätzlicher Fehler drin zu sein.
Oh Mann, so simple Dinge die einen so lange aufhalten.

[Peter W. (pe_wi)]

Hallo Hans

Ich hatte das gleiche Problem wie Du. Das zyklische Auslesen einzelne 
Werte klappte bei mir auch nicht. Nach langen Tests glaube ich nun, es 
liegt am Sensor. Der will vermutlich nur komplett ausgelesen werden.... 
Dann klappt es immer!

mfG

Peter

[Reiner W. (reiner_w)]

Peter W. schrieb:
> Der will vermutlich nur komplett ausgelesen werden....
> Dann klappt es immer!

Ja, steht auch irgendwo versteckt im Datasheet.
Noch ein Hinweis zur Genauigkeit. Hab so ein Teil inzwischen mal seit 
ca. 48h im Dauertest mit obigem Sketch, wobei ich nur aller 4 sec 
auslese um ihn nicht unnötig zu erwärmen.
Jetzt nach 48h Laufzeit, ist temp immernoch ziemlich korrekt (geschätzt 
+/-2% weil ich nicht genau weis, wie genau meine Referenz ist)
Der Feuchtesensor zeigt inzwischen aber eine Abweichung von ca. -15% ;-(
Na ja, nun ist die Steckbrettmessung mit einem einzigem Exemplar nicht 
aussagekräftig, läßt aber befürchten, dass die Aussage von Bingo 
zutreffen könnte.

bingo schrieb:
> weil der DHT12 die
> Luftfeuchte sehr (!) ungenau misst (20-30% Abweichung sind normal)

Reiner

[Carsten (Gast)]

Moin,

ich hol das hier nochmal aus den Untiefen.
Habe mir ein paar DHT12 geholt, weil ich es schön fand mit der I2C 
Schnittstelle arbeiten zu können.

Den "alten" DHT11/22 habe ich mit einem AVR unter Bascom fehlerfrei 
auslesen können.

I2C ist mit Bascom aufm AVR ja total einfach, bisher hat jeder Baustein 
da gemacht was er soll, mit Hard und Software I2C btw TWI.
Habe aber nach mehreren Stunden recherche im Netz und Zeilenspielerei 
dem Ding jedoch nix entlocken können.

Laut Datenblatt, Netrecherche und euren Erläuterungen ist die Adresse ja 
Dezimal 92 wegen der 8 vs. 7 bit Geschichte - das deckt sich so auch mit 
anderen Foren im www.

Im Datenblatt seite 8. ist allerdings das Beispielprotokoll so 
dargestellt, das er er einmal mit write auf 92 (0xB8) und dann einmal 0 
aufgerufen wird, bzw. der Pointer damit auf Anfang gesetzt wird und dann 
nochmal write auf 93 (0xB9) und dann 5 bytes lesen.

Das kommt mir in dieser Form auch ganz klassich vor, ähnlich ist es ja 
bei anderen I2c Bausteinen mit jeweils einer Lese und Schreibadresse.

z.b. hier für den DS1307 siehts in Bascom so aus :

I2cstart
I2cwbyte 208
I2cwbyte 0

I2cstart
I2cwbyte 209
I2crbyte Sekunden , Ack
I2crbyte Minuten , Ack
I2crbyte Stunden , Ack
I2crbyte Wochentag , Ack
I2crbyte Tag , Ack
I2crbyte Monat , Ack
I2crbyte Jahr , Nack
I2cstop

wenn ich das nun auf den DHT12 übernehme :

I2cstart
I2cwbyte 92
I2cwbyte 0

I2cstart
I2cwbyte 93
I2crbyte Feuchte_wert , Ack
I2crbyte Feuchte_scale , Ack
I2crbyte Temperatur_wert , Ack
I2crbyte Temperatur_scale , Ack
I2crbyte Checksumme , Ack
I2cstop

kommt nix, nur 255 für alle werte, sehe auch auf dem Oszilloskop auf 
beiden Datenleitungen keine Reaktion.

Habe wie gesagt diverse Variationen dieses Programms ausprobiert, null 
Reaktion. Mache ich denn so einen Denkfehler diesmal ?
Habe 4 Stück, ist bei allen so.
Oder habe ich doch die Adresse falsch übersetzt ?

[Wolfgang (Gast)]

Carsten schrieb:
> Oder habe ich doch die Adresse falsch übersetzt ?

Guck nach. Spiele einen I2C-Scanner auf deinen µC und guck, wo sich der 
DHT12 angesprochen fühlt (Ack-Bit). Adressen 0xB8/0xB9 ist das selbe wie 
I2C-Adresse 0x5C. Ich übersetze das jetzt nicht auch noch auf dez.

[Carsten (Gast)]

Wolfgang schrieb:
> Adressen 0xB8/0xB9 ist das selbe wie
> I2C-Adresse 0x5C.

Zwei unterschiedliche Adressen sind eine, Oder wie soll ich das 
verstehen?

[Carsten (Gast)]

Habs,

Was auch immer es war, geht:

I2cstart
I2cwbyte 184
I2cwbyte 0
I2cstop

I2cstart
I2cwbyte 185
I2crbyte Feuchte_wert , Ack
I2crbyte Feuchte_scale , Ack
I2crbyte Temperatur_wert , Ack
I2crbyte Temperatur_scale , Ack
I2crbyte Checksumme , Nack
I2cstop

Danke, habs dann auch mal mitm kleinen I2C Scanner probiert.....hätte 
ich auch drauf kommen können :D

[Wolfgang (Gast)]

Carsten schrieb:
> Zwei unterschiedliche Adressen sind eine, Oder wie soll ich das
> verstehen?

Zwei unterschiedliche Lesarten für die gleiche Adressierung, einmal das 
komplette Adressbyte einschließlich R/W-Bit, d.h. unterschiedlich für 
Lesen und Schreiben und einmal die 7-Bit I2C Adresse, wie sie im 
Standard beschrieben ist, d.h. ohne R/W-Bit.

[Carsten (Gast)]

Wolfgang schrieb:
> Carsten schrieb:
>> Zwei unterschiedliche Adressen sind eine, Oder wie soll ich das
>> verstehen?
>
> Zwei unterschiedliche Lesarten für die gleiche Adressierung, einmal das
> komplette Adressbyte einschließlich R/W-Bit, d.h. unterschiedlich für
> Lesen und Schreiben und einmal die 7-Bit I2C Adresse, wie sie im
> Standard beschrieben ist, d.h. ohne R/W-Bit.

Aaaachso, alles klar, jo. danke.