Larghezza di banda del framebuffer LTDC STM32: traffico e underrun FIFO

Un framebuffer può essere contenuto nella RAM mentre un display STM32 LTDC rimane comunque a corto di dati pixel. La capacità indica quanti byte possono essere memorizzati. La larghezza di banda descrive il traffico ricorrente. Il FIFO underrun riguarda se il controller riceve dati prima che la sua riserva corrente si esaurisca. Un progetto deve affrontare tutti e tre gli aspetti.

Questa analisi copre la scansione continua da un framebuffer lineare e non compresso. I suoi numeri sono ipotesi didattiche, non temporizzazioni di pannello o garanzie di prestazioni STM32. L'obiettivo è costruire un conteggio del traffico e un'indagine sulla latenza del servizio prima di decidere che un'interfaccia di memoria è adeguata.

Iniziare con la capacità, poi inserire il tempo nel calcolo

Assumere un'immagine attiva di 800 x 480 memorizzata in RGB565 a due byte per pixel. Un frame allocato in modo compatto richiede 800 x 480 x 2 = 768.000 byte. Due framebuffer di questo tipo richiedono 1.536.000 byte. Qualsiasi allocazione effettiva deve anche soddisfare i propri requisiti di layout e di memoria.

Questi valori stabiliscono la memorizzazione, non una velocità di trasferimento. Lo stesso frame memorizzato può essere letto ripetutamente senza modifiche. Al contrario, il rendering di un frame sostitutivo aggiunge traffico ancora prima che il motore di visualizzazione lo legga.

TouchGFX 4.27 descrive il costo di memorizzazione e il ciclo di vita del double buffering: un buffer può fornire una lettura continua per la visualizzazione mentre un altro viene renderizzato, con uno scambio controllato.^[2] Due buffer allocati non significano che LTDC legga due immagini complete per ogni refresh.

I buffer memorizzano immagini; i layer sono input di composizione configurati. Layer attivi multipli possono richiedere letture separate. Il double buffering di un layer cambia le posizioni dei frame successivi, non il numero di layer letti insieme.

Distinguere il traffico medio per frame dal consumo attivo

Mantenere l'immagine didattica a 800 x 480 e assumere un refresh a 60 Hz. Il payload utile di pixel attivi letto nell'arco di un secondo intero è:

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

Ovvero 46,08 MB/s usando megabyte decimali. È una media sull'intervallo di frame, non una garanzia che la memoria possa ritardare il servizio arbitrariamente all'interno di tale intervallo.

Ora assumere dimensioni di temporizzazione totali di 1056 x 525, incluso il blanking. Il corrispondente pixel clock è 1056 x 525 x 60 = 33,264 MHz. Moltiplicando tale clock per due byte si ottiene 66,528 MB/s come tasso di screening del consumo attivo basato sul pixel clock.

ST AN4861, Revisione 7, mette in relazione il pixel clock con le dimensioni di temporizzazione totali e il refresh, e presenta uno screening della larghezza di banda basato sul pixel clock e sui byte di memorizzazione per pixel del layer. Discute anche dei bus master concorrenti e distingue la starvation del FIFO da un errore di trasferimento.^[1]

Questo tasso di screening descrive la cadenza dei pixel attivi, non pixel RAM aggiuntivi per i porch o un tasso RAM costante attraverso il blanking. I fetch bufferizzati possono avvenire durante il blanking. Non aggiungere questo tasso alla media per frame.

I fetch di memoria reali possono essere a raffica e bufferizzati. Questi calcoli non descrivono l'esatto pattern di riempimento, l'overhead delle transazioni o il servizio di memoria garantito. Aiutano a distinguere il volume del payload utile dal tasso e dai vincoli temporali che lo forniscono.

Aggiungere il traffico del produttore una volta, presso la memoria in esame

Il lettore del display è solo uno dei partecipanti. Il rendering CPU, la decodifica delle immagini, le operazioni DMA2D e le copie dei buffer possono creare letture e scritture aggiuntive. Contarle a un confine dichiarato: ad esempio, la memoria esterna che contiene sia la sorgente della copia sia la destinazione.

Supporre che un frame RGB565 completo venga copiato 30 volte al secondo. Assumere che entrambi i lati utilizzino quella memoria conteggiata e che ogni payload attraversi il confine una volta. Ogni copia allora legge 768.000 byte e ne scrive altri 768.000:

(768.000 lettura + 768.000 scrittura) x 30 = 46.080.000 byte/s

Aggiungendo tale copia alla scansione media per frame a un layer si ottiene 46,08 + 46,08 = 92,16 MB/s. Questo è un subtotale ideale del payload. Esclude altro lavoro e costi di transazione; la cache o lo staging intermedio possono cambiare il traffico al confine scelto. Contare ogni lettura e scrittura una volta; non aggiungere poi la stessa copia di nuovo sotto un'altra etichetta come traffico di flush.

Il posizionamento cambia il conteggio. Se la sorgente della copia risiede altrove, le sue letture possono non attraversare lo stesso confine di memoria delle scritture di destinazione. Al contrario, il rendering che legge i pixel di destinazione prima di scriverli aggiunge traffico oltre un semplice modello di sola scrittura. Definire l'operazione invece di assegnare a ogni aggiornamento GUI un costo generico.

Le modalità di rendering GUI cambiano il lato produttore

LVGL 9.5 distingue il rendering PARTIAL, DIRECT e FULL. PARTIAL utilizza buffer di disegno più piccoli per le aree modificate. DIRECT utilizza buffer delle dimensioni dello schermo intero; con due buffer copia le aree renderizzate nell'altro buffer dopo il flush. FULL ridisegna l'intero schermo.^[3]

