Library für GUI

[Johannes M. (johmel)]

Hallo zusammen,
Ich entwickle ein Mobiles Gerät, welches ein Display als Ausgabe und 
Rotary Encoder und Buttons als Eingabe hat. Das Display ist momentan ein 
standard SSD1306 0.96 Zoll OLED mit 64x128 Pixeln. Das ist aber für die 
zukünftigen Revisionen nicht mehr gut genug und daher will ich ein 2 
Zoll Farbdisplay verwenden. Programmiert wird ein ESP32S3 mit Arduino 
IDE.

Mein Problem ist nun aber, dass ich möglichst schnell eine GUI 
Programmieren sollte, welche wenn möglich unabhängig vom Display ist. 
Und eine passende Library hab ich dafür noch nicht wirklich gefunden. 
Probiert habe ich bereits LVGL, U8G2, EEZ-Studio mit LVGL, Squareline 
Studio mit LVGL, Planet 096 und ein paar kleinere Projekte. Keines davon 
hat mir von der Programmierweise wirklich gepasst, da ich es 
Objektorientiert brauch und die UI sich anpassen soll während der 
Laufzeit mit einer undefinierten Anzahl an ICONs etc. und guten 
Animationen.

Ein Kleines Beispiel ist, dass das Gerät Zusatzmodule unterstützen soll, 
die dann in der GUI je nach Typ des Modules ein anderes ICON haben 
sollen. Die Module sollen dann über das Hauptgerät gesteuert werden über 
die GUI.

Die ganzen Desktop Programme bei denen man die UI mit Drag and Drop 
designed gefallen mir nicht, da man immer exportieren muss, dann im 
Projekt hinzufügen und die Dateien Manuell verändern, dass man es 
hinbekommt, dass die Buttons etc was tun ohne Touch eingabe. Touch ist 
für meine Anwendung allerdings nicht gut geeignet. Und 
Displayspezifische Librarys wie die Adafruit SSD1306 Library in Arduino 
IDE haben den Nachteil, dass die immer nur mit einem oder ein Paar 
wenigen Displays der gleichen Type funktionieren. Und da ich nicht weis 
ob das nächste Display, dass wir aussuchen wirklich das Finale ist, wäre 
es gut wenn man nicht immer alles neu programmieren muss.

Zudem fehlt mir auch noch ein gutes 2 Zoll Farbdisplay, welches nicht 
allzu viele GPIOs braucht. Vorzüglich über I2C oder 3 Wire SPI. Wenn es 
für Arduino IDE da nichts geeignetes gibt, wäre ESP-IDF auch noch ein 
Ausweg, allerdings nur als Notlösung.

Falls jemand von euch andere Erfahrung mit den Tools gemacht hat: Bitte 
auch mitteilen, da es auch ein Benutzerfehler meinerseits sein könnte.

Danke im Voraus für jede Unterstützung!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Johannes M. schrieb:
> Mein Problem ist nun aber, dass ich möglichst schnell eine GUI
> Programmieren sollte, welche wenn möglich unabhängig vom Display ist.
Und am besten auch sonst hardwareunabhängig?

Nimm HTML5 und einen Browser.

[Johannes M. (johmel)]

Der Rest der Hardware ist relativ fix. Also der ESP32S3 wird bleiben.

Und dann vom PC/Laptop/Handy aus bedienen?

Oder meinst du einen Browser am ESP32 direkt und über das Display 
ausgeben? Falls ja welche gibt es da?

[Rene K. (xdraconix)]

Nun ich sag mal so: fertig wird es deine Lösung wahrscheinlich auch 
nicht geben.

Gerade was die dynamischen Inhalte angehen - das sich eine GUI - 
dynamische anpasst - kenne ich soweit nicht aus der MC Welt.

Du wirst nicht ohnehin kommen dies selbst zu schreiben. Wie man eine GUI 
an sich erstellt kannst du dir da von den üblichen abschauen.

Was mich bei solchen Projekten, und da wird ja hier so einige in der 
Richtung angefangen, dann aber immer wieder Frage: Woher weiß / kennt 
der "Master" dann ein Modul und dessen Icons, Animationen, Funktionen, 
GUI Aufbau eines Moduls welches erst ein Jahr später kommt und deren 
Funktion, Spezifikation bis dato noch überhaupt nicht klar ist?! Wie 
löst du das? Ein Grundkonzept muss ja schon da sein.

