TouchGFX 4.26: Nach den emulierten Framebuffern bringt ST nun Quality-of-Life-Verbesserungen

16. September 2025: Was ist neu in TouchGFX 4.26?

ST hat gerade TouchGFX 4.26 veröffentlicht, das UI-Optimierungen enthält, die bei sich wiederholenden oder gewohnheitsmäßigen Aufgaben helfen, wie dem Kopieren von Typografien oder dem Neuanordnen und Klonen von Interaktionen. Nach der Veröffentlichung von emulierten Framebuffern mit TouchGFX 4.25 wissen wir, dass Entwickler noch daran arbeiten, die neue Funktion in ihre Anwendungen zu integrieren. Aus diesem Grund haben wir uns auf Quality-of-Life-Verbesserungen konzentriert, wie die Unterstützung für den Clang C++-Compiler, der nun in CubeIDE TouchGFX-Projekten unterstützt wird. Wir haben außerdem das Widget ScalableImage optimiert, um die Rendering-Zeit um bis zu 30 % zu reduzieren, unabhängig davon, ob ein Programm Software-Rendering oder unsere NeoChrom GPU verwendet.

• Laden Sie TouchGFX herunter

Artikel veröffentlicht am 3. März 2025

Anmerkung der Redaktion: Für diejenigen, die die Ankündigung der emulierten Framebuffer, die wir Anfang des Jahres gemacht haben, verpasst haben oder für Leser, die eine Auffrischung wünschen: Hier ist eine Neuveröffentlichung des Artikels zur Ankündigung von TouchGFX 4.25.

TouchGFX 4.25 führt den zum Patent angemeldeten emulierten Framebuffer ein, der deutlich weniger Speicherplatz benötigt, indem er das anzuzeigende Bild in Teile zerlegt und eine Speicherzuordnungstechnik verwendet, die den grafischen RAM auf dem Display selbst überflüssig macht. Folglich können Systeme, die bisher einen externen Arbeitsspeicher benötigten, jetzt auf einer Ein-Chip-Platine betrieben werden, wodurch die Materialkosten gesenkt werden. Da ST die Technologie auf Middleware-Ebene integriert hat, können Entwickler die Vorteile dieser Technologie nutzen, indem sie die richtige Option im TouchGFX-Generator auswählen, um zu sehen, ob sie für ihr Projekt sinnvoll ist. Es zwingt die Ingenieure auch dazu, ihre Framebuffer-Strategie genauer unter die Lupe zu nehmen, um zu sehen, ob sie zu ihrer Anwendung passt – etwas, das zu viele oft übersehen.

• TouchGFX 4.25 herunterladen

Was ist neu in TouchGFX 4.25?

Framebuffer-Strategie

Doppelter Framebuffer

Allzu oft machen sich Entwickler keine Gedanken darüber, wie das Bild auf ihrem Bildschirm dargestellt wird. Das kann jedoch ein kostspieliger Fehler sein, denn die Art des Framebuffers hat großen Einfluss auf die Speicherkonfiguration. Ein doppelter Framebuffer speichert zum Beispiel zwei Framebuffer in voller Größe im Speicher, um ein reibungsloses Erlebnis ohne Tearing zu gewährleisten. Ein standardmäßiges 24-Bit-Bild mit 1024×600 Pixeln für einen 10-Zoll-Bildschirm würde jedoch fast vier Megabyte Arbeitsspeicher erfordern, was für ein System mit begrenzten Ressourcen normalerweise unvorstellbar ist. Aus diesem Grund ist ein doppelter Framebuffer nur dann sinnvoll, wenn Sie große Bildschirme und hochwertige grafische Schnittstellen verwenden, bei denen das System natürlich viel externen Arbeitsspeicher nutzt.

Einzelner Framebuffer

Der Kompromiss wäre, nur einen einzigen vollständigen Framebuffer zu verwenden. Der offensichtliche Vorteil ist, dass der Speicherbedarf damit um die Hälfte reduziert wird. Das Risiko des Tearings ist höher, da das Display mitten in einem Refresh aktualisiert werden kann, aber es ist auch möglich, dieses Problem abzumildern. Entwickler können beispielsweise die Komplexität der von ihnen erstellten Animationen einschränken oder dafür sorgen, dass das Display weniger häufig aktualisiert wird und die DMA2D-Beschleunigung (Chrom-ART auf STM32) zur Optimierung der Datenverarbeitung verwenden. Das ist es, was wir oft bei mittleren Grafiken auf Embedded-Systemen finden. Der Bildschirm ist klein und die Anforderungen an die Benutzeroberfläche sind nicht so anspruchsvoll, so dass die Verwendung eines einzigen Framebuffers ohne das Risiko von Tearing möglich ist.

Partieller Framebuffer

Eine andere Möglichkeit ist die Verwendung eines partiellen Framebuffers, den wir in TouchGFX 4.12 eingeführt haben (mehr dazu später). Wie der Name schon sagt, speichert der Speicher nur die Teile des Framebuffers, die aktualisiert werden müssen, wodurch der Speicherbedarf weiter verringert wird. Diese Technik setzt jedoch voraus, dass der Bildschirm über ein grafisches RAM (oder GRAM) verfügt, das den gesamten Framebuffer speichern kann. Der Grund dafür ist, dass das Display den gesamten Framebuffer benötigt, wenn es an der Zeit ist, das Bild zu rendern. Es ist zwar möglich, den eingebetteten Arbeitsspeicher zu reduzieren, indem man nur einen Teil des Framebuffers verwendet, aber es war nicht möglich, die Tatsache zu umgehen, dass der Bildschirm den gesamten Framebuffer in seinem GRAM benötigt.

Emulierter Framebuffer

Mit TouchGFX 4.25 werden heute emulierte Framebuffer eingeführt, die ähnlich wie partielle Framebuffer funktionieren, aber keinen GRAM benötigen. Das ST-Grafik-Framework verwendet den LTDC (LCD-TFT-Display-Controller) und die Grafikspeicher-Verwaltungseinheit der Chrom-GRC-IP, die in bestimmten MCUs wie dem STM32H7R/S, dem STM332H7A/B, dem STM32U5 und dem neu veröffentlichten STM32N6 zu finden ist. Emulierte Framebuffer sind daher möglich, da sie einige der neuesten IPs auf STM32-Bausteinen nutzen. Darüber hinaus implementiert TouchGFX emulierte Framebuffer auf der Middleware-Ebene, ohne dass der Benutzer viel dazu beitragen muss. Er muss lediglich entscheiden, ob er sie im TouchGFX Generator verwenden möchte oder nicht.

Ein neues Speicherverwaltungssystem

Kurz gesagt, TouchGFX verwendet die Speicherverwaltungseinheit, um einen kompletten Framebuffer zu emulieren, ohne ihn im Speicher abzulegen, indem Speicheradressen zugeordnet werden. Wenn das System also nach dem Framebuffer sucht, weiß die MMU, was sie senden muss. Und weil dies an einen partiellen Framebuffer erinnert, unterteilen Entwickler ihre Anzeige in gleich große Abschnitte, z.B. in ein Viertel oder ein Achtel, um die Aktualisierung ihrer Benutzeroberfläche zu optimieren. Je kleiner der Ausschnitt ist, desto mehr Granularität steht den Teams zur Verfügung, aber desto rechenintensiver ist der Vorgang auch. Die Programmierer müssen also den richtigen Kompromiss finden, je nachdem, wie viel des Bildschirms sie aktualisieren.

Mit dem Display sprechen und zuhören, was es zu sagen hat

