Controlador de display¶

Visão geral¶

O controlador de display (LCDC) envia os pixels já preparados ao painel pela interface selecionada. Nos dispositivos e nas configurações compatíveis, também descompacta o framebuffer TurboPixel durante a saída. O LCDC permite uma mesclagem alfa limitada das camadas de saída sobre um fundo monocromático. A documentação descreve as camadas 0 e 1, mas o SF32LB52x não oferece a camada 1. Esse recurso não substitui a renderização geral da UI nem a composição com ePicasso. A decodificação de recursos eZip continua sendo uma operação separada.

Referência primária: documentação LCDC HAL da SiFli.

O link acima está fixado em um commit específico do SiFli-SDK. Ele documenta o comportamento do HAL naquela revisão, mas não comprova que todas as interfaces, camadas ou funções estejam disponíveis em todos os dispositivos e encapsulamentos SF32 ou em outras versões do SDK. Confirme a combinação exata de dispositivo, encapsulamento e versão do SDK usada no projeto.

Consulte a Visão geral de gráficos para ver o fluxo completo dos recursos até o painel. Este artigo se concentra no controlador, na conexão com o painel e na integração do driver.

Consulte esta página ao escolher a interface do painel, definir o caminho de flush do LVGL ou inicializar um painel novo no hardware. Ela separa o trabalho de saída do controlador da decodificação de recursos e da composição de pixels, ajudando a localizar problemas na camada correta.

Escolha a interface de display¶

EPD e Memory-in-Pixel descrevem tecnologias de painel ou formas de atualizar pixels, não barramentos intercambiáveis. Um módulo EPD pode usar SPI para se conectar a um controlador externo; o modo de acionamento direto de EPD pelo LCDC também está documentado para o SF32LB57x. JDI oferece modos de interface serial e paralela com sinais diferentes. Confira a interface elétrica e os requisitos de manutenção do painel, não apenas sua categoria.

A escolha do painel afeta a largura de banda, a estratégia de buffers, o uso de pinos, o consumo de energia, a complexidade de inicialização e os riscos para a PCB. Confirme a lista exata de interfaces compatíveis com o dispositivo e o encapsulamento escolhidos.

Por exemplo, um painel SPI/QSPI pequeno pode favorecer atualizações parciais, enquanto um painel RGB/DPI exige um orçamento de largura de banda para a leitura contínua do display (scanout). Não escolha a interface apenas pela vazão teórica: considere o formato de pixel, a resolução, o comportamento de atualização, a GRAM do painel e os demais usuários de PSRAM.

Matriz de interfaces por dispositivo¶

A matriz abaixo auxilia na escolha da família; não é uma tabela de atribuição de pinos. Ela resume as interfaces de display documentadas para cada família SF32 ou variante de silício indicada. Um traço significa que a interface não está documentada para aquela linha; isso não exclui um controlador externo acionado por GPIO nem uma implementação específica da placa. Antes de fechar o esquemático, confirme o código exato do dispositivo, o encapsulamento, a multiplexação dos pinos, a versão do SDK e o driver do painel.

No SF32LB56x, não trate as variantes U e V como intercambiáveis. Para SF32LB55x e SF32LB58x, só reserve MIPI DSI no esquemático depois de confirmar o encapsulamento exato, os pinos DSI disponíveis e os requisitos de vias de dados e modo do painel. Em particular, o SF32LB55x só oferece modo comando; portanto, não é compatível com um painel sem RAM em modo vídeo. Projetos EPD também exigem planejamento específico para a temporização, a forma de onda e a alimentação do painel; conhecer apenas a interface não basta para concluir o projeto.

O guia de modelos de chips da SiFli lista DPI/RGB entre as interfaces da família SF32LB55x, mas sua tabela por número de peça comercial não atribui DPI aos SKUs listados. Considere isso apenas uma indicação no nível da família; antes de depender de DPI, confirme o suporte e a disponibilidade dos pinos no código exato. A distinção U/V do SF32LB56x segue os guias de hardware separados, e não a tabela HAL comum à família.

Os dois guias de hardware do SF32LB52x divergem quanto ao JDI: o resumo cita JDI serial, enquanto as seções detalhadas mostram mapeamentos de sinais paralelos. Por isso, a matriz mantém as duas informações documentadas, sem garantir a disponibilidade dos pinos em um código específico. Antes de fechar o projeto, confirme o mapeamento LCDC, o SDK/driver e os sinais do painel para a variante exata.

No SF32LB52x, diferencie a interface de sinais EPD paralela de 8 bits documentada do modo de acionamento direto de EPD pelo LCDC. O guia de hardware do 52B/D/E/G/J lista os sinais EPD paralelos e o controle do PMIC TPS; separadamente, as notas de versão do SiFli-SDK v2.5.1 documentam o acionamento direto de EPD pelo LCDC no SF32LB57x. Não presuma que um projeto 52x possa usar o modo de acionamento direto de EPD pelo LCDC do 57x; confirme o driver e a implementação de temporização para a variante exata.