[J. S. (jojos)]

Also lvgl unterstützt so eine Dynamik schon sehr gut, Nur die Designer 
wie SLS nicht. Zumindest bis etwa vor einem Jahr, da habe ich die letzte 
aktuelle Version benutzt.
Die Widgets können relativ zu einem anderen ausgerichtet werden und 
Größe und Abstände zu einem Ankerpunkt kann man relativ angeben, damit 
passt sich ein Layout schon automatisch an verschiedene Größen an. Dazu 
gibt es noch die Flex und Grid Widgets für einfache Anordnung. Das ist 
auch alles sehr gut dokumentiert.
Mit einem grafischen Editor ist die feine Fummelei schon etwas 
einfacher, den kann man aber nutzen um ein Grundgerüst zu bekommen und 
bearbeitet das dann so das die Positionen nicht absolut gesetzt werden. 
Ich habe auch schon Widgets in C++ Klassen gepackt, das geht auch sehr 
gut um Gruppierungen zu bauen. Freundlicherweise hat lvgl in allen 
Objekten ein user_data Feld in dem man den this Pointer der Instanzen 
unterbringen kann.

Johannes M. schrieb:
> und die Dateien Manuell verändern, dass man es
> hinbekommt, dass die Buttons etc was tun ohne Touch eingabe.

halte ich für unnötig, statt Touchscreen kann man Tasten für die 
Eingaben verwenden. Eigene Input Devices können Events senden, auch da 
ist lvgl extrem flexibel.
Beispiel für Hardware Button:
https://docs.lvgl.io/master/details/main-components/indev.html#hardware-button

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Intelligente Displays von Nextion könnten hier eine passende Alternative 
sein.

[Frank E. (Firma: Q3) (qualidat)]

Sherlock 🕵🏽‍♂️ schrieb:
> Intelligente Displays von Nextion könnten hier eine passende
> Alternative
> sein.

Dem kann ich mich unbedingt anschließen.

Zum Erstellen der Screens, Buttons, Diagramme u.a. Objekte gibts eine 
kostenlose IDE. Das Display agiert nach Upload des Projekts unabhängig 
von der restlichen Geräte-Logik und belastet den ESP32 nicht. Befehle 
werden per RS232/UART hin und her gesendet, hier bietet sich auf dem ESP 
eine SoftSerial an.

https://nextion.tech/

https://www.amazon.de/NX3224K024-Enhanced-Display-320x240-Resistive/dp/B09PLJWDLF

[Frank E. (Firma: Q3) (qualidat)]

Lothar M. schrieb:
> Johannes M. schrieb:
>> Mein Problem ist nun aber, dass ich möglichst schnell eine GUI
>> Programmieren sollte, welche wenn möglich unabhängig vom Display ist.
> Und am besten auch sonst hardwareunabhängig?
>
> Nimm HTML5 und einen Browser.

Mit Verlaub - aber auf einem MC der Größenordnung ESP32 ist das Unsinn. 
In Richtung Raspi u.ä. könnte man darüber nachdenken.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Frank E. schrieb:
> Mit Verlaub - aber auf einem MC der Größenordnung ESP32 ist das Unsinn.

Verstehe ich nicht. Mein erstes HTML Interface zur Statusabfrage und 
Konfiguration habe ich auf einem ATmega644 umgesetzt. Das ist ein 
kleiner Pickel, im Vergleich zum ESP32.

http://stefanfrings.de/net_io/

[Frank E. (Firma: Q3) (qualidat)]

Sherlock 🕵🏽‍♂️ schrieb:
> Frank E. schrieb:
>> Mit Verlaub - aber auf einem MC der Größenordnung ESP32 ist das Unsinn.
>
> Verstehe ich nicht. Meine erste HTML Interface zur Statusabfrage und
> Konfiguration habe ich auf einem ATmega644 umgesetzt. Das ist ein
> kleiner Pickel, im Vergleich zum ESP32.