Auf der anderen Seite liest der LTDC von ST ständig die von der MMU geschriebenen Pixeldaten und sendet den emulierten Framebuffer über Schnittstellen wie Parallel RGB oder MIPI DSI an das Display. Wenn das System also nicht alle 16 Millisekunden den gesamten Bildschirm auffrischt, kommt es zu einem deutlichen Tearing des Bildes. Es ist jedoch wichtig, dies als Vorteil zu betrachten. Emulierte Framebuffer sind nur für statischere Benutzeroberflächen geeignet. Wenn es angebracht ist, bietet diese Strategie genügend Speichereinsparungen, um auf externen RAM zu verzichten und nur den Speicher der MCU zu verwenden. So können beispielsweise 720p- oder 1080p-Displays mit reichhaltigen Benutzeroberflächen, die traditionell einen Mikroprozessor erfordern würden, dank unseres emulierten Framebuffers problemlos auf einer MCU laufen.

Wenn es nur wenige Animationen gibt, wie es bei Anwendungen der Fall ist, die sich auf schnelle Informationen wie Statusaktualisierungen konzentrieren, gibt es keinen Grund, ständig einen ganzen Framebuffer im Speicher zu haben. In diesen Fällen bietet der emulierte Framebuffer eine weitaus effizientere Nutzung des Speichers, was dazu führt, dass eine MCU und weit weniger RAM verwendet werden können. Wenn Entwickler also auf Tearing stoßen, sollten sie dies als eine Nachricht des Frameworks betrachten, die ihnen sagt, dass sie entweder Animationen entfernen oder eine andere Framebuffer-Strategie verwenden sollen (siehe unsere Dokumentation zu Framebuffer-Strategien). Und da alle Strategien als Option im TouchGFX-Generator verfügbar sind, ist es sehr einfach, von einer zur anderen zu wechseln.

Anwendungen aus der realen Welt

Etwas mehr als fünf Jahre nach der Einführung von partiellen Framebuffern in TouchGFX 4.12 sind unsere Teams mit emulierten Framebuffern wieder am Werk, einer noch optimierteren Option, die die Tür zu Single-Chip-Designs öffnet. Die Lösung spiegelt wider, wie TouchGFX die in STM32-Bausteinen vorhandenen IPs nutzt, um die Speichernutzung zu optimieren und sich direkt auf die Stückliste auszuwirken. Es bedeutet auch, dass UIs immer zugänglicher werden, da Projekte, die sie aufgrund der Kosten für ein externes RAM-Modul nicht übernehmen konnten, jetzt eine GUI anbieten können. Der beste Weg, um herauszufinden, welche Framebuffer-Strategie funktioniert, ist das Experimentieren mit emulierten Framebuffern auf einer kompatiblen Entwicklungsplattform, wie dem STM32H7S78-DK, um zu sehen, ob eine Anwendung reibungslos läuft.

In unseren internen Tests haben wir ein Proof-of-Concept auf der oben genannten Entwicklungsplatine durchgeführt, dabei nur den internen Arbeitsspeicher verwendet und großartige Ergebnisse bei 800×400 erzielt. Das einzige Mal, dass wir ein Screen-Tearing hatten, war, als wir Live-Statistiken darstellten. Wir teilen dies mit, damit unsere Community versteht, dass nicht jede Demo auf einem emulierten Framebuffer gut läuft. Diejenigen, die gut laufen, werden jedoch die Tür zu effizienteren und kostengünstigeren Embedded-Systemen öffnen. Der Screenshot rechts zeigt zum Beispiel die Benutzeroberfläche eines Aufzugs, der auf einem 720p-Display und einem STM32H7 läuft. Dabei wird nur der eingebettete RAM verwendet, was vor emulierten Framebuffern unmöglich gewesen wäre.

Neue Kompression und Unterstützung

TouchGFX 4.25 führt auch die Komprimierung von Bitmap-Schriften ein, um den Speicherbedarf einer Benutzeroberfläche zu reduzieren. Diese Funktion dient als Alternative zu Vektorschriftarten, wenn ein System aus Leistungsgründen Bitmaps verwenden muss. In realen Anwendungen reduziert die neue Komprimierung den Speicherbedarf von Bitmap-Schriften um 20% bis 80%. Bei einer Schriftart mit vielen chinesischen Zeichen kann die Größe beispielsweise um 40 % abnehmen, und eine sehr große Schriftart, wie Verdana in 110 Punkt, aber mit einer geringen Anzahl von Zeichen, kann von etwa 40 KB auf nur 8 KB im Speicher schrumpfen.

Die neue Version von TouchGFX bietet außerdem Unterstützung für CMake und iAR 9, um Arbeitsabläufe zu optimieren. CMake ist eine Open-Source-Suite von Tools, mit denen Entwickler ihre Software erstellen, testen und verpacken können. Es hilft Ingenieuren, ihre Projekte auf mehrere Plattformen zu portieren und sie mit Teammitgliedern zu teilen, um die Entwicklungsabläufe zu optimieren.

Was ist TouchGFX?

Der Rahmen

TouchGFX ist ein kostenloses Framework von ST, mit dem Sie grafische Benutzeroberflächen auf STM32-Mikrocontrollern erstellen können. Die in C++ geschriebene Engine nutzt die Vorteile von Optimierungen auf ST-Geräten. TouchGFX geht von der Annahme aus, dass Schnittstellen aus Bildschirmen bestehen, durch die der Benutzer navigiert. Daher ist das Framework intuitiv und spiegelt die Erfahrungen der Benutzer wider. Außerdem ist es umfangreich, da es 2D- und 3D-Objekte, Videos, Animationen, Übergänge usw. verarbeitet. Die Möglichkeit, auf den generierten Code zuzugreifen, erlaubt es Experten, ihn zu optimieren. Um sie dabei zu unterstützen, bietet die TouchGFX-Dokumentation Informationen zu den APIs des Frameworks oder den verfügbaren Entwicklungstools.

TouchGFX-Designer

TouchGFX-Designer ist oft das erste Tool, das Entwickler verwenden, wenn sie mit ihrer Benutzeroberfläche beginnen. Es handelt sich dabei um ein Dienstprogramm mit einem WYSIWYG-Ansatz, mit dem Designer das erstellen, was ihre Benutzer sehen und mit dem sie interagieren werden. Entwickler können mit Beispielprojekten beginnen, z. B. einer Uhr, einer Anzeige oder einem animierten Bild. Es gibt auch umfassendere Demos wie eine Würfelanimation, Szenenübergänge oder ein Pool-Überwachungssystem. Ein Startbildschirm hilft Ihnen bei der Auswahl der Demoanwendung und des ST-Entwicklungsboards und konfiguriert alles. Die Ausführung von Beispielcodes und Demos dauert daher nur wenige Minuten, was eine schnellere Erstellung von Proofs-of-Concept bedeutet. UI-Elemente in TouchGFX-Designer haben oft die Form von Widgets, die Sie über die Benutzeroberfläche des Programms hinzufügen und konfigurieren.

TouchGFX-Designer ist ein integraler Bestandteil des TouchGFX-Ökosystems. Solange der Benutzer eine 3.0-Vorlage wählt, ist es zum Beispiel möglich, das Projekt im Designer zu starten, es dann zu STM32CubeMX zu bringen, das Discovery-Board oder die MCU einzurichten und TouchGFX-Generator (siehe unten) die .IOC-Datei aktualisieren zu lassen, um die neuen Einstellungen sofort anzuwenden. Auf ähnliche Weise kann ein Entwickler mit TouchGFX-Generator beginnen, zu TouchGFX-Designer wechseln und dann zu STM32CubeMX zurückkehren, um die Displayauflösung zu ändern. Das System wird TouchGFX-Designer automatisch aktualisieren, ohne dass Sie die Anwendung schließen müssen.

