Bande passante du framebuffer LTDC STM32 : Trafic et sous-remplissage FIFO

Un framebuffer peut tenir en RAM alors qu'un écran STM32 LTDC manque encore de données de pixels. La capacité indique combien d'octets peuvent être stockés. La bande passante décrit le trafic récurrent. Le sous-remplissage de la FIFO concerne la question de savoir si le contrôleur reçoit les données avant que sa réserve actuelle ne s'épuise. Une conception doit traiter ces trois aspects.

Cette analyse couvre le balayage continu depuis un framebuffer linéaire et non compressé. Ses chiffres sont des hypothèses pédagogiques, et non des timings de panneau ou des garanties de performance STM32. L'objectif est de construire un bilan de trafic et une investigation de latence de service avant de décider qu'une interface mémoire est adéquate.

Commencer par la capacité, puis intégrer le temps dans le calcul

Supposons une image active de 800 x 480 stockée en RGB565 à deux octets par pixel. Une frame allouée de manière compacte nécessite 800 x 480 x 2 = 768 000 octets. Deux tels framebuffers nécessitent 1 536 000 octets. Toute allocation réelle doit également satisfaire ses exigences de disposition et de mémoire.

Ces chiffres établissent le stockage, pas un débit de transfert. La même frame stockée peut être lue de manière répétée sans changer. Inversement, le rendu d'une frame de remplacement ajoute du trafic avant même que le moteur d'affichage ne la lise.

TouchGFX 4.27 décrit le coût de stockage et le cycle de vie du double buffering : un buffer peut fournir une lecture d'affichage continue pendant qu'un autre est rendu, avec un échange contrôlé.^[2] Deux buffers alloués ne signifient pas que le LTDC lit deux images complètes à chaque rafraîchissement.

Les buffers stockent des images ; les couches sont des entrées de composition configurées. Plusieurs couches actives peuvent nécessiter des lectures séparées. Le double buffering d'une couche modifie les emplacements successifs des frames, pas le nombre de couches lues ensemble.

Distinguer le trafic moyen par frame de la consommation active

Conserver l'image pédagogique à 800 x 480 et supposer un rafraîchissement à 60 Hz. La charge utile de pixels actifs lue sur une seconde entière est :

800 x 480 x 60 x 2 = 46 080 000 octets/s

Cela représente 46,08 Mo/s en mégaoctets décimaux. Il s'agit d'une moyenne sur l'intervalle de frame, et non d'une garantie que la mémoire peut retarder le service arbitrairement dans cet intervalle.

Supposons maintenant des dimensions de timing totales de 1056 x 525, incluant le blanking. L'horloge pixel correspondante est 1056 x 525 x 60 = 33,264 MHz. Multiplier cette horloge par deux octets donne 66,528 Mo/s comme taux de criblage de consommation active basé sur l'horloge pixel.

ST AN4861, révision 7, relie l'horloge pixel aux dimensions de timing totales et au rafraîchissement, et présente un criblage de bande passante basé sur l'horloge pixel et les octets de stockage par pixel des couches. Il aborde également les maîtres de bus concurrents et distingue la famine de FIFO d'une erreur de transfert.^[1]

Ce taux de criblage décrit la cadence des pixels actifs, et non les pixels RAM supplémentaires pour les porches ou un débit RAM constant pendant le blanking. Les fetches bufferisés peuvent se produire pendant le blanking. Ne pas ajouter ce taux à la moyenne par frame.

Les fetches mémoire réels peuvent être irréguliers et bufferisés. Ces calculs ne décrivent pas le schéma exact de remplissage, les surcoûts de transaction ou le service mémoire garanti. Ils aident à distinguer le volume de charge utile utile du taux et des contraintes de timing qui l'alimentent.

Ajouter le trafic producteur une seule fois, au niveau de la mémoire évaluée

Le lecteur d'affichage n'est qu'un participant. Le rendu CPU, le décodage d'images, les opérations DMA2D et les copies de buffers peuvent créer des lectures et écritures supplémentaires. Les compter à une frontière déclarée : par exemple, la mémoire externe qui contient à la fois la source et la destination de la copie.

Supposons qu'une frame RGB565 complète soit copiée 30 fois par seconde. Supposons que les deux côtés utilisent cette mémoire comptée et que chaque charge utile traverse la frontière une fois. Chaque copie lit alors 768 000 octets et écrit 768 000 autres octets :

(768 000 lecture + 768 000 écriture) x 30 = 46 080 000 octets/s

Ajouter cette copie au balayage moyen par frame d'une couche donne 46,08 + 46,08 = 92,16 Mo/s. Il s'agit d'un sous-total de charge utile idéal. Il exclut les autres travaux et les coûts de transaction ; la mise en cache ou le staging intermédiaire peut modifier le trafic à la frontière choisie. Compter chaque lecture et écriture une fois ; ne pas ensuite ajouter la même copie sous une seconde étiquette telle que le trafic de flush.

Le placement modifie le bilan. Si la source de copie réside ailleurs, ses lectures peuvent ne pas traverser la même frontière mémoire que les écritures de destination. Inversement, un rendu qui lit les pixels de destination avant de les écrire ajoute du trafic au-delà d'un simple modèle en écriture seule. Définir l'opération plutôt que d'attribuer à chaque mise à jour GUI un coût générique.

Les modes de rendu GUI modifient le côté producteur

LVGL 9.5 distingue les rendus PARTIAL, DIRECT et FULL. PARTIAL utilise des buffers de dessin plus petits pour les zones modifiées. DIRECT utilise des buffers de taille plein écran ; avec deux buffers, il copie les zones rendues vers l'autre buffer après le flush. FULL redessine l'écran entier.^[3]

