Grafikübersicht¶

Grafikarchitektur planen¶

Dieser Leitfaden erklärt, wie sich auf SF32-Geräten reaktionsschnelle grafische Benutzeroberflächen entwickeln lassen. Im Mittelpunkt stehen praktische Entscheidungen für das Produkt: Display-Auswahl, Framebuffer-Strategie, LVGL-Integration, ePicasso-Hardwarebeschleunigung, Speicherzuordnung und Aktualisierungsverhalten.

SF32-Geräte eignen sich für kompakte AIoT- und Wearable-Produkte mit strengen Vorgaben für Stromverbrauch, Speicher und Leiterplattenfläche. Gleichzeitig soll sich die Benutzeroberfläche flüssig bedienen lassen. Der Grafikpfad trennt Ressourcenverarbeitung, Pixelkomposition, optionale Framebuffer-Kompression und Panel-Ausgabe. Wer diese Aufgaben auseinanderhält, kann gezielter optimieren.

Nutzen Sie diese Seite für frühe UI-Architekturentscheidungen, die sich später nur mit hohem Aufwand ändern lassen: Panel und Schnittstelle, Framebuffer-Strategie, Farbtiefe, Transparenz, Ablage der Ressourcen und Aktualisierungsrichtlinie. Die verlinkten Grafikartikel erläutern die Implementierung der einzelnen Schritte.

SF32-Grafikablauf¶

Der typische Pfad für Display-Ressourcen ist:

Source images, fonts, and animations
        │
        ▼
GraphicsTool converts supported resources to eZip or eZip-A
        │
        ▼
Compressed assets in NOR Flash, PSRAM, NAND, or file storage
        │
        ▼
eZip hardware decoder expands an asset when required
        │
        ▼
LVGL or another UI framework + graphics/display driver
        │
        ├── CPU fallback rendering
        │
        └── ePicasso pixel acceleration
        │
        ▼
Final rendered bitmap in a draw buffer or framebuffer
        │
        ├── Uncompressed display path
        │
        └── Optional: extDMA compresses it into TurboPixel
                    │
                    ▼
             TurboPixel framebuffer in PSRAM
        │
        ▼
Display controller transfers pixels to the panel
        │
        ▼
SPI / QSPI / 8080 / RGB / MIPI DSI / EPD / JDI panel

Der Grafikpfad lässt sich flexibel zusammenstellen; ein Produkt kann auch ohne eZip, ePicasso, TurboPixel oder einen vollständigen Framebuffer auskommen. Verfügbarkeit und Anbindung hängen vom Gerät, SDK, der Display-Schnittstelle, dem Panel und der Treiberkonfiguration ab. Der aktuelle OpenSiFli-LCDC-Header definiert LCDC_SUPPORTED_COMPRESSED_LAYER nur, wenn HAL_EXTDMA_MODULE_ENABLED aktiviert ist und die Familienbedingung erfüllt wird; SF32LB52x und SF32LB57x sind ausgeschlossen. Ein Quellcodekommentar weist außerdem darauf hin, dass der LCPU-Pfad nicht aktiviert ist. Die veröffentlichte SDK-LCDC-Funktionstabelle kennzeichnet die Dekomprimierung komprimierter Ebenen auf SF32LB55x als nicht unterstützt. Daher ist 55x als bedingt und nicht als end-to-end validiert zu betrachten. Prüfen Sie die genaue SDK-Version, den Kern, die Build-Konfiguration und die Zielhardware; weitere Hinweise finden Sie unter TurboPixel.

Der Anwendungscode beschreibt Zustand und Verhalten der Benutzeroberfläche. Das UI-Framework verwaltet Widgets, zu aktualisierende Bereiche und das Zeichnen. Der Grafik-/Displaytreiber entscheidet, ob die CPU oder ePicasso eine Operation ausführt, und koordiniert die Puffer. Der Display-Controller übernimmt die Übertragung an das Panel. Details zu den einzelnen Funktionen finden Sie unter ePicasso, eZip und TurboPixel.