Fontes das interfaces: guia de seleção de chips SiFli, guia de hardware SF32LB52x com bateria, guia de hardware 52B/D/E/G/J, SF32LB55x, SF32LB56xU, SF32LB56xV, SF32LB58x e notas de suporte do SF32LB57x no SDK.

Controlador, buffers e caminhos de flush¶

O diagrama de referência do LCDC diferencia a área visível do painel, a janela de atualização e a região do buffer de origem. Aplique os offsets de coluna e linha de forma consistente. A janela de atualização pode se sobrepor apenas parcialmente à região do buffer de origem; os pixels da janela sem dados de origem exibem a cor de fundo. Confira em conjunto as coordenadas, a origem do buffer e o stride, sem presumir que o buffer e a janela são iguais.

O framework de UI produz os pixels alterados; o driver e o controlador de display os enviam ao painel. O caminho adequado depende do painel:

• Um driver SPI/QSPI ou 8080 normalmente define uma janela do painel e transfere apenas a região alterada.
• Um controlador que faz a varredura do framebuffer lê os pixels da memória conforme a temporização do display.
• Um caminho compatível com TurboPixel lê o bitmap final compactado e o descompacta na etapa do controlador de display.

Em um projeto com LVGL, o callback de flush do display marca o limite entre a renderização e a saída. Ele deve considerar a região a atualizar, iniciar a operação correta de DMA ou do controlador e sinalizar a conclusão somente quando o framework puder reutilizar o buffer de desenho com segurança. Defina explicitamente as operações de limpeza (clean) e invalidação (invalidate) de cache sempre que CPU e hardware compartilharem buffers.

A propriedade do buffer deve seguir o caminho real de transferência. Ao transferir para a memória do painel, libere o buffer de desenho somente depois que o hardware terminar de lê-lo. Na varredura contínua, uma interrupção de quadro não basta para liberar o framebuffer ativo: espere a confirmação da troca de buffers, quando o controlador deixar de ler o buffer anterior. O fim da transferência e a atualização visível são eventos diferentes; use o sinal TE ou a temporização de quadro do painel quando necessário para evitar tearing.

Se a memória compartilhada usar cache, limpe o cache dos dados de origem escritos pela CPU antes da leitura pelo hardware. Antes de uma escrita pelo hardware, prepare o destino conforme as regras de manutenção de cache da plataforma, para impedir que linhas modificadas sejam gravadas depois e sobrescrevam o resultado. Após a conclusão da operação de hardware, invalide o destino antes da leitura pela CPU. Respeite o alinhamento e a propriedade das linhas de cache, inclusive para dados vizinhos que compartilhem uma mesma linha.

Atualização parcial e regiões alteradas¶

A renderização parcial e a transferência parcial ao painel são otimizações diferentes. Um fluxo contínuo RGB/DPI ou DSI em modo vídeo pode continuar enviando o quadro inteiro mesmo quando apenas uma pequena região da memória muda. Para EPD, confira as formas de onda aceitas, a dependência da temperatura, as imagens residuais e os intervalos de atualização completa. Não presuma que uma região de atualização menor seja sempre válida.

A maioria das UIs embarcadas não precisa redesenhar a tela inteira a cada quadro. O LVGL acompanha as regiões invalidadas, e o driver pode atualizar apenas as áreas alteradas. Isso é especialmente útil com painéis SPI/QSPI, dispositivos vestíveis alimentados por bateria, páginas estáticas com poucos valores que mudam e displays EPD e JDI.

A atualização da tela inteira é adequada para telas com muitas animações, transições ou painéis que naturalmente fazem a varredura a partir de um framebuffer completo. A escolha depende da largura de banda da interface de display, do comportamento do painel e do orçamento de memória, não apenas da configuração do framework de UI.

Sequência de bring-up do painel¶

Faça o bring-up do painel por etapas antes de depurar widgets ou o comportamento da aplicação:

1. Verifique as linhas de alimentação, a temporização do reset, os pinos de retroiluminação e habilitação e o consumo básico de corrente.
2. Envie a sequência de inicialização do fabricante do painel exatamente como foi fornecida.
3. Exiba cores sólidas para identificar problemas de ordem de bytes, formato de pixel ou cabeamento da interface.
4. Desenhe padrões geométricos simples para verificar stride, endereçamento de janela e coordenadas.
5. Adicione imagens e texto para verificar a conversão de cor, as fontes e a alocação dos recursos.
6. Habilite atualização parcial, DMA, TurboPixel e aceleração gráfica, um recurso por vez.
7. Teste os caminhos de suspensão, display desligado, retomada e reinicialização.

