Ich fürchte zwar, dass es möglicherweise so eine Frage bereits gab, aber ich frage trotzdem mal, weil ich sie nicht gefunden habe. Ich möchte eine relativ simple gui mit entweder einem kleinen garb LCD oder einem simplen oled display zeichnen. Ich wollte zuerst adafruitGFX auf einem esp8266 benutzen, hab aber gehört, dass der stm32 einen grafikbeschleuniger hat. Da hat direkt mein innerer Perfektionist zugeschlagen. Welche stm32 haben den und könnte ich den nicht verwenden um Speicher für die fonts im internen Flash sparen kann? Ich würde gerne freertos und libopencm3 verwenden und weiß nicht, ob ich da stms eigene grafikbibliothek verwenden kann. Oder was beachten muss. Da dieser grafikbeschleuniger wohn auch direkt double buffering unterstützt, wäre es echt toll, wenn die hardware mir das mit den framebuffern komplett abnehmen könnte. Und wie meistens noch die Frage, habt ihr zufällig nen Projekte gesehen, das das bereits macht, oder guides für Teile meines Vorhabens gesehen? Oder habt irr wenigstens Handbücher, die ich konsultieren kann um das selst herauszufinden?
Stefan S. schrieb: > Welche stm32 haben den und könnte ich den nicht verwenden um Speicher > für die fonts im internen Flash sparen kann? Irgendwo muss ja der Font gespeichert werden - was soll denn daran ein Grafikbeschleuniger ändern? Georg
hier gibt es eine GUI Library: https://lvgl.io/ Ist Open Source auf Github, Beispiele für STM32, NXP und ESP findet man auch im Repo vom Autor. Der 'Grafikbeschleuniger' im STM32 ist ein besserer DMA, der kann Offsets im Grafikspeicher berücksichtigen, Formate beim Transfer konvertieren und Alpha Blending berechnen. Wichtig ist einfach eine schnelle Schnittstelle zum Display. edit: wobei der ESP afaik mit 80 MHz SPI auch schon recht fix ist und das für eine einfache GUI auch oft reichen wird. Es gibt ein weiteres Projekt openHASP das lvgl benutzt, das vereinfacht die GUI Erstellung nochmal durch eine Konfiguration mit vorgefertigten GUI Elementen, z.B. als Bedienpanel für Heimautomatisierung: https://haswitchplate.github.io/openHASP-docs/0.6/
Kleine Ergänzung zu dem was Johannes schon gesagt hat, es gibt da zwei Varianten: "ART Accelerator" und "Chrom-ART". Ersteres dient nur zum Beschleunigen von Speicherzugriffen (dämpft auch den Kommunikations-Overhead bei der Displayansteuerung) und Letzteres kann das Blenden/Konvertieren von Pixeln für dich übernehmen wie schon gesagt wurde. Achte darauf, dass dein Controller beides hat, wenn du viel transparente Sprites rendern willst. Das Pixel-Konvertieren ist auch nützlich um Speicher zu sparen.
Stefan S. schrieb: > Da dieser grafikbeschleuniger wohn auch direkt double buffering > unterstützt, wäre es echt toll, wenn die hardware mir das mit den > framebuffern komplett abnehmen könnte. Das tut die Hardware sowieso, aber du wilst ja den Framebuffer auch füllen und das macht ART oder ChromART. Allerdings habe ich schon meinen Spass mit Fonts und ART gehabt, denn es dauert schon, den DMA passend zu füllen und in der Zeit sind Pixelroutinen schon mittendrin oder bereits fertig. ART ist gut zum Füllen von Flächen und dann wirklich schneller. Aber Fonts pinseln lohnt sich nicht immer - zumindest auf dem F429, mit dem ich hier rumspiele.
:
Bearbeitet durch User
Moin, >Da dieser grafikbeschleuniger wohn auch direkt double buffering >unterstützt, wäre es echt toll, wenn die hardware mir das mit den >framebuffern komplett abnehmen könnte. Das ist ein Irrglaube. Der LTDC (nur für DPI- bzw. DSI-Displays) verwaltet zwei Grafiklayer als Frmaebuffer im RAM, die er quasi-parallel ausliest und zu einem Gesamtbild verrechnet. Damit sind so Spielereien möglich wie ein statisches Hintergrundbild überlagert mit einem halbtransparenten GUI. Nachteil ist, wenn man beide Layer benutzt, hat man bei der Ausgabe auch nur noch die halbe Performance - gerade bei größeren Displays, für die der Framebuffer im externen SDRAM untergebracht werden muss, merkt man das deutlich. Generell muß sich die benutzte Grafikbibliothek selbst um das Doublebuffering kümmern, also ganz klassisch zwei Framebuffer aufsetzen und dem LTDC dann immer die Startadresse des sichtbaren Frambuffers übergeben. Dem LTDC kannst Du dann noch sagen, ob er am Ende der aktuelle Zeile oder erst am Ende des Bildes umschalten soll. >ART ist gut zum Füllen von Flächen und dann wirklich schneller. Aber >Fonts pinseln lohnt sich nicht immer - zumindest auf dem F429, mit dem >ich hier rumspiele. Da sind meine Erfahrungen etwas anders - in meinem Fall auf dem F767 und dem H743. Auch Fonts gehen mit dem DMA2D alias Chrome-Art deutlich schneller. OK, wenn man die HAL benutzt, ist der Perfomracegewinn nicht so groß, aber wenn man den DMA2D direkt benutzt, ist es doch einiges mehr an Performance. Ich mache hier alles mit 4 bit Graustufen-Fonts fürs Anti-Aliasing. Da übergebe ich dem DMA2D nur die Startadresse, Zeilenoffset, Anzahl der Zeilen, den Type der Formatkonvertierung (A4 auf ARGB32) und die Zielfarbe und den Rest mach die Hardware selbst, sprich den Bitblit mit Einfärben und Alphablending. Da ist der DMA2D schon lange fertig, wo die CPU noch am Berechnen des Alphablendings und Kopieren der Daten in den Framebuffer beschäftigt wäre. LG Micha
:
Bearbeitet durch User
Stefan S. schrieb: > weiß nicht, ob ich da stms eigene grafikbibliothek verwenden kann Ja warum nicht, heisst TouchGFX. Segger STemWin kann man auch kostenlos verwenden. https://www.st.com/content/st_com/en/ecosystems/stm32-graphic-user-interface.html
:
Bearbeitet durch User
Ich habe so ein komisches Gefühl, dass dieser "Grafikbeschleuniger" hier schon einmal diskutiert wurde. Und ich meine mich zu erinnern, das dabei heraus kam, dass er bei Textausgabe keinen nennenswerten Performance-Vorteil bringt, dafür aber einige komplizierter macht. Versuche mal diesen Thread mit der Suchfunktion zu finden.
Die Idee war, dass stm was von font rendering und einem format schreibt, das wohl ähnlich sein soll wie true type. Wenn ich Glück habe, muss ich dann die font nur ein einziges Mal speichern, anstatt das für jede der drei geplanten Schriftgrößen zu machen. Und da es auf Grund von physischen Vorgaben wahrscheinlich letztendlich ein 1bit monochrom Display werden wird - zumindest, wenn ich nicht noch ein Farbdisplay finde, das in 60x60 mm passt. Wird der grafikbeschleuniger ggf ganix an Geschwindigkeit bringen.....
Hi, OK, Truetype rendern ist ja reine Berechnung von Pixeln aus Vektoren. Da bringt der DMA2D in der tat nichts. Aber macht sowas auf einem MC Sinn? Macht TTF Sind bei einem monochromen Display? Da würde ich lieber die Pixelfonts fertig vorberechnet im Flash ablegen. Das dürfte auch reichlich Platz im Flash sparen. Gruß Micha
Stefan S. schrieb: > Die Idee war, dass stm was von font rendering und einem format > schreibt, > das wohl ähnlich sein soll wie true type. Font-Rendering auf Basis von TrueType (und ähnlichen Formaten?) ist extrem kompliziert. Als erstes braucht man Bibliotheken wie Pango+Harfbuzz, welche den Unicode-Text analysieren, die Zeichen positionieren und dabei Dinge wie Kerning, die Anordnung von Diakritika (insb. in Sprachen wie Arabisch), Rechts-Nach-Links-Skripte usw. beachten. Dann braucht man die Freetype2-Bibliothek zum Auslesen der TrueType-Datei, Interpretieren der Hinting-Algorithmen (manche Schriften funktionieren nicht ohne) und damit Erstellung der Kontur für eine bestimmte Schriftart&Größe. Dann brauchst du nur noch einen Algorithmus der die Kontur in eine Pixelgrafik rendert und dabei Anti-Aliasing, Subpixel-Rendering usw. macht. Die Freetype2-Library kann das, aber in Software. Wenn man eine OpenGL/Vulkan-fähige Grafikkarte hat kann man sich überlegen das Rendern dort parallel zu implementieren. Die Algorithmen brauchen natürlich auch Floatingpoint-Unterstützung. Dann gibt es noch https://github.com/nothings/stb/blob/master/stb_truetype.h was hier einige Abkürzungen macht. Die folgenden Fragen solltest du dir stellen: - Welche Sprachen/Skripte sollen unterstützt werden? Nur Latein, oder auch arabisch, hebräisch, chinesisch, Emoji, ...? - Sollen beliebige Unicode-Texte dargestellt werden können? - Möchtest du beliebige Schriftarten unterstützen, oder reicht es wenn alles nur mit einer Schriftart funktioniert, bei der du bestimmte Einschränkungen machen kannst (z.B.: funktioniert ohne Hinting)? - Soll die Darstellung mit unterschiedlichen Auflösungen (DPI) funktionieren? - Brauchst du Hinting? - Brauchst du Anti-Aliasing? - Brauchst du Subpixel-Rendering? - Möchtest du fontconfig verwenden um Schriftarten automatisch zu finden und auszuwählen anhand ihres Namens? - Soll das Rendern der Outline klassisch auf der CPU geschehen oder per GPU beschleunigt werden? Bei GPU: Soll der Text vielleicht sogar in eine 3D-Welt eingebettet werden? - Hast du genug Platz & Leistung für Bibliotheken wie Pango, Harfbuzz, Freetype und ihren Haufen an Abhängigkeiten (Glib...)? Funktionieren die überhaupt auf deinem OS? "Vollständiges" Text-Rendering kann einen STM32-Mikrocontroller locker sprengen und ist eigentlich nur auf einem vollwertigen Anwendungsprozessor und entsprechendem OS wirklich praktikabel. Die Einschränkungen entscheiden also über die Machbarkeit.
Stefan S. schrieb: > Die Idee war, dass stm was von font rendering und einem format schreibt, > das wohl ähnlich sein soll wie true type. > Wenn ich Glück habe, muss ich dann die font nur ein einziges Mal > speichern, anstatt das für jede der drei geplanten Schriftgrößen zu > machen. Da bist du vermutlich auf einem Erguß der PR-Abteilung von ST ausgeruscht... Also im Klartext: Sowas wie TrueType halte ich auf einem Mikrocontroller für nicht wirklich handelbar. Selbst schon mit 16 Bit Char's tut man sich schwer. Also übe dich in dem angemessenen Maße in Bescheidenheit. Auf einem µC-System benötigt man für jede Schrift in jedem Schriftgrade einen fertig berechneten und in der Firmware irgendwo gespeicherten Satz von Glyphen. Die Alternative wäre das Berechnen zur Laufzeit - und das kostet dann nicht nur Platz für die Berechnungsroutinen sondern auch noch Laufzeit. Also vergiß sowas möglichst schnell. Die Frage, wie du die Glyphen (sprich: den jeweiligen Font) vorhältst und wie sie gezeichnet werden sollen, ist für die Verwendung in einem µC-System weitaus wichtiger. Meine Version sieht so aus: Es gibt einen Canvas (sprich: RAM, in dem der Displayinhalt aufgebaut werden soll) und ein GDI (sprich: einen Satz von Routinen, die grafische Operationen tun, vom Zeichnen eines Punktes bis zum Zeichnen von Bildern), das auf den Canvas arbeitet. Dazu gibt es Device-Kontexte (sprich structs, die die wesentlichen Kennwert des zugehörigen Canvas halten, z.B. Breite, Höhe, Adresse des Canvas, aktuelle Farben usw.) Dazu gibt es Schriften, die aus Programmsicht wie Arrays aus Bytes aussehen und alles enthalten, was für die jeweilige Schrift benötigt wird. Um Schrift hinzuzeichnen, wird zuvor der benutzte Bereich mit der aktuellen Hintergrundfarbe abgelöscht und dann der Schriftzug in der aktuellen Schriftfarbe gezeichnet. System Schultafel: wo man was hinschreiben will, muß zuvor der Schwamm zum Platzschaffen drüber. Mit diesem System bin ich schon seit mehr als 10 Jahren recht gut gefahren und es funktioniert auch auf langsameren Systemen (CPU-Takt < 50 MHz) ganz gut. W.S.
Schließe mich an, vergiss das mit TrueType (und OpenType). Man müsste der Sache aber halbwegs nah kommen können: Schnapp dir Cairo+Pango und render die Glyphen selbst in Bitmaps der richtigen Auflösung. Lässt sich mit z.B. Python alles automatisiert aufsetzen, inkl. Auslesen vom Bild und umpacken in z.B. C Sourcecode. Zusätzlich kannst du eine einfache Tabelle dazulegen, die das Kerning für alle Buchstabenkombinationen enthält. Die Info dazu bekommst du aus Pango, der Rest geht mit Cairo. Die häufigsten Ligaturen könnte man auch noch per Hand einfügen. (ff, ffi usw.) Ist sicher ein wenig Fleißarbeit und Doku fläddern dabei, aber am Ende hast du sauberes Hinting und Kerning. Problematisch ist vermutlich noch, dass man Buchstaben auch an gebrochenen Pixelgrenzen ausrichten möchte. Dafür könnte man noch für jedes Zeichen ein Bitmap mit einem .5 Pixel-Offset dazu legen, Cairo übernimmt dann das Hinting.
W.S. schrieb: > Also im Klartext: Sowas wie TrueType halte ich auf einem Mikrocontroller > für nicht wirklich handelbar. Selbst schon mit 16 Bit Char's tut man > sich schwer. Also übe dich in dem angemessenen Maße in Bescheidenheit. Bescheidenheit ist eine Zier... Ob Vektorfont-Rendering auf einem Mikrocontroller sinnvoll und notwendig ist, muß natürlich jeder von Fall zu Fall entscheiden, möglich ist es auf jeden Fall. Klar, der Mikrocontroller muß "ausreichend Schmackes" mitbringen. Ich habe schon vor Jahren eine nahezu vollständige (lediglich "exotische" Font-Formate weggelassen) FreeType-Implementierung auf einem 200 MHz ColdFire umgesetzt. Die Performance war selbst auf 16 Bit Displays (anti-aliasing) mit hoher Auflösung (XGA+) mehr als ausreichend. Aktuelle Mikrocontroller (z.B. vom Schlage eines NXP iMXRT1062 wie im "großen" Teensy verbaut) sollten das "mit Links" hinbekommen.
Das Problem ist nicht die letztliche Berechnung, sondern die Komplexität der gesamten Spec mit all ihren Ausnahmen und Sonderfällen. Mal ganz direkt gefragt: Die Hinting-Algorithmen (BCI) waren bis vor wenigen Jahren patentrechtlich geschützt. Wie hast du das denn umgangen?
Wenn es wirklich schön sein soll, müsste man sich auch mit Unicode auseinander setzen.
Stefan ⛄ F. schrieb: > Wenn es wirklich schön sein soll, müsste man sich auch mit Unicode > auseinander setzen. Das ist sowieso Grundvoraussetzung, denn sonst wird's schwierig die richtigen Glyphen in der Schrift zu identifizieren! Daher auch Harfbuzz&Pango, um Schriftzeichen aus einzelnen Glyphen zusammen bauen zu können, wenn diese eben als einzelne Unicode-Codepoints daher kommen aber kombiniert werden müssen.
Johannes schrieb: > Mal ganz direkt gefragt: Die Hinting-Algorithmen (BCI) waren bis vor > wenigen Jahren patentrechtlich geschützt. Wie hast du das denn umgangen? FreeType bringt alles mit, was man braucht - inclusive des Byte Code Interpreters. Anfänglich gab es nur den Autohinter (eben deswegen), aber das Apple-Patent ist seit mehr als 10 Jahren ausgelaufen. Seither dürfen auch Linux-Bildschirme legal per BCI beackert werden.
Johannes schrieb: > Mal ganz direkt gefragt: Die Hinting-Algorithmen (BCI) waren bis vor > wenigen Jahren patentrechtlich geschützt. Wie hast du das denn umgangen? Software kann in D und in der EU nicht patentrechtlich geschützt werden.
Die Frage war an Markus F gerichtet, weil er das ja schon implementiert hat. Da Hinting zu einer vollständigen Implementierung dazu gehört hat mich nur interessiert, wie er das damals (vermutlich vor Auslaufen des Patentschutzes) gelöst hat. Den Auto-Hinter in Freetype kenn ich, und teilweise bringt der sogar schönere Ergebnisse als der BCI Hinter. Aber bei einigen Fonts kommt leider Mist raus.
Johannes schrieb: > Da Hinting zu einer vollständigen Implementierung dazu gehört hat > mich nur interessiert, wie er das damals (vermutlich vor Auslaufen des > Patentschutzes) gelöst hat. FreeType hat den BCI übrigens bereits lange vor Auslaufen des Apple-Patents enthalten - nur haben die gängigen Linux-Distributionen ihn nicht mit einkompiliert, weil in etlichen Ländern eben genau das die Patentrechtsverletzung darstellte. Seit 2010 ist er aber praktisch überall verfügbar. In den eigenen vier Wänden konnte man den BCI schon lange vorher aktivieren.
Leute, kommt mal aus der Abschweife zurück zum Thema. Also, wie man das mit einem GUI auf dem µC macht, wenn man lediglich 48MHz Takt und 64K oder eine Kleinigkeit mehr an Flash im System hat. Stefan S. schrieb: > Ich möchte eine relativ simple gui mit entweder einem kleinen garb LCD > oder einem simplen oled display zeichnen. Das Problem ist mMn nicht das Malen von grafischen Basis-Elementen (Rechtecke ausmalen, Linien+Ellipsen zeichnen, Text darstellen oder Icons malen) - sondern das grafische System darüber, also Buttons, Check-Listen, Scroll- oder Drop-Down Listen, Menüs usw. Auf dem PC macht man das zumeist, indem man im RAM (konkret: im Heap) ein System miteinander verlinkter Objekte anlegt. Aber Speicher jeder Art ist in einem µC weitaus weniger vorhanden und folglich kostbarer, so daß man ein Doppelspeichern wie am PC (in der Datei als Ressource und im Arbeitsspeicher (=RAM) als Objekte) besser nicht anzielt. Die logische Folge davon ist, besagtes System miteinander verlinkter Objekte bereits zur Übersetzungszeit zu kreieren und dann im Flash zu speichern. das geht - aber es gibt gerade bei C dezente Probleme, weil C keine Objekte kennt. Obendrein brauchen die meisten Objekte nicht nur Methoden, sondern auch während der Laufzeit veränderbare Properties, also RAM, weswegen man sich auf irgendeinen Kanon von Zeigern aus dem Flash auf den RAM durchringen muß. Das ist ne Menge Detailwissen, was man für sowas erstmal ansammeln muß. Also diskutieren wir lieber diese Aspekte als Details der Schriftdarstellung, die eher in PC-Gefilden relevant sind. W.S.
W.S. schrieb: > Also diskutieren wir lieber diese Aspekte als Details der > Schriftdarstellung, die eher in PC-Gefilden relevant sind. Kanst Du gerne diskutieren. Hat der TO aber gar nicht gefragt.
und auch nicht das er sich die Arbeit durch wenig Speicher extra erschweren möchte. Die STM mit ChromART haben 0,5...2 MByte Flash, da passen auch 3 Fonts rein.
Ihr interpretiert wahrscheinlich viel mehr in das Projekt rein als ich wirklich vor hatte. Mir ging es mit dem ganzen Debakel darum, dass die virberechneten Fonts zusammen mit meinem Code nicht in die 64k Flash passen. (ich habs schon probiert) Die Zeichen, die ich brauche sind im Grundsatz nur Zahlen, der grad Kreis und das C. Und in eine kleinen Schriftgröße ascii Zeichen plus vielleicht Umlaute. Die Anwendung ist ein Thermostat. Die ui beschränkt sich auf entweder 8 Boxen mit je einem Symbol, oder eine große Zeile, eine mittlere und eine Kleine. Mehr Details führen an dem Thema vorbei, wie ich meine fonts in 64k Flash Pressen kann.
Stefan S. schrieb: > dass die virberechneten Fonts zusammen mit meinem Code nicht in die 64k > Flash passen. Hast du denn auch ein vernünftiges Format gewählt? 8 Monochrom-Pixel in ein Byte gequetscht?
Stefan S. schrieb: > Mir ging es mit dem ganzen Debakel darum, dass die > virberechneten Fonts zusammen mit meinem Code nicht in die 64k Flash > passen. > Die Zeichen, die ich brauche sind im Grundsatz nur Zahlen, der grad > Kreis und das C. Verstehe ich nicht. Wenn wir mal von einem mittelgut aufgelösten Font mit 16x10 Pixeln ausgehen, dann sind das 20 Bytes pro Zeichen. Das mal ca 100 Zeichen ergibt 2 Kilobytes. Wo ist das Problem? Wenn dir das zu viel ist: Es gibt auch Fonts mit 7x5 Pixeln, die brauchen nur ein halbes Kilobyte Flash. Da kannst du zur Not alle Pixel verdoppeln, falls das auf dem Display zu klein dargestellt wird. Es sieht dann allerdings ziemlich "retro" aus. Die Adafruit Library ist ziemlich generisch, weswegen sie auch zu den langsameren gehört. Aber im Rahmen der Möglichkeiten haben die Leute das schon gut gemacht, kein Grund sie nicht wenigstens mal zu probieren.
Angehängte Dateien:
Für einen Thermostat kommt man sicher auch ohne Grafikbeschleuniger aus. Da sehen die runden Displays GA9C01 gut aus.
Stefan S. schrieb: > Mehr Details führen an dem Thema vorbei, wie ich meine fonts in 64k > Flash Pressen kann. Und deswegen setzt du dabei auf hochentwickelte Fontverwaltungen wie True Type, die für Desktopsysteme entwickelt wurden, wo es auf einige zig MByte nicht ankommt? Seltsame Idee. Und was Grafikbeschleuniger zur Datenreduktion von Fonts beitragen sollen ist noch rätselhafter. Stefan ⛄ F. schrieb: > Das mal > ca 100 Zeichen ergibt 2 Kilobytes. Wo ist das Problem? Die 2 kBytes zusätzlich frei finden sich garantiert viel eher im Code. Und dass der Grafikbeschleuniger weniger als 2 kBytes braucht glaube ich auch nicht. Georg
Stefan S. schrieb: > Mir ging es mit dem ganzen Debakel darum, dass die > virberechneten Fonts zusammen mit meinem Code nicht in die 64k Flash > passen. Also, mir scheint, daß deine Fonts ein wenig undurchdacht sind und deswegen viel zu viel an Speicherplatz fressen. Ich hab grad mal ein altes Projekt von mir herausgekramt. µC=MK02FN128, davon belegt=13.5KByte - und darin befinden sich: 1.Font = Fix5x7 2.Font = Helvetica 12 3.Font = Helvetica 12 Bold 4.Font = Helvetica 14 5.Font = Helvetica 14 Bold und an sonstigem Zeugs - Display-Ansteuerung für die damalige Pollin "..wrnna.." (Nummer hab ich vergessen) - Tasten, SysTick und Event-Verwaltung - IR-Dekoder für die "Merlin"-Tastatur (ebenfalls Pollin) - das Basis-Zeugs (Config, Startup, IO-Konverter, Kommando-Interpreter, Serial usw.) Wegen Fonts hab ich hier vor Zeiten schon mal so einiges gepostet, da müßtest du suchen, wenn dich das interessiert. W.S.
Ich würde adafruit grfx benutzen und die drei Fonts zusammen nehmen ungefähr 24MByte ein, zumindest bei dem bisher verwendeten displays. Mit true type meinte ich vector fonts, hatte aber beim Schreiben den Ausdruck vector-font nicht im Kopf. Ungefähr 64kByte brauche ich für eine art config objekt Außerdem überlege ich momentan, ob ich aus Gründen der Verfügbarkeit und der Kosten von einem spm32 auf einen msp430 wechsle. Der hat den Vorteil, dass ich da keine touch ics bräuchte, weil der Controller das von selbst kann. Leider habe ich dann noch viel weniger Platz, wenn ich jetzt nicht einen der großen msps nehme. Perfekt wäre es, wenn es möglich wäre für alle größen nur eine font speichern zu müssen. Da momentan nur monospace font geplant ist, wäre es kein Problem eine art Bitmap zu speichern und zu skalieren (zumindest, wenn ich das Geschwindigkeitsmäßig optimiert bekomme.) Ohne dass ich die Diskussion neu Andachten will, erkläre ich jetzt nochmal anders meinen gedankengang. Da eine theoretische Vector font ja nur Anweisungen zum zeichnen beinhaltet, dachte ich es wäre möglich da flash zu sparen im Vergleich zu einer Bitmap. Und der Grafikbeschleuniger hätte das zeichnen und füllen beschleunigen können. Außerdem war ein anderer Gedanke, dass ich das neu zeichnen ein wenig hübscher machen kann. Zugegeben das komplette neu zeichnen könnte ich auch per dma Kanal umsetzen. Außerdem habe ich anscheinend die englische Doku fehlinterpretiert. Es klang zumindest in meinen Ohren so, als könnte ich den Sceenbuffer aus dem Hauptspeicher auslagern. Jetzt nach nochmaligem lesen verstehe ich, dass das Quatsch wäre. Der msp430 hat zwar auch einen grafikbeschleuniger, aber da hat mir die Doku gezeigt, dass er mir nicht hilft. Dank der Doku von TI habe ich dann auch die ST Doku anders gelesen und verstehe jetzt, dass der Beschleuniger weitgehend sinnlos wäre.
Beschreibe doch mal ganz genau wie du die Fonts abgelegt hast. Irgend was läuft da mächtig schief bei dir. Oder du hast dich verschrieben (MB statt kB).
Johannes schrieb: > Oder du hast dich verschrieben (MB > statt kB). davon würde ich ausgehen, so dumm ist die AdafruitGFX Lib nicht. Ein Font mit 224 Zeichen und 12 Pixel Höhe hat ca. 2,5 kB + 900 Byte Index, 16 Pixel ca. 5 kB + 900 Byte. Die Zeichen haben unterschiedliche Breite und Höhe, daher ist der Index nötig. Damit sind 24 kB für 3 Fonts plausibel.
Stefan S. schrieb: > Mir ging es mit dem ganzen Debakel darum, dass die > virberechneten Fonts zusammen mit meinem Code nicht in die 64k Flash > passen. > (ich habs schon probiert) > Die Zeichen, die ich brauche sind im Grundsatz nur Zahlen, der grad > Kreis und das C. Mit der STM-HAL kommt mit STemWin (Middlewares/STemWin) ein Programm Mamens FontCvtST.exe Damit kann man einen TTF-Font laden, die benötigen Zeichen auswählen, und es wird ein C-File ausschließlich mit den benötigten Zeichen in der gewünschten Größe als Bitmap-Font erzeugt. das sollte für deine Anwendung perfekt sein.
:
Bearbeitet durch User
Hier gibt es eine Vektorfont Library die sogar auf einem AVR läuft. Beitrag "Vektor-Font in C" Hier der Artikel dazu: https://www.mikrocontroller.net/articles/Vektor-Font_in_C Hab ich in meiner Scopeuhr mit STM32F103 benutzt. War leicht in Betrieb zu nehmen und funktioniert gut.
:
Bearbeitet durch User
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.