TouchGFX 4.25: il nuovo framebuffer emulato rende il sogno del “singolo chip” una realtà

TouchGFX 4.25 introduce il framebuffer emulato (in attesa di brevetto), che occupa molto meno spazio in memoria suddividendo l’immagine da visualizzare in parti e utilizzando una tecnica di mappatura della memoria che elimina la RAM grafica sul display stesso. Di conseguenza, i sistemi che prima richiedevano una RAM esterna possono ora funzionare su una scheda a chip singolo, riducendo così il costo dei materiali. Inoltre, poiché la ST ha integrato la tecnologia a livello di middleware, gli sviluppatori possono trarne vantaggio scegliendo l’opzione giusta nel TouchGFX Generator per vedere se ha senso per il loro progetto. Inoltre, costringe gli ingegneri a esaminare più da vicino la propria strategia di framebuffer per vedere se è adatta alla loro applicazione, cosa che spesso molti trascurano.

• Scarica TouchGFX 4.25

Cosa c’è di nuovo in TouchGFX 4.25?

Strategia del framebuffer

Doppio framebuffer

Troppo spesso gli sviluppatori non pensano a come l’immagine verrà renderizzata sul display. Tuttavia, questo può essere un errore costoso perché il tipo di framebuffer influisce pesantemente sulla configurazione della memoria. Ad esempio, un framebuffer doppio memorizza due framebuffer a grandezza naturale per garantire un’esperienza fluida e senza strappi. Tuttavia, un’immagine standard a 24 bit 1024×600 per un display da 10 pollici richiederebbe quasi quattro megabyte di memoria, una quantità normalmente inconcepibile per un sistema dalle risorse limitate. Ecco perché un framebuffer doppio avrebbe senso solo se si tiene conto di display di grandi dimensioni e interfacce grafiche di alto livello, dove il sistema utilizza naturalmente molta RAM esterna.

Framebuffer singolo

Il compromesso sarebbe quello di utilizzare un solo framebuffer completo. L’ovvio vantaggio è che riduce della metà l’ingombro della memoria. Il rischio di tearing è maggiore perché il display potrebbe aggiornarsi nel bel mezzo di un aggiornamento, ma è anche possibile mitigare questo problema. Ad esempio, gli sviluppatori possono limitare la complessità delle animazioni create o assicurarsi che il display si aggiorni meno frequentemente e utilizzare l’accelerazione DMA2D (Chrom-ART su STM32) per ottimizzare la gestione dei dati. Questo è ciò che spesso troviamo nella grafica di medio livello dei sistemi embedded. Lo schermo è piccolo e i requisiti dell’interfaccia utente non sono così impegnativi, il che consente di utilizzare un singolo frame buffer senza il rischio di tearing.

Framebuffer parziale

Allo stesso modo, un’altra opzione è quella di utilizzare un framebuffer parziale, che abbiamo introdotto in TouchGFX 4.12 (ne parleremo più avanti). Come suggerisce il nome, la memoria memorizza solo le parti del framebuffer che devono essere aggiornate, riducendo ulteriormente l’ingombro della memoria. Tuttavia, questa tecnica richiede che il display abbia una RAM grafica (o GRAM) in grado di memorizzare l’intero framebuffer. Il motivo è che quando è il momento di renderizzare l’immagine, il display avrà bisogno dell’intero framebuffer. Quindi, sebbene sia possibile ridurre la quantità di RAM incorporata necessaria utilizzando solo un framebuffer parziale, era impossibile evitare che il display avesse bisogno dell’intero framebuffer nella sua GRAM.

Framebuffer emulato

Oggi TouchGFX 4.25 inaugura i framebuffer emulati che funzionano in modo simile ai framebuffer parziali ma non richiedono GRAM. Il framework grafico della ST utilizza l’LTDC (LCD-TFT Display Controller) e l’unità di gestione della memoria grafica dell’IP Chrom-GRC presente in alcuni MCU, come l’STM32H7R/S, l’STM332H7A/B, l’STM32U5 e il nuovo STM32N6. I framebuffer emulati sono quindi possibili perché sfruttano alcuni degli ultimi IP presenti nei dispositivi STM32. Inoltre, TouchGFX implementa i framebuffer emulati a livello di middleware senza che gli utenti debbano scegliere se utilizzarli o meno nel TouchGFX Generator.

Un nuovo sistema di gestione della memoria

In poche parole, TouchGFX utilizza l’unità di gestione della memoria per emulare un intero framebuffer senza doverne memorizzare uno in memoria, mappando gli indirizzi di memoria. In questo modo, quando il sistema cerca il framebuffer, la MMU sa cosa inviare. E poiché questo ricorda un framebuffer parziale, gli sviluppatori suddividono il display in sezioni uguali, come la quarta o l’ottava, per ottimizzare l’aggiornamento dell’interfaccia utente. Più piccola è la sezione, maggiore è la granularità di cui possono godere i team, ma maggiore sarà l’intensità di calcolo dell’operazione. I programmatori dovranno quindi trovare il giusto compromesso a seconda della porzione di schermo da aggiornare.

Parlare con il display e ascoltare ciò che ha da dire

Dall’altra parte, l’LTDC della ST legge costantemente i dati dei pixel scritti dalla MMU e invia il framebuffer emulato al display utilizzando interfacce come Parallel RGB o MIPI DSI. Pertanto, se il sistema non riesce ad aggiornare l’intero schermo ogni 16 millisecondi, l’immagine mostrerà un notevole tearing. È fondamentale, tuttavia, considerare questo aspetto come un vantaggio. I framebuffer emulati sono indicati solo per le interfacce utente più statiche. Quando è il caso, questa strategia offre un risparmio di memoria tale da poter eliminare la RAM esterna e utilizzare solo la memoria dell’MCU. Ad esempio, i display a 720p o 1080p con interfacce utente ricche che tradizionalmente richiederebbero un microprocessore possono ora essere facilmente eseguiti su un MCU grazie al nostro framebuffer emulato.

Infatti, se le animazioni sono poche, come nel caso delle applicazioni che si concentrano su informazioni rapide, come gli aggiornamenti di stato, non c’è motivo di avere un intero framebuffer sempre in memoria. In questi casi, il framebuffer emulato offre un uso molto più efficiente della memoria, consentendo di utilizzare una MCU e molta meno RAM. Di conseguenza, se gli sviluppatori riscontrano il tearing, dovrebbero considerarlo come un messaggio del framework che indica loro di rimuovere le animazioni o di utilizzare una strategia di framebuffer diversa (vedi la nostra documentazione sulle strategie di framebuffer). E poiché tutte le strategie sono disponibili come opzione nel TouchGFX Generator, è molto facile passare da una all’altra.