Queste distinzioni appartengono al conteggio del carico di lavoro. Il solo nome di una modalità non può stabilire il traffico risultante sulla memoria esterna. Tracciare dove avviene il rendering, cosa copia l'operazione di flush e quali allocazioni condividono la memoria in esame.

Il rendering parziale non interrompe la scansione continua di LTDC. L'aggiornamento di un piccolo pulsante può ridurre il lavoro del produttore mentre il controller continua a leggere il frame visualizzato. Se un'architettura utilizza invece memoria immagini locale al display o un altro modello di refresh, necessita di un conteggio diverso da quello usato qui.

Allo stesso modo, il double buffering può separare la proprietà del produttore e del lettore senza ridurre i byte consumati da un refresh. Può anche introdurre copie di sincronizzazione a seconda del framework. Confrontare le operazioni effettive invece di assumere che un buffer aggiuntivo sia un'ottimizzazione della larghezza di banda.

La larghezza di banda media non può proteggere da ogni lacuna nel servizio

Un FIFO contiene una riserva finita. Anche se la memoria fornisce byte sufficienti su un intervallo lungo, un periodo senza servizio può esaurire tale riserva durante il consumo attivo. Questo è il motivo per cui un risultato di larghezza di banda media non può stabilire l'immunità all'underrun.

Considerare un modello deliberatamente idealizzato: un FIFO da 256 byte parte pieno, si svuota a un tasso costante di 96 MB/s e non riceve riempimento per quattro microsecondi. Questi sono parametri fittizi per un esempio indipendente, non una specifica del FIFO STM32 o valori derivati dal precedente carico di lavoro RGB565.

Byte richiesti durante la lacuna = 96.000.000 x 0,000004 = 384

Il divario richiede più dati di quanti ne contenga la riserva totale ipotizzata. Un servizio più rapido successivamente non può fornire pixel la cui scadenza è già trascorsa. Una capacità di trasferimento adeguata a lungo termine non può quindi compensare ogni interruzione del servizio. Questo esempio dimostra un vincolo di latenza; non prescrive un limite di pianificazione per alcun LTDC reale.

Una valutazione reale necessita dell'organizzazione target della FIFO, dell'occupazione all'inizio di un divario, del comportamento di fetch e della temporizzazione del servizio di memoria. Una FIFO che parte parzialmente piena ha meno riserva di questo modello. Il riempimento durante il consumo cambia nuovamente la traiettoria. L'aritmetica rimane utile solo quando le sue ipotesi restano visibili.

Analizzare la contesa con un carico di lavoro rappresentativo

La velocità di picco dell'interfaccia non è la stessa cosa della consegna utile sostenuta all'LTDC. La temporizzazione della memoria del target, il pattern delle transazioni, il comportamento di refresh, l'arbitraggio e gli accessi concorrenti determinano il servizio che riceve. Non inserire una percentuale di efficienza ipotizzata e trattare il risultato come un limite validato.

Costruire un registro del carico di lavoro che separi lo scanout statico dal rendering aggiunto, dalla copia e dagli altri utenti della memoria. Poi esercitare combinazioni realistiche, incluse le transizioni che producono raffiche di lavoro. Una schermata statica silenziosa non può rappresentare un sistema che decodifica anche immagini e copia regioni aggiornate.

Raccogliere i record di stato o del driver documentati dal target senza presumere che ogni dispositivo esponga lo stesso contatore. Confermare che il monitoraggio sia abilitato e registri gli eventi di interesse. Seguire le semantiche di gestione documentate. Un periodo senza underrun registrati è un'evidenza utile per quelle condizioni; non prova la piena compatibilità del pannello né copre ogni carico di lavoro futuro.

Le modifiche possibili includono la riduzione delle copie non necessarie, la riconsiderazione dei layer attivi o la revisione del posizionamento e della pianificazione della memoria. Ciascuna modifica una parte specifica del conteggio e deve essere verificata sul target. Le modifiche al refresh devono rimanere entro la temporizzazione supportata dal pannello; non esiste una riduzione sicura universale.

Mantenere la larghezza di banda separata dagli altri guasti di integrazione

Un layout dei pixel errato e dati obsoleti scritti dalla CPU richiedono evidenze proprie. Un calcolo della larghezza di banda non può provare la corretta pubblicazione della cache o la proprietà del buffer. Al contrario, correggere la visibilità della memoria non può garantire che un sistema di memoria occupato rispetti le scadenze dello scanout.

Utilizzare la clock pixel e temporizzazione LCD per il contesto di temporizzazione e la interfacce dei moduli display LCD guida per il contesto dell'interfaccia. Mantenere il conteggio del traffico legato al percorso effettivo di scanout continuo.

Per una revisione specifica del progetto, RJY Display con il datasheet e la temporizzazione del pannello, MCU, topologia e clock della memoria, larghezza del bus, layer e formati, pianificazione di rendering/copia, record di guasto e carico di lavoro concorrente rappresentativo. Questi dettagli supportano una discussione di integrazione con ambito definito; i numeri calcolati non stabiliscono una scheda compatibile né una correzione garantita.

Riferimenti

1. ST AN4861, Revisione 7: Creazione di un'applicazione grafica con LTDC; discussione sui layer nella stessa application note. Febbraio 2026.
2. TouchGFX 4.27: Framebuffer, consultato il 22 ottobre 2026.
3. LVGL 9.5: Configurazione del display e buffer di disegno.