kein Zugriff auf I2C-EEPROM

[Alexander S. (knut740)]

Hallo,
ich habe ein AT24C512B (=I2C-EEPROM), das ich gern benutzen möchte, aber 
leider nicht ansprechen kann.

Seine Adresse ist lt. Datenblatt 0b1010xxx, wobei bei mir A0 an 5V und 
A1 und A2 mit Gnd verbunden sind. Also müßte die Adresse 0x51 sein 
(möglich wären 0x50 bis 0x57, die ich allesamt durchprobiert habe).
Ich könnte eidesstattlich versichern, daß alles richtig verdrahtes ist 
und wenigstens plus und minus konnte ich an den richtigen Stellen 
nachmessen - aber trotzdem kriege ich keine Verbindung.

Da ich den Chip gegen meine sonstige Gewohnheit direkt eingelötet habe, 
könnte man annehmen, daß das Ding beim Löten verbrannt sei, deshalb habe 
ich einen zweiten auf Sockel eingebaut, ging aber auch nicht. Den 
zweiten habe ich durch einen dritten ersetzt - auch ohne Erfolg. Nun bin 
ich ratlos.

Kann mir jemand weiterhelfen?
Vielen Dank schon mal!
Alexander

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Bei I2C-Adressen gibt es leider ein inkonsequente Zählweise. Teilweise 
wird das Write/Read-Bit als unterstes Adressbit angesehen, so dass sich 
der Adressteil um ein Bit nach links verschiebt. Also hätte Dein EEPROM 
dann die Adresse 0xA2/0xA3.

Die Inkonsistenzen findet man sowohl in Datenblätter als auch in der 
Software bzw. entsprechenden Bibliotheken. Die Krönung dessen fand ich 
vor langer Zeit in U-Boot. Dort wurde je nach I2C-Schnittstelle mal die 
eine und mal die andere Zählweise verwendet.

[VIA (Gast)]

Alexander S. schrieb:
> Kann mir jemand weiterhelfen?

Ohne Schaltplan, Layout/Bild vom Aufbau und Programmcode, zumindest in 
Teilen eher nicht.

Dir ist das alles bekannt, sonst keinem hier.
Wo sollte man da ansetzen?!


Alexander S. schrieb:
> Also müßte die Adresse 0x51 sein

Klingt erstmal richtig, R/W-Bit (LSB) beachtet?


Ansonsten bleibt nur raten:

Pullup-Widerstände an SDA und SCL vorhanden?

[Christian S. (roehrenvorheizer)]

Hallo,

kannst Du bei irgendeiner ADRESSE ein ACK erkennen, wenn Du nacheinander 
alle 255 Adressen durchzählen läßt?

Mfg

[Christian M. (Gast)]

Christian S. schrieb:
> alle 255 Adressen

Es sind ja sogar nur 128...

Andreas S. schrieb:
> leider ein inkonsequente Zählweise

Ja grausam, aber auch auf der Softwareseite muss man aufpassen, je nach 
Library.

Am besten bin ich immer gefahren, wenn ich nach Diagramm programmiert 
habe. Und LA dran! Das beste Werkzeug schlechthin!

Gruss Chregu

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

Alexander S. schrieb:
> Seine Adresse ist lt. Datenblatt 0b1010xxx, wobei bei mir A0 an 5V und
> A1 und A2 mit Gnd verbunden sind. Also müßte die Adresse 0x51 sein
> (möglich wären 0x50 bis 0x57, die ich allesamt durchprobiert habe).

 Oder auch 0xA2 (schreiben) und 0xA3 (lesen).

 Um nicht wieder endlos darüber zu diskutieren...
 ATMEL sagt folgendes:

EEPROM requires an 8-bit device address word following a start condition to
enable the chip for a read or write operation

 Und noch:

The eighth bit of the device address is the read/write operation select bit.
A read operation is initiated if this bit is high and a write operation is initiated if this bit is low.

[Einer K. (Gast)]

