Wie man FPS in eingebetteten Systemen misst

Inhaltsübersicht

Warum FPS in eingebetteten Systemen messen?

Die Messung der FPS in eingebetteten Systemen hilft dabei, zu quantifizieren, wie reaktionsschnell und reibungslos die Benutzeroberfläche unter realen Hardwarebeschränkungen tatsächlich ist. Sie bietet eine einfache, vergleichbare Metrik, die es einfacher macht, Leistungsprobleme zu erkennen, Optimierungen zu bewerten und zu überprüfen, ob das System die Anforderungen erfüllt.

In der Praxis werden die FPS häufig als schnelles Feedbacksignal während der Entwicklung verwendet, um auf Probleme im Zusammenhang mit der CPU-Last, der Speicherbandbreite oder dem Display-Durchsatz hinzuweisen. Sie sagt zwar nicht alles aus, ist aber ein nützlicher Ausgangspunkt für das Verständnis und die Verbesserung der Gesamtleistung der Benutzeroberfläche.

Wie kann man FPS in eingebetteten Systemen messen?

Die Messung von FPS (Bilder pro Sekunde) in eingebetteten Systemen ist nicht so einfach wie in Desktop-Umgebungen. Es gibt in der Regel keine eingebauten Profiler, GPU-Zähler oder eine standardisierte Rendering-Pipeline. Stattdessen müssen die FPS daraus abgeleitet werden, wie und wann der Bildschirm tatsächlich aktualisiert wird.

In der Praxis geht es bei der FPS-Messung darum, eine Frage zu beantworten:

Wie oft produziert das System ein vollständig gerendertes Bild?

Die Antwort hängt vom Grafikstack, dem Rendering-Modell und der Anzeigeoberfläche ab.

Was bedeutet Frame in Embedded?

Bevor Sie FPS messen, sollten Sie definieren, was ein „Frame“ ist.

In eingebetteten Systemen kann ein Frame bedeuten:

• vollständige Aktualisierung des Framebuffers (üblich bei doppelter Pufferung)
• Teilweise Aktualisierung (nur verschmutzte Bereiche)
• Display bündig (Übertragung auf das Display)

Aus diesem Grund kann FPS sein:

• Render FPS – wie oft die Benutzeroberfläche gezeichnet wird
• Display FPS – wie oft Pixel an das Display gesendet werden

Diese sind nicht immer identisch.

In diesem Beispiel konzentrieren wir uns auf das Rendern von FPS.

STM32 / Bare Metal (Generischer Ansatz)

Auf MCU-Systemen (z.B. STM32) werden die FPS oft mit einem Timer oder Zykluszähler gemessen.

Ansatz:

• Inkrementieren des Bildzählers am Ende der Rendering-Schleife
• Messung der verstrichenen Zeit mit SysTick oder DWT-Zykluszähler

Dann in einer periodischen Aufgabe:

Was dies misst:

• FPS wiedergeben

Alternativ (genauer):

Verwenden Sie das DWT->CYCCNT-Register, um die genaue Rahmenzeit in CPU-Zyklen zu messen.

Eine präzisere Methode zur Messung von FPS auf STM32 (und Cortex-M im Allgemeinen) ist die Verwendung des DWT-Zykluszählers (DWT->CYCCNT), der die CPU-Taktzyklen zählt, anstatt sich auf Millisekunden-Systemticks zu verlassen.

So funktioniert es:
Zu Beginn eines Frames speichern Sie den aktuellen Wert von CYCCNT. Am Ende des Bildes lesen Sie ihn erneut und berechnen die Differenz. So erhalten Sie die genaue Anzahl der CPU-Zyklen, die für das Rendern eines Einzelbildes benötigt werden. Wenn Sie die CPU-Frequenz kennen, können Sie die FPS berechnen:

FPS = CPU_Frequenz / Zyklen_pro_Bild

Vorteile:

• Sehr hohe Präzision (Zyklusgenauigkeit)
• Ideal für Leistungsanalyse und -optimierung
• Keine Beeinträchtigung durch SysTick-Unterbrechungen oder Jitter bei der Planung

Benachteiligungen:

• Erfordert eine bekannte und stabile CPU-Taktfrequenz
• Nicht auf allen Cortex-M-Kernen verfügbar (z.B. M0/M0+)
• Etwas komplizierter in der Einrichtung und Verwendung
• Zählerüberlauf muss bei längeren Messungen berücksichtigt werden

LVGL Leistungsüberwachung (LV_USE_PERF_MONITOR)

LVGL bietet eine integrierte Möglichkeit zur Leistungsüberwachung, indem Sie die Option LV_USE_PERF_MONITOR in der Konfiguration (lv_conf.h) aktivieren. Wenn diese Option aktiviert ist, zeigt LVGL auf dem Bildschirm ein kleines Overlay mit Echtzeit-Metriken an.

Dazu gehören in der Regel:

• FPS (Bilder pro Sekunde)
• CPU-Nutzung (Zeit, die für LVGL-Aufgaben verwendet wird)
• manchmal speicherbezogene Statistiken (je nach Konfiguration)

Der Monitor arbeitet intern, indem er verfolgt, wie oft die Rendering-Schleife läuft und wie viel Zeit für die Verarbeitung von Aufgaben und das Zeichnen aufgewendet wird.

Was dies misst:

• eine Mischung aus Render-FPS und Systemlast
• näher an der „UI-Leistung“ als an den rohen Display-FPS

Warum es nützlich ist:

• Zero-Effort-Einrichtung (einfach in der Konfiguration aktivieren)
• sofortiges visuelles Feedback während der Entwicklung
• ideal für eine schnelle Leistungsüberprüfung und Regressionstests

Beschränkungen:

• misst nicht die tatsächliche Übertragungszeit der Anzeige (bündig zum Bildschirm)
• FPS spiegeln möglicherweise keine Vollbildaktualisierungen wider, wenn ein teilweises Redraw verwendet wird
• fügt leichten Overhead hinzu (sollte in der Produktion deaktiviert werden)

In der Praxis ist LV_USE_PERF_MONITOR der schnellste Weg, um ein grobes Verständnis der Systemleistung zu erhalten. Für präzise Messungen – insbesondere bei der Optimierung von Bandbreiten oder Display-Treibern – sollte es jedoch mit dem Timing auf niedrigerer Ebene kombiniert werden (z.B. Messung von Flush-Callbacks).

LVGL bietet eine integrierte Möglichkeit zur Leistungsüberwachung, indem Sie die Option LV_USE_PERF_MONITOR in der Konfiguration (lv_conf.h) aktivieren. Wenn diese Option aktiviert ist, zeigt LVGL auf dem Bildschirm ein kleines Overlay mit Echtzeit-Metriken an.

Dazu gehören in der Regel:

• FPS (Bilder pro Sekunde)
• CPU-Nutzung (Zeit, die für LVGL-Aufgaben verwendet wird)
• manchmal speicherbezogene Statistiken (je nach Konfiguration)

Der Monitor arbeitet intern, indem er verfolgt, wie oft die Rendering-Schleife läuft und wie viel Zeit für die Verarbeitung von Aufgaben und das Zeichnen aufgewendet wird.

Was dies misst:

• eine Mischung aus Render-FPS und Systemlast
• näher an der „UI-Leistung“ als an den rohen Display-FPS

Warum es nützlich ist:

• Zero-Effort-Einrichtung (einfach in der Konfiguration aktivieren)
• sofortiges visuelles Feedback während der Entwicklung
• ideal für eine schnelle Leistungsüberprüfung und Regressionstests

Beschränkungen:

• misst nicht die tatsächliche Übertragungszeit der Anzeige (bündig zum Bildschirm)
• FPS spiegeln möglicherweise keine Vollbildaktualisierungen wider, wenn ein teilweises Redraw verwendet wird
• fügt leichten Overhead hinzu (sollte in der Produktion deaktiviert werden)

In der Praxis ist LV_USE_PERF_MONITOR der schnellste Weg, um ein grobes Verständnis der Systemleistung zu erhalten. Für präzise Messungen – insbesondere bei der Optimierung von Bandbreiten oder Display-Treibern – sollte es jedoch mit dem Timing auf niedrigerer Ebene kombiniert werden (z.B. Messung von Flush-Callbacks).

MPU/Linux

Auf Linux-Systemen hängt die FPS-Messung vom Grafik-Stack ab.

Einfacher Framebuffer (fbdev)

Messen Sie die Zeit zwischen Pufferwechseln:

Wayland / GUI-Frameworks

Die Optionen umfassen:

• integrierte Tools (z.B. Weston FPS-Zähler)
• Timing auf App-Ebene
• GPU-Profiling-Tools (falls verfügbar)

Schlussfolgerungen

Um die FPS in eingebetteten Systemen zu messen, müssen Sie verstehen, was ein „Frame“ in einer bestimmten Pipeline tatsächlich bedeutet. Ob Sie nun Rendering-Schleifen, Flush-Callbacks oder Buffer-Swaps messen, jede Methode spiegelt einen anderen Aspekt der Leistung wider. Frameworks wie LVGL oder Linux-basierte Stacks bieten nützliche Anhaltspunkte, aber es ist Sache des Entwicklers, den richtigen Messpunkt zu wählen.

In der Praxis reichen die FPS allein nicht aus. Die Konsistenz der Bildrate, die Latenzzeit und die Speicherbandbreite haben oft einen größeren Einfluss auf die wahrgenommene Leistung. Eine stabile und vorhersehbare Bildrate ist in der Regel wichtiger als das Erreichen der höchstmöglichen FPS.