Un framebuffer puede caber en la RAM mientras una pantalla STM32 LTDC todavía se queda sin datos de píxeles. La capacidad responde cuántos bytes se pueden almacenar. El ancho de banda describe el tráfico recurrente. El desbordamiento de FIFO se refiere a si el controlador recibe datos antes de que se agote su reserva actual. Un diseño debe abordar los tres aspectos.
Este análisis cubre el scanout continuo desde un framebuffer lineal y sin comprimir. Sus cifras son supuestos didácticos, no temporizaciones de panel ni garantías de rendimiento del STM32. El objetivo es construir una cuenta de tráfico y una investigación de latencia de servicio antes de decidir que una interfaz de memoria es adecuada.
Comenzar con la capacidad, luego incorporar el tiempo en el cálculo
Suponer una imagen activa de 800 x 480 almacenada en RGB565 a dos bytes por píxel. Un frame asignado de forma compacta requiere 800 x 480 x 2 = 768.000 bytes. Dos framebuffers de este tipo requieren 1.536.000 bytes. Cualquier asignación real también debe satisfacer sus requisitos de diseño y de memoria.
Esas cifras establecen el almacenamiento, no una tasa de transferencia. El mismo frame almacenado puede leerse repetidamente sin cambiar. A la inversa, renderizar un frame de reemplazo añade tráfico incluso antes de que el motor de pantalla lo lea.
TouchGFX 4.27 describe el costo de almacenamiento y el ciclo de vida del doble búfer: un búfer puede suministrar lectura continua de pantalla mientras otro se renderiza, con un intercambio controlado.[2] Dos búferes asignados no significan que LTDC lea dos imágenes completas en cada refresco.
Los búferes almacenan imágenes; las capas son entradas de composición configuradas. Múltiples capas activas pueden requerir lecturas separadas. El doble búfer de una capa cambia las ubicaciones sucesivas de los frames, no el número de capas leídas conjuntamente.
Distinguir el tráfico promedio por frame del consumo activo
Mantener la imagen didáctica en 800 x 480 y suponer un refresco de 60 Hz. La carga útil de píxeles activos leída a lo largo de un segundo completo es:
800 x 480 x 60 x 2 = 46.080.000 bytes/sEso es 46,08 MB/s usando megabytes decimales. Es un promedio durante el intervalo de frame, no una garantía de que la memoria pueda retrasar el servicio arbitrariamente dentro de ese intervalo.
Ahora suponer dimensiones totales de temporización de 1056 x 525, incluyendo el blanking. El reloj de píxeles correspondiente es 1056 x 525 x 60 = 33,264 MHz. Multiplicar ese reloj por dos bytes da 66,528 MB/s como tasa de cribado del consumo activo basada en el reloj de píxeles.
ST AN4861, Revisión 7, relaciona el reloj de píxeles con las dimensiones totales de temporización y el refresco, y presenta un cribado de ancho de banda basado en el reloj de píxeles y los bytes de almacenamiento por píxel de la capa. También analiza maestros de bus en competencia y distingue el agotamiento de FIFO de un error de transferencia.[1]
| Cantidad didáctica | RGB565, 2 bytes/píxel | ARGB8888, 4 bytes/píxel |
|---|---|---|
| Carga útil activa promediada durante el intervalo de frame | 46,08 MB/s | 92,16 MB/s |
| Tasa de cribado basada en el reloj de píxeles | 66,528 MB/s | 133,056 MB/s |
Esta tasa de cribado describe la cadencia de píxeles activos, no píxeles extra de RAM para los porches ni una tasa constante de RAM durante el blanking. Las lecturas almacenadas en búfer pueden ocurrir durante el blanking. No sumar esta tasa al promedio por frame.
Las lecturas reales de memoria pueden ser a ráfagas y almacenadas en búfer. Estos cálculos no describen el patrón exacto de recarga, la sobrecarga de transacciones ni el servicio de memoria garantizado. Ayudan a distinguir el volumen de carga útil del ritmo y las restricciones de temporización que lo suministran.
Añadir el tráfico del productor una vez, en la memoria que se evalúa
El lector de pantalla es solo un participante. El renderizado por CPU, la decodificación de imágenes, las operaciones DMA2D y las copias de búfer pueden crear lecturas y escrituras adicionales. Contarlas en un límite declarado: por ejemplo, la memoria externa que contiene tanto el origen como el destino de la copia.
Suponer que un frame RGB565 completo se copia 30 veces por segundo. Asumir que ambos lados usan esa memoria contabilizada y que cada carga útil cruza el límite una vez. Cada copia entonces lee 768.000 bytes y escribe otros 768.000 bytes:
(768.000 lectura + 768.000 escritura) x 30 = 46.080.000 bytes/sAñadir esa copia al scanout promedio por frame de una capa da 46,08 + 46,08 = 92,16 MB/s. Este es un subtotal ideal de carga útil. Excluye otro trabajo y costos de transacción; el almacenamiento en caché o la intermediación pueden cambiar el tráfico en el límite elegido. Contar cada lectura y escritura una vez; no añadir luego la misma copia bajo otra etiqueta como tráfico de flush.
| Carga de trabajo en la cuenta didáctica | Tráfico promedio en la memoria declarada |
|---|---|
| Un scanout RGB565 a 60 Hz | 46,08 MB/s de lectura |
| Copia de frame completo a 30 actualizaciones/s | 23,04 MB/s de lectura más 23,04 MB/s de escritura |
| Subtotal | 92,16 MB/s |
La ubicación cambia la cuenta. Si el origen de la copia reside en otro lugar, sus lecturas pueden no cruzar el mismo límite de memoria que las escrituras de destino. A la inversa, el renderizado que lee píxeles de destino antes de escribirlos añade tráfico más allá de un modelo simple de solo escritura. Definir la operación en lugar de asignar a cada actualización de GUI un costo genérico.
Los modos de renderizado de GUI cambian el lado del productor
LVGL 9.5 distingue el renderizado PARTIAL, DIRECT y FULL. PARTIAL usa búferes de dibujo más pequeños para áreas modificadas. DIRECT usa búferes del tamaño de pantalla completa; con dos búferes copia las áreas renderizadas al otro búfer después del flush. FULL redibuja toda la pantalla.[3]
Estas distinciones pertenecen a la cuenta de carga de trabajo. Un nombre de modo por sí solo no puede establecer el tráfico resultante en memoria externa. Rastrear dónde ocurre el renderizado, qué copia la operación de flush y qué asignaciones comparten la memoria bajo revisión.
El renderizado parcial no detiene el scanout continuo de LTDC. Actualizar un botón pequeño puede reducir el trabajo del productor mientras el controlador continúa leyendo el frame mostrado. Si una arquitectura en cambio usa memoria de imagen local a la pantalla u otro modelo de refresco, necesita una cuenta diferente de la usada aquí.
Asimismo, el doble búfer puede separar la propiedad del productor y del lector sin reducir los bytes consumidos por un refresco. También puede introducir copias de sincronización dependiendo del framework. Comparar las operaciones reales en lugar de asumir que un búfer extra es una optimización de ancho de banda.
El ancho de banda promedio no puede proteger contra toda brecha de servicio
Una FIFO mantiene una reserva finita. Incluso si la memoria entrega suficientes bytes durante un intervalo largo, un período sin servicio puede agotar esa reserva durante el consumo activo. Por esto un resultado de ancho de banda promedio no puede establecer inmunidad al desbordamiento.
Considerar un modelo deliberadamente idealizado: una FIFO de 256 bytes comienza llena, se vacía a una tasa constante de 96 MB/s y no recibe recarga durante cuatro microsegundos. Estos son parámetros ficticios para un ejemplo independiente, no una especificación de FIFO del STM32 ni valores derivados de la carga de trabajo RGB565 anterior.
Bytes demanded during the gap = 96,000,000 x 0.000004 = 384El intervalo requiere más datos de los que contiene la reserva total asumida. Un servicio más rápido posteriormente no puede suministrar píxeles cuyo plazo ya ha vencido. Por lo tanto, un rendimiento sostenido adecuado a largo plazo no puede compensar cada interrupción en el servicio. Este ejemplo demuestra una restricción de latencia; no prescribe un límite de planificación para ningún LTDC real.
Una evaluación real necesita la organización objetivo de la FIFO, la ocupación al inicio de un intervalo, el comportamiento de obtención y la temporización del servicio de memoria. Una FIFO que comienza parcialmente llena tiene menos reserva que este modelo. El rellenado durante el consumo cambia la trayectoria nuevamente. La aritmética sigue siendo útil solo cuando sus suposiciones permanecen visibles.
Investigar la contención con una carga de trabajo representativa
La tasa máxima de la interfaz no es lo mismo que la entrega útil sostenida al LTDC. La temporización de memoria del objetivo, el patrón de transacciones, el comportamiento de refresco, el arbitraje y los accesos competidores determinan el servicio que recibe. No inserte un porcentaje de eficiencia asumido y trate el resultado como un límite validado.
Construya un registro de carga de trabajo que separe el escaneo estático de la renderización añadida, la copia y otros usuarios de memoria. Luego ejercite combinaciones realistas, incluyendo transiciones que produzcan ráfagas de trabajo. Una pantalla estática silenciosa no puede representar un sistema que también decodifica imágenes y copia regiones actualizadas.
| Evidencia a registrar | Pregunta que aborda |
|---|---|
| Capas activas, formato y totales de temporización | ¿Qué consumo de pantalla está configurado? |
| Programación de copia y renderización con ubicaciones de memoria | ¿Qué transacciones del productor compiten en el mismo límite? |
| Registros de underrun y errores de transferencia documentados por el objetivo | ¿El fallo observado indica inanición u otra falla? |
| Carga de trabajo concurrente y duración de la observación | ¿En qué condiciones se obtuvo el resultado? |
Recopile los registros de estado o del controlador documentados por el objetivo sin asumir que cada dispositivo expone el mismo contador. Confirme que el monitoreo está habilitado y registra los eventos de interés. Siga su semántica de manejo documentada. Un período sin underrun registrado es evidencia útil para esas condiciones; no prueba la compatibilidad total del panel ni cubre cada carga de trabajo futura.
Los cambios posibles incluyen reducir copias innecesarias, reconsiderar las capas activas o revisar la ubicación en memoria y la planificación. Cada uno cambia una parte específica de la cuenta y debe verificarse en el objetivo. Los cambios de refresco deben permanecer dentro de la temporización soportada por el panel; no existe una reducción segura universal.
Mantener el ancho de banda separado de otras fallas de integración
El diseño de píxeles incorrecto y los datos obsoletos escritos por la CPU requieren su propia evidencia. Un cálculo de ancho de banda no puede probar la publicación correcta de caché ni la propiedad del búfer. A la inversa, corregir la visibilidad de memoria no puede garantizar que un sistema de memoria ocupado cumpla con los plazos de escaneo.
Utilice la Guía de reloj de píxel y temporización de LCD para contexto de temporización y la interfaces del módulo de pantalla LCD guía para contexto de interfaz. Mantenga la cuenta de tráfico vinculada a la ruta real de escaneo continuo.
Para revisión específica del proyecto, contacte a RJY Display con la hoja de datos y temporización del panel, MCU, topología de memoria y reloj, ancho de bus, capas y formatos, programación de renderización/copia, registros de fallos y carga de trabajo concurrente representativa. Esos detalles respaldan una discusión de integración con alcance definido; los números elaborados no establecen una placa compatible ni una corrección garantizada.
Referencias
- ST AN4861, Revisión 7: Creación de una aplicación gráfica con LTDC; discusión de capas en la misma nota de aplicación. Febrero de 2026.
- TouchGFX 4.27: Framebuffer, según lectura del 22 de octubre de 2026.
- LVGL 9.5: Configuración de pantalla y búferes de dibujo.