Marc V. schrieb:
> Um nicht wieder endlos darüber zu diskutieren...

Man man..
Da kommt er wieder aus dem OFF und erklärt einem, dass EEPROMs die 
einzigen Speicher sind, die nicht nur 7 Adressbit mit positiver 
Zählweise haben, also A6 bis A0, sondern sogar noch ein A-1 Adressbit.
Allgemein bekannt, als R/W Bit.


Liebster Marc, ich kann deinen Unwillen über diese Adressverwirrung 
verstehen!
Ja, mich nervts auch!
Aber DU wirst es nicht mehr ändern.
1. Du bis ein paar Jahre zu spät dran
2. Hier ist der falsche Ort. Hier sind nur Opfer der Verwirrung.

Tipp:
Such dir eine Zeitmaschine, und misch die Entwicklungsabteilung bei 
Philips auf.

Kannst natürlich auch weiter einen auf Don Quijote machen...
Bringt nur keinem was. Ganz im Gegenteil.

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

Arduino F. schrieb:
> Tipp:
> Such dir eine Zeitmaschine, und misch die Entwicklungsabteilung bei
> Philips auf.

 Tipp:
 Lass den TO beide Adressen probieren, ohne deine Kommentare...

> Kannst natürlich auch weiter einen auf Don Quijote machen...
> Bringt nur keinem was. Ganz im Gegenteil.

 Kannst natürlich auch weiter nutzlose Kommentare schicken...
 Bringt nur keinem was. Ganz im Gegenteil.

[Alexander S. (knut740)]

Hallo,
ich habe in den Arduino-Beispielprogrammen eines gefunden, das die 
I2C-Adressen durchzählt und dann wohl reagiert, wenn ein Ack kommt. Aber 
etwas ist da nicht richtig, denn es reagiert auch da, wo nichts ist, Ich 
habe es modifiziert auf 0-255 wegen des LSB. Unten den gefundenen 
Adressen ist A0, das könnte meinem EEPROM entsprechen (0b1010.....).
Das Programm heißt I2C_scanner, ich füge es bei. Mein Testprogramm füge 
ich anschließend an.

 // i2c_scanner
 //
 //
 // This sketch tests the standard 7-bit addresses
 // from 0 to 127. Devices with higher bit address
 // might not be seen properly.
 //
 // Adapted to be as simple as possible by Arduino.cc user Krodal
 //
 // June 2012
 // Using Arduino 1.0.1
 //

#include <Wire.h>

void setup()
 {
   Wire.begin();

  Serial.begin(9600);
   Serial.println("\nI2C-Scanner");
 }

void loop()
 {
   byte error, address;
   int nDevices;

  Serial.println("Scanning...");

  nDevices = 0;
   for(address = 0; address <= 254; address++ )
  {
     // The i2c_scanner uses the return value of
     // the Write.endTransmisstion to see if
     // a device did acknowledge to the address.
     Wire.beginTransmission(address);
     error = Wire.endTransmission();

    if (error == 0)
     {
       Serial.print("I2C-Device gefunden mit der Adresse 0x");
       if (address<16)
        Serial.print("0");
       Serial.print(address,HEX);
       Serial.println(" !");

      nDevices++;
     }
     else if (error==4)
    {
       Serial.print("Unknow error at address 0x");
       if (address<16)
        Serial.print("0");
       Serial.println(address,HEX);
     }
   }
   if (nDevices == 0)
     Serial.println("No I2C devices found\n");
   else
     Serial.println("fertig\n");

  delay(8000);           // wait 8 seconds for next scan
 }

//  _2_Werte_schreib_ausl_I2C_EEPROM                                   5.2.17

// aus dem I2C-EEPROM zwei Zahlenwerte, die aus je zwei
// Bytes bestehen, auslesen.
// Seriell ausdrucken: EEPROMadresse, die einzelnen Bytes und die 
// daraus zusammengesetzten Zahlenwerte. 



