Hardware-Beschleuniger: STM32 Chrom-ART für flüssige Grafiken

Ein Hardware-Beschleuniger: STM32 Chrom-ART ist für viele Embedded-GUIs der entscheidende Schritt von „funktional“ zu „flüssig“. Sobald ein STM32 nicht nur Werte auf ein Display schreibt, sondern Icons, Bilder, Transparenzen, Fonts und Animationen darstellen soll, wird das reine CPU-Rendering schnell zum Flaschenhals. Genau hier setzt Chrom-ART an: Hinter dem Marketingnamen steckt die Peripherie DMA2D, ein 2D-DMA-Engine, die Pixel kopieren, füllen, konvertieren und mischen kann – parallel zur CPU. Das Ergebnis sind kürzere Renderzeiten, geringere CPU-Last und oft auch ein besseres Energieprofil, weil die CPU früher wieder in Idle- oder Sleep-Zustände wechseln kann. In der Praxis ist Chrom-ART besonders interessant für STM32 mit Display-Controller (z. B. LTDC) und Framebuffer im SRAM oder externem SDRAM, aber auch für Systeme, die Assets aus externem QSPI-Flash einblenden. Damit die Grafikausgabe wirklich „butterweich“ wird, reicht es allerdings nicht, den Beschleuniger nur zu aktivieren: Sie müssen Pixel-Formate, Speicherlayout, Stride/Line-Offset, Cache-Verhalten und die Einbindung in das Grafik-Framework sauber planen. Dieser Artikel erklärt, wie Chrom-ART (DMA2D) funktioniert, welche Operationen es beschleunigt und wie Sie typische Stolpersteine vermeiden, um auf STM32-Plattformen wirklich flüssige Grafiken zu erreichen.

Was ist STM32 Chrom-ART (DMA2D) und wofür ist es gedacht?

Chrom-ART ist STMicroelectronics’ Bezeichnung für die DMA2D-Peripherie. Während klassische DMA-Controller vor allem „linear“ Daten von A nach B kopieren, ist DMA2D auf zweidimensionale Bilddaten optimiert. Das bedeutet: Es versteht Zeilen (Lines), Pixel-Formate und kann beim Transfer gleichzeitig umrechnen oder Alpha-Blending anwenden. Damit eignet sich Chrom-ART für typische GUI-Operationen wie:

• Area Fill: Rechteckige Flächen in einem Framebuffer mit einer Farbe füllen (z. B. Hintergrund, Buttons, Overlays).
• Blit/Copy: Bildbereiche kopieren (z. B. Icon an Position X/Y zeichnen).
• Pixel-Format-Conversion (PFC): Bilddaten beim Kopieren von einem Format in ein anderes konvertieren (z. B. ARGB8888 nach RGB565).
• Alpha-Blending: Vordergrund und Hintergrund nach Alpha-Regeln mischen (Transparenzen, Anti-Aliasing, weiche Kanten).

Für eine vertiefende technische Einführung sind STs Schulungsunterlagen zu Chrom-ART/DMA2D hilfreich, z. B. STM32 Chrom-ART (DMA2D) Training (PDF). Außerdem beschreibt ST in einer Anwendungsschrift die Nutzung des Beschleunigers im Display-Kontext, siehe AN4943 zur Display-Aktualisierung mit Chrom-ART.

Warum Chrom-ART die UI „flüssig“ macht: Parallelität statt CPU-Schleifen

Der wichtigste Effekt ist nicht nur „schneller kopieren“, sondern Entkopplung: DMA2D arbeitet asynchron zur CPU. Während die CPU sonst Pixel in Schleifen schreibt, kann sie mit Chrom-ART andere Aufgaben erledigen: Touch-Handling, Kommunikation, Sensorik, Applikationslogik oder das Vorbereiten des nächsten Frames. So sinken nicht nur die Renderzeiten, sondern auch die Wahrscheinlichkeit, dass Interrupts, Protokollstacks oder Hintergrundaufgaben die Grafik ausbremsen.

• Mehr FPS oder weniger Ruckler: weil Pixeloperationen hardwarebeschleunigt sind.
• Mehr CPU-Budget: für nicht-grafische Aufgaben im selben System.
• Besseres Echtzeitverhalten: weil die CPU weniger lange in großen Copy-Loops hängt.
• Potenzial für geringeren Energieverbrauch: weil die CPU schneller wieder in Idle kann (abhängig vom Gesamtdesign).

Die wichtigsten DMA2D-Modi: R2M, M2M, M2M_PFC und Blending

