Hallo ich verwende den IC PCF8575 (I2C 16 Bit) In dem Programm wollte ich die Adresse 0x32 bis 0x39 nutzen. Habe aber zufällig noch die Adresse 0x42 drin gehabt. Dies stammt doch vom PCF 8574. Mit dieser Adresse geht der PCF 8575 auch. Mit seiner richtigen Adresse (0x32) geht er nicht. Versteh leider nicht warum. Hat jemand eine Erklärung für mich? achim
Hi >In dem Programm wollte ich die Adresse 0x32 bis 0x39 nutzen. Lt. meinem Datenblatt hat der PCF8575 die Adressen 0x40/41, 0x42/43, ... . MfG Spess
>Lt. meinem Datenblatt hat der PCF8575 die Adressen 0x40/41, 0x42/43, ...
I2C slave address L H L L A2 A1 A0 R/W
Da frag ich mich auch wie man auf 0x32 bis 0x39 kommt;)
Interessant, wie viele Datenblätter es da gibt :-) Lt. http://www.ti.com/lit/ds/symlink/pcf8575.pdf (Seite 8 oben) gehts von 0x20 bis 0x27
>Da frag ich mich auch wie man auf 0x32 bis 0x39 kommt;)
Mit 32 bis 39 dezimal ohne 0x davor passt es dann;)
Angehängte Dateien:
-
PCH8575_Adr.png
32 KB
Hallo habe auch das selbe Datenblatt wie Dieter. Dort werden die Adressen auf dem Bild angegeben. Verwende die Schreibweise als Dez mit 0x... Sorry, das ist mir unklar. Wo hast du die Adressen her? Gibt es zwei verschiedene Angaben oder hat jeder Hersteller seine eigenen Adressen? achim
Achim Seeger schrieb: > Verwende die Schreibweise als Dez mit 0x... Das ist falsch - 0x... steht für einen Hexadezimal-Wert. Du Schreibst ja auch nicht "das kostet 0x55,60 Euro" - oder? :-) Wie auch im Datenblatt zu sehen entspricht z.B. 32 dezimal 0x20 hexadezimal. Gruß Dieter
Stimmt Dieter, du hast wieder recht. Trotzdem versteh ich es nicht. unsigned char adr1_w = 0x40; // Schreibadresse 40 unsigned char adr1_r = 0x41; // Leseadresse unsigned char adr2_w = 0x42; // Schreibadresse 42 unsigned char adr2_r = 0x43; // Leseadresse Gebe es so an in meinem Prg und damit geht es achim
Schön wenn zu der Verwirrung mit 7- und 8-Bit Adressen noch verschiedene Zahlensysteme kommen ;-)
Achim Seeger schrieb: > unsigned char adr1_w = 0x40; // Schreibadresse 40 > unsigned char adr1_r = 0x41; // Leseadresse Wenn Du genau diese Werte übergibst wird es (bei passender Jumper-Stellung) wohl passen, da jeweils an der eigentlichen Adresse noch ein Schreib-/Lese-Bit "dranhängt". D.h. z.B. die erste Adresse 0x20 wird eins nach links geschoben (dann 0x40) und das Schreib-/Lese-Bit (Seite 7 unten dargestellt) addiert - das ergibt dann 0x40 bzw. 0x41. So gesehen hat Spess auch wieder (irgendwie) Recht, obwohl die korrekte Bezeichnung für das "Konstrukt" nicht "I2C-Adresse" sondern vielleicht "Adressierung mit Schreib-/Lese-Information" lauten sollte (oder so ähnlich :-)). Gruß Dieter
Oliver R. schrieb: > Schön wenn zu der Verwirrung mit 7- und 8-Bit Adressen noch verschiedene > Zahlensysteme kommen ;-) Achim Seeger schrieb: > unsigned char adr1_w = 0x40; // Schreibadresse 40 > unsigned char adr1_r = 0x41; // Leseadresse Richtig :-) daher sollte der Kommentar auch // Schreibadresse 64 oder besser einfach // Schreibadresse lauten
Hallo Dieter welcher Zahlenbereich (Adressbereich) gilt den nun? Wie ist den nun die korrekt Schreibweise? Hallo Oliver finde deinen Kommentar irgendwie erbauen und Mutmachend Könntest du was beitragen zu diesem Durcheinander? Wie ist es mit einer Stelle oder Tut, wo so was einfach erklärt wird. Lese es gern und wende es an. achim
Achim Seeger schrieb: > Hallo Dieter > welcher Zahlenbereich (Adressbereich) gilt den nun? > Wie ist den nun die korrekt Schreibweise? Du musst die gewünschte Hexadezimal-Adresse lt. Datenblatt 1 mal nach links schieben und 1 oder 0 für Lesen oder Schreiben addieren: Adresse 0x20 links geschoben wird 0x40 + Lesen(1)/Schreiben(0) Adresse 0x21 links geschoben wird 0x42 + Lesen(1)/Schreiben(0) ... Adresse 0x27 links geschoben wird 0x4F + Lesen(1)/Schreiben(0) Gruß Dieter
Achim Seeger schrieb: > Hallo Dieter > welcher Zahlenbereich (Adressbereich) gilt den nun? > Wie ist den nun die korrekt Schreibweise? > Beide sind richtig. Die I2C Spec lässt sich darüber nicht aus. Selbst bei Philips dokumentierten schon von Anfang an manche Abteilungen in der 7bit Schreibweise, und andere in der 8bit Schreibweise.
Hi >Du musst die gewünschte Hexadezimal-Adresse lt. Datenblatt 1 mal nach >links schieben und 1 oder 0 für Lesen oder Schreiben addieren: Etwas pauschal. Weder die Hersteller und schon gar nicht die Programmierer haben dafür eine 'Norm'. Für den PCF 8575 gibt NXP als Adresse 0 1 0 0 A2 A1 A0 R/W, TI 32..39D (0x20..0x27) an. Ersteres ergibt als Adresse 0x40...0x4E und muss nicht geschoben werden. Letztere schon. Bei den Librarys gibt es welche die selbst schieben, also die 7-Bit-Adresse erwarten und welche die die 8-Bit-Adresse brauchen. Also gibt es kein >Wie ist es mit einer Stelle oder Tut, wo so was einfach erklärt wird. >Lese es gern und wende es an. Da hilft nur Datenblatt und Quelltext selbst lesen. MfG Spess
Achim Seeger schrieb: > welcher Zahlenbereich (Adressbereich) gilt den nun? > Wie ist den nun die korrekt Schreibweise? Wie schon geschrieben wurde gibt es keine korrekte Schreibweise, Du mußt nur wissen, daß es beide gibt und wie sie sich in einander umwandeln lassen. Für Dein Bauteil kommst Du um den Blick ins Datenblatt eh nicht drumrum und da steht dann welche Schreibweise benutzt wird bzw ist erklärt wie sich die Adresse aufbaut. Nur die Dezimaldarstellung ist eher unüblich.
Oliver R. schrieb: > Wie schon geschrieben wurde gibt es keine korrekte Schreibweise, Du mußt > nur wissen, daß es beide gibt und wie sie sich in einander umwandeln > lassen. Im Standard steht dazu: > Data transfers follow the format shown in Figure 9. After the START > condition (S), a slave address is sent. This address is seven bits > long followed by an eighth bit which is a data direction bit (R/W) > — a ‘zero’ indicates a transmission (WRITE), a ‘one’ indicates a > request for data (READ) (refer to Figure 10). Ein Byte eines Datentransfers (an anderen Stellen auch gerne Oktet genannt) wird oft in mehrere Bitfelder aufgeteilt. MfG Klaus
Angehängte Dateien:
-
nxp-Datenblatt.jpg
20 KB
spess53 schrieb: > Für den PCF 8575 gibt NXP als Adresse 0 1 0 0 A2 A1 A0 R/W, TI 32..39D > (0x20..0x27) an. Ersteres ergibt als Adresse 0x40...0x4E und muss nicht > geschoben werden. Ich habe mal - aus Interesse - nachgeschaut. http://www.nxp.com/documents/data_sheet/PCF8575.pdf NXP sagt aus meiner Sicht genau das gleiche wie TI - die Adresse ist 7-stellig (0x20..0x27) und wird im ersten Byte mit "angehängter" R/W-Information übertragen (siehe anleigende Bild - habe die Adresse grün markiert)
Angehängte Dateien:
-
pcf8574.png
3,6 KB
>NXP sagt aus meiner Sicht genau das gleiche wie TI
NXP sagt auf einer Seite eines Datenblattes beides;)
Siehe Anhang.
dummy schrieb: > NXP sagt auf einer Seite eines Datenblattes beides;) Es geht um den PCF8575 (mit einer 5 am Ende)
>> NXP sagt auf einer Seite eines Datenblattes beides;) > >Es geht um den PCF8575 (mit einer 5 am Ende) Das weiss ich, bin ja nicht blöd. Das sollte nur zeigen das das jeder hält wie ein Dachdecker. Es gibt keine einheitliche Vorgehensweise was diese Adressen angeht.
Was übergeben wird ist ein Byte. In diesem Byte, sind eine 7-Bit-Adressinformation und eine 1-Bit-Schreib-Lese-Information enthalten. Steht auch so in der I²C-Spezifikation: The slave address and R/W bit Data transfers follow the format shown in Figure 9. After the START condition (S), a slave address is sent. This address is seven bits long followed by an eighth bit which is a data direction bit (R/W) — a ‘zero’ indicates a transmission (WRITE), a ‘one’ indicates a request for data (READ) (Und ja, ich weiß auch das es mittlerweile 10-Bit-Adressen gibt) Ich vermute mal, dass es sich bei der rechten Abbildung um einen Fehler handelt, da es auf Seite 13 anders - aus meiner Sicht korrekt - dargestellt wird.
Sorry, wenn ich mich jetzt ganz blöd stelle oder vielleicht sogar bin. Je mehr ich dazu von euch lese um so weniger verstehe ich. Es gibt also 7 Stellen oder 8 Stellen. Steht im Datenblatt drin. Adressen können "umgerechnet" werden. Hab ich das soweit richtig verstanden? Wenn ich das richtig verstanden habe, brauche ich noch ein Tip wie das geht. Habe bisher immer angenommen das z.B. die Adresse unsigned char adr1_w = 0x40; // Schreibadresse 40 unsigned char adr1_r = 0x41; // Leseadresse unsigned char adr2_w = 0x42; // Schreibadresse 42 unsigned char adr2_r = 0x43; // Leseadresse so angegeben richtig sind. Das jeder IC (I2C) einen bestimmten Adressbereich hat und so ca 1024 (?) mögliche Adressen gibt. Ich Dummerchin. hab da wohl was falsch verstanden. Könnte mich jemand von dieser Unwissenheit befreien, wirklich, ich sehe nicht mehr durch. achim
@ Achim Seeger (achims) >Sorry, wenn ich mich jetzt ganz blöd stelle oder vielleicht sogar bin. Wer so wie du schon so lange mit I2C rumspielt und es noch immer nicht begriffen hat . . . >Es gibt also 7 Stellen oder 8 Stellen. Es sind immer 8 Bit, wobei das LSB angibt, ob gelesen oder geschrieben wird. Nun kann man diese 8 Bit als Adresse ansehen (incl. R/W Bit) oder nur die echten 7 Adressbits (ohne R/W Bit). >Habe bisher immer angenommen das z.B. die Adresse >unsigned char adr1_w = 0x40; // Schreibadresse 40 >unsigned char adr1_r = 0x41; // Leseadresse >so angegeben richtig sind. Das jeder IC (I2C) einen bestimmten >Adressbereich hat und so ca 1024 (?) mögliche Adressen gibt. Wie kommst du bei 8 Bit auf 1024? >Könnte mich jemand von dieser Unwissenheit befreien, Ob das möglich ist?
Achim Seeger schrieb: > Habe bisher immer angenommen das z.B. die Adresse > > unsigned char adr1_w = 0x40; // Schreibadresse 40 > unsigned char adr1_r = 0x41; // Leseadresse > > unsigned char adr2_w = 0x42; // Schreibadresse 42 > unsigned char adr2_r = 0x43; // Leseadresse > > so angegeben richtig sind. Das jeder IC (I2C) einen bestimmten > Adressbereich hat und so ca 1024 (?) mögliche Adressen gibt. Jein :-) Wenn Du mit "Adresse" das Byte mit den Adress- UND Schreib-Lese-Informationen meinst ist das für den ersten Teil korrekt (wobei der Kommentar immer noch falsch ist ...) Mit 7 Adress-Bit kann man aber keine 1024 Adressen abbilden - es sind theoretisch 128 möglich, von denen aber 16 reserviert/nicht nutzbar sind (wenn man von der möglichen 10-Bit-Adressierung absieht) - also max. 112 unterschiedliche Slave-Adressen.
Dieter Frohnapfel schrieb: > (Und ja, ich weiß auch das es mittlerweile 10-Bit-Adressen gibt) Nicht "mitlerweile" sondern schon immer. Und da wirds dann komisch, das R/W Bit liegt, wenn man es in die Adresse reinrechnet, mitten drin. Die Spezialisten hier schimpfen immer, wenn man ein Register, daß verschiedene Bits oder Bitfelder beinhaltet in einem Rutsch als Hexwert beschreibt. Ein solcher Code sei schlecht wartbar und unleserlich. Mit derselben Begründung ist dann das erste Byte eine I2C-Telegramms (auch schon mal Address Byte genannt):
1 | data = I2C_address << 1 | RW_bit |
MfG Klaus
Klaus schrieb: > Nicht "mitlerweile" sondern schon immer. Nö - das ist nicht korrekt. Die 10-Bit-Adressierung kam später.
Hallo Falk diese 1024 hab ich irgendwo im Netz gelesen. Das mit den 128 ist ja klar. Ich kenne auch die Version, das in abhängigkeit der verwendeten ICs es zu einer doppelten Adresse kommen kann und ich dann 2x Bus verwenden muss mit einem entsprechenden ICs um beide Bus Adressen zu verwenden. Es geht mir im Moment darum, das ich jetzt durcheiander gekommen bin oder eine Stelle nicht ganz verstanden habe oder etwas einfach durcheinander bringe. Deswegen frage ich bei euch. Zu der falschen Bezeichnung. Habe infach das Stück von oben kopiert Werde jetzt im Prg es ändern. achim
Es kommt darauf an, wie die Adresse im Programm/den Funktionen verwendet wird. Da muss man im Sourcecode nachsehen.
1 | #define RW_BIT 1
|
2 | |
3 | //Version 1 , 7 Bit ohne RW
|
4 | |
5 | #define I2C_ADDRESS 0x20
|
6 | |
7 | data = I2C_ADDRESS << 1 | RW_bit |
8 | |
9 | //Version 2 , 8 Bit incl. RW
|
10 | |
11 | #define I2C_ADDRESS 0x40
|
12 | |
13 | data = I2C_ADDRESS | RW_bit |
Dieter Frohnapfel schrieb: > Die 10-Bit-Adressierung kam später. ... nämlich 1992 (1982 wurde die "originale I²C-Bus-Spezifikation" bekanntgegeben) ...
Dieter Frohnapfel schrieb: > Klaus schrieb: >> Nicht "mitlerweile" sondern schon immer. > > Nö - das ist nicht korrekt. Die 10-Bit-Adressierung kam später. Ab Version 1.0 (1992), d.h. die erste Version die nicht nur Philips intern war. Ich würde sagem, dass zählt als schon immer. In der Spec wird die Addresse immer nur binär geschrieben, und wird dabei sehr oft in 4bit gefolgt von 3bit gruppiert. Und das legitimiert die hexadezimale 8bit Schreibweise. Die aus der I2C Spec abgeleitete SMBUS Spec schreibt an mehreren Stellen, dass das bit 0 der Assigned Address (ein 8bit Wert!) zu ignorieren ist. Davon abgesehen wird immer binär notiert, aber auch hier mit 4bit,3bit Gruppierung. Darauf zu bestehen, dass das eine richtig und das andere falsch ist (egal wie rum) geht schlicht und einfach an der Realität vorbei.
Lattice User schrieb: > Ich würde sagem, dass zählt als schon immer. Nö - (mal abgesehen davon, dass mich "würde" nicht berührt; aber ihr könnt gerne eine Gebetsfahne oder -trommel aufstellen, nur wird es dadurch nicht richtiger :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.