Applicazioni nel mondo reale

Poco più di cinque anni dopo il lancio dei framebuffer parziali da parte di TouchGFX 4.12, i nostri team ci riprovano con i framebuffer emulati, un’opzione ancora più ottimizzata che apre le porte ai progetti a chip singolo. La soluzione riflette il modo in cui TouchGFX utilizza gli IP presenti nei dispositivi STM32 per ottimizzare l’uso della memoria e incidere direttamente sulla distinta base. Ciò significa anche che le interfacce utente stanno diventando sempre più accessibili: i progetti che non potevano adottarle a causa del costo di un modulo RAM esterno possono ora offrire una GUI. Il modo migliore per capire quale strategia di framebuffer funziona è sperimentare l’uso di framebuffer emulati su una piattaforma di sviluppo compatibile, come l’STM32H7S78-DK, e vedere se un’applicazione funziona senza problemi.

Nei nostri test interni, abbiamo eseguito una prova di concetto sulla scheda di sviluppo di cui sopra utilizzando solo la RAM interna e abbiamo ottenuto ottimi risultati a 800×400. L’unico caso in cui abbiamo riscontrato un tearing dello schermo è stato quando abbiamo eseguito le rappresentazioni delle statistiche dal vivo. Condividiamo questo dato per aiutare la nostra comunità a capire che non tutte le demo funzionano bene su un framebuffer emulato. Tuttavia, quelle che lo faranno apriranno le porte a sistemi embedded più efficienti e convenienti. Ad esempio, lo screenshot a destra mostra l’interfaccia utente di un ascensore che gira su un display a 720p e un STM32H7, utilizzando solo la RAM integrata, cosa che sarebbe stata impossibile prima dei framebuffer emulati.

Nuova compressione e supporto

TouchGFX 4.25 introduce anche la compressione dei font bitmap per ridurre l’ingombro in memoria dell’interfaccia utente. Questa funzione serve come alternativa ai font vettoriali quando un sistema deve usare i bitmap per motivi di prestazioni. Nelle applicazioni reali, la nuova compressione riduce l’ingombro dei font bitmap dal 20% all’80%. Ad esempio, un font con molti caratteri cinesi può vedere una riduzione delle dimensioni del 40%, mentre un font molto grande, come Verdana in 110 punti, ma con un numero ridotto di caratteri, può passare da circa 40 KB a soli 8 KB in memoria.

La nuova versione di TouchGFX aggiunge anche il supporto a CMake e iAR 9 per ottimizzare i flussi di lavoro. CMake è una suite di strumenti open-source che consente agli sviluppatori di costruire, testare e pacchettizzare il proprio software. Per questo motivo, aiuta gli ingegneri a portare i loro progetti su più piattaforme e a condividerli con i membri del team per semplificare le operazioni di sviluppo.

Che cos’è TouchGFX?

La struttura

TouchGFX è il framework gratuito della ST che aiuta a creare interfacce grafiche sui microcontrollori STM32. Scritto in C++, il motore sfrutta le ottimizzazioni dei dispositivi ST. TouchGFX parte dal presupposto che le interfacce sono costituite da schermate che gli utenti navigano. Per questo motivo, il framework è intuitivo e riflette le esperienze degli utenti. È anche completo, in quanto gestisce oggetti 2D e 3D, video, animazioni, transizioni, ecc. Inoltre, la possibilità di accedere al codice generato permette agli ingegneri esperti di ottimizzarlo. Per aiutarli in questo processo, la Documentazione di TouchGFX fornisce informazioni sulle API del framework o sugli strumenti di sviluppo disponibili.

Designer TouchGFX

TouchGFX Designer è spesso il primo strumento che gli sviluppatori utilizzano quando iniziano a creare la loro interfaccia utente. Si tratta di un’utility con un approccio WYSIWYG in cui i designer creano ciò che gli utenti vedranno e con cui interagiranno. Gli sviluppatori possono iniziare con progetti di esempio, come un orologio, un indicatore o un’immagine animata. Ci sono anche demo più complete, come un’animazione di dadi, transizioni di scene o un sistema di monitoraggio della piscina. Una schermata di avvio aiuta a scegliere l’applicazione demo, una scheda di sviluppo ST e a configurare il tutto. L’esecuzione di codici di esempio e di demo richiede pochi minuti e quindi la creazione di proof-of-concept è più rapida. Gli elementi dell’interfaccia utente di TouchGFX Designer assumono spesso la forma di widget che si aggiungono e si configurano attraverso l’interfaccia dell’utility.

TouchGFX Designer è parte integrante dell’ecosistema TouchGFX. Ad esempio, se gli utenti scelgono un modello 3.0, è possibile iniziare il progetto in Designer, poi portarlo in STM32CubeMX, impostare la scheda Discovery o MCU e lasciare che TouchGFX Generator (vedi sotto) aggiorni il file .IOC per applicare immediatamente le nuove impostazioni. Allo stesso modo, uno sviluppatore può iniziare con TouchGFX Generator, passare a TouchGFX Designer e poi tornare a STM32CubeMX per modificare la risoluzione del display. Il sistema aggiornerà automaticamente TouchGFX Designer senza dover chiudere l’applicazione.

Simulatore TouchGFX

TouchGFX Simulator aiuta gli sviluppatori a visualizzare in anteprima la loro interfaccia grafica prima di eseguirla sulla loro MCU. Parte del suo fascino è che offre scorciatoie da tastiera per semplificare i flussi di lavoro. Ad esempio, è più facile fare vari screenshot e studiare le animazioni fotogramma per fotogramma. Allo stesso modo, premendo F2 si evidenziano le aree invalidate, cioè le sezioni del fotogramma che il sistema deve aggiornare. Di conseguenza, gli sviluppatori possono verificare se le loro animazioni sprecano risorse della MCU invalidando inutilmente le risorse.

Generatore TouchGFX

