________________________________Capitolo 3
Emulatore del prototipo con
LabVIEW™
3.1 Introduzione
Una parte del lavoro di tesi è stata dedicata alla realizzazione di un emulatore del prototipo realizzato utilizzando il software LabVIEW™, della National Instruments.
LabVIEW™ è un linguaggio di programmazione grafico che utilizza delle icone in sostituzione delle righe di codice dei classici linguaggi di programmazione testuali. Mentre in questi ultimi sono le istruzioni che determinano il flusso di esecuzione di programma, in LabVIEW™ viene utilizzato il cosiddetto “dataflow programming”: un nodo viene eseguito solo quando sono presenti tutti i dati ai suoi terminali di ingresso e presenta un dato in uscita solo quando è conclusa la sua esecuzione.
Un’applicazione realizzata con LabVIEW™ (detta VI, Virtual Instrument) è costituita da due elementi fondamentali: il “front panel” e il “block diagram”.
Il primo costituisce l’interfaccia con cui l’utente interagisce con l’applicazione: esso è dotato di controlli e indicatori, che risultano essere rispettivamente degli ingressi e delle uscite del VI. Il block diagram invece rappresenta il codice dell’applicazione, ed è costituito da un’insieme di funzioni rappresentate graficamente ed opportunamente connesse fra loro.
Prima di passare alla descrizione dell’intero emulatore sono necessarie alcune precisazioni.
L’emulatore, esattamente come il prototipo realizzato, per funzionare necessita di trasferire dati e comandi attraverso l’interfaccia seriale RS-232. L’oggetto fisico, e
quindi l’emulatore, sono compatibili con una famiglia di display grafici lcd con interfaccia seriale della Matrix Orbital. Disponendo materialmente di un display di questa famiglia (il GLK12232-25SM), per lo sviluppo dell’emulatore e del prototipo si è fatto riferimento ad esso, senza tuttavia perdere di generalità.
Per la trasmissione dei comandi, e per valutare il corretto funzionamento del prototipo e dell’emulatore, è stato utilizzato il software freeware messo a disposizione dalla stessa Matrix Orbital (MOGD, Matrix Orbital Graphic Display).
Nel corso di questo capitolo verrà fornita dapprima una panoramica sulle caratteristiche generali del display lcd GLK12232-25SM preso in esame per la realizzazione dell’emulatore, dopodiché saranno presentati la struttura ed il principio di funzionamento di quest’ultimo, ponendo maggiore attenzione ai Virtual Instruments (VIs) più significativi.
3.2 Caratteristiche generali e panoramica dei comandi del display lcd Matrix Orbital GLK12232-25
L’unità GLK12232-25-SM rappresenta un modulo con display lcd a matrice 122 x 32 pixel in grado di rappresentare sia informazioni di tipo testuale che grafiche. Esso è stato studiato per essere utilizzato in associazione ad un controller esterno, il quale ha il compito di fornire tutti i comandi necessari al fine di visualizzare le informazioni che devono essere rappresentate nel display. È importante notare come l’unità stessa abbia necessità di un controller esterno per la visualizzazione di informazioni dinamiche: essa infatti esegue solamente i comandi che le vengono forniti attraverso l’interfaccia di comunicazione; la conseguenza di ciò è che, in assenza di comandi esterni, il display non esegue autonomamente nessuna operazione (eccetto rinfrescare il display ed elaborare i segnali provenienti dall’interfaccia tastiera). Il controller che può venire utilizzato può risultare di varia natura: tipicamente è rappresentato da un microcontrollore o da un personal computer.
Per quanto riguarda l’interfaccia di comunicazione, il display è in grado di utilizzare sia l’interfaccia seriale RS-232, che l’interfaccia I²C.
È possibile stabilire via hardware quale delle due interfacce utilizzare; non ci si può tuttavia servire contemporaneamente di entrambe le interfacce, anche per il fatto che condividono lo stesso connettore nel circuito stampato. L’interfaccia RS-232 può operare correttamente sia con i livelli relativi allo standard EIA232 (+/-12V), sia con livelli TTL (0/5V); questa scelta può essere impostata sempre per via hardware. È possibile inoltre definire alcuni parametri della comunicazione (come baud rate, flow control) attraverso opportuni comandi inviati dal controller.
Oltre alla comunicazione con un controller, è prevista la possibilità di interfacciare l’unità con una tastiera: a tale scopo viene dedicato un connettore a 10 pin, che consente la connessione di una tastiera con al massimo 25 tasti. Quest’ultima tuttavia non ha alcun effetto diretto sul display: in seguito alla pressione di un tasto l’unità genera semplicemente il codice ASCII che vi corrisponde, e successivamente lo invia al controller attraverso l’interfaccia seriale (o I²C). Qualora si voglia ottenere una ripercussione sul contenuto del display a seguito della pressione di un tasto, è necessario implementare nel controller una opportuna porzione di programma specifica per tale funzione. Relativamente alla tastiera sono dedicati una serie di comandi con la funzione di impostare i parametri tipici per un’interfaccia di questo tipo.
Il GLK12232-25-SM prevede anche due uscite general purpose, attraverso le quali possono essere pilotati relè o dispositivi di altro tipo. Ogni uscita può assorbire una corrente massima di 250 mA, ed il controllo di queste ultime avviene per mezzo di appositi comandi inviati al modulo attraverso l’interfaccia RS-232 o I²C.
A questo punto analizziamo in dettaglio le potenzialità dell’unità GLK12332-25-SM per quanto concerne la visualizzazione del testo e della grafica.
Il display permette di mostrare del testo utilizzando dei fonts contenuti all’interno di una memoria non volatile presente nell’unità stessa. I display sono venduti con un font standard già caricato in memoria, a matrice 5 x 7 pixel; l’utente può comunque aggiungere dei fonts personalizzati, eliminarli e modificarli attraverso degli appositi comandi inviati dal controller. Tutti i tipi di fonts contenuti in memoria sono identificati da un numero, che consente quindi all’utente (e al microcontrollore dell’unità) di contraddistinguerli univocamente. Sono previsti diversi comandi per la trattazione del testo: alcuni di essi permettono di definirne la posizione, altri consentono di stabilire il
tipo e la metrica del font da utilizzare, altri ancora stabiliscono la modalità di rappresentazione del testo nel display.
Per quanto riguarda invece la grafica, sono previsti una serie di comandi che permettono al GLK12232-25SM di costituire un prodotto dalle buone potenzialità. Esso è in grado, ad esempio, di mostrare una bitmap salvata in memoria semplicemente attraverso un comando che la identifica (possono essere memorizzate fino ad un massimo di 30 bitmaps). Un altro modo di visualizzare un’immagine consiste nel crearla attraverso una successione opportuna di comandi inviati all’unità, che forniscano informazioni al display su quali pixel debbano essere accesi e quali no. A tale scopo esistono comandi di vario tipo: il più semplice, ma indispensabile, permette di accendere (o spegnere) un singolo pixel in una posizione determinata; altri permettono di tracciare una linea nel display (accendendo o spegnendo i pixel corrispondenti), di disegnare il contorno di un rettangolo (o un rettangolo “pieno”), e perfino di visualizzare dei grafici a barre (secondo diverse modalità).
In appendice verrà presentato il sommario dei comandi del modulo lcd che vengono implementati nell’emulatore e nel prototipo realizzati. A questo punto andiamo a descrivere il principio di funzionamento dell’emulatore.
3.3 Principio di funzionamento
Il Virtual Instrument principale che costituisce l’emulatore vero e proprio è “Emulator.vi”. Nella figura 1 ne viene illustrato il relativo front panel.
Come visibile dalla figura 1 il front panel dell’emulatore è molto semplice: è possibile notare il display LED, alcuni controlli ed un indicatore. Il display LED è stato realizzato per mezzo di un array 2D di elementi di tipo booleano (“round led”) e di esso è possibile controllarne le dimensioni attraverso i parametri “x dimension”, “y dimension” e “pixel dimension”: i primi due stabiliscono rispettivamente il numero di colonne e di righe della matrice di led, mentre grazie al terzo controllo è possibile agire sulle dimensioni del singolo pixel. La caratteristica di poter modificare le dimensioni della matrice permette di estendere la validità dell’emulatore anche ad altri modelli di
display della stessa famiglia (e non solo, infatti funziona correttamente anche con dimensioni diverse da quelle standard).
Figura 1 – Front panel dell’emulatore del display.
L’altro controllo presente (“VISA resource name”) è relativo all’interfaccia RS-232: in particolare per mezzo di esso è possibile impostare la porta di comunicazione interessata dal trasferimento di dati. L’unico indicatore visibile (“RS-232 port speed”) si riferisce alla velocità di comunicazione (baud rate) della porta seriale, che viene stabilita attraverso la variabile globale “RS-232 port speed” definita nel file “Global.vi”. Il valore di default per il baud rate è pari a 19200 bps.
Dopo aver mostrato l’aspetto del front panel, andiamo a vedere com’è stata strutturata l’intera applicazione.
Per prima cosa è stata adottata una struttura gerarchica: l’intero sistema è cioè costituito da un insieme di subVIs, ognuno dei quali si occupa di svolgere determinate funzioni. L’utilizzo di una struttura di questo tipo ha permesso di semplificare la realizzazione dell’emulatore, che altrimenti avrebbe avuto un block diagram assai più complesso e di difficile lettura.
Inoltre, affinché tutti i Vis potessero leggere ed eventualmente modificare alcuni paramentri del sistema, è stato previsto l’utilizzo di alcune variabili globali, definite nel file “Global.vi”.
Nella figura 2 viene riportato lo schema a blocchi relativo all’implementazione dell’emulatore.
Figura 2 – Schema a blocchi dell’emulatore.
Inizializzazione dell'intero sistema
Aggiornamento del display nel front panel
Sono presenti dati nel buffer della
porta RS232?
Attesa di eventuali dati mancanti e loro
inserimento in un array usato come
buffer Elaborazione dei dati ed esecuzione delle appropriate routine Rimozione dall'array dei dati utilizzati
Ci sono altri dati da elaborare? SI NO SI Fine NO STOP? SI NO
Come si può notare dalla figura 2, vengono effettuate le seguenti operazioni:
• Dapprima viene eseguita un’inizializzazione di tutti i parametri necessari al funzionamento dell’intero oggetto, come ad esempio l’inizializzazione del display, della porta seriale e della tastiera.
• Successivamente si attende che siano presenti dati nel buffer di ingresso della porta seriale: non appena ciò accade ne viene effettuata la lettura e i dati pervenuti vengono salvati in un array 1D.
• Una volta che sono presenti dei dati, ne viene effettuato il riconoscimento. Si inizia dal primo dato pervenuto e si stabilisce se esso è un comando o un carattere da visualizzare. Qualora sia stato riconosciuto un comando, viene verificato che siano disponibili anche tutti i parametri ad esso associati necessari al fine della sua esecuzione: se questo non avviene, prima di passare alla fase successiva, si attendono i dati mancanti.
• Una volta stabilito se è pervenuto un carattere o un comando, segue la fase di esecuzione, nella quale si affida ad alcuni subVIs il compito di eseguire le opportune operazioni.
• Dopo l’esecuzione, vengono eliminati dall’array usato per il salvataggio dei dati, il numero necessario di caratteri relativi al comando eseguito o al carattere visualizzato. Si verificano a questo punto le condizione del buffer dati: se presenta ancora degli elementi al suo interno, si processano i dati rimanenti fino al loro esaurimento.
• Una volta esauriti i dati, si procede ad aggiornare il display del front panel, con l’array globale “Led DISPLAY”. Quest’ultimo infatti rappresenta il contenuto del display dopo l’esecuzione di ogni comando che lo coinvolge.
• Infine, se non è stato premuto il pulsante per arrestare l’esecuzione dell’emulatore, si torna ad attendere nuovi dati dall’interfaccia seriale.
Nel corso dei paragrafi successivi verranno descritte con maggior dettaglio le varie fasi di funzionamento dell’emulatore.
3.3.1 Inizializzazione del sistema
Nel momento in cui viene avviata l’esecuzione dell’applicazione principale, la prima fase che viene portata a termine è quella relativa all’inizializzazione dell’intero sistema. Nel seguito riportiamo le varie operazioni che vengono eseguite in questa fase:
• Dapprima viene impostata la dimensione del singolo pixel ed il numero di righe e colonne della matrice sulla base dei relativi controlli presenti nel front panel. Inoltre, in quest’ultimo, viene fissata la posizione del vertice superiore sinistro del display a delle coordinate specifiche per evitare problemi causati dal ridimensionamento. • Vengono settati alcuni parametri relativi alla metrica sulla base delle dimensioni correnti del display.
• Si provvede all’inizializzazione dell’interfaccia seriale e della tastiera.
• Si verifica se sono già stati caricati nell’array globale “Font data” i dati relativi al font standard da utilizzare per la visualizzazione dei caratteri, qualora non ne venga selezionato uno da parte dell’utente. Durante la prima esecuzione dell’applicazione si procede al caricamento del font standard, mentre per le esecuzioni successive tale operazione non viene più eseguita.
Nel corso dei successivi paragrafi verranno descritte con maggiore dettaglio le funzionalità dei singoli blocchi dell’emulatore.
Nella figura seguente (figura 3) viene mostrato il block diagram relativo all’impostazione delle dimensioni del singolo pixel del display. Come visibile si è agito semplicemente sulle proprietà dell’oggetto boolean (che rappresenta il singolo elemento del display).
In figura 4 viene invece rappresentato il block diagram che si occupa di impostare le dimensioni della matrice e la sua posizione nel front panel. Inoltre, grazie al subVI “Initialize display.vi” vengono settati alcuni parametri relativi alla metrica e alla posizione iniziale del primo carattere che verrà eventualmente visualizzato, si provvede alla cancellazione del display, si inizializza l’array di cluster riservato ai grafici a barre e, se necessario, viene caricato il font standard.
Figura 4 – Inizializzazione della posizione della matrice e delle sue dimensioni. Il subVI “Init display” si occupa di settare altri parametri relativi al display.
In figura 5 viene mostrato il block diagram relativo all’inizializzazione della porta seriale e della tastiera: sono state utilizzate le due funzioni “VISA Configure Serial Port.vi” e “Initialize Keyboard.vi”, entrambe fornite a corredo con il software LabVIEW™. Il baud rate della porta seriale viene impostato sulla base della lettura della variabile globale “RS-232 port speed”: il valore di default alla prima esecuzione dell’applicazione è pari a 19200 bps (proprio come per i display lcd della Matrix Orbital).
Nella figura 6 si riporta solo una parte del VI “Init display.vi” nella quale viene effettuato il caricamento di un font standard, qualora non sia già stato caricato precedentemente. I dati relativi al font vengono letti da un file predisposto a tale scopo e salvati nella variabile globale “Font data”.
Questo viene fatto al fine di agevolare la lettura di tali dati nel momento in cui è richiesta la visualizzazione di un carattere sul display, senza dover quindi accedere al file del font per ogni carattere da visualizzare.
Figura 5 – Inizializzazione dell’interfaccia tastiera e della porta RS-232.
Figura 6 – Caricamento del font standard.
Nel successivo paragrafo viene esaminata la parte dell’applicazione che si occupa di ricevere dati dalla porta seriale e di inserirli nell’array predisposto come buffer.
3.3.2 Ricezione dati dalla porta RS-232
Una volta che è stata portata a termine l’inizializzazione del sistema, segue un ciclo while nel quale vengono eseguite in successione alcune operazioni: tra di esse, la prima ad essere effettuata è la lettura di dati dalla porta seriale.
Questa attività viene svolta dal VI “Read from RS-232.vi”, del quale in figura 7 ne viene riportato il block diagram.
Figura 7 – Block diagram del VI “Read from RS-232”.
Come è possibile vedere dalla figura, viene eseguita ciclicamente la lettura del buffer di ingresso della porta seriale (individuata da “VISA resource name”) fino a che in esso non risultano presenti dei dati (ovvero fino a che il numero di bytes nel buffer è pari a zero). Nel momento in cui si rilevano dati nel buffer, essi vengono prelevati da quest’ultimo, convertiti nel relativo codice ASCII, e successivamente accodati all’interno dell’array 1D “Txt/cmd buffer” per una loro successiva elaborazione. Quindi al termine del ciclo while, l’array conterrà la successione di codici ASCII corrispondenti a comandi da eseguire oppure a caratteri da visualizzare nel display. Questo array in uscita dal subVI, è direttamente connesso nell’applicazione principale all’array dal nome omonimo. L’altro VI presente è relativo all’acquisizione da tastiera e verrà trattato in seguito.
Una volta terminata la fase di ricezione di dati dalla porta RS-232, segue la fase di riconoscimento e verifica di questi ultimi.
3.3.3 Decodifica e verifica dei dati ricevuti
Una volta che l’array “Txt/cmd buffer” contiene elementi al suo interno, è necessario riconoscere tra di essi i vari comandi (con i relativi parametri associati) ed i caratteri che eventualmente dovranno essere visualizzati. Nei display lcd della Matrix Orbital che sono stati presi in esame, un comando viene riconosciuto in quanto inizia sempre con il carattere ASCII 254. Dopo di esso è presente il tipo di comando da eseguire, seguito da un numero di parametri dipendente dal tipo di comando stesso. La maggior parte dei comandi ha bisogno di più parametri, ma ve ne sono alcuni che ne sono privi.
La prima operazione che viene eseguita dall’emulatore è quella di verificare la presenza o meno del carattere 254: se esso viene riconosciuto, si passa ad analizzare il tipo di comando individuandone il numero di parametri che ad esso devono essere associati. Questa operazione viene svolta dal VI “Type of command.vi”, che per ogni comando riconosciuto fornisce il numero di parametri occorrenti ed informazioni inerenti la sua esecuzione. Esistono dei comandi che hanno significato per i display lcd della Matrix Orbital, ma non lo hanno se utilizzati per un display LED: un esempio è dato dal comando “Backlight on” che attiva la retroilluminazione del display lcd; ovviamente per il prototipo realizzato, ed anche sull’emulatore, questo comando è stato ignorato. Quindi il VI “Type of command.vi”, relativamente al comando “Backlight on”, comunica ai VIs a cui è connesso che tale comando non necessita di parametri ed inoltre che è da ignorare. Un’altra situazione nella quale è necessario ignorare un comando è quella in cui non sia stata implementata la sua funzione: un esempio è dato dal comando “Enter flow control mode”, in quanto il controllo di flusso non è stato utilizzato per l’emulatore.
Stabilito il numero di parametri necessari, si passa a verificare che questi siano tutti presenti nell’array “Txt/cmd buffer”: qualora così non fosse si attendono i dati mancanti. Una volta che il comando è completo dei suoi parametri si passa alla successiva fase di elaborazione ed esecuzione.
Se non viene riconosciuto il carattere 254, si assume che il carattere pervenuto non sia un comando e che quindi debba essere visualizzato sul display. Ad occuparsi della
visualizzazione è il VI “Char on display.vi”, che verrà descritto nei paragrafi successivi.
3.3.4 Fase di esecuzione
La fase di esecuzione viene trattata separatamente a seconda che si riferisca ad un comando da eseguire oppure ad un carattere da visualizzare. Nei due paragrafi seguenti verranno illustrate le diverse operazioni svolte in entrambi i casi.
3.3.4.1 Fase di esecuzione di un comando
A gestire l’operazione di esecuzione di un comando è il VI “Execute command.vi”: esso viene eseguito solamente se la funzione “type of command.vi” ha dato conferma che il comando non deve essere ignorato. Per compiere la sua funzione, il VI riceve in ingresso l’array “Txt/cmd buffer” ed il riferimento alla risorsa di comunicazione relativa alla porta seriale correntemente selezionata.
Il VI è costituito da un costrutto case che, sulla base del comando selezionato, esegue una specifica porzione di codice. Questo generalmente consiste nella chiamata di opportuni subVIs e nell’aggiornamento di alcune variabili globali. Sono questi subVIs che generalmente eseguono la maggior parte del lavoro.
A titolo di esempio vengono riportate nelle figure 8 e 9 due casi presenti nella funzione “Execute command.vi” (i casi sono molti, uno per ogni comando, e la descrizione di ognuno di essi appesantirebbe troppo l’esposizione; per tale motivo ne vengono riportati solamente due): il primo (in figura 8) è relativo al comando “Initialize bar graph”, mentre il secondo (figura 9) al comando “Display saved bitmap”.
In questo paragrafo si è visto come si procede all’esecuzione di un comando: nel paragrafo che segue invece verrà illustrata la modalità con cui l’emulatore visualizza caratteri sul display.
Figura 8 – Block diagram relativo al comando “Initialize bar graph”
3.3.4.2 Visualizzazione di caratteri sul display
Prima di procedere con la descrizione del funzionamento della routine che si occupa di visualizzare un carattere sul display, è necessario fornire alcune informazioni riguardo la gestione dei fonts nei display Matrix Orbital.
I fonts (così come le bitmaps) vengono caricati nella memoria non volatile presente nel display lcd per mezzo del software MOGD. Un file che contiene un font (sia quello in formato mgf manipolabile con MOGD, che quello generato da LabVIEW™ per mezzo di un’apposita routine) è costituito da tre parti fondamentali: un’intestazione, una lista dei caratteri, ed infine dalle bitmaps relative ad ogni carattere. L’intestazione contiene le seguenti informazioni:
• Larghezza nominale del carattere del font. • Altezza del font (valida per tutti i caratteri). • Codice ASCII del primo carattere definito. • Codice ASCII dell’ultimo carattere definito.
La lista dei caratteri è invece formata da un certo numero di coppie di elementi (pari al numero totale di caratteri definiti) ognuna delle quali racchiude le seguenti informazioni:
• Offset relativo alla definizione della bitmap del carattere.
• Larghezza specifica del carattere (che può essere diversa da quella nominale). Per quanto riguarda la bitmap di un carattere, essa è costituita da un numero di bytes che può variare a seconda della specifica larghezza che caratterizza il carattere stesso. Nelle figure seguenti (figure 10 e 11) viene riportato un esempio, tratto dal manuale del display lcd Matrix Orbital GLK12232-25SM, di come viene rappresentato in tale dispositivo il carattere “h” di un font 5 x 7. Come è possibile notare dalla figura 11, il primo byte relativo al carattere si riferisce alla prima colonna del carattere stesso, ed il primo bit è relativo al pixel più in alto. Eventuali bit non significativi vengono ignorati. Il salvataggio di un font in un display Matrix Orbital può avvenire per mezzo del software MOGD: dopo aver creato o selezionato un file font in MOGD, è possibile salvarlo nella memoria del display lcd grazie al comando “Upload font data”.
Figura 10 – Rappresentazione in pixel del carattere”h” in un font 5 x 7.
Figura 11 – Modalità di conversione della bitmap del carattere “h” nei bytes corrispondenti.
L’emulatore invece, per ovvie ragioni, utilizza un file per memorizzare i dati relativi al font. Quando si procede ad effettuare l’upload del font verso il display, dapprima il software informa il display circa le dimensioni totali del font: se c’è spazio sufficiente in memoria tale da contenerlo allora si può procedere all’upload, altrimenti il modulo comunica al software che la procedura deve essere terminata. Per quanto riguarda l’emulatore, esso fornisce sempre la sua disponibilità all’upload, non avendo problemi di spazio per il salvataggio su disco. Una volta che il software riceve conferma sulla disponibilità di memoria, inizia il trasferimento dei dati; per ogni dato trasferito si eseguono le seguenti operazioni: il software invia un dato, attende la restituzione dell’echo di quel dato da parte del modulo e conferma a quest’ultimo la corretta ricezione dell’echo. In caso di errori nel trasferimento viene visualizzato un errore da parte del software MOGD (nel caso dell’emulatore, anche da parte di quest’ultimo).
Passiamo ora a descrivere il principio di funzionamento utilizzato per la visualizzazione di un carattere sul display.
Il VI “Char on display.vi” è quello che si occupa di tutto il processo volto alla rappresentazione di un carattere nello schermo. Affinché un carattere possa essere visualizzato è necessario disporre di alcuni dati fondamentali. Essi consistono in:
• Informazioni circa il font ed il carattere, come larghezza nominale e reale di quel carattere, altezza, codice ASCII del primo e dell’ultimo carattere definiti e dimensioni del font.
• Informazioni riguardo le dimensioni della matrice, la posizione corrente per la visualizzazione del carattere e lo stato di alcune variabili globali.
Esistono due modalità per la visualizzazione su schermo del carattere: la prima utilizza il sistema di riferimento in pixel, mentre la seconda quello a celle di caratteri.
Il primo caso presenta una soluzione più semplice, in quanto il carattere deve essere visualizzato alle coordinate specificate dal comando predisposto a tale scopo. L’unica operazione da fare è quindi quella di reperire le informazioni relative al carattere e rimpiazzare nella matrice di led l’area occupata dal carattere stesso con i dati letti dal file del font.
Il secondo caso, quello più comune, è invece più complesso: infatti, oltre ad effettuare l’operazione di lettura e di rimpiazzo nel display, devono essere valutati i vari casi che si possono presentare e comportarsi di conseguenza. Il sistema di riferimento a celle di caratteri si basa, oltre che sull’altezza e sulla larghezza del font, anche su altri parametri, che costituiscono la metrica correntemente in uso. In particolare essa si riferisce ai seguenti elementi:
• Left margin, che rappresenta la prima colonna in pixel da cui viene visualizzato il primo carattere di una riga.
• Top margin, che costituisce la prima riga in pixel che sarà utilizzata per disporre il vertice superiore sinistro del primo carattere della prima riga del display.
• X space, che specifica il numero di pixel di spazio da lasciare tra due caratteri consecutivi di una stessa riga.
• Y space, che indica il numero di pixel che separano due caratteri posti su due righe consecutive.
• Scroll row, che stabilisce la coordinata in direzione verticale oltre la quale eseguire lo scroll del display, se abilitato.
A titolo di esempio, si riporta il solo schema funzionale semplificato relativo alla visualizzazione di un carattere nel sistema di riferimento a celle di caratteri.
Come è possibile vedere dal diagramma di flusso di figura 12, la prima operazione che viene effettuata è quella di reperire le informazioni di base del font. Sulla base di tali informazioni si và a verificare che il codice ASCII del carattere da visualizzare sia compreso tra quelli definiti nel file del font: se ciò non accade non si esegue alcuna operazione, in caso contrario viene avviata la procedura per la visualizzazione.
Una volta stabilito che il carattere è stato definito, si valuta la posizione corrente per l’inserimento del carattere nel display e si verifica che vi sia spazio nella stessa riga. Se lo spazio è sufficiente, la posizione corrente può essere utilizzata per l’inserimento del carattere: si procederà allora alla visualizzazione del carattere in tale posizione e si aggiorna la coordinata x dell’eventuale carattere successivo sulla base della metrica corrente.
Se invece lo spazio non è sufficiente è necessario valutare lo stato della variabile globale “Autoscroll”:
• se l’autoscroll è disattivato, oppure è attivo ma non è stata raggiunta la posizione limite per lo scroll, si valuta se c’è spazio per una nuova riga. Se c’è spazio, si aggiorna la posizione Y del cursore al valore della riga successiva, altrimenti è necessario spostarsi alla prima riga del display (quindi la posizione Y diventa uguale a Top margin).
• Se l’autoscroll è attivo ed è stata raggiunta la posizione limite per lo scroll, si effettua la traslazione del display verso l’alto di una riga e si mantiene invariata la posizione Y.
Una volta che è stata aggiornata la posizione Y si imposta la posizione X alla prima colonna utile al fine della visualizzazione, cioè al valore definito dalla variabile globale “Left margin” e si aggiorna il cursore di posizione X per il carattere successivo.
Figura 12 – Diagramma di flusso relativo alla visualizzazione di un carattere utilizzando il sistema di riferimento a celle di caratteri.
Si valuta la posizione corrente per il carattere
SI NO SI Si aggiorna Y position al valore calcolato Y pos=Top marg X pos=Left marg Y position rimane invariata ((Autoscr=OFF) oppure (Autoscr=ON e limite per lo scroll
non raggiunto)) ? Cè spazio sufficiente per il nuovo carattere nella
stessa riga?
SI NO
C'è spazio per una nuova
riga? Si recuperano i dati relativi al carattere da visualizzare Si esegue la traslazione del display di una riga Rimpiazzamento area occupata dal carattere Si raccolgono informazioni relative al font correntemente selezionato Si aggiorna la posizione corrente in direzione x per il carattere corrente e per il successivo Fine NO
A questo punto, stabilite le coordinate nelle quali è necessario disporre il carattere, si passa alla fase di recupero dei dati relativi ai pixel da accendere o meno nell’area occupata dal carattere stesso. Questo viene eseguito effettuando una lettura dell’array che contiene i dati del font, a partire da un offset calcolato sulla base dei codici ASCII del carattere da visualizzare e del primo carattere definito.
Una volta che si dispone dei dati riguardo la bitmap del carattere, si esegue la cancellazione e successivamente la scrittura dei dati nell’array globale “Led DISPLAY”. L’effettiva visualizzazione del carattere sul display avverrà solo in una fase successiva, come verrà illustrato nel paragrafo seguente.
3.3.5 Aggiornamento del buffer e del display led
Le ultime fasi del diagramma di flusso circa il funzionamento dell’emulatore riguardano la rimozione dei dati utilizzati nell’array “Txt/cmd buffer” e l’aggiornamento del display posto nel front panel.
L’operazione di rimozione dei dati utilizzati dal buffer risulta molto semplice:
• Se un dato rappresenta un carattere da visualizzare è necessario eliminare solo quell’elemento, quindi un singolo byte.
• Se invece si deve eliminare un comando con tutti i parametri, è sufficiente rimuovere un numero di bytes superiore di due rispetto al numero dei paramentri del comando. Infatti un comando inizia sempre con il carattere ASCII 254, seguito dal codice ASCII del comando e dai parametri che lo accompagnano. Si ricorda che il numero dei parametri associati ad ogni comando viene fornito dal VI “Type of command.vi”.
Anche l’operazione di aggiornamento del display posto nel front panel dell’emulatore risulta molto semplice: infatti è sufficiente sovrascrivere l’array bidimensionale che costituisce il display led, con l’array globale “Led DISPLAY”. È importante notare che è solo quest’ultimo a subire cambiamenti durante la fase di esecuzione. Infatti agire direttamente sulla matrice del front panel avrebbe comportato delle inutili
complicazioni a causa dell’utilizzo consistente di riferimenti a quest’ultima in ogni VI che necessiti di accedere alla matrice.
3.4 Cenni alla trattazione di bitmaps
I display lcd della Matrix Orbital, così come l’emulatore e il prototipo realizzato, consentono il salvataggio di immagini a 2 colori (B/N) per una loro successiva visualizzazione.
Mentre i display lcd salvano queste immagini nella memoria non volatile presente on board, l’emulatore effettua il salvataggio su file. Nel momento in cui perviene all’emulatore il comando “Display saved bitmap” seguito dal numero di riferimento dell’immagine, viene effettuata la lettura dei dati dallo specifico file.
Un file di bitmap contiene, oltre che i dati della bitmap stessa, anche un’intestazione nella quale vengono indicate le sue dimensioni in pixel. È il software MOGD ad occuparsi di controllare che la bitmap possa essere effettivamente contenuta nell’area del display. Altro controllo che viene eseguito da parte di MOGD è che vi sia spazio sufficiente in memoria a contenere la bitmap: ovviamente l’emulatore, non avendo problemi di spazio su disco da impiegare per il salvataggio, conferma sempre al software MOGD che lo è spazio sufficiente a contenere l’immagine. Durante la fase di trasferimento (del tutto simile a quella relativa ad un font) c’è un colloquio costante tra emulatore e software per stabilire se i dati pervenuti sono stati trasferiti correttamente: in pratica MOGD invia un dato, l’emulatore ne restituisce l’echo e MOGD conferma la corretta ricezione di quest’ultimo. Se viene riscontrato un problema da parte dell’emulatore o del software MOGD, viene riportato un messaggio di errore. Terminata la fase di trasferimento, l’emulatore visualizza una finestra dove si chiede di salvare il file in un dato percorso scelto dall’utente.
Per quanto riguarda invece la fase di visualizzazione, la procedura è simile a quella per i fonts: al comando “Display saved bitmap” l’emulatore risponde aprendo una finestra nella quale l’utente seleziona il file corrispondente alla bitmap da visualizzare (viene proposto già il nome del file suggerito in fase di salvataggio della stessa immagine). A questo punto viene salvata la bitmap nell’array globale ”Led DISPLAY”,
per una successiva scrittura nel display LED presente nel front panel con il contenuto dell’array stesso.
3.5 Cenni al’uso dell’interfaccia tastiera
Nei display Matrix Orbital, come accennato nel paragrafo 2, è stato previsto un connettore al quale è possibile collegare una tastiera a matrice con al massimo 25 tasti. È stato anche detto che quest’ultima, tuttavia, non ha alcun effetto diretto sul display, ma invia solamente attraverso l’interfaccia di comunicazione il codice ASCII del carattere premuto.
Per emulare questa proprietà presente in tali dispositivi con LabVIEW™, è stata utilizzata la tastiera del pc nel quale quest’ultimo è in esecuzione.
Tra le funzioni disponibili in LabVIEW™, è presente il VI “Acquire input data”, che restituisce un array 1D di elementi di tipo enum con informazioni circa i tasti premuti. Nel VI “Keyboard acquire.vi”, viene sfruttata tale funzione al fine di fornire, a partire da elementi di tipo enum, dati di tipo char, necessari per l’invio attraverso l’interfaccia seriale. In questo VI sono stati ritenuti validi un numero superiore di caratteri rispetto ai soli 25 utilizzabili nella tastiera reale.
La funzione principale che si occupa di gestire interamente la tastiera è il VI “Read from keyb.vi”, il quale sfrutta il subVI “Keyboard acquire.vi” per la ricezione dei dati da tastiera. La routine di acquisizione agisce all’interno del VI “Read from RS-232”
Nel display Matrix Orbital vi sono molti comandi relativi all’interfaccia tastiera: nell’emulatore invece, è stata posta poca importanza a tale interfaccia e per questo motivo è stato previsto il semplice invio del codice ASCII dei caratteri premuti attraverso l’interfaccia seriale.
Il principio di funzionamento per l’interfaccia tastiera è il seguente: si legge periodicamente lo stato della tastiera mentre si attendono dati dall’interfaccia RS-232 e se viene rilevata la pressione di un tasto se ne invia il relativo codice ASCII per mezzo dell’interfaccia seriale.
Ultima cosa da evidenziare è che la funzionalità della tastiera nell’emulatore è disabilitata di default all’avvio dello stesso, in quanto interferisce nell’utilizzo del software MOGD (ad esempio quando si inseriscono da tastiera alcuni parametri come le coordinate necessarie ad alcuni comandi, oppure si digita un messaggio testuale da inviare al display). Tuttavia tale funzionalità può essere attivata semplicemente agendo sulla variabile globale “Keyb enable” nel file “Global.vi”.
