Resumen de gráficos¶

Planifique la arquitectura gráfica¶

Esta guía explica cómo crear interfaces gráficas ágiles en dispositivos SF32. Se centra en decisiones prácticas que afectan al producto: selección de pantalla, estrategia de framebuffer, integración de LVGL, aceleración por hardware ePicasso, distribución de memoria y actualización de la pantalla.

Los dispositivos SF32 están diseñados para productos compactos de AIoT y dispositivos vestibles, en los que la interfaz debe responder con fluidez sin superar los límites estrictos de consumo, memoria y área disponible en la PCB. El flujo gráfico separa la gestión de recursos, la composición de píxeles, la compresión opcional del framebuffer y la salida al panel. Entender la función de cada etapa ayuda a elegir la optimización adecuada.

Consulte esta página al tomar decisiones de arquitectura de UI que después resultan costosas de cambiar: panel e interfaz, estrategia de framebuffer, profundidad de color, transparencia, ubicación de recursos y política de actualización. Los artículos enlazados sobre gráficos explican cómo implementar cada etapa.

Flujo gráfico de SF32¶

La ruta típica de recursos de pantalla es:

Imágenes, fuentes y animaciones de origen
        │
        ▼
GraphicsTool convierte los recursos compatibles a eZip o eZip-A
        │
        ▼
Recursos comprimidos en Flash NOR, PSRAM, NAND o almacenamiento de archivos
        │
        ▼
El decodificador eZip por hardware descomprime un recurso cuando se necesita
        │
        ▼
LVGL u otro framework de UI + controlador gráfico/de pantalla
        │
        ├── Renderizado de respaldo por CPU
        │
        └── Aceleración de píxeles por ePicasso
        │
        ▼
Mapa de bits final renderizado en un búfer de dibujo o framebuffer
        │
        ├── Ruta de pantalla sin comprimir
        │
        └── Opcional: extDMA lo comprime en TurboPixel
                    │
                    ▼
             Framebuffer TurboPixel en PSRAM
        │
        ▼
El controlador de pantalla transfiere los píxeles al panel
        │
        ▼
Panel SPI / QSPI / 8080 / RGB / MIPI DSI / EPD / JDI

El flujo es configurable: un producto puede prescindir de eZip, ePicasso, TurboPixel o de un framebuffer completo. La disponibilidad y las conexiones dependen del dispositivo, el SDK, la interfaz de pantalla, el panel y la configuración del controlador. El encabezado LCDC actual de OpenSiFli define LCDC_SUPPORTED_COMPRESSED_LAYER solo cuando está habilitado HAL_EXTDMA_MODULE_ENABLED y se cumple la condición de compilación correspondiente a la familia; SF32LB52x y SF32LB57x quedan excluidos. Un comentario del código también indica que la ruta LCPU aún no está habilitada. La tabla publicada de funciones LCDC del SDK marca como no compatible la descompresión de capas comprimidas en SF32LB55x; por eso, en 55x debe considerarse una capacidad condicional, no una ruta de ejecución validada de extremo a extremo. Compruebe la revisión exacta del SDK, el núcleo, la configuración de compilación y el hardware objetivo; consulte TurboPixel.

El código de la aplicación define el estado y el comportamiento de la interfaz. El framework gestiona los widgets, las áreas que deben redibujarse y el dibujo. El controlador gráfico coordina los búferes y determina si las operaciones se ejecutan en la CPU o en ePicasso; el controlador de pantalla transfiere los datos al panel. Para conocer los detalles de cada función, consulte ePicasso, eZip y TurboPixel.

Elija primero la pantalla¶

La elección de pantalla afecta a casi todas las decisiones gráficas. Antes de optimizar el código, defina claramente los requisitos del panel:

• Resolución.
• Profundidad de color.
• Tasa de refresco.
• Tipo de interfaz.
• Requisitos del controlador táctil.
• Alimentación de la retroiluminación o del panel.
• Compatibilidad con refresco parcial.
• Si el panel tiene GRAM interna.
• Si se necesita una pantalla de bajo consumo que permanezca siempre encendida.

Una pantalla AMOLED pequeña con interfaz SPI o QSPI se comporta de forma muy distinta de los paneles RGB, MIPI DSI y EPD, así como de las pantallas JDI con memoria. Un mismo framework de UI puede funcionar con distintos tipos de pantalla, pero la estrategia de búfer y la política de actualización adecuadas variarán.

Para elegir la interfaz, diseñar la ruta de flush y poner en marcha el panel, consulte Controlador de pantalla.

Empiece con un ejemplo de LVGL verificado¶

Antes de diseñar las pantallas, elija un ejemplo del SDK que ya valide el aspecto gráfico de mayor riesgo del producto. Ejemplos de LVGL del SDK agrupa los ejemplos oficiales —base, herramienta de diseño, widgets, recursos comprimidos, animación y multimedia, brújula, juegos e interfaz de reloj— según la tarea de ingeniería que resuelven. También señala qué supuestos sobre la placa, la versión, la pantalla, la memoria y el rendimiento hay que volver a validar al adaptar el ejemplo al producto.

Elija el dispositivo SF32 adecuado¶

Elija el chip según la carga de trabajo de pantalla y UI, no solo la frecuencia de la CPU.

Las restricciones más importantes son la interfaz de pantalla, la resolución, la capacidad de memoria, la generación del acelerador gráfico, los pines disponibles y el presupuesto de energía.

Cálculo de framebuffer y ancho de banda¶

Estime el costo de memoria y transferencia antes de elegir un panel o un estilo de animación:

framebuffer bytes = width x height x bytes_per_pixel
raw full-frame bandwidth = framebuffer bytes x frames_per_second

Ejemplos:

El tamaño de los búferes se expresa en KiB (1.024 bytes) y el ancho de banda, en MB/s decimales (1.000.000 bytes/s). Son cifras de datos de píxeles sin procesar: no incluyen la sobrecarga de comandos, la alineación, el mantenimiento de caché, la lectura de recursos, la composición ni otros flujos de datos del sistema. Si el producto también maneja audio Bluetooth, ejecuta cargas de IA o accede a PSRAM externa, reserve margen adicional.

Entienda los búferes¶

Al final, una interfaz gráfica se representa mediante píxeles en memoria. Estos son los principales tipos de búfer:

Un framebuffer de pantalla completa es cómodo, pero en paneles grandes puede consumir demasiada SRAM. Un búfer RGB565 de 454 × 454 contiene 412.232 bytes (unos 412 kB o 403 KiB); dos búferes requieren el doble de capacidad. La memoria necesaria aumenta rápidamente con la profundidad de color y la resolución.

Si la memoria es limitada, use búferes parciales y actualice solo las zonas modificadas. Si la animación es importante y hay memoria suficiente, un framebuffer completo o el doble búfer pueden dar más fluidez a la interfaz.

Elija bien la profundidad de color¶

La profundidad de color afecta a la calidad de imagen, el uso de memoria y el ancho de banda del bus.

En la mayoría de los dispositivos vestibles y las HMI compactas, RGB565 es una buena opción inicial, salvo que el panel, la calidad de imagen deseada o los requisitos del producto exijan más.

Transparencia, alfa y composición de capas¶

La transparencia se representa mediante un factor alfa, que indica cuánto contribuye el píxel en primer plano al dibujarse sobre el fondo. El alfa es independiente de los canales de color RGB. Un píxel opaco tiene un alfa de 1 (o 255 en un canal alfa de 8 bits); uno totalmente transparente tiene un alfa de 0.

En la composición source-over sobre un fondo opaco, con colores de primer plano sin premultiplicar por alfa y alfa normalizado entre 0 y 1, cada canal RGB de salida se calcula así. Esta fórmula simplificada no calcula el alfa de salida de un destino transparente:

output = foreground × alpha + background × (1 − alpha)

Por ejemplo, un píxel de un icono con un alfa del 50 % aporta la mitad de su color y deja ver la mitad del fondo. Al repetir esta operación se compone la interfaz por capas: fondo, imágenes, texto, controles translúcidos, sombras y animaciones. El mapa de bits resultante pasa después por las etapas de framebuffer y controlador de pantalla descritas arriba.

RGB565 no tiene canal alfa, por lo que suele usarse para superficies de dibujo opacas y framebuffers finales. Los recursos de origen o las capas intermedias que requieren transparencia suelen usar un formato con canal alfa, como ARGB8888, o una imagen en color acompañada de una máscara alfa independiente. El controlador debe usar formatos compatibles con el SDK, la ruta de pantalla y el acelerador elegido.

Hay dos representaciones habituales del alfa. En alfa directo (straight alpha), RGB contiene el color original y el alfa se aplica durante la composición. En alfa premultiplicado, los valores RGB ya se han multiplicado por el alfa y la ecuación "source-over" queda así: output = premultiplied_foreground + background × (1 − alpha). No mezcle ambas representaciones: interpretar datos de alfa directo como premultiplicados o viceversa produce halos claros u oscuros en los bordes.

La composición alfa lee los píxeles del primer plano y del destino y escribe el resultado, por lo que genera más tráfico de memoria que una copia o un relleno opacos. Use ePicasso si el controlador admite la operación de composición y los formatos de píxel elegidos; de lo contrario, mantenga una alternativa por CPU. Si el ancho de banda de PSRAM o el presupuesto de consumo energético son limitados, limite las capas translúcidas de pantalla completa, actualice solo las zonas que hayan cambiado y evite superficies intermedias innecesarias.

Integración de LVGL¶

LVGL es un framework práctico para las interfaces de dispositivos SF32: ofrece widgets, estilos, gestión de entradas, animaciones, control de las zonas que deben redibujarse e interfaces para los controladores de pantalla.

Una integración típica de LVGL necesita:

• Una función de callback flush del controlador de pantalla.
• Uno o más búferes de dibujo.
• Una fuente de tick para la temporización de LVGL.
• Controladores de entrada para pantalla táctil, botones, encoders o gestos.
• Gestión de recursos gráficos, como imágenes y fuentes.
• Ganchos opcionales de aceleración por hardware para ePicasso.

El callback flush marca el límite entre el renderizado y la salida a pantalla. El funcionamiento del controlador y del DMA se explica en Controlador de pantalla.

Decisiones para portar LVGL¶

Fije estos detalles de integración de LVGL antes de pulir las pantallas:

Una buena integración de LVGL permite que el código de las pantallas describa la interfaz, mientras el controlador se ocupa de las transferencias, la sincronización, la aceleración y la caché.

Uso de la aceleración ePicasso¶

ePicasso resulta útil cuando la interfaz necesita realizar repetidamente muchas operaciones sobre píxeles. Entre los casos habituales están:

• Rellenos de rectángulo.
• Copia y blit de imágenes.
• Mezcla alfa.
• Escalado de imagen.
• Rotación o transformación de zonas de imagen compatibles.
• Composición de capas.
• Conversión de formato de píxel cuando sea compatible con el controlador.

Una buena integración acelera las operaciones frecuentes y de gran volumen, pero conserva alternativas por CPU para los casos no compatibles. No dé por hecho que todos los estilos y widgets de LVGL se ejecutan en el hardware. Mida las pantallas que realmente se usarán en el producto.

Cuándo resulta más útil la aceleración¶

ePicasso generalmente ayuda más cuando:

• Se rellenan, copian, mezclan, escalan o transforman regiones grandes.
• La UI usa iconos transparentes, máscaras de texto, sombras, superposiciones o transiciones animadas.
• Sin aceleración, la CPU dedicaría gran parte del tiempo de cada fotograma a procesar píxeles en bucles.
• La ubicación de memoria y los formatos de píxel coinciden con lo que el acelerador puede manejar eficientemente.

Cuándo puede aportar poco la aceleración¶

La aceleración por hardware puede proporcionar un beneficio limitado cuando:

• La región actualizada es muy pequeña.
• El cuello de botella es el ancho de banda de transferencia al panel, no el renderizado.
• Los recursos usan formatos no compatibles o requieren conversiones costosas.
• Los búferes se colocan en memoria lenta sin suficiente ancho de banda.
• La sobrecarga de mantenimiento de caché domina la operación.

Estrategia de distribución de memoria¶

El rendimiento gráfico suele estar limitado por el movimiento de datos. Distribuya los búferes según su uso:

• Si es posible, coloque en SRAM rápida los búferes de dibujo de acceso frecuente.
• Mantenga los framebuffers grandes en PSRAM solo cuando la SRAM sea insuficiente.
• Almacene imágenes y fuentes grandes en Flash o PSRAM, teniendo en cuenta la latencia de acceso.
• Evite convertir recursos repetidamente durante la ejecución.
• Mantenga los búferes accedidos por DMA alineados según la guía del SDK.
• Use recursos comprimidos o indexados si reducen el ancho de banda total y el costo de decodificación.

Cuando la CPU y el hardware gráfico o de pantalla compartan búferes, siga las reglas del SDK sobre caché y propiedad de los búferes. Antes de que el hardware lea datos escritos por la CPU, ejecute clean sobre las líneas de caché correspondientes y complete la sincronización necesaria. Antes de que el hardware escriba en un búfer, prepárelo para que ninguna línea sucia de la CPU pueda sobrescribir después el resultado. Espere a que termine la transferencia e invalide las líneas obsoletas antes de que la CPU lea el resultado. Respete la alineación de las líneas de caché y los datos vecinos; no modifique un búfer mientras lo controle el hardware. Use las rutinas admitidas por el SDK: clean e invalidate no son intercambiables.

Para el refresco parcial, el comportamiento específico de cada panel y la secuencia de puesta en marcha por etapas, consulte Controlador de pantalla.

Preparación de recursos gráficos¶

Una buena preparación de los recursos puede agilizar la interfaz antes de optimizar el código.

Siga estas pautas:

• Haga coincidir las dimensiones de la imagen con el tamaño real en pantalla.
• Evite escalar imágenes grandes en cada cuadro.
• Prerrenderice sombras complejas, gradientes o fondos cuando sea posible.
• Use alfa solo donde se necesite transparencia.
• Prefiera conjuntos de iconos compartidos y subconjuntos de fuentes.
• Elimine los glifos no usados de las fuentes.
• Guarde los recursos de uso frecuente en formatos que la ruta gráfica procese de forma eficiente.