TouchGFX Generator lavora con STM32CubeMX per generare una parte significativa del livello di astrazione TouchGFX. Supportiamo quasi tutti i Discovery Kit STM32 con display e il nuovo plugin funziona con qualsiasi MCU STM32 con Cortex-M0+, M4 o M7. Gli sviluppatori devono ancora riempire alcuni spazi vuoti con il loro codice utente ed eseguire ottimizzazioni, ma questo nuovo plugin rende l’avvio di un progetto molto più semplice. Infatti, Generator crea delle funzioni vuote per guidare gli sviluppatori e facilitare l’inizializzazione della scheda. Ci sono anche delle configurazioni predefinite per le schede di sviluppo ST per accelerare lo sviluppo e servire da esempio.

Quali sono le funzioni già presenti in TouchGFX?

Ottimizzazioni vettoriali

La maggior parte delle interfacce statiche dei microcontrollori utilizza le bitmap perché richiedono una bassa potenza di calcolo. Le immagini vettoriali, invece, sono meno comuni perché richiedono molta più potenza di calcolo. La sfida è che i vettori sono essenziali per le animazioni. Di conseguenza, gli sviluppatori possono scegliere di utilizzare più risorse per ottenere un numero maggiore di fotogrammi al secondo o di utilizzare meno energia e avere un’animazione meno fluida. Per affrontare questo problema, TouchGFX offre ottimizzazioni significative nell’elaborazione della grafica vettoriale, con un aumento dell’efficienza fino al 70% in alcuni casi. Gli sviluppatori possono quindi offrire animazioni più fluide su MCU più piccole o utilizzare un maggior numero di elementi vettoriali. Tuttavia, gli sviluppatori otterranno i guadagni di prestazioni più significativi con le animazioni più estese.

La nuova ottimizzazione utilizza Chrom-ART per scaricare il microcontrollore durante alcune operazioni come i riempimenti di colore. ST ha anche aggiornato il modo in cui il framework calcola i bordi di una forma. Inoltre, poiché gli aggiornamenti riguardano la gestione della grafica vettoriale da parte del framework, gli utenti ne beneficiano automaticamente. Gli sviluppatori noteranno quindi immediatamente un aumento delle prestazioni e potranno pianificare di conseguenza. Alcuni potrebbero ridurre i requisiti di memoria delle loro applicazioni o aggiungere nuove animazioni alla loro interfaccia. I team potrebbero anche dover rivedere la loro interfaccia utente perché alcuni elementi potrebbero girare più velocemente del previsto.

Font vettoriali

È paradossale che il testo, pur essendo una parte importante della maggior parte delle UI, possa essere uno degli aspetti più trascurati. Ad esempio, molti non conoscono nemmeno la differenza tra un font e un carattere tipografico e sì, come dimostreremo, la differenza è importante. Helvetica o Avenir sono spesso chiamati font ma sono caratteri tipografici. In poche parole, un carattere tipografico è il linguaggio di design che dà forma a un insieme di lettere, numeri e icone. Un font è il sottoinsieme di un carattere tipografico caratterizzato, tra le altre cose, da peso e dimensioni. Quindi, mentre l’Helvetica è un carattere tipografico, l’Helvetica a 12 punti è un font. Allo stesso modo, l’Helvetica Bold a 12 punti è un font diverso dall’Helvetica Light a 12 punti.

Perché è importante? Perché i sistemi embedded devono creare nuove bitmap per ogni font al momento della compilazione. A differenza dei PC che utilizzano font di contorno (chiamati anche font vettoriali), che contengono istruzioni su come disegnarli, i sistemi embedded utilizzano le bitmap. I font vettoriali sono ad alta intensità di calcolo, il che non è un problema su un PC, ma può portare le interfacce utente a uno stallo su un microcontrollore. Al contrario, le bitmap non hanno bisogno di essere calcolate perché sono già renderizzate, ma occupano molto più spazio in memoria perché ogni font deve essere renderizzato separatamente. Ad esempio, le bitmap di tre font (un carattere tipografico in tre dimensioni diverse) occuperebbero quasi 800 byte di memoria, mentre un file vettoriale ne richiederebbe meno di 200.

Il fatto che TouchGFX Designer sia diventato il primo toolkit UI a supportare i font vettoriali sulle MCU è quindi un enorme passo avanti per gli ingegneri che vogliono ridurre l’ingombro della flash. Grazie a questa funzione, un cliente della ST ha potuto utilizzare solo la flash interna dell’MCU, riducendo così in modo significativo la distinta dei materiali. È ancora più impressionante per i sistemi di scrittura logografici che spesso richiedono più bitmap di quelli alfabetici. Anche se i guadagni variano molto a seconda dell’applicazione, la volatilità intrinseca del mercato della memoria significa che molti sviluppatori cercano sempre di ridurre la loro dipendenza dai moduli flash esterni.

La capacità di supportare i font vettoriali è stata realizzata da molti anni. Ad esempio, sebbene molte delle nostre MCU STM32 le supportino tecnicamente, la capacità di accelerare il calcolo vettoriale con la nostra GPU NeoChrom significa che la STM32U5 e la nuova STM32H7R/S aprono le porte a prestazioni che rendono i font vettoriali praticabili. Ad esempio, mentre un STM32F7 può impiegare fino a 2,88 ms per renderizzare un font vettoriale, un STM32U5F9 ne impiega appena 0,80 ms. Allo stesso modo, anche le recenti ottimizzazioni vettoriali nelle versioni precedenti di TouchGFX hanno alleggerito il carico. Tuttavia, sappiamo anche che non tutte le interfacce utente possono trarre vantaggio dai font outline. Di certo non lo faranno i sistemi che fanno uso di animazioni. Pertanto, questa funzione è solo uno strumento in più nell’arsenale di un team.

Per aiutare gli utenti a determinare se i font vettoriali sono adatti a loro, abbiamo rilasciato la demo mostrata qui sopra che combina vettori e bitmap e ne abbiamo condiviso il codice sorgente. In effetti, i font vettoriali non sono l’unica opzione per risparmiare memoria. Ad esempio, il nostro sistema di compressione L8 può ridurre anche le bitmap. Ogni progetto avrà requisiti flash diversi e ogni interfaccia utente avrà esigenze di rendering particolari. Alcuni progetti devono fare i conti con la limitata capacità della flash esterna, altri cercano di utilizzare solo la flash interna e altri ancora vogliono semplicemente ridurre i tempi di programmazione. Tuttavia, sempre più spesso i clienti chiedono interfacce utente che utilizzino meno flash. Di conseguenza, i font vettoriali aprono potenzialmente la porta a interfacce che altrimenti non sarebbero state possibili.