TouchGFX-Simulator

TouchGFX-Simulator hilft Entwicklern, ihre grafische Benutzeroberfläche in der Vorschau zu sehen, bevor sie sie auf ihrer MCU ausführen. Ein Teil seiner Attraktivität besteht darin, dass er Tastaturkürzel bietet, um Arbeitsabläufe zu rationalisieren. So ist es beispielsweise mühelos möglich, verschiedene Screenshots zu erstellen und Animationen Bild für Bild zu untersuchen. Wenn Sie F2 drücken, werden ungültige Bereiche hervorgehoben, d.h. die Abschnitte des Frames, die das System aktualisieren muss. So können Entwickler überprüfen, ob ihre Animationen MCU-Ressourcen verschwenden, indem sie unnötigerweise Assets ungültig machen.

TouchGFX-Generator

TouchGFX-Generator arbeitet mit STM32CubeMX zusammen, um einen großen Teil der TouchGFX-Abstraktionsschicht zu erzeugen. Wir unterstützen fast alle STM32-Discovery-Kits mit einem Display und das neue Plugin funktioniert mit jeder STM32-MCU mit einem Cortex-M0+, -M4 oder -M7. Entwickler müssen zwar immer noch einige Leerstellen in ihrem Anwendercode ausfüllen und Optimierungen vornehmen, aber dieses neue Plugin macht den Start eines Projekts viel einfacher. Generator erstellt nämlich leere Funktionen, um die Entwickler anzuleiten und die Initialisierung des Boards zu erleichtern. Es gibt auch Standard-Setups für die ST-Entwicklungsboards, die die Entwicklung beschleunigen und als Beispiele dienen.

Welche Funktionen sind bereits in TouchGFX enthalten?

Vektor-Optimierungen

Die meisten statischen Schnittstellen auf Mikrocontrollern verwenden Bitmaps, weil sie einen geringen Rechendurchsatz erfordern. Im Vergleich dazu sind Vektorbilder weniger verbreitet, weil sie viel mehr Rechenleistung benötigen. Die Herausforderung besteht darin, dass Vektoren für Animationen unerlässlich sind. Daher können Entwickler entweder mehr Ressourcen verwenden, um eine höhere Anzahl von Bildern pro Sekunde zu erhalten, oder sie verwenden weniger Energie und haben eine weniger flüssige Animation. Um dieses Problem anzugehen, bietet TouchGFX erhebliche Optimierungen bei der Verarbeitung von Vektorgrafiken, mit einer Steigerung der Effizienz von bis zu 70% in einigen Fällen. Entwickler können also auf kleineren MCUs flüssigere Animationen anbieten oder mehr Vektorelemente verwenden. Die größten Leistungsgewinne werden Entwickler jedoch bei umfangreicheren Animationen sehen.

Die neue Optimierung nutzt Chrom-ART, um den Mikrocontroller bei bestimmten Operationen wie Farbfüllungen zu entlasten. ST hat auch die Art und Weise aktualisiert, wie das Framework die Kanten einer Form berechnet. Da sich die Aktualisierungen auf den Umgang des Frameworks mit Vektorgrafiken beziehen, profitieren die Benutzer automatisch von ihnen. Entwickler werden also sofort Leistungssteigerungen feststellen und können entsprechend planen. Einige können den Speicherbedarf ihrer Anwendung senken oder neue Animationen zu ihrer Oberfläche hinzufügen. Teams müssen möglicherweise auch ihre Benutzeroberfläche überarbeiten, weil einige Elemente schneller laufen als erwartet.

Vektor-Schriften

Es ist paradox, dass Text zwar ein wichtiger Bestandteil der meisten Benutzeroberflächen ist, aber auch einer der am meisten übersehenen Aspekte sein kann. Viele kennen zum Beispiel nicht einmal den Unterschied zwischen einer Schriftart und einem Schriftbild, und ja, wie wir zeigen werden, ist der Unterschied wichtig. Helvetica oder Avenir werden oft als Schriftarten bezeichnet, sind aber Schriftbilder. Kurz gesagt, eine Schriftbild ist die Designsprache, die eine Reihe von Buchstaben, Zahlen und Symbolen prägt. Eine Schriftart ist eine Untergruppe eines Schriftbilds, die sich unter anderem durch ihr Gewicht und ihre Größe auszeichnet. Während Helvetica also ein Schriftbild ist, ist Helvetica 12-Punkt eine Schriftart. Ebenso ist die 12-Punkt Helvetica Bold eine andere Schriftart als die 12-Punkt Helvetica Light.

Warum ist das wichtig? Weil Embedded-Systeme zur Kompilierungszeit für jede Schriftart neue Bitmaps rendern müssen. Im Gegensatz zu PCs, die Outline-Schriftarten (auch Vektorschriftarten genannt) verwenden, die Anweisungen zum Zeichnen enthalten, verwenden Embedded-Systeme Bitmaps. Vektorschriftarten sind rechenintensiv, was auf einem PC kein Problem ist, aber auf einem Mikrocontroller die Benutzeroberfläche zum Stillstand bringen kann. Umgekehrt brauchen Bitmaps keine Berechnungen, da sie bereits gerendert sind, aber sie benötigen viel mehr Platz im Speicher, da jede Schriftart separat gerendert werden muss. Die Bitmaps für drei Schriftarten (ein Schriftbild in drei verschiedenen Größen) würden beispielsweise fast 800 Byte Speicherplatz beanspruchen, während eine Vektordatei weniger als 200 Byte benötigen würde.

Die Tatsache, dass TouchGFX-Designer das erste UI-Toolkit ist, das Vektorschriftarten auf MCUs unterstützt, ist ein großer Schritt nach vorn für Ingenieure, die ihren Flash-Footprint reduzieren wollen. Dank dieser Funktion konnte ein ST-Kunde jetzt nur noch mit dem internen Flash der MCU auskommen und so seine Stückliste erheblich reduzieren. Noch beeindruckender ist dies bei logografischen Schriftsystemen, die oft mehr Bitmaps benötigen als alphabetische Schriftsysteme. Während die Gewinne je nach Anwendung sehr unterschiedlich ausfallen, bedeutet die inhärente Volatilität des Speichermarktes, dass viele Entwickler stets bestrebt sind, ihre Abhängigkeit von externen Flash-Modulen zu verringern.

Die Unterstützung von Vektorschriftarten war eine langjährige Entwicklung. Viele unserer STM32-MCUs unterstützen sie zwar technisch, aber die Möglichkeit, die Vektorberechnungen mit unserer NeoChrom-GPU zu beschleunigen , bedeutet, dass der STM32U5 und der neue STM32H7R/S die Tür zu Leistungen öffnen, die Vektorschriftarten realisierbar machen. Während zum Beispiel ein STM32F7 bis zu 2,88 ms für das Rendern einer Vektorschriftart benötigt, benötigt ein STM32U5F9 nur 0,80 ms. In ähnlicher Weise haben die jüngsten Vektoroptimierungen in früheren Versionen von TouchGFX die Belastung verringert. Wir wissen aber auch, dass nicht jede Benutzeroberfläche von Outline-Schriftarten profitieren würde. Bei animationslastigen Systemen ist das sicher nicht der Fall. Daher ist diese Funktion nur ein weiteres Werkzeug im Arsenal eines Teams.

