Tools und Ansätze zur Entwicklung eingebetteter GUI

Inhaltsübersicht

Einführung

Eine eingebettete grafische Benutzeroberfläche wird oft einfach als „Grafik auf einem Display“ verstanden. In der Praxis ist sie jedoch viel mehr als das. Eine eingebettete GUI ist eine Kombination aus Software-Architektur, Rendering-Strategie, Eingabeverarbeitung und Hardware-Fähigkeiten, die alle zusammenarbeiten, um Informationen zu präsentieren und Benutzerinteraktionen auf zuverlässige und vorhersehbare Weise zu akzeptieren.

Im Gegensatz zu Desktop- oder mobilen Anwendungen arbeiten eingebettete GUIs unter strengen Auflagen. Begrenzte CPU-Leistung, begrenzter Speicherplatz, Echtzeitanforderungen und lange Produktlebenszyklen haben Einfluss darauf, wie die Benutzeroberfläche gestaltet und implementiert wird. Daher reichen die eingebetteten GUI-Lösungen von leichtgewichtigen Schnittstellen, die auf kleinen Mikrocontrollern laufen, bis hin zu fortschrittlichen grafischen Anwendungen, die auf Linux-basierten Systemen laufen.

Aufgrund dieser Vielfalt beschreibt der Begriff „eingebettete GUI“ nicht eine einzige Technologie oder einen einzigen Arbeitsablauf. Stattdessen umfasst er ein breites Spektrum von Ansätzen, die sich darin unterscheiden, wo das Rendering stattfindet, wie eng die GUI an die Hardwareplattform gebunden ist und wie viel Flexibilität für zukünftige Systementwicklungen besteht.

Drei praktische Kategorien von eingebetteten GUI-Lösungen

Aus der Perspektive der Systemebene können die meisten eingebetteten GUI-Lösungen in drei praktische Kategorien eingeteilt werden. Diese Klassifizierung basiert nicht auf bestimmten Produkten oder Anbietern, sondern darauf, wie die GUI in die gesamte Systemarchitektur integriert ist.

1. GUI gebunden an ein einziges Hardware-Ökosystem

In dieser Kategorie werden das GUI-Framework und die Tools speziell für eine Prozessorfamilie oder einen Siliziumhersteller entwickelt. Die Benutzeroberfläche wird zu einer natürlichen Erweiterung des Hardware-Ökosystems mit eng integrierten Werkzeugen und empfohlenen Arbeitsabläufen.

2. Plattformübergreifende GUI-Frameworks und -Bibliotheken

Hier ist das GUI-Framework weitgehend unabhängig von der zugrunde liegenden Hardware. Dieselbe UI-Codebasis kann auf verschiedenen Mikrocontrollern oder Prozessoren wiederverwendet werden, solange geeignete Anzeige- und Eingabetreiber verfügbar sind.

3. GUI mit Auslagerung des Renderings auf externe Grafikcontroller

Bei diesem Ansatz rendert der Hauptprozessor die grafische Oberfläche nicht direkt. Stattdessen wird das Rendering von einem speziellen externen Grafikcontroller übernommen, während sich die Haupt-CPU auf die Anwendungslogik und die Systemsteuerung konzentriert.

Dieses Drei-Kategorien-Modell bietet eine klare und praktische Möglichkeit, die eingebettete GUI-Landschaft zu verstehen. Es macht es auch einfacher, bestimmte Tools und Frameworks auf der Grundlage von Architekturentscheidungen und nicht von Feature-Checklisten zu positionieren.

In den folgenden Abschnitten wird jede Kategorie ausführlicher beschrieben, zusammen mit konkreten Beispielen, die zeigen, wie diese Ansätze in realen eingebetteten Systemen verwendet werden.

GUI gebunden an ein einziges Hardware-Ökosystem

In dieser Kategorie ist die grafische Benutzeroberfläche eng mit einer bestimmten Hardwareplattform oder einem Siliziumhersteller verbunden. Das GUI-Framework, die Entwicklungswerkzeuge und die empfohlenen Arbeitsabläufe sind so konzipiert, dass sie als Teil eines kohärenten Ökosystems zusammenarbeiten.