En productos multilingües, las fuentes pueden ocupar gran parte de la memoria disponible para la interfaz. Planifique desde el principio la sustitución de fuentes, los subconjuntos de glifos y la composición del texto.

Estrategia de animación¶

La fluidez de la animación depende del tiempo disponible por fotograma, el ancho de banda del panel, el costo de renderizado y el consumo energético.

Un enfoque práctico:

• Anime solo lo que los usuarios notan.
• Mantenga pequeñas las regiones animadas.
• Prefiera transformaciones o cambios de opacidad que se adapten bien a la aceleración.
• Evite efectos costosos de desenfoque, sombra o transparencia de pantalla completa en cada cuadro.
• Reduzca la frecuencia de fotogramas para efectos no críticos.
• Detenga las animaciones cuando la pantalla esté atenuada, cubierta o inactiva.

La interfaz de un dispositivo vestible no necesita animaciones al estilo de escritorio en todas partes. Unas pocas transiciones breves y claras suelen ofrecer una mejor experiencia que muchos efectos que consumen energía o provocan caídas de fotogramas.

Matriz de validación gráfica¶

Use pantallas de prueba reproducibles en lugar de confiar en una valoración subjetiva de si algo se ve «lo bastante fluido»:

Registre para cada pantalla el tiempo de renderizado, el tiempo de flush, la carga de CPU y el consumo energético. Si solo mide el tiempo total del fotograma, será difícil determinar si el cuello de botella está en LVGL, ePicasso, la memoria o la interfaz del panel.

Diagnóstico del rendimiento gráfico¶

Cuando la UI es lenta, identifique el cuello de botella antes de cambiar el diseño.

Mida por separado:

• Tiempo de renderizado de LVGL.
• Tiempo de operación de ePicasso.
• Tiempo de flush de pantalla.
• Carga de CPU.
• Presión de ancho de banda de memoria.
• Consumo de energía durante los estados activo, inactivo y de suspensión.

Errores comunes¶

Evite estos desde el principio; son costosos de corregir tarde:

• Elegir una interfaz de panel antes de estimar el ancho de banda.
• Usar redibujados de pantalla completa para pequeños cambios de UI.
• Almacenar todos los recursos gráficos en memoria lenta sin medir el rendimiento.
• Usar RGB888 cuando RGB565 es suficiente.
• Escalar imágenes grandes en cada cuadro.
• Olvidar el mantenimiento de caché para búferes compartidos con hardware.
• Asumir que ePicasso acelera automáticamente cada operación de UI.
• Usar demasiados temporizadores o animaciones que mantienen la CPU despierta.
• Ignorar la latencia táctil mientras se optimiza solo la frecuencia de fotogramas.
• Esperar hasta la puesta en marcha de la PCB para validar la inicialización del panel.

Lista de comprobación para la puesta en marcha¶

Para iniciar un nuevo proyecto gráfico con SF32, siga esta lista:

• Confirme la resolución, la profundidad de color, la interfaz de pantalla y el circuito integrado controlador del panel.
• Confirme que el dispositivo SF32 seleccionado soporta la interfaz de pantalla requerida.
• Estime los requisitos de memoria de framebuffer y búfer de dibujo.
• Decida si usará un framebuffer completo o parcial y uno o dos búferes.
• Verifique el reinicio del panel, las líneas de alimentación, la retroiluminación y la secuencia de inicialización.
• Implemente el tick de LVGL, el callback flush de pantalla y los controladores de entrada.
• Verifique el comportamiento básico de relleno, imagen, texto y táctil.
• Habilite la aceleración de ePicasso cuando sea compatible con el SDK y el controlador.
• Valide la limpieza e invalidación de caché de los búferes compartidos.
• Mida el tiempo de renderizado y de flush, la carga de CPU y el consumo energético.
• Pruebe las pantallas del peor caso, las animaciones, la actividad Bluetooth y las rutas de suspensión/activación.

Ideas clave¶

• Comience el diseño gráfico a partir de la interfaz de pantalla, la resolución, la profundidad de color y los requisitos de refresco.
• Use LVGL o un framework similar para gestionar widgets, zonas por redibujar, dibujo y entradas.
• Use ePicasso para acelerar operaciones de píxeles comunes, pero mantenga rutas de respaldo de CPU.
• Optimice la ubicación de memoria y la estrategia de búfer con tanto cuidado como el código de renderizado.
• Prefiera el refresco parcial para paneles limitados en ancho de banda y pantallas estáticas de dispositivos portátiles.
• Considere el rendimiento de la interfaz como un problema de sistema que abarca la CPU, ePicasso, la memoria, el controlador de pantalla, la interfaz del panel, la pantalla táctil y la gestión energética.

Última actualización: 2026-10-12