Hi,
ich habe so ein I2C 0,96" OLED-Display (128x64) vom Chinamann.
Aktuell benutze ich die u8g2-lib von olikraus.
So läuft alles super, nur braucht die lib für den Bildaufbau nahezu 40ms.
Für mein Vorhaben (Laufschrift) ist das etwas zu langsam.
Kennt ihr eine lib, die "schneller" arbeitet? oder sind wir hier schon an der Grenze der technischen Möglichkeiten?
Das ist kein I2C-Problem, sondern ein Problem von vielen Grafikdisplays ohne eigenen Prozessor.
Wenn Du nur Texte und keine Grafiken ausgeben willst, verwende die u8glib.h vom gleichen Autor (ist mit der Lib schon installiert). Die ist dann schneller.
Dann nur die Teile des Displays erneuernlöschen (mit Hintergrundfarbe überschreiben - fillRect), die Du neu beschreiben willst und nicht immer alles neu schreiben.
Gruß Tommy
Jetzt hab ich mal zum Vergleich die "Adafruit_SSD1306.h" getestet:
Ohoh, die ist ja noch um Faktor 3 langsamer.
Da brauch die Ausführung des Befehls "display.display" ja ~120ms.
Egal ob Text, oder Grafik.
Wenn Du nur Texte und keine Grafiken ausgeben willst
Hätte schon noch 2 kleine Grafiken angezeigt 
Dann musst Du entweder mit der "Geschwindigkeit" leben oder Dir ein Display mit eigenem Prozessor (z.B. Nextion) kaufen oder selbst eine schnellere Lib schreiben, wobei ich die Lib von Olikraus schon als gut aufgebaut empfinde.
Wenn Du nur für 1 Display anhand vom Datenblatt des Displays entwickelst, kannst Du allerdings wahrscheinlich schneller werden. Das ist halt ein ziemlicher Aufwand.
Gruß Tommy
Hi,
hab jetzt noch die SSD1306 lib gefunden.
Die schafft einen Bildaufbau viel schneller.
Sieht so aus, als ob die nur das an das Display sendet, was neu geschrieben oder gezeichnet wird.
Bedeutet aber, dass wenn man auf diselbe Stelle schreibt, dann bleibt das "alte" stehen.
Allerdings brauchen Befehle wie Display.clear() auch >30ms.
Aber da hilft dein Trick mit dem gefüllten Rechteck.
Ja, das ist das "kleine Löschen" auf Grafikdisplays.
Gruß Tommy
@hk007: Benutzt du denn HW_I2C? Das Software-emulierte I2C wäre in der Tat etwas langsam.
Ansonsten ist es leider tatsächlich so, dass die interne Arduino I2C Lib hier recht langsam ist. In meiner alten U8glib hatte ich mir noch die Mühe gemacht, die I2C Treiber neu zu implementieren, aber bei der Menge an neuen/unterschiedlichen Boards war das irgendwann nicht mehr zu machen.
Ich hatte also die Wahl: Leute die sich über die Geschwindigkeit beklagen und Leute die sich darüber beklagen, dass ihr XYZ Arduino Board nicht unterstützt wird.
U8g2 setzt ausschließlich auf die Arduino Libs SPI.h und Wire.h auf. Damit ist U8g2 langsam, aber kompatibel mit allen Boards die diese Libs implementiert haben. Somit unterstützt U8g2 alle Boards...
Grüße,
Oliver
Hallo Oliver,
Ist doch gut, wenn deine lib viele Displays/µC-Boards unterstützt.
Bei mir ist sie sogar auf einem esp8266 problemlos gelaufen. 
Wobei ich ehrlich gesagt keine Ahnung habe, ob das I2C dort HW oder SW-emuliert ist.
Aber sicherlich ist auch dort der I2C-Bus der Flaschenhals.
Final bin ich jetzt bei der SSD1306.h gelandet. Nutzt auch wire.h.
Wenn ich es richtig gesehen habe, dann werden bei dieser lib mit .display() nur alle Pixel rausgeschrieben, die mit vorherigen Befehlen aktiv gemacht wurden. Ich muss mich zwar dann um das Löschen des zu beschreibenden Bereiches selber kümmern, aber es geht doch flotter, wenn man nur Displaybereiche höher frequent ändern will.
Ein .clear(), bei dem er alle Pixel löscht, dauert genauso lange wie bei der u8g2.
Na dann, sehr gut!
Oliver