Hallo Zusammen,
auf einem zugegebenermaßen äußerst billigen Display finden sich auf der
Platine die I2C-Adresse 0x78 und 0x7A. (Wobei es auf meiner Platine so
unsauber gedruckt ist, dass es auch 0x7B heißen könnte).
Funktioniert aber alles nicht. Was funktioniert ist 0x3C. Controller ist
ein SSD 1306.
Ist das ein Fehler in der Hardware/im Aufdruck oder verstehe ich etwas
falsch - und wenn ja, dann wüsste ich natürlich auch gerne was... ;-)
Thx u. Grüße
PS: Hier ein Foto
https://images-na.ssl-images-amazon.com/images/I/71GKhNAcDbL._SL1500_.jpg
HS schrieb:> Ist das ein Fehler in der Hardware/im Aufdruck oder verstehe ich etwas> falsch
Es gibt Leute, die geben die I2C-Adresse wie in der Spezifikation von
Philips als 7-Bit Wert an. Dann besteht das erste übertragene Byte aus
den 7 Adressbits und dem R/W-Bit und es gibt Leute, die geben das erste
Byte als Adressbyte an.
0x3C würde allerdings eher zu 0x78/0x79 passen.
HS schrieb:> Was funktioniert ist 0x3C
...
> oder verstehe ich etwas falsch
Das ist das übliche und weit verbreitete Problem der 7- bzw.
8-Bit-Adressen von I2C.
0x3C << 1 == 0x78
Bei 8-Bit-Darstellung wird das R/W-Bit zur Adresse hinzugefügt.
Rufus Τ. F. schrieb:> Das ist das übliche und weit verbreitete Problem der 7- bzw.> 8-Bit-Adressen von I2C.
Es könnte alles so einfach sein, wenn sich jeder bei seiner Bezeichnung
an die Spezifikation halten würden (UM10204 Fig.9) und es den Leuten
beizubringen wäre, Adresse und erstes Byte ("Address Byte") auseinander
zu halten.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
HS schrieb:> Ist das ein Fehler in der Hardware/im Aufdruck oder verstehe ich etwas> falsch - und wenn ja, dann wüsste ich natürlich auch gerne was... ;-)
Wie es schon gesagt wurde, ist es eine Frage der Adress-Darstellung. Auf
der Platine ist der 8-Bit-Code abgedruckt. Und das ist im Prinzip auch
richtig so denn Slaves, und das ist dein Display ja, arbeiten mit der
8-Bit-Darstellung (0x78) während Master mit der 7+1-Bit-Darstellung
arbeiten (hier wird dann 0x3C vorgegeben, der Mastercode hängt dann das
letzte Bit hinten dran). Ich hab diesen Fehler auch in meinen Mastercode
drin, werde ich irgendwann noch abändern müssen (hab ja auch eine Lib zu
den SSD1306-Controllern geschrieben)
M. K. schrieb:> Und das ist im Prinzip auch richtig so denn Slaves, und das ist> dein Display ja, arbeiten mit der 8-Bit-Darstellung (0x78) während> Master mit der 7+1-Bit-Darstellung arbeiten
Wofür gibt es eigentlich Spezifikationen?
Propagierst du jetzt, das Master und Slave bei der Kommunikation
nominell unterschiedliche Adressen verwenden?
Damit wird die Welt nicht übersichtlicher.
Der Slave hat genauso eine 7 Bit Adresse und die Datenrichtung wird
genauso über das nachfolgend übertragene Bit spezifiziert.
Wolfgang schrieb:> Wofür gibt es eigentlich Spezifikationen?> Propagierst du jetzt, das Master und Slave bei der Kommunikation> nominell unterschiedliche Adressen verwenden?
Nein, ihre Adresse ist gleich aber die Darstellung wird unterschiedlich
gehandhabt, auch in der eigentlichen Spezifikation. ;)
M. K. schrieb:> Nein, ihre Adresse ist gleich aber die Darstellung wird unterschiedlich> gehandhabt, auch in der eigentlichen Spezifikation. ;)
Wo? Ich konnte nicht finden, was der 7Bit Spezifikation widerspricht.
Auch dort wird von 7 Bit Slave Address gesprochen und in den Abbildungen
sind genau diese 7 Bit als "Address" bezeichnet. Im Text tauchen IMHO
auch immer 7Bit Adressen (gesetzt als 4+3 Bit) auf.
Aber diese Diskussion scheint wohl fruchtlos und man wird weiterhin mit
beiden Sprachgebräuchen leben müssen.
Wolfgang schrieb:> Der Slave hat genauso eine 7 Bit Adresse und die Datenrichtung wird> genauso über das nachfolgend übertragene Bit spezifiziert.
Ganz so einfach ist das nicht. Manche Slaves arbeiten eben NUR in einer
Richtung und reagieren auf die andere garnicht. Also wäe es logisch,
grundsätzlich immer nur die 8 Bit Darstellung zu wählen. Da weiß man
präzise, worauf so ein Slave überhaupt reagiert.
Aber abgesehen von dieser Theoretisiererei ist es doch ganz easy:
Einfach mal nen Scan aller Adressen machen und ab da weiß man, was man
zu wissen braucht.
W.S.
W.S. schrieb:> Also wäe es logisch,> grundsätzlich immer nur die 8 Bit Darstellung zu wählen.
Genau das ist "the root of all evil".
Besser wäre schon, nur devices mit Adressen >64 zu verwenden, da ist
sofort klar ob 7 oder 8 bit :-)
Da der Erfinder, Philips, in den Anfangszeiten von I²C üblicherweise die
Adresse als Adressbyte mit LSB = R/W angegeben hat, bleibe ich dabei.
Also Adresse ist AAAA AAAx. Das die Linuxianer, und so manch Anderer,
die Bits nach unten schiebt, ist deren Ding. Was jetzt NXP/Qualcomm
macht, weiß ich nicht. Aber in den Anfängen wurde immer das Byte als
Adresse genannt. Und Adresse + 1 war dann logischerweise die
Leseadresse.
Leider hat es Philips verabsäumt, dies explizit im Standard so
festzuschreiben. Wahrscheinlich deshalb, weil es eh jedem klar war. Aber
dann kamen die Linuxianer....
Viele I²C Mikrochips haben mehr oder weniger Leitungen zur Einstellung
einiger Adress-Bits. Diese heissen üblicherweise A0, A1, A2, usw.
A0 ist hierbei das niedrigste Bit der 7bit Adresse - nicht das
niedrigste Bit des Bytes!
Andi B. schrieb:> Leider hat es Philips verabsäumt, dies explizit im Standard so> festzuschreiben. Wahrscheinlich deshalb, weil es eh jedem klar war. Aber> dann kamen die Linuxianer....
Das ist doch Unsinn. In vielen, zum Teil immer noch üblichen,
Datenprotokollen werden Bits und Bitfelder in einem Datenbyte, meisst
eher Oktet genannt, übertragen. Bei HDLC kann man zb. zwei 3bit Felder
und zwei Bits in einem Oktet finden. Wenn man das in einem Stück
bearbeiten würde, bekäme man nie einen Funktionierenden Protokollstack
hin.
Das sprengt natürlich das Verständniss der Nicht-Linuxianer, die über
die für den mechanischen Fernschreiber erfundene asynchrone
Schnittstelle nie wirklich hinausgekommen sind.
MfG Klaus
Andi B. schrieb:> Da der Erfinder, Philips, in den Anfangszeiten von I²C üblicherweise die> Adresse als Adressbyte mit LSB = R/W angegeben hat, bleibe ich dabei.> Also Adresse ist AAAA AAAx.
Dann mal Butter bei die Fische
Wo liest du das?
In der oben verlinkten UM10204 von NXP ist davon nichts zu erkennen -
und das ist die zuletzt 2014 überarbeitet Revision, der ursprünglich von
Philips herausgegebenen Originalausgabe der Spezifikation von 1982.
Die Adresse ist die Adresse
und das R/W Bit ist das R/W Bit
und das ACk-Bit ist das ACK Bit
Jedes ist für sich
Alle zusammen brauchen 9 Bit.
Die Adresse braucht 7 Bit. Das R/W-Bit hat nichts mit der Adresse zu
tun. Sonst hätte jeder Slave 2 Adressen und das R/W-Bit wäre nirgendwo
als solches erwähnt.
Punkt.
Hi
> Bei HDLC kann man zb. zwei 3bit Felder>und zwei Bits in einem Oktet finden. Wenn man das in einem Stück>bearbeiten würde, bekäme man nie einen Funktionierenden Protokollstack>hin.
Und was hat das mit den I2C-Adressen zu tun?
MfG Spess
Andi B. schrieb:> Aber dann kamen die Linuxianer....
Wie lange hast Du gebraucht um einen Zusammenhang zu Linux und
imaginären "Linuxianern" herbeizufantasieren bei diesem Thema das
absolut null und nichts damit zu tun hat, aber auch sowas von gar
nichts, und zwar nicht mal im Entferntesten? Bist Du etwa ein
Windowsianer und suchst Streit?