Um Anwendern dabei zu helfen, herauszufinden, ob Vektorschriftarten für sie geeignet sind, haben wir die oben gezeigte Demo, die Vektoren und Bitmaps kombiniert, veröffentlicht und ihren Quellcode freigegeben. In der Tat sind Vektorschriftarten nicht die einzige Möglichkeit, um Speicher zu sparen. Unser L8-Komprimierungssystem kann zum Beispiel auch Bitmaps verkleinern. Jedes Projekt hat andere Flash-Anforderungen, und jede Benutzeroberfläche hat spezielle Rendering-Anforderungen. Einige Projekte müssen mit begrenzter externer Flash-Kapazität auskommen, andere versuchen, nur den internen Flash zu verwenden, und wieder andere wollen einfach nur die Programmierzeiten reduzieren. Allerdings verlangen die Kunden zunehmend nach Benutzeroberflächen, die weniger Flash verwenden. Folglich öffnen Vektorschriftarten potenziell die Tür zu Schnittstellen, die sonst nicht möglich gewesen wären.

Speicheroptimierung

TouchGFX 4.24 bringt eine Reihe von Optimierungen an seinen Kompressionsalgorithmen und Vektoroperationen, um mehr Flash zu sparen. Seit der vorigen Version hat ST die eBike-Demo im obigen Video veröffentlicht, die nur 355 KB verwendet, anstatt eines anfänglichen Satzes von Bitmaps von insgesamt 10,5 MB. Konkret haben wir daran gearbeitet, unser L8-Komprimierungsformat weiter zu optimieren und geben Tipps, die Entwicklern helfen, das Beste aus ihren Benutzeroberflächen herauszuholen und dabei weniger Flash zu verwenden. So erhalten Teams beispielsweise eine höhere Komprimierung für Bilder, die in 8 Bit oder weniger kodierte Farben verwenden. Außerdem kann TouchGFX dank ChromART einige Elemente direkt aus dem Flash zeichnen und so die Abhängigkeit der Anwendung vom RAM verringern.

Das ST-Framework brachte auch neue Optimierungen bei der Implementierung des QuiteOK-Image-(QOI)-Komprimierungsalgorithmus mit, die dazu beitragen, die Größe der grafischen Elemente im Speicher zu reduzieren. Das Komprimierungsverhältnis hängt von einer Vielzahl von Faktoren ab. Unter optimalen Umständen können wir die Dateigröße verlustfrei um 95% reduzieren. Da Dekomprimierungsvorgänge auf leistungsschwächeren CPUs jedoch teuer sein können, verwenden manche Unternehmen vorrangig optimierte Bitmaps und Tricks wie Kachelbilder (ein komplettes Bild, das aus Kopien einer kleinen Kachel besteht), um die Flash-Nutzung zu begrenzen. Ingenieure wissen, dass es keine Einheitslösungen für Benutzeroberflächen auf Embedded-Systemen gibt. TouchGFX 4.24 öffnet jedoch die Tür zu der Möglichkeit, Benutzeroberflächen ohne externen Flash zu betreiben.

L8-Komprimierungsformat

Grafische Elemente benötigen viel Speicherplatz, und eine Verringerung ihrer Qualität bedeutet eine Verschlechterung der Benutzeroberfläche. L8 ist daher ein unverzichtbares Bildformat, da es dank des Chrom-ART-Beschleunigers in STM32-Mikrocontrollern eine Datei um bis zu 75 % komprimieren kann, ohne dass es zu einer Verschlechterung kommt. Solange ein Element maximal 256 Farben verwendet, was bei kleinen Embedded-Systemen mit einer STM32-MCU häufig der Fall ist, können Entwickler ein Element mit dem L8-Format komprimieren, indem sie einfach ein Kästchen im TouchGFX-Designer anklicken. Die Dekomprimierung ist auch rechnerisch effizient, da sie die Chrom-ART-Engine verwendet, um Farben in einer Tabelle nachzuschlagen und das Element ohne Qualitätsverlust zu rendern.

L8-Bilder weiter komprimieren

Mit TouchGFX-Designer 4.22 wurde eine wichtige Funktion eingeführt: Die Komprimierung von L8-Bildern. Wenn Sie in der linken Spalte auf „Bilder“ klicken, werden die aktuell geladenen grafischen Elemente aufgelistet. Für alle L8-Bilder ist ein neues Dropdown-Menü „Komprimierung“ verfügbar, in dem Sie zwischen drei Methoden wählen können: L4, LZW9 (Lempel-Ziv-Welch) und Run Length Encoding (RLE). Alle drei sind verlustfrei, wobei L4 und LZW9 Kompressionstabellen erstellen, die einem Eintrag eine Farbe zuweisen, während RLE einfach wiederholte Sequenzen faktorisiert. Alle haben Vor- und Nachteile. Deshalb bieten wir auch eine „Auto“-Option an, mit der der Compiler auf der Grundlage der neuen Dateigröße und der Rendering-Zeit die optimalste Komprimierungsmethode auswählen kann.

Im Durchschnitt können die Benutzer mit einer Verringerung der Dateigröße zwischen 20% und 80% rechnen. Die Erfahrungen sind unterschiedlich, aber es ist leicht zu verstehen, warum so viele Benutzer eine solche Funktion gewünscht haben. In den meisten Fällen dauert das Rendern des Bildes doppelt so lange. Da Entwickler diese Funktion jedoch für statische Oberflächen, Icons oder kleinere Elemente verwenden, sind die Auswirkungen nicht spürbar, da das Rendern immer noch nur Millisekunden dauert. Außerdem bedeutet die drastisch geringere Dateigröße in vielen Fällen eine kürzere Abrufzeit aus dem Speicher, was die längere Renderingzeit ausgleicht. Einfach ausgedrückt: Die Speicheroptimierung gleicht den Nachteil der Dekomprimierung aus und bietet somit eine identische oder nahezu identische Leistung wie bei einem unkomprimierten L8-Asset, während weniger Speicherplatz benötigt wird.

Wenn Sie von einer Version von TouchGFX-Designer, die älter als 4.22 ist, umsteigen, müssen Sie die Komprimierungsmethode manuell auswählen. Unsere Teams haben das unkomprimierte Format als Standardverhalten beibehalten, weil wir nicht wollten, dass die Entwickler eine drastische Änderung in der Art und Weise sehen, wie das Framework ihre L8-Bilder handhabt, ohne zu verstehen, warum dies geschieht. Nichtsdestotrotz halten wir die Funktion für sehr symbolträchtig, da sie explizit unseren Wunsch zum Ausdruck bringt, den Speicherbedarf, insbesondere im Flash, zu optimieren und dabei die Leistung im Auge zu behalten.

QR-Code-Generator

QR-Codes werden immer beliebter, denn. Sie ermöglichen es einem Verbraucher beispielsweise, einen Code zu scannen und automatisch eine Seriennummer erscheinen zu lassen, was den Registrierungsprozess erheblich erleichtert. Auch die Weiterleitung zu einer bestimmten Support-Seite auf der Website eines Unternehmens wird viel einfacher, wenn niemand eine URL manuell eingeben muss. Außerdem können Hersteller ihre Website aktualisieren, ohne sich Sorgen machen zu müssen, dass die Benutzer die richtige Seite nicht finden. Die Herausforderung besteht darin, dass die Erstellung eines QR-Codes große externe Bibliotheken erfordern kann, die schlecht für Mikrocontroller optimiert sind. Darüber hinaus ist die Übergabe von Argumenten zur dynamischen Erstellung eines Codes und zum anschließenden Zeichnen im Framebuffer extrem komplex, um sie von Grund auf zu implementieren.