Chrom-ART/DMA2D bietet typischerweise verschiedene Betriebsarten. Die Benennungen können in HAL/LL oder im Reference Manual leicht variieren, das Prinzip ist aber stabil:

• R2M (Register-to-Memory): Ein Farbwert wird in eine rechteckige Region geschrieben. Perfekt für Hintergrundflächen, Clear-Operationen oder einfache GUI-Elemente.
• M2M (Memory-to-Memory): Kopieren von Pixelblöcken ohne Formatumwandlung. Gut für Blits, wenn Quell- und Zielformat gleich sind.
• M2M_PFC (Memory-to-Memory mit Pixel Format Conversion): Kopieren und gleichzeitig Format konvertieren. Typisch, wenn Assets in ARGB8888 vorliegen, das Display aber RGB565 nutzt.
• M2M_Blending: Vordergrund und Hintergrund werden nach Alpha gemischt und ins Ziel geschrieben. Ideal für Transparenzen, Anti-Aliasing und Compositing.

Alpha-Blending verstehen: Was wirklich berechnet wird

Beim Blending wird vereinfacht ein Vordergrundpixel F mit Alpha α über ein Hintergrundpixel B gelegt. Das Ergebnis O ist (für einen Farbkanal) typischerweise:

$O=\alpha \cdot F+(1–\alpha )\cdot B$

In der Praxis ist α oft im Bereich 0…255 (8 Bit) codiert und wird intern skaliert. Für Sie als Entwickler ist entscheidend: Je häufiger Sie Transparenzen einsetzen, desto mehr lohnt sich der Hardwarepfad, weil die CPU-Blending-Schleifen sehr teuer werden.

Pixel-Formate und Farbtiefe: Der häufigste Performance- und Qualitätshebel

Flüssige Grafiken sind nicht nur eine Frage des Beschleunigers, sondern auch der Speicherbandbreite. Ein Framebuffer in ARGB8888 benötigt pro Pixel 4 Byte, RGB565 nur 2 Byte. Das wirkt sich direkt auf Transferzeiten, Cache-Last und RAM-Bedarf aus.

• RGB565: sehr verbreitet für Embedded-Displays, guter Kompromiss aus Qualität und Bandbreite.
• ARGB8888: hohe Qualität und Alpha, aber doppelte Bandbreite gegenüber RGB565.
• CLUT/L8 (palettiert): kann Speicher sparen, erhöht aber Komplexität und ist stark vom Use-Case abhängig.

DMA2D kann viele Konvertierungen beschleunigen, dennoch gilt: Wenn Ihr gesamtes Rendering ständig zwischen Formaten wandelt, verlieren Sie Zeit. Ein guter Ansatz ist, ein primäres Framebuffer-Format festzulegen (oft RGB565 oder ARGB8888) und Assets möglichst kompatibel vorzuhalten.

Chrom-ART im Display-Stack: LTDC, Framebuffer und externe Speicher

In klassischen STM32-GUI-Systemen gibt es einen Framebuffer im RAM (internes SRAM oder externes SDRAM). Der Display-Controller (häufig LTDC) liest diesen Framebuffer zyklisch aus und erzeugt die Signale zum Panel. Chrom-ART schreibt in denselben Framebuffer – idealerweise ohne die CPU zu blockieren.

• Framebuffer im internen SRAM: schnell, aber oft zu klein für große Auflösungen oder Double Buffering.
• Framebuffer im externen SDRAM: mehr Platz, aber sorgfältiges Timing/Layout nötig; Bandbreite wird wichtig.
• Assets im QSPI-Flash: gut für Bilder/Fonts; DMA2D kann von extern lesen, aber Random-Access-Latenzen beachten.

ST beschreibt typische Datenpfade, in denen Assets aus externem Speicher in den Framebuffer gemischt werden, in der Anwendungsschrift AN4943 (Chrom-ART im Display-Refresh).

Double Buffering und Partial Updates: Zwei Strategien gegen Tearing und Ruckler

Flüssige Grafiken hängen stark davon ab, wann Sie in den Framebuffer schreiben. Wenn LTDC gerade ausliest und DMA2D gleichzeitig in denselben Bereich schreibt, kann Tearing entstehen. Zwei etablierte Strategien:

• Double Buffering: Zwei Framebuffer: einer wird angezeigt, der andere gerendert. Beim Vertical Sync (oder in einem definierten Zeitpunkt) wird umgeschaltet. Ergebnis: sehr sauber, aber doppelte RAM-Anforderung.
• Partial Updates: Nur veränderte Regionen werden aktualisiert (Dirty Rectangles). Spart Bandbreite und Zeit, erfordert aber saubere Regionverwaltung.

