Ich betreibe ein
1.3" OLED LCD 4Pin Display Module IIC I2C 128x64 3-5V
an einem STM32F103C8T6 und einer Library von
https://controllerstech.com/oled-display-using-i2c-stm32/
Auf dem Display (s. Bild) sieht man am rechten Rand so ein Gegrissel,
auf dessen Zustandekommen ich mir keinen Reim machen kann. Es gab mal
einen Zustand im Verlauf der Programmierung, da war es plötzlich weg,
aber im Moment bleibt es hartnäckig präsent. Der beteiligte Code:
1
SSD1306_Init (); // initialize the display
2
SSD1306_Clear();
3
SSD1306_UpdateScreen(); // habe ich noch hinzugefügt, bringt aber nichts
A. H. schrieb:> Sicher das kein 1305 verbaut ist? der macht 132 Punkte und würde beim> Clear des 1306 die letzten Spalten nicht löschen.> Stimmt die Pos 0,0?
Hatte jetzt gerade mal Power weggenommen und den Reset Knopf gedrückt.
Jetzt ist alles gecleart. Leider sieht man es dem Chip nicht an, was es
ist. Ist von DIYMore. Werde mal ein Rechteck malen:
SSD1306_DrawRectangle(0, 0, 127, 63, 1);
ergibt das 1. Bild
und
SSD1306_DrawRectangle(2, 2, 129, 63, 1);
das 2. Bild
Lynx schrieb:> Ich hab Module die genau so aussehen - nur ist da ein SH1106 verbaut...
Jetzt, wo Du es sagst, erkenne ich schwach auf dem Rand des Displays
N201102C.
Wahrscheinlich hat die Lib noch ein Clipping der Parameter eingebaut.
Müßte mal in die Source schauen. Sowas tut es auch noch:
SSD1306_DrawRectangle(2, 0, 132, 65, 1);
Aber
SSD1306_DrawRectangle(1, 0, 132, 65, 1);
schneidet vorne die schmale Seite ab.
Gibt es alternative Libraries zu dem Chip?
Das Problem ist noch nicht gelöst (s. Bild)
Ich kann nicht in diesen Bereich hineinmalen.
In der Source wird ein Pixelbuffer von WIDTHxHEIGHT von 128x64
definiert, der mit 0 gefüllt wird.Setze ich in der Lib source die
SSD1306_WIDTH=132, wird der Bereich nicht gecleart (FILL).
Da würde ich am ehesten auf eine falsche Initialisierung tippen. Man
muss nicht unbedingt eine andere Lib nehmen, erstmal den init Code gegen
anderen austauschen, vor allem wenn der für einen andere Controller war.
Ansonsten sind eben die Adafruit_GFX oder andere für Arduino sehr
ausgereift, allerdings in C++.
Offenbar ist da der RAM Puffer versus Display um 2 Pixel verschoben. Das
liegt bestimmt an der Initialisierung des Displays.
Vielleicht magst du mal einen schnelle Gegentest machen:
http://stefanfrings.de/arduino_oled/index.html
Wenn es damit geht kannst du die Initialisierungs-Sequenz der beiden
Quelltexte vergleichen.
Nachtrag: Mach mal 2,2kΩ Pull-Up Widerstände an SCL und SDA. Die
Widerstände auf meinem Display sind arg hochohmig. Deine vielleicht
auch.
gelöscht schrieb:> Christoph K. schrieb:>> wird der Bereich nicht gecleart>> Ist dein Problem jetzt geeatet?
Nee, noch nicht gegessen. Bin im
Moment fern von meinem Schreibtisch. Vielleicht komme ich heute abend
noch dazu oder sonst morgen. Danke.
Christoph K. schrieb:> Auf dem Display (s. Bild) sieht man am rechten Rand so ein Gegrissel,
Sowas hatte ich am Arduino, kurz bevor mir der Kram wegen Mangel an
freiem RAM komplett abgeflogen ist.
Dann liegt es wohl wirklich daran, dass dein Display einen anderen Chip
hat.
Da ich nur SSD1306 Displays habe wäre ich dir dankbar, wenn du an deinem
Display etwas für mich ausprobieren würdest:
Ändere:
1
OLEDdisplay(Wire,0x3C,NO_RESET_PIN,128,64);
auf:
1
OLEDdisplay(Wire,0x3C,NO_RESET_PIN,128,64,true);
Wenn das bei dir klappt, lässt sich deine nicht funktionierende
Bibliothek wahrscheinlich schnell anpassen. Du kannst in meinem Code
sehen, dass nur wenige Zeilen beim SH1106 anders sind.
Unter anderen beeinflusst das, an welche Position der Pufferspeicher für
jede Zeile in das RAM des Displays kopiert wird. Das klingt doch
verdächtig, oder?
Christoph K. schrieb:> Das Problem ist noch nicht gelöst (s. Bild)> Ich kann nicht in diesen Bereich hineinmalen.> In der Source wird ein Pixelbuffer von WIDTHxHEIGHT von 128x64> definiert, der mit 0 gefüllt wird.Setze ich in der Lib source die> SSD1306_WIDTH=132, wird der Bereich nicht gecleart (FILL).
Kann ja auch nicht. In der LIB wird diese 132Pixel Sonderfall garnicht
behandelt. Hängt aich mit der Drehung des Display im Portrait oder
Landsape-Mode zusammen. Da werden die üblichen 64x128, 128x64, usw.
aufgeführt und die switch case Strukturen wuseln dann da hin, aber 132
wird schlicht nicht breücksichtigt.
Ich hatte leider den Fall, ein OLED bestellt zu bekommen und das war am
ENde kein 128x64, sondern ein 64x128. Da musste ich auch in der LIB
händisch eingreifen und bei der Gelegenheit sämtliche "I2C/SPI-Abfragen"
rausschmeissen, weil ich kein SPI brauchte, dass den Treiber aber derart
aufgebläht hatte, dass es in den 32U4 nicht mehr reinpasste. Ist eh ein
Whansinn, was der Treiber(LIB), den man hier oft sieht, sich an Extras
gönnt und wie das alles kompliziert mit dieversen h-Dateien
hinzugebastelt wurde, nur damit das universell betrieben werden kann.
Leider muss ich jetzt den branch extra Pflegen, bzw. darf da nicht mehr
ran, weil sonst die anderen Projekte nicht mehr laufen. KlasseSache,
echt - man wird schnell fertig, wenn man kleine Dinge zu erledigen hat.
Aber wehe, es tanzt mal was aus der Reihe, muss man sich gefühlt für
jedes "Projekt" einen eigenen Rechner anschaffen, um die ganzen
Bibliotheken auseinanderhalten zu können. 😂
ich gehe mal fest von einer Aruino-Umgebung aus, oder?
Axel R. schrieb:> Christoph K. schrieb:>> Das Problem ist noch nicht gelöst (s. Bild)>> Ich kann nicht in diesen Bereich hineinmalen.>> In der Source wird ein Pixelbuffer von WIDTHxHEIGHT von 128x64>> definiert, der mit 0 gefüllt wird.Setze ich in der Lib source die>> SSD1306_WIDTH=132, wird der Bereich nicht gecleart (FILL).> Kann ja auch nicht. In der LIB wird diese 132Pixel Sonderfall garnicht>...>> ich gehe mal fest von einer Aruino-Umgebung aus, oder?
Nein, Arduino hatte ich nur für den Schnelltest hinzugezogen. Target ist
aber STM32F103C8T6 unter STM32CubeIDE.
Christoph K. schrieb:> aber immer noch um ca. 2 Pixel nach links verschoben
Hmm, schade. Ein passendes Datenblatt vom Display (nicht vom COG) wäre
jetzt nicht schlecht, wo die Parameter zur Initialisierung und
Speicherzuordnung angegeben wären.
Steve van de Grens schrieb:> Christoph K. schrieb:>> aber immer noch um ca. 2 Pixel nach links verschoben>> Hmm, schade. Ein passendes Datenblatt vom Display (nicht vom COG) wäre> jetzt nicht schlecht, wo die Parameter zur Initialisierung und> Speicherzuordnung angegeben wären.
Datenblatt konnte ich noch nicht auftreiben. Habe noch ein zweites
Exemplar getestet, um auszuschließen, daß es ein Fehler im Teil selbst
ist. Gleicher Effekt. Es ist auch so, daß beim scrollenden
unterstrichenen Hello World-Beispiel der Unterstrich und die untere
Pixelzeile des "Hello" nicht mitscrollen.
Es handelt sich mit ziemlicher Sicherheit um dieses Bauteil:
https://www.diymore.cc/collections/led-display-module/products/diymore-1-3-inch-oled-lcd-display-module-4pin-iic-i2c-interface-ssh1106-128-64-128-64-for-arduino-raspberry-pi-3-3v-5v?variant=14648256561210
Ob man von denen ein Datenblatt kriegt?
2,2K Pullup an SDA und SCL haben nichts verändert.
Und noch etwas: wenn das Ding als 128x64 beschrieben wird, warum sollte
es 132 pixel in X haben?
Auf der Produktseite steht, es sei ein SH1106 verarbeitet. Dazu findet
man ein Datenblatt.
Christoph K. schrieb:> Auf der Produktseite steht, es sei ein SH1106 verarbeitet. Dazu findet> man ein Datenblatt.
Das alleine reicht aber nicht, weil man auch wissen müsste, wie das
Display an den Controller angeschlossen ist. Das kann man ja von außen
durch angucken nicht herausfinden.
Ich hänge mal als Beispiel eins an, da wird es ab Seite 20 interessant.
SO etwas bräuchtest du für dein Display.
Stefan F. schrieb:> Christoph K. schrieb:>> Auf der Produktseite steht, es sei ein SH1106 verarbeitet. Dazu findet>> man ein Datenblatt.>> Das alleine reicht aber nicht, weil man auch wissen müsste, wie das> Display an den Controller angeschlossen ist. Das kann man ja von außen> durch angucken nicht herausfinden.>> Ich hänge mal als Beispiel eins an, da wird es ab Seite 20 interessant.> SO etwas bräuchtest du für dein Display.
Das Pendant für den vermeintlich verbauten SH1106 wäre dann:
https://www.velleman.eu/downloads/29/infosheets/sh1106_datasheet.pdf
Nur entzieht es sich im Moment meiner Kenntnis, daraus
Programmierinformationen für eine Library zu destillieren.
Übrigens wird im letztgenannten Dokument immer von 8080 und 6800 ports
geredet. Das sind doch längst verjährte µPs? Oder sind da immer noch
sowas wie 8255 oder 6821 auf den Chips?
Christoph K. schrieb:> Das Pendant für den vermeintlich verbauten SH1106 wäre dann:> https://www.velleman.eu/downloads/29/infosheets/sh1106_datasheet.pdf
Eben nicht, das ist das Datenblatt des COG. Es gibt aber viele
unterschiedliche Gläser die man dort unterschiedlich anschließen kann.
Die dazu nötigen konkreten Konfigurationsparameter nennt dieses
Datenblatt nicht (kann es auch nicht, hängt ja vom Display ab).
Christoph K. schrieb:> Übrigens wird im letztgenannten Dokument immer von 8080 und 6800 ports> geredet. Das sind doch längst verjährte µPs?
Das sind zwei Mikroprozessoren mit parallelem Bus, die etwa
unterschiedliche Steuersignale haben. Die Busse der meisten
Mikroprozessoren, die danach auf den Markt kamen, waren an einen der
beiden angelehnt.
Habe festgestellt, daß bereits der Call
SSD1306_Init ();
zum Löschen des Displays führt und dabei genau zwei Pixelspalten mit
Randomdaten stehenbleiben. Der darauffolgende
SSD1306_Clear();
hat keine Wirkung.
Axel R. schrieb:> vielleicht hilft das weiter> Beitrag "128 x 64 SH1107 OLED mit eingeschränktem Sichtfeld"
Danke für den Tipp. Ich versuche das gerade nachzustellen. Habe einen
Arduino Nano angeschlossen. Das Testprogramm von Stefanus läuft gerade
drauf, mit eben den besagten Displayfehlern. Könntest Du mir noch die
weiteren "Zutaten" nennen? Welche Arduino lib (AdaFruitGFX)? Wie sieht
Dein Testprogramm aus?
Kann noch Folgendes hinzufügen: Ein Beispiel aus der AdaFruit SH110X
Library (auf Arduino Nano), sh1106_128x64_i2c.ino, läuft aus dem Stand
ohne irgendwelchen Versatz oder falschen Pixeln oder sonstigen falschen
Ergebnissen mit meinem DIY OLED Display 1.3" 128x64.
Wie kriege ich das jetzt transformiert nach STM32CubeIDE und STM32F103 ?
Habe versucht, den Teil der Init in meine ssd1306 Init hineinzuziehen.
Es gibt noch eine Variable, die unbekannt ist, nämlich vccstate. Dies
ist eine Variable in der SH1106 Init Funktion, die markiert, ob der Chip
eine externe Vcc hat. Wie soll ich da verfahren. Einfach ignorieren?
Christoph K. schrieb:> Habe versucht, den Teil der Init in meine ssd1306 Init> hineinzuziehen.> Es gibt noch eine Variable, die unbekannt ist, nämlich vccstate. Dies> ist eine Variable in der SH1106 Init Funktion, die markiert, ob der Chip> eine externe Vcc hat. Wie soll ich da verfahren. Einfach ignorieren?
Schau nach, welchen Wert die Variable im Lauffähigen System hat.
Notfalls mit einer printf Ausgabe.
Wahrscheinlich benutzt dein Display die Ladepumpe, also keine externe
Versorgung. Oder legst du da irgendwo noch eine zweite Spannung >5V an?
Die beiden Kontrastwerte unterhalb von "SETCONTRAST" kommen mir recht
hoch vor. Im Sinne der Lebensdauer würde mit mit kleinen Werten (z.B.
0x20) starten und nur höher gehen, wenn es wirklich nötig ist.
Warum jetzt plötzlich das Thema "Kontrast/VCC"?
Das Display zeigt doch ansonsten korrekt und lesbar an!
Es gibt überhaupt keinen Grund für so einen Nebenkriegsschauplatz.
Ich würde mal in die "clear"-Routine schauen, ob die
a) "genug" 0-Bytes schreibt oder
b) eine LCD-Interne Löchfunktion verwendet (die nicht immer perfekt
greift)
Ich hatte mal so einen Effekt, das lag an a), allerdings mit eigenen
Routinen denn ich nutze niemals irgendwelche "Libs".
Peter Z. schrieb:> Hast du die Init aus deiner AdaFruit Library> "sh1106_128x64_i2c.ino" schon auf dem STM ausprobiert?> (C-Quelltext)> Bei mir funktioniert diese Init am STM32F072
Ich habe das mal mit meinem Code verglichen, der bei mir funktioniert,
aber beim TO nicht. Habe nur zwei Unterschiede gefunden:
Adafruit:
> SH1106_command(SH1106_SETPRECHARGE); // 0xd9> if (vccstate == SH1106_EXTERNALVCC)> { SH1106_command(0x22); }> else> { SH1106_command(0xF1); }> SH1106_command(SH1106_SETVCOMDETECT); // 0xDB> SH1106_command(0x40);
Mein Code:
> i2c.write(0xD9); // pre-charge period> i2c.write(0x22);> i2c.write(0xDB); // set vcomh deselect level> i2c.write(0x20);
Kommando D9 ist Beschrieben als: "This command is used to set the
duration of the pre-charge period. The interval is counted in number of
DCLK, where RESET equals 2 DCLKs." Ich habe keine Ahnung was das
bewirkt. Auffällig ist, dass das Datenblatt von Allvision den rot
markierten Wert früher mal anders hatte. Der chinesische Text heißt
übersetzt "Register (0xD9) Parameter 0x1F auf 0xF1 geändert".
Kommand0 DB ist Beschrieben als: "This command adjusts the VCOMH
regulator output." Ich wage ich zu behaupten, dass es keine Rolle für
das aktuelle Problem spielt. Hier empfiehlt das Datenblatt abweichend
den Wert 0x30.
Hermann Kokoschka schrieb:> Warum jetzt plötzlich das Thema "Kontrast/VCC"?> Das Display zeigt doch ansonsten korrekt und lesbar an!> Es gibt überhaupt keinen Grund für so einen Nebenkriegsschauplatz.>> Ich würde mal in die "clear"-Routine schauen, ob die> a) "genug" 0-Bytes schreibt oder> b) eine LCD-Interne Löchfunktion verwendet (die nicht immer perfekt> greift)>> Ich hatte mal so einen Effekt, das lag an a), allerdings mit eigenen> Routinen denn ich nutze niemals irgendwelche "Libs".
1) es sind noch mehr Stellen, wo abhängig vom vccstate unterschiedliche
Commands geschrieben werden, nicht nur contrast.
2) da ist noch die Sache mit dem Offset, um den der Nullpunkt verschoben
ist.
Ich poste gleich mal die Sequenz, die geht (aber mit dem Offsetfehler
und den random bits) und die neue (SH1106), die nicht geht.
Ich habe einen vielversprechenden Unterschied zwischen meinem Code (der
den Versatz hat) und
https://github.com/lorneb/Adafruit_SH1106/blob/master/Adafruit_SH1106_STM32.h
gefunden. Siehe den TODO Marker im Anhang (den habe ich gerade
eingefügt).
Ich habe mit Google beide Varianten (0x00 und 0x02) mehrmals gefunden.
Scheint hardware-abhängig zu sein.
Das könnte des Rätsels Lösung sein.
Beide Deiner Sequenzen funktionieren derart, daß sie zwar das Display
anschalten und meine Malerei erscheint, aber beide zeigen das
"Gegrissel".
Die zweite Sequenz stelle das Bild auf den Kopf.'tschuldigung für die
Bilderflut. Hochladen war zu langsam, sodaß ich zuviel abgschickt habe.
Stefan F. schrieb:> Ich habe einen vielversprechenden Unterschied zwischen meinem Code (der> den Versatz hat) und> https://github.com/lorneb/Adafruit_SH1106/blob/master/Adafruit_SH1106_STM32.h> gefunden. Siehe den TODO Marker im Anhang (den habe ich gerade> eingefügt).>> Ich habe mit Google beide Varianten (0x00 und 0x02) mehrmals gefunden.> Scheint hardware-abhängig zu sein.>> Das könnte des Rätsels Lösung sein.
Ich sehe nur in meiner Sequenz nicht die Stelle, wo ich eine 00
testweise in eine 02 ändern könnte:
1
#undef SH1106_128_64
2
#ifndef SH1106_128_64 /* Init LCD */
3
SSD1306_WRITECOMMAND(0xAE); //display off
4
SSD1306_WRITECOMMAND(0xD5); //--set display clock divide ratio/oscillator frequency
Du bist immer noch bei der Initialisierung.
Schau in die Prozedur, welche die Daten in den Speicher des Displays
überträgt. Bei mir und bei Adafruit heißt die display().
Das erste Byte ist 0xB0 + Pagenummer, die beiden Bytes danach sind die
spannenden, danach kommen die eigentlichen Nutzdaten.
> Die zweite Sequenz stelle das Bild auf den Kopf
1) Das IST ja beabsichtigt damit ich die Einbaulage wählen kann.
2) Lies mal den Beitrag von stefanus von vorhin!
3) Mach mal die I2C-Taktrate sehr langsam UND lege zwischen allen
INIT-Bytes
eine Timing-Pause ein, teils benötigen die Kommandos etwas Zeit.
Korrekturvorschlag in dem Code aus dem Link im Eröffnungsbeitrag.
Ich finde ziemlich beschissen dass diese Bibliothek offenbar schon für
den SH1106 modifiziert wurde, aber im Quelltext immer noch überall
SSD1306 steht.
Das erkenne ich daran, dass hier 3 Bytes gesendet werden. Beim SD1306
müssten es 4 Bytes sein. Siehe mein vorheriger Screenshot von 18:06.
Christoph K. schrieb:> Ich danke allen.
und wir würden dir Danken wenn du als Letztes mal genau schreibst was du
nun geändert hast, das würde ALLEN mit dem selben Problem helfen ohne
den ganzen Thread noch mal von vorn durchzuarbeiten!
Mit Nennung von deinem Display Link und Type und mit der LIB Name Link
und Änderung.
so blickt doch keiner mehr durch der aktuell nicht daran beteiligt ist!
Hermann Kokoschka schrieb:> Warum jetzt plötzlich das Thema "Kontrast/VCC"?> Das Display zeigt doch ansonsten korrekt und lesbar an!
Ich bin darauf gekommen, weil das die einzigen Unterschiede in der
Initialisierung sind, die mir dort aufgefallen sind. Ich stimme dir zu,
dass wir auf diesem Weg nicht weiter kommen.
Inzwischen wurde die Lösung ja schon ganz woanders gefunden. Das
bestätigt deine Annahme.
Christoph K. schrieb:> Also, noch mal zusammengefaßt:>> Es geht physikalisch um folgendes Bauteil:https://www.diymore.cc/products/diymore-1-3-inch-oled-lcd-display-module-4pin-iic-i2c-interface-ssh1106-128-64-128-64-for-arduino-raspberry-pi-3-3v-5v?variant=14648256561210
Angefangen hatte ich mit folgender oled.zip (dort zum Download
verfügbar),:
https://controllerstech.com/oled-display-using-i2c-stm32/
zu dem Zeitpunkt nicht wissend, daß es sich um ein Bauteil mit einem
SH1106 und nicht SSD1306 handelte. Die Verwendung dieser Library
geschah
unter STM32CubeIDE. Dabei zeigte sich die unvollständige Initialisierung
des Displayinhalts und auch ein Versatz in den Ursprungskoordinaten (um
2 pixel in x).
Lösung von Stefan F. (stefanus):void SSD1306_UpdateScreen(void) {
uint8_t m;
for (m = 0; m < 8; m++) {
SSD1306_WRITECOMMAND(0xB0 + m);
SSD1306_WRITECOMMAND(0x02); //<<<<<<<< von 00 auf 02 ändern
SSD1306_WRITECOMMAND(0x10);
/* Write multi data */
ssd1306_I2C_WriteMulti(SSD1306_I2C_ADDR, 0x40,
&SSD1306_Buffer[SSD1306_WIDTH * m], SSD1306_WIDTH);
}
}
so also korrigiert? (sollte als Abschluß und als Letztes stehen, sonst
übersieht man das wieder!)
J. S. schrieb:> das Ganze hättet ihr wesentlich eher haben können wenn ihr meinen> Kommentar bzw. Link auf den Beitrag von Oli Kraus gelesen hättet.
Zumal ja schon schnell klar war, daß es sich ganz einfach um einen
Offset handeln mußte.
Letztlich aber ein gutes Beispiel, was beim Zusammenklicken von LIBs
herauskommen kann. Eine Woche hat das gedauert :-(
> Und auch ein SSD_DrawRectangle(0,0,127,63,1); sieht vernünftig aus.
Kleine Korrektur:
SSD_DrawRectangle(0,0,**128**,**64**,1);
(Markdown Bold Darstelluung funktioniert hier im Forum zwar in der
mobilen Ansicht, aber nicht im Browser auf Desktops)
Christoph K. schrieb:> Markdown Bold Darstelluung funktioniert ... nicht
Mal geht es, mal nicht. Da scheint ein ungewollter Zufallsgenerator drin
zu stecken.
Lese hier leise mit und gebe mal meinen Senf abseits des
eigentlichen Problems dazu. Die Lib um den Display-Controller
ist ja nicht die schlechteste, zumal man sie nicht unter irgend-
welchen Arduino-IDEs verwenden muss. Ist schon bemerkenswert da
sehr viele Vorschläge sich immer auf Arduino beziehen.
Aber ein paar Kleinigkeiten sind schon "bemerkenswert". Sie
fallen nur nicht ins Gewicht da ja die Anbindung über I2C nicht
besonders hohe Display-Raten zulässt.
Die gezeigte Funktion zeigt zwei "Besonderheiten".
- hier wird ein temporäres Array von 256 Bytes angelegt was
in komplexeren Anwendungen schon mal zu einem Stack-Problem
werden könnte. Ausserdem ist es zu gross da maximal 128 Bytes
plus ein Kommando-Byte (Register-Adressierung) im Buffer
stehen (müssen).
- das Umkopieren des zu schreibenden Buffers in das Ziel-
Array kostet zusätzlich Zeit, was in einer schnellen Display-
Anwendung sicherlich hinderlich wäre. Hier aber wohl nicht da
der I2C-Bus-Verkehr der ausschlaggebende Bremsfaktor ist.
Den Buffer zu vermeiden ist wohl nicht ganz einfach da das
Register-Byte vorangestellt werden muss und dieses in einem
Flow mit den Daten gesendet werden muss. Wäre eventuell
nützlich um das "horse" noch etwas schneller rennen lassen
zu können. Ansonsten natürlich ohne Belang in dieser Anwendung.
meine 2ct, SCNR
mitlesa schrieb:> Ausserdem ist es zu gross da maximal 128 Bytes> plus ein Kommando-Byte (Register-Adressierung) im Buffer> stehen (müssen).
Stimmt. Der Code war offenbar für SSD1306 vorgesehen, bei dem kann man
mehr Bytes am Stück senden.
Steve van de Grens schrieb:> Stimmt. Der Code war offenbar für SSD1306 vorgesehen, bei dem kann man> mehr Bytes am Stück senden.
Sollten wirklich 256 Bytes am Stück gesendet werden dann wäre der
reservierte Buffer um 1 zu klein da das Kommando-Byte (Register-
Adressierung) am Anfang "'rein muss" und dann erst die 256 Bytes
Nutzdaten. Dann schreibt die Funktion irgendwo hin ....
Thread beobachten
Seitenaufteilung abschalten