Zuerst das Display auswählen¶

Die Display-Wahl beeinflusst nahezu jede Grafikentscheidung. Definieren Sie die Panel-Anforderungen klar, bevor Sie Code optimieren:

• Auflösung.
• Farbtiefe.
• Aktualisierungsrate.
• Schnittstellentyp.
• Anforderungen an den Touch-Controller.
• Hintergrundbeleuchtung oder Display-Versorgungsspannungen.
• Ob Teilaktualisierung unterstützt wird.
• Ob das Panel internes GRAM hat.
• Ob stromsparendes Always-on-Display-Verhalten erforderlich ist.

Ein kleines SPI- oder QSPI-AMOLED verhält sich ganz anders als ein RGB- oder MIPI-DSI-Panel, ein JDI-Memory-Display oder ein EPD-Panel. Dasselbe UI-Framework kann für viele Displaytypen eingesetzt werden, doch die passende Pufferstrategie und Aktualisierungsrichtlinie unterscheiden sich.

Informationen zur Schnittstellenauswahl, zum Flush-Pfad und zur Inbetriebnahme des Panels finden Sie unter Display-Controller.

Mit einem verifizierten LVGL-Beispiel beginnen¶

Wählen Sie zunächst ein SDK-Beispiel, das den grafischen Aspekt mit dem größten Produktrisiko bereits abdeckt. LVGL-SDK-Beispiele ordnet offizielle Beispiele zu Basisfunktionen, Designtools, Widgets, komprimierten Ressourcen, Animation und Medien, Kompass, Spielen und Uhrenoberflächen nach der jeweiligen technischen Aufgabe. Außerdem zeigt die Seite, welche Annahmen zu Board, Version, Display, Speicher und Leistung bei der Produktanpassung erneut geprüft werden müssen.

Das richtige SF32-Gerät wählen¶

Wählen Sie den Chip anhand des Displays und der UI-Arbeitslast, nicht nur der CPU-Frequenz.

Die wichtigsten Einschränkungen sind Display-Schnittstelle, Auflösung, Speicherkapazität, Generation des Grafikbeschleunigers, verfügbare Pins und Leistungsbudget.

Framebuffer- und Bandbreitenrechner¶

Schätzen Sie Speicher- und Übertragungskosten, bevor Sie ein Panel oder einen Animationsstil wählen:

framebuffer bytes = width x height x bytes_per_pixel
raw full-frame bandwidth = framebuffer bytes x frames_per_second

Beispiele:

Die Puffergrößen sind in KiB (1 024 Byte), die Bandbreite in dezimalen MB/s (1 000 000 Byte/s) angegeben. Die Werte berücksichtigen nur die Rohdaten der Pixel. Befehls-Overhead, Ausrichtung, Cache-Wartung, Lesen von Ressourcen, Blending und sonstige Datenbewegungen im System sind nicht enthalten. Wenn das Produkt gleichzeitig Bluetooth-Audio oder KI nutzt oder andere Zugriffe auf externen PSRAM anfallen, planen Sie zusätzliche Reserven ein.

Die verschiedenen Puffer verstehen¶

Eine UI wird letztlich als Pixel im Speicher dargestellt. Die wichtigsten Puffertypen sind:

Ein Vollbild-Framebuffer ist bequem, kann bei größeren Panels aber zu viel SRAM belegen. Ein 454 × 454 großer RGB565-Puffer enthält 412 232 Byte (etwa 412 kB bzw. 403 KiB); zwei Puffer benötigen die doppelte Kapazität. Mit höherer Farbtiefe und größerer Auflösung steigt der Bedarf schnell.