Dieser Ansatz bietet in der Regel ein hohes Maß an Integration zwischen der GUI und der zugrunde liegenden Hardware. Display-Treiber, Touch-Controller, Grafikbeschleunigung und Speichernutzung sind auf die Fähigkeiten einer bestimmten MCU- oder SoC-Familie abgestimmt. Infolgedessen ist die Lernkurve oft glatter, insbesondere für Teams, die bereits mit der Entwicklungsumgebung des Herstellers vertraut sind.

GUI-Lösungen dieser Kategorie werden in der Regel für Projekte ausgewählt, bei denen:

• die Hardware-Plattform wird schon früh im Design festgelegt,
• langfristige Unterstützung innerhalb eines einzigen Ökosystems erwartet wird,
• Entwicklungsgeschwindigkeit und Konsistenz der Toolchain sind wichtig.

Anstatt sich auf die Portabilität zwischen verschiedenen Plattformen zu konzentrieren, legen diese Lösungen den Schwerpunkt auf eine enge Kopplung und Optimierung innerhalb einer Umgebung.

TouchGFX für STM32

TouchGFX ist ein Framework für grafische Benutzeroberflächen, das speziell für STM32-Mikrocontroller entwickelt wurde. Es ist eng in das STM32-Ökosystem integriert und bildet eine natürliche Erweiterung des Entwicklungs-Workflows von ST.

Aus der Sicht eines Entwicklers kombiniert TouchGFX ein visuelles UI-Design-Tool mit einem für STM32-Hardware optimierten C++-Framework. UI-Bildschirme, Animationen und Interaktionen werden im Designer erstellt, während die Anwendungslogik und die Hardwarekonfiguration über STM32CubeMX und die zugehörigen Entwicklungswerkzeuge abgewickelt werden.

Dank dieser engen Integration kann die GUI mit einem klaren Verständnis der verfügbaren MCU-Ressourcen, Display-Schnittstellen und Grafikbeschleunigungsfunktionen entwickelt werden.

Typische Merkmale

• GUI-Framework exklusiv für STM32 entwickelt
• Visueller UI-Designer kombiniert mit eingebettetem C++-Code
• Arbeitsablauf abgestimmt auf STM32Cube Tools

TouchGFX - Werkzeug zur Kartenauswahl

Wenn Sie mehr über TouchGFX erfahren möchten, finden Sie weitere Informationen auf der ST-Website.

NXP GUI Guider

NXP GUI Guider verfolgt einen etwas anderen, aber immer noch herstellerzentrierten Ansatz. Obwohl LVGL als zugrunde liegende Grafikbibliothek verwendet wird, bleibt der gesamte Arbeitsablauf eng mit dem NXP-Ökosystem verbunden.

GUI Guider bietet eine Drag-and-Drop-Oberfläche zur Erstellung von Bildschirmen und zur Definition des Verhaltens der Benutzeroberfläche. Das Tool generiert LVGL-basierten Quellcode, der dann in die MCUXpresso SDK-Umgebung integriert und erstellt wird. Aus der Sicht des Benutzers wird die GUI als Teil einer einzigen, vom Hersteller bereitgestellten Toolchain erstellt und verwaltet.

Obwohl LVGL selbst plattformübergreifend ist, spiegelt die Art und Weise, wie es hier verwendet wird, einen plattformspezifischen Arbeitsablauf wider, der für NXP-Mikrocontroller und deren empfohlenen Software-Stack optimiert ist.

Typische Merkmale

• Visuelle UI-Erstellung durch ein vom Anbieter bereitgestelltes Tool
• LVGL als Rendering-Engine verwendet
• Starke Integration mit MCUXpresso SDK und NXP-Plattformen

NXP Gui Guider - Neues Projektfenster

Weitere Informationen über NXP Gui Guider finden Sie auf der NXP Website.

Andere anbieterspezifische Ansätze

Ähnliche Konzepte sind in der gesamten Embedded-Industrie zu finden. Viele Siliziumhersteller bieten GUI-Tools oder Frameworks an, die so konzipiert sind, dass sie am besten innerhalb ihrer eigenen Hardware- und Software-Ökosysteme funktionieren.

Auch wenn sich die spezifischen Tools unterscheiden, bleibt die gemeinsame Idee dieselbe:

• wird die GUI als nativer Teil der Hardware-Plattform behandelt,
• Tooling und Beispiele sind auf eine bestimmte MCU- oder SoC-Familie abgestimmt,
• Optimierung und Benutzerfreundlichkeit innerhalb einer Umgebung haben Vorrang vor der Portabilität.

Diese Kategorie ist weiterhin eine gute Wahl für Projekte, bei denen die Standardisierung auf einen einzigen Anbieter die Entwicklung und langfristige Wartung vereinfacht.

Plattformübergreifende GUI-Frameworks und -Bibliotheken

Plattformübergreifende GUI-Frameworks verfolgen einen anderen Ansatz als herstellerspezifische Lösungen. Anstatt eng an ein Hardware-Ökosystem gekoppelt zu sein, sind sie so konzipiert, dass sie auf mehreren Plattformen mit minimalen oder gar keinen Änderungen an der UI-Codebasis laufen.

In diesem Modell wird die GUI zu einer eigenen Softwareschicht, die über der Hardwareabstraktion liegt. Solange geeignete Anzeige-, Eingabe- und Timing-Treiber bereitgestellt werden, kann dasselbe Framework für verschiedene Mikrocontroller, Prozessoren, Betriebssysteme und sogar Produktgenerationen wiederverwendet werden.

Diese Kategorie wird in der Regel gewählt, wenn:

• Hardware-Plattformen können sich im Laufe der Zeit ändern,
• Mehrere Produktvarianten haben eine gemeinsame Benutzeroberfläche,
• langfristige Wartbarkeit und Portabilität sind wichtige Designziele.

Anstatt für eine bestimmte MCU zu optimieren, legen plattformübergreifende Frameworks den Schwerpunkt auf Konsistenz und Wiederverwendung in verschiedenen Umgebungen.

LVGL als plattformübergreifendes eingebettetes GUI-Framework

LVGL ist eines der am häufigsten verwendeten plattformübergreifenden GUI-Frameworks in der Embedded-Welt. Es ist so konzipiert, dass es auf einer Vielzahl von Systemen läuft, von kleinen MCUs mit begrenzten Ressourcen bis hin zu MPU-basierten Plattformen mit Linux.

Aus architektonischer Sicht bietet LVGL:

• ein einheitliches Objektmodell für Bildschirme, Widgets und Stile,
• eine flexible Rendering-Pipeline, die an verschiedene Display-Treiber angepasst werden kann,
• Unterstützung sowohl für Bare-Metal- als auch für OS-basierte Systeme.

Da LVGL unabhängig von einem einzelnen Siliziumhersteller ist, können Entwicklungsteams die gleiche GUI-Logik beibehalten, während sie die zugrunde liegende Hardwareplattform ändern. Das macht es besonders attraktiv für Produkte, die sich im Laufe der Zeit weiterentwickeln oder in verschiedenen Hardwarekonfigurationen existieren.

Typische Merkmale

• Ein einziges GUI-Framework für MCU- und MPU-Systeme
• Portable C-basierte Codebasis
• Große Auswahl an unterstützten Displays, Touch-Controllern und Plattformen

Wenn Sie mehr erfahren möchten, lesen Sie Erste Schritte mit LVGL oder sehen Sie sich die Dokumentation auf docs.lvgl.io an.

Qt und Qt Quick in eingebetteten Systemen

Qt stellt einen High-Level-Ansatz für die Entwicklung von Embedded GUI dar und wird am häufigsten in Systemen verwendet, die auf MPUs unter Linux basieren. In dieser Umgebung wird die Benutzeroberfläche als eine vollständige Anwendungsschicht und nicht als eine leichtgewichtige Erweiterung der Firmware behandelt.

Das Herzstück moderner Qt-basierter eingebetteter GUIs ist Qt Quick, ein Framework, das auf QML, einer deklarativen Sprache zur Beschreibung von Benutzeroberflächen, basiert. Qt Quick trennt die visuelle Struktur, Animationen und Interaktionslogik vom zugrundeliegenden Anwendungscode, so dass sich die Benutzeroberfläche unabhängig von der Systemfunktionalität weiterentwickeln kann.

Dieser Ansatz ermöglicht:

