Kleine Frage zu TWI bzw. I²C Ansteuerung

Falls du C kannst, würde ich Dir empfehlen, von einer C Library 
abzugucken. Das Datenblatt ist nämlich an vielen Stellen ziemlich 
unklar.

int 21h schrieb:
> Natürlich sagt der Name bereits alles, aber wie und in welcher
> Reihenfolge setze ich das "Data/Command Bit"?
> (In dem Diagramm vom Hersteller ist das nicht ganz ersichtlich finde
> ich)

Ich kann das "nicht ersichtlich Finden" nicht nachvollziehen.

Ist im Diagramm klar dargestellt.

Ich hänge noch mal einen Ausschnitt vom Diagramm an.
Daraus entnehme ich, dass man nach der Slave Adresse immer ein "Control 
Byte" mitgibt (und davon Bit 5-0 immer Low sind).
Aber ich verstehe immer noch nicht den Zweck des Continuation Bits.
Und dem Diagramm ist zu entnehmen, dass nach jedem Databyte wider ein 
Controlbyte folgt. Könnte man sich das nicht sparen?

Bessa Wissa schrieb:
> void ssd1306_command_start (void)
> {
>   I2C_SetStart (SSD1306_SA);   // Slave address
>   I2C_WriteByte (0x00);        // write command
> }
>
> void ssd1306_send_command (uint8_t command)
> {
>   ssd1306_command_start ();
>   I2C_WriteByte (command);
>   I2C_SetStop ();
> }
>
> void ssd1306_send_data_start (void)
> {
>   I2C_SetStart (SSD1306_SA);   // Slave address
>   I2C_WriteByte (0x40);        // write data
> }

Bei ssd1306_command_start sowie bei ssd1306_send_data_start ist das 
"Data command selection Bit" auf Low.
Nur bei send_data setzt du das "Co" Bit auf High.
Aber macht das Sinn?

Edit:

int 21h schrieb:
> Bei ssd1306_command_start sowie bei ssd1306_send_data_start ist das
> "Data command selection Bit" auf Low.
> Nur bei send_data setzt du das "Co" Bit auf High.
> Aber macht das Sinn?

Sorry, das D/C Bit wird doch gesetzt, hatte mich bei der Umrechnung 
verlesen.

Ich habe die "ssd1306_send_data" Routine soweit fertig gestellt.
Auf meinem OLED wird aber noch nichts dargestellt.
Um mich jetzt noch einmal auf Fehlersuche zu begeben, muss noch etwas 
geklärt werden.

Mal Angenommen ich möchte jetzt ein Datenbyte an das OLED senden um 8 
Pixel vom Display weiß darzustellen.
Das mache ich mit der TWI Schnittstelle vom Atmega328p folgendermaßen:

-> START einleiten
-> TWI Datenregister mit der SLAVE_ADD+W beschreiben
-> TWI Datenregister ausgeben
-> TWI Datenregister mit dem Controlbyte beschreiben (0x40)
-> TWI Datenregister ausgeben
-> TWI Datenregister mit dem jeweiligen Byte beschreiben
-> TWI Datenregister ausgeben
-> STOP einleiten

Mir ist jetzt nicht ganz klar, wie sich die Slave Adresse darstellt.
Laut meinen Quellen über TWI besteht die Slave Adresse immer auf 7 Bit!
Das letzte Bit sagt dann aus ob das GDDRAM gelesen oder beschrieben 
werden soll.
In dem Diagramm (siehe oben) stehen aber nur 6 Bits für die Adresse.
Wofür ist das nächste Bit (SA0) da, also Bit 1?
Laut Datenblatt:
"For the SSD1306, the slave address is either “b0111100” or “b0111101” 
by changing the SA0 to LOW or HIGH (D/C pin acts as SA0)."

int 21h schrieb:
> In dem Diagramm (siehe oben) stehen aber nur 6 Bits für die Adresse.