Aus diesem Grund führt TouchGFX einen QR-Code-Generator ein. Er kann dynamisch einen QR-Code der Stufe 40 (177 Module x 177 Module) erzeugen und in den Framebuffer einzeichnen. Anstatt einen Fehlercode anzuzeigen, könnten Entwickler einen QR-Code generieren, der den Benutzer auf die entsprechende Support-Seite weiterleitet. Wir unterstützen sogar die Fehlerkorrektur, um die Integrität der dargestellten Daten zu gewährleisten, was z. B. bei der Übertragung einer Seriennummer ein wichtiges Thema sein kann. Der QR-Code macht es auch einfacher, Symbole anstelle von alphanumerischen Zeichen zu senden, was für bestimmte Regionen nützlich ist.

Live-Anrufe

Die Komprimierung von L8-Bildern ist auch ein Beispiel dafür, dass wir besser mit unseren Benutzern kommunizieren müssen, um sie über neue Möglichkeiten zu informieren. TouchGFX wird häufig aktualisiert. Die Designer sind sich jedoch nicht immer bewusst, was gerade passiert. Wir haben zwar bereits E-Mail-Kampagnen, diesen Blog und die ST.com-Website, aber viele bitten uns trotzdem, eine direktere Kommunikation zu etablieren. Um dieser Bitte nachzukommen, haben wir Live-Callouts eingeführt. Das sind kleine Kästchen, die nur am unteren Rand des Lobby-Bildschirms erscheinen, um Benutzer auf Funktionen, Veranstaltungen oder eine Lösung von einem Partner hinzuweisen. Wenn Sie auf einen Live-Callout klicken, wird ein Popup-Fenster mit weiteren Details angezeigt oder ein Browserfenster zu ST.com geöffnet.

Wie der Name schon sagt, machen Live-Callouts die Benutzer auf bestimmte Funktionen oder Möglichkeiten aufmerksam. Sie existieren nur in der Lobby, um die Entwickler nicht abzulenken, während sie an ihrer Oberfläche arbeiten. Live-Callouts unterscheiden sich auch von Benachrichtigungen, die den Benutzer nur auf eine neue Version des Frameworks oder eine wichtige Nachricht aufmerksam machen. Sie sind weniger empfindlich, was bedeutet, dass die Entwickler nicht belastet werden, wenn sie sie nicht sofort sehen. Auch die Privatsphäre unserer Nutzer hat für uns Priorität. Wir passen die Live-Callouts für jede Region an, erheben aber keine Benutzerdaten. Die Standortdaten verbleiben auf den lokalen Rechnern, und TouchGFX-Designer entscheidet anhand des Standorts des Systems, was angezeigt wird.

Offline-Modus

Mit TouchGFX 4.22 wurde ein neuer Offline-Modus eingeführt, mit dem Benutzer Demos und Beispiele herunterladen können, um sie ohne Internetverbindung auszuführen. Wir liefern auch ein leistungsfähigeres Proxy-Konfigurations-Tool aus, um komplexen Konfigurationen gerecht zu werden. In vielen Fällen ist es nicht möglich oder schwierig, eine Online-Verbindung herzustellen. Manche Benutzer sehen sich mit Problemen konfrontiert, die ihren Arbeitsablauf behindern, sei es im Flugzeug oder aufgrund von Bandbreiten- oder Firewall-Beschränkungen. Dank des neuen Offline-Modus und des Proxy-Konfigurationstools ist es einfacher und praktischer, TouchGFX-Designer zu verwenden und von einem flüssigeren Arbeitsablauf zu profitieren.

Schnellere Flash-Programmierung

Mit TouchGFX-Designer 4.23 wurde die Möglichkeit geschaffen, nur für den internen Flash-Speicher bestimmten Code zu flashen, wodurch die Programmierzeit erheblich verkürzt wurde. Bis dahin lud TouchGFX bei der Kompilierung einer Benutzeroberfläche alle Elemente, auch die im externen Speicher gespeicherten, selbst wenn sie unverändert waren. Infolgedessen konnte die Kompilierung manchmal fast 10 Minuten dauern, selbst wenn die Entwickler keine ihrer extern gespeicherten Elemente aktualisiert hatten. Um die Arbeitsabläufe zu optimieren, enthält TouchGFX-Designer 4.23 eine Option, mit der nur der interne Flash programmiert werden kann, wodurch die Kompilierungsvorgänge auf wenige Sekunden reduziert werden. Entwickler sollten jedoch bedenken, dass eine Anwendung kaputt gehen kann, wenn sie vergessen, den externen Speicher zu flashen, nachdem sie einige der darin gespeicherten Daten geändert haben.

Unterstützung für X-NUCLEO-GFX01M2 und X-NUCLEO-GFX02Z1

Wenn Ingenieure sich für eine grafische Benutzeroberfläche entscheiden, wird das Display oft zur teuersten Komponente in ihrer Materialliste. Ein einfaches 2-Zoll-Display ohne Touch-Ebene wird das Benutzererlebnis erheblich verbessern, ist aber immer noch teurer als alles andere. Die Beschaffung eines erschwinglichen Bildschirms ist daher problematisch, wenn Sie einen BoM von fünf Dollar oder weniger anstreben. ST liefert daher Display-Erweiterungskarten aus, um Ingenieuren bei der Suche nach kostengünstigen Teilen zu helfen, und wir bieten Unterstützung für die Hardware in TouchGFX-Designer. Der Benutzer wählt die Konfiguration des Displays und kann mit der Arbeit an einer Schnittstelle beginnen, die seinen Spezifikationen entspricht.

Die erste Erweiterungskarte, die Ingenieure wählen können, ist die X-NUCLEO-GFX01M2. Es verwendet ein SPI-2,2-Zoll-QVGA-(320 x 240)-Display, das SPI-Flash unterstützt. und das würde zu einer Stückliste von etwa fünf Dollar für ein typisches Embedded-System mit externem Flash und einer zweilagigen Platine passen. Der X-NUCLEO-GFX01M2 ist mit einer breiten Palette von 64-Pin-NUCLEO-Boards kompatibel. Ingenieure können ihn zum Beispiel auf dem NUCLEO-WB55RG verwenden, um Bluetooth-Anwendungen zugänglicher zu machen.

Ebenso ist das X-NUCLEO-GFX02Z1 unser erstes Display-Erweiterungsboard, das eine parallele Schnittstelle, QSPI-Flash und Nucleo-Boards mit 144 Pins unterstützt. Die Plattform zielt auf Mikrocontroller mit mehr Leistung ab, was die Kompatibilität mit Schnittstellen erklärt, die höhere Bandbreiten bieten. Entwickler können den X-NUCLEO-GFX02Z1 mit dem NUCLEO-U575ZI-Q verwenden, der mit den ersten STM32U5s herauskam. Auf diese Weise können Ingenieure das bessere Verhältnis von Leistung pro Watt der neuen MCU nutzen, um Benutzeroberflächen zu erstellen, die bei früheren STM32-Generationen nicht möglich waren.

Videos in Benutzeroberflächen einbetten

Der Wunsch, mehr Benutzeroberflächen mit Videos auszustatten, ist eine natürliche Folge der wachsenden Beliebtheit von Displays auf Embedded-Systemen. Leider ist die Wiedergabe eines Videos auf einem Embedded-System mit einem Mikrocontroller eine Herausforderung. Es gibt kein Betriebssystem mit einem Standard-Media-Player und Codecs. Ebenso ist es unmöglich, eine Webseite zu schreiben, die ein YouTube-Video anzeigt. Die Entwickler müssen die ganze Arbeit machen, z.B. einen Videopuffer implementieren, herausfinden, welches Format auf ihrem Mikrocontroller am besten funktioniert, und bestimmen, wie sie die Vorteile der Hardwarebeschleunigung nutzen können, falls diese verfügbar ist. TouchGFX-Designer bietet ein Video-Widget, um diese Herausforderung zu lösen. Das Hinzufügen eines Videos erfordert also nur noch drei einfache Schritte.