Ces distinctions appartiennent au bilan de charge de travail. Un nom de mode seul ne peut pas établir le trafic mémoire externe résultant. Tracer où le rendu se produit, ce que l'opération de flush copie, et quelles allocations partagent la mémoire examinée.

Le rendu partiel n'arrête pas le balayage LTDC continu. La mise à jour d'un petit bouton peut réduire le travail du producteur pendant que le contrôleur continue de lire la frame affichée. Si une architecture utilise plutôt une mémoire d'image locale à l'affichage ou un autre modèle de rafraîchissement, elle nécessite un bilan différent de celui utilisé ici.

De même, le double buffering peut séparer la propriété du producteur et du lecteur sans réduire les octets consommés par un rafraîchissement. Il peut également introduire des copies de synchronisation selon le framework. Comparer les opérations réelles plutôt que de supposer qu'un buffer supplémentaire est une optimisation de bande passante.

La bande passante moyenne ne peut pas protéger contre toutes les interruptions de service

Une FIFO contient une réserve finie. Même si la mémoire fournit suffisamment d'octets sur un intervalle long, une période sans service peut épuiser cette réserve pendant la consommation active. C'est pourquoi un résultat de bande passante moyenne ne peut pas établir l'immunité au sous-remplissage.

Considérons un modèle délibérément idéalisé : une FIFO de 256 octets commence pleine, se vide à un débit constant de 96 Mo/s et ne reçoit aucun remplissage pendant quatre microsecondes. Ce sont des paramètres fictifs pour un exemple indépendant, et non une spécification de FIFO STM32 ou des valeurs dérivées de la charge de travail RGB565 précédente.

Octets demandés pendant l'interruption = 96 000 000 x 0,000004 = 384

L'écart exige plus de données que ce que contient la réserve totale supposée. Un service plus rapide par la suite ne peut pas fournir les pixels dont l'échéance est déjà passée. Un débit adéquat à long terme ne peut donc pas compenser chaque interruption de service. Cet exemple illustre une contrainte de latence ; il ne prescrit pas de limite d'ordonnancement pour un LTDC réel quelconque.

Une évaluation réelle nécessite l'organisation cible de la FIFO, l'occupation au début d'un écart, le comportement de récupération et la temporisation du service mémoire. Une FIFO qui démarre partiellement remplie dispose de moins de réserve que ce modèle. Le remplissage pendant la consommation modifie à nouveau la trajectoire. L'arithmétique ne reste utile que lorsque ses hypothèses restent visibles.

Étudier la contention avec une charge de travail représentative

Le débit de crête de l'interface n'est pas identique à la livraison utile soutenue au LTDC. La temporisation mémoire de la cible, le modèle de transactions, le comportement de rafraîchissement, l'arbitrage et les accès concurrents déterminent le service qu'elle reçoit. Ne pas insérer un pourcentage d'efficacité supposé et traiter le résultat comme une limite validée.

Construire un enregistrement de charge de travail qui sépare le balayage statique du rendu ajouté, de la copie et des autres utilisateurs de mémoire. Ensuite, exercer des combinaisons réalistes, y compris des transitions qui produisent des rafales de travail. Un écran statique calme ne peut pas représenter un système qui décode également des images et copie des régions mises à jour.

Collecter les états documentés ou les enregistrements de pilotes de la cible sans supposer que chaque dispositif expose le même compteur. Confirmer que la surveillance est activée et enregistre les événements d'intérêt. Suivre ses sémantiques de traitement documentées. Une période sans sous-consommation enregistrée constitue une preuve utile pour ces conditions ; elle ne prouve pas la compatibilité complète avec le panneau ni ne couvre toute charge de travail future.

Les modifications possibles incluent la réduction des copies inutiles, la reconsidération des couches actives ou la révision du placement mémoire et de l'ordonnancement. Chacune modifie une partie spécifique du bilan et doit être vérifiée sur la cible. Les modifications de rafraîchissement doivent rester dans les temporisations prises en charge par le panneau ; il n'existe pas de réduction sûre universelle.

Séparer la bande passante des autres défauts d'intégration

Une disposition de pixels incorrecte et des données obsolètes écrites par le CPU nécessitent leurs propres preuves. Un calcul de bande passante ne peut pas prouver une publication de cache correcte ni la propriété du tampon. Inversement, corriger la visibilité mémoire ne peut pas garantir qu'un système mémoire occupé respecte les échéances de balayage.

Utilisez le guide du pixel clock et du timing LCD de RJY pour le contexte de temporisation et le interfaces des modules d'affichage LCD guide pour le contexte d'interface. Maintenir le bilan de trafic lié au chemin réel de balayage continu.

Pour une revue spécifique au projet, contactez RJY Display avec la fiche technique et la temporisation du panneau, le MCU, la topologie mémoire et l'horloge, la largeur de bus, les couches et formats, le calendrier de rendu/copie, les enregistrements de fautes et une charge de travail concurrente représentative. Ces détails soutiennent une discussion d'intégration délimitée ; les chiffres calculés n'établissent pas une carte compatible ni un correctif garanti.

Références

1. ST AN4861, Révision 7 : Création d'une application graphique avec LTDC; discussion des couches dans la même note d'application. Février 2026.
2. TouchGFX 4.27 : Framebuffer, tel que lu le 22 octobre 2026.
3. LVGL 9.5 : Configuration de l'affichage et tampons de dessin.