In "unserem" Fall muss die Device Adresse linksbündig stehen damit
für das R/W Bit noch Platz bleibt.

Also Device Adresse = xxxx_xxxY, Y=R/W

int 21h schrieb:
> In dem Diagramm (siehe oben) stehen aber nur 6 Bits für die Adresse.

Ohne das Datenblatt gelesen zu haben. Können durch SA0 vielleicht 
verschiedene Register/Teile des Displays angesprochen werden?

Hier noch einmal der Komplette Quellcode falls jemand interessiert ist 
(was ich nicht glaube ^^)
https://pastebin.com/Ww91e33e


Bessa Wissa schrieb:
> int 21h schrieb:
>> In dem Diagramm (siehe oben) stehen aber nur 6 Bits für die Adresse.
>
> In "unserem" Fall muss die Device Adresse linksbündig stehen damit
> für das R/W Bit noch Platz bleibt.
>
> Also Device Adresse = xxxx_xxxY, Y=R/W

Kann ich das SA0 Bit also auf Low setzen?

int 21h schrieb:
> Kann ich das SA0 Bit also auf Low setzen?

Wirst du vermutlich sogar müssen, denn diese Displays haben
normalerweise eine Device Adresse von 0x78 (linksbündig).

int 21h schrieb:
> falls jemand interessiert ist (was ich nicht glaube ^^)

Was ich auch nicht glaube, denn wenn man das Display wirklich
nutzbringend ansteuern will dann ist noch "ein wenig" mehr an
Assembler-Arbeit erforderlich.

Du hast auf Assembler-Ebene auch keinerlei Zeitvorteil da die
Geschwindigkeitsbegrenzung im I2C-BusTransfer zu suchen ist,
nicht im ansteuernden Code.

Bessa Wissa schrieb:
> int 21h schrieb:
>> falls jemand interessiert ist (was ich nicht glaube ^^)
>
> Was ich auch nicht glaube, denn wenn man das Display wirklich
> nutzbringend ansteuern will dann ist noch "ein wenig" mehr an
> Assembler-Arbeit erforderlich.

Ja das ist mir klar, danke.
Aber erst einmal muss ich diese eine Routine zum laufen bekommen.
Der Rest klärt sich dann von selbst.
Mein Ziel wird es später sein, mit diesen Mitteln ein kleines Spiel zu 
entwickeln.
Sei es so geringfügig wie Snake oder ein Klicker Simulator.

Bernd S. schrieb:
> Ich setze mal das von dir verlinkte Listing hier rein und auch als
> Anhang, damit andere sich daraus einfach Passagen kopieren, edidieren
> und wieder hier reinsetzen können :

Welchen Zweck hat das ganze den??

Kann es sein, dass du das Display noch nicht initialisiert hast? Ich 
habe dazu noch keinen Programmcode gesehen. Diese Displays brauchen eine 
umfangreiche Initialisierungssequenz.

int 21h schrieb:
> Welchen Zweck hat das ganze den??

Damit er auch was mit labern kann.

Stefanus F. schrieb:
> Kann es sein, dass du das Display noch nicht initialisiert hast? Ich
> habe dazu noch keinen Programmcode gesehen. Diese Displays brauchen eine
> umfangreiche Initialisierungssequenz.

Ich habe das Display nicht initialisiert, da ich es bis her nicht für 
nötig gehalten habe. Ich wollte mich erstmal auf die Voreinstellungen 
beschränken (Page-Addressing Mode, x=0, y=0).
Aber vielleicht liegt ja wirklich hier der Fehler.
Ich werde mich noch mal von neuem einlesen.

Bessa Wissa schrieb:
> int 21h schrieb:
>> Welchen Zweck hat das ganze den??
>
> Damit er auch was mit labern kann.

XD

int 21h schrieb:
> Ich habe das Display nicht initialisiert, da ich es bis her nicht für
> nötig gehalten habe.

Plonk.

