Wie steuere ich ein OLED Display als OSD am Raspi an

Using the ILI9481 3.5" Color TFT Display with Arduino - Electronics-Lab.com

Displays are one of the best ways to provide feedback to users of a particular device...

www.electronics-lab.com

Ist in Adafruit Libs drin.

Ich konnte damals auch keine fertige Library für das T6963C nutzen. Von daher gehe ich fest davon aus das ich das Protokoll dann "zu Fuß" implementieren muss.

Problem ist, dass der Arduino selber nicht genügend Speicher hat um das Bild zu speichern. Man muss also die einkommenden Befehle mehr oder weniger "in Echtzeit" auf dem Display anwenden um den Speicher im Display ausnutzen zu können.

Wenn man es hinbekommt das der zweite HDMI ein Framebuffer bereitstellt, dann ja. Graphlcd kann auf Framebuffer ausgeben.

Hi,

fbtft/fb_ili9806.c at master · birdtechstep/fbtft

fbtft, volumio, rpi. Contribute to birdtechstep/fbtft development by creating an account on GitHub.

github.com

Ist ein Framebuffertreiber für das ili9806e.

Hier wurde der Adafruit auf ESP32 und 8266 zum Laufen gebracht

Quote from SurfaceCleanerZ

Gibt auch 4". Hab mir gerade eins bestellt für 14 bei Ali. ST7796S.

https://m.de.aliexpress.com/it…J3sv&gatewayAdapt=glo2deu

Klingt sehr interessant. Hast du schon erste Gehversuche unternommen?

graphlcd-base unterstützt seit einer Weile zwei Typen von Displays am RaspberryPi über SPI:

- farbiges TFT mit ILI9341 Controller, z.B. das hier https://www.adafruit.com/product/1480, welches ich selbst seit Jahren im Einsatz habe.

- zweifarbige OLEDs mit SSD1306 Controller, z.B. das hier https://www.adafruit.com/product/661

Beide Treiber benutzen die WiringPi library als Basis. Mit etwas Programmierkenntnissen und dem Datenblatt des Controllers ließen sich andere Displays sicher ähnlich leicht anbinden.

MfG

Andreas

Hallo Andreas, das klingt ja sehr interessant. Ich habe noch nicht weiter gemacht, da ich am SSD1309 schon fast gescheitert bin am Teensy 3.2. Das dritte war heil und funktioniert jetzt am Teleskop.

Das größte bestellte war natürlich Müll weil ohne Controller, haha. Die anderen beiden liegen hier. Ich vermute, die sind alle ähnlich anzusteuern. Nur Reset scheinen die größeren zu brauchen. SSD1306 läuft ohne...

Mit programmieren bin ich raus!

Ixh will die aber am PC betreiben, nicht am Pi. Also via ESP32 oder 8266.

MfG Stefan

Der ESP ist definitiv nicht der optimale Controller dafür. Wenn die Displays 3,3V Logik haben, dann wäre vielleicht der Raspberry Pico ein interessanter Kandidat.

Oder so, normaler RasPi ist definitiv zu teuer dafür.

Mal ne blöde Frage:

Könnte graphlcd mit E-Ink-Displays zusammen verwenden werden?

Meine Frage bezieht sich auf die E-Ink-Technik generell, die ist ja nicht besonders schnell. Treiber wäre ein anderes Thema.

Inzwischen gibt es ja einige nette mehrfarbige (s/w+ eine Farbe) E-Ink-Displays zu erschwinglichen Preisen.

Sowas könnte ich mir ganz nett im VDR vorstellen.

- Anzeige des nächsten Timers/-Konflikts bei abgeschaltetem Rechner.

- Auch ohne Beleuchtung gut ablesbar. Das spart Strom und vor allem das penetrante Leuchten, die Beleuchtung ist mir eh oft zu hell oder zu dunkel.

Bei den Dingern ist eher Verschleiß ein Problem. Und da kann dann schon sowas wie ein ständig scrollender Text reichen. Bei einem Bekannten haben wir mal sowas im Dauerbetrieb getestet. Nach zwei Wochen war das Display hin.

Quote from Dumpfbacke

Haben ja mittlerweile auch alle Supermärkte als Preisschilder. Auf Geschwindigkeit kommt es da ja nicht an, außer man möchte Videos auf dem Minidisplay abspielen.

Für stehende Informationen sind die Displays top.

Die Update-Zeit, in der nur so ein "grauer Matsch" dargestellt wird, liegt laut Datenblatt aber bei 0,6 Sekunden. Das ist im Computer-Bereich schon extremst lange.

Selbst bei einer Uhr mit Sekunden-Anzeige wird das schon knapp.

Man müsst die Updates wirklich auf das nötige Minimum reduzieren.

Also Kanalwechsel, Wiedergabe, Wechsel der Minute bei der Uhr, ...

Ich kann momentan nicht abschätzen, ob dann graphlcd sinnvoll funktioniert, oder nicht. Daher auch die Nachfrage.

Quote from Dumpfbacke

Aber ob man da Treiber für ein einzelnes Display bekommt?

Für die Displays, die mir Aufgefallen sind ("DEBO EPA xxx" bei Reichelt), gibt es Datenblätter und Beispieltreiber. Unter anderem für den RaspberryPi und Arduino µCs.

