Qt im Embedded-Umfeld

Kurz gesagt: Qt ist ein C++-Framework, dessen deklarative UI-Sprache QML zusammen mit dem GPU-beschleunigten Qt-Quick-Szenengraph dieselbe, smartphone-taugliche Bedienoberfläche vom Industrie-Panel bis zum Mikrocontroller trägt – und das ganz ohne kompletten Desktop-Stack auf dem Gerät.

Die Erwartung an Bedienoberflächen eingebetteter Geräte ist in den letzten Jahren stark gestiegen. Nutzer vergleichen die HMI einer Industrieanlage unbewusst mit ihrem Smartphone – flüssige Animationen, klare Gestaltung, sofortige Reaktion. Qt löst diesen Anspruch auch auf bescheidener Hardware ein, weil es die GPU der Zielplattform ausnutzt statt gegen sie zu arbeiten. Im Folgenden gehen wir die entscheidenden Stellschrauben durch: Szenengraph, Display-Stack, Hardwarebeschleunigung, Boot-Zeit und die Wahl zwischen Qt for Embedded Linux und Qt for MCUs.

Wie erreicht Qt Quick smartphone-taugliche HMIs auf schwacher Hardware?

Der Schlüssel ist der Qt-Quick-Szenengraph. Statt jedes Bild mit CPU-Zeichenbefehlen neu zu malen, baut Qt Quick einen persistenten Baum aus Rendering-Knoten (retained mode) auf und übergibt ihn an die GPU. Knoten mit demselben Material – etwa alle Texte einer Schrift oder alle Rechtecke einer Farbe – werden dabei zu wenigen Draw-Calls gebatcht, was Zustandswechsel und damit den teuersten Teil der GPU-Kommunikation minimiert.

Mit QML beschreiben Entwickler die Oberfläche deklarativ über Property-Bindings, während die rechenintensive Logik in C++ bleibt. Genauso wichtig: Wo die Plattform es zulässt, läuft das Rendering in einem eigenen Render-Thread. Animationen werden dort fortgeschrieben und sind vom GUI-Thread entkoppelt – eine kurze Berechnung im Anwendungscode lässt die Oberfläche also nicht ruckeln.

Rectangle {
    width: 320; height: 64
    radius: 12
    color: pressed ? "#0891b2" : "#131c2e"
    Behavior on color { ColorAnimation { duration: 150 } }

    property bool pressed: false
    Text { anchors.centerIn: parent; text: "Start"; color: "white" }
    TapHandler { onTapped: parent.pressed = !parent.pressed }
}

Die Farbanimation läuft flüssig, weil sie im Szenengraph und nicht in der Anwendungsschleife abgearbeitet wird. Die Trennung von deklarativem UI und maschinennaher Logik ist zugleich der Grund, warum sich Qt-Projekte gut zwischen QML-Oberfläche und C++-Backend aufteilen lassen.

EGLFS, LinuxFB oder Wayland – welcher Display-Stack passt?

Im Embedded-Einsatz braucht es keinen vollständigen Desktop. Qt bringt dafür mehrere Plattform-Plugins (QPA) mit, die direkt auf die Hardware zielen – die richtige Wahl hängt vor allem davon ab, ob eine GPU vorhanden ist und ob mehrere Prozesse sich einen Bildschirm teilen.

Backend	Rendering	Fenster	Passt für
EGLFS	GPU über EGL/OpenGL ES (z. B. eglfs_kms auf DRM/KMS)	Ein Vollbild-Fenster	Der Standard für Single-App-HMIs mit GPU
LinuxFB	Software-Raster auf /dev/fb0	Ein Vollbild-Fenster	Hardware ganz ohne GPU
Wayland	GPU, als Client oder eigener Compositor	Mehrere Fenster/Prozesse	Multi-Window- und Multi-App-Szenarien

EGLFS ist für die meisten Geräte die erste Wahl: Es rendert ohne Display-Server-Overhead direkt auf die GPU und spart so Speicher, Boot-Zeit und Angriffsfläche. Fehlt eine GPU vollständig, rendert Qt Quick mit dem Software-Backend (QT_QUICK_BACKEND=software) über LinuxFB weiter – langsamer, aber lauffähig. Sobald mehrere Prozesse gleichzeitig auf ein Display zeichnen sollen, kommt der Qt Wayland Compositor ins Spiel, mit dem sich ein schlanker, gerätespezifischer Compositor bauen lässt, ohne einen vollen Desktop mitzuschleppen.

OpenGL ES oder Vulkan: Wie wird die Beschleunigung gewählt?

In Qt 6 zeichnet der Szenengraph nicht mehr direkt gegen OpenGL, sondern gegen das RHI (Rendering Hardware Interface) – eine Abstraktion, die zur Laufzeit auf OpenGL ES, Vulkan, Metal, Direct3D oder einen reinen Software-Rasterizer abgebildet wird. Für Embedded bedeutet das: Man wählt das Backend passend zum GPU-Treiber der Zielplattform, ohne die UI-Codebasis anzufassen.

