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
https://www.heise.de/select/make/2017/3/1498421637812722 Dein Problem ist hier (weiter unten) beschrieben.
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: > I2C-Adresse 0x78 und 0x7A p.s. die beiden aufgedruckten Adressen beziehen sich auf den Lötjumper für den D/C-Pin (SA0 im I2C Mode)
Danke. Also kein Chinaschrott, also zumindest nicht deswegen ... u. ich hab was gelernt.
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.
Wenn man das bit 7 für R/W verwendet hätte, gäbe es dieses Missverständnis nicht.
HS schrieb: > Was funktioniert ist 0x3C. Das war keine Überraschung:
1 | 0x3C<<1 == 0x78 |
Oftmals ist deswegen auch eine Wellenform für das I²C Signal angegeben, weil die 7-Bit Addressen manchmal geshiftet sind und manchmal nicht.
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?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.