• flexible Layouts und dynamische Skalierung über verschiedene Bildschirmgrößen hinweg,
• fließende Animationen und Übergänge,
• Hardware-beschleunigtes Rendering mit modernen Grafik-Pipelines,
• klare Trennung zwischen UI-Design und Anwendungslogik.

Qt Quick ist daher die primäre Technologie, die dafür verantwortlich ist, was in modernen Qt-basierten eingebetteten Systemen auf dem Bildschirm dargestellt wird.

Visuelle UI-Erstellung mit Qt Design Studio

Ein wesentlicher Bestandteil des Qt Embedded GUI-Workflows ist Qt Design Studio, das als Hauptwerkzeug für das visuelle UI-Design und Prototyping dient.

Qt Design Studio ermöglicht es Designern und Entwicklern, Benutzeroberflächen visuell zu gestalten, Animationen und Zustände zu definieren und Interaktionen in der Vorschau zu sehen, ohne sich auf den Low-Level-Anwendungscode zu konzentrieren. Das Tool generiert QML-Assets, die direkt in die eingebettete Anwendung integriert werden können.

Aus Sicht des Arbeitsablaufs ermöglicht Qt Design Studio:

• visuelle Gestaltung von Bildschirmen und Komponenten,
• Timeline-basiertes Animationsdesign,
• schnelle Iteration von Look und Feel,
• enge Zusammenarbeit zwischen Design- und Software-Teams.

Qt Design Studio

In Embedded-Projekten spielt Qt Design Studio eine ähnliche Rolle wie herstellerspezifische GUI-Designer in MCU-Ökosystemen, ist aber auf die Bedürfnisse von Systemen der Linux-Klasse mit fortgeschritteneren grafischen Fähigkeiten zugeschnitten. Weitere Einzelheiten zu dieser Umgebung finden Sie auf der Qt-Website.

Integration und Einsatzkontext

Qt-basierte eingebettete Anwendungen werden normalerweise mit Qt Creator entwickelt und integriert. Qt Creator dient als Haupt-IDE für die Verwaltung von QML, C++ und Build-Konfigurationen. Qt Creator ist zwar selbst kein GUI-Design-Tool, aber es bietet die Umgebung, in der die in Qt Design Studio erstellten UI-Assets mit der Anwendungslogik kombiniert werden.

In kommerziellen Embedded-Produkten wird Qt häufig mit Qt for Device Creation ausgeliefert, das eine unterstützte Runtime, Toolchain und Update-Infrastruktur für Embedded-Linux-Geräte bietet. Dieses Paket vereinfacht die Bereitstellung und langfristige Wartung, hat aber keinen direkten Einfluss auf die Gestaltung der Benutzeroberfläche.

Wenn Qt die richtige Wahl ist

Qt-basierte eingebettete GUIs werden in der Regel ausgewählt, wenn:

• die Systemarchitektur umfasst bereits eine MPU und Linux,
• die Benutzeroberfläche ist ein zentraler Bestandteil des Produkterlebnisses,
• moderne Interaktionsmuster und reichhaltige visuelle Darstellungen sind erforderlich,
• Design und Softwareentwicklung laufen parallel.

Qt erfordert zwar leistungsfähigere Hardware als MCU-fokussierte Frameworks, aber die Kombination aus Qt Quick und Qt Design Studio bietet eine ausgereifte und skalierbare Umgebung für die Entwicklung fortschrittlicher eingebetteter Benutzeroberflächen.

Andere tragbare GUI-Technologien

Neben LVGL und Qt gibt es weitere portable Ansätze, die in Embedded-Projekten verwendet werden, abhängig von den Systemanforderungen und der Erfahrung des Teams.

Dazu gehören:

• webbasierte Benutzeroberflächen, die mit HTML, CSS und JavaScript erstellt und über einen eingebetteten Browser angezeigt werden,
• andere offene oder Legacy-GUI-Bibliotheken, die in langlebigen Produkten verwendet werden,
• maßgeschneiderte interne Frameworks, die für sehr spezifische Anforderungen entwickelt wurden.

Diese Lösungen unterscheiden sich zwar in der Implementierung, haben aber ein gemeinsames Prinzip:
die GUI wird als plattformunabhängige Schicht behandelt, unter der hardwarespezifische Details abstrahiert werden.