#include<Wire.h>
//#include<EEPROM.h>            // nur für internes EEPROM benötigt
const int I2CADRESSE = 0xA0;
int eepromadresse;
int Value_a, Value_b;
byte value1, value2, value3, value4;

void setup() {
int Wert;
   Wire.begin();
   Serial.begin(9600);
int eepromadresse = 0;


  Wert = 1234;

 for (eepromadresse = 0; eepromadresse < 2000; eepromadresse++){
  schreibEEPROM(eepromadresse, highByte(Wert));
  eepromadresse++;
  schreibEEPROM(eepromadresse, lowByte(Wert));
   }
 

 for (eepromadresse = 0;  eepromadresse < 2000; eepromadresse++){
  value1 = (liesEEPROM(eepromadresse));
  eepromadresse++;
  value2 = (liesEEPROM(eepromadresse));
  eepromadresse++;
  value3 = (liesEEPROM(eepromadresse));
  eepromadresse++;  
  value4 = (liesEEPROM(eepromadresse));
  

  Serial.print(eepromadresse);
  Serial.print("\t");
  Serial.print(value1);
  Serial.print("\t");
  Serial.print(value2);
  Value_a = value1 << 8 | value2;
  Serial.print("\t");
  Serial.print(Value_a, DEC);
  Value_b = value3 << 8 | value4;
  Serial.print("\t");
  Serial.println(Value_b, DEC);
  
  }
}  
 

void loop()
 {};

//  Unterprogramme

  byte liesEEPROM( unsigned int eepromaddress)   // byte datenbyte=0xFF)
{
  byte  datenbyte = 0x00;
  Wire.beginTransmission(I2CADRESSE);
  Wire.write ((byte) (eepromaddress >> 8));
  Wire.write ( (byte) (eepromaddress & 0xFF));
  Wire.endTransmission();
  Wire.requestFrom(I2CADRESSE, 1);         //  1 ... heißt ein Byte ???
  if (Wire.available())                    
    datenbyte = Wire.read();  // ich weiß, hier müßte man eine Fehleroutine  // einfügen, kommt später
  return datenbyte;           //
}

void   schreibEEPROM(int adresse, byte daten) 
  {  
  Wire.beginTransmission(I2CADRESSE);
  Wire.write ((byte) (adresse >> 8));
  Wire.write ( (byte) (adresse & 0xFF));
  Wire.write (daten);
  Wire.endTransmission();  
  delay(5);
  }

VG

[STK500-Besitzer (Gast)]

Alexander S. schrieb:
>Aber etwas ist da nicht richtig, denn es reagiert auch da, wo nichts ist,
Wie wäre es, wenn du uns das Ergebnis des Scans mitteilen würdest?

> Ich habe es modifiziert auf 0-255 wegen des LSB
Son Quatsch!
Das LSB gibt die Datenrichtung an.

[Alexander S. (knut740)]

STK500-Besitzer schrieb:
>>Aber etwas ist da nicht richtig, denn es reagiert auch da, wo nichts ist,
> Wie wäre es, wenn du uns das Ergebnis des Scans mitteilen würdest?

Scanning...
I2C-Device gefunden mit der Adresse 0x00 !
I2C-Device gefunden mit der Adresse 0x20 !
I2C-Device gefunden mit der Adresse 0x7C !
I2C-Device gefunden mit der Adresse 0x80 !
I2C-Device gefunden mit der Adresse 0xA0 !
I2C-Device gefunden mit der Adresse 0xFC !
fertig

>
>> Ich habe es modifiziert auf 0-255 wegen des LSB
> Son Quatsch!
> Das LSB gibt die Datenrichtung an.

Dann scanne mal mit der Originaleinstellung des i2c-scanners (0-127)

[Alexander S. (knut740)]

VIA schrieb:
> Pullup-Widerstände an SDA und SCL vorhanden?