Ottimizzazione della memoria

TouchGFX 4.24 apporta una serie di ottimizzazioni agli algoritmi di compressione e alle operazioni vettoriali per risparmiare più flash. Dopo la versione precedente, ST ha rilasciato la demo dell’eBike nel video qui sopra, che utilizza solo 355 KB di risorse invece di un set iniziale di bitmap per un totale di 10,5 MB. Concretamente, abbiamo lavorato per ottimizzare ulteriormente il nostro formato di compressione L8 e stiamo fornendo suggerimenti per aiutare gli sviluppatori a sfruttare al meglio le loro UI utilizzando meno flash. Ad esempio, i team ottengono una maggiore compressione sulle immagini che utilizzano colori codificati a 8 bit o meno. Inoltre, grazie a ChromART, TouchGFX può attingere alcune risorse direttamente dalla flash, riducendo così il consumo di RAM dell’applicazione.

Il framework ST ha anche apportato nuove ottimizzazioni all’implementazione dell’algoritmo di compressione QuiteOK Image (QOI), che aiuta a ridurre le dimensioni delle risorse grafiche in memoria. Il rapporto di compressione dipende da una miriade di fattori. In circostanze ottimali, possiamo ridurre senza perdite le dimensioni di un file del 95%. Tuttavia, poiché le operazioni di decompressione possono essere costose sulle CPU meno potenti, alcuni possono dare la priorità all’uso di bitmap ottimizzate e di trucchi come le immagini a piastrelle (un’immagine completa composta da copie di una piccola piastrella) per limitare l’uso della flash. Gli ingegneri sanno che non esistono soluzioni uniche per le interfacce utente nei sistemi embedded. Tuttavia, TouchGFX 4.24 apre ulteriormente le porte alla possibilità di eseguire interfacce senza utilizzare la flash esterna.

Formato di compressione L8

Le risorse grafiche occupano molto spazio in memoria e ridurre la loro qualità significa peggiorare l’interfaccia utente. L8 è quindi un formato di immagine essenziale perché può comprimere un file fino al 75% senza alcun declassamento, grazie all’acceleratore Chrom-ART dei microcontrollori STM32. Finché una risorsa utilizza un massimo di 256 colori, come spesso accade nei piccoli sistemi embedded con MCU STM32, gli sviluppatori possono comprimere una risorsa utilizzando il formato L8 semplicemente selezionando una casella in TouchGFX Designer. La decompressione è anche efficiente dal punto di vista computazionale perché utilizza il motore Chrom-ART per cercare i colori in una tabella e renderizzare l’asset senza perdere qualità.

Comprimere ulteriormente le immagini L8

TouchGFX Designer 4.22 ha introdotto una funzione fondamentale: la compressione delle immagini L8. Facendo clic su “Immagini” nella colonna di sinistra, vengono elencate le risorse grafiche attualmente caricate. Per tutte le immagini L8 è disponibile un nuovo menu a tendina “Compressione” che consente agli utenti di scegliere tra tre metodi: L4, LZW9 (Lempel-Ziv-Welch) e Run Length Encoding (RLE). Tutti e tre sono senza perdita: L4 e LZW9 creano tabelle di compressione che assegnano un colore a una voce, mentre RLE si limita a fattorizzare sequenze ripetute. Tutti hanno vantaggi e svantaggi, per questo offriamo anche un’opzione “Auto” che permette al compilatore di scegliere il metodo di compressione più ottimizzato in base alle nuove dimensioni del file e al suo tempo di rendering.

In media, gli utenti possono aspettarsi una riduzione delle dimensioni dei file compresa tra il 20% e l’80%. Il chilometraggio varia, ma è facile capire perché tanti utenti hanno richiesto questa funzione. Nella maggior parte dei casi, il rendering dell’immagine richiede il doppio del tempo. Tuttavia, poiché gli sviluppatori utilizzano questa funzione per le interfacce statiche, le icone o le risorse più piccole, l’impatto non è evidente perché il rendering richiede solo pochi millisecondi. Inoltre, in molti casi, le dimensioni drasticamente ridotte del file significano un tempo di recupero più breve dalla memoria, che compensa il tempo di rendering più lungo. In parole povere, l’ottimizzazione dell’archiviazione bilancia la penalizzazione della decompressione, offrendo così prestazioni identiche o quasi a quelle di un asset L8 non compresso e utilizzando meno memoria.

Se gli utenti stanno passando da una versione di TouchGFX Designer precedente alla 4.22, devono selezionare manualmente il metodo di compressione. I nostri team hanno mantenuto il formato non compresso come comportamento predefinito perché non volevamo che gli sviluppatori vedessero un cambiamento drastico nel modo in cui il framework gestiva le loro immagini L8 senza capirne il motivo. Ciononostante, riteniamo che questa funzione sia altamente simbolica in quanto comunica esplicitamente il nostro desiderio di ottimizzare l’ingombro della memoria, soprattutto nella flash, tenendo conto delle prestazioni.

Generatore di codici QR

I codici QR sono sempre più popolari perché. Ad esempio, permettono a un consumatore di scansionare un codice e vedere comparire automaticamente un numero di serie, facilitando così notevolmente il processo di registrazione. Allo stesso modo, inviare qualcuno a una particolare pagina di supporto sul sito web di un’azienda diventa molto più accessibile se nessuno deve digitare manualmente un URL. Inoltre, i produttori possono aggiornare il loro sito web senza preoccuparsi che gli utenti non trovino la pagina giusta. La sfida è che la generazione di un codice QR può richiedere grandi librerie esterne poco ottimizzate per i microcontrollori. Inoltre, passare gli argomenti per creare dinamicamente un codice e poi disegnarlo nel framebuffer è estremamente complesso da implementare da zero.

Ecco perché TouchGFX ha introdotto un generatore di codici QR. Può generare dinamicamente fino a un codice QR di livello 40 (177 moduli x 177 moduli) al volo e disegnarlo nel framebuffer. Invece di visualizzare un codice di errore, gli sviluppatori possono generare un codice QR che invia l’utente alla relativa pagina di supporto. Supportiamo anche la correzione degli errori per garantire l’integrità dei dati rappresentati, che può essere un problema significativo se l’interfaccia utente trasmette un numero di serie, ad esempio. Il codice QR facilita anche l’invio di simboli invece che di soli caratteri alfanumerici, il che è utile per alcune regioni.

