Wie steuere ich ein OLED Display als OSD am Raspi an

Noch ein kleiner Nachtrag zu den E-Ink-Displays:

Es steht doch was zur Lebensdauer in einigen der (leider etwas unübersichtlichen) Datenblättern:

Es werden wohl 5 Jahre und 1.000.000 Updates garantiert.

Des Weiteren habe ich die Empfehlung gefunden zwischen den Updates mindestens 180s zu warten.

Nach dem Update sollte das Modul auch unbedingt in den Sleepmode versetzt, werden da die sonst noch anliegende Spannung das Display schädigen würde.

Mit kontinuierlichen Updates 24/7 im Abstand von 180s käme man übrigens auf etwa 6 Jahre.

Bei 60s noch auf knapp 3 Jahre.

Da muss man also schon etwas aufpassen, aber wenn die Nutzeraktivität einbezieht und das Updateverhalten entsprechend anpasst, sollte es gehen.

Des weiteren sind die "bunten" Displays für diese Anwendung wohl leider raus.

Deren Update-Time liegt mindestens im Bereich von 12-15s. Das scheint, nach meinen Stichproben, alle Modelle zu betreffen.

Die s/w-Typen sind deutlich schneller, mit denen könnte es was werden:

Partitielles Update unter 0,5s und volles Update in 1...3s.

Grössere Displays brauchen übrigens beim vollen Update länger als kleine.

Zitat von M-Reimer

Für mich wäre auf dieser LED-Anzeige schlicht erheblich zu wenig Platz für Informationen.

Das Projekt habe ich natürlich interessiert verfolgt und das Teil sieht auch klasse aus.

Aber im Endeffekt geht es mir genau so. 1x7 Zeichen sind mir einfach zu wenig Platz auf dem Display.

Da würde ich eher wieder eines meiner alten Kassen-VFDs aktivieren. Die haben in etwa die Display-Größe der "mini" Version, aber es sind 2x20 Zeichen möglich. Damit kann man das VDR-Menü gerade so bedienen.

Da seriell laufen die an USB-Adaptern, nur der Stromverbrauch schreckt etwas ab.

Zitat von M-Reimer

Mein aktuelles "Bastel-Ziel" wäre das hier: https://www.amazon.de/dp/B0BCGFWMN8/ Groß genug und kommt bereits fertig aufgebaut.

Also ein klassisches "Fehlt ein Linux-Treiber"-Projekt.

Ist das ein Display mit so einer "USB-Grafikkarte", oder ganz was anderes?

Der USB-Monitor-Standard "display-link" wird von Linux nämlich schon eine Weile direkt unterstützt. Die Displays kann man ganz normal ans Bildschirm verwenden, wenn ich das richtig verstanden habe. Zumindest geht es unter X, ob auch Framebuffer möglich ist weiss ich leider nicht.

Eventuell wäre das ja eine gute Basis für zukünftige Grafik-Displays?

Vielleicht nicht die billigste Lösung, aber man hat Auswahl und muss nicht für jedes Display den Treiber anpassen.

Zitat von SHF

Ist das ein Display mit so einer "USB-Grafikkarte", oder ganz was anderes?

Soweit ich das verstanden habe wird das Display als serieller Port erkannt. Ist also UART. Keine Ahnung wie die das Protokoll dafür umgesetzt haben. Das müsste ich dann noch rausfinden. Es gibt Python-Code zum Ansteuern. Damit würde ich dann auch anfangen mit ersten Versuchen.

Im Prinzip hat aber auch UART viel Potential. Bei usbserlcd ist das Display der limitierende Faktor gewesen. Ich hätte im Prinzip vom PC zum Arduino noch schneller senden können. Ich hoffe man bekommt eine halbwegs brauchbare Bildwiederholrate hin. Ich hatte da mit usbserlcd schon zu kämpfen und die dort genutzten Displays haben weniger Auflösung und nur Schwarz und Weiß. Vermutlich gibt es eine Möglichkeit die Zieladresse zu ändern um nur Änderungen zu senden. Das könnte dann schon etwas bringen.