• OpenGL ES 2.0/3.x ist der breite gemeinsame Nenner und auf praktisch jeder Embedded-GPU verfügbar – ein sicherer Ausgangspunkt.
• Vulkan lohnt sich, wenn der Grafiktreiber es stabil unterstützt und man geringeren Overhead oder feinere Kontrolle braucht.
• Auf Systemen ohne 3D-GPU übernimmt der Software-Rasterizer; manche MCU-SoCs beschleunigen stattdessen 2D-Blitting.

Die Wahl des Backends – und die Absicherung, dass der passende GPU-Treiber überhaupt im Board Support Package steckt – ist Teil der Embedded-Linux- und Yocto-BSP-Arbeit, lange bevor die erste QML-Zeile gerendert wird.

Wie senkt man Boot-to-First-Frame und Speicherbedarf?

Zwei Kennzahlen entscheiden über den ersten Eindruck: die Zeit bis zum ersten sichtbaren Bild und der belegte Arbeitsspeicher. Beide lassen sich gezielt drücken.

Zur Boot-Zeit trägt der Qt Quick Compiler (qmlcachegen) bei: Er übersetzt QML bereits zum Build-Zeitpunkt in Bytecode bzw. C++, sodass beim Start nicht mehr geparst werden muss. In Qt 6 geschieht das automatisch, sobald QML über ein QML-Modul eingebunden wird:

qt_add_executable(panel main.cpp)
qt_add_qml_module(panel
    URI Panel
    QML_FILES Main.qml
)
# qt_add_qml_module ruft qmlcachegen auf: QML wird vorab
# kompiliert und muss beim Start nicht geparst werden.
target_link_libraries(panel PRIVATE Qt6::Quick)

Weitere Hebel für Startzeit und Speicher:

1. UI zuerst zeigen: Ein leichtes erstes Bild sofort rendern, teure Initialisierung asynchron nachladen und Komponenten per Loader erst bei Bedarf instanziieren.
2. Text als Distance-Field: Qt rendert Schrift standardmäßig über Distance-Field-Glyphen – vorgenerierte Glyph-Caches sparen zur Laufzeit CPU und Speicher.
3. Assets für die Zielauflösung: Bilder in passender Größe und mit GPU-Texturkompression (ETC2/ASTC) ausliefern, statt zur Laufzeit zu skalieren.
4. Schlanker Qt-Build: Über eine feature-reduzierte Konfiguration und ein passend zugeschnittenes meta-qt6-Image im Yocto-Build landen nur die tatsächlich genutzten Module auf dem Gerät.

Qt for MCUs oder Qt for Embedded Linux?

Nicht jedes Gerät hat einen MMU-fähigen Prozessor mit Linux. Qt deckt beide Welten ab, aber mit unterschiedlichen Laufzeiten. Qt for Embedded Linux ist das vollständige Qt-Framework und setzt einen Linux-fähigen SoC voraus. Qt for MCUs (Qt Quick Ultralite) ist eine eigene, schlanke Grafik-Engine für Mikrocontroller auf Bare-Metal oder RTOS: Sie versteht ein QML-Subset, kompiliert es vorab nach C++ und rendert über 2D-Blitter, kleine GPUs oder Software – lauffähig in wenigen hundert Kilobyte RAM.

Kriterium	Qt Widgets	Qt Quick / QML	Qt for MCUs
Rendering	CPU-Raster (QPainter)	GPU-Szenengraph (RHI)	Qt Quick Ultralite (2D-HW/GPU oder Software)
Sprache	C++	QML + C++	QML-Subset + C++
Zielhardware	Linux/Desktop mit CPU	Embedded Linux mit GPU (Software-Backend möglich)	Mikrocontroller (Bare-Metal/RTOS)
Typischer RAM	einige MB	zweistelliger MB-Bereich	einige hundert KB bis wenige MB
Animationen/Touch	funktional, begrenzt flüssig	flüssig, gestenreich	flüssig auf MCU-Niveau
Ideal für	dichte Werkzeug- und Konfigurations-UIs	moderne Touch-HMIs	kostensensitive Großserie

Qt Widgets bleibt dabei kein Auslaufmodell: Für dichte, formularlastige Konfigurations- oder Service-Oberflächen ist der klassische Widget-Stack oft die pragmatischere Wahl. Für animierte Touch-HMIs führt hingegen kein Weg an Qt Quick vorbei.

Eine Codebasis von der Entwicklung bis ins Feld

Ein oft unterschätzter Vorteil: Dieselbe Qt-Codebasis läuft auf dem Entwickler-Desktop und auf dem Zielgerät. Entwickelt und getestet wird komfortabel am PC, das Deployment auf die Hardware ändert an der Logik nichts. Das verkürzt Iterationszyklen erheblich – gerade in Verbindung mit einem reproduzierbaren Yocto-Build, der Framework, Treiber und Anwendung deterministisch zusammenbindet.

Fazit

Qt verbindet moderne, ansprechende Bedienkonzepte mit der Effizienz, die eingebettete Systeme verlangen. Entscheidend ist ein Team, das die Stellschrauben kennt – von der Wahl des Grafik-Backends über die Hardwarebeschleunigung bis zur Boot-Zeit-Optimierung. Dieses Wissen vermitteln wir auch in unseren Qt- und Embedded-Linux-Schulungen. Beispiele umgesetzter Projekte finden Sie in unserem Portfolio; wenn Sie eine konkrete HMI planen, sprechen Sie uns an.