GUI mit Auslagerung des Renderings auf externe Grafikcontroller

Die dritte Kategorie von eingebetteten GUI-Lösungen basiert auf einer anderen architektonischen Annahme als die herstellerspezifischen und plattformübergreifenden Frameworks. Bei diesem Ansatz wird das Grafik-Rendering nicht von der Haupt-MCU oder MPU durchgeführt, sondern an einen dedizierten externen Grafik-Controller delegiert.

Der Hauptprozessor kommuniziert mit dem Grafikcontroller über High-Level-Befehle, während der Controller selbst für die Erzeugung der Bildschirmausgabe und die Verarbeitung von Berührungseingaben zuständig ist. Auf diese Weise wird die Anwendungslogik von der Darstellung getrennt und die Notwendigkeit, einen Framebuffer im Hauptspeicher des Systems zu halten, entfällt.

Solche Architekturen werden in der Regel gewählt, wenn:

• MCU-Ressourcen sind begrenzt oder für Echtzeitaufgaben reserviert,
• ein vorhersehbares und deterministisches Rendering-Verhalten erforderlich ist,
• Die Komplexität des Systems muss unter strenger Kontrolle gehalten werden.

Anstatt die Leistung durch eine Erhöhung der CPU- oder Speicherressourcen zu skalieren, verlässt sich diese Kategorie auf die Auslagerung der grafischen Arbeitslast durch die Hardware.

Bridgetek EVE-basierte HMIs

Die EVE-Familie von Bridgetek ist ein repräsentatives Beispiel für diesen Ansatz. EVE-Geräte fungieren als dedizierte Display-, Grafik- und Touch-Controller, die das Rendering, das Display-Timing und die Touch-Verarbeitung intern erledigen.

In einem EVE-basierten System:

• sendet die Host-MCU Zeichen- und Steuerbefehle,
• erstellt der EVE-Controller eine Anzeigeliste und führt sie aus,
• Die Berührungseingabe wird direkt vom EVE-Gerät verarbeitet,
• das endgültige Videosignal wird direkt vom EVE-Controller erzeugt.

Diese Architektur ermöglicht es selbst relativ kleinen MCUs, komplexe grafische Oberflächen zu steuern und Benutzerinteraktionen zu verarbeiten, ohne Pixelpuffer zu verwalten, Touch-Algorithmen zu implementieren oder Echtzeit-Rendering-Operationen durchzuführen.

Zu den typischen Merkmalen von EVE-basierten HMIs gehören:

• kein Framebuffer im MCU-Speicher,
• integrierte Touchbedienung (resistiv oder kapazitiv, je nach EVE-Variante),
• stabile Rendering-Leistung unabhängig von der Anwendungslast,
• klare Trennung zwischen UI-Präsentation, Touch-Verarbeitung und Anwendungslogik.

Damit eignet sich EVE hervorragend für klassische industrielle HMIs, Bedienfelder und Geräte, bei denen robuste Touch-Interaktion, deterministisches Verhalten und Einfachheit des Systems die wichtigsten Anforderungen sind.

EVE Screen Designer als zentraler Bestandteil des EVE-Workflows

Ein Kernelement des Bridgetek EVE-Ökosystems ist der EVE Screen Designer (ESE), der eine zentrale Rolle bei der Erstellung von EVE-basierten Benutzeroberflächen spielt.

EVE Screen Designer ist ein visuelles, hardwareunabhängiges Tool, mit dem Sie komplette Benutzeroberflächen und Interaktionen entwerfen können, ohne dass Sie Zugriff auf die endgültige Zielhardware benötigen. Die Bildschirme werden aus grafischen Primitiven und Widgets zusammengesetzt, die direkt den Befehlen der EVE-Anzeigeliste entsprechen.

Aus der Perspektive des Entwicklungs-Workflows ermöglicht EVE Screen Designer:

• visuelle Gestaltung der UI-Bildschirme und des Navigationsflusses,
• Definition von Touch-Interaktionen und Bildschirmverhalten,
• Vorschau und Validierung der UI-Logik vor der Integration in die Firmware,
• Generierung von UI-Assets, die später vom Anwendungscode gesteuert werden.