Wenn der Speicher knapp ist, verwenden Sie partielle Zeichenpuffer und aktualisieren Sie nur geänderte Bereiche. Ist Animation wichtig und genügend Speicher vorhanden, kann ein Vollbild-Framebuffer oder Doppelpufferung die UI flüssiger machen.

Farbtiefe sorgfältig wählen¶

Die Farbtiefe beeinflusst visuelle Qualität, Speicherverbrauch und Busbandbreite.

Für die meisten Wearables und kompakten HMI-Produkte ist RGB565 eine gute Ausgangswahl, sofern Panel, gewünschte UI-Qualität oder Produktanforderungen keine höhere Farbtiefe verlangen.

Transparenz, Alpha und Ebenenzusammensetzung¶

Transparenz wird durch den Alpha-Faktor angegeben. Er bestimmt, wie stark ein Vordergrundpixel beim Zeichnen über einem Hintergrundpixel in das Ergebnis eingeht. Alpha ist unabhängig von den RGB-Farbkanälen. Ein opaker Pixel hat den Alpha-Wert 1 (oder 255 in einem 8-Bit-Alphakanal), ein vollständig transparenter Pixel den Wert 0.

Bei der Source-over-Komposition auf einen undurchsichtigen Hintergrund, mit nicht vormultiplizierten RGB-Farbwerten im Vordergrund und einem Alpha-Wert von 0 bis 1, wird jeder Ausgabe-RGB-Kanal wie folgt berechnet. Diese vereinfachte Formel berechnet nicht den Ausgabe-Alpha-Wert eines transparenten Ziels:

output = foreground × alpha + background × (1 − alpha)

Ein Symbolpixel mit 50 % Alpha trägt beispielsweise die Hälfte seiner Farbe bei und lässt die Hälfte des Hintergrunds sichtbar. Die Wiederholung dieser Operation erzeugt den visuellen Stapel einer UI: einen Hintergrund, Bilder, Text, durchscheinende Steuerelemente, Schatten und Animationsebenen. Die finale zusammengesetzte Bitmap durchläuft anschließend die oben gezeigten Framebuffer- und Display-Controller-Stufen.

RGB565 enthält keinen Alphakanal und wird daher normalerweise für opake Zeichenziele und finale Framebuffer verwendet. Quell-Assets oder Zwischenebenen, die Alpha benötigen, verwenden üblicherweise ein Format mit Alphakanal, wie ARGB8888, oder ein Farbbild plus separate Alphamaske. Der Treiber muss die tatsächlich vom SDK, Display-Pfad und gewählten Beschleuniger unterstützten Formate verwenden.

Zwei Alpha-Darstellungen sind üblich. Bei nicht vormultipliziertem Alpha (straight alpha) beschreibt RGB die ursprüngliche Farbe, und Alpha wird beim Blending angewendet. Bei vormultipliziertem Alpha (premultiplied alpha) wurde RGB bereits mit Alpha multipliziert; die Source-over-Gleichung wird zu output = premultiplied_foreground + background × (1 − alpha). Verwechseln Sie die beiden Darstellungen nicht: Werden nicht vormultiplizierte Daten als vormultipliziert interpretiert oder umgekehrt, entstehen dunkle oder helle Säume an den Kanten.

Alpha-Blending liest sowohl Vordergrund- als auch Zielpixel und schreibt dann das Ergebnis. Es erhöht daher den Speicherverkehr im Vergleich zu einer einfachen opaken Kopie oder Füllung. Nutzen Sie ePicasso, wo der Treiber die gewählte Blend-Operation und Pixelformate unterstützt; andernfalls behalten Sie einen CPU-Fallback bei. Begrenzen Sie durchscheinende Vollbildebenen, aktualisieren Sie nur invalidierte Bereiche und vermeiden Sie unnötige Zwischenoberflächen, wenn PSRAM-Bandbreite oder Stromverbrauch knapp sind.

LVGL integrieren¶

