Kann ein eingebettetes Display ein anderes gleichzeitig ansteuern?
In dieser Anleitung zeigen wir, wie ein einzelner STM32H7 in ein Riverdi-Display integriert werden kann:
- seine eigene GUI mit TouchGFX rendern und
- ein zweites EVE4-basiertes Display über RiBUS (SPI) steuern.
Das Ergebnis ist eine saubere und wiederholbare Vorlage für Dual-Display-Systeme wie POS-Terminals, Kioske und industrielle HMI-Panels.
Das Beispiel ist absichtlich minimalistisch. Es konzentriert sich auf:
- die richtige Reihenfolge der Initialisierung,
- klare Trennung der Verantwortlichkeiten,
- einen gemeinsamen Anwendungsstatus, der von zwei unabhängigen Rendering-Pfaden verwendet wird.
Die Struktur ist als praktische Grundlage konzipiert, die in realen Projekten Schritt für Schritt erweitert werden kann.
Hardware-Übersicht
Programmierung und Fehlersuche
- ST-LINK/V3 über SWD mit dem STM32H7 auf dem Riverdi-Display verbunden
- Nur der STM32H7 wird programmiert
- Das EVE4-Display wird nie geflasht und kommuniziert ausschließlich über SPI
(RiBUS)
STM32 + EVE4 – Blog
Anzeigen
Riverdi STM32 Embedded Display (Master)
7″ Display mit integriertem STM32H7, gesteuert von TouchGFX.
Riverdi EVE4 Display (Slave)
7″ EVE4-basiertes Display, gesteuert von STM32H7 über RiBUS.
Schnittstellen
- SWD – Programmierung und Fehlersuche
- SPI (RiBUS) – STM32H7 → EVE4 Befehlsschnittstelle
- Touch-Oberflächen auf beiden Displays
Software-Stapel
Entwicklung
- STM32CubeIDE
- STM32 HAL
- FreeRTOS
Grafiken und UI
- TouchGFX – Framebuffer-basierte GUI auf dem im STM32H7 integrierten Display
- EVE4 (BT81x) – kommandobasiertes Rendering über Display-Listen über SPI
Anwendungsschicht
- Einzelne Anwendungslogik auf STM32H7
- Getrennte Ausführungskontexte (FreeRTOS-Tasks)
- Gemeinsamer Anwendungsstatus für die Synchronisierung beider Displays
Architekturkonzept – eine Logik, zwei Renderer
Das wichtigste architektonische Prinzip ist die Trennung von Logik und Rendering.
- Der STM32H7 besitzt den Anwendungsstatus
- TouchGFX und EVE4 sind unabhängige Rendering-Backends
- Beide Displays reagieren auf denselben gemeinsamen Status
Rendering Modelle
TouchGFX
- Framebuffer-basiertes Rendering
- Vollständig durch den STM32H7 gesteuert
EVE4
- Befehlsbasiertes Rendering mit Anzeigelisten
- Von der EVE GPU ausgeführtes Rendering
Das Ziel ist nicht, diese Ansätze zu vergleichen, sondern zu zeigen, dass beide in einem einzigen System, das von einem Mikrocontroller gesteuert wird, problemlos nebeneinander bestehen können.
Demo-Szenario – gemeinsamer Status und bidirektionale Interaktion
Das Beispiel demonstriert einen kleinen gemeinsamen Anwendungsstatus, der zwischen zwei unabhängigen Benutzeroberflächen ausgetauscht wird.
- Das TouchGFX-Display (Master) schlägt Änderungen vor.
- Das EVE4-Display (Slave) bestätigt oder lehnt sie ab.
Die Berührungsinteraktion auf einem Display wirkt sich direkt auf das Verhalten des anderen aus.
Gemeinsamer Anwendungsstatus
typedef struct {
uint8_t master_proposedColor;
uint8_t master_requestPending;
uint8_t slave_currentColor;
uint8_t slave_lastResponse;
uint8_t slave_responseDirty;
} app_state_t;
volatile app_state_t gAppState = {
.master_proposedColor = COLOR_RED,
.master_requestPending = 0,
.slave_currentColor = COLOR_RED,
.slave_lastResponse = SLAVE_IDLE,
.slave_responseDirty = 0
};
Der Status wird deterministisch initialisiert, so dass beide Displays synchron starten.Von diesem Punkt aus:
- TouchGFX aktualisiert master_proposedColor und setzt master_requestPending.
- EVE4 nimmt an oder lehnt ab und aktualisiert slave_currentColor und slave_lastResponse.
Beide Rendering-Pfade lesen kontinuierlich gAppState und aktualisieren ihre Benutzeroberfläche entsprechend.
Dadurch bleibt der Interaktionsfluss eindeutig, leicht nachvollziehbar und wird vollständig durch die gemeinsame Anwendungslogik von
gesteuert und nicht durch die direkte Kommunikation von Bildschirm zu Bildschirm.
Dieses Interaktionsmodell ist absichtlich einfach gehalten und dient als klare Vorlage für reale
Projekte, bei denen zwei Displays zusammenarbeiten und gleichzeitig architektonisch unabhängig bleiben müssen.
Reihenfolge der Initialisierung
Hier wird nur die richtige Reihenfolge angezeigt.
- MCU-Initialisierung und Takte
HAL_Init() → SystemClock_Config() → PeriphCommonClock_Config() - Peripherie-Initialisierung
GPIO, LTDC/DSI, DMA2D/MDMA, SPI, Timer, externer Speicher (SDRAM/QSPI) - TouchGFX-Initialisierung
MX_TouchGFX_Init() → MX_TouchGFX_PreOSInit() - SPI-Initialisierung für RiBUS
MX_SPI1_Init() (oder ausgewählte Instanz) - EVE4-Initialisierung
EVE4_RiBUS_Init(&eve)
EVE4_RiBUS_ConfigIPS70(&eve) - FreeRTOS starten
osKernelInitialize() → MX_FREERTOS_Init() → osKernelStart()
Wenn Sie diese Reihenfolge einhalten, vermeiden Sie subtile Startprobleme und stellen sicher, dass beide Rendering-Pfade sauber initialisiert werden. TouchGFX startet mit einer vollständig konfigurierten Display-Pipeline, und der EVE4 ist bereit zum Rendern, sobald seine FreeRTOS-Aufgabe mit der Ausführung beginnt.
Struktur des Projekts
Bei diesem Projekt werden die TouchGFX-Benutzeroberfläche und die EVE4-Integration klar voneinander getrennt.
- CM7/Core/
MCU-Start und Peripherie-Initialisierung (main.c, *_init.c)
Systemkonfiguration und Einrichten der Karte - CM7/TouchGFX/
TouchGFX-Anwendung (Bildschirme, Widgets, Assets)
Haupt-UI-Logik (Master-Display)
- Anwendung/Benutzer/Kern/
app_state.c / app_state.h – gemeinsamer Master/Slave-Anwendungsstatus (gAppState)
eve4_ribus.c / eve4_ribus.h – Low-Level EVE4-Treiber (SPI + Registerzugriff + Displaylisten-Helfer)
eve_task.c – EVE FreeRTOS-Task (Rendering-Schleife + Touch-Handling auf dem Slave-Display) - Anwendung/Benutzer/gui/ (TouchGFX-Benutzerschicht)
z.B. Screen1View.cpp/.hpp – Master-UI-Logik (Farbe vorschlagen, Slave-Status wiedergeben)
Laufzeitmodell (TouchGFX + EVE-Aufgabe)
Die Anwendung läuft unter FreeRTOS und verwendet zwei unabhängige Ausführungskontexte:
TouchGFX Aufgabe (Hauptanzeige)
Verwaltet das Haupt-UI-Rendering und die Touch-Interaktion auf dem STM32-gesteuerten Display.
Benutzeraktionen aktualisieren den gemeinsamen Status (gAppState).
EVE Aufgabe (Slave-Anzeige)
Erstellt und tauscht EVE-Anzeigelisten und verarbeitet Berührungseingaben auf dem EVE4-Display. Entscheidungen (akzeptieren/ablehnen) aktualisieren gAppState und werden auf der Master-Benutzeroberfläche wiedergegeben. Beide Rendering-Pfade reagieren auf denselben gemeinsamen Anwendungsstatus, wodurch die Architektur einfach und die Verantwortlichkeiten klar getrennt bleiben.
EVE Rendering-Zusammenfassung
Die EVE4-Anzeige wird mit einer Standard-Anzeigelistensequenz aktualisiert, die von
die EVE GPU:
CLEAR_COLOR_RGB() – Hintergrundfarbe setzen
CLEAR() – Löscht die Zeichenpuffer
Zeichenbefehle
DISPLAY() – Beenden der Anzeigeliste
Flush_DL_Buffer() – Kopieren von Befehlen in RAM_DL
DLSWAP_FRAME – Sichtbarmachen des neuen Frames
Dieser Low-Level-Rendering-Flow ist absichtlich einfach und unverändert gehalten und bietet
die volle Kontrolle darüber, wie und wann EVE4 seine Anzeige aktualisiert.
Ergebnis
Mit dieser Einstellung:
- beide Anzeigen laufen gleichzeitig,
- beide Displays reagieren auf Berührungseingaben,
- Die Benutzerinteraktion auf einem Bildschirm wird auf dem anderen wiedergegeben.
Das Ergebnis ist eine saubere und skalierbare Dual-Display-Architektur, die von einem einzigen STM32H7 gesteuert wird, wobei eine Anwendung zwei unabhängige Rendering-Pfade mit klar getrennten Verantwortlichkeiten steuert.
Zusammenfassung und nächste Schritte
Diese Vorlage bietet einen Ausgangspunkt für Systeme, die zwei von einem Mikrocontroller gesteuerte Displays benötigen, die unterschiedliche Rendering-Modelle, aber eine gemeinsame Anwendungslogik verwenden.
Sie kann natürlich erweitert werden:
- erweitern Sie den gemeinsamen Status,
- erweiterte EVE-Grafikfunktionen einführen,
- das Interaktionsmodell an komplexere Arbeitsabläufe anzupassen,
- auf neuere EVE-Generationen umsteigen.
Das vollständige Referenzprojekt ist auf GitHub verfügbar:
https://github.com/riverdi/STM32H7-EVE4
Dieses Projekt ist als praktische Grundlage für skalierbare Dual-Display-Systeme auf Basis von STM32 und EVE konzipiert.
ENTDECKEN SIE UNSER
Whitepaper
Erzielen Sie die perfekte Interaktion zwischen Benutzer und Display mit dem richtigen Touchsensor-IC. Hatten Sie jemals Probleme mit Phantomberührungen oder Zertifizierungen? Verbessern Sie Ihre Forschung und Entwicklung wie ein Profi mit unserem Whitepaper!
Schauen Sie sich unseren Produktkatalog an und sehen Sie, wie Sie durch Qualität und nicht an Qualität sparen können.
