Newsgroup: it.hobby.elettronica.digitale
Titolo: GUI su TFT con i Cortex-M

Nessuno qui ha fatto qualcosa del genere, utilizzando i TFT controller 
integrati nei nuovi Cortex-M3/4 di NXP o ST che forniscono, tra l'altro, 
le librerie emWin in formato oggetto gratuitamente?
 
Io ci sto provando con un NXP (un LPC4350 per l'esattezza, un dual core 
Cortex-M4/M0+) ed un TFT 320x240 con una profondità di colore a 16bit, 
ma non ottengo buone prestazioni.
Il disegno delle finestre e percettibile agli occhi e pure gli scrolling 
non sono fluidi.
 
Mi chiedo se sia io a sbagliare qualcosa oppure da questi sistemi non si 
può ottenere molto di più.
 
Anche se, quando vedo su YouTube cosa riescono a fare con questi micro 
(addirittura utilizzando TFT controller esterni), penso sia io a 
sbagliare qualcosa.
 

 non sono fluidi.
 
Non conosco il caso specifico ma quello che descrivi accade quando disegni
direttamente nel frame buffer usato dal controller TFT. Se hai abbastanza
RAM potresti usare una tecnica di double buffering: disegni su un buffer a
parte, e poi trasferisci l'intero buffer nel frame buffer in un colpo solo
(magari sincronizzandoti col VSYNC).
 
-- 
Fletto i muscoli e sono nel vuoto.

 (magari sincronizzandoti col VSYNC).
 
Capisco la tua tecnica del double-buffer, però non sono convinto, magari 
mi sbaglio, che quello che vedo sia dovuto a questo.
 
Penso che il double-buffer eviti che si veda la progressione del 
disegno: prima una linea, poi un'altra linea, poi un cerchio, ecc. ecc.
Disegno tutto in un altro framebuffer nascosto e lo rendo visibile, con 
un'unica istruzione, quando ho finito.  Non si vedranno le operazioni di 
disegno intermedie.
 
Nel mio caso mi sembra più una mancanza di fluidità, lentezza nelle 
operazioni di disegno.  La tecnica del double-buffer non dovrebbe 
aumentare le prestazioni, ma solo migliorare l'effetto visivo.
 
Comunque proverò e ti farò sapere...
 
 

 aumentare le prestazioni, ma solo migliorare l'effetto visivo.
 
Probabilmente avevo inteso male io, quando parlavi del fatto che si vedeva
il ridisegno delle finestre pensavo ti riferissi proprio al primo caso.
 
Se invece stai parlando delle prestazioni complessive, c'è ben poco da fare
se non ottimizzare il codice applicando tutti i "trucchi" ben noti a chi
sviluppa motori grafici. Ad esempio tu parlavi di scolling: una tecnica
usata spesso è quella di usare un frame buffer più grande di quello
necessario per la visualizzazione, e modificare semplicemente l'indirizzo
di partenza del frame buffer in modo che venga visualizzata la porzione che
ti interessa. Nel frattempo aggiorni in background le parti che saranno
visualizzate successivamente.



Sì, però queste soluzioni Cortex-M3/M4 di NXP (LPC) e ST (STM32) con TFT 
controller integrato, ti permettono di usare gratuitamente le emWin 
(librerie grafiche della Segger).  E penso che il lavoro che hanno fatto 
loro negli anni non è facilmente replicabile da me in tempi ragionevoli.
 
In altre parole, non mi metterei a rifare il lavoro della Segger visto 
che posso utilizzare queste aggratisse (hanno già tecniche raffinate per 
aumentare le prestazioni, tipo doppio o triplo framebuffer, 
anti-aliasing, alpha blending, memory devices, virtual pages, window 
manager, ...)
 
Il mio dubbio di partenza era che, pur utilizzando librerie grafiche 
ottimizzate (probabilmente il meglio che c'è nel mercato embedded) e 
microcontrollori performanti (frequenza di lavoro 200MHz e core 
Cortex-M4) le prestazioni non sembrano eccezionali.
 
Dopo un po' di prove ho forse capito che il collo di bottiglia del mio 
sistema è l'esecuzione del codice da una Flash esterna Quad-SPI. Facendo 
eseguire il codice dalla Flash interna, le cose migliorano parecchio.