> Aber vielleicht liegt ja wirklich hier der Fehler.

Nicht nur vielleicht, sondern 100% sicher. Es sind ungefähr 26 Bytes zur 
Initialisierung nötig. Du darfst hiervon abgucken: 
http://stefanfrings.de/esp8266/WIFI-Kit-8-OLED.zip Die 
Initialisierungssequenz beginnt in oled.cpp Zeile 257.

Stefanus F. schrieb:
> Nicht nur vielleicht, sondern 100% sicher. Es sind ungefähr 26 Bytes zur
> Initialisierung nötig.

Ich habe mir die von dir mitgegebene Initialisierungs Routine mal 
angeschaut.
Die meisten von denen bzw. fast alle wären bei mir gar nicht nötig, da 
diese bereits beim Reset gesetzt werden.

Laut Datenblatt kann man 0x12 nicht als Parameter auswählen:
> i2c_send(0xDA); // com pins hardware configuration
> i2c_send(0x12);

Wieso versetzt du den uC in den sleep mode:
> i2c_send(0xAE); // display off
Wird übrigens von alleine durch den Reset gesetzt.

Also ist die ganze Initialisierungs Routine sozusagen überflüssig... 
schade :/

> Die meisten von denen bzw. fast alle wären bei mir gar nicht
> nötig, da diese bereits beim Reset gesetzt werden.

Kann sein. Ich habe es gemäss dem angehängten Datenblatt programmiert 
und dann so gelassen, da es funktioniert. Auf ein paar Bytes mehr oder 
weniger kommt es am Ende nicht an.

> Laut Datenblatt kann man 0x12 nicht als Parameter auswählen:
>> i2c_send(0xDA); // com pins hardware configuration
>> i2c_send(0x12);

In dem angehängten Datenblatt ist der Wert 0x12 vorgegeben und so 
funktioniert das Display auch.

> Wieso versetzt du den uC in den sleep mode

Weil das im Datenblatt so empfohlen wird.

> Also ist die ganze Initialisierungs Routine sozusagen überflüssig...

Das bezweifle ich. Der Chip ist für viele unterschiedliche Displays 
geeignet und hat mehrere Optionen zur Stromversorgung. Er muss dazu 
passend konfiguriert werden.

Ich kann Dir nur empfehlen, mit einem bewährten Code zu beginnen und den 
dann ggf. auf das Nötigste zu reduzieren. Wunder Dich dann aber nicht, 
wenn es beim nächsten Display nicht mehr funktioniert. Die Chinesen 
bauen oft gleichnamige Chips, die sich nicht exakt gleich verhalten.

Wir hatten diese Diskussion auch schon öfters bezüglich HD44780 
kompatible Displays. Fast immer wenn ein Programm nicht funktionierte, 
lag es daran, dass der Programmierer sich nicht an die Vorgaben des 
Datenblattes gehalten hat - in dem Glauben, er könne etwas weglassen 
oder schneller machen. So etwas funktioniert dann oft mit einem Display, 
aber nicht mit jedem vermeintlich baugleichen.

Stefanus F. schrieb:
> Du darfst hiervon abgucken:
> http://stefanfrings.de/esp8266/WIFI-Kit-8-OLED.zip Die
> Initialisierungssequenz beginnt in oled.cpp Zeile 257.

Manche Routinen sind mir in dem Code noch nicht ganz klar.
1. Wieso taucht immer wieder "OLED_I2C_DELAY;" auf?
2. Bei der Funktion "bool OLED::i2c_send(uint8_t byte)" verarbeitest du 
jedes
   Bit aus der Variable byte einzeln. Bei mir erledigt es das 
integrierte TWI
   Module vom uC selbstständig.
   Das macht es sehr schwer, deinen Code mit meinem Assembler zu 
vergleichen,
   da du eine ganz andere Vorgehensweisen nutzt.
