Un display incorporato può pilotarne un altro allo stesso tempo?
In questa guida ti mostriamo come un singolo STM32H7 integrato in un display Riverdi può essere utilizzato contemporaneamente:
- renderizzare la propria interfaccia grafica utilizzando TouchGFX e
- controllare un secondo display basato su EVE4 tramite RiBUS (SPI).
Il risultato è un modello pulito e ripetibile per sistemi a doppio display come terminali POS, chioschi e pannelli HMI industriali.
L’esempio è volutamente minimale. Si concentra su:
- ordine di inizializzazione corretto,
- una chiara separazione delle responsabilità,
- uno stato applicativo condiviso utilizzato da due percorsi di rendering indipendenti.
La struttura è concepita come una base pratica che può essere ampliata passo dopo passo in progetti reali.
Panoramica dell’hardware
Programmazione e debug
- ST-LINK/V3 collegato via SWD all’STM32H7 integrato nel display Riverdi
- Viene programmato solo l’STM32H7
- Il display dell’EVE4 non viene mai flashato e comunica esclusivamente tramite SPI
(RiBUS)
STM32 + EVE4 – Blog
Visualizzazioni
Riverdi STM32 Embedded Display (master)
Display da 7″ con STM32H7 integrato, pilotato da TouchGFX.
Display EVE4 Riverdi (slave)
Display da 7″ basato su EVE4, controllato da STM32H7 su RiBUS.
Interfacce
- SWD – programmazione e debug
- SPI (RiBUS) – STM32H7 → Interfaccia di comando EVE4
- Interfacce touch su entrambi i display
Pila software
Sviluppo
- STM32CubeIDE
- STM32 HAL
- FreeRTOS
Grafica e interfaccia utente
- TouchGFX – GUI basata su framebuffer sul display integrato nell’STM32H7
- EVE4 (BT81x) – rendering basato su comandi tramite liste di visualizzazione su SPI
Livello applicazione
- Logica di applicazione singola su STM32H7
- Contesti di esecuzione separati (task FreeRTOS)
- Stato dell’applicazione condiviso utilizzato per sincronizzare entrambi gli schermi
Concetto di architettura: una logica, due rendering
Il principio architettonico chiave è la separazione tra logica e rendering.
- L’STM32H7 è proprietario dello stato dell’applicazione
- TouchGFX e EVE4 sono backend di rendering indipendenti
- Entrambi i display reagiscono allo stesso stato condiviso
Modelli di rendering
TouchGFX
- Rendering basato su framebuffer
- Completamente gestito dall’STM32H7
EVE4
- Rendering basato sui comandi utilizzando gli elenchi di visualizzazione
- Rendering eseguito dalla GPU di EVE
L’obiettivo non è quello di confrontare questi approcci, ma di dimostrare che entrambi possono coesistere in un unico sistema gestito da un microcontrollore.
Scenario dimostrativo: stato condiviso e interazione bidirezionale
L’esempio mostra un piccolo stato condiviso dell’applicazione scambiato tra due UI indipendenti.
- Il display TouchGFX (master) propone le modifiche.
- Il display dell’EVE4 (slave) li conferma o li rifiuta.
L’interazione touch su un display influisce direttamente sul comportamento dell’altro.
Stato dell’applicazione condivisa
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
};
Lo stato viene inizializzato in modo deterministico in modo che entrambi i display partano sincronizzati.Da quel momento:
- TouchGFX aggiorna master_proposedColor e imposta master_requestPending.
- EVE4 accetta o rifiuta e aggiorna slave_currentColor e slave_lastResponse.
Entrambi i percorsi di rendering leggono continuamente gAppState e aggiornano l’interfaccia utente di conseguenza.
In questo modo il flusso di interazione rimane esplicito, facile da seguire e completamente guidato dalla logica applicativa condivisa di
piuttosto che dalla comunicazione diretta tra display.
Questo modello di interazione è volutamente semplice e serve come modello chiaro per i progetti reali di
in cui due display devono cooperare pur rimanendo architettonicamente indipendenti.
Ordine di inizializzazione
Qui viene mostrata solo la sequenza corretta.
- Inizializzazione e clock dell’MCU
HAL_Init() → SystemClock_Config() → PeriphCommonClock_Config() - Inizializzazione delle periferiche
GPIO, LTDC/DSI, DMA2D/MDMA, SPI, timer, memoria esterna (SDRAM/QSPI) - Inizializzazione di TouchGFX
MX_TouchGFX_Init() → MX_TouchGFX_PreOSInit() - Inizializzazione SPI per RiBUS
MX_SPI1_Init() (o istanza selezionata) - Inizializzazione di EVE4
EVE4_RiBUS_Init(&eve)
EVE4_RiBUS_ConfigIPS70(&eve) - Avviare FreeRTOS
osKernelInitialize() → MX_FREERTOS_Init() → osKernelStart()
Seguendo questa sequenza si evitano problemi di avvio e si assicura che entrambi i percorsi di rendering siano inizializzati in modo pulito. TouchGFX inizia con una pipeline di visualizzazione completamente configurata, mentre EVE4 è pronto per il rendering non appena il suo task FreeRTOS inizia l’esecuzione.
Struttura del progetto
Questo progetto mantiene chiaramente separate l’interfaccia TouchGFX e l’integrazione di EVE4.
- CM7/Core/
Avvio dell’MCU e inizializzazione delle periferiche (main.c, *_init.c)
configurazione del sistema e creazione della scheda - CM7/TouchGFX/
Applicazione TouchGFX (schermate, widget, asset)
Logica UI principale (display master)
- Application/User/Core/
app_state.c / app_state.h – stato dell’applicazione master/slave condiviso (gAppState)
eve4_ribus.c / eve4_ribus.h – driver EVE4 di basso livello (SPI + accesso ai registri + helper per l’elenco dei display)
eve_task.c – task EVE FreeRTOS (loop di rendering + gestione del touch sul display slave) - Application/User/gui/ (livello utente TouchGFX)
ad esempio Screen1View.cpp/.hpp – logica master dell’interfaccia utente (proporre il colore, riflettere lo stato dello slave)
Modello di runtime (TouchGFX + task EVE)
L’applicazione viene eseguita in FreeRTOS e utilizza due contesti di esecuzione indipendenti:
Attività TouchGFX (display principale)
Gestisce il rendering dell’interfaccia utente principale e l’interazione tattile sul display guidato dall’STM32.
Le azioni dell’utente aggiornano lo stato condiviso (gAppState).
Compito di EVE (visualizzazione dello slave)
Costruisce e scambia gli elenchi dei display di EVE ed elabora gli input tattili sul display di EVE4. Le decisioni (accettazione/rifiuto) aggiornano gAppState e si riflettono sull’interfaccia utente principale. Entrambi i percorsi di rendering reagiscono allo stesso stato condiviso dell’applicazione, mantenendo l’architettura semplice e le responsabilità chiaramente separate.
Riassunto del rendering di EVE
Il display di EVE4 viene aggiornato utilizzando una sequenza standard di elenchi di display eseguita da
la GPU di EVE:
CLEAR_COLOR_RGB() – imposta il colore di sfondo
CLEAR() – cancella i buffer di disegno
comandi di disegno
DISPLAY() – termina l’elenco di visualizzazione
Flush_DL_Buffer() – copia i comandi nella RAM_DL
DLSWAP_FRAME – rende visibile il nuovo fotogramma
Questo flusso di rendering di basso livello è intenzionalmente mantenuto semplice e invariato, fornendo a
il pieno controllo su come e quando l’EVE4 aggiorna il suo display.
Risultato
Con questa configurazione:
- entrambi i display funzionano contemporaneamente,
- entrambi i display reagiscono all’input tattile,
- L’interazione dell’utente su uno schermo si riflette sull’altro.
Il risultato è un’architettura a doppio display pulita e scalabile gestita da un unico STM32H7, dove un’applicazione controlla due percorsi di rendering indipendenti con responsabilità chiaramente separate.
Riepilogo e passi successivi
Questo modello fornisce un punto di partenza per i sistemi che richiedono due display gestiti da un unico microcontrollore, utilizzando modelli di rendering diversi ma una logica applicativa condivisa.
Può essere esteso in modo naturale:
- espandere lo stato condiviso,
- introdurre caratteristiche grafiche avanzate di EVE,
- adattare il modello di interazione a flussi di lavoro più complessi,
- migrare verso le nuove generazioni di EVE.
Il progetto di riferimento completo è disponibile su GitHub:
https://github.com/riverdi/STM32H7-EVE4
Questo progetto è stato concepito come base pratica per sistemi scalabili a doppio display basati su STM32 ed EVE.
SCOPRI IL NOSTRO
Carta bianca
Ottieni un’interazione perfetta tra utente e display con il giusto IC per sensore tattile. Hai mai avuto problemi con eventi di tocco fantasma o con la certificazione? Potenzia la tua ricerca e sviluppo come un professionista con il nostro Whitepaper!
Consulta il nostro catalogo prodotti e scopri come puoi risparmiare sulla qualità, non sulla qualità.