Auf jeden Fall wird das die Plattform die ich als nächstes auf meiner TODO-Liste habe. Man bekommt die Dinger fertig und ob die Windows-Software Schrott ist, ist mir erstmal total egal. Auf komplette Eigenbauten habe ich keinen Bock mehr. Gefühlt wurde mein usbserlcd nur maximal 5 mal noch von jemandem nachgebaut. Vielleicht erreicht man mit "fertig kaufen" potentiell mehr Nutzer die das dann auch noch einsetzen wollen.

Zitat von SHF

Des weiteren sind die "bunten" Displays für diese Anwendung wohl leider raus.

Deren Update-Time liegt mindestens im Bereich von 12-15s

Falls du zweifarbige eInks meinst (rot, schwarz,weiß), ist das praktisch sehr viel weniger.

Zumindest bei dem 2.9 Zoll296x128px was ich hier habe. Die update Zeit hängt vom Bereich des Displays ab (anteilige Fläche), der neu geschrieben wird, wenn man nur Teile des Displays neu schreibt, braucht man auch nur Bruchteile davon. Bei eine Sekundenzähler, der nur ~10% des Display bereichs neu schreibt merkt man fast keine Verzögerung. Der Riesenvorteil ist ein flimmerfreies Display mit krassem Kontrast und der Inhalt bleibt ohne Strom stehen.

Zitat von M-Reimer

Soweit ich das verstanden habe wird das Display als serieller Port erkannt. Ist also UART.

An sich auch nicht schlecht, aber Framebuffer wäre halt universell als Zweitmonitor, Konsole, ... einsetzbar.

Kleine "display-link" USB-Monitore scheint es aber praktisch nicht zu geben, ich konnte eigentlich nur Dockingstationen finden.

Praktisch alles unter 100€ und 10" scheinen irgendwie Varianten / Clone von deinem verlinkten Display zu sein. Die Preise sind teils aber echt attraktiv und es gibt Massen davon .

Ich suche momentan (anderes Projekt) eher was, wo man ein Terminal darstellen kann, daher leider nichts für mich.

Zitat von M-Reimer

Es gibt Python-Code zum Ansteuern. Damit würde ich dann auch anfangen mit ersten Versuchen.

Den habe ich inzwischen auch gefunden und eine kurzen Blick derauf geworfen.

Von den Displays scheint es unterschiedliche, inkompatible Varianten zu geben.

Zitat von M-Reimer

Bei usbserlcd ist das Display der limitierende Faktor gewesen. Ich hätte im Prinzip vom PC zum Arduino noch schneller senden können. Ich hoffe man bekommt eine halbwegs brauchbare Bildwiederholrate hin. Ich hatte da mit usbserlcd schon zu kämpfen und die dort genutzten Displays haben weniger Auflösung und nur Schwarz und Weiß. Vermutlich gibt es eine Möglichkeit die Zieladresse zu ändern um nur Änderungen zu senden. Das könnte dann schon etwas bringen.

Vermutlich. Bei der Anwendung und Hardware wäre das jedenfalls logisch.

Auf den Displays soll ein 8051er µC verbaut sein (CH552). Der hat zwar praktisch kein RAM, kann aber bis zu 24Mhz takten.

Zwischenspeicher wird man also nicht haben, aber das Teil sollte es eigentlich schaffen die Daten in USB2-Geschwindigkeit ins Display zu schreiben. Es wird also wirklich aufs Display ankommen.

Da das ein Vollfarb-Display ist und die Entwicklung ja voran schreitet, bleibt zu hoffen, dass sich da auch was getan hat. Ich bin jedenfalls gespannt, was da raus kommt.