Chiamate in diretta

La compressione delle immagini L8 è anche un esempio della necessità di comunicare meglio con i nostri utenti per informarli sulle nuove possibilità. TouchGFX riceve aggiornamenti frequenti. Tuttavia, i progettisti non sono sempre al corrente di ciò che accade. Abbiamo già campagne e-mail, questo blog e il sito web ST.com, tra le altre cose, ma molti ci chiedono ancora di stabilire una linea di comunicazione più diretta. Per rispondere alla loro richiesta, abbiamo lanciato i Live Callout, piccoli riquadri che appaiono solo nella parte inferiore della schermata della lobby per indirizzare gli utenti verso funzionalità, eventi o soluzioni di un partner. Cliccando su una chiamata in diretta si genera un popup con ulteriori dettagli o si apre una finestra del browser su ST.com.

Come suggerisce il nome, i Live Callout richiamano l’attenzione degli utenti su specifiche funzionalità o opportunità. Esistono solo nella lobby per evitare di distrarre gli sviluppatori mentre lavorano alla loro interfaccia. Le Live Callout sono anche diverse dalle notifiche che avvisano gli utenti solo di una nuova versione del framework o di un messaggio importante. Sono di natura meno sensibile, il che significa che gli sviluppatori non si sentiranno oppressi se non li vedranno subito. Inoltre, diamo priorità alla privacy dei nostri utenti. Personalizziamo i Live Callout per ogni regione, ma non raccogliamo i dati degli utenti. I dati relativi alla posizione rimangono sulle macchine locali e TouchGFX Designer decide cosa visualizzare in base alla posizione del sistema.

Modalità offline

TouchGFX 4.22 ha introdotto una nuova modalità offline, che consente agli utenti di scaricare demo ed esempi da eseguire senza una connessione a Internet. Inoltre, forniamo uno strumento di configurazione proxy più potente per soddisfare le configurazioni più complesse. In molti casi, una connessione online non è possibile o è difficile da ottenere. Alcuni utenti devono affrontare problemi che ostacolano il loro flusso di lavoro, sia in aereo che a causa di restrizioni di banda o firewall. Grazie alla nuova modalità offline e allo strumento di configurazione proxy, è più facile e pratico utilizzare TouchGFX Designer e godere di un flusso di lavoro più fluido.

Programmazione flash più veloce

TouchGFX Designer 4.23 ha acquisito la capacità di flashare il codice destinato solo alla flash interna, riducendo così notevolmente i tempi di programmazione. Prima di allora, infatti, quando si compilava un’interfaccia, TouchGFX caricava tutti gli asset, compresi quelli memorizzati nella memoria esterna, anche se non erano stati modificati. Di conseguenza, le operazioni di compilazione potevano richiedere quasi 10 minuti, anche se gli sviluppatori non avevano aggiornato nessuno degli asset memorizzati esternamente. Per ottimizzare i flussi di lavoro, TouchGFX Designer 4.23 include un’opzione per programmare solo la flash interna, riducendo così le operazioni di compilazione a pochi secondi. Tuttavia, gli sviluppatori devono fare attenzione al fatto che dimenticare di flashare la memoria esterna dopo aver modificato alcune delle risorse in essa memorizzate può interrompere un’applicazione.

Supporto per X-NUCLEO-GFX01M2 e X-NUCLEO-GFX02Z1

Quando gli ingegneri decidono di avere un’interfaccia grafica, il display diventa spesso il componente più costoso nella distinta base. Un semplice display da 2 pollici senza strato tattile migliorerà notevolmente l’esperienza dell’utente, ma è comunque più costoso di qualsiasi altra cosa. Trovare un display economico quando si punta a un BoM di cinque dollari o meno è quindi problematico. Di conseguenza, la ST sta distribuendo schede di espansione per display per aiutare gli ingegneri a trovare componenti economicamente vantaggiosi, e noi offriamo il supporto per l’hardware all’interno di TouchGFX Designer. Gli utenti scelgono la configurazione del display e possono iniziare a lavorare su un’interfaccia che corrisponde alle sue specifiche.

La prima scheda di espansione che gli ingegneri possono scegliere è la X-NUCLEO-GFX01M2. Utilizza un display QVGA (320 x 240) da 2,2 pollici SPI che supporta la flash SPI. e che si adatta a una distinta base di circa cinque dollari per un tipico sistema embedded con flash esterna e un PCB a due strati. X-NUCLEO-GFX01M2 è compatibile con un’ampia gamma di schede NUCLEO a 64 pin. Ad esempio, gli ingegneri possono utilizzarla sul NUCLEO-WB55RG per rendere più accessibili le applicazioni Bluetooth.

Allo stesso modo, X-NUCLEO-GFX02Z1 è la nostra prima scheda di espansione per display a supportare un’interfaccia parallela, una flash QSPI e schede Nucleo con 144 pin. La piattaforma si rivolge a microcontrollori con maggiore potenza, il che spiega la compatibilità con le interfacce che offrono una maggiore larghezza di banda. Gli sviluppatori possono utilizzare X-NUCLEO-GFX02Z1 con il NUCLEO-U575ZI-Q, uscito con i primi STM32U5. In questo modo gli ingegneri possono sfruttare il miglior rapporto prestazioni/watt della nuova MCU per creare interfacce utente che non erano possibili con le precedenti generazioni di STM32.

Incorporare video nelle interfacce utente

Il desiderio di inserire i video in un maggior numero di interfacce utente è una conseguenza naturale della crescente popolarità dei display nei sistemi embedded. Purtroppo, mostrare un video su un sistema embedded con un microcontrollore è una sfida. Non esiste un sistema operativo con un lettore multimediale e dei codec predefiniti. Allo stesso modo, scrivere una pagina web che mostri un video di YouTube è impossibile. Gli sviluppatori devono fare tutto il lavoro pesante, come implementare un buffer video, capire quale formato funziona meglio sul loro microcontrollore e determinare come sfruttare l’accelerazione hardware, se disponibile. TouchGFX Designer offre un widget video per risolvere questa sfida. Per questo motivo, l’aggiunta di un video ora richiede solo tre semplici passaggi.

Video direttamente al framebuffer