3. ich würde mir gerne die beiden Funktionen digitalWrite/Read genauer
   anschauen wollen, wäre das möglich?

Sonst ist alles genauso wie bei mir.
Deine Initialisierungsschritte sind die selben wie bei mir.

Noch eine Frage, hinter meinem OLED steht die Slave Adresse "0x78", 
müsste ich diese bei der Übertragung dann auch schicken oder die hälfte 
vom Wert?
Also (0x78 << 1) oder (0x3C << 1)?

int 21h schrieb:
> 1. Wieso taucht immer wieder "OLED_I2C_DELAY;" auf?

Damit die Kommunikation nicht zu schnell wird. Das Display ist bis 
400kHz Taktrate spezifiziert. Darüber hinaus muss man aber auch gewisse 
Abstände zwischen den Signalwechseln an SCL versus SDL einhalten.

> 2. Bei der Funktion "bool OLED::i2c_send(uint8_t byte)" verarbeitest du
> jedes Bit aus der Variable byte einzeln.

Ja, das nennt man Bit-Banging. Diese Library nutzt nicht das TWI 
Interface, sondern normale I/O Pins.

> Bei mir erledigt es das integrierte TWI

Wenn möglich ist das sicher die bessere Wahl.

> Das macht es sehr schwer, deinen Code mit meinem Assembler zu
> vergleichen, da du eine ganz andere Vorgehensweisen nutzt.

Es sind doch nur drei Funktionen:

OLED::i2c_start() sendet eine START Bedingung
OLED::i2c_stop() sendet eine STOP Bedingung
OLED::i2c_send(uint8_t byte) sendet ein Byte und liefert die Antwort 
(ACK oder NACK) zurück.

und Empfangen wird gar nicht.

Ob du das wie ich per Bitbanging oder durch ein TWI Interface 
austauschst, spielt doch für den Rest des Quelltextes keine Rolle.

> 3. ich würde mir gerne die beiden Funktionen digitalWrite/Read genauer
>    anschauen wollen, wäre das möglich?

Dann lade Dir die Arduino IDE herunter und gucke in die Quelltexte rein. 
Sicher kannst du deren Quelltext auch irgendwo auf Github finden. Doch 
da gibt es nichts spannendes zu sehen. digitalWrite setzt einen 
einzelnen I/O Pin auf High oder Low und digitalRead liest den Zustand 
eines I/O Pins ein.

> Sonst ist alles genauso wie bei mir.

Sicher? Noch vor wenigen tagen schriebst du:
> Ich habe das Display nicht initialisiert, da ich es bis her nicht für
> nötig gehalten habe.
> Also ist die ganze Initialisierungs Routine sozusagen überflüssig...

Die Adresse wird in den oberen 7 Bit übertragen. Das niederwertigste Bit 
signalisiert, ob du lesen oder schreiben willst. Siehe 
https://www.nxp.com/docs/en/user-guide/UM10204.pdf

0x78 ist keine gültige I²C Adresse, weil das nicht in 7 Bit passt. Aber 
wenn du die richtige Adresse 0x3C um ein Bit nach links schiebst, um 
Platz für das R/W Bit zu machen, und dieses R/W Bit auf 0 setzt, dann 
kommt dabei 0x78 heraus. Das ist das Byte, dass du zur Adressierung 
senden musst.

Besorge Dir mal einen Logic Analyzer, damit kannst du deine 
Kommunikation überprüfen. Die Dinger kosten nur ca 10 Euro!

Joachim B. schrieb:
> Stefanus F. schrieb:
>> 0x78 ist keine gültige I²C Adresse, weil das nicht in 7 Bit passt. Aber
>> wenn du die richtige Adresse 0x3C
>
> was ist schon richtig, es ist eine Frage der Interpretation.
>
> Die ersten LIBs vor Arduino und Datenblätter wiesen 0x78 aus, das passt
> in 7 Bit rechtsshift!
> Das read/write Bit gehört als 8tes Bit ja wohl dazu, also falsch ist es
> nicht.