Nein.
Habe ich da irgend wo etwas überlesen? Ich habe noch nie etwas von sda-, 
scl-Pullups gelesen.
Wenn Du sicher bist, würde ich die nachrüsten.
An den gleichen sda-scl-Ports hängt noch ein I2C-LCD dran, das sich 
nicht über mangelnde Pullups beschwert. Alledings könnten sie unsichtbar 
intern vorhanden sein. Aber dann müßten sie mein EEPROM mit"versorgen".

VG

[Einer K. (Gast)]

Alexander S. schrieb:
> Aber dann müßten sie mein EEPROM mit"versorgen".
Das tun sie!
Wenn sie denn da sind.

[VIA (Gast)]

Alexander S. schrieb:
> Habe ich da irgend wo etwas überlesen?

Scheint so.

I2C-Devices besitzen "nur" Open-Collector Ausgänge.
Zusammen mit den Pullup-Widerständen, ergibt sich dadurch ein Wired-AND,
sodass jeder Teilnehmer den Bus auf LOW ziehen kann.

Anders herum ist der Bus nur HIGH, wenn alle Teilnehmer den Bus 
"freigeben".


Lesen kann man das zum Beispiel hier:
https://de.wikipedia.org/wiki/I%C2%B2C#Elektrische_Definition

und auch eigentlich in jedem Datenblatt, in dem ein I2C beschrieben 
wird...

[S. Landolt (Gast)]

> Anders herum ist der Bus nur HIGH ...
Und abhängig von der Größe dieser Widerstände dauert es eben mehr oder 
weniger lang bis zum Erreichen dieses HIGH.

[Alexander S. (knut740)]

Arduino F. schrieb:
> Wenn sie denn da sind.

Stimmt! Ich habe aber bei sda/scl noch nie pullups gesehen

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Alexander S. schrieb:
> Habe ich da irgend wo etwas überlesen? Ich habe noch nie etwas von sda-,
> scl-Pullups gelesen.

Auf die Verwendung und Dimensionierung wird doch in der 
I2C-Spezifikation explizit hingewiesen. Oder hast Du die etwa nicht 
gelesen?

[S. Landolt (Gast)]

> Stimmt! Ich habe aber bei sda/scl noch nie pullups gesehen
So kann es gehen mit "eidesstattlichen" Erklärungen - aber solange es 
kein Ehrenwort ist...

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

S. Landolt schrieb:
>> Stimmt! Ich habe aber bei sda/scl noch nie pullups gesehen
> So kann es gehen mit "eidesstattlichen" Erklärungen - aber solange es
> kein Ehrenwort ist...

Vor allem sollte man bei solch einer gewichtigen Erklärung davon 
ausgehen können, dass bei der Kontrolle sämtliche Sorgfaltspflichten 
erfüllt wurden. Und bei der Behauptung, es handele sich um eine 
I2C-Schnittstelle, gehört eben eine formale Prüfung dazu. Und diese kann 
man natürlich nur anhand der offiziellen Spezifikation im Originaltext 
oder einem gleichwertigen Dokument durchführen.

Letztendlich bleibt also nur die Feststellung, dass der Threadersteller 
schon bei der Implementierung hemmungslos gepfuscht hat und nun 
versucht, das ganze auch noch schönzureden. Im Bereich der Elektronik 
geht so etwas aber nach hinten los. Stattdessen sollte er lieber eine 
Parteikarriere anstreben. Dort wäre er mit einem derart oberflächlichen 
Gelaber hochgradig angesehen. Und wenn die Behauptungen nicht der 
Realität entsprechen, kann man sie trotzdem noch schönreden, 
vorzugsweise unter Verwendung möglichst verbindlich wirkender Worte, die 
sich dann aber doch als hohle Phrasen erweisen.

Und spätestens seit Barschel ist das Gewicht eines sog. Ehrenwortes doch 
auch bekannt geworden.

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

Hi

Der mit dem Ehrenwort war der Kohl - und hat's Ihm geschadet?