Un’altra caratteristica di TouchGFX 4.23 che mira a ridurre l’ingombro di memoria di un’applicazione è la possibilità di configurare automaticamente un sistema per scrivere direttamente sul framebuffer. Tradizionalmente, quando si visualizza un video, i fotogrammi vengono prima memorizzati in un buffer video prima di essere trasferiti al framebuffer che alimenterà il display. Questo passaggio intermedio assicura che tutte le risorse siano disponibili per garantire un’animazione fluida. Il problema è che richiede molta più memoria perché i fotogrammi video devono risiedere in questa cache prima di passare al framebuffer.

TouchGFX ha supportato per un po’ di tempo la scrittura di fotogrammi video direttamente nel framebuffer per il rendering software puro. Tuttavia, cercare di utilizzare il decodificatore MJPEG hardware e l’acceleratore Chrom-ART richiedeva un’implementazione manuale ed estremamente complessa, in quanto gli sviluppatori dovevano modificare le sincronizzazioni e i driver di basso livello. Di conseguenza, questa funzione era fuori dalla portata di molti a causa delle competenze necessarie per implementarla. TouchGFX 4.23 risolve questo problema offrendo la possibilità di inizializzare automaticamente un microcontrollore per scrivere i fotogrammi video direttamente nel framebuffer utilizzando il motore MJPEG e l’IP Chrom-ART. A partire da TouchGFX 4.23, questo è diventato il nuovo comportamento predefinito, garantendo così che il widget video richieda molta meno memoria per funzionare.

Esportazione di contenitori personalizzati

Nella sua forma più semplicistica, TouchGFX Designer si basa sui widget, una rappresentazione di un elemento disegnato sullo schermo. Il software viene fornito con molti widget predefiniti, come un indicatore, un orologio o un grafico, e gli sviluppatori possono anche progettarne di personalizzati. Per rendere i widget più semplici, i designer possono raggrupparli all’interno di un contenitore. I contenitori sono spesso gli elementi costitutivi di un’interfaccia. Permettono ai programmatori di riutilizzare una serie di widget su più schermate senza doverli riconfigurare ogni volta. Inoltre, la modifica di un contenitore ha un impatto su tutte le schermate che lo utilizzano, semplificando notevolmente lo sviluppo. TouchGFX dispone anche di contenitori predefiniti per velocizzare le operazioni di progettazione più comuni e gli sviluppatori possono creare contenitori personalizzati.

I contenitori personalizzati sono molto popolari perché permettono agli sviluppatori di modificare la loro interfaccia e di dare forma a una visione precisa. Tuttavia, la sfida insita in ogni strumento di progettazione è che il lavoro svolto su un progetto raramente può essere esportato su un’altra interfaccia utente. Infatti, un contenitore personalizzato include codice, risorse grafiche, testi, dipendenze e molto altro che lo lega al progetto esistente. Dalla versione 4.20, TouchGFX Designer ha risolto questo problema offrendo una funzione di esportazione che crea un bundle (file .tpkg) riutilizzabile in altri progetti. L’utility aggiungerà tutte le risorse, compresi i font, al bundle e un file XML ne elencherà il contenuto. Gli sviluppatori possono quindi controllare e modificare tale file per selezionare ciò che desiderano esportare.

Importare contenitori personalizzati

Per importare un contenitore personalizzato, gli utenti devono selezionare Modifica -> Importazione -> Contenitore personalizzato. TouchGFX include una nuova utility di importazione che guida gli utenti attraverso il processo. Ad esempio, il software rileva le lingue definite dal contenitore personalizzato e le abbina a quelle disponibili nel nuovo progetto oppure le ignora. Il sistema arresta anche il processo di importazione se c’è un conflitto tra nomi generici o se un problema potrebbe causare problemi all’interno della nuova interfaccia. TouchGFX Designer obbliga gli utenti a risolvere i problemi nel contenitore personalizzato originale, invece di creare soluzioni durante il processo di importazione. Poiché lo scopo di questa funzione è quello di preservare l’aspetto e l’atmosfera delle interfacce tra i vari prodotti, la forzatura delle modifiche all’interno del progetto originale garantisce la coerenza tra le UI.

CacheableContainers

Come dice il nome, utilizza una cache di bitmap per accelerare le prestazioni grafiche e consentire un frame rate più elevato per transizioni più fluide. La demo qui sotto viene eseguita su un kit STM32F429I Discovery. Senza CacheableContainers, la semplice animazione a tutto schermo (240 × 320) viene eseguita a nove fotogrammi al secondo. Con la tecnologia TouchGFX, il sistema raggiunge i 60 fotogrammi al secondo. Alcuni smartwatch utilizzano questa funzione per garantire un’esperienza d’uso fluida nonostante le notevoli limitazioni hardware inerenti al loro fattore di forma e la necessità di una maggiore durata della batteria. Oltre alle animazioni, CacheableContainers può ottimizzare widget complessi, come i texture mapper o piccoli elementi dinamici visualizzati su uno sfondo statico.

Senza i CacheableContainer, un’animazione deve essere ridisegnata ad ogni fotogramma, il che può diventare costoso dal punto di vista computazionale. CacheableContainer aggira questo problema memorizzando il primo e l’ultimo fotogramma in un contenitore separato come una bitmap che il sistema conserva nella RAM. Invece di renderizzare l’animazione, il sistema recupera le due immagini dalla memoria utilizzando il DMA e le mostra in punti diversi grazie a un semplice metodo DynamicBitmap. L’MCU non genera più ogni fotogramma, ottimizzando così in modo significativo le prestazioni. Gli sviluppatori devono solo spuntare la casella Cacheable nel TouchGFX Designer, selezionare la posizione in memoria dei contenitori che vogliono memorizzare e richiamarli quando necessario. Questa tecnica riduce il tempo di rendering da 100 ms a 5 ms.

Framebuffer parziale

Un framebuffer è uno spazio di memoria contiguo che memorizza una rappresentazione di ogni pixel che verrà visualizzato sul display. Ad esempio, un’immagine standard a 24 bit 390 x 390 per il display di uno smartwatch richiede un framebuffer di 3.650.400 bit o 456,3 KB(latex\div8[/latex]), ovvero più del 70% della SRAM disponibile sull’STM32L4+ che eccelle negli smartwatch e nei wearable. E questo numero può esplodere se un’applicazione richiede più di un framebuffer. Oltre ai limiti di capacità, un framebuffer di grandi dimensioni richiede più tempo per essere recuperato, in quanto i dati devono viaggiare dalla memoria al display, rallentando le prestazioni.