Oh, 0x78 passt ja doch in 7 Bit. Facepalm.

Jedenfalls sollte man da klar unterscheiden. I²C Adressen sind immer 
7-bit (oder 10-bit) lang. Das achte Bit gehört nicht zur Adresse. Wenn 
das so wäre, dann müsste in der Spezifikation etwa das stehen:

"The device address is reserved for write operation. The following 
address (+1) is reserved for read operation."

Aber so steht das dort nicht. Sondern:

"7-bit slave address" (Absatz 3.1.0)

Absatz 3.1.10 zeigt detailliert, wie die 7-bit Adresse und das R/W Bit 
übertragen werden. Dort ist ganz klar die Adresse von R/W-bit getrennt 
gezeichnet. Und dann gibt es ja noch die 10-bit Adressierung, auch dort 
ist die Adresse klar von anderen Bits getrennt dargestellt.

Wer jetzt irgendwo von einer 8-bit Adresse oder einen 8-bit Wert 
schreibt, der hat es nicht verstanden und stiftet unnötige Verwirrung. 
Ich weiß dass sogar einige Datenblätter es nicht richtig darstellen oder 
zumindest unklar.

Wenn ich eine Funktion write_i2c(addr,buffer,len) oder 
read_i2c(addr,buffer,len) oder so ähnlich anbiete, dann muss klar sein, 
dass addr entweder eine 7-bit oder 10-bit Adresse ist. Irgendwelche 
protokollspezifischen Shift Operationen sind Aufgabe der 
Schnittstellen-Implementierung, nicht des Aufrufers. Willst du etwa bei 
der 10-bit Adressierung das Shiften auch dem Aufrufer überlassen? Das 
wäre Wahnsinn!

Danke für deine Hilfe Stefanus, jetzt ist mir alles klar geworden.
Ich denke, jetzt sollten meine weiteren Fragen aufkommen.

P.s. Ich hatte die Bitrate nicht eingestellt, vielleicht liegt das 
Problem unter anderem daran.

Stefanus F. schrieb:
> Besorge Dir mal einen Logic Analyzer, damit kannst du deine
> Kommunikation überprüfen. Die Dinger kosten nur ca 10 Euro!

Sehr gute Sache das Teil, ich habe es direkt in meinen Warenkorb gelegt.

Joachim B. schrieb:
> Stefanus F. schrieb:
>> Wer jetzt irgendwo von einer 8-bit Adresse oder einen 8-bit Wert
>> schreibt, der hat es nicht verstanden
>
> ich frage mich gerade WER was nicht verstanden hat, man muss auf jeden
> FALL 8 Bit senden, das die Adresse hier 7-bittig ist ist doch
> schnurzpiepegal ohne 8tes Bit R/W schickt man NICHTS, aber dreh dich nur
> weiter, DU hast IMMER Recht und alle anderen sind doof.

Das kommt dabei heraus, wenn man einzelne Sätze aus dem Zusammenhang 
reißt ohne den Rest zu beachten. Ich habe klar geschrieben, dass

a) die Adresse 7-bit oder 10-bit groß ist, und
b) dass die 7-bit Adresse mit dem R/W bit zusammen als 8-bit gesendet 
wird.

Es gibt bei I²C keine 8-bit Adresse

Habe ich ja geschrieben, einige Datenblatter machen das meiner Meinung 
nach falsch. Philips (jetzt NXP) hat die Adressen spezifiziert, meine 
Meinung nach ist da kein Raum für Abweichungen von 7 und 10 bits.

Stefanus F. schrieb:
> Habe ich ja geschrieben, einige Datenblatter machen das meiner Meinung
> nach falsch. Philips (jetzt NXP) hat die Adressen spezifiziert, meine
> Meinung nach ist da kein Raum für Abweichungen von 7 und 10 bits.