Auf der Basis halte ich das für machbar, auch zeitlich. Ob die Software für mehr als als Beispiel taugt, muss man sehen, aber man hat zumindest alle Informationen, die man benötigt.

Quote from M-Reimer

Bei den Dingern ist eher Verschleiß ein Problem. Und da kann dann schon sowas wie ein ständig scrollender Text reichen. Bei einem Bekannten haben wir mal sowas im Dauerbetrieb getestet. Nach zwei Wochen war das Display hin.

Interessant, das Thema hatte ich noch nicht auf dem Schirm. Dazu steht auch nicht wirklich was im Datenblatt.

Wie sieht es denn mit einem Update pro Minute aus? Meinst du das macht das Display mit?

Da scrollende Texte sind eh nicht so mein Ding sind, könnte man graphlcd denn entsprechend konfigurieren?

Ich hatte bislang nur Text-Displays und mir graphlcd noch nicht näher angesehen.

Dort hat man keine Bedenken bezüglich Haltbarkeit:

Lebensdauer e-Ink Display

Vielleicht hatte ich auch nur ein "Montagsdisplay" erwischt...

Auf jeden Fall lästig ist, dass man ein E-Ink bei jedem Update komplett weiß schalten muss. Sonst gibt es Ghosting. Das Flackern könnte dann auf Dauer doch nerven.

Aber ich würde schon meinen das sowas mit graphlcd gehen würde. Auch das Weißschalten könnte man in graphlcd-base automatisieren.

Hi,

Das scrollen der Texte lässt sich abschalten.

MfG Stefan

Quote from M-Reimer

Lebensdauer e-Ink Display

Interessanter Link.

Besonders dieser Link im Link: Digitaler Bilderrahmen, ePaper, Batteriebetrieb, portabel

Da gibt es einige interessante Informationen:

- Die AVR-Treiber sind nicht direkt nutzbar, das sie µC während des Updates blockieren.

(Das hatte ich wegen der vielen "busywait" im Code aber irgendwie schon befürchtet .)

Quote from M-Reimer

Auf jeden Fall lästig ist, dass man ein E-Ink bei jedem Update komplett weiß schalten muss. Sonst gibt es Ghosting. Das Flackern könnte dann auf Dauer doch nerven.

Wenn ich die Beschreibung im Link richtig interpretiere, ist es bei S/W-Modell möglich auch einzelne Pixel umzuschalten. Ob das auf Dauer zu Ghosting führt muss man wohl probieren.

Im Bereich der Uhr z.B. könnte man etwas Ghosting auch eine Weile tolerieren, wenn man dadurch das Flackern reduziert. Das volle Update kommt dann beim nächsten Sendungswechsel.

Bei den Displays mit Farbe muss man aber bei jedem Update immer über komplett Weiss gehen.

Das S/W-Modell hätte da also einen Vorteil.

Andererseits hätte so ein roter Punkt als Aufnahmekennung oder ein roter Hintergrund bei einem Timerkonflikt echt was...

Quote from M-Reimer

Aber ich würde schon meinen das sowas mit graphlcd gehen würde. Auch das Weißschalten könnte man in graphlcd-base automatisieren.

Beim S/W-Display könnte man das vielleicht auch den µC, automatisch vor jedem grösseren Update, erledigen lassen. Und irgendeinen AVR oder dergleichen mit etwas Software wird man wohl brauchen, um das Display sinnvoll am USB betreiben zu können.

Im Endeffekt wird man aber wohl trotzdem an graphlcd-base ran müssen, wenn es optimal laufen soll.

Mal sehen, vielleicht hole ich mir mal so ein kleines, billiges E-Ink-Display zum probieren. Dann sieht man, ob es Sinn hat das weiter zu verfolgen, oder nicht.

Quote from cinfo

für ausgewählte Info´s vom VDR nutze ich das hier zum Anzeigen mit z.B. PicoMQTT (Mosquitto)

https://plantprogrammer.de/mqt…m-raspberry-pi-mosquitto/

warum nicht per Netzwerk an ein Display die Info´s senden ? --> fertige Anzeige incl. scrollen der Texte

Der Akku im Display kann auch entfernt werden

Quote from cinfo

warum nicht per Netzwerk an ein Display die Info´s senden ? --> fertige Anzeige incl. scrollen der Texte

Der Akku im Display kann auch entfernt werden

Letztlich ist das alles eine Frage der persönlichen Anforderungen.

Für mich wäre auf dieser LED-Anzeige schlicht erheblich zu wenig Platz für Informationen. Deshalb habe ich auch Null Motivation nochmal Treiber für Mini-Displays zu schreiben. Wenn da jemand in Vorleistung geht kann ich gerne beim Testen helfen und wenn Displays in einem erträglichen Preisrahmen sind kaufe ich für solche Tests gerne auch Displays.

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. Aber: Vor den Wintermonaten werde ich nicht dazu kommen. Wenn man das Protokoll mal versteht kann man dann eventuell auch die "Gegenseite" für einen Raspberry Pi Pico nachbauen und so andere farbige TFTs treiben. Man könnte sich so sparen selbst ein Protokoll auszudenken. Mein "usbserlcd"-Protokoll kann nämlich nur für monochrome Displays genutzt werden.