Bildwiederholrate grob abschätzen

Ob Ihr System „flüssig“ wirkt, hängt von der Zeit pro Frame ab. Eine einfache Beziehung ist:

$f_{\mathrm{FPS}}=\frac{1}{t_{\mathrm{frame}}}$

Wenn Sie statt Fullscreen-Redraw nur kleine Rechtecke aktualisieren, sinkt tframe oft drastisch. Chrom-ART hilft besonders dort, wo viele Pixeloperationen in diesen Regionen anfallen: Fills, Blits, Blends.

Integration in TouchGFX und LVGL: Beschleunigung ohne Eigenbau

Viele Teams nutzen Frameworks wie TouchGFX oder LVGL, weil sie Rendering, Widgets und Assets standardisieren. Beide Ökosysteme unterstützen DMA2D/Chrom-ART als Beschleuniger – mit leicht unterschiedlicher Integrationstiefe:

• TouchGFX: kann Chrom-ART automatisch nutzen, um Pixel zu bewegen und zu blenden, wodurch die CPU entlastet wird.
• LVGL: bietet eine Integration, bei der DMA2D als „GPU“-Backend für bestimmte Operationen genutzt werden kann.

Für TouchGFX sind die Abschnitte zur Hardware Acceleration mit Chrom-ART sowie zur Performance-Optimierung in TouchGFX praxisnah. Für LVGL ist die Vendor-Doku zur STM32 DMA2D (Chrom-ART) Integration ein guter Startpunkt.

Wann Framework-Beschleunigung besonders viel bringt

• Viele Bilder und Text: Blitting und Font-Rendering profitieren, weil viele Pixelbereiche bewegt werden.
• Transparenzen: Alpha-Blending ist CPU-seitig teuer, hardwareseitig deutlich effizienter.
• Häufige Clears/Fills: R2M-Fills beschleunigen Screen-Clears oder große Farbflächen massiv.

Konfiguration in STM32CubeMX: Die typischen Stellschrauben

In STM32CubeMX aktivieren Sie DMA2D als Peripherie und konfigurieren – abhängig vom Projekt – LTDC, Speicher (FMC/SDRAM, QSPI/OSPI), Cache-Einstellungen (bei Cortex-M7) und Interrupts. Für Chrom-ART sind besonders relevant:

• DMA2D Takt (RCC): Peripherie-Clock muss aktiv sein.
• Interrupt-Handling: Optional, wenn Sie Completion-Callbacks nutzen oder Transfers ketten wollen.
• Memory Regions: Framebuffer-Adressen, Strides (Line Offset), Alignment.
• LTDC Layer-Formate: müssen zum Framebuffer-Format passen (RGB565 vs ARGB8888).

CubeMX ist besonders wertvoll, um den Clock Tree und die Zusammenhänge zwischen LTDC, Speicherinterface und DMA2D im Blick zu behalten, siehe STM32CubeMX.

Best Practices für hohe Performance: Bandbreite, Alignment, Burst-Verhalten

Chrom-ART ist schnell, aber nicht magisch. Häufig limitiert die Speicherbandbreite, nicht die Rechenlogik. Mit den folgenden Punkten holen Sie in der Praxis die meiste Leistung heraus:

• Framebuffer in schnellen Speicher legen: Wenn möglich internes SRAM/AXI-SRAM oder gut getaktetes SDRAM mit sauberem FMC-Timing.
• Große, zusammenhängende Transfers bevorzugen: Viele kleine Blits haben mehr Overhead als wenige größere.
• Alignment beachten: Pixelzeilen und Startadressen auf sinnvolle Grenzen ausrichten, um ineffiziente Zugriffe zu vermeiden.
• Pixel-Format-Konvertierung minimieren: PFC ist hilfreich, kostet aber Zeit; ideal ist ein konsistenter Render-Pfad.
• Dirty Rectangles nutzen: Nur Bereiche aktualisieren, die sich geändert haben.

Cache-Kohärenz: Der unsichtbare Stolperstein bei Cortex-M7

Wenn Ihre STM32-Plattform Daten-Cache nutzt (typisch bei Cortex-M7), kann es passieren, dass DMA2D „alte“ Daten liest oder die CPU „alte“ Framebuffer-Inhalte sieht, weil Cache und RAM nicht synchron sind. Das wirkt dann wie Zufallsfehler: Flackern, Artefakte, „halb gezeichnete“ Widgets. Grundregeln:

