Índice
¿Por qué medir los FPS en los sistemas embebidos?
Medir los FPS en sistemas embebidos ayuda a cuantificar la capacidad de respuesta y la fluidez de la interfaz de usuario en condiciones reales de hardware. Proporciona una métrica sencilla y comparable que facilita la detección de problemas de rendimiento, la evaluación de optimizaciones y la validación de si el sistema cumple sus requisitos.
En la práctica, los FPS se utilizan a menudo como una señal de respuesta rápida durante el desarrollo, que pone de manifiesto problemas relacionados con la carga de la CPU, el ancho de banda de la memoria o el rendimiento de la pantalla. Aunque no cuenta toda la historia, es un punto de partida útil para comprender y mejorar el rendimiento general de la interfaz de usuario.
¿Cómo medir los FPS en sistemas embebidos?
Medir los FPS (fotogramas por segundo) en los sistemas embebidos no es tan sencillo como en los entornos de escritorio. Normalmente no hay un perfilador integrado, contadores de GPU ni un canal de renderizado estandarizado. En su lugar, los FPS deben derivarse de cómo y cuándo se actualiza realmente la pantalla.
En la práctica, la medición de los FPS consiste en responder a una pregunta:
¿Con qué frecuencia produce el sistema un fotograma completamente renderizado?
La respuesta depende de la pila gráfica, el modelo de renderizado y la interfaz de visualización.
¿Qué significa marco en incrustado?
Antes de medir los FPS, es importante definir qué es un «fotograma».
En los sistemas empotrados, un marco puede significar:
- actualización completa del búfer de fotogramas (común en el doble búfer)
- actualización parcial (sólo zonas sucias)
- descarga de pantalla (transferencia a pantalla)
Por ello, los FPS pueden ser
- render FPS – frecuencia con la que se dibuja la IU
- FPS de pantalla – frecuencia con la que se envían píxeles a la pantalla
No siempre son iguales.
En este ejemplo nos centraremos en el renderizado FPS.
STM32 / Bare metal (Enfoque genérico)
En los sistemas MCU (por ejemplo, STM32), los FPS se suelen medir utilizando un temporizador o un contador de ciclos.
Enfoque:
- incrementa el contador de fotogramas al final del bucle de renderizado
- medir el tiempo transcurrido mediante el contador de ciclos SysTick o DWT
volatile uint32_t frame_count = 0;
void render_frame(void)
{
// dibuja la IU
frame_count++;
}
Luego, en una tarea periódica:
void fps_task(void)
{
static uint32_t last = 0;
uint32_t now = HAL_GetTick();
if (now – last >= 1000) {
printf(«FPS: %lun», frame_count);
frame_count = 0;
last = now;
}
}
Qué mide esto:
- renderizar FPS
Alternativa (más precisa):
Utiliza el registro DWT->CYCCNT para medir el tiempo exacto de fotograma en ciclos de CPU.
Una forma más precisa de medir los FPS en STM32 (y Cortex-M en general) es utilizar el contador de ciclos DWT (DWT->CYCCNT), que cuenta los ciclos de reloj de la CPU en lugar de basarse en los ticks del sistema en milisegundos.
Cómo funciona:
Al principio de una trama, almacenas el valor actual de CYCCNT. Al final del fotograma, lo vuelves a leer y calculas la diferencia. Esto te da el número exacto de ciclos de CPU gastados en renderizar un único fotograma. Conociendo la frecuencia de la CPU, puedes calcular los FPS:
FPS = Frecuencia_CPU / ciclos_por_fotograma
Ventajas:
- Precisión muy alta (precisión a nivel de ciclo)
- Ideal para el análisis y la optimización del rendimiento
- No le afectan las interrupciones SysTick ni el jitter de programación
Desventajas:
- Requiere una frecuencia de reloj de CPU conocida y estable
- No disponible en todos los núcleos Cortex-M (por ejemplo, M0/M0+)
- Algo más complejo de configurar y utilizar
- El desbordamiento del contador debe tenerse en cuenta en las mediciones más largas
Monitor de rendimiento LVGL (LV_USE_PERF_MONITOR)
LVGL proporciona una forma integrada de monitorizar el rendimiento activando la opción LV_USE_PERF_MONITOR en la configuración (lv_conf.h). Cuando está activada, LVGL muestra una pequeña superposición en pantalla con métricas en tiempo real.
Esto suele incluir:
- FPS (fotogramas por segundo)
- Uso de la CPU (tiempo empleado en tareas LVGL)
- a veces estadísticas relacionadas con la memoria (dependiendo de la configuración)
El monitor funciona internamente haciendo un seguimiento de la frecuencia con la que se ejecuta el bucle de renderizado y del tiempo que se dedica a procesar tareas y a dibujar.
Qué mide esto:
- una mezcla de FPS de renderizado y carga del sistema
- más cerca del «rendimiento de la interfaz de usuario» que de los FPS brutos de la pantalla
Por qué es útil:
- configuración de esfuerzo cero (sólo tienes que activarla en la configuración)
- información visual inmediata durante el desarrollo
- ideal para una rápida validación del rendimiento y comprobaciones de regresión
Limitaciones:
- no mide el tiempo real de transferencia de la pantalla (descarga a pantalla)
- Los FPS pueden no reflejar las actualizaciones a pantalla completa cuando se utiliza el redibujado parcial
- añade una ligera sobrecarga (debe desactivarse en producción)
En la práctica, LV_USE_PERF_MONITOR es la forma más rápida de obtener una comprensión aproximada del rendimiento del sistema, pero para obtener mediciones precisas -especialmente cuando se optimiza el ancho de banda o los controladores de pantalla- debe combinarse con temporización de nivel inferior (por ejemplo, midiendo las devoluciones de llamada de descarga).
LVGL proporciona una forma integrada de monitorizar el rendimiento activando la opción LV_USE_PERF_MONITOR en la configuración (lv_conf.h). Cuando está activada, LVGL muestra una pequeña superposición en pantalla con métricas en tiempo real.
Esto suele incluir:
- FPS (fotogramas por segundo)
- Uso de la CPU (tiempo empleado en tareas LVGL)
- a veces estadísticas relacionadas con la memoria (dependiendo de la configuración)
El monitor funciona internamente haciendo un seguimiento de la frecuencia con la que se ejecuta el bucle de renderizado y del tiempo que se dedica a procesar tareas y a dibujar.
Qué mide esto:
- una mezcla de FPS de renderizado y carga del sistema
- más cerca del «rendimiento de la interfaz de usuario» que de los FPS brutos de la pantalla
Por qué es útil:
- configuración de esfuerzo cero (sólo tienes que activarla en la configuración)
- información visual inmediata durante el desarrollo
- ideal para una rápida validación del rendimiento y comprobaciones de regresión
Limitaciones:
- no mide el tiempo real de transferencia de la pantalla (descarga a pantalla)
- Los FPS pueden no reflejar las actualizaciones a pantalla completa cuando se utiliza el redibujado parcial
- añade una ligera sobrecarga (debe desactivarse en producción)
En la práctica, LV_USE_PERF_MONITOR es la forma más rápida de obtener una comprensión aproximada del rendimiento del sistema, pero para obtener mediciones precisas -especialmente cuando se optimiza el ancho de banda o los controladores de pantalla- debe combinarse con temporización de nivel inferior (por ejemplo, midiendo las devoluciones de llamada de descarga).
MPU/Linux
En sistemas Linux, la medición de FPS depende de la pila gráfica.
Framebuffer simple (fbdev)
Mide el tiempo entre intercambios de búfer:
clock_gettime(CLOCK_MONOTONIC, &t1);
// render + memcpy to framebuffer
clock_gettime(CLOCK_MONOTONIC, &t2);
Wayland / Marcos GUI
Las opciones incluyen:
- herramientas integradas (por ejemplo, el contador de FPS de Weston)
- temporización a nivel de aplicación
- Herramientas de perfilado de la GPU (si están disponibles)
Conclusiones
Medir los FPS en sistemas embebidos requiere comprender lo que representa realmente un «fotograma» en una determinada canalización. Tanto si se miden los bucles de renderizado, las devoluciones de llamada de descarga o los intercambios de búfer, cada método refleja un aspecto diferente del rendimiento. Los marcos como LVGL o las pilas basadas en Linux proporcionan ganchos útiles, pero depende del desarrollador elegir el punto de medición adecuado.
En la práctica, los FPS por sí solos no bastan. La consistencia del tiempo de fotogramas, la latencia y el ancho de banda de la memoria suelen tener un mayor impacto en el rendimiento percibido. Una velocidad de fotogramas estable y predecible suele ser más importante que conseguir los FPS más altos posibles.
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.
