Un écran intégré peut-il en piloter un autre en même temps ?
Dans ce guide, nous montrons comment un simple STM32H7 intégré dans un écran Riverdi peut simultanément :
- rendre son propre GUI en utilisant TouchGFX, et
- contrôler un deuxième écran basé sur l’EVE4 via RiBUS (SPI).
Il en résulte un modèle propre et reproductible pour les systèmes à double affichage tels que les terminaux de point de vente, les kiosques et les panneaux IHM industriels.
L’exemple est délibérément minimal. Il se concentre sur :
- ordre d’initialisation correct,
- une séparation claire des responsabilités,
- un état d’application partagé utilisé par deux chemins de rendu indépendants.
La structure est conçue comme une base pratique qui peut être étendue pas à pas dans des projets réels.
Aperçu du matériel
Programmation et débogage
- ST-LINK/V3 connecté via SWD au STM32H7 intégré à l’écran Riverdi
- Seul le STM32H7 est programmé
- L’écran EVE4 n’est jamais flashé et communique exclusivement via SPI
(RiBUS)
STM32 + EVE4 – Blog
Affiche
Riverdi STM32 Embedded Display (master)
Écran 7″ avec STM32H7 intégré, piloté par TouchGFX.
Afficheur Riverdi EVE4 (esclave)
Afficheur 7″ basé sur EVE4, contrôlé par STM32H7 via RiBUS.
Interfaces
- SWD – programmation et débogage
- SPI (RiBUS) – STM32H7 → Interface de commande EVE4
- Interfaces tactiles sur les deux écrans
Pile logicielle
Développement
- STM32CubeIDE
- STM32 HAL
- FreeRTOS
Graphisme et interface utilisateur
- TouchGFX – interface graphique basée sur le framebuffer sur l’écran intégré du STM32H7
- EVE4 (BT81x) – rendu basé sur des commandes via des listes d’affichage sur SPI
Couche application
- Logique d’application unique sur STM32H7
- Contextes d’exécution séparés (tâches FreeRTOS)
- État partagé de l’application utilisé pour synchroniser les deux écrans
Concept d’architecture – une logique, deux rendus
Le principe architectural clé est la séparation de la logique et du rendu.
- Le STM32H7 possède l’état de l’application
- TouchGFX et EVE4 sont des backends de rendu indépendants.
- Les deux écrans réagissent au même état partagé
Modèles de rendu
TouchGFX
- Rendu basé sur le tampon d’images
- Entièrement géré par le STM32H7
EVE4
- Rendu par commande à l’aide de listes d’affichage
- Rendu exécuté par le GPU EVE
L’objectif n’est pas de comparer ces approches, mais de montrer qu’elles peuvent coexister sans problème dans un système unique piloté par un microcontrôleur.
Scénario de démonstration – état partagé et interaction bidirectionnelle
L’exemple montre un petit état d’application partagé échangé entre deux interfaces utilisateur indépendantes.
- L’écran TouchGFX (maître) propose des changements.
- L’écran EVE4 (esclave) les confirme ou les rejette.
L’interaction tactile sur un écran affecte directement le comportement de l’autre.
État de l’application partagée
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
} ;
L'état est initialisé de manière déterministe afin que les deux écrans démarrent de manière synchronisée.A partir de là :
- TouchGFX met à jour master_proposedColor et définit master_requestPending.
- EVE4 accepte ou rejette et met à jour slave_currentColor et slave_lastResponse.
Les deux chemins de rendu lisent continuellement gAppState et mettent à jour leur interface utilisateur en conséquence.
Le flux d’interaction reste ainsi explicite, facile à suivre et entièrement piloté par la logique d’application partagée de
plutôt que par une communication directe d’écran à écran.
Ce modèle d’interaction est volontairement simple et sert de modèle clair pour les projets réels
où deux écrans doivent coopérer tout en restant indépendants sur le plan architectural.
Ordre d’initialisation
Seule la séquence correcte est présentée ici.
- Initialisation du MCU et horloges
HAL_Init() → SystemClock_Config() → PeriphCommonClock_Config() - Initialisation des périphériques
GPIO, LTDC/DSI, DMA2D/MDMA, SPI, minuteries, mémoire externe (SDRAM/QSPI) - Initialisation de TouchGFX
MX_TouchGFX_Init() → MX_TouchGFX_PreOSInit() - Initialisation SPI pour RiBUS
MX_SPI1_Init() (ou instance sélectionnée) - Initialisation de l’EVE4
EVE4_RiBUS_Init(&eve)
EVE4_RiBUS_ConfigIPS70(&eve) - Démarrer FreeRTOS
osKernelInitialize() → MX_FREERTOS_Init() → osKernelStart()
Suivre cette séquence permet d’éviter des problèmes subtils au démarrage et garantit que les deux chemins de rendu sont initialisés proprement. TouchGFX démarre avec un pipeline d’affichage entièrement configuré, et l’EVE4 est prêt à effectuer le rendu dès que sa tâche FreeRTOS commence à s’exécuter.
Structure du projet
Ce projet sépare clairement l’interface TouchGFX et l’intégration d’EVE4.
- CM7/Core/
Démarrage du MCU et initialisation des périphériques (main.c, *_init.c)
Configuration du système et mise en service de la carte - CM7/TouchGFX/
Application TouchGFX (écrans, widgets, actifs)
Logique principale de l’interface utilisateur (affichage principal)
- Application/User/Core/
app_state.c / app_state.h – état partagé de l’application maître/esclave (gAppState)
eve4_ribus.c / eve4_ribus.h – pilote EVE4 de bas niveau (SPI + accès aux registres + aides à la liste d’affichage)
eve_task.c – tâche EVE FreeRTOS (boucle de rendu + gestion du toucher sur l’écran esclave) - Application/User/gui/ (couche utilisateur TouchGFX)
par exemple Screen1View.cpp/.hpp – logique de l’interface utilisateur principale (proposer une couleur, refléter l’état de l’esclave)
Modèle d’exécution (TouchGFX + tâche EVE)
L’application fonctionne sous FreeRTOS et utilise deux contextes d’exécution indépendants :
Tâche TouchGFX (écran principal)
Gère le rendu de l’interface utilisateur principale et l’interaction tactile sur l’écran piloté par le STM32.
Les actions de l’utilisateur mettent à jour l’état partagé (gAppState).
Tâche EVE (affichage de l’esclave)
Construit et échange les listes d’affichage EVE et traite les entrées tactiles sur l’écran EVE4. Les décisions (acceptation/rejet) mettent à jour gAppState et sont répercutées sur l’interface utilisateur principale. Les deux chemins de rendu réagissent au même état partagé de l’application, ce qui simplifie l’architecture et sépare clairement les responsabilités.
Récapitulatif du rendu EVE
L’affichage EVE4 est mis à jour à l’aide d’une séquence standard de liste d’affichage exécutée par
le GPU EVE :
CLEAR_COLOR_RGB() – définit la couleur d’arrière-plan
CLEAR() – efface les tampons de dessin
commandes de dessin
DISPLAY() – termine la liste d’affichage
Flush_DL_Buffer() – copie les commandes dans RAM_DL
DLSWAP_FRAME – rend la nouvelle image visible
Ce flux de rendu de bas niveau est intentionnellement maintenu simple et inchangé, offrant à
un contrôle total sur la manière et le moment où l’EVE4 met à jour son affichage.
Résultat
Avec cette configuration :
- les deux écrans fonctionnent simultanément,
- les deux écrans réagissent au toucher,
- l’interaction de l’utilisateur sur un écran se reflète sur l’autre.
Le résultat est une architecture à double affichage propre et évolutive pilotée par un seul STM32H7, où une application contrôle deux chemins de rendu indépendants avec des responsabilités clairement séparées.
Résumé et prochaines étapes
Ce modèle constitue un point de départ pour les systèmes nécessitant deux écrans pilotés par un microcontrôleur, utilisant des modèles de rendu différents mais une logique d’application partagée.
Il peut être prolongé naturellement :
- étendre l’état partagé,
- introduire des fonctions graphiques avancées pour EVE,
- adapter le modèle d’interaction à des flux de travail plus complexes,
- migrer vers les nouvelles générations d’EVE.
Le projet de référence complet est disponible sur GitHub :
https://github.com/riverdi/STM32H7-EVE4
Ce projet est conçu comme une base pratique pour les systèmes évolutifs à double affichage basés sur STM32 et EVE.
DÉCOUVREZ NOTRE
Livre blanc
Réalisez l’interaction parfaite entre l’utilisateur et l’écran avec le bon circuit intégré pour capteur tactile. Vous avez déjà été confronté à des problèmes d’événements tactiles fantômes ou de certification ? Boostez votre R&D comme un pro grâce à notre livre blanc !
Consultez notre catalogue de produits et voyez comment vous pouvez économiser sur la qualité, et non sur la qualité.