Wenn das Display richtig gut läuft, könnte man auch sich einfache Framebuffer-Anwendungen vorstellen. So viele Pixel haben die kleinen Displays ja nicht und 5-10 fps reichen für eine Textkonsole.

Wobei ich aktuell überfragt bin, ob man überhaupt im Userspace Framebuffer erstellen kann.

Zitat von wirbel

Falls du zweifarbige eInks meinst (rot, schwarz,weiß), ist das praktisch sehr viel weniger.

Ich meinte die und die 7-farbigen von Waveshare.

Zitat von wirbel

Zumindest bei dem 2.9 Zoll296x128px was ich hier habe. Die update Zeit hängt vom Bereich des Displays ab (anteilige Fläche), der neu geschrieben wird, wenn man nur Teile des Displays neu schreibt, braucht man auch nur Bruchteile davon.

Interessant.

Laut Selection Guide können die mehrfarbingen Displays kein partizielles Update.

Was aber nicht bedeuten muss, dass es nicht geht.

In dem Artikel bei Mikrocontroller.net steht, dass die farbigen Partikel deutlich langsamer sind als die Schwarzen.

Es kann also durchaus sein, schwarz / weiss Änderungen schneller sind.

Und da, soweit ich das sehe, die Controller auf allen E-Papers nahezu identisch sind, sollten partizielle Updates prinzipiell möglich sein.

Vermutlich wird nicht alles sinnvoll funktionieren, besonders bei farbigen Pixeln, aber wenn s/w geht reich das eigentlich. Man wird da aber wohl ausprobieren müssen.

Zitat von SHF

An sich auch nicht schlecht, aber Framebuffer wäre halt universell als Zweitmonitor, Konsole, ... einsetzbar.

Kleine "display-link" USB-Monitore scheint es aber praktisch nicht zu geben, ich konnte eigentlich nur Dockingstationen finden.

Display Link willst du eh nicht. Der Kernel kann nur die USB 2.0 Variante direkt und die wird faktisch schon ewig nicht mehr neu verkauft. Die USB 3.0 Docking Stations mit Display Link brauchen einen proprietären Closed Source Treiber.

Zitat von SHF

Von den Displays scheint es unterschiedliche, inkompatible Varianten zu geben.

Ja, leider. Mich interessiert erstmal nur das Protokoll von dem "großen Display". Die mit kleinerer Diagonale haben wohl ein abweichendes Protokoll. Wenn es stark abweicht wäre da dann ein eigener Treiber in graphlcd-base nötig. Ich selber werde mir aber nur die 5 Zoll Variante kaufen.

Zitat von SHF

Wenn das Display richtig gut läuft, könnte man auch sich einfache Framebuffer-Anwendungen vorstellen. So viele Pixel haben die kleinen Displays ja nicht und 5-10 fps reichen für eine Textkonsole.

Wobei ich aktuell überfragt bin, ob man überhaupt im Userspace Framebuffer erstellen kann.

GitHub - xspager/fuse_fb: Fuse emulation of Linux Framebuffer using Cuse

Fuse emulation of Linux Framebuffer using Cuse. Contribute to xspager/fuse_fb development by creating an account on GitHub.

github.com

Zitat von M-Reimer

Display Link willst du eh nicht. Der Kernel kann nur die USB 2.0 Variante direkt und die wird faktisch schon ewig nicht mehr neu verkauft.

Letztlich hatte ich noch Adapter der USB 2.0 Variante gesehen und das recht günstig.
Problem ist eher, dass es wohl keiner Variante kompakte Displays zu verträglichen Preisen gibt.

Zitat von M-Reimer

Fuse emulation of Linux Framebuffer using Cuse Fuse emulation of Linux Framebuffer using Cuse.

Interessant.

Und natürlich über FUSE, hätte man drauf kommen können, ist ja alles ein Dateisystem unter Linux.

Als ich den Tab gestern schliessen wollte, ist mir dann noch das ins Auge gesprungen:

Zitat