Videos direkt in den Framebuffer

Eine weitere Funktion von TouchGFX 4.23, die darauf abzielt, den Speicherbedarf einer Anwendung zu reduzieren, ist die Möglichkeit, ein System automatisch so zu konfigurieren, dass es direkt in den Framebuffer schreibt. Traditionell werden bei der Anzeige eines Videos die Bilder zunächst in einem Videopuffer gespeichert, bevor sie in den Framebuffer übertragen werden, der die Anzeige speist. Dieser Zwischenschritt stellt sicher, dass alle Ressourcen verfügbar sind, um eine reibungslose Animation zu gewährleisten. Das Problem dabei ist, dass viel mehr Speicher benötigt wird, da die Videobilder in diesem Cache gespeichert werden müssen, bevor sie in den Framebuffer übertragen werden.

TouchGFX unterstützt schon seit einiger Zeit das Schreiben von Videobildern direkt in den Framebuffer für reines Software-Rendering. Der Versuch, den Hardware-MJPEG-Decoder und den Chrom-ART-Beschleuniger zu verwenden, erforderte jedoch eine manuelle und äußerst komplexe Implementierung, da die Entwickler Synchronisierungen und Low-Level-Treiber anpassen mussten. Infolgedessen war die Funktion für viele unerreichbar, da sie viel Fachwissen erforderte, um sie zu implementieren. TouchGFX 4.23 löst dieses Problem, indem es die Möglichkeit bietet, einen Mikrocontroller automatisch zu initialisieren, um Videobilder direkt in den Framebuffer zu schreiben und dabei die MJPEG-Engine und Chrom-ART-IP zu nutzen. Ab TouchGFX 4.23 wurde dies zum neuen Standardverhalten, wodurch sichergestellt wird, dass das Video-Widget sehr viel weniger Arbeitsspeicher zur Ausführung benötigt.

Exportieren von benutzerdefinierten Containern

In seiner einfachsten Form basiert TouchGFX-Designer auf Widgets, einer Darstellung einer Funktion, die auf dem Bildschirm gezeichnet wird. Die Software wird mit vielen vordefinierten Widgets geliefert, z. B. einer Anzeige, einer Uhr oder einem Diagramm, und Entwickler können auch eigene Widgets entwerfen. Um Widgets übersichtlicher zu gestalten, können Designer sie in einem Container gruppieren. Container sind oft die Bausteine einer Benutzeroberfläche. Sie ermöglichen es Programmierern, eine Reihe von Widgets auf mehreren Bildschirmen wiederzuverwenden, ohne sie jedes Mal neu konfigurieren zu müssen. Außerdem wirkt sich die Änderung eines Containers auf jeden Bildschirm aus, der ihn verwendet, was die Entwicklung erheblich vereinfacht. TouchGFX verfügt auch über vordefinierte Container, um die gängigsten Designvorgänge zu beschleunigen, und Entwickler können eigene Container erstellen.

Benutzerdefinierte Container erfreuen sich großer Beliebtheit, da sie es Entwicklern ermöglichen, ihre Oberfläche zu optimieren und eine genaue Vision zu entwerfen. Die Herausforderung bei jedem Design-Tool ist jedoch, dass die Arbeit an einem Projekt nur selten in eine andere Benutzeroberfläche exportiert werden kann. Ein benutzerdefinierter Container enthält nämlich Code, grafische Elemente, Texte, Abhängigkeiten und vieles mehr, das ihn an das bestehende Projekt bindet. Seit Version 4.20 hat TouchGFX-Designer dieses Problem gelöst, indem er eine Exportfunktion anbietet, die ein Bundle (.tpkg-Datei) erstellt, das in anderen Projekten wiederverwendet werden kann. Das Dienstprogramm fügt alle Elemente, einschließlich der Schriftarten, zum Bundle hinzu und listet den Inhalt in einer XML-Datei auf. Entwickler können diese Datei also überprüfen und ändern, um auszuwählen, was sie exportieren möchten.

Importieren von benutzerdefinierten Containern

Um einen benutzerdefinierten Container zu importieren, wählen Sie Bearbeiten -> Importieren -> Benutzerdefinierter Container. TouchGFX enthält ein neues Importprogramm, das Sie durch den Prozess führt. So erkennt die Software beispielsweise die vom benutzerdefinierten Container definierten Sprachen und gleicht sie mit den im neuen Projekt verfügbaren Sprachen ab oder ignoriert sie. Das System hält den Importprozess auch an, wenn es einen Konflikt zwischen generischen Namen gibt oder wenn ein Problem innerhalb der neuen Schnittstelle Probleme verursachen könnte. TouchGFX-Designer zwingt die Benutzer dazu, Probleme im ursprünglichen benutzerdefinierten Container zu beheben, anstatt während des Importvorgangs Umgehungslösungen zu schaffen. Da der Zweck der Funktion darin besteht, das Erscheinungsbild von Benutzeroberflächen über verschiedene Produkte hinweg beizubehalten, wird durch das Erzwingen von Änderungen innerhalb des ursprünglichen Projekts die Konsistenz der Benutzeroberflächen sichergestellt.

CacheableContainers

Wie der Name schon sagt, verwendet es einen Bitmap-Cache, um die grafische Leistung zu beschleunigen und eine höhere Bildrate für flüssigere Übergänge zu ermöglichen. Die unten stehende Demo läuft auf einem STM32F429I Discovery Kit. Ohne CacheableContainers läuft die einfache bildschirmfüllende (240 × 320) Dia-Animation mit neun Bildern pro Sekunde. Mit der TouchGFX-Technologie erreicht das System 60 Bilder pro Sekunde. Einige Smartwatches nutzen diese Funktion, um ein nahtloses Benutzererlebnis zu gewährleisten, trotz der erheblichen Hardwarebeschränkungen, die mit ihrem Formfaktor verbunden sind, und der Notwendigkeit einer längeren Akkulaufzeit. Neben Animationen kann CacheableContainers auch komplexe Widgets optimieren, z. B. Texture Mapper oder kleine dynamische Elemente, die vor einem statischen Hintergrund angezeigt werden.

Ohne CacheableContainers muss eine Animation bei jedem Bild neu gezeichnet werden, was sehr rechenintensiv werden kann. CacheableContainer umgeht dieses Problem, indem es das erste und das letzte Bild in einem separaten Container als Bitmap speichert, den das System im RAM hält. Anstatt die Animation zu rendern, ruft das System die beiden Bilder mit DMA aus dem Speicher ab und zeigt sie dank einer einfachen DynamicBitmap-Methode an verschiedenen Stellen an. Die MCU generiert nicht mehr jeden Frame, wodurch die Leistung erheblich optimiert wird. Die Entwickler müssen lediglich das Kästchen Cacheable im TouchGFX-Designer anklicken, den Speicherort der Container auswählen, die sie zwischenspeichern möchten, und diese bei Bedarf aufrufen. Mit dieser Technik sinkt die Renderzeit von 100 ms auf 5 ms.

Partieller Framebuffer

Ein Framebuffer ist ein zusammenhängender Speicherbereich, der eine Darstellung jedes Pixels speichert, das auf dem Display angezeigt wird. Ein Standard 24-Bit 390 x 390 Bild für ein Smartwatch-Display erfordert beispielsweise einen Framebuffer von 3.650.400 Bits oder 456,3 KB(latex\div8[/latex]), was mehr als 70% des auf dem STM32L4+ verfügbaren SRAM ausmacht , der sich auf Smartwatches und Wearables auszeichnet. Und diese Zahl kann explodieren, wenn eine Anwendung mehr als einen Framebuffer benötigt. Abgesehen von den Kapazitätsbeschränkungen dauert der Abruf eines großen Framebuffers länger, da mehr Daten vom Speicher zum Display übertragen werden müssen, was die Leistung verlangsamt.

