Nachdem ich erfolgreich ein ePaper-Display in Betrieb genommen habe, suche ich eine simple Grafikbibliothek, die sich auf einem STM32 implementieren lässt. Dabei ist nur Statik gefragt d.h. Zeichnen von Linien,Kreisen, Rechtecke etc. und vor allem Text mit unterschiedlichen Größen und Fonts. GUI-Funktionen wie Buttons und Menüs brauche ich nicht. Außerdem soll die Library in ANSI-C geschrieben sein, also kein Python, C++ o.ä. Idealerweise baut mir die Library lediglich das Bild in einem Framebuffer zusammen, den ich dann bei Bedarf händisch aufs Display schicke. Libraries gibt es zwar wie Sand am Meer, aber die meisten haben zu viel Schnickschnack oder setzen eine bestimmte Hardware voraus. Was könnt Ihr mir empfehlen? Beim Suchen bin ich auf HAGL (Hardware Agnostic Graphic Library) gestoßen, die genau das macht, was ich brauche. Allerdings scheint die noch nicht ausgereift zu sein. Die Alternative wäre LVGL, die ist für meine Zwecke aber schon zu aufgebläht.
Na da gibt es nur es doch nur das GDI aus der Lernbetty… Lvgl kann man in der Größe etwas reduzieren durch auskommentieren der fetten Controls, aber so ca. 80 kB flashsize werden es trotzdem.
Charly K. schrieb: > Was könnt Ihr mir empfehlen GEM VDI. Kann alles was du forderst, ohne dass es zu viel kann. Es kann Kreise und Fonts, aber Kreise werden durch Linienstücke angenähert und Fonts sind nur bitmapped, aber immerhin proportional und man kann sie mit Programm auf PC in jeder Grösse vorab berechnen lassen. Kann nur Rechteckclipping, keine Regions, und kann s/w bzw. Graustufen und nicht nur RGB. Es gibt den Source, damit man das rauslöschen kann, was man nicht braucht, um Platz zu schaffen, und es gibt reihenweise Doku und Beispielprogramme.
MaWin schrieb: > GEM VDI. > > Kann alles was du forderst, ohne dass es zu viel kann. Was, das gibt es noch? Damit habe ich 1985 auf dem Atari ST programmiert. Hat damals zumindest alles getan, was es sollte.
Charly K. schrieb: > Beim Suchen bin ich auf HAGL (Hardware > Agnostic Graphic Library) gestoßen, die genau das macht, was ich > brauche. Allerdings scheint die noch nicht ausgereift zu sein. Also erstens: sie macht wohl noch lange nicht das, was du vermutlichst brauchst. Ich hab mir das Zeugs eben mal angesehen und weder eine Funktion zum Ausgeben von Schrift noch Fonts gefunden. Und zweitens: Da stimme ich dir zu, diese HAGL ist noch keineswegs ausgereift. Es finden sich zwar Umwandelfunktionen von RGB565 und RGB888 in die einzelnen Farben und sogar etwas zum Auseinandernehmen von JPG, aber das ist alles nicht wirklich das, was man für einen Mikrocontroller am dringendsten braucht. Offenbar ist das derzeit wichtigste Thema der HAGL, wo welcher Lizenztext in den Quelldateien zu stehen hat. OK, für manche ist sowas am wichtigsten. Warum machst du dir nicht etwas selbst - und zwar eben genau so, wie du es brauchst? Es ist nicht wirklich schwer. Sowas wie das Setzen von einzelnen Pixeln in der gewünschten Farbe ist Basiswissen. OK, bei einem monochromen Display hätte man nur 3 Farben: schwarz, weiß und invertiert. Aber alles andere wie - Flächen füllen - Linien zeichnen - Text ausgeben - Grafiken ausgeben kann darauf aufbauen. Ich hab im Laufe der Zeit hier ja schon einiges gepostet, sowohl Fonts und Zeichenausgabe als auch Grafiken und Grafiken ausgeben. Sowas wie TTF-Schriften oder JPG oder andere am PC übliche Grafikformate sind für kleinere Mikrocontroller schlecht geeignet, weil sie zuviel Platz und Rechenleistung benötigen. Aber es geht dennoch und auch komprimiert, auch das findet man hier in diesem Forum. W.S. p.s. Hier hat ja jemand bereits die Lernbetty erwähnt. Die hatte ein Display mit 4 Graustufen und die Quellen dazu finden sich hier ebenfalls. Ist jetzt zwar schon so etwa 10 Jahre her, aber als Anregung allemal auch noch gut.
W.S. schrieb: > Also erstens: sie macht wohl noch lange nicht das, was du vermutlichst > brauchst. Ich hab mir das Zeugs eben mal angesehen und weder eine > Funktion zum Ausgeben von Schrift noch Fonts gefunden. Doch, hagl_put_text() ist dabei, ebenso gibt es 3 elementare Bitmap-Fonts. Was fehlt, ist die Möglichkeit, Linien dicker als 1 Pixel zu zeichnen sowie Fonts, die höher als 8 Pixel sind. Auf einem 400x300 Display mit 12cm Kantenlänge braucht man da schon gute Augen. Man kann wohl weitere X11-Fonts hinzufügen, leider fehlt dazu jegliche Dokumentation. > Warum machst du dir nicht etwas selbst - und zwar eben genau so, wie du > es brauchst? Es ist nicht wirklich schwer. Sowas wie das Setzen von > einzelnen Pixeln in der gewünschten Farbe ist Basiswissen. OK, bei einem > monochromen Display hätte man nur 3 Farben: schwarz, weiß und > invertiert. Aber alles andere wie > - Flächen füllen > - Linien zeichnen > - Text ausgeben > - Grafiken ausgeben Naja, ich würde ungern das Rad immer wieder neu erfinden und die n-te Implementierung von Bresenham und Co. selbst schreiben. Ich habe die HAGL mal probeweise geholt und werde sie nun als Basis für eine Eigenentwicklung nutzen. Ich musste nur noch die Pixel-Setzfunktion hinzufügen, die sich dank Bit-Banding des STM recht elegant implementieren läßt. Die 3 Farben (Schwarz, Weiß, Rot), die mein Display anzeigen kann, konnte ich einfach durch die Konstanten 0,1 und 2 repräsentieren. Alles ließ sich ohne Fehler und Warnungen kompilieren und tut, was es soll. Ich bin gerade dabei, breitere Linien zu ergänzen. Leider habe ich noch nicht herausgefunden, wie man größere Fonts einbinden kann.
Charly K. schrieb: > Libraries gibt es zwar wie Sand am Meer, aber die meisten haben zu viel > Schnickschnack oder setzen eine bestimmte Hardware voraus. Das liegt wohl daran, dass die Kombination STM32 + genügend Speicher für einen Framebuffer eher Seltenheitswert hat.
Charly K. schrieb: > suche ich eine simple Grafikbibliothek, Da fällt mir spontan die Adafruit GFX ein.
Hatte mal das hier ausprobiert: http://embeddedlightning.com/ugui/ Hat getan, was es sollte :) Gerade mal reingekuckt - das kann auf einem Frame-Buffer arbeiten und selbst muss man nur noch eine Funktion schreiben, die dann den Frame-Buffer auf der Hardware ausgibt.
:
Bearbeitet durch User
Walter T. schrieb: > Das liegt wohl daran, dass die Kombination STM32 + genügend Speicher für > einen Framebuffer eher Seltenheitswert hat. das war doch wohl hoffentlich ironisch gemeint? Bei den größen F7/H7 gibt es schon einige. Und bei den Discovery Boards wird gezeigt wie man schnellen ext. RAM anklemmt. Stefan ⛄ F. schrieb: > Da fällt mir spontan die Adafruit GFX ein. der TO wollte kein C++. Ohne diese Beschränkung wäre das einfach, da gibt es ja auch Libs mit Unterstützung nahezu aller EPD. Ansonsten nochmal zur lvgl: gerade bei Fonts ist die sehr stark, auch Symbole über Images sind einfach einzusetzen. Mittlerweile gibt es auch Decoder für verschiedene Bildformate dafür. Auch Treiberbeispiele für EPD gibt es, der Treiber muss nur den Framebuffer in das Display schaufeln, und diese Routine hat der TO ja schon. Nur für freie Grafik ist nochmal extra Speicher nötig, diese wird in einen extra Canvas gezeichnet.
Mike schrieb: > Leider habe ich noch nicht herausgefunden, wie man größere Fonts > einbinden kann. Dazu hat es hier vor kurzem einen Thread gegeben, inclusive Font-Erstellung. Das sollte aber eigentlich seit rund 10 Jahren kein Problem mehr sein. Manche Leute machen es dennoch immer wieder falsch, indem sie Grafik-Routinen und Fonts miteinander vermengen oder gar (noch schlimmer) das Transportmodell zwischen dem Displaypuffer und dem eigentlichen Display mit den eigentlichen Grafikroutinen vermengen. Da kommt dann etwas dabei heraus, was nur auf genau 1 Anwendungsfall paßt und nicht nachnutzbar ist. So viel zum Thema "Rad neu erfinden". W.S.
> Naja, ich würde ungern das Rad immer wieder neu erfinden und die n-te > Implementierung von Bresenham und Co. selbst schreiben. Eine Stunde Arbeit im Vergleich zu hier tagelang rumlabern? Ja, das klingt nach einem Gewinn. Olaf
W.S. schrieb: > Manche Leute machen es dennoch immer wieder falsch, Ja, alles sind doof, nur du nicht. Jeder hat seine Gründe für das was er tut.
Mike schrieb: > ich würde ungern das Rad immer wieder neu erfinden und die n-te > Implementierung von Bresenham und Co. selbst schreiben Du könntest einfach den Code von Wikipedia kopieren.
J. S. schrieb: > Walter T. schrieb: >> Das liegt wohl daran, dass die Kombination STM32 + genügend Speicher für >> einen Framebuffer eher Seltenheitswert hat. > > das war doch wohl hoffentlich ironisch gemeint? Bei den größen F7/H7 > gibt es schon einige. Und bei den Discovery Boards wird gezeigt wie man > schnellen ext. RAM anklemmt. Ich habe nicht behauptet, dass es das nicht gibt. Ich habe nur behauptet, dass es nicht die Regel ist. Ich habe mir tatsächlich noch nie angeschaut, wie es bei den Discovery-Beispielen gelöst ist. Ich nehme ja an, dass der externe SPI nicht gerade Memory-mapped ist. Schade, dass die 32F429-Discovery (im Vergleich zu den anderen) so teuer sind. Edit: Der externe SRAM scheint doch memory-mapped zu sein.
:
Bearbeitet durch User
Walter T. schrieb: > Edit: Der externe SRAM scheint doch memory-mapped zu sein. SDRAM, ja klar ist der Memory-Mapped, das würde anders überhaupt keinen Sinn machen 🤔 Eventuell hab ich dich aber auch nur falsch verstanden.
:
Bearbeitet durch User
Memory mapped ist er einfacher zu handhaben. Aber es ist nicht die einzige Methode, Speicher einzubinden. Aber zurück zum Thema des Threads: Das 32F429-Discovery ist tatsächlich ein Beispiel mit einem wahlfrei zugreifbaren Framebuffer. Vielleicht muss ich mir in einem zukünftigen Projekt diese Konfiguration mal abschauen.
Waveshare bietet eine Menge EPD an und hat ein umfangreiches Wiki, auch mit Beispielcode für STM32. C, Zeichenfunktionen und verschieden große Fonts sind drin.
Charly K. schrieb: > Nachdem ich erfolgreich ein ePaper-Display in Betrieb genommen habe, > suche ich eine simple Grafikbibliothek, die sich auf einem STM32 > implementieren lässt. Wie wäre es mit emWin? https://www.segger.com/products/user-interface/emwin/ Hier kannst du ein Paket downloaden mit du es recht einfach ausprobieren können solltest: https://www.segger.com/evaluate-our-software/st-microelectronics/
Til S. schrieb: > Wie wäre es mit emWin? Der TO wollte keinen LKW, sondern ein Fahrrad. Möglichst mit aufgepumpten Reifen, aber zum selber anfassen und verstehen. Da bist du ein paar Etagen zu hoch rangegangen. W.S.
W.S. schrieb: > Der TO wollte keinen LKW, sondern ein Fahrrad. Ich hatte es so verstanden, dass der TO schnell ans Ziel kommen wollte. Und da ist der LKW gegenüber dem Fahrrad im Vorteil ;-). Aber es gibt natürlich auch genug andere schicke GUI Lösungen.
Til S. schrieb: > Aber es gibt natürlich auch genug andere schicke GUI Lösungen. Klar, aber der TO wollte eigentlich nur etwas zum Kringels malen. Und das vermutlich für sein E-Ink-Display: Charly K. schrieb: > Dabei ist nur Statik gefragt d.h. Zeichnen von > Linien,Kreisen, Rechtecke etc. und vor allem Text mit unterschiedlichen > Größen und Fonts. Und da sehe ich vor allem bei kleineren Routinen, die obendrein im Quellcode vorliegen, den (hoffentlich) damit verbundenen Lerneffekt. W.S.
Nano-X- ehemals micro- windows: http://microwindows.org/SSNanoXDist.html http://microwindows.org/SSPixil.html http://microwindows.org/ Hat man für verschiedenen "Motosteuerungen" (bspw. Aufzug) benutzt.
EmWin ist hoch skalierbar. Den Schnickschnack mit Widgets kann man weglassen. Insofern ist emWin Fahrrad und Lkw. Just my 2 Cents
oh je, das microwindows sieht ja noch altbackener als Windows 3.0 aus. Und ein Windowsystem auf einem ePaper?
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.