Richtig, für I2C gibt es eine aufgeschriebene Dokumentation. Und dort 
kommen nur 7 Bit oder 10 Bit Adressen vor. Das Datenblatt eines Chips 
ist nur Sekundärliteratur.

Daß in einem Byte 2 verschiedene Informationen übertragen werden (hier 
Adresse und Richtung der folgenden Übertragung) scheint für manche zu 
kompliziert zu sein. Etwas komplexere Protokolle, bei denen noch mehr 
als zwei unabhängige Informationen in ein Byte kodiert werden, würden 
die nie verstehen.

MfG Klaus

Stefanus F. schrieb:
> Philips (jetzt NXP) hat die Adressen spezifiziert

So ist es und Philips/NXP darf das.
Und sieht man in ein Datenblatt von NXP beispielsweise für den PCF8583 
https://www.nxp.com/documents/data_sheet/PCF8583.pdf, dann steht dort 
auf der 1. Seite:
"Slave addresses: A1h or A3h for reading, A0 or A2 for writing"
Für mich sind das eindeutig 8 Bit Werte ;-)

Man tut sich im übrigen keinen Gefallen, IIC-Adressen mit 7 Bit 
rechtsbündig anzugeben. Denn sobald man sich die Signale auf dem Bus 
ansieht, passt das nicht mehr zusammen.

Aus der I2C Spec:

> This address is 7 bits long followed by an eighth bit
> which is a data direction bit (R/W)

m.n. schrieb:
> Man tut sich im übrigen keinen Gefallen, IIC-Adressen mit 7 Bit
> rechtsbündig anzugeben. Denn sobald man sich die Signale auf dem Bus
> ansieht, passt das nicht mehr zusammen.

Das stimmt so nicht, mein i2c Dekoder zeigt sie mir als 7-Bit Wert an 
und getrennt davon das R/W Bit. Das krieg ich aber auch im Kopf leicht 
hin.

Nur weil manche nicht in der Lage sind etwas abstrakter zu denken, 
sollte man das eigene Niveau nicht daran anpassen. Es gibt noch 
wesentlich komplexere Kodierungen. Ein Fall ist z.B. die 10 Bit I2C 
Adresse oder noch etwas komplexer Base64.

MfG Klaus

Klaus schrieb:
> Das stimmt so nicht, mein i2c Dekoder zeigt sie mir als 7-Bit Wert an
> und getrennt davon das R/W Bit.

Wie Du siehst, taugt das Ding nichts! ;-)

Der IIC-Bus wurde Anfang der 80er von Philips entwickelt. Folglich hat 
man auch die Vorgaben des Urhebers Übernommen, zum Beispiel für den 
PCF8385 die Adressen A0 und A2 als Basisadressen zu verwenden.
Dass die heutige Jugend das nicht mehr weiß, ist nicht mein Problem.

Klaus schrieb:
> Daß in einem Byte 2 verschiedene Informationen übertragen werden (hier
> Adresse und Richtung der folgenden Übertragung) scheint für manche zu
> kompliziert zu sein.

Genau deswegen würde ich Schnittstellentreiber ("Libraries") immer so 
auslegen, dass jeder Aufrufparameter genau eine Funktion hat. Also eben 
nicht Adresse mit R/W Bit kombinieren. Spätestens wenn man das mal auf 
10-bit erweitert wird das ganz besonders wichtig, denn da steckt das R/W 
bit mitten drin.

m.n. schrieb:
> Und sieht man in ein Datenblatt von NXP beispielsweise für den PCF8583
> https://www.nxp.com/documents/data_sheet/PCF8583.pdf, dann steht dort
> auf der 1. Seite:
> "Slave addresses: A1h or A3h for reading, A0 or A2 for writing"
> Für mich sind das eindeutig 8 Bit Werte ;-)

Tolle Wurst, die legen es wohl drauf an, ihre Kunden zu verwirren.