Wie der Name schon sagt, speichert der Partielle Framebuffer nur einen Teil des Framebuffers und reduziert damit seinen Speicherbedarf um den Faktor 10. Entwickler können seine Größe entsprechend dem sich ändernden Bildschirmausschnitt konfigurieren und dann mehrere Teilpuffer speichern. Das Framework wählt dann den passenden aus und sendet ihn an das Display. Die Technologie funktioniert am besten mit kurzen Animationen wie Uhren, Ladebalken oder einem Diagramm, das sich mit der Zeit aufbaut. Sie erfordert außerdem, dass der Bildschirm einen eingebetteten Controller verwendet, da er den partiellen Framebuffer direkt aus dem RAM der MCU empfängt und so das Flash umgeht, was zu mehr Leistung führt. Die Technologie funktioniert mit Parallel/8080-, DSI- und SPI-Displays.

TouchGFX optimiert auch den partiellen Framebuffer, um UIs auf ressourcenbeschränkte Mikrocontroller zu bringen. Traditionell würde eine minimale grafische Oberfläche einen Framebuffer von etwa 200 KB erfordern. Wenn ein Mikrocontroller wie der STM32G071 jedoch nur 36 KB RAM hat, kann dies ein echtes Problem darstellen. TouchGFX löst dieses Problem durch die Optimierung des partiellen Framebuffers auf nur sechs Kilobyte. Unter Berücksichtigung der Anwendungsdaten des Frameworks benötigt eine Einstiegs-UI nur 16 KB RAM für die Ausführung. TouchGFX verwendet auch intelligente partielle Bildschirmaktualisierungen. Diese Funktion ergänzt das partielle Framebuffering, um die Reihenfolge der Aktualisierungen auf dem Bildschirm zu optimieren. Der Prozess spart Ressourcen und ermöglicht so mehr Aktualisierungen im gleichen Zeitraum.

Unterstützung für skalierbare Vektorgrafiken (SVG)

Mit TouchGFX 4.21 wurde die Unterstützung für SVG eingeführt. Traditionell speichert das Framework Rasterbilder, wie z.B. PNG-Dateien, da diese leicht zugänglich sind und angezeigt werden können. Im Gegensatz dazu enthalten SVG-Dateien keine Darstellung, sondern Anweisungen, wie sie zu zeichnen sind. Dadurch sind sie zwar hoch skalierbar, aber auch deutlich anspruchsvoller. Und während das auf einem Laptop oder Desktop kein Problem ist, sieht es auf einem Mikrocontroller mit geringem Stromverbrauch schon ganz anders aus. Das Problem ist, dass Designer zunehmend animierte Benutzeroberflächen erstellen und eine Benutzeroberfläche auf verschiedene Displaygrößen skalieren wollen. Daher möchten Teams SVG-Dateien verwenden, um Ressourcen zu sparen, da eine Datei auf viele verschiedene Arten gezeichnet werden kann und weniger Platz im Speicher benötigt.

ST verwendet seinen neuen NeoChrom-2.5D-Beschleuniger, der auf bestimmten STM32U5s verfügbar ist, um diese neue Herausforderung zu meistern. Die Hardware, die das Zeichnen von Animationen optimiert, entlastet einige der mit SVG-Dateien verbundenen Berechnungen und löst so das Leistungsproblem. Die IP nutzt außerdem schnellere Speicherschnittstellen, was die Abrufvorgänge beschleunigt, und die Datei ist oft kleiner. Folglich gibt es weniger Nachteile beim Speichern von Dateien im externen Speicher. Letztlich ist die Ankündigung höchst symbolisch, denn SVG stand nicht auf der Liste der Funktionen, als wir im Mai 2022 über NeoChrom sprachen. Die heutige Veröffentlichung zeigt jedoch, dass die IP über ein großes Potenzial verfügt und dass ST auch weiterhin neue Funktionen veröffentlichen wird, die diese Fähigkeiten nutzen.

XML-Datei für Text

Designteams speichern Texte oft in einer Excel-Datei, um mit verschiedenen Übersetzern weltweit zu arbeiten. Anstatt jedoch Versionskontrollsysteme wie Git zu verwenden, müssen die Redakteure Änderungen manuell bearbeiten und sicherstellen, dass niemand versehentlich die Arbeit eines anderen überschreibt, was mühsam sein kann. Um dieses Problem zu lösen, speichert TouchGFX den gesamten Text in einer XML-Datei. Das Format macht Zusammenführungsvorgänge und Konfliktlösungen viel einfacher. TouchGFX enthält auch einen XML-zu-Excel-Konverter, der sich in bestehende Arbeitsabläufe einfügt. Entwickler können nach Excel exportieren und dann ihre Excel-Datei wieder in TouchGFX und sein XML-Format importieren.

Optimierte Projektdateien

TouchGFX fördert auch die Zusammenarbeit dank kleiner Projektdateien. Dank ihrer Größe lassen sie sich leichter zusammenführen und möglicherweise gemeinsam nutzen. Früher wurden in den Projektdateien alle Parameter in einem JSON-Format gespeichert. Das Problem ist, dass eine solche Datei ziemlich groß werden kann. ST hat daher beschlossen, die Projektdateien zu optimieren, indem nur noch benutzerdefinierte Einstellungen gespeichert werden. Daher wird alles, was nicht in der Datei enthalten ist, als Standardwert behandelt. Folglich ist die Datei viel kleiner, was das Zusammenführen auf Git viel einfacher und schneller macht.

Einmaliger Text und seine zufällige ID

Entwickler, die Text verwenden möchten, müssen eine Ressource im Text-Panel von TouchGFX-Designer erstellen und dann die ID des Textes in der Benutzeroberfläche verwenden. TouchGFX ermöglicht jedoch auch „Einwegtext“, der nicht als typische Textressource erscheint. Entwickler verwenden es beim Testen oder wenn ein Text unwichtig ist. Dadurch wird verhindert, dass die Datenbank mit irrelevanten Texten gefüllt wird, und Sie können schneller Prototypen erstellen. Die Funktion für Einwegtexte generiert nämlich automatisch eine ID und löscht, im Gegensatz zu normalen Textressourcen, die Ressource aus der Datenbank, wenn sie aus der Benutzeroberfläche gelöscht wird. TouchGFX verwendet auch einen Zufallsgenerator für die ID-Erstellung. Daher ist es fast unmöglich, dass zwei Text-IDs für die einmalige Verwendung im selben Projekt identisch sind.

TouchGFX-Stock

Kostenlose Bildbibliothek

TouchGFX-Stock ist die größte Bibliothek mit kostenlosen grafischen Elementen für Benutzeroberflächen, die von einem Framework für Mikrocontroller bereitgestellt wird. Sie umfasst Icons, GUI-Elemente, Themen, Bilder und mehr. Da die Icons aus der frei verwendbaren Bibliothek von Google stammen und ST die Rechte an allen anderen Ressourcen besitzt, verfügt TouchGFX-Stock über eine großzügige Lizenz, die es Teams erlaubt, die Elemente kostenlos, sogar für kommerzielle Projekte, zu verwenden, solange sie auf STM32-Geräten laufen. Die Benutzer können die Elemente nutzen, um sie für ihre Benutzeroberfläche zu verkleinern oder sie an ihre speziellen Bedürfnisse anzupassen. Die Lizenz deckt sogar die Verwendung dieser Elemente mit einem anderen grafischen Framework ab, solange das Programm auf einem ST-Mikrocontroller läuft.

