L’evoluzione dei sistemi embedded verso il livello palmare e anche indossabile implica una radicale trasformazione del modello di interfaccia uomo-macchina, considerando da una parte la necessità di comunicare informazioni di natura più prossima a quella nativa dell’uomo (audio/visuale/gestuale), dall’altra la necessità di interagire senza dispositivi artificiosi, come tastiera o dispositivi di puntamento. La modalità multimediale e multimodale è il nuovo paradigma di interfaccia uomo-macchina che si sta sviluppando come sottosistema indipendente e ad alto livello per i sistemi embedded di nuova generazione. Ftdi ha introdotto da qualche anno un chip che integra il controllo della visualizzazione con quello del tocco e dell’audio, ottenendo in tal modo un vero e proprio esecutore di comandi di comunicazione audio-visuale e di interprete di comandi basati sul tocco, il controller Eve (Embedded Video Engine) FT800. Recentemente questo dispositivo è ulteriormente evoluto con i modelli FT801/811/813, implementando la capacità del multitocco e del sensing di informazioni fisiche esterne (audio o luce/temperatura) e rendendo tale interfaccia oltre che multimediale, anche multimodale. Il vantaggio di questo approccio è che tutta la funzionalità di interfaccia, essendo completamente integrata in un chip, ingloba completamente tutte le risorse necessarie al funzionamento, compresa un’ampia memoria fino a 1 MByte per la memorizzazione di oggetti visuali e audio. Il dispositivo FT8xx non è un semplice controller ma un vero e proprio motore di elaborazione, quindi capace di eseguire sequenze di programmazione di istruzioni e comandi ad alto livello, inviate dal processore host. Tali istruzioni o comandi sono l’equivalente di centinaia o migliaia di istruzioni a basso livello necessarie ad un controller video per pilotare un display. Di fatto il video engine FT8xx è un processore (coprocessore) a tutti gli effetti e quindi dotato delle necessarie risorse sia di comunicazione (Spi/I2C/Qspi), sia di acquisizione (Adc), sia di elaborazione (processore di comandi, decoder Bmp, Dxt, Jpeg hardware). Grazie a queste risorse questo motore multimediale esegue autonomamente ed efficientemente una grande quantità di processo di controllo che normalmente sarebbe a carico della Mcu host, che invece in questo caso si limita solo a inviare al chip controller macrocomandi in modalità asincrona.
Modello di programmazione
Il modello di programmazione del motore multimediale EVE FT8xx è ad oggetti e a script. Ciò rende particolarmente efficiente la programmazione di questo processore multimediale sia per quanto concerne lo sviluppo del software applicativo, sia per quanto concerne il modo di controllo dell’intero sottosistema multimediale (audio-visual-touch). Gli script destinati al processore multimediale vengono processati da questo tramite un meccanismo di rendering line-by-line, superando in tal modo le limitazioni tipiche del frame buffer (costoso sia in termini economici che dimensionali). Gli script vengono ricevuti direttamente da interfaccia seriale (I2C o Spi) e applicati direttamente al controllo multimediale (audio-video-tocco) in una modalità pin-to-pin. Ciò significa che EVE è in grado di connettere direttamente una Mcu dotata di Spi o I2C a un display Tft, indipendentemente dalle risorse e capacità di controllo video, audio e touch della Mcu. Inoltre, la combinazione degli script con la gestione a oggetti rende particolarmente efficiente questo modello di programmazione in quanto offre allo sviluppatore una visibilità ad alto livello dell’interfaccia multimediale che consente di modellare in maniera più efficace ed estensiva le applicazioni. Due sono le peculiarità del modello di programmazione del FT8xx: la funzionalità memory mapped e il motore di esecuzione dei comandi. Queste due funzionalità rendono il controller multimediale di Ftdi un vero e proprio coprocessore della Mcu che in termini di soluzione single-chip consente a qualsiasi Mcu, anche dotata di scarse risorse on-chip, di gestire processi di interfaccia Hmi molto avanzate, soddisfacendo allo stesso tempo requisiti di embedding particolarmente stretti. I registri, ma anche la memoria, sono “memory mapped”, cioè sono accessibili tramite trasferimento di dati. FT800 utilizzata uno spazio di indirizzamento di 4 MB per la gestione della sua funzionalità multimediale (video, audio, touch). Tale spazio è accessibile in termini di lettura e scrittura tramite transazioni (memory read, memory write, command write) via comunicazione seriale (Spi o I2C). In tale spazio di memoria, oltre ad essere mappati i registri ci controllo, sono mappati anche i buffer che ogni controller utilizza per gestire in maniera efficiente la propria funzionalità. Il motore di esecuzione dei comandi si avvale di due aree di memoria accessibili alla Mcu per gestire in maniera efficace il controllo multimediale dell’interfaccia: la Display List Ram e il Graphic Engine Command Buffer. La caratteristica fondamentale di questi due aree di memoria condivise tra Mcu e FT8xx è quella di funzionare da aree di memorizzazione di comandi basate sul meccanismo di swap. La Mcu scrive i comandi sotto forma di lista e il controller Ftdi esegue i controlli precedentemente scritti in un’altra lista. La Mcu, al completamento della lista esegue lo swap di lista e il controller inizia ad eseguire dalla lista chiusa dalla Mcu. Ecco di seguito una display list per il disegno di un punto posizionato nell’area di visualizzazione del display. wr32 sono comandi di scrittura a controllo di programma eseguiti dalla Mcu via seriale verso FT800. Sono evidenti sia i trasferimenti di dati di controllo, sia i trasferimenti per il controllo stesso della display list (Start, End, Swap):
- wr32(RAM_DL + 0, CLEAR(1, 1, 1); //Azzera lo schermo
- wr32(RAM_DL + 4, COLOUR_RGB(160, 22, 22)); //Fissa al rosso il colore di disegno
- wr32(RAM_DL + 8, POINT_SIZE(320)); //Fissa la dimensione a 320/16 = 20 pixel
- wr32(RAM_DL + 12, BEGIN(POINTS)); //Punto di inizio del disegno
- wr32(RAM_DL + 16, VERTEX2II(192, 133, 0, 0)); //Posiziona il disegno 192 pixel da sinistra e 133 sotto
- wr32(RAM_DL + 20, END()); //Punto di fine del disegno
- wr32(RAM_DL + 24, DISPLAY()); //Chiude la display list (28 byte utilizzati)
- wr32(REG_DLSWAP, SWAP_FRAME); //Rende attiva la display list per essere visualizzata al frame successivo
L’aggiornamento del display consiste quindi nell’invio di una nuova display list al FT8xx attraverso l’interfaccia seriale. Il processo in tal senso è sostanzialmente interattivo e quindi consente di eseguire macro o micro variazioni in qualsiasi momento lo richiede l’interfaccia. I comandi inviabili alla display list sono sostanzialmente funzioni primitive che consentono di costruire qualsiasi tipo di interfaccia multimediale. FT800 implementa comunque una modalità ad alto livello di gestione grafica cosiddetta “widgets” che consente di generare, con pochi comandi e minimo impegno della Mcu, un oggetto grafico complesso che si integra con il resto della grafica in maniera dinamica. Si tratta di macrocomandi che implementano oggetti grafici parametrici (orologi, bottoni, caselle di testo, loghi, ecc.) e operazioni esecutive che agiscono sul display, come eseguire uno snapshout sul display corrente, tracciare dal pannello touch come input, memorizzare in formato Jpeg una immagine, decomprimere un file in memoria, ecc. Tale meccanismo di controllo grafico si basa su un altro buffer di controllo mappato in memoria di 4 kByte, gestito in maniera circolare. La Mcu scrive tramite comunicazione seriale in questo buffer e il controller multimediale legge i comandi e li esegue. Il controllo basato sulla Display List e quello sulla Command List sono concorrenti e gestiti completamente dalla FT800, lasciando alla Mcu solo il compito di aggiornare questi due buffer in funzione dell’applicazione.
Prototipazione rapida
Grazie alla disponibilità di schede di valutazione del FT8xx e una serie di ambienti di modellazione dell’interfaccia multimediale, è possibile prototipare in maniera rapida un’applicazione concentrandosi principalmente sul modello di gestione dell’interfaccia a livello software applicativo, piuttosto che a livello firmware. La prototipazione rapida può essere eseguita sia utilizzando come host il Pc, sia utilizzando come host una Mcu embedded. A livello hardware sono disponibili schede di prototipazione che integrano il controller FT8xx e la relativa logica di interfaccia seriale verso il Pc/Mcu, insieme al display touchscreen e alla catena audio per la riproduzione sonora. In questa forma le schede di prototipazione dell’interfaccia multimediale possono integrarsi direttamente con l’applicazione tramite una connessione seriale. La prototipazione rapida basata su Pc e sui moduli preassemblati del controller FT8xx è molto vantaggiosa in quanto consente di modellare l’applicazione con interfaccia multimediale indipendentemente dalla Mcu target. Ciò grazie al modello di programmazione ad alto livello che implementa il controller multimediale FT8xx. Questo modello di programmazione consente di sviluppare dal lato host un livello di astrazione dell’hardware o Hal (Hardware abstracion layer) che rende il codice dell’applicazione adattabile in maniera immediata a qualsiasi host Mcu. I moduli che montano il controller multimediale FT8xx (FT800C e FT801B) sono entrambi dotati di display Tft touch per la visualizzazione e di altoparlante per la riproduzione audio, nonché di una connessione Spi verso host. Per la connessione tra Pc e modulo viene utilizzato un bridge (Usb-Spi) che consente, previa istallazione di un apposito driver fornito da Ftdi, di collegare in maniera immediata ed equivalente alla connessione diretta Spi-Spi con l’host. In questa modalità di connessione e grazie all’Hardware Abstraction Layer il prototipo può facilmente essere convertito da Pc-based a embedded. Tale Mcu deve implementare la Hal che a sua volta è stata implementata dal Pc utilizzando il codice C “FT_Gpu_Hal.c” che definisce le funzioni di transportation layer che implementano lo strato software Spi di accesso al FTxx.