> Man tut sich im übrigen keinen Gefallen, IIC-Adressen mit 7 Bit
> rechtsbündig anzugeben. Denn sobald man sich die Signale auf dem Bus
> ansieht, passt das nicht mehr zusammen.

Die beiden mir bekannten Logic Analyzer Programme können die Adresse 
wahlweise in beiden Formaten anzeigen.

Joachim B. schrieb:
> Deine Meinung lasse ich dir gerne, die darf ruhig anders sein.

Dito, wir müssen uns nicht auf einen gemeinsamen Konsens einigen - 
jedenfalls nicht für diese Pillepalle.

Ich wollte heute mal wieder an dem Programm für die TWI Kommunikation 
weiterarbeiten.
Als nach vielen Versuchen immer noch nichts am Display zu sehen war, 
beschloss ich spaßeshalber noch einmal das OLED Arduino Sketch von 
Adafruit drauf zu spielen.
Auf dem Display war allerdings nichts zu sehen.
Vor wenigen Tagen lief das Programm noch und heute nicht mehr.
Die Schaltung ist die selbe geblieben, unverändert!
Dann habe ich test weise ein Programm zum auslesen der TWI Adresse 
geladen, dass auch funktioniert hat (0x3C kam raus).
Ist das GDDRAM vom OLED defekt?
Geht das wirklich so leicht?

Klaus schrieb:
> mein i2c Dekoder zeigt sie mir als 7-Bit Wert an
> und getrennt davon das R/W Bit

Den kennen hier sicher alle :-)

Joachim B. schrieb:
>> "Slave addresses: A1h or A3h for reading, A0 or A2 for writing"
>> Für mich sind das eindeutig 8 Bit Werte ;-)
>
> ganz meine Meinung!

Sehe ich auch so - man achte auf das letzte Bit.

Stefanus F. schrieb:
> Die beiden mir bekannten Logic Analyzer Programme können die Adresse
> wahlweise in beiden Formaten anzeigen.

Kannst Du die bitte benennen? Die hätte ich auch gerne.

Dieter F. schrieb:
> Stefanus F. schrieb:
>> Die beiden mir bekannten Logic Analyzer Programme können die Adresse
>> wahlweise in beiden Formaten anzeigen.
>
> Kannst Du die bitte benennen? Die hätte ich auch gerne.

Sigrok/PulseView und Salae Logic.

Stefanus F. schrieb:
> und Salae Logic.

Saleae nutze ich - da ist es mir noch nicht aufgefallen. Ich schaue mal.

Ganz rechts bei I2C Analyzer musst du auf das Zahnrad klicken, dann auf 
Edit Settings,dann erscheint der gezeigte Dialog.

7-bit Address bits only
8-bit read/write bit included

Und dann gibt es noch eine Option, die ich für Quatsch halte:
8-bit read/write bit set as 0

Stefanus F. schrieb:
> Ganz rechts bei I2C Analyzer musst du auf das Zahnrad klicken, dann auf
> Edit Settings,dann erscheint der gezeigte Dialog.

Danke - werde ich bei Gelegenheit ausprobieren. War mir echt unbekannt. 
Vielen Dank.

Das habe mir jetzt alle Initialisierungs Commands herausgesucht, die 
unbedingt nötig sind um etwas darzustellen.
Dabei stieß ich auf den Command "Charge Pump Regulator", der anscheinend 
unbedingt aktiviert werden muss.
(Der Grund weshalb ich diesen Befehl erst jetzt im Datenblatt entdeckt 
habe, ist weil der ganz unten im Datenblatt steht und auch nicht in der 
Command Table eingetragen ist!)
Kann mir jemand bitte erklären, was dieser genau macht, da ich nicht 
viel von Elektronik verstehe?

Warum kopierst du nicht einfach die von mir empfohlene 
Initialisierungssequenz aus dem Datenblatt des Displays (nicht dem 
Datenblatt des COB)? Meinst du die schreiben das zum Spaß dort hinein?