Ich hatte vor einiger Zeit hier schon einmal gefragt, finde aber den
Thread nicht mehr.
Ich habe ein 3-farbiges ePaper-Display mit 400x300 Auflösung, für das
ich eine Grafikbibliothek suche. Angetrieben wird das von einem
STM32F411.
Nach einigen Versuchen mit der HAGL
https://www.appelsiini.net/2020/embedded-graphics-library/ bin ich von
dieser wieder abgekommen, da die Fontunterstützung doch zu primitiv ist.
Die HAGL erlaubt nur monospaced-Fonts und die sehen auf dem Display
alles andere als schön aus. Proportionalschrift und Kerning sollten
schon sein, idealerweise auch nichtlateinische Schriften
(Kyrillisch/Arabisch). Was ich nicht brauche, sind dynamische
GUI-Funktionen, denn die machen auf einem ePaper mit >10s Refreshzeit
schlicht keinen Sinn.
Nun habe ich mir die Alternativen LVGL und emWin (von ST als STEmWin
vertrieben) angeschaut. LVGL scheint ziemlich Speicherhungrig zu sein
und unterstützt anscheinend auch keine 2bpp. 8bpp würden bei meinem
Display bereits 120kB, also nahezu das gesamte RAM belegen.
emWin scheint da besser zu sein, allerdings scheint es sehr an die
eigenen Treiber gebunden, die meinen Controller leider nicht
unterstützen. Allerdings gibt es die Möglichkeit, einen eigenen Treiber
zu schreiben. Der würde einfach nur einen Puffer im RAM beschreiben, der
erst dann, wenn ales fertig ist, via SPI zum Display geschickt wird.
Vielleicht hat dies jemand hier im Forum schon mal getan und weiß, wie
groß der Auwand ist?
Mike schrieb:> LVGL scheint ziemlich Speicherhungrig zu sein> und unterstützt anscheinend auch keine 2bpp.
RAM brauchst du einen Buffer der min. 10 Zeilen mit kompletter Breite *
Pixel groß ist. lvgl kann auch 1bb, es gibt ein Beispiel mit dem
berühmen SSD1306 OLED. Der Trick sind da spezielle Ausgaberoutinen, z.B.
hier:
https://github.com/lvgl/lvgl_esp32_drivers/blob/master/lvgl_tft/ssd1306.c
lvgl auf OLED hat auch schon jemand gebaut, das war wohl sehr aufwändig
weil man den partitiellen Refresh nutzen muss. Dazu gibt es einen langen
Thread im lvgl Forum.
A. B. schrieb:> Du könntest dir wenn du bei ST Controllern bleibst auch TouchGFX> ansehen.> Die folgenden Infos könntest du dir mal zu Gemüte führen.>> https://support.touchgfx.com/4.20/docs/development/scenarios/lowering-memory-usage-with-partial-framebuffer>> https://support.touchgfx.com/4.20/docs/development/scenarios/touchgfx-on-lowcost-hardware>> Fontmäßig werden Sachen wie Kerning unterstützt(ob es da Einschränkungen> gibt kann ich nicht sagen)
Danke für den Tipp. TouchGFX werde ich mir mal anschauen. Partial update
unterstützt mein Display leider nicht, allein schon wegen der
Geschwingkeit (< 0.1 fps) muss ich den kompletten Bildinhalt puffern.
Bei 2bpp sind das 30kB, was kein Problem ist. Dummerweise braucht LVGL
aber pro pixel ein byte, belegt also das Vierfache.
Alle Grafikbibliotheken scheinen eher auf LCD oder OLED ausgerichtet zu
sein und wollen mit schnellen Animationen glänzen. Für ePaper ist das
aber nur unnötiger Ballast
Mike schrieb:> Dummerweise braucht LVGL> aber pro pixel ein byte,
Aber nicht für den gesamten Bildschirminhalt, sondern nur für einen oder
zwei Buffer, die jeweils nur einige Zeilen enthalten.
J. S. schrieb:> RAM brauchst du einen Buffer der min. 10 Zeilen mit kompletter Breite *> Pixel groß ist.
Mit zwei Buffern ist die Idee, dass der eine gerade per DMA
rausgeschoben wird, während die CPU den anderen vorbereitet.
Ich weiß ja nicht was du da anzeigen willst. Wenn es zu lahm ist kommt
es wahrscheinlich zu Tearing. Aber sowas sollte ja nur auffallen wenn
man da schnell viele Pixel ändert was ja eh nicht geht. Aber es klingt
jetzt eher so als ob es da bei den Displays noch paar Besonderheiten
gibt und da kenne ich mich nicht aus
Touchgfx unterstützt 1bpp, 2bpp & 4bpp und im 1bpp Mode wird auch intern
nur 1bit pro Pixel gespeichert...das hatte ich mal angeschaut
STemWin hab ich mal für einen SSD1306 auf einem F103 gebaut.
Das ist recht genügsam, was den Speicherbedarf betrifft.
Den meisten Platz braucht man für die Fonts.
Hier ist der Code:
https://cloud.it-livetalk.de/index.php/s/wZpWsMZ5L42H7Gk
Ist allerdings eher ein proof-of-concept.
dann gibt es noch https://github.com/ZinggJM/GxEPD
kein GUI Zeug, kann aber auch schöne Fonts.
Den Arduino Krempel muss man dann durch eigene Routienen ersetzten.
Εrnst B. schrieb:> Mit zwei Buffern ist die Idee, dass der eine gerade per DMA> rausgeschoben wird, während die CPU den anderen vorbereitet.
ja, für dynamische Sachen. Aber ePaper ist ja dynamisch wie ein Hammer
im Teer, da reicht ein Buffer :)
Ich habe gerade mal STemWin heruntergeladen. Für mein Display wäre der
GUIDRV_BitPlains - Treiber mit 2bits per pixel geeignet, da er die Bits
auf zwei verschiedene Framebuffer aufteilt. Leider scheint der in der
STemWin-Library nicht drin zu sein. Weiß jemand, ob und wie man den
nachinstallieren kann?
Mike schrieb:> Leider scheint der in der> STemWin-Library nicht drin zu sein.
Deckt sich leider mit meiner Erfahrung.
In der ST-Doku ist auch das PNG-API beschrieben - fehlt aber auch in den
von ST bereitgestellten Librarys.
Source gibts prinzipiell von Segger, aber natürlich nicht für lau.
https://www.segger.com/products/user-interface/emwin/
Harry L. schrieb:> In der ST-Doku ist auch das PNG-API beschrieben - fehlt aber auch in den> von ST bereitgestellten Librarys.
Ich hoffe, das zumindest Bitmaps funktionieren, habe das aber noch nicht
ausprobiert.
> Source gibts prinzipiell von Segger, aber natürlich nicht für lau.> https://www.segger.com/products/user-interface/emwin/
Zum Glück ist ein Treiber-Template dabei, so dass ich recht einfach
einen Treiber selbst programmieren konnte.
Dieser schreibt nur in einen Framebuffer, die Übertragung ins Display
und dessen Refresh mache ich dann von Hand, wenn alles fertig gezeichnet
ist. Wenig effizient, aber bei einer Framerate von maximal 1-3fpd
(frames per day) spielt das keine Rolle
Mike schrieb:> Ich hoffe, das zumindest Bitmaps funktionieren, habe das aber noch nicht> ausprobiert.
BMP geht, ebenso wie JPG.
Daß PNG fehlt ist deshalb problematisch, da das das einzige unterstützte
Format mit Alpha-Kanal ist. (Transparenz)
Mike schrieb:> Dieser schreibt nur in einen Framebuffer, die Übertragung ins Display> und dessen Refresh mache ich dann von Hand, wenn alles fertig gezeichnet> ist. Wenig effizient, aber bei einer Framerate von maximal 1-3fpd> (frames per day) spielt das keine Rolle
Naja....kann man natürlich machen.
Ich hab auch einige Klimmzüge machen müssen um ein SSD1306 zu
adaptieren, da die Bitorder von dem Ding bei der ST-Version so nicht
vorgesehen ist.
Aus all den o.g Gründen arbeite ich mich gerade in LVGL ein.
Das scheint mir ein min. ebenbürtiger Ersatz zu sein, und das ist
vollst. OpenSource.