LVGL eignet sich für UIs auf SF32-Geräten und stellt Widgets, Stile, Eingabeverarbeitung, Animation, Bereichsinvalidierung und Schnittstellen zum Displaytreiber bereit.

Eine typische LVGL-Integration benötigt:

• Einen Display-Treiber-Flush-Callback.
• Einen oder mehrere Zeichenpuffer.
• Eine Tick-Quelle für das LVGL-Timing.
• Eingabegerätetreiber für Touch, Tasten, Encoder oder Gesten.
• Asset-Verarbeitung für Bilder und Schriftarten.
• Optionale Hardware-Beschleunigungs-Hooks für ePicasso.

Der Display-Flush-Callback bildet die Grenze zwischen Rendering und Ausgabe. Das Verhalten des Controllers und des DMA ist unter Display-Controller beschrieben.

LVGL-Portierungsentscheidungen¶

Legen Sie diese LVGL-Integrationsdetails fest, bevor Sie Bildschirme verfeinern:

Eine gute LVGL-Portierung sollte es dem Bildschirmcode erlauben, deklarativ zu bleiben, während der Treiber Übertragung, Synchronisation, Beschleunigung und Cache-Verhalten übernimmt.

ePicasso-Beschleunigung nutzen¶

ePicasso ist nützlich, wenn die UI Operationen enthält, die andernfalls viele wiederholte Pixelberechnungen erfordern würden. Häufige Kandidaten sind:

• Rechteckfüllungen.
• Bildkopie- und Blit-Operationen.
• Alpha-Blending.
• Bildskalierung.
• Rotation oder Transformation unterstützter Bildbereiche.
• Ebenenzusammensetzung.
• Pixelformatkonvertierung, sofern vom Treiber unterstützt.

Eine gute Portierung sollte häufige, volumenstarke Operationen beschleunigen und dabei CPU-Fallback-Pfade für nicht unterstützte Fälle beibehalten. Gehen Sie nicht davon aus, dass jeder LVGL-Stileffekt oder jedes Widget auf Hardware abgebildet wird. Messen Sie die tatsächlichen Bildschirme, die für das Produkt wichtig sind.

Wann Beschleunigung am meisten hilft¶

ePicasso hilft üblicherweise am meisten, wenn:

• Große Bereiche gefüllt, kopiert, geblendet, skaliert oder transformiert werden.
• Die UI transparente Symbole, Textmasken, Schatten, Overlays oder animierte Übergänge verwendet.
• Die CPU andernfalls einen großen Teil jedes Frames mit Pixelschleifen verbringen würde.
• Speicherplatzierung und Pixelformate zu dem passen, was der Beschleuniger effizient verarbeiten kann.

Wann Beschleunigung möglicherweise wenig hilft¶

Hardwarebeschleunigung bietet möglicherweise begrenzten Nutzen, wenn:

• Der aktualisierte Bereich sehr klein ist.
• Der Engpass die Panel-Übertragungsbandbreite ist, nicht das Rendering.
• Assets nicht unterstützte Formate oder aufwändige Konvertierung erfordern.
• Puffer in langsamem Speicher ohne ausreichende Bandbreite liegen.
• Der Cache-Wartungsaufwand die Operation dominiert.

Strategie der Speicherzuordnung¶

Die Grafikleistung wird häufig durch den Datentransfer zwischen Speichern begrenzt. Ordnen Sie Puffer deshalb gezielt zu:

• Legen Sie häufig genutzte Zeichenpuffer nach Möglichkeit in schnellem SRAM ab.
• Halten Sie große Framebuffer nur dann in PSRAM, wenn SRAM nicht ausreicht.
• Speichern Sie große Bilder und Schriftarten in Flash oder PSRAM, berücksichtigen Sie dabei aber die Zugriffslatenz.
• Vermeiden Sie wiederholte Laufzeitkonvertierungen von Assets.
• Richten Sie DMA-zugängliche Puffer gemäß den SDK-Vorgaben aus.
• Nutzen Sie komprimierte oder indizierte Assets, wenn sie die Gesamtbandbreite und Dekodierkosten reduzieren.