• DMA-Buffer als non-cacheable markieren (MPU-Regionen), wenn Sie maximale Robustheit wollen.
• Oder Cache-Operationen konsequent durchführen: Clean/Invalidate vor/nach DMA2D-Transfers, abhängig von Richtung.
• Nie „gemischt“ arbeiten: Halbherzige Cache-Strategien sind die häufigste Ursache für schwer reproduzierbare Grafikfehler.

Typische Fehlerbilder und schnelle Diagnose

Viele Probleme mit Chrom-ART sind nicht „Hardware defekt“, sondern Konfigurationsdetails. Diese Muster sind in Projekten besonders häufig:

• Falsche Farben: Pixel-Format passt nicht (RGB565 vs BGR565, ARGB-Reihenfolge), oder CLUT/Alpha falsch interpretiert.
• Versetzte Grafik: Line Offset/Stride falsch gesetzt, dadurch wird Zeile für Zeile in falsche Bereiche geschrieben.
• Bildränder „zerstört“: Breite/Höhe oder Zieladresse nicht korrekt berechnet, Off-by-one bei Pixelmaßen.
• Flackern/Tearing: Schreiben in den aktiven Framebuffer ohne Synchronisierung, fehlendes Double Buffering oder fehlende VSync-Strategie.
• Artefakte nur bei Aktivierung des Caches: typischer Cache-Kohärenzfehler zwischen CPU und DMA2D.

Validierungsschritt: Erst Fills, dann Blits, dann Blends

Wenn Sie Chrom-ART neu integrieren, ist ein gestuftes Vorgehen effizient: Erst eine Vollflächenfüllung (R2M) testen, dann einfache Kopien im gleichen Format (M2M), danach Formatkonvertierung (M2M_PFC) und zuletzt Alpha-Blending. So isolieren Sie Fehlerquellen und erkennen schnell, ob das Problem im Format, im Stride oder in der Blending-Konfiguration liegt.

Praxis-Szenarien: Wo Chrom-ART den größten Nutzen liefert

• Dashboards und HMIs: viele Icons, Text, teilweise Transparenzen; Chrom-ART reduziert Renderzeiten spürbar.
• Animierte Menüs: wiederholtes Bewegen von Elementen (Blits) und Hintergrundfüllungen.
• Overlay-Grafiken: Warnsymbole, Highlights, Soft-Shadows und Alpha-Blending über Live-Daten.
• Asset-lastige UIs: Bilder und Fonts aus externem Flash, Einblendungen in den Framebuffer.
• Partial Refresh Systeme: geringe Änderungen, aber häufig; DMA2D erledigt kleine Updates sehr effizient.

Chrom-ART und Energie: Nicht nur schneller, sondern oft auch effizienter

Eine schnellere Renderpipeline kann auch den Energieverbrauch senken, weil die CPU weniger lange im Run-Modus bleiben muss. Ob das in Ihrem System messbar ist, hängt von den Nebenverbrauchern (Display, Backlight, SDRAM, Regler) und vom Duty-Cycle ab. In vielen batteriebetriebenen Geräten ist das Backlight der dominierende Verbraucher, dennoch lohnt sich Chrom-ART: Eine entlastete CPU schafft mehr Zeit in Idle oder ermöglicht niedrigere CPU-Takte bei gleicher UI-Performance.

Empfohlene Ressourcen für die Vertiefung

• ST AN4943: Chrom-ART (DMA2D) für LCD-TFT-Refresh
• ST Training: Chrom-ART (DMA2D) Grundlagen
• TouchGFX: Hardware Acceleration mit DMA2D
• LVGL: STM32 DMA2D (Chrom-ART) Integration
• STM32CubeMX: Clock Tree und Peripherie-Konfiguration

Wenn Sie Chrom-ART als Teil einer gesamten Render-Architektur verstehen – mit konsistenten Pixel-Formaten, sauberer Speicherplanung, geeigneter Synchronisierung (Double Buffering oder Partial Updates) und korrekter Cache-Strategie – erreichen Sie auf STM32-Plattformen sehr flüssige Grafiken, ohne die CPU dauerhaft an die UI zu binden. Gerade in Kombination mit Frameworks wie TouchGFX oder LVGL ist der Hardware-Beschleuniger ein praxisnaher Weg, um UI-Qualität, Reaktionsgefühl und Systemreserve gleichzeitig zu verbessern.

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.