Come indica il nome, Partial Framebuffer memorizza solo una parte del framebuffer, riducendo così l’ingombro in memoria di 10 unità. Gli sviluppatori possono configurare le sue dimensioni in base alla sezione dello schermo che cambierà e quindi memorizzare più buffer parziali. Il framework sceglierà poi quello appropriato e lo invierà al display. Questa tecnologia funziona meglio con animazioni brevi, come orologi, barre di caricamento o grafici che si sviluppano nel tempo. Inoltre, richiede che lo schermo utilizzi un controller incorporato in quanto riceverà direttamente il framebuffer parziale dalla RAM dell’MCU, bypassando così la flash per aumentare le prestazioni. Questa tecnologia funziona su schermi paralleli / 8080, DSI e SPI.

TouchGFX ottimizza anche il framebuffer parziale per portare le interfacce grafiche sui microcontrollori con risorse limitate. Tradizionalmente, un’interfaccia grafica minima richiederebbe un framebuffer di circa 200 KB. Tuttavia, quando un microcontrollore come l’STM32G071 ha solo 36 KB di RAM, può essere un vero problema. TouchGFX risolve questo problema ottimizzando il framebuffer parziale a soli sei kilobyte. Tenendo conto dei dati dell’applicazione del framework, un’interfaccia utente entry-level avrebbe bisogno di soli 16 KB di RAM per funzionare. TouchGFX utilizza anche aggiornamenti parziali intelligenti dello schermo. Questa funzionalità integra il framebuffering parziale per ottimizzare l’ordine degli aggiornamenti sullo schermo. Il processo consente di risparmiare risorse, permettendo così un maggior numero di aggiornamenti nello stesso periodo.

Supporto per la grafica vettoriale scalabile (SVG)

TouchGFX 4.21 ha inaugurato il supporto per SVG. Tradizionalmente, il framework memorizza immagini raster, come i file PNG, perché sono facili da accedere e da visualizzare. Al contrario, i file SVG non includono un rendering ma istruzioni su come disegnarli. Questo li rende altamente scalabili ma decisamente più impegnativi. E se su un laptop o un desktop non è un problema, su un microcontrollore a basso consumo è tutta un’altra storia. Il problema è che i designer creano sempre più spesso interfacce animate e cercano di scalare un’interfaccia utente su display di dimensioni diverse. Di conseguenza, i team desiderano utilizzare i file SVG per risparmiare risorse, poiché un unico file può essere disegnato in molti modi diversi e occupa meno spazio in memoria.

La ST utilizza il suo nuovo acceleratore NeoChrom 2.5D, disponibile su alcuni STM32U5, per affrontare questa nuova sfida. L’ottimizzazione hardware delle animazioni di disegno scarica alcuni dei calcoli associati ai file SVG, risolvendo così il problema delle prestazioni. L’IP si affida anche a interfacce di memoria più veloci, velocizzando le operazioni di fetching, e il file è spesso più piccolo. Di conseguenza, l’archiviazione dei file nella memoria esterna è meno penalizzante. In definitiva, l’annuncio è altamente simbolico perché SVG non era nell’elenco delle funzionalità quando abbiamo parlato di NeoChrom nel maggio 2022. Tuttavia, il rilascio di oggi dimostra che l’IP ha molte potenzialità e la ST continuerà a rilasciare nuove funzionalità che sfruttano le sue capacità.

File XML per il testo

I team di progettazione spesso archiviano il testo in un file Excel per lavorare con diversi traduttori in tutto il mondo. Tuttavia, invece di utilizzare i sistemi di controllo delle versioni, come Git, i redattori devono gestire manualmente le modifiche e assicurarsi che nessuno sovrascriva inavvertitamente il lavoro di qualcun altro, il che può risultare complicato. Per risolvere questo problema, TouchGFX memorizza tutto il testo in un file XML. Il formato rende molto più semplici le operazioni di fusione e la risoluzione dei conflitti. TouchGFX include anche un convertitore da XML a Excel per adattarsi ai flussi di lavoro esistenti. Gli sviluppatori possono esportare in Excel e poi importare il file Excel in TouchGFX e nel suo formato XML.

File di progetto ottimizzati

TouchGFX favorisce anche la collaborazione grazie ai piccoli file di progetto. La loro dimensione li rende più facili da unire e potenzialmente da condividere. In precedenza, i file di progetto memorizzavano tutti i parametri in un formato JSON. Il problema è che un file di questo tipo può diventare molto grande. ST ha quindi deciso di ottimizzare i file di progetto memorizzando solo le impostazioni personalizzate. Pertanto, tutto ciò che non è presente nel file viene considerato come un valore predefinito. Di conseguenza, il file è molto più piccolo, rendendo le operazioni di fusione su Git molto più semplici e veloci.

Testo a uso singolo e ID casuale

Gli sviluppatori che desiderano utilizzare il testo devono creare una risorsa nel pannello del testo di TouchGFX Designer e poi utilizzare l’ID del testo nell’interfaccia utente. Tuttavia, TouchGFX consente anche il “testo monouso”, che non appare come una tipica risorsa di testo. Gli sviluppatori lo usano durante i test o se un testo non è importante. Evita di riempire il database con testi irrilevanti e aiuta a prototipare più velocemente. Infatti, la funzione di testo monouso genera automaticamente un ID e cancella la risorsa dal database se viene eliminata dall’interfaccia utente, a differenza delle normali risorse di testo. TouchGFX utilizza anche un generatore di stringhe casuali per la creazione dell’ID. Di conseguenza, è quasi impossibile che due ID di testo monouso nello stesso progetto siano identici.

Azioni TouchGFX

Libreria di immagini gratuita

TouchGFX Stock è la più grande libreria di risorse grafiche gratuite per interfacce utente fornita da un framework destinato ai microcontrollori. Include icone, elementi GUI, temi, immagini e molto altro. Poiché le icone provengono dalla libreria gratuita di Google e la ST detiene i diritti di tutte le altre risorse, TouchGFX Stock dispone di una generosa licenza che consente ai team di utilizzare gratuitamente le risorse, anche per progetti commerciali, purché funzionino su dispositivi STM32. Gli utenti possono prendere le risorse per ridimensionarle per la loro interfaccia o modificarle per adattarle alle loro esigenze specifiche. La licenza copre anche l’utilizzo di queste risorse con un altro framework grafico, purché il programma venga eseguito su un microcontrollore ST.