Wenn CPU und Grafik- oder Display-Hardware Puffer gemeinsam nutzen, beachten Sie die SDK-Regeln für Cache-Wartung und Pufferbesitz. Bevor die Hardware CPU-Daten liest, führen Sie für die betroffenen Cache-Zeilen eine Clean-Operation aus und schließen die erforderliche Synchronisierung ab. Bereiten Sie den Puffer vor einem Hardware-Schreibzugriff so vor, dass veränderte CPU-Cache-Zeilen das Ergebnis nicht später durch Zurückschreiben überschreiben. Warten Sie das Ende der Übertragung ab und invalidieren Sie veraltete Cache-Zeilen, bevor die CPU das Ergebnis liest. Beachten Sie die Cache-Zeilen-Ausrichtung und benachbarte Daten; verändern Sie keinen Puffer, solange die Hardware ihn besitzt. Verwenden Sie die unterstützten SDK-Routinen: Clean und Invalidate sind nicht austauschbar.

Für Teilaktualisierung, panelspezifisches Verhalten und den gestuften Inbetriebnahmeablauf siehe Display-Controller.

Grafikressourcen vorbereiten¶

Gut vorbereitete Grafikressourcen können die UI beschleunigen, bevor Sie den Code optimieren.

Nutzen Sie diese Faustregeln:

• Passen Sie die Bildabmessungen an die tatsächliche Bildschirmgröße an.
• Vermeiden Sie es, große Bilder in jedem Frame zu skalieren.
• Rendern Sie komplexe Schatten, Farbverläufe oder Hintergründe nach Möglichkeit vor.
• Verwenden Sie Alpha nur dort, wo Transparenz benötigt wird.
• Bevorzugen Sie gemeinsam genutzte Symbolsätze und Schriftart-Teilmengen.
• Entfernen Sie ungenutzte Glyphen aus Schriftarten.
• Halten Sie häufig genutzte Assets in Formaten, die der Grafikpfad effizient unterstützt.

Bei mehrsprachigen Produkten kann der Schriftartspeicher das UI-Budget dominieren. Planen Sie Schriftart-Fallback, Glyphen-Teilmengen und Textlayout frühzeitig.

Animationsstrategie¶

Flüssige Animationen hängen vom Zeitbudget pro Frame, der Panel-Bandbreite, dem Rendering-Aufwand und dem Stromverbrauch ab.

Ein praktischer Ansatz:

• Animieren Sie nur, was Nutzer bemerken.
• Halten Sie animierte Bereiche klein.
• Bevorzugen Sie Transformationen oder Deckkraftänderungen, die sich gut beschleunigen lassen.
• Vermeiden Sie aufwändige Vollbild-Unschärfe-, Schatten- oder Transparenzeffekte in jedem Frame.
• Reduzieren Sie die Bildrate für unkritische Effekte.
• Stoppen Sie Animationen, wenn der Bildschirm gedimmt, abgedeckt oder inaktiv ist.

Eine Wearable-UI benötigt nicht überall Desktop-artige Animation. Wenige schnelle, klare Übergänge fühlen sich meist besser an als viele Effekte, die Strom verbrauchen oder Frames auslassen.

Grafik-Validierungsmatrix¶

Verwenden Sie wiederholbare Bildschirme statt subjektiver „flüssig genug“-Prüfungen:

Erfassen Sie Render-Zeit, Flush-Zeit, CPU-Last und Stromverbrauch für jeden Bildschirm. Wird nur die Gesamt-Frame-Zeit gemessen, ist schwer zu erkennen, ob der Engpass LVGL, ePicasso, der Speicher oder die Panel-Schnittstelle ist.

Grafikleistung debuggen¶

Wenn die UI langsam ist, identifizieren Sie den Engpass, bevor Sie das Design ändern.