In letzter Zeit haben viele Startups TouchGFX-Platzhalter oder Beispiel-Elemente für ihr Design wiederverwendet. Dieser neue Trend ist auf die Zunahme kleinerer Teams zurückzuführen, die nicht die Ressourcen haben, um in Designer zu investieren. Wenn sie TouchGFX übernehmen, finden einige Entwickler die Platzhalter elegant und fügen sie in ihre endgültigen Oberflächen ein. Aus diesem Grund haben wir uns entschieden, in TouchGFX-Stock zu investieren, und wurden so zum MCU-Anbieter mit der umfangreichsten lizenzfreien Bibliothek für grafische Elemente. Das erklärt auch unseren Ansatz bei der Lizenzierung. Im Laufe der Jahre haben wir uns bemüht, GUIs auf MCUs leichter zugänglich zu machen. Dies ist ein weiterer Baustein auf diesem Gebäude, und wir sind entschlossen, diese Bibliothek im Laufe der Zeit mit neuen Themen, Bildern und mehr zu erweitern.

Ein kostenloser Designer zu Ihren Diensten

In der Zwischenzeit enthält TouchGFX-Stock UI-Elemente wie Balken, Popups, Uhren, Messgeräte und vieles mehr. Wir bieten auch helle und dunkle Versionen einiger Elemente an. Letztendlich ist TouchGFX 4.21 eine Lektion in Sachen Design. Ingenieure müssen sich keine Gedanken über unpassende Farbpaletten machen oder sich auf antiquierte Designvorstellungen verlassen. Wir stellen Sets zur Verfügung, damit die Benutzeroberflächen kohärent und modern bleiben. Außerdem bieten wir verschiedene Größen an, die auf die meisten Bildschirme passen, so dass viele die Größenanpassung nicht einmal selbst vornehmen müssen. TouchGFX-Stock wird zum Start mit fünf Themen geliefert. Aufgrund der Beschaffenheit von GUIs auf MCUs erfolgt der Wechsel zwischen den Themen jedoch nicht automatisch. Da es keine Eins-zu-Eins-Beziehung zu allen Elementen gibt, müssen die Benutzer sie manuell ersetzen.

Animationen und Widgets

Einschubübergänge und dynamische Diagramme

Die Herausforderung für Entwickler besteht darin, die Vorteile aller Funktionen zu nutzen, die wir TouchGFX ständig hinzufügen. Daher bieten wir optimierte Animationen an, die die oben genannten Funktionen bereits nutzen. Während zum Beispiel ein herkömmlicher Slide-In-Übergang eine komplette Aktualisierung des Bildschirms erfordert, verbraucht die Wischanimation von TouchGFX viel weniger Ressourcen. In ähnlicher Weise zeigt das dynamische Diagramm-Widget sequenzielle Daten besser und mit weniger Auswirkungen auf den RAM und den Mikrocontroller an.

Statische Diagramme

Wenn Wearables Umwelt- oder Körperdaten aufzeichnen, möchten die Benutzer den Fortschritt sehen. Graphen können die Herzfrequenz, die Temperatur, die gelaufenen Schritte und mehr anzeigen. TouchGFX-Entwickler haben zuerst nach dynamischen Graphen gefragt, da diese schwierig zu implementieren sind, und diese Funktion ist seit TouchGFX 4.15 verfügbar. Jetzt geben unsere Teams statische Graphen frei, um neue Anwendungen zu ermöglichen. In der Tat eignen sich Daten, die sich nicht ständig weiterentwickeln müssen oder nur geringe Veränderungen im Laufe der Zeit erfahren, besser für eine statische Darstellung. Die neuen Diagramme funktionieren etwas anders. Bei dynamischen Diagrammen müssen die Entwickler nur einen Datenpunkt senden, da das Zeitintervall konstant ist. Bei statischen Diagrammen müssen die Programmierer jedoch Informationen für die X- und Y-Achse eingeben.

Uhren und Textur-Mapper

TouchGFX verfügt auch über Widgets, die Anwendungen wie analoge und digitale Uhren imitieren. Außerdem gibt es einen Textur-Mapper, d.h. Entwickler können ihr Mapping-Programm einfach per Drag & Drop erstellen. Sie müssen zwar immer noch ihren C++-Code eingeben, aber der ganze Prozess wird dadurch viel reibungsloser ablaufen. Der Texture Mapper ist auch ein großartiges Beispiel für TouchGFX-Optimierungen auf ressourcenbeschränkten MCUs. Er kann bei der Animation von Objekten helfen und funktioniert sogar auf einem STM32G0, solange sich das grafische Element im RAM und nicht im Flash befindet.

Messgerät

Die Vorlage für das Messgerät zeichnet eine Nadel und einen Bogen, um den Benutzern die Überwachung der Werte zu erleichtern. Die Entwickler können auch den Hintergrund, die Ausrichtung der Nadel, den Wertebereich und vieles mehr ändern. Die Demo unten zeigt, wie Programmierer zwischen ihrer IDE und TouchGFX-Designer wechseln können, um einen flüssigeren Arbeitsablauf zu gewährleisten. Teams können das Messgerät schnell überprüfen, es spontan anpassen und ihren Code sofort testen. Das Video zeigt zum Beispiel, wie die Funktion handleTickEvent() das Verhalten des Indikators steuert. Mit nur wenigen Codezeilen können Entwickler unter anderem den Wertebereich und die Häufigkeit der Aktualisierung des Indikators ändern. Solche Optimierungen können in Anwendungen, die den angezeigten Wert nicht ständig erneuern müssen, eine Menge Ressourcen einsparen.

Erweiterte Textverwaltung

Text ist für die meisten grafischen Benutzeroberflächen unverzichtbar, was erklärt, warum Designer so viel daran arbeiten. Sie passen ihn an, übersetzen ihn und formen ihn. Einige Anwendungen, die mit TouchGFX-Designers erstellt wurden, können Tausende von Textressourcen enthalten, die jeweils in viele Sprachen übersetzt sind. Das Problem ist, dass die Arbeit mit Text mühsam sein kann. Um die Reibungsverluste zu verringern, bietet TouchGFX jetzt Gruppen an, die Entwickler nach einem Abschnitt oder einer Funktion ihrer Anwendungen definieren können. Die neue Funktion macht es einfacher, übersetzten Text im TouchGFX-Designer nebeneinander anzuzeigen. Außerdem hilft sie, relevante Informationen zu bündeln, um sie auf Konsistenz und Genauigkeit zu prüfen. Schließlich erleichtern Gruppen die Suche und das Auffinden bestimmter Ressourcen.

TouchGFX-Designer enthält auch eine Typographies Option, um Standardparameter innerhalb von Gruppen festzulegen. In diesem Abschnitt können Sie Schriftarten, Fallback-Zeichen, Platzhalter, Ausrichtung usw. festlegen. Bisher mussten die Entwickler die Parameter für jede Textressource überschreiben, was eine Menge Arbeit bedeuten konnte. Dank der Gruppen ist es möglich, Parameter für viele Ressourcen gleichzeitig einzustellen und so die Entwicklung zu optimieren. Bei bestehenden Projekten mit benutzerdefinierten Typografien werden deren Einstellungen in den neuen Bereich verschoben. Die neue Textschnittstelle zeigt auch Texte zur einmaligen Verwendung an und ermöglicht es, diese bei Bedarf in eine Ressource zu verschieben.

• TouchGFX 4.25 herunterladen