Da ESE das zugrundeliegende EVE-Rendering-Modell widerspiegelt, arbeiten die Entwickler innerhalb genau definierter Grenzen, was zu einer vorhersehbaren Leistung beiträgt und Optimierungsprobleme in der Spätphase vermeidet.

EVE Bildschirm Designer

LVGL unter EVE – ein hybrider Ansatz

Eine interessante Erweiterung des EVE-Konzepts ist das Referenzprojekt, das gemeinhin als „LVGL running on EVE“ bezeichnet wird. Bei diesem hybriden Ansatz wird LVGL als High-Level-GUI-Framework verwendet, während das eigentliche Rendering-Backend vom EVE-Controller übernommen wird.

Dieses Konzept wird in einem öffentlichen Referenz-Repository demonstriert, in dem LVGL für die Arbeit mit Bridgetek EVE-Geräten angepasst wurde.

Von einem architektonischen Standpunkt aus betrachtet:

• LVGL bietet ein portables und vertrautes Benutzeroberflächenmodell,
• EVE dient als Rendering-Engine und Anzeigeoberfläche,
• koordiniert die Host-MCU die Anwendungslogik und die Aktualisierungen der Benutzeroberfläche.

Dieses hybride Modell verdeutlicht, dass die drei in diesem Artikel beschriebenen GUI-Kategorien keine starren Grenzen darstellen, sondern architektonische Bausteine, die kombiniert werden können, wenn die Projektanforderungen dies rechtfertigen.

Eine Anzeigeplattform, mehrere GUI-Ansätze

Aus Sicht der Anzeige erfordern die bisher beschriebenen architektonischen Unterschiede nicht unbedingt eine unterschiedliche Anzeigehardware.

Die gleiche physische Display-Plattform kann mit verwendet werden:

• herstellerspezifische MCU-basierte GUI-Lösungen,
• plattformübergreifende Frameworks, die auf MCUs oder MPUs laufen,
• Systeme mit externen Grafikcontrollern,
• Linux-basierte Plattformen mit Qt- oder webbasierten Benutzeroberflächen.

Solange die Bildschirmschnittstelle und die elektrischen Eigenschaften kompatibel sind, bleibt die Wahl der GUI-Technologie eine Entscheidung auf Systemebene und nicht eine Einschränkung auf der Ebene des Bildschirms.

Diese Flexibilität ist besonders wertvoll bei Produkten mit langen Lebenszyklen und Produktfamilien, die sich im Laufe der Zeit weiterentwickeln.

Wo Riverdi in diese Landschaft passt

Riverdi konzentriert sich auf die Bereitstellung von Display-Lösungen, die sich nahtlos in eine breite Palette von Embedded-Systemarchitekturen integrieren lassen.

Riverdi-Displays sind nicht an ein einziges GUI-Framework oder einen Rendering-Ansatz gebunden, sondern unterstützen diese:

• MCU-basierte Systeme mit herstellerspezifischen oder plattformübergreifenden GUI-Frameworks,
• EVE-basierte Architekturen mit ausgelagertem Rendering,
• MPU und Linux-basierte Plattformen unter Verwendung von Qt oder Web-Technologien.

So können Entwicklungsteams den GUI-Ansatz auswählen oder ändern und gleichzeitig die Anzeigeplattform über verschiedene Projekte und Produktgenerationen hinweg konsistent halten.

Schlussfolgerung - eine Architektur wählen, nicht eine Einschränkung

Die Entwicklung eingebetteter GUI wird nicht durch ein einziges Tool oder Framework definiert, sondern durch eine Reihe von Architekturentscheidungen, die ein Gleichgewicht zwischen Leistung, Komplexität und langfristiger Flexibilität herstellen.

Herstellerspezifische Lösungen bieten eine enge Integration und ein schnelles Onboarding.
Plattformübergreifende Frameworks ermöglichen Portabilität und Wiederverwendung.
Externe Grafikcontroller bieten eine vorhersehbare Leistung bei minimaler MCU-Belastung.

Mit einer gut gewählten Display-Plattform können diese Ansätze nebeneinander bestehen und sich im Laufe der Zeit weiterentwickeln, so dass sich die Teams auf die Systemarchitektur und das Benutzererlebnis konzentrieren können und nicht auf technische Beschränkungen.