Largura de banda do framebuffer do STM32 LTDC: Tráfego e underrun de FIFO

Um framebuffer pode caber na RAM enquanto um display STM32 LTDC ainda fica sem dados de pixel. Capacidade responde quantos bytes podem ser armazenados. Largura de banda descreve o tráfego recorrente. Underrun de FIFO diz respeito a se o controlador recebe dados antes que sua reserva atual se esvazie. Um projeto deve abordar os três.

Esta análise cobre varredura contínua a partir de um framebuffer linear e não comprimido. Seus números são premissas didáticas, não timings de painel ou garantias de desempenho do STM32. O objetivo é construir uma conta de tráfego e uma investigação de latência de serviço antes de decidir que uma interface de memória é adequada.

Comece pela capacidade, depois coloque o tempo no cálculo

Assuma uma imagem ativa de 800 x 480 armazenada em RGB565 a dois bytes por pixel. Um frame com alocação justa requer 800 x 480 x 2 = 768.000 bytes. Dois framebuffers desse tipo requerem 1.536.000 bytes. Qualquer alocação real também deve satisfazer seus requisitos de layout e de memória.

Esses números estabelecem armazenamento, não uma taxa de transferência. O mesmo frame armazenado pode ser lido repetidamente sem alteração. Por outro lado, renderizar um frame de substituição adiciona tráfego mesmo antes de o mecanismo de display lê-lo.

O TouchGFX 4.27 descreve o custo de armazenamento e o ciclo de vida do double buffering: um buffer pode fornecer leitura contínua para o display enquanto outro é renderizado, com uma troca controlada.^[2] Dois buffers alocados não significam que o LTDC lê duas imagens completas a cada refresh.

Buffers armazenam imagens; camadas são entradas de composição configuradas. Múltiplas camadas ativas podem exigir leituras separadas. O double buffering de uma camada altera as localizações sucessivas dos frames, não o número de camadas lidas em conjunto.

Distinguir tráfego médio por frame do consumo ativo

Mantenha a imagem didática em 800 x 480 e assuma um refresh de 60 Hz. O payload útil de pixels ativos lido ao longo de um segundo inteiro é:

800 x 480 x 60 x 2 = 46.080.000 bytes/s

Isso é 46,08 MB/s usando megabytes decimais. É uma média ao longo do intervalo de frame, não uma garantia de que a memória possa atrasar o serviço arbitrariamente dentro desse intervalo.

Agora assuma dimensões totais de timing de 1056 x 525, incluindo blanking. O pixel clock correspondente é 1056 x 525 x 60 = 33,264 MHz. Multiplicar esse clock por dois bytes dá 66,528 MB/s como uma taxa de triagem de consumo ativo baseada no pixel clock.

O ST AN4861, Revisão 7, relaciona o pixel clock às dimensões totais de timing e ao refresh, e apresenta uma triagem de largura de banda baseada no pixel clock e nos bytes de armazenamento por pixel da camada. Também discute mestres de barramento concorrentes e distingue starvation de FIFO de um erro de transferência.^[1]

Essa taxa de triagem descreve a cadência de pixels ativos, não pixels extras de RAM para porches ou uma taxa de RAM constante durante o blanking. Buscas em buffer podem ocorrer durante o blanking. Não some essa taxa à média por frame.

Buscas reais na memória podem ser em rajadas e com buffer. Esses cálculos não descrevem o padrão exato de recarga, a sobrecarga de transações ou o serviço de memória garantido. Eles ajudam a distinguir o volume de payload útil da taxa e das restrições de timing que o fornecem.

Adicione o tráfego do produtor uma vez, na memória que está sendo avaliada

O leitor de display é apenas um participante. Renderização por CPU, decodificação de imagens, operações DMA2D e cópias de buffer podem criar leituras e gravações adicionais. Conte-as em um limite declarado: por exemplo, a memória externa que contém tanto a origem quanto o destino da cópia.

Suponha que um frame RGB565 completo seja copiado 30 vezes por segundo. Assuma que ambos os lados usem essa memória contabilizada e que cada payload cruze o limite uma vez. Cada cópia então lê 768.000 bytes e grava outros 768.000 bytes:

(768.000 leitura + 768.000 gravação) x 30 = 46.080.000 bytes/s

Adicionar essa cópia à varredura média por frame de uma camada dá 46,08 + 46,08 = 92,16 MB/s. Este é um subtotal ideal de payload. Exclui outro trabalho e custos de transação; caching ou staging intermediário podem alterar o tráfego no limite escolhido. Conte cada leitura e gravação uma vez; não adicione então a mesma cópia novamente sob um segundo rótulo, como tráfego de flush.

O posicionamento altera a conta. Se a origem da cópia residir em outro lugar, suas leituras podem não cruzar o mesmo limite de memória que as gravações de destino. Por outro lado, renderização que lê pixels de destino antes de gravá-los adiciona tráfego além de um modelo simples somente de gravação. Defina a operação em vez de atribuir a cada atualização de GUI um custo genérico.

Modos de renderização de GUI alteram o lado do produtor