Wurde schon geklärt, WOMIT über I2C mit dem EEProm und dem LCD-Display 
geschwätzt wird?
Beim Arduino sind entweder die chipinternen PullUps aktiv oder es wurden 
auf dem Shield zwei Widerstände versteckt, Die genau dafür da sind.

Da das Display wohl funktioniert (nehme ich jetzt so an), sollte es dem 
Bus gut gehen.

Die Überprüfung aller 256 IDs scheint aber nicht geglückt zu sein:

Alexander S. schrieb:
> Scanning...
> I2C-Device gefunden mit der Adresse 0x00 !
> I2C-Device gefunden mit der Adresse 0x20 !
> I2C-Device gefunden mit der Adresse 0x7C !
> I2C-Device gefunden mit der Adresse 0x80 !
> I2C-Device gefunden mit der Adresse 0xA0 !
> I2C-Device gefunden mit der Adresse 0xFC !
> fertig

Ich sehe da nur Geradzahlige IDs

Zu den 127 prüfbaren IDs:
An diese ID wird jeweils ein 0-Bit angehangen und dieses Byte in den 
I2C-Bus gesendet.
Fühlt sich jetzt wer angesprochen, gibt's das ACK - damit findet man 
alle Busteilnehmer, Die eine Adresse haben (ein Single-Master braucht 
normal Keine).

Zeig Mal ein Bild von Deinem Aufbau, die ganzen I2C-Slaves müssen ja 
irgendwo sein, wenn schon eine Erkennung statt findet.

MfG

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Patrick J. schrieb:
> Der mit dem Ehrenwort war der Kohl - und hat's Ihm geschadet?

Kohl hat meines Erachtens niemals die Begriffe "Eidesstattliche 
Versicherung" und "Ehrenwort" in einem Kontext zusammen verwendet. 
Außerdem hat er auch nicht gelogen, sondern einfach weitere Auskünfte 
verweigert. Außerdem war das wesentlich später als bei Barschel.

Ganz im Gegensatz dazu hat Barschel gnadenlos gelogen:
https://www.youtube.com/watch?v=PCn-C6AkLm0

[Christian M. (Gast)]

Alexander S. schrieb:
> Ich habe noch nie etwas von sda-,
> scl-Pullups gelesen.

Kam schon im dritten Beitrag:

VIA schrieb:
> Pullup-Widerstände an SDA und SCL vorhanden?

Ich bin raus!

Gruss Chregu

[Alex W. (a20q90)]

Patrick J. schrieb:
> Der mit dem Ehrenwort war der Kohl - und hat's Ihm geschadet?

Das war Uwe Barschel! Später war er tot!

In den 90er gab es die Zeitschrift PC-Player. Da waren mal CDs mit 
Audiofiles im OGG-Format dabei und einen DOS-Player.

Da war eine Audiodatei mit Musik und dem Text "Ich bin. Ich bin wieder 
da. Barschel Bar Bar Barschel".

Eventuell kann sich jemand daran erinnern.

[Alexander S. (knut740)]

Wieder etwas gelernt (wegen dieser Möglichkeit schätze ich ja dieses 
Forum)!

Im Datenblatt des AT24C512B habe ich auf S. 6 nur einen verschämtem 
Hinweis gefunden, den man weitherzig als Pullups deuten kann:

3.   Device Operation
CLOCK and DATA TRANSITIONS:
The SDA pin is normally pulled high with an external device.
Data on the SDA pin may change only during SCL low time periods (see
Figure 3-4 on page 8
).
Data changes during SCL high periods will indicate a start or stop condition as defined below.

Zugegeben, das Datenblatt hatte mir gereicht und erst der Beitrag von 
VIA hat mich wieder an die open collector Ausgänge erinnert.

Nachdem ich nun Pullups eingelötet habe, funktioniert es.

Vielen Dank für Eure Hilfe!

VG
Alexander

