Das 128 x 64 Pixel 1,3 Zoll OLED I2C Display für Arduino habe ich zwar schon an anderer Stelle, im Rahmen eines Projektes erwähnt, allerdings war dort nicht der Platz, um die vielen kleinen Fußangeln zu beschreiben, die mir dieses Display gelegt hat. Außerdem ist es hilfreicher, wenn all diese Sachen konzentriert und nur auf das Display bezogen in einem Thema zu finden sind.
Zur Einstimmung erstmal ein Foto von dem Display, um das es hier geht:
Das Display habe ich von AZ-Delivery und zwar dieses hier. Achtung, das ist keine Schleichwerbung, ich musste das Teil mit harten Euros bezahlen. Ich verlinke nur deshalb, weil es eine Vielzahl von OLED-Displays gibt und die alle so ihre Spezialitäten haben.
Der Anschluß war recht einfach, weil die Pinbeschriftung bereits alle erforderlichen Informationen enthält. Man muß allerdings wissen, wo die Anschlüsse an den Arduino gehören.
Angeschlossen wird VDO -> +5V, GND -> GND, SCK -> A5, SDA -> A4 am Arduino. Weiters findet man in meinem Post im Thema zu Sensoren und Module (Da ist auch ein Beispielsketch) für den Arduino.
Kommen wir zur Fußangel Nr. 1:
Die OLED-Displays haben einen Treiberchip, derer mehrere im Umlauf sind. Es gibt einmal den SSD1306, für den es eine Adafruit-Library gibt und wir haben den SH1106 Controller-Chip, so wie mein Display.
Man braucht also die richtige Library, sonst hat man nur ganz viele weiße Punkte auf dem Display und könnte meinen, dass das Ding kaputt ist, ist es aber nicht .
Für mein Display, verrät mir AZ-Delivery etwas versteckt auf deren Internetshopseitenblog, braucht es die Lib U8g2 Bibliothek von Oliver Kraus.
Also runtergeladen und in die Arduino IDE eingebunden. Super!
Fußangel 2:
AZ-Delivery gibt als Beispielprogram "Datei" -> "Beispiele" -> "u8g2" -> "full_buffer" -> "GraphicsTest" an.
Ganz davon abgesehen, dass ich das Programm über den Pfad nicht gefunden habe, sondern etwas suchen mußte, wurde ich zuerst von einer sehr beunruhigenden Meldung des Compilers überrascht.
Nämlich:
Der Sketch verwendet 9962 Bytes (32%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1605 Bytes (78%) des dynamischen Speichers, 443 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.
Ich habe das Programm trotzdem hochgeladen und gestartet. Heissa, was flimmerten, flackerten und hopsten tolle Grafilen da herum. Nur, was soll ich damit? Und vor allen Dingen, wo sollte überhaupt noch die eigene Applikation Platz finden, wenn der Speicher bereits mit dem Zeugs für Zappelgrafiken voll ist.
Aber auch dafür hat AZ-Delivery eine Lösung parat. Einfach ein anderes beispielprogramm nehmen, nämlich dann dieses hier: "Datei" -> "Beispiele" -> "U8g2" -> "page_buffer" -> "GraphicsTest"
Ganz ehrlich, der Bringer ist das auch nicht und verflixt ich will kein Videogame auf einer Briefmarke programmieren, sondern schlicht ein paar mehr Messwerte darstellen können.
Nach einigem Herumstochern in den Beispielen bin ich dann auf ein Beispielprogramm gestoßen, das "HelloWorld" heißt und als Library nicht das grafiküberfrachtete Ungetüm vom Oliver Kraus benötigt, sondern als schlanken Fuß dessen U8x8lib.h benötigt. Damit kann man wirklich nur Zeichen ausgeben - wirklich, mehr nicht.
Fußangel 3:
Als Übergabeparameter akzeptiert die "Druckfunktion" der Lib eigentlich nur irgendwelche zeichen, die in Hochkommas sind. z.B. "Test", "123 Testtext" usw.. Versucht man aber eine Zeichenkette in eine Stringvariable zu packen und der Druckfunktion zu übergeben, gibt es eine charmante Fehlermeldung.
Auch bei irgendwelchen Zahlen, egal ob vom Typ Byte, Integer oder Fließkommazahlen, weigert sich die Ausgabefunktion beharrlich. Man bekommt beim kompilieren zwar keine Fehlermeldung, es erscheint aber auch nichts auf dem Display, oder nur irgendetwas Sinnloses.
Um es kurz zu machen, die Lösung des Problems geht nur über ein Datenfeld, in dem der Datentyp char (für character oder Zeichen) gespeichert wird. Ein String ist eigentlich auch nichts Anderes als ein eindimensionales Datenfeld, in dem nur Zeichen gespeichert sind. Damit soll es wohl funktionieren. Es klappt natürlich, das verrate ich bevor ich erzähle wie es geht.
Fußangel 4:
Die Umwandlung von Zahlen in ein Char array ist nun doch nicht mal eben so gemacht. Je nach Zahlentyp muß man andere Wege gehen, manchmal auch Umwege. Am Ende ist aber entscheident, dass man das auf dem Display darstellen kann, was man haben will.
Den Code dafür poste ich noch, komme in diesem Augenblick aber gerade nich da dran .
Edit:
Es geht hier schon weiter, keine Sorge, aber ab und zu muss ich meine Brötchen verdienen und manchmal lässt mir das keine Zeit für was Anderes.
Zur Einstimmung erstmal ein Foto von dem Display, um das es hier geht:
Das Display habe ich von AZ-Delivery und zwar dieses hier. Achtung, das ist keine Schleichwerbung, ich musste das Teil mit harten Euros bezahlen. Ich verlinke nur deshalb, weil es eine Vielzahl von OLED-Displays gibt und die alle so ihre Spezialitäten haben.
Der Anschluß war recht einfach, weil die Pinbeschriftung bereits alle erforderlichen Informationen enthält. Man muß allerdings wissen, wo die Anschlüsse an den Arduino gehören.
Angeschlossen wird VDO -> +5V, GND -> GND, SCK -> A5, SDA -> A4 am Arduino. Weiters findet man in meinem Post im Thema zu Sensoren und Module (Da ist auch ein Beispielsketch) für den Arduino.
Kommen wir zur Fußangel Nr. 1:
Die OLED-Displays haben einen Treiberchip, derer mehrere im Umlauf sind. Es gibt einmal den SSD1306, für den es eine Adafruit-Library gibt und wir haben den SH1106 Controller-Chip, so wie mein Display.
Man braucht also die richtige Library, sonst hat man nur ganz viele weiße Punkte auf dem Display und könnte meinen, dass das Ding kaputt ist, ist es aber nicht .
Für mein Display, verrät mir AZ-Delivery etwas versteckt auf deren Internetshopseitenblog, braucht es die Lib U8g2 Bibliothek von Oliver Kraus.
Also runtergeladen und in die Arduino IDE eingebunden. Super!
Fußangel 2:
AZ-Delivery gibt als Beispielprogram "Datei" -> "Beispiele" -> "u8g2" -> "full_buffer" -> "GraphicsTest" an.
Ganz davon abgesehen, dass ich das Programm über den Pfad nicht gefunden habe, sondern etwas suchen mußte, wurde ich zuerst von einer sehr beunruhigenden Meldung des Compilers überrascht.
Nämlich:
Der Sketch verwendet 9962 Bytes (32%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1605 Bytes (78%) des dynamischen Speichers, 443 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.
Ich habe das Programm trotzdem hochgeladen und gestartet. Heissa, was flimmerten, flackerten und hopsten tolle Grafilen da herum. Nur, was soll ich damit? Und vor allen Dingen, wo sollte überhaupt noch die eigene Applikation Platz finden, wenn der Speicher bereits mit dem Zeugs für Zappelgrafiken voll ist.
Aber auch dafür hat AZ-Delivery eine Lösung parat. Einfach ein anderes beispielprogramm nehmen, nämlich dann dieses hier: "Datei" -> "Beispiele" -> "U8g2" -> "page_buffer" -> "GraphicsTest"
Ganz ehrlich, der Bringer ist das auch nicht und verflixt ich will kein Videogame auf einer Briefmarke programmieren, sondern schlicht ein paar mehr Messwerte darstellen können.
Nach einigem Herumstochern in den Beispielen bin ich dann auf ein Beispielprogramm gestoßen, das "HelloWorld" heißt und als Library nicht das grafiküberfrachtete Ungetüm vom Oliver Kraus benötigt, sondern als schlanken Fuß dessen U8x8lib.h benötigt. Damit kann man wirklich nur Zeichen ausgeben - wirklich, mehr nicht.
Fußangel 3:
Als Übergabeparameter akzeptiert die "Druckfunktion" der Lib eigentlich nur irgendwelche zeichen, die in Hochkommas sind. z.B. "Test", "123 Testtext" usw.. Versucht man aber eine Zeichenkette in eine Stringvariable zu packen und der Druckfunktion zu übergeben, gibt es eine charmante Fehlermeldung.
Auch bei irgendwelchen Zahlen, egal ob vom Typ Byte, Integer oder Fließkommazahlen, weigert sich die Ausgabefunktion beharrlich. Man bekommt beim kompilieren zwar keine Fehlermeldung, es erscheint aber auch nichts auf dem Display, oder nur irgendetwas Sinnloses.
Um es kurz zu machen, die Lösung des Problems geht nur über ein Datenfeld, in dem der Datentyp char (für character oder Zeichen) gespeichert wird. Ein String ist eigentlich auch nichts Anderes als ein eindimensionales Datenfeld, in dem nur Zeichen gespeichert sind. Damit soll es wohl funktionieren. Es klappt natürlich, das verrate ich bevor ich erzähle wie es geht.
Fußangel 4:
Die Umwandlung von Zahlen in ein Char array ist nun doch nicht mal eben so gemacht. Je nach Zahlentyp muß man andere Wege gehen, manchmal auch Umwege. Am Ende ist aber entscheident, dass man das auf dem Display darstellen kann, was man haben will.
Den Code dafür poste ich noch, komme in diesem Augenblick aber gerade nich da dran .
Edit:
Es geht hier schon weiter, keine Sorge, aber ab und zu muss ich meine Brötchen verdienen und manchmal lässt mir das keine Zeit für was Anderes.
Zuletzt bearbeitet: