Visão geral¶

Planeje a arquitetura gráfica¶

Este guia apresenta como criar interfaces gráficas responsivas em dispositivos SF32. O foco está nas decisões práticas que afetam produtos reais: escolha do display, estratégia de framebuffer, integração com LVGL, aceleração por hardware do ePicasso, posicionamento de memória e atualização do display.

Os dispositivos SF32 são voltados a produtos compactos de AIoT e wearables, nos quais a interface precisa ser fluida sem ultrapassar limites rigorosos de consumo de energia, memória e área de PCB. O fluxo gráfico separa o tratamento de recursos, a composição de pixels, a compressão opcional do framebuffer e a saída para o painel. Distinguir essas funções é essencial para escolher a otimização adequada.

Use esta página para tomar decisões de arquitetura de interface que são difíceis de reverter mais tarde: painel e interface, estratégia de framebuffer, profundidade de cor, transparência, localização dos recursos e política de atualização. Os artigos de gráficos relacionados detalham cada etapa.

Fluxo gráfico SF32¶

O caminho típico dos recursos até o display é:

Source images, fonts, and animations
        │
        ▼
GraphicsTool converts supported resources to eZip or eZip-A
        │
        ▼
Compressed assets in NOR Flash, PSRAM, NAND, or file storage
        │
        ▼
eZip hardware decoder expands an asset when required
        │
        ▼
LVGL or another UI framework + graphics/display driver
        │
        ├── CPU fallback rendering
        │
        └── ePicasso pixel acceleration
        │
        ▼
Final rendered bitmap in a draw buffer or framebuffer
        │
        ├── Uncompressed display path
        │
        └── Optional: extDMA compresses it into TurboPixel
                    │
                    ▼
             TurboPixel framebuffer in PSRAM
        │
        ▼
Display controller transfers pixels to the panel
        │
        ▼
SPI / QSPI / 8080 / RGB / MIPI DSI / EPD / JDI panel

Esse fluxo é configurável: um produto pode não usar eZip, ePicasso, TurboPixel ou um framebuffer completo. A disponibilidade e as conexões dependem do dispositivo escolhido, do SDK, da interface de display, do painel e da configuração do driver. O cabeçalho LCDC atual do OpenSiFli define LCDC_SUPPORTED_COMPRESSED_LAYER somente quando HAL_EXTDMA_MODULE_ENABLED está habilitado e a condição da família permite; SF32LB52x e SF32LB57x são excluídos. Um comentário no código também informa que o caminho LCPU não está habilitado. A tabela publicada de recursos LCDC do SDK marca a descompressão de camadas comprimidas como não suportada no SF32LB55x. Portanto, considere o SF32LB55x condicional, e não como uma implementação validada de ponta a ponta. Verifique a revisão exata do SDK, o núcleo, a configuração de build e o hardware-alvo; consulte TurboPixel.

O código da aplicação define o estado e o comportamento da interface. O framework gerencia widgets, regiões a redesenhar e desenho. O driver do subsistema gráfico seleciona o processamento por CPU ou ePicasso e coordena os buffers; o controlador de display cuida da transferência para o painel. Para detalhes de implementação, consulte ePicasso, eZip e TurboPixel.

Escolha primeiro o display¶

A escolha do display afeta quase todas as decisões gráficas. Antes de otimizar o código, defina claramente os requisitos do painel:

• Resolução.
• Profundidade de cor.
• Taxa de atualização.
• Tipo de interface.
• Requisitos do controlador de toque.
• Retroiluminação (backlight) ou linhas de alimentação do display.
• Suporte a atualização parcial.
• Presença de GRAM interno no painel.
• Necessidade de operação always-on de baixo consumo.

Um AMOLED pequeno com SPI ou QSPI se comporta de forma muito diferente de um painel RGB, MIPI DSI, JDI de memória ou EPD. O mesmo framework de interface pode atender a vários tipos de display, mas a estratégia de buffers e atualização precisa mudar conforme o painel.

Para escolher a interface, projetar o caminho de flush e fazer o bring-up do painel, consulte Controlador de display.

Comece por um exemplo LVGL validado¶

Antes de montar as telas, escolha um exemplo do SDK que já valide o limite gráfico de maior risco para o produto. O artigo Exemplos de LVGL do SDK organiza os exemplos oficiais de referência, ferramentas de design, widgets, recursos compactados, animação e mídia, bússola, jogos e interface de relógio pela tarefa de engenharia que cada um demonstra e indica quais premissas de placa, versão, display, memória e desempenho precisam ser revalidadas ao adaptar o exemplo ao produto.

Escolha o dispositivo SF32 adequado¶

Escolha o chip considerando o display e a carga gráfica, não apenas a frequência da CPU.

As restrições mais importantes são a interface e a resolução do display, a capacidade de memória, a geração do acelerador gráfico, os pinos disponíveis e o orçamento de energia.

Calcule framebuffer e largura de banda¶

Estime o custo de memória e transferência antes de escolher o painel ou o estilo de animação:

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

Exemplos:

As capacidades dos buffers são expressas em KiB (1.024 bytes), e a largura de banda, em MB/s decimais (1.000.000 bytes/s). Os valores consideram apenas os pixels brutos: não incluem overhead de comandos, alinhamento, manutenção de cache, leitura de recursos, blending nem outros fluxos de dados do sistema. Se o produto também executar áudio Bluetooth ou IA, ou acessar PSRAM externa, reserve margem adicional.

Entenda os buffers¶

No fim, uma interface gráfica é representada por pixels na memória. Os principais tipos de buffer são:

Um framebuffer de tela inteira é prático, mas pode consumir SRAM demais em painéis maiores. Um buffer RGB565 de 454 x 454 contém 412.232 bytes (cerca de 412 kB ou 403 KiB); dois buffers precisam do dobro dessa capacidade. Resoluções e profundidades de cor maiores aumentam rapidamente esse custo.

Quando a memória é limitada, use buffers de desenho parciais e atualize apenas as regiões alteradas. Se a animação for importante e houver memória suficiente, um framebuffer completo ou uma estratégia com dois buffers pode deixar a interface mais fluida.

Escolha a profundidade de cor com cuidado¶

A profundidade de cor afeta a qualidade visual, o uso de memória e a largura de banda do barramento.

Para a maioria dos wearables e HMIs compactas, RGB565 é um bom padrão inicial, a menos que o painel, a meta de qualidade visual ou os requisitos do produto exijam outro formato.

Transparência, alpha e composição de camadas¶

A transparência é representada pelo fator alpha, que indica quanto um pixel de primeiro plano contribui quando é desenhado sobre o fundo. Alpha é independente dos canais RGB. Um pixel opaco tem alpha 1 (ou 255 em um canal alpha de 8 bits); um pixel totalmente transparente tem alpha 0.

Na composição source-over sobre um fundo opaco, com cores do primeiro plano não pré-multiplicadas pelo alpha e alpha normalizado entre 0 e 1, cada canal RGB do resultado é calculado assim. Esta fórmula simplificada não calcula o alpha de saída de um destino transparente:

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

Por exemplo, um pixel de ícone com 50% de alpha contribui com metade da própria cor e deixa metade do fundo visível. Repetida em sequência, essa operação forma as camadas da interface: fundo, imagens, texto, controles translúcidos, sombras e animações. O bitmap composto segue então para as etapas de framebuffer e controlador de display mostradas acima.

RGB565 não tem canal alpha e, por isso, costuma ser usado em destinos de desenho opacos e framebuffers finais. Recursos de origem ou camadas intermediárias que precisam de transparência normalmente usam um formato com canal alpha, como ARGB8888, ou uma imagem colorida com uma máscara alpha separada. O driver deve usar formatos realmente suportados pelo SDK, pelo caminho de display e pelo acelerador escolhido.

Há duas representações comuns de alpha. Com alpha direto (straight alpha), o RGB descreve a cor original e o alpha é aplicado durante o blending. Com alpha pré-multiplicado (premultiplied alpha), o RGB já foi multiplicado pelo alpha; a equação source-over passa a ser output = premultiplied_foreground + background × (1 − alpha). Não misture as representações: interpretar dados com alpha direto como pré-multiplicados, ou o contrário, cria halos claros ou escuros nas bordas.

O blending alpha lê os pixels do primeiro plano e do destino e depois grava o resultado. Portanto, aumenta o tráfego de memória em relação a uma cópia ou preenchimento opaco simples. Use ePicasso quando o driver oferecer suporte à operação de blending e aos formatos escolhidos; caso contrário, mantenha um caminho de fallback em software. Limite camadas translúcidas em tela inteira, atualize apenas as regiões invalidadas e evite superfícies intermediárias desnecessárias quando a largura de banda da PSRAM ou o consumo de energia forem restrições.

Integre o LVGL¶

O LVGL é uma opção prática para interfaces em dispositivos SF32 porque oferece widgets, estilos, gerenciamento de entrada, animação, invalidação e pontos de integração com o driver de display.

Uma integração típica do LVGL precisa de:

• Um callback de flush do driver de display.
• Um ou mais buffers de desenho.
• Uma fonte de tick para o tempo do LVGL.
• Drivers de entrada para toque, botões, encoders ou gestos.
• Gerenciamento de recursos gráficos, como imagens e fontes.
• Hooks opcionais de aceleração por hardware para ePicasso.

O callback de flush do display marca o limite entre renderização e saída. O comportamento do controlador e do DMA é explicado em Controlador de display.

Decisões para portar o LVGL¶

Fixe estes detalhes de integração antes de aperfeiçoar as telas:

Uma boa integração do LVGL mantém o código das telas declarativo, enquanto o driver controla a transferência, a sincronização, a aceleração e o cache.

Use a aceleração ePicasso¶

O ePicasso é útil quando a interface executa operações que, de outro modo, exigiriam muitos cálculos repetidos por pixel. Alguns exemplos:

• Preenchimento de retângulos.
• Cópia e blit de imagens.
• Alpha blending.
• Redimensionamento de imagens.
• Rotação ou transformação das regiões de imagem compatíveis.
• Composição de camadas.
• Conversão de formato de pixel, quando suportada pelo driver.

Uma boa adaptação do LVGL acelera as operações frequentes e de alto volume, mas mantém caminhos alternativos pela CPU para os casos não suportados. Não presuma que todo efeito de estilo do LVGL ou widget será executado em hardware. Meça as telas que realmente importam para o produto.

Quando a aceleração mais ajuda¶

O ePicasso tende a trazer mais benefício quando:

• Grandes regiões precisam ser preenchidas, copiadas, mescladas, redimensionadas ou transformadas.
• A interface usa ícones transparentes, máscaras de texto, sombras, sobreposições ou transições animadas.
• Sem aceleração, a CPU gastaria uma parte significativa de cada quadro em loops de pixels.
• O posicionamento de memória e os formatos de pixel são adequados ao acelerador.

Quando a aceleração pode ajudar pouco¶

A aceleração por hardware pode trazer pouco benefício quando:

• A região atualizada é muito pequena.
• O gargalo é a largura de banda de transferência do painel, e não a renderização.
• Os recursos estão em formatos não suportados ou exigem conversão onerosa.
• Os buffers estão em memória lenta e sem largura de banda suficiente.
• O custo de manutenção de cache domina a operação.

Estratégia de posicionamento de memória¶

O desempenho gráfico costuma ser limitado pelo tráfego de memória. Posicione os buffers deliberadamente:

• Sempre que possível, mantenha os buffers de desenho mais usados na SRAM rápida.
• Use PSRAM para framebuffers grandes somente quando a SRAM não for suficiente.
• Armazene imagens e fontes grandes em Flash ou PSRAM, considerando a latência de acesso.
• Evite converter recursos repetidamente durante a execução.
• Alinhe os buffers acessados por DMA conforme as orientações do SDK.
• Use recursos compactados ou indexados quando isso reduzir o tráfego total e o custo de decodificação.

Quando a CPU e o hardware gráfico ou de display compartilharem buffers, siga as regras do SDK para cache e propriedade dos buffers. Antes de o hardware ler dados escritos pela CPU, execute clean nas linhas de cache correspondentes e conclua a sincronização necessária. Antes de o hardware gravar no buffer, prepare-o para impedir que linhas sujas do cache da CPU sejam gravadas posteriormente na memória e sobrescrevam o resultado. Aguarde o término da transferência e invalide as linhas desatualizadas antes de a CPU ler o resultado. Respeite o alinhamento das linhas de cache e os dados vizinhos; não altere um buffer enquanto ele estiver sob controle do hardware. Use as rotinas compatíveis do SDK: clean e invalidate não são intercambiáveis.

Para atualização parcial, comportamento específico do painel e sequência de bring-up, consulte Controlador de display.

Prepare os recursos gráficos¶

Uma boa preparação dos recursos pode acelerar a interface antes mesmo da otimização do código.

Regras práticas:

• Use imagens com as dimensões reais em que serão exibidas.
• Evite redimensionar imagens grandes a cada quadro.
• Quando possível, pré-renderize sombras, gradientes ou fundos complexos.
• Use alpha somente onde a transparência for necessária.
• Prefira conjuntos compartilhados de ícones e subconjuntos de fontes.
• Remova dos arquivos de fonte os glifos que não serão usados.
• Prefira formatos de recurso processados com eficiência pelo caminho gráfico.