Messen Sie diese getrennt:

• LVGL-Render-Zeit.
• ePicasso-Operationszeit.
• Display-Flush-Zeit.
• CPU-Last.
• Auslastung der Speicherbandbreite.
• Stromverbrauch in aktiven, inaktiven und Schlafzuständen.

Häufige Fehler¶

Vermeiden Sie diese frühzeitig; sie sind spät nur schwer zu beheben:

• Wählen Sie keine Panel-Schnittstelle, bevor Sie die Bandbreite abgeschätzt haben.
• Vermeiden Sie Vollbildneuzeichnungen für kleine UI-Änderungen.
• Legen Sie nicht alle UI-Assets ohne vorheriges Profiling in langsamem Speicher ab.
• Verwenden Sie nicht RGB888, wenn RGB565 ausreicht.
• Vermeiden Sie es, große Bilder in jedem Frame zu skalieren.
• Vergessen Sie die Cache-Wartung für gemeinsam genutzte Hardware-Puffer nicht.
• Gehen Sie nicht davon aus, dass ePicasso automatisch jede UI-Operation beschleunigt.
• Vermeiden Sie zu viele Timer oder Animationen, die die CPU wachhalten.
• Ignorieren Sie nicht die Touch-Latenz, während Sie nur die Bildrate optimieren.
• Warten Sie mit der Validierung der Panel-Initialisierung nicht bis zur PCB-Inbetriebnahme.

Inbetriebnahme-Checkliste¶

Verwenden Sie diese Checkliste zum Start eines neuen SF32-Grafikprojekts:

• Bestätigen Sie Display-Auflösung, Farbtiefe, Schnittstelle und Panel-Treiber-IC.
• Prüfen Sie, ob das gewählte SF32-Gerät die benötigte Display-Schnittstelle unterstützt.
• Schätzen Sie den Speicherbedarf für Framebuffer und Zeichenpuffer ab.
• Legen Sie Vollbild- oder Teilaktualisierung sowie Einzel- oder Doppelpufferung fest.
• Nehmen Sie Panel-Reset, Versorgungsspannungen, Hintergrundbeleuchtung und Initialisierungssequenz in Betrieb.
• Implementieren Sie LVGL-Tick, Display-Flush und Eingabetreiber.
• Prüfen Sie grundlegendes Füll-, Bild-, Text- und Touch-Verhalten.
• Aktivieren Sie ePicasso-Beschleunigung, sofern SDK und Treiber sie unterstützen.
• Validieren Sie Cache-Clean- und Invalidate-Verhalten für gemeinsam genutzte Puffer.
• Messen Sie Render-Zeit, Flush-Zeit, CPU-Last und Stromverbrauch.
• Testen Sie Worst-Case-Bildschirme, Animationen, Bluetooth-Aktivität und Schlaf-/Aufwach-Pfade.

Wichtige Erkenntnisse¶

• Beginnen Sie das Grafikdesign mit Display-Schnittstelle, Auflösung, Farbtiefe und Aktualisierungsanforderungen.
• Nutzen Sie LVGL oder ein ähnliches Framework, um Widgets, Invalidierung, Zeichnen und Eingabe zu verwalten.
• Nutzen Sie ePicasso, um häufige Pixeloperationen zu beschleunigen, behalten Sie aber CPU-Fallback-Pfade bei.
• Optimieren Sie Speicherplatzierung und Pufferstrategie ebenso sorgfältig wie Rendering-Code.
• Bevorzugen Sie Teilaktualisierung für bandbreitenbegrenzte Panels und statische Wearable-Bildschirme.
• Betrachten Sie UI-Leistung als Systemaufgabe, an der CPU, ePicasso, Speicher, Display-Controller, Panel-Schnittstelle, Touch und Energiemanagement beteiligt sind.

Zuletzt aktualisiert: 2026-10-12