Es geht m.E. um eine GUI, die auf einem Display am/im Gerät mit ESP32 
laufen soll, nicht extern auf PC/Tablet/Laptop. Also müsste der Browser 
(HTML-Rendering, CSS- und JS-Interpreter u.v.a.) zur Darstellung dieser 
GUI eben auf dem ESP32 laufen - was wohl kaum möglich ist.

Zudem wurde explizit HTML5 erwähnt, sicher in der Absicht, die 
speziellen Objekte (z.B. Canvas, Movie- udn Audioplaer usw.) zu 
empfehlen.

[Christoph db1uq K. (christoph_kessler)]

FTDI hatte vor einigen Jahren eine Software namens EVE für die 
Entwicklung einer graphischen Oberfläche auf Mikrocontrollern:
https://www.mouser.com/pdfDocs/EVEBrochure-2.pdf
https://embeddedgo.github.io/2020/03/27/programming_with_eve.html

[Johannes M. (johmel)]

Vielen Dank schon mal für die Vielen Antworten!

Rene K. schrieb:
> Was mich bei solchen Projekten, und da wird ja hier so einige in der
> Richtung angefangen, dann aber immer wieder Frage: Woher weiß / kennt
> der "Master" dann ein Modul und dessen Icons, Animationen, Funktionen,
> GUI Aufbau eines Moduls welches erst ein Jahr später kommt und deren
> Funktion, Spezifikation bis dato noch überhaupt nicht klar ist?! Wie
> löst du das? Ein Grundkonzept muss ja schon da sein.

Das ist ein guter Punkt! Möglich wäre es aber, dass die einzelnen Module 
die Bilder gespeichert haben und falls das Core Modul das Gerät noch 
nicht kennt wird das Bild zusammen mit den verfügbaren Registern und 
Fähigkeiten geschickt. Oder man macht einfach ein Software Update. Da 
muss ich mir noch was gutes einfallen lassen.

Für die Modulerkennung und die ganze Kommunikation zwischen den Modulen 
müssen wir auch noch ein passendes Protokoll aussuchen. Momentan kommt 
Canbus in Frage. Wirklich andere Hotplugfähige Protokolle mit relativ 
hohen Übertragungsraten hab ich auch noch nicht gefunden. Falls ihr da 
auch noch eine Idee habt würd ich mich darüber auch freuen. Momentan 
haben wir auf den Prototypen noch I2C und einen Hotplug Detect pin. Ist 
hald nicht dafür gedacht und ist alles custom mit Software und nicht 
direkt ein richtiges Protokoll, dass das untersützt.

J. S. schrieb:
> halte ich für unnötig, statt Touchscreen kann man Tasten für die
> Eingaben verwenden. Eigene Input Devices können Events senden, auch da
> ist lvgl extrem flexibel.

Das werd ich mit definitiv anschauen. Welches Programm verwendest du da 
für die UI Programmierung? Werden die von dir erwähnten Sachen von 
Squareline Studio oder EEZ Studio unterstützt?

Squareline hat für mich den großen Nachteil, dass es ein Limit an gratis 
Elementen hat.

Frank E. schrieb:
> Zum Erstellen der Screens, Buttons, Diagramme u.a. Objekte gibts eine
> kostenlose IDE. Das Display agiert nach Upload des Projekts unabhängig
> von der restlichen Geräte-Logik und belastet den ESP32 nicht. Befehle
> werden per RS232/UART hin und her gesendet, hier bietet sich auf dem ESP
> eine SoftSerial an.

Klingt interessant. Vorallem, da dies Displayausgabe über z.B. I2C sehr 
viel Ressourcen braucht, welche ich gerner für andere Dinge verwenden 
würde. Aber soweit ich sehe haben die eigentlich nur 2.4 Zoll und 
größer. Ich habe ein längenlimit von 60mm und breite von max 40mm. Und 
mit dem Rahmen der Displays etc dazu sind die 2 Zoll normal schon so 
groß oder größer.

Was ich bis jetzt gesucht habe ist ein barebone display ohne PCB und 
nichts daran. Nur ein Flexkabel, welches dann auf mein PCB verbunden 
wird.