PS da hat sich jemand über eidesstattliche Erklärungen und genaue 
Formulierungen erregt: Ob es vielleicht möglich ist, einen Text  g e n a 
u  zu lesen? Oder ist die Bedeutung das Konjunktivs unbekannt?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Alexander S. schrieb:
> Im Datenblatt des AT24C512B

wird an keiner Stelle die Abkürzung I2C o.ä. verwendet!

> Zugegeben, das Datenblatt hatte mir gereicht

Du hast also ein Datenblatt, in dem an KEINER Stelle I2C erwähnt wird, 
als normative Referenz für den I2C-Bus verwendet? Das ist schon äußerst 
gewagt.

[VIA (Gast)]

Alexander S. schrieb:
> Im Datenblatt des AT24C512B habe ich auf S. 6 nur einen verschämtem
> Hinweis gefunden, den man weitherzig als Pullups deuten kann:


Das Datenblatt soll dir aber auch nicht die Grundlagen des I2C 
vermitteln, sondern dir die Eigenschaften und Funktionen des Bauteils 
erklären ;-)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Und letztendlich war/ist der I2C-Bus auch mit Patenten und Markenrechten 
von Philips belastet. Das bedeutet aber auch, dass andere Hersteller 
zwingend entsprechende Patentumgehungen einbauen müssen, so dass an 
irgendwelchen Stellen die strikte Kompatibilität zu I2C sogar verletzt 
werden muss.

Ein Zweidrahtbus, der nicht mindestens eine relevante Komponente von 
Philips/NXP oder einem offiziellen Lizenznehmer beinhaltet, kann somit 
gar kein I2C-Bus sein. Und da Atmel die Verwendung von I2C strikt 
vermeidet, ist Atmel offenbar auch kein Lizenznehmer von Philips/NXP. 
Natürlich versuchen solche Hersteller, so weit kompatibel zu I2C zu 
bleiben, dass in den meisten Fällen der reibungslose Betrieb 
sichergestellt ist, aber die Abweichungen müssen so groß sein, dass ein 
Richter und ggf. Gutachter ganze klar erkennen können, dass die 
entsprechenden Patente eben nicht verletzt werden.

[Alexander S. (knut740)]

Eine Frage am Rande hätte ich noch - aus reiner Neugier, das eigentliche 
Problem ist ja gelöst:

Das oben gepostete Programm "i2c-scanner" sieht für meine bescheidenen 
Kenntnisse sehr schön aus, aber es liefert eigenartige Ergebnisse:

I2C-Scanner
Scanning...
I2C-Device gefunden mit der Adresse 0x00 !
I2C-Device gefunden mit der Adresse 0x20 !
I2C-Device gefunden mit der Adresse 0x51 !
I2C-Device gefunden mit der Adresse 0x7C !
I2C-Device gefunden mit der Adresse 0x80 !
I2C-Device gefunden mit der Adresse 0xA0 !
I2C-Device gefunden mit der Adresse 0xD1 !
I2C-Device gefunden mit der Adresse 0xFC !
fertig


Wie ich das sehe, liefert der Ausdruck
Wire.endTransmission()
eine 0, wenn ein Ack empfangen wird.
Dies sollte nur bei 0x20 und 0x51 der Fall sein. Woher kommt dann das 
übrige Ack-Geschrei?

[Einer K. (Gast)]

Alexander S. schrieb:
> Woher kommt dann das
> übrige Ack-Geschrei?
Weiterhin den Ardiono Scanner?
Dann: Verwende das Original.
Das mit der 127.

Damit halbiert sich die Menge.

Die 0x00 kann von einem Baustein stammen, welcher auf den General Call 
hört.

[m.n. (Gast)]

Alexander S. schrieb:
> Dies sollte nur bei 0x20 und 0x51 der Fall sein. Woher kommt dann das
> übrige Ack-Geschrei?

Arduino Programme sind eben von Hause aus kreativ ;-)

[Alexander S. (knut740)]