Primeiro valide cores sólidas e padrões com uma configuração mínima da interface prevista. Depois de adicionar DMA, compactação ou aceleração, repita os testes em cada caminho novo antes de testar a UI completa do LVGL.

Isole falhas no caminho de display¶

Trate cada etapa como um limite independente. Isso evita alterar ao mesmo tempo os comandos do painel, o código LVGL, a alocação dos buffers e as configurações de DMA, o que torna uma falha de display mais difícil de reproduzir.

Orientações específicas por painel¶

AMOLED/TFT SPI e QSPI¶

Priorize atualizações parciais, use RGB565 quando adequado e mantenha pequenas as regiões animadas. Evite redesenhar a tela inteira para pequenas alterações; renderize e componha os pixels antes de atualizar a região alterada.

Painéis RGB / DPI¶

Dimensione a largura de banda contínua de scanout considerando também o tráfego da CPU, do ePicasso, do DMA e dos demais acessos à memória. Escolha uma estratégia de framebuffer compatível com a taxa de atualização necessária, considere buffers duplos quando houver memória suficiente e leve em conta a temporização e a integridade de sinal no projeto da PCB.

Painéis MIPI DSI¶

Escolha o modo do painel antes de fechar a seleção do componente. O SF32LB55x oferece somente o modo comando MIPI DSI, portanto o controlador do painel precisa ter SRAM/GRAM interna para armazenar a imagem atualizada. O SF32LB58x oferece os modos comando e vídeo: painéis em modo comando precisam de RAM no controlador, enquanto o modo vídeo pode acionar um controlador sem RAM pelo fluxo contínuo de pixels. Valide a inicialização desde o início, teste os estados de baixo consumo e o tempo de retomada e mantenha a taxa de dados necessária abaixo da vazão útil da interface, com margem para a sobrecarga do protocolo, as restrições de temporização e os demais acessos à memória.

Displays EPD¶

Projete para atualizações pouco frequentes; use modos de atualização parcial apenas quando forem compatíveis e visualmente aceitáveis. Não presuma que haverá animações e planeje os requisitos do PMIC do display, do VCOM e da forma de onda.

Interfaces JDI e painéis Memory-in-Pixel¶

Neste artigo, JDI refere-se aos modos de interface serial ou paralela do painel; Memory-in-Pixel é uma tecnologia de painel. Eles podem aparecer juntos em alguns projetos de baixo consumo, mas não são termos intercambiáveis. Em um painel MIP, pequenas regiões de atualização e um layout de UI adequado podem aproveitar a retenção do estado dos pixels enquanto o painel está alimentado. Isso não significa armazenamento não volátil da imagem nem consumo zero do sistema em espera. Siga o datasheet do painel para inversão COM e outras operações de manutenção; depois meça a atualização, a legibilidade ao ar livre e o consumo nas condições do produto.

Checklist de transição para a produção¶

Antes de considerar completo o caminho de display, registre as escolhas que outro engenheiro deverá conseguir reproduzir:

• Dispositivo SF32 e encapsulamento exatos, versão do SDK, revisão da placa, código do painel e revisão do controlador do painel.
• Modo de interface, atribuição de pinos, formato de pixel, ordem de bytes/cores, comportamento de atualização desejado e origem da sequência de inicialização do painel.
• Localização, tamanho e alinhamento do buffer de desenho e do framebuffer, responsável pela manutenção de cache e sinal de conclusão do DMA/controlador.
• Política de atualização parcial, regras das janelas do painel e quaisquer regiões que precisem ser atualizadas em conjunto para evitar artefatos.
• Tempo de renderização e de transferência medidos, tráfego de PSRAM de pico/médio quando relevante e corrente para estados representativos da UI.
• Resultados dos testes de suspensão, display desligado, retomada e recuperação, incluindo o comportamento após uma transferência com falha ou interrompida.

Esse registro transforma um resultado pontual de bring-up do display em uma integração de produto reproduzível. Valide-o novamente sempre que houver mudança no painel, SDK, organização da memória, formato de pixel ou driver de display.

Principais conclusões¶

• O controlador de display é responsável pela saída para o painel; ele é independente da composição de pixels do ePicasso e da descompactação de recursos do eZip.
• A escolha da interface determina grande parte da largura de banda, da estratégia de buffers, do consumo, do uso de pinos e do projeto da PCB.
• Trate o caminho de flush, a sincronização, a manutenção de cache e a inicialização do painel como tarefas centrais do firmware.
• Valide o painel com padrões simples antes de habilitar UI de nível superior, DMA, TurboPixel ou recursos de aceleração.
• Diagnostique falhas verificando um limite do caminho de display por vez e preserve a configuração e as medições validadas para a transição para a produção.

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