Christoph db1uq K. schrieb:
> FTDI hatte vor einigen Jahren eine Software namens EVE für die
> Entwicklung einer graphischen Oberfläche auf Mikrocontrollern:

Die sieht aber schon etwas älter aus. Die neueste Version auf deren 
Website die ich finden kann ist von 2017.

Allgemein sollte die GUI Software auch auf Linux Funktionieren, da ich 
kein Windows verwende. Nur im Ausnahmefall.

[Frank E. (Firma: Q3) (qualidat)]

Johannes M. schrieb:
> Frank E. schrieb:
>> Zum Erstellen der Screens, Buttons, Diagramme u.a. Objekte gibts eine
>> kostenlose IDE. Das Display agiert nach Upload des Projekts unabhängig
>> von der restlichen Geräte-Logik und belastet den ESP32 nicht. Befehle
>> werden per RS232/UART hin und her gesendet, hier bietet sich auf dem ESP
>> eine SoftSerial an.
>
> Klingt interessant. Vorallem, da dies Displayausgabe über z.B. I2C sehr
> viel Ressourcen braucht, welche ich gerner für andere Dinge verwenden
> würde. Aber soweit ich sehe haben die eigentlich nur 2.4 Zoll und
> größer. Ich habe ein längenlimit von 60mm und breite von max 40mm. Und
> mit dem Rahmen der Displays etc dazu sind die 2 Zoll normal schon so
> groß oder größer.

Ich möchte nochmal einige Tips zu den Nextion-Displays ausführen, die 
scheinen erstaunlich wenig bekannt zu sein.

- die IDE (nur Windows) ist kostenlos, wird aber gut gepflegt, und kann 
mit allen marktüblichen Display-Versionen (2.4 bis 10 Zoll) umgehen.

- die Displays gibt es jeweils mit resistivem und kapazitivem 
Touchscreen. Hat beides seine Vor- und Nachteile

- man kann komplett offline, d.h. ohne Besitz bzw. Anschluss eines 
Displays arbeiten. In der IDE ist ein Simulator enthalten, der mit der 
Maus bedient werden kann. Ein- und Ausgaben per UART werden ebenfalls 
simuliert.

- so ein Display kann mehrere Screens bzw. Pages enthalten, die jeweils 
eigene Sets von Controls tragen

- man sendet über UART Befehle, um auf eine bestimmte Page zu schalten, 
was optisch ohne Zeitverzug passiert. Kein mühsames "Hinmalen" der 
Controls.

- Ebenfalls über UART-Kommandos kann man Texte, Zahlen sowie Farben und 
den Status von Controls verändern. Alle Ojekte werden über einfache 
Kommandos mit IDs und Parametern angesprochen.

- Es gibt neben den Standards (Page, Button, Checkbox, Radiobutton, 
Slider, Pulldown, Texte usw.) noch Zeigerinstrumente ("Gauge") und 
Diagramme.

- Bilder bzw. eigene Grafiken müssen vorher mit hochgeladen werden, dann 
kann man deren Darstellung ein/ausblenden bzw. wechseln (z.B. 
Darstellung virtuelle LEDs). Live Bilder hochladen oder gar Video geht 
nicht.

- tippt/toucht man ein Element, erhält man per UART eine Info, welches 
Objekt auf welcher Page den Event ausgelöst hat ... der externe 
Controller muss dann darauf reagieren

- in der Firmware ist eine einfache Basic-ähnliche Programmiersprache 
enthalten, so dass das Display z.B. beim Touch auf einen Button auch 
selbstständig (d.h. ohne den Umweg über den externen Controller) 
bestimmte Aktionen ausführen kann, z.B. Page wechseln, parallel zu einem 
Slider Zahlen anzeigen und/oder einfache Berechnungen ausführen

- Das Flashen des Projekts wird entweder mittels USB-Serial-TTL-Wandler 
aus der IDE heraus erledigt oder man kopiert das Projekt auf eine 
(Mikro-) SD-Karte, die Displays haben einen Slot dafür. Beim nächsten 
Start wird das Projekt dann von der Karte in den Flash geladen.

Ach ja, manche der Displays können auch Piepsen. Die Helligkeit des 
Displays kann ebenfalls per Kommando eingestellt werden ...

