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?
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)
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.