¿Puede una pantalla integrada manejar otra al mismo tiempo?
En esta guía, mostramos cómo un único STM32H7 integrado en una pantalla Riverdi puede, simultáneamente:
- renderizar su propia GUI utilizando TouchGFX, y
- controlar una segunda pantalla basada en EVE4 a través de RiBUS (SPI).
El resultado es una plantilla limpia y repetible para sistemas de doble pantalla, como terminales de punto de venta, quioscos y paneles HMI industriales.
El ejemplo es intencionadamente mínimo. Se centra en:
- orden correcto de inicialización,
- una clara separación de responsabilidades,
- un estado de aplicación compartido utilizado por dos rutas de renderizado independientes.
La estructura está diseñada como una base práctica que puede ampliarse paso a paso en proyectos reales.
Visión general del hardware
Programación y depuración
- ST-LINK/V3 conectado mediante SWD al STM32H7 integrado en la pantalla Riverdi
- Sólo se programa el STM32H7
- La pantalla del EVE4 nunca parpadea y se comunica exclusivamente a través de SPI
(RiBUS)
STM32 + EVE4 – Blog
Muestra
Riverdi STM32 Embedded Display (maestro)
Pantalla de 7″ con STM32H7 integrado, controlada por TouchGFX.
Pantalla Riverdi EVE4 (esclava)
Pantalla de 7″ basada en EVE4, controlada por STM32H7 a través de RiBUS.
Interfaces
- SWD – programación y depuración
- SPI (RiBUS) – STM32H7 → Interfaz de comandos EVE4
- Interfaces táctiles en ambas pantallas
Pila de software
Desarrollo
- STM32CubeIDE
- STM32 HAL
- FreeRTOS
Gráficos e IU
- TouchGFX – GUI basada en framebuffer en la pantalla integrada del STM32H7
- EVE4 (BT81x) – renderizado basado en comandos mediante listas de visualización a través de SPI
Capa de aplicación
- Lógica de aplicación única en STM32H7
- Contextos de ejecución separados (tareas FreeRTOS)
- Estado de aplicación compartido utilizado para sincronizar ambas pantallas
Concepto de arquitectura: una lógica, dos renderizadores
El principio arquitectónico clave es la separación entre lógica y representación.
- STM32H7 posee el estado de la aplicación
- TouchGFX y EVE4 son backends de renderizado independientes
- Ambas pantallas reaccionan al mismo estado compartido
Modelos de renderizado
TouchGFX
- Renderizado basado en búfer de trama
- Totalmente gestionado por el STM32H7
EVE4
- Renderizado basado en comandos mediante Listas de Visualización
- Renderizado ejecutado por la GPU de EVE
El objetivo no es comparar estos enfoques, sino demostrar que ambos pueden coexistir limpiamente en un único sistema controlado por un microcontrolador.
Escenario de demostración: estado compartido e interacción bidireccional
El ejemplo muestra un pequeño estado compartido de la aplicación intercambiado entre dos UI independientes.
- La pantalla TouchGFX (maestra) propone los cambios.
- La pantalla del EVE4 (esclavo ) las confirma o las rechaza.
La interacción táctil en una pantalla afecta directamente al comportamiento de la otra.
Estado compartido de la aplicación
typedef struct {
uint8_t color_propuesto_maestro;
uint8_t solicitud_maestra_pendiente;
uint8_t esclavo_color_actual;
uint8_t esclavo_últimaRespuesta;
uint8_t esclavo_respuestaSucio;
} app_state_t;
volatile app_state_t gAppState = {
.color_propuesto_maestro = COLOR_ROJO,
.master_requestPending = 0,
.slave_currentColor = COLOR_ROJO,
.slave_lastResponse = SLAVE_IDLE,
.esclavo_respuestaSucio = 0
};
El estado se inicializa de forma determinista para que ambas pantallas comiencen sincronizadas.A partir de ahí:
- TouchGFX actualiza master_proposedColor y establece master_requestPending.
- EVE4 acepta o rechaza y actualiza slave_currentColor y slave_lastResponse.
Ambas rutas de renderizado leen continuamente gAppState y actualizan su IU en consecuencia.
Esto mantiene el flujo de interacción explícito, fácil de seguir y totalmente impulsado por la lógica de aplicación compartida de
, en lugar de por la comunicación directa de pantalla a pantalla.
Este modelo de interacción es intencionadamente sencillo y sirve de plantilla clara para proyectos reales de
en los que dos pantallas tienen que cooperar sin dejar de ser arquitectónicamente independientes.
Orden de inicialización
Aquí sólo se muestra la secuencia correcta.
- Inicialización de la MCU y relojes
HAL_Init() → SystemClock_Config() → PeriphCommonClock_Config() - Inicialización de periféricos
GPIO, LTDC/DSI, DMA2D/MDMA, SPI, temporizadores, memoria externa (SDRAM/QSPI) - Inicialización de TouchGFX
MX_TouchGFX_Init() → MX_TouchGFX_PreOSInit() - Inicialización SPI para RiBUS
MX_SPI1_Init() (o instancia seleccionada) - Inicialización de EVE4
EVE4_RiBUS_Init(&eve)
EVE4_RiBUS_ConfigIPS70(&eve) - Iniciar FreeRTOS
osKernelInitialize() → MX_FREERTOS_Init() → osKernelStart()
Seguir esta secuencia evita sutiles problemas de arranque y garantiza que ambas rutas de renderizado se inicialicen limpiamente. TouchGFX se inicia con un canal de visualización totalmente configurado, y el EVE4 está listo para renderizar en cuanto su tarea FreeRTOS comienza a ejecutarse.
Estructura del proyecto
Este proyecto mantiene la interfaz de usuario TouchGFX y la integración con EVE4 claramente separadas.
- CM7/Core/
Puesta en marcha de la MCU e inicialización de los periféricos (main.c, *_init.c)
configuración del sistema y puesta en marcha de la placa - CM7/TouchGFX/
Aplicación TouchGFX (pantallas, widgets, activos)
lógica principal de IU (pantalla maestra)
- Application/User/Core/
app_state.c / app_state.h – estado compartido de la aplicación maestro/esclavo (gAppState)
eve4_ribus.c / eve4_ribus.h – controlador EVE4 de bajo nivel (SPI + acceso a registros + ayudantes de la lista de pantallas)
eve_task.c – tarea EVE FreeRTOS (bucle de renderizado + manejo táctil de la pantalla esclava) - Aplicación/Usuario/gui/ (capa de usuario de TouchGFX)
por ejemplo Screen1View.cpp/.hpp – lógica de IU maestra (proponer color, reflejar estado esclavo)
Modelo de tiempo de ejecución (TouchGFX + tarea EVE)
La aplicación se ejecuta en FreeRTOS y utiliza dos contextos de ejecución independientes:
Tarea TouchGFX (pantalla maestra)
Gestiona la representación de la interfaz de usuario principal y la interacción táctil en la pantalla controlada por STM32.
Las acciones del usuario actualizan el estado compartido (gAppState).
Tarea EVE (pantalla esclava)
Crea e intercambia listas de pantallas EVE y procesa la entrada táctil en la pantalla EVE4. Las decisiones (aceptar/rechazar) actualizan gAppState y se reflejan en la interfaz de usuario maestra. Ambas rutas de renderizado reaccionan al mismo estado compartido de la aplicación, manteniendo la arquitectura simple y las responsabilidades claramente separadas.
Resumen de la renderización de EVE
La pantalla del EVE4 se actualiza mediante una secuencia de lista de visualización estándar ejecutada por
la GPU de EVE:
CLEAR_COLOR_RGB() – Fijar el color de fondo
CLEAR() – borra los buffers de dibujo
comandos de dibujo
DISPLAY() – termina la lista de visualización
Flush_DL_Buffer() – copia los comandos a RAM_DL
DLSWAP_FRAME – hace visible el nuevo fotograma
Este flujo de renderizado de bajo nivel se mantiene intencionadamente simple y sin cambios, proporcionando a
un control total sobre cómo y cuándo el EVE4 actualiza su pantalla.
Resultado
Con esta configuración:
- ambas pantallas funcionan simultáneamente,
- ambas pantallas reaccionan a la entrada táctil,
- la interacción del usuario en una pantalla se refleja en la otra.
El resultado es una arquitectura de doble pantalla limpia y escalable controlada por un único STM32H7, en la que una aplicación controla dos rutas de renderizado independientes con responsabilidades claramente separadas.
Resumen y próximos pasos
Esta plantilla proporciona un punto de partida para los sistemas que requieren dos pantallas controladas por un microcontrolador, utilizando modelos de representación diferentes pero una lógica de aplicación compartida.
Puede ampliarse de forma natural:
- ampliar el estado compartido,
- introducir funciones gráficas avanzadas de EVE,
- adaptar el modelo de interacción a flujos de trabajo más complejos,
- migrar a nuevas generaciones de EVE.
El proyecto de referencia completo está disponible en GitHub:
https://github.com/riverdi/STM32H7-EVE4
Este proyecto está diseñado como base práctica para sistemas escalables de doble pantalla basados en STM32 y EVE.
DESCUBRE NUESTRA
Libro Blanco
Consigue una interacción perfecta entre el usuario y la pantalla con el CI de sensor táctil adecuado. ¿Te has enfrentado alguna vez a problemas con eventos táctiles fantasma o de certificación? ¡Impulsa tu I+D como un profesional con nuestro Libro Blanco!
Ve a nuestro catálogo de productos y comprueba cómo puedes ahorrar por calidad, no en calidad.