Die Preise beginnen bei ca. 40,- für die 2.4-Zoll-Version.

[Vanye R. (vanye_rijan)]

> Ich möchte nochmal einige Tips zu den Nextion-Displays ausführen, die
> scheinen erstaunlich wenig bekannt zu sein.

Ich kenne genau dieses nicht, habe aber schon frueher vergleichbares 
genutzt. Das hat fuer den Entwickler Vorteile, aber fuer den Einkaeufer 
nachteile. :-)
Deshalb wirst du sowas nur bei kleinen Stueckzahlen im industriellen 
Bereich finden. Ausserdem hat es den Nachteil das man dann mit dem leben 
muss was angeboten wird.

Man kann sich so eine Grafikoberflaeche komplett selber schreiben. Ist 
natuerlich Arbeit! Und noch schlimmer, ausser Programmierkenntnisse 
braucht man ein gewisses kuenstlerisches Haendchen damit am Ende etwas 
ansehnliches raus kommt.
Sowas ist nicht jedem gegeben!

Man kann sowas wie lvgl verwenden und sich mit den Funktionen abfinden. 
Falls man das nicht schafft, man kann dann auch seine eigenen 
Verbesserungen da einfuegen. Es ist doch kein Problem sich ein eigenes 
Widget zu programmieren. Ich hab z.B auch gerade ein Nixie Widget fuer 
Qt geschrieben und denke gerade ueber VFD oder magisches Auge nach. :-)
Sowas scheint mir der geringste Aufwand zu sein.

Vanye

p.s: Wo ich gerade drueber nachdenke, eigentlich waere so eine 
Nixieanzeige auch cool fuer lvgl, muesste ich mal anpassen. Allerdings 
ist die Bildqualitaet kleiner TFT Display wie man sie meist fuer seine 
Bastelsachen verwenden IMHO etwas zu unterirdisch fuer solche 
Spielchen....

[Andreas S. (bastelmax)]

Könnte man sich auch mal ansehen:
https://4dsystems.com.au/catalog/
Programmierung über C++ und / oder vorhandener Software :
https://4dsystems.com.au/products/workshop5
https://4dsystems.com.au/products/workshop4

[J. S. (jojos)]

Johannes M. schrieb:
> Das werd ich mit definitiv anschauen. Welches Programm verwendest du da
> für die UI Programmierung? Werden die von dir erwähnten Sachen von
> Squareline Studio oder EEZ Studio unterstützt?
>
> Squareline hat für mich den großen Nachteil, dass es ein Limit an gratis
> Elementen hat.

Aktuell (Jahrhundertprojekt) bin ich an einer Heizungssteuerung, den 
Screen wie im Anhang habe ich vor etwa einem Jahr mit SquarlineStudio 
gemacht.
Die Lizenzgeschichte wäre ok für kommerziellen Einsatz, aber für Hobby 
und die wenigen Projekten ist mir das auch zu viel. EEZ gab es da noch 
nicht oder in minimalen Anfängen, das wollte ich mir auch noch ansehen. 
LVGL selber ist ja jetzt auch an einem eigenen Editor dran nach dem sie 
sich von SquareLine abgekoppelt haben, das sieht aber auch noch sehr 
rudimentär aus und vermutlich wollen sie damit auch Geld verdienen wenn 
es weiter gewachsen ist.
Es macht Sinn sich mit den Basics von lvgl zu beschäftigen, das ist sehr 
leistungsfähig. Im Speicher werden Objektbäume aufgebaut, ein Widget aus 
mehreren anderen kann über ein Unterprogramm erzeugt werden und dann 
auch mehrfach in einen Screen eingefügt werden. Bei meinem Beispiel 
konnte ich in SLS nur einen Slider mit den ganzen einzelnen Elemnten 
bauen und das dann mehrfach kopieren, was zu unendlich langem Code 
führt. Wenn etwas an allen Slidern geändert werden soll, muss ich alle 
bis auf einen löschen, den verändern und wieder kopieren. Sowas gefällt 
mir auch nicht.

