STM32 LTDC Framebuffer-Bandbreite: Datenverkehr und FIFO-Unterlauf

Ein Framebuffer kann in den RAM passen, während eine STM32-LTDC-Anzeige dennoch keine Pixeldaten mehr erhält. Die Kapazität beantwortet die Frage, wie viele Bytes gespeichert werden können. Die Bandbreite beschreibt den wiederkehrenden Datenverkehr. Ein FIFO-Unterlauf betrifft die Frage, ob der Controller Daten erhält, bevor seine aktuelle Reserve erschöpft ist. Ein Design muss alle drei Aspekte berücksichtigen.

Diese Analyse behandelt den kontinuierlichen Scanout aus einem linearen, unkomprimierten Framebuffer. Die Zahlen sind didaktische Annahmen, keine Panel-Timings oder STM32-Leistungsgarantien. Das Ziel ist, eine Verkehrsbilanz und eine Untersuchung der Service-Latenz zu erstellen, bevor entschieden wird, dass eine Speicherschnittstelle ausreichend ist.

Beginnen Sie mit der Kapazität und bringen Sie dann die Zeit in die Berechnung ein

Nehmen Sie ein aktives Bild von 800 x 480 an, das in RGB565 mit zwei Bytes pro Pixel gespeichert ist. Ein eng allokierter Frame benötigt 800 x 480 x 2 = 768.000 Bytes. Zwei solche Framebuffer benötigen 1.536.000 Bytes. Jede tatsächliche Allokation muss auch ihre Layout- und Speicheranforderungen erfüllen.

Diese Zahlen legen den Speicherbedarf fest, nicht eine Übertragungsrate. Derselbe gespeicherte Frame kann wiederholt gelesen werden, ohne sich zu ändern. Umgekehrt erzeugt das Rendern eines Ersatz-Frames zusätzlichen Verkehr, noch bevor die Display-Engine ihn liest.

TouchGFX 4.27 beschreibt die Speicherkosten und den Lebenszyklus des Double Buffering: Ein Buffer kann die kontinuierliche Display-Ausgabe liefern, während ein anderer gerendert wird, mit einem kontrollierten Austausch.^[2] Zwei allokierte Buffer bedeuten nicht, dass LTDC bei jeder Aktualisierung zwei vollständige Bilder liest.

Buffer speichern Bilder; Layer sind konfigurierte Kompositionseingaben. Mehrere aktive Layer können separate Lesevorgänge erfordern. Double Buffering eines Layers ändert die aufeinanderfolgenden Frame-Positionen, nicht die Anzahl der gemeinsam gelesenen Layer.

Unterscheiden Sie frame-gemittelten Verkehr vom aktiven Verbrauch

Behalten Sie das didaktische Bild bei 800 x 480 und nehmen Sie eine Aktualisierungsrate von 60 Hz an. Die über eine ganze Sekunde gelesene Nutzlast aktiver Pixel beträgt:

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

Das sind 46,08 MB/s unter Verwendung dezimaler Megabytes. Es ist ein Mittelwert über das Frame-Intervall, keine Garantie dafür, dass der Speicher den Service innerhalb dieses Intervalls beliebig verzögern darf.

Nehmen Sie nun Gesamt-Timing-Dimensionen von 1056 x 525 an, einschließlich Blanking. Der entsprechende Pixeltakt beträgt 1056 x 525 x 60 = 33,264 MHz. Multipliziert man diesen Takt mit zwei Bytes, ergibt sich 66,528 MB/s als pixeltaktbasierte Screening-Rate für den aktiven Verbrauch.

ST AN4861, Revision 7, setzt den Pixeltakt in Beziehung zu den Gesamt-Timing-Dimensionen und der Aktualisierungsrate und stellt ein Bandbreiten-Screening basierend auf Pixeltakt und Layer-Speicherbytes pro Pixel vor. Es behandelt auch konkurrierende Bus-Master und unterscheidet FIFO-Starvation von einem Übertragungsfehler.^[1]

Diese Screening-Rate beschreibt die Kadenz aktiver Pixel, nicht zusätzliche RAM-Pixel für Porches oder eine konstante RAM-Rate während des Blankings. Gepufferte Fetches können während des Blankings erfolgen. Addieren Sie diese Rate nicht zum Frame-Mittelwert.

Reale Speicher-Fetches können bursty und gepuffert sein. Diese Berechnungen beschreiben nicht das genaue Nachfüllmuster, den Transaktions-Overhead oder einen garantierten Speicher-Service. Sie helfen, das Volumen der Nutzlast von den Raten- und Timing-Einschränkungen zu unterscheiden, die es liefern.

