Blog Post tecnici

4 librerie per GUI embedded a confronto

3 Marzo 2022 Luca Ottaviano · Tech Leader

Una delle decisioni che un responsabile del software deve prendere è quella dello stack software da usare. È una decisione importante perché richiede formazione del personale, eventuali investimenti in costi di licenze e aggiornamenti nelle procedure organizzative. Fatta una scelta, ogni tanto è bene rivalutarla alla luce delle novità emerse sul mercato.

In questa serie di articoli analizzerò le librerie GUI più promettenti e cercherò di capire quali sono le migliori per lo sviluppo di applicazioni embedded. Il mio focus principale sarà sui sistemi Linux embedded, perché rispetto ai sistemi a MCU supportano un maggior numero di casi d’uso. Le domande a cui vorrei rispondere sono:

Quali piattaforme sono supportate?
Quali linguaggi si usano per programmare la UI e il backend?
La libreria permette di personalizzare i font, le immagini e il layout degli oggetti a schermo?
Quali sono i requisiti minimi di hardware?
Quanto è matura la libreria?
Quanta documentazione ed esempi si trovano?

Le librerie che ho scelto di analizzare sono Qt, LVGL, Flutter e Slint.

Ho brevemente valutato anche altre librerie che sembravano interessanti in C#, C++, Go o Rust, ma le ho scartate per una serie di motivi: alcune erano di tipo immediate mode, altre erano troppo giovani o sperimentali, molte non avevano come target Linux embedded o MCU.

Il banco di prova per ciascuna libreria è stata una piccola applicazione orologio, con timer e lista di sveglie. La logica dell’applicazione è semplice, ma completa, e la grafica contiene tutte le caratteristiche necessarie per scrivere applicazioni 2D:

gestione della navigazione tra pagine
animazioni di oggetti
layout, rotazione e font personalizzati
liste di oggetti e data binding

La grafica e l’interazione sono state progettate da un mio collega designer e sono disponibili su Adobe XD, così come tutte le risorse (icone e font TTF). Questo mi ha permesso di simulare quanto più possibile una sessione di sviluppo reale.

Ho cominciato sviluppando l’applicazione per desktop, poi l’ho cross compilata su una Raspberry Pi 3B+ con display per capire la maturità del supporto su embedded.

Ecco alcuni screenshot per riferimento:

Schermata di visualizzazione dell’orario analogico

Qua usiamo rotazioni degli asset grafici (le lancette), leggiamo l’orario corrente dal backend, le icone in alto a destra sono informazioni su allarmi e durata del timer che arrivano anche esse dal backend

In questa schermata sfruttiamo il data binding con le informazioni che arrivano dal backend e dobbiamo poter interagire in scrittura sul backend per rimuovere le sveglie non più necessarie e per attivare o disattivare una sveglia.

Perché non valutare tecnologie web?

Ho scelto di proposito di non valutare tecnologie nate in ambito web, quindi HTML e Javascript, perché sebbene siano molto note, è anche improponibile usarle in ambito embedded. Bisogna tenere presente che ad oggi il prodotto medio ha una cpu single o dual core con 128 o 256 Mb di RAM, mentre una webview con una semplice applicazione caricata richiede dai 200 ai 300 Mb di RAM. È chiaro quindi che lo sforzo per mantenere sotto controllo l’occupazione di RAM del layer GUI è molto importante e questo va a scapito del resto del sistema.

Perché non immediate mode?

Tipicamente le UI immediate mode sono pensate per tutte quelle applicazioni, tipo i videogiochi, che disegnano costantemente lo schermo ad una frequenza fissa. Le UI per applicazioni embedded devono, al contrario, essere per quanto possibile parche di risorse perché non ce ne sono molte a disposizione. In questo caso le UI retained mode sono più indicate.

Perché non Android con il suo layer di UI?

Rispondere a questa domanda richiederebbe un articolo a parte. In sintesi, ritengo che sia più semplice partire da poco e prendere i pezzi che servono (il caso di Yocto) che partire da troppo e spegnere o disabilitare i pezzi che non servono (il caso di Android). La vostra esperienza potrebbe variare a seconda di quanto siete avvezzi con Yocto o con il sistema Android.

Perché non TouchGFX?

TouchGFX è una libreria grafica con editor UI integrato molto interessante. Purtroppo è presente solamente per processori STM, per cui non ho ritenuto interessante analizzarla.

Nei prossimi articoli vedremo quali sono i punti di forza e le debolezze di ciascuna delle librerie che ho menzionato, cominciando da Qt.