Bei Nextion ist der Editor kostenlos, dafür sind die Displays relativ 
teuer und die Auswahl ist begrenzt. Die MCUs wie ESP32 oder STM32 (LPC 
u.a. natürlich auch) haben heute soviel Power und schnelles SPI per DMA 
das es kein Problem ist eine Anwendung mit guter Grafik auf einer CPU 
laufen zu lassen. Oder heute auch der RP2040 mit Dual Core.
Habe mit lvgl v6 angefangen und eine Schrittmotorsteuerung damit gebaut, 
ich kann den Screen scrollen und der SM läuft unbeeindruckt weiter (ab 
1:42 im Video):
https://www.youtube.com/watch?v=poZjMwRAcH8

Auf so einem kleinen 2" Display bekommt man nicht viel unter, aber hier 
kann man auch das scrolling nutzen: lvgl zeigt auf dem Display einen 
Fenster aus einem großen 16k x 16k Universum aus, das Fenster kann man 
über diesen Bereich verschieben. Dazu ist dann aber eine schnelle 
Schnittstelle für schnelle Updates nötig, also mindestens SPI.

[Vanye R. (vanye_rijan)]

> Bei Nextion ist der Editor kostenlos, dafür sind die Displays relativ
> teuer und die Auswahl ist begrenzt.

Ein Punkt den man auch noch bedenken sollte, gibt es viele Nutzer von 
"seinem" Display dann hat man wenig Problem mit der Verfuegbarkeit. Denn 
wenn das eigentlich Panel nicht mehr hergestellt wird, dann wird der 
Hersteller des Display schnell einen kompatiblen Ersatz auf die Beine 
stellen.

Andererseits wenn es kaum einer nutzt ist es ploetzlich eingestellt und 
dann steht man mit einer fetten Anwendung da und bekommt keins mehr.

Vanye

[J. S. (jojos)]

Immerhin gibt es die Nextion schon recht lange und die Palette ist 
gewachsen. Aber die Frage ist auch ob es kommerziell oder privat genutzt 
werden soll.
Es gab auch mal eine günstigere chinesische Variante, weiß nicht ob es 
die noch gibt. Nextion mochte nicht das die außerhalb Chinas verkauft 
werden.

[Frank E. (Firma: Q3) (qualidat)]

J. S. schrieb:
> Immerhin gibt es die Nextion schon recht lange und die Palette ist
> gewachsen. Aber die Frage ist auch ob es kommerziell oder privat genutzt
> werden soll.
> Es gab auch mal eine günstigere chinesische Variante, weiß nicht ob es
> die noch gibt. Nextion mochte nicht das die außerhalb Chinas verkauft
> werden.

Mein Amazon-Beispiel auf das preiswerte Display in meinem Post verweist 
garantiert einen Clon. Aber solange die Firmware kompatibel ist, ist mir 
das schnuppe ...

[Johannes M. (johmel)]

Frank E. schrieb:
> Die Preise beginnen bei ca. 40,- für die 2.4-Zoll-Version.

Das ist eben weit aus dem Preisbereich den ich brauche. Für die jetzigen 
Prototypen würde das noch gehen, aber da ich mir vorstellen kann es 
kommerziell zu verkaufen ist das keine gute Lösung. Und später will ich 
auch nicht alles nochmal neu programmieren.

Vanye R. schrieb:
> Ich kenne genau dieses nicht, habe aber schon frueher vergleichbares
> genutzt. Das hat fuer den Entwickler Vorteile, aber fuer den Einkaeufer
> nachteile. :-)

Das ist auch mein Bedenken bei den Nextion displays. Die kosten schon 
mal gleich viel wie die restliche Hardware.

J. S. schrieb:
> Es macht Sinn sich mit den Basics von lvgl zu beschäftigen, das ist sehr
> leistungsfähig.

Das merke ich jetzt auch, wenn ihr da so drüber redet. Werde mir LVGL 
nochmal genauer anschauen. Gibt es da sonst noch was zu beachten? 
Funktioniert LVGL auch von haus aus mit monochromen Displays? Worauf 
muss ich dann bei der GUI erstellung achten? darf alles nur monochrom 
sein oder wandelt LVGL das automatisch um?