Em produtos multilíngues, a memória das fontes pode consumir grande parte do orçamento da interface. Planeje cedo a seleção de fontes alternativas, os subconjuntos de glifos e a composição do texto.

Estratégia de animação¶

Animações fluidas dependem do orçamento por quadro, da largura de banda do painel, do custo de renderização e do consumo de energia.

Uma abordagem prática:

• Anime somente o que o usuário percebe.
• Mantenha pequenas as regiões animadas.
• Prefira transformações ou alterações de opacidade que aproveitem bem a aceleração.
• Evite blur, sombra ou transparência em tela inteira a cada quadro.
• Reduza a taxa de quadros de efeitos não críticos.
• Interrompa as animações quando a tela estiver escurecida, coberta ou inativa.

Uma interface vestível não precisa de animações como as de um desktop em todos os elementos. Poucas transições rápidas e claras costumam funcionar melhor do que muitos efeitos que consomem energia ou derrubam a taxa de quadros.

Matriz de validação gráfica¶

Use telas de teste reproduzíveis em vez de avaliar apenas se a interface parece “fluida o suficiente”:

Registre o tempo de renderização e de flush, a carga da CPU e o consumo de energia de cada tela. Medir apenas o tempo total do quadro dificulta identificar se o gargalo está no LVGL, ePicasso, memória ou interface do painel.

Diagnóstico do desempenho gráfico¶

Quando a interface ficar lenta, identifique o gargalo antes de alterar o projeto.

Meça separadamente:

• Tempo de renderização do LVGL.
• Tempo das operações ePicasso.
• Tempo de flush do display.
• Carga da CPU.
• Pressão sobre a largura de banda da memória.
• Consumo de energia nos estados ativo, ocioso e de suspensão.

Erros comuns¶

Evite estes erros: corrigi-los no fim do projeto costuma ser caro.

• Escolher a interface do painel sem estimar a largura de banda.
• Redesenhar a tela inteira para pequenas alterações na interface.
• Armazenar todos os recursos em memória lenta sem medir o desempenho.
• Usar RGB888 quando RGB565 atende aos requisitos.
• Redimensionar imagens grandes a cada quadro.
• Esquecer a manutenção de cache em buffers compartilhados com hardware.
• Presumir que ePicasso acelera automaticamente todas as operações da interface.
• Usar timers ou animações em excesso e manter a CPU ativa.
• Ignorar a latência do toque enquanto se otimiza apenas a taxa de quadros.
• Esperar o bring-up da PCB para validar a inicialização do painel.

Checklist de bring-up¶

Use este checklist ao iniciar um projeto gráfico com SF32:

• Confirme a resolução, a profundidade de cor, a interface e o circuito integrado controlador do painel.
• Confirme se o dispositivo SF32 escolhido suporta a interface de display necessária.
• Estime a memória exigida pelos framebuffers e buffers de desenho.
• Defina uma estratégia de buffer completo ou parcial, com buffer simples ou duplo.
• Faça o bring-up do reset do painel, das linhas de alimentação, da retroiluminação e da sequência de inicialização.
• Implemente o tick do LVGL, o flush do display e os drivers de entrada.
• Verifique preenchimentos, imagens, texto e toque.
• Habilite a aceleração ePicasso quando o SDK e o driver oferecerem suporte.
• Valide a limpeza/invalidação de cache para buffers compartilhados.
• Meça o tempo de renderização e flush, a carga da CPU e o consumo de energia.
• Teste telas de pior caso, animações, atividade Bluetooth e transições entre suspensão e retomada.

Principais conclusões¶

• Comece pelo tipo de interface do display, resolução, profundidade de cor e requisitos de atualização.
• Use LVGL ou um framework semelhante para gerenciar widgets, invalidação, desenho e entrada.
• Use ePicasso para acelerar operações de pixels compatíveis, mantendo caminhos de fallback em software.
• Otimize o posicionamento de memória e a estratégia de buffers com o mesmo cuidado dedicado ao código de renderização.
• Prefira atualização parcial em painéis limitados pela largura de banda e em telas vestíveis estáticas.
• Trate o desempenho gráfico como um problema de sistema: CPU, ePicasso, memória, controlador de display, interface do painel, toque e política de energia.

Última atualização: 2026-10-19