Stimmt,
I2C-Scanner
Scanning...
I2C-Device gefunden mit der Adresse 0x00 !
I2C-Device gefunden mit der Adresse 0x20 !
I2C-Device gefunden mit der Adresse 0x51 !
I2C-Device gefunden mit der Adresse 0x7C !
fertig

aber 0x7C ist  immer noch unberechtigt

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

Alexander S. schrieb:
> aber 0x7C ist  immer noch unberechtigt

 Diese Adresse ist sowieso reserviert.
 Und über 0x78 sollte man nicht abfragen.

[Einer K. (Gast)]

Marc V. schrieb:
> Diese Adresse ist sowieso reserviert.
Wohl wahr...

Aber trotzdem komisch, dass die und auch die 00 belegt sind.
Ist mir so noch nicht untergekommen.

Bisher war I2C frei von Magie

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

Hi

Die 00 ist eine Art Broad-Cast, ein Rundruf - darauf müssen/sollen ALLE 
SLaves ein ACK senden.

Wieso/weshalb über 0x78 ... eine weiterführende Erklärung, daß man nicht 
jedes Datenblatt dutzende Male neu erkunden muß, hätte auch zukünftigen 
Lesern bestimmt weiter geholfen als diese lappidare Aussage, wo noch 
nicht Mal sicher gestellt ist, daß Diese ein Fakt ist (oder auch nicht).

Denke mir zwar gerade, daß Das in RIchtung 10bit oder reservierte 
Adressen geht, aber Denken heißt nun Mal nicht Wissen.

MfG

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

Patrick J. schrieb:
> Denke mir zwar gerade, daß Das in RIchtung 10bit oder reservierte
> Adressen geht, aber Denken heißt nun Mal nicht Wissen.

 Das man nicht über 0x78 abfragen soll, ist nur meine Empfehlung,
 verboten ist es nicht.

 0x78 bis 0x7B ist reserviert für 10-bit Adressen.
 0x7C bis 0x7F ist reserviert für zukünftige Erweiterungen.

[Alexander S. (knut740)]

Marc V. schrieb:
> 0x78 bis 0x7B ist reserviert für 10-bit Adressen.
>  0x7C bis 0x7F ist reserviert für zukünftige Erweiterungen.

ok, aber wieso senden die ein ack?
Ob vielleicht irgend etwas von den beiden DS18B20 als Ack mißverstanden 
wird?

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

Hi

Was suchen 1-wire-Sensoren auf dem I2C-Bus?

Dann kann es natürlich sein, daß Alles bunt durcheinander schwätzt und 
Keiner wirklich was versteht.

MfG

[Joachim B. (jar)]

Marc V. schrieb:
>  Das man nicht über 0x78 abfragen soll, ist nur meine Empfehlung,
>  verboten ist es nicht.
>  0x78 bis 0x7B ist reserviert für 10-bit Adressen.
>  0x7C bis 0x7F ist reserviert für zukünftige Erweiterungen.

hmmm die Idee kam mir auch schon nur ist dann der Arduino Scanner mit

for (address = 1; address < 127; address++ )

eher ungünstig sollte also < 121 heissen, aber bis jetzt hatte ich keine 
Probleme und heute
dachte ich ich erwische mal einen mit erweiterter I2C Adress einen

PT2258


der wird beworben mit Address 0x88 / 88hex

durch den Scanner gejagt 0x84 nanu? Takt auf 100kHz runtergesetzt, dito.

Tiefer geschürft, aha die typischen Addressleitungen Ax und Ay heissen 
Code und geben merkwürdige Kombinationen aber egal zwischen 8hex 80hex 
84hex und 88hex kann man wählen, warum nur wird der mit 88hex default 
beworben? Dazu muss man Code 1/2 schon speziell beschalten weder beide 
high noch beide low.

Richtig beschaltet also auf "0x88" geshiftet 0x44

Ich mag die verschiedene Bezeichnungwirrwar nicht, eigentlich sind 
(fast) alle ICs die ich bis jetzt hatte deutlich unter 77hex