O LVGL 9.5 distingue renderização PARTIAL, DIRECT e FULL. PARTIAL usa buffers de desenho menores para áreas alteradas. DIRECT usa buffers do tamanho da tela inteira; com dois buffers, copia as áreas renderizadas para o outro buffer após o flush. FULL redesenha a tela inteira.^[3]

Essas distinções pertencem à conta de carga de trabalho. Um nome de modo sozinho não pode estabelecer o tráfego resultante na memória externa. Rastreie onde a renderização ocorre, o que a operação de flush copia e quais alocações compartilham a memória em análise.

Renderização parcial não interrompe a varredura contínua do LTDC. Atualizar um botão pequeno pode reduzir o trabalho do produtor enquanto o controlador continua lendo o frame exibido. Se uma arquitetura em vez disso usar memória de imagem local ao display ou outro modelo de refresh, ela precisa de uma conta diferente da usada aqui.

Da mesma forma, o double buffering pode separar a propriedade entre produtor e leitor sem reduzir os bytes consumidos por um refresh. Também pode introduzir cópias de sincronização dependendo do framework. Compare operações reais em vez de assumir que um buffer extra é uma otimização de largura de banda.

Largura de banda média não pode proteger contra toda lacuna de serviço

Uma FIFO mantém uma reserva finita. Mesmo que a memória entregue bytes suficientes ao longo de um intervalo longo, um período sem serviço pode esgotar essa reserva durante o consumo ativo. É por isso que um resultado de largura de banda média não pode estabelecer imunidade a underrun.

Considere um modelo deliberadamente idealizado: uma FIFO de 256 bytes começa cheia, drena a uma taxa constante de 96 MB/s e não recebe recarga por quatro microssegundos. Esses são parâmetros fictícios para um exemplo independente, não uma especificação de FIFO do STM32 ou valores derivados da carga de trabalho RGB565 anterior.

Bytes demanded during the gap = 96.000.000 x 0,000004 = 384

O intervalo exige mais dados do que a reserva total assumida comporta. Um serviço mais rápido posteriormente não pode fornecer pixels cujo prazo já passou. Portanto, uma taxa de transferência adequada a longo prazo não pode compensar toda interrupção no serviço. Este exemplo demonstra uma restrição de latência; ele não prescreve um limite de agendamento para qualquer LTDC real.

Uma avaliação real necessita da organização alvo da FIFO, da ocupação no início de um intervalo, do comportamento de busca e do timing de serviço de memória. Uma FIFO que começa parcialmente cheia tem menos reserva do que este modelo. O reabastecimento durante o consumo altera a trajetória novamente. A aritmética permanece útil apenas quando suas premissas permanecem visíveis.

Investigar contenção com uma carga de trabalho representativa

A taxa de pico da interface não é o mesmo que entrega útil sustentada ao LTDC. O timing de memória do alvo, o padrão de transações, o comportamento de refresh, a arbitragem e os acessos concorrentes determinam o serviço que ele recebe. Não insira uma porcentagem de eficiência assumida e trate o resultado como um limite validado.

Construa um registro de carga de trabalho que separe o scanout estático da renderização adicionada, cópia e outros usuários de memória. Em seguida, exercite combinações realistas, incluindo transições que produzem rajadas de trabalho. Uma tela estática silenciosa não pode representar um sistema que também decodifica imagens e copia regiões atualizadas.

Colete os registros de status ou de driver documentados pelo alvo sem assumir que todo dispositivo expõe o mesmo contador. Confirme que o monitoramento está habilitado e registra os eventos de interesse. Siga suas semânticas de tratamento documentadas. Um período sem underrun registrado é evidência útil para aquelas condições; isso não prova compatibilidade total com o painel nem cobre toda carga de trabalho futura.

Mudanças possíveis incluem reduzir cópias desnecessárias, reconsiderar camadas ativas ou revisar o posicionamento e o agendamento de memória. Cada uma altera uma parte específica da conta e deve ser verificada no alvo. Mudanças de refresh devem permanecer dentro do timing suportado pelo painel; não há redução segura universal.

Mantenha a largura de banda separada de outras falhas de integração

Layout de pixel incorreto e dados obsoletos escritos pela CPU exigem suas próprias evidências. Um cálculo de largura de banda não pode provar publicação correta de cache ou propriedade de buffer. Por outro lado, corrigir a visibilidade de memória não pode garantir que um sistema de memória ocupado cumpra os prazos de scanout.

Utilizar o clock de pixel e timing de LCD para contexto de timing e o interfaces de módulo de display LCD guia para contexto de interface. Mantenha a conta de tráfego vinculada ao caminho real de scanout contínuo.

Para revisão específica do projeto, contate a RJY Display com o datasheet e timing do painel, MCU, topologia de memória e clock, largura de barramento, camadas e formatos, cronograma de renderização/cópia, registros de falhas e carga de trabalho concorrente representativa. Esses detalhes suportam uma discussão de integração com escopo definido; os números calculados não estabelecem uma placa compatível ou uma correção garantida.

Referências

1. ST AN4861, Revisão 7: Creating a graphical application with LTDC; discussão de camadas na mesma nota de aplicação. Fevereiro de 2026.
2. TouchGFX 4.27: Framebuffer, conforme lido em 22 de outubro de 2026.
3. LVGL 9.5: Display setup and draw buffers.