you can just use this project as a module from any Python code to do some simple operations on the display:

• Display custom picture
  
• [...]

This project will act as an abstraction library to handle specific protocols and capabilities of each supported smart screen models in a transparent way for the user. Check simple-program.py as an example.

Ein Blick in das Beispiel-Programm zeigt, dass man wirklich sehr einfach .png Bitmaps auf den Displays darstellen kann. Auch scheint es so möglich zu sein nur Teilbereiche des Displays zu ändern.

Das könnte die Integration in den VDR deutlich vereinfachen. Man müsste sich nur einmal überlegen, wie man die gerenderten Bilder übergibt, vorliegen müssen die ja im Prinzip irgendwie schon. Dann hätte man auch alle Varianten auf einen Schlag unterstützt und müsste sich nicht mit Varianten, Details und Modifikationen seitens des Herstellers rum plagen.

Wenn das mit einigermaßen brauchbarer Geschwindigkeit geht, ist die Basis ist doch interessanter, as ich zuerst dachte.

Dann ist noch was bemerkenswertes am Beispiel-Programm:

Da scheint eine Art Benchmark integriert zu sein. Es werden ein paar Texte und Progressbars geändert und benötigte Zeit ausgegeben.

Das legt den Schluss nahe, dass die Displays wirklich etwas langsam sind. (Ich hoffe ich habe da unrecht.)

Hi,

Dann sollten digitale Bilderrahmen gehen. Die wurden vor 10 Jahren oder länger von ct schon für Anzeigezwecke verwendet (Türschild in Praxis oder so erinnere ich mich.

Die dürften jetzt schon mit Bildern befüllbar sein.

Es gab doch eine Ausgabe als Bilddatei (jpg oder png wenn ich mich recht erinnere, ob farbig keine Ahnung).

MfG Stefan

Zitat von SurfaceCleanerZ

Dann sollten digitale Bilderrahmen gehen. Die wurden vor 10 Jahren oder länger von ct schon für Anzeigezwecke verwendet (Türschild in Praxis oder so erinnere ich mich.

Die dürften jetzt schon mit Bildern befüllbar sein.

Ich erinnere mich dunkel...

Problematisch könnte auch hier wieder Geschwindigkeit / Latenz werden.

Aber im Prinzip auch keine schlechte Idee, wenn es klappt.

M-Reimer hat schon recht, je einfacher man Hardware kommt, desto eher wird es genutzt.

Auf so einige digitale Bilderrahmen habe ich auch zugriff, da könnte man im Winter mal einen Blick drauf werfen, mal sehen...

Zitat von SurfaceCleanerZ

Es gab doch eine Ausgabe als Bilddatei (jpg oder png wenn ich mich recht erinnere, ob farbig keine Ahnung).

Bei einem Farbigen TFT müsste man eigentlich doch über graf-TFT oder dessen Nachfolger osd2html (oder so ähnlich) gehen?

Ich hatte mich mit beidem aber noch nie beschäftigt und allein schon die Beschreibung als "Skin-Plugin" ist etwas verwirrend für mich .

Zitat von SHF

Bei einem Farbigen TFT müsste man eigentlich doch über graf-TFT oder dessen Nachfolger osd2html (oder so ähnlich) gehen?

Nicht unbedingt. Wenn man das will müsste aber in der Tat erstmal jemand einen Framebuffer Treiber für das kleine TFT schreiben.

Graphlcd kann schon länger auch mit farbigen Displays. Es fehlte bisher nur an einfach nutzbarer Hardware dafür.

Hi,

Also ich muss sagen, die Konfiguration von graphtftng via xorg.conf hat mich abgeschreckt.

MfG Stefan

Zitat von M-Reimer

Graphlcd kann schon länger auch mit farbigen Displays.

Oh, das war mir bislang entgangen.

Ich dachte, das wäre immer noch auf 1Bpp beschränkt.

Dann werde ich mir das doch mal näher ansehen müssen...