Fügen Sie Producer-Verkehr einmal hinzu, an dem Speicher, der bewertet wird

Der Display-Leser ist nur ein Teilnehmer. CPU-Rendering, Bilddekodierung, DMA2D-Operationen und Buffer-Kopien können zusätzliche Lese- und Schreibvorgänge erzeugen. Zählen Sie sie an einer festgelegten Grenze: zum Beispiel dem externen Speicher, der sowohl Kopierquelle als auch -ziel enthält.

Angenommen, ein vollständiger RGB565-Frame wird 30-mal pro Sekunde kopiert. Nehmen Sie an, dass beide Seiten diesen gezählten Speicher verwenden und jede Nutzlast die Grenze einmal überschreitet. Jede Kopie liest dann 768.000 Bytes und schreibt weitere 768.000 Bytes:

(768.000 Lesen + 768.000 Schreiben) x 30 = 46.080.000 Bytes/s

Addiert man diese Kopie zum frame-gemittelten Scanout eines Layers, ergibt sich 46,08 + 46,08 = 92,16 MB/s. Dies ist eine ideale Nutzlast-Zwischensumme. Sie schließt andere Arbeiten und Transaktionskosten aus; Caching oder Zwischenstaging können den Verkehr an der gewählten Grenze verändern. Zählen Sie jeden Lese- und Schreibvorgang einmal; addieren Sie dann nicht dieselbe Kopie erneut unter einem zweiten Label wie Flush-Verkehr.

Die Platzierung ändert das Konto. Wenn die Kopierquelle woanders liegt, überschreiten ihre Lesevorgänge möglicherweise nicht dieselbe Speichergrenze wie die Ziel-Schreibvorgänge. Umgekehrt fügt Rendering, das Zielpixel vor dem Schreiben liest, Verkehr über ein einfaches Write-Only-Modell hinaus hinzu. Definieren Sie die Operation, anstatt jeder GUI-Aktualisierung einen generischen Kostenwert zuzuweisen.

GUI-Render-Modi verändern die Producer-Seite

LVGL 9.5 unterscheidet zwischen PARTIAL-, DIRECT- und FULL-Rendering. PARTIAL verwendet kleinere Draw-Buffer für geänderte Bereiche. DIRECT verwendet bildschirmgroße Buffer; mit zwei Buffern kopiert es gerenderte Bereiche nach dem Flush in den anderen Buffer. FULL zeichnet den gesamten Bildschirm neu.^[3]

Diese Unterscheidungen gehören in das Arbeitslast-Konto. Ein Modusname allein kann den resultierenden externen Speicherverkehr nicht belegen. Verfolgen Sie, wo das Rendering stattfindet, was die Flush-Operation kopiert und welche Allokationen den zu untersuchenden Speicher gemeinsam nutzen.

Partielles Rendering stoppt den kontinuierlichen LTDC-Scanout nicht. Das Aktualisieren einer kleinen Schaltfläche kann die Producer-Arbeit reduzieren, während der Controller weiterhin den angezeigten Frame liest. Wenn eine Architektur stattdessen display-lokalen Bildspeicher oder ein anderes Aktualisierungsmodell verwendet, benötigt sie ein anderes Konto als das hier verwendete.

Ebenso kann Double Buffering die Eigentümerschaft von Producer und Reader trennen, ohne die von einer Aktualisierung verbrauchten Bytes zu reduzieren. Je nach Framework kann es auch Synchronisationskopien einführen. Vergleichen Sie tatsächliche Operationen, anstatt anzunehmen, dass ein zusätzlicher Buffer eine Bandbreitenoptimierung ist.

Durchschnittliche Bandbreite kann nicht vor jeder Service-Lücke schützen

Ein FIFO hält eine endliche Reserve. Selbst wenn der Speicher über ein langes Intervall genügend Bytes liefert, kann eine Periode ohne Service diese Reserve während des aktiven Verbrauchs erschöpfen. Deshalb kann ein durchschnittliches Bandbreitenergebnis keine Immunität gegen Unterlauf belegen.

Betrachten Sie ein bewusst idealisiertes Modell: Ein 256-Byte-FIFO startet voll, entleert sich mit konstanten 96 MB/s und erhält vier Mikrosekunden lang keine Nachfüllung. Dies sind fiktive Parameter für ein unabhängiges Beispiel, keine STM32-FIFO-Spezifikation oder aus der früheren RGB565-Arbeitslast abgeleitete Werte.

Während der Lücke benötigte Bytes = 96.000.000 x 0,000004 = 384

Die Lücke erfordert mehr Daten, als die vollständig angenommene Reserve vorhält. Ein danach schnellerer Dienst kann keine Pixel liefern, deren Deadline bereits verstrichen ist. Ein ausreichender langfristiger Durchsatz kann daher nicht jede Dienstunterbrechung kompensieren. Dieses Beispiel demonstriert eine Latenzbeschränkung; es schreibt kein Scheduling-Limit für ein bestimmtes tatsächliches LTDC vor.

Eine reale Bewertung benötigt die Ziel-FIFO-Organisation, den Füllstand zu Beginn einer Lücke, das Fetch-Verhalten und das Speicherdienst-Timing. Eine FIFO, die teilweise gefüllt startet, hat weniger Reserve als dieses Modell. Nachfüllen während des Verbrauchs verändert die Trajektorie erneut. Die Arithmetik bleibt nur nützlich, wenn ihre Annahmen sichtbar bleiben.

Konkurrenz mit einer repräsentativen Arbeitslast untersuchen

Die Spitzen-Schnittstellenrate ist nicht dasselbe wie die dauerhaft nutzbare Lieferung an das LTDC. Das Speicher-Timing des Ziels, das Transaktionsmuster, das Refresh-Verhalten, die Arbitration und konkurrierende Zugriffe bestimmen den Dienst, den es erhält. Fügen Sie keinen angenommenen Effizienzprozentsatz ein und behandeln Sie das Ergebnis nicht als validiertes Limit.

Erstellen Sie eine Arbeitslastaufzeichnung, die statisches Scanout von zusätzlichem Rendering, Kopieren und anderen Speichernutzern trennt. Führen Sie dann realistische Kombinationen aus, einschließlich Übergängen, die Arbeitsspitzen erzeugen. Ein ruhiger statischer Bildschirm kann kein System repräsentieren, das auch Bilder dekodiert und aktualisierte Bereiche kopiert.

Erfassen Sie die dokumentierten Status- oder Treiberaufzeichnungen des Ziels, ohne anzunehmen, dass jedes Gerät denselben Zähler bereitstellt. Bestätigen Sie, dass die Überwachung aktiviert ist und die relevanten Ereignisse aufzeichnet. Folgen Sie ihren dokumentierten Behandlungssemantiken. Ein Zeitraum ohne aufgezeichneten Underrun ist nützliche Evidenz für diese Bedingungen; er beweist nicht die vollständige Panel-Kompatibilität und deckt nicht jede zukünftige Arbeitslast ab.

Mögliche Änderungen umfassen die Reduzierung unnötiger Kopien, die Überprüfung aktiver Layer oder die Anpassung von Speicherplatzierung und Scheduling. Jede ändert einen bestimmten Teil der Bilanz und muss auf dem Ziel überprüft werden. Refresh-Änderungen müssen innerhalb des unterstützten Timings des Panels bleiben; es gibt keine universell sichere Reduzierung.

Bandbreite von anderen Integrationsfehlern getrennt halten

Falsches Pixel-Layout und veraltete CPU-geschriebene Daten erfordern ihre eigene Evidenz. Eine Bandbreitenberechnung kann weder korrekte Cache-Veröffentlichung noch Puffer-Eigentümerschaft beweisen. Umgekehrt kann die Korrektur der Speichersichtbarkeit nicht garantieren, dass ein ausgelastetes Speichersystem die Scanout-Deadlines einhält.

Verwenden Sie die LCD-Pixelclock- und Timing-Leitfaden für den Timing-Kontext und den LCD-Display-Modul-Schnittstellen Leitfaden für den Schnittstellenkontext. Halten Sie die Verkehrsbilanz an den tatsächlichen kontinuierlichen Scanout-Pfad gebunden.

Für projektspezifische Überprüfung, kontaktieren Sie RJY Display mit dem Panel-Datenblatt und Timing, MCU, Speichertopologie und Takt, Busbreite, Layern und Formaten, Render-/Kopier-Zeitplan, Fehleraufzeichnungen und repräsentativer gleichzeitiger Arbeitslast. Diese Details stützen eine abgegrenzte Integrationsdiskussion; die durchgerechneten Zahlen belegen weder eine kompatible Platine noch eine garantierte Lösung.

Referenzen

1. ST AN4861, Revision 7: Creating a graphical application with LTDC; Layer-Diskussion in derselben Application Note. Februar 2026.
2. TouchGFX 4.27: Framebuffer, gelesen am 22. Oktober 2026.
3. LVGL 9.5: Display setup and draw buffers.