Ach ja und ich bin mir noch nicht sicher ob die integrierten Physischen 
Buttons von LVGL für mich so funktionieren. Kann das vielleicht bitte 
nochmal jemand genauer erklären wie das funktioniert? Ich habe meine 
Inputs nämlich über variable Spannungsteiler an einen ADC Input 
angeschlossen und somit quasi einen analog multiplexer um GPIOs zu 
sparen. Also ist der State der Buttons nur über einen Funktionsaufruf 
verfügbar, der die Berechnungen für den ADC macht und das dann mit 
lookups vergleicht.

Also Für das Display wäre für mich ideal, wenn es ein Display wie die 
von Newhaven Display ist. Die brauchen aber soweit ich weis dann einen 
externen constant current LED Driver für das Backlight. Das wäre aber 
auch nicht wirklich ein Problem. Mir ist es lieber das auf der main 
Platine zu haben, anstatt ein viel größeres Display Modul mit 2 cm PCB 
Rand rundum zu haben. Nur weis ich nicht wie viel billiger die in großen 
Stückzahlen werden, denn für einzelne sind auch die relativ teuer. Und 
um das anzufragen muss ich eine Firma haben. Weis das zufällig jemand 
von euch oder kennt ihr noch einen anderen Bildschirmhersteller der für 
große und kleine Stückzahlen direkt produziert?

https://newhavendisplay.com/2-4-inch-ips-tft-without-touchscreen/

[J. S. (jojos)]

Johannes M. schrieb:
> Die brauchen aber soweit ich weis dann einen
> externen constant current LED Driver für das Backlight.

Da reicht bei den kleinen üblicherweise ein Vorwiderstand.
Ich meine so Displays gibt es auch bei TME wo man privat bestellen kann. 
Ansonsten natürlich die Distris wie DigiKey oder Mouser.

> Funktioniert LVGL auch von haus aus mit monochromen Displays?

ja, wobei lvgl erstmal farbig arbeitet. Es gibt Beispiele für monochrom 
Displays, z.B. 
https://github.com/lvgl/lvgl_esp32_drivers/blob/master/lvgl_tft/ssd1306.c
Es gibt mittlerweile auch die Einstellung für BPP=1, vorher musste das 
über einen callback von Farbe auf Monochrom umgerechnet werden. Ob jetzt 
anders/einfacher ist weiß ich nicht.

Johannes M. schrieb:
> Ich habe meine
> Inputs nämlich über variable Spannungsteiler an einen ADC Input
> angeschlossen

Ist auch kein Problem. Ein Input Device ist ein read callback der 
zyklisch aufgerufen wird. In diesem cb können analoge/digitale Eingänge 
gelesen werden und daraus macht man die gewünschen Tastencodes wie z.B. 
links/rechts/Enter/Escape.

[N. M. (mani)]

Johannes M. schrieb:
> Funktioniert LVGL auch von haus aus mit monochromen Displays? Worauf
> muss ich dann bei der GUI erstellung achten?

https://docs.lvgl.io/master/details/main-components/display.html#monochrome

Ausreichend neue Version vorausgesetzt. Keine Ahnung ab wann das drin 
ist.

[Johannes M. (johmel)]

J. S. schrieb:
> Da reicht bei den kleinen üblicherweise ein Vorwiderstand.

Kann man aus den Datasheets der Displays den internen Widerstand normal 
auslesen? In welchem Bereich sind solche Vorwiderstände dann?

Eine Konstantstromquelle mit Transistoren kann ich aber auch drauf 
packen. Die wird sicher weitaus bessere Effizienz haben.

N. M. schrieb:
> Ausreichend neue Version vorausgesetzt. Keine Ahnung ab wann das drin
> ist.

Das habe ich auch schon verwendet, aber da kam nichts heraus, was ich 
direkt auf das Display laden konnte. Ich habe noch manuell eine Funktion 
geschrieben, die schaut ob ein Pixel !=0 ist und dann ist er 1. Das wird 
in eine Bitmap geschrieben und schließlich gesendet. Natürlich absolut 
nicht effizient so und wäre wünschenswert, wenn es direkt über lvgl 
geht.
Aber kann ich dann einfach farbige widgets machen im editor und 
squareline übersetzt das dann automatisch? Denn das manuelle umfärben 
geht mich ein wenig an.