Recentemente, molte startup hanno riutilizzato i segnaposto o gli esempi di TouchGFX nel loro design. Questa nuova tendenza deriva dalla proliferazione di piccoli team che non hanno le risorse per investire in designer. Di conseguenza, quando adottano TouchGFX, alcuni sviluppatori trovano eleganti i segnaposto e li aggiungono alle loro interfacce finali. Ecco perché abbiamo deciso di investire in TouchGFX Stock e siamo diventati il fornitore di MCU con la più ampia libreria di risorse grafiche libere da royalty. Questo spiega anche il nostro approccio alle licenze. Nel corso degli anni ci siamo impegnati per rendere più accessibili le interfacce grafiche delle MCU. Questa è un’altra pietra sulla cima di questo edificio e ci impegniamo a far crescere questa libreria nel tempo con nuovi temi, immagini e altro ancora.

Un designer gratuito al tuo servizio

Nel frattempo, TouchGFX Stock è dotato di elementi UI come barre, popup, orologi, indicatori e molto altro ancora. Forniamo anche versioni chiare e scure di alcuni elementi. In definitiva, TouchGFX 4.21 è una lezione di design. Gli ingegneri non devono preoccuparsi di sbagliare le palette di colori o di affidarsi a nozioni di design antiquate. Forniamo set per mantenere le UI coese e moderne. Inoltre, offriamo varie dimensioni per adattarsi alla maggior parte degli schermi, in modo che molti non abbiano bisogno di ridimensionarsi da soli. TouchGFX Stock viene fornito con cinque temi al momento del lancio. Tuttavia, il cambio di tema non è automatico a causa della natura delle interfacce grafiche degli MCU. Poiché non c’è una relazione uno-a-uno con tutti gli asset, gli utenti devono sostituirli manualmente.

Animazioni e widget

Transizioni a scorrimento e grafici dinamici

La sfida per gli sviluppatori è quella di sfruttare tutte le funzionalità che continuiamo ad aggiungere a TouchGFX. Per questo motivo, offriamo animazioni ottimizzate che utilizzano già le funzioni di cui sopra. Ad esempio, mentre una transizione tradizionale richiede un aggiornamento dell’intero schermo, l’animazione wipe di TouchGFX utilizza molte meno risorse. Allo stesso modo, il widget del grafico dinamico mostra meglio i dati sequenziali con un minore impatto sulla RAM e sul microcontrollore.

Grafici statici

Quando i wearable tracciano dati ambientali o fisici, gli utenti vogliono vedere i progressi. I grafici possono tracciare la frequenza cardiaca, la temperatura, i passi percorsi e altro ancora. Gli sviluppatori di TouchGFX hanno chiesto per la prima volta dei grafici dinamici, che possono essere difficili da implementare, e questa funzione è disponibile dalla versione 4.15 di TouchGFX. Ora i nostri team stanno rilasciando grafici statici per soddisfare le nuove applicazioni. Infatti, i dati che non hanno bisogno di evolversi costantemente o che conoscono solo lievi variazioni nel tempo si adattano meglio a una rappresentazione statica. I nuovi grafici funzionano in modo leggermente diverso. In quelli dinamici gli sviluppatori devono inviare un solo punto di dati, poiché l’intervallo di tempo è costante. Per quelli statici, invece, i programmatori devono inserire le informazioni per gli assi X e Y.

Orologi e Texture Mapper

TouchGFX dispone anche di widget che imitano applicazioni come orologi analogici e digitali. C’è anche un texture mapper, il che significa che gli sviluppatori possono iniziare a creare il loro programma di mappatura con un semplice drag and drop. Dovranno comunque inserire il codice C++, ma l’intero processo sarà molto più fluido. Texture Mapper è anche un ottimo esempio di ottimizzazione di TouchGFX su MCU con risorse limitate. Può aiutare ad animare gli oggetti e funziona anche su un STM32G0, a patto che la risorsa grafica si trovi nella RAM e non nella flash.

Calibro

Il modello di indicatore disegna un ago e un arco per aiutare gli utenti a monitorare i valori. Gli sviluppatori possono anche modificare lo sfondo, l’orientamento dell’ago, l’intervallo di valori e altro ancora. La demo qui sotto mostra come i programmatori possono passare dall’IDE al TouchGFX Designer per un flusso di lavoro più fluido. I team possono controllare rapidamente l’indicatore, modificarlo al volo e testare il loro codice istantaneamente. Ad esempio, il video mostra come la funzione handleTickEvent() controlla il comportamento dell’indicatore. Con pochissime righe di codice, gli sviluppatori possono modificare l’intervallo di valori e la frequenza di aggiornamento dell’indicatore, tra le altre cose. Queste ottimizzazioni possono far risparmiare molte risorse nelle applicazioni che non hanno bisogno di rinnovare costantemente il valore visualizzato.

Gestione avanzata del testo

Il testo è essenziale per la maggior parte delle interfacce grafiche, il che spiega perché i designer ci lavorano così tanto. Lo personalizzano, lo traducono e lo modellano. Alcune applicazioni create con TouchGFX Designers possono avere migliaia di risorse di testo, ognuna tradotta in molte lingue. Il problema è che lavorare con il testo può essere complicato. Per questo motivo, per ridurre l’attrito, TouchGFX offre ora dei gruppi che gli sviluppatori possono definire in base a una sezione o a una caratteristica delle loro applicazioni. La nuova funzione rende più semplice mostrare il testo tradotto fianco a fianco in TouchGFX Designer. Inoltre, aiuta a raggruppare le informazioni rilevanti per verificarne la coerenza e l’accuratezza. Infine, i gruppi rendono più veloce la ricerca e il reperimento di risorse specifiche.

TouchGFX Designer include anche un’opzione Typographies per impostare i parametri predefiniti all’interno dei gruppi. La sezione consente agli utenti di scegliere le specifiche dei font, i caratteri di fallback, i caratteri jolly, l’allineamento, ecc. In precedenza, gli sviluppatori dovevano sovrascrivere i parametri per ogni risorsa di testo, il che poteva richiedere molto lavoro. Grazie ai gruppi, è possibile impostare simultaneamente i parametri per molte risorse, ottimizzando così notevolmente gli sviluppi. I progetti esistenti con tipografie personalizzate vedranno le loro impostazioni spostarsi nella nuova sezione. La nuova interfaccia di testo visualizza anche i testi monouso e consente di promuoverli in una risorsa, se necessario.

• Scarica TouchGFX 4.25