Come misurare gli FPS nei sistemi embedded

Indice dei contenuti

Perché misurare gli FPS nei sistemi embedded?

La misurazione degli FPS nei sistemi embedded aiuta a quantificare la reattività e la fluidità dell’interfaccia utente in presenza di vincoli hardware reali. Fornisce una metrica semplice e comparabile che facilita l’individuazione dei problemi di prestazioni, la valutazione delle ottimizzazioni e la verifica della conformità del sistema ai requisiti.

In pratica, l’FPS viene spesso utilizzato come segnale di feedback rapido durante lo sviluppo, evidenziando i problemi legati al carico della CPU, alla larghezza di banda della memoria o al throughput del display. Anche se non racconta tutta la storia, è un utile punto di partenza per comprendere e migliorare le prestazioni complessive dell’interfaccia utente.

Come misurare gli FPS nei sistemi embedded?

Misurare gli FPS (fotogrammi al secondo) nei sistemi embedded non è così semplice come negli ambienti desktop. Di solito non esistono profiler integrati, contatori della GPU o una pipeline di rendering standardizzata. Invece, gli FPS devono essere ricavati da come e quando lo schermo viene effettivamente aggiornato.

In pratica, la misurazione degli FPS serve a rispondere a una domanda:

Con quale frequenza il sistema produce un fotogramma completamente renderizzato?

La risposta dipende dallo stack grafico, dal modello di rendering e dall’interfaccia di visualizzazione.

Cosa significa cornice in embedded?

Prima di misurare gli FPS, è importante definire cosa sia un “frame”.

Nei sistemi embedded, un frame può significare:

• aggiornamento completo del framebuffer (comune nel double buffering)
• aggiornamento parziale (solo aree sporche)
• lavaggio del display (trasferimento sul display)

Per questo motivo, gli FPS possono essere:

• render FPS – la frequenza con cui viene disegnata l’interfaccia utente
• FPS del display – la frequenza con cui i pixel vengono inviati al display

Questi non sono sempre gli stessi.

In questo esempio ci concentreremo sul rendering FPS.

STM32 / Bare metal (approccio generico)

Nei sistemi MCU (ad esempio STM32), gli FPS vengono spesso misurati utilizzando un timer o un contatore di cicli.

Approccio:

• incrementa il contatore di fotogrammi alla fine del ciclo di rendering
• misurare il tempo trascorso usando il contatore di cicli SysTick o DWT

Poi in un’attività periodica:

Cosa misura:

• Rendering FPS

Alternativa (più precisa):

Usa il registro DWT->CYCCNT per misurare il tempo esatto del frame in cicli della CPU.

Un modo più preciso per misurare gli FPS sull’STM32 (e sul Cortex-M in generale) è quello di utilizzare il contatore di cicli DWT (DWT->CYCCNT), che conta i cicli di clock della CPU invece di affidarsi ai ticchettii millisecondi del sistema.

Come funziona:
All’inizio di un fotogramma, memorizzi il valore corrente di CYCCNT. Alla fine del fotogramma, lo leggi di nuovo e calcoli la differenza. In questo modo si ottiene il numero esatto di cicli della CPU spesi per il rendering di un singolo fotogramma. Conoscendo la frequenza della CPU, puoi calcolare gli FPS:

FPS = frequenza della CPU / cicli_per_frame

Vantaggi:

• Precisione molto elevata (accuratezza a livello di ciclo)
• Ideale per l’analisi e l’ottimizzazione delle prestazioni
• Non è influenzato dagli interrupt di SysTick o dal jitter di programmazione.

Svantaggi:

• Richiede una frequenza di clock della CPU nota e stabile
• Non disponibile su tutti i core Cortex-M (es. M0/M0+)
• Leggermente più complesso da configurare e utilizzare
• L’overflow del contatore deve essere considerato nelle misurazioni più lunghe

Monitoraggio delle prestazioni LVGL (LV_USE_PERF_MONITOR)

LVGL offre un modo integrato per monitorare le prestazioni abilitando l’opzione LV_USE_PERF_MONITOR nella configurazione (lv_conf.h). Quando è abilitata, LVGL visualizza un piccolo overlay sullo schermo con le metriche in tempo reale.

In genere questo include:

• FPS (fotogrammi al secondo)
• Utilizzo della CPU (tempo speso in attività LVGL)
• a volte statistiche relative alla memoria (a seconda della configurazione)

Il monitor funziona internamente monitorando la frequenza con cui viene eseguito il ciclo di rendering e quanto tempo viene speso per elaborare le attività e disegnare.

Cosa misura:

• un mix di FPS di rendering e carico di sistema
• più vicini alle “prestazioni dell’interfaccia utente” che agli FPS grezzi del display

Perché è utile:

• configurazione zero-effort (basta abilitarla nella configurazione)
• feedback visivo immediato durante lo sviluppo
• Ideale per una rapida convalida delle prestazioni e per i controlli di regressione.

Limitazioni:

• non misura l’effettivo tempo di trasferimento del display (da schermo a schermo)
• L’FPS potrebbe non riflettere gli aggiornamenti a schermo intero quando si utilizza il ridisegno parziale
• aggiunge un leggero overhead (dovrebbe essere disabilitato in produzione)

In pratica, LV_USE_PERF_MONITOR è il modo più veloce per ottenere una comprensione approssimativa delle prestazioni del sistema, ma per misurazioni precise – soprattutto quando si ottimizza la larghezza di banda o i driver di visualizzazione – dovrebbe essere combinato con tempistiche di livello inferiore (ad esempio misurando le callback di flush).

LVGL offre un modo integrato per monitorare le prestazioni abilitando l’opzione LV_USE_PERF_MONITOR nella configurazione (lv_conf.h). Quando è abilitata, LVGL visualizza un piccolo overlay sullo schermo con le metriche in tempo reale.

In genere questo include:

• FPS (fotogrammi al secondo)
• Utilizzo della CPU (tempo speso in attività LVGL)
• a volte statistiche relative alla memoria (a seconda della configurazione)

Il monitor funziona internamente monitorando la frequenza con cui viene eseguito il ciclo di rendering e quanto tempo viene speso per elaborare le attività e disegnare.

Cosa misura:

• un mix di FPS di rendering e carico di sistema
• più vicini alle “prestazioni dell’interfaccia utente” che agli FPS grezzi del display

Perché è utile:

• configurazione zero-effort (basta abilitarla nella configurazione)
• feedback visivo immediato durante lo sviluppo
• Ideale per una rapida convalida delle prestazioni e per i controlli di regressione.

Limitazioni:

• non misura l’effettivo tempo di trasferimento del display (da schermo a schermo)
• L’FPS potrebbe non riflettere gli aggiornamenti a schermo intero quando si utilizza il ridisegno parziale
• aggiunge un leggero overhead (dovrebbe essere disabilitato in produzione)

In pratica, LV_USE_PERF_MONITOR è il modo più veloce per ottenere una comprensione approssimativa delle prestazioni del sistema, ma per misurazioni precise – soprattutto quando si ottimizza la larghezza di banda o i driver di visualizzazione – dovrebbe essere combinato con tempistiche di livello inferiore (ad esempio misurando le callback di flush).

MPU/Linux

Sui sistemi Linux, la misurazione degli FPS dipende dallo stack grafico.

Framebuffer semplice (fbdev)

Misura il tempo tra gli scambi di buffer:

Wayland / framework GUI

Le opzioni includono:

• strumenti integrati (ad esempio il contatore Weston FPS)
• tempistica a livello di app
• Strumenti di profilazione della GPU (se disponibili)

Conclusioni

Per misurare gli FPS nei sistemi embedded è necessario capire cosa rappresenta effettivamente un “frame” in una determinata pipeline. Che si misurino i loop di rendering, i callback di flush o gli scambi di buffer, ogni metodo riflette un aspetto diverso delle prestazioni. Framework come LVGL o stack basati su Linux forniscono utili agganci, ma spetta allo sviluppatore scegliere il giusto punto di misurazione.

In pratica, i soli FPS non sono sufficienti. La coerenza del frame time, la latenza e la larghezza di banda della memoria hanno spesso un impatto maggiore sulle prestazioni percepite. Un frame rate stabile e prevedibile è di solito più importante del raggiungimento del massimo FPS possibile.