Capitolo 9: Sviluppo della portabilità
Introduzione
Dopo aver effettuato le misure con la configurazione circuitale descritta nei capitoli precedenti, è stato deciso di cambiarne una parte per ovviare all’utilizzo di costose schede di acquisizione che devono essere installate su un PC e perciò limitano fortemente la portabilità del sistema di cui fanno parte; inoltre, l’utilizzo vantaggioso di queste schede richiede ambienti di sviluppo software proprietari, come LabVIEW.
Inizialmente è stato comodo e conveniente utilizzare la scheda di acquisizione NI6025E in quanto doveva essere verificata la fattibilità del sistema.
9.1 Scheda con microcontrollore
In sostituzione della scheda NI6025E è usato il microcontrollore PIC16F877, affiancato d altri componenti, che gestisce:
• l’acquisizione del segnale analogico tramite un convertitore A/D interno
• la compensazione degli offset di tensione dei vari canali sensoriali secondo apposite procedure di calibrazione
• la regolazione del guadagno dell’amplificatore da strumentazione (anche se in questa prima versione esso è regolato ad un valore per tutti i canali)
• l’interfacciamento al PC tramite il protocollo USB (Universal
Serial Bus)
L’interfacciamento tra microcontrollore e PC via USB è mediato dall’integrato Philips PDUSBD12.
Dal lato dell’host la comunicazione avviene tramite il supporto di un software ad alto livello realizzato in amplificatore da strumentazione isualC++: un
OCX (ActiveX Control di Windows, protocollo COM) utilizza una libreria di
medio livello (CHidDevice) realizzata ad hoc per la gestione di una generica periferica USB che comunica tramite il protocollo HID. Tale libreria fa uso di altre librerie software di basso livello di Windows, ed in particolare delle API (Application Program Interface) SetupAPI disponibili all’interno del DDK (Driver Development Kit) di Windows.
Il trasferimento dei dati è gestito, sempre internamente a CHidDevice e in modo trasparente per il software di alto livello, tramite le API di windows per la gestione di I/O su file.
Il software in VisualC++ fornisce l’interfaccia grafica, che fa uso dell’OCX sopra descritto, e organizza la memorizzazione dei dati.
Questa nuova configurazione è stata messa in opera e provata, ma non sono state fatte le calibrazioni e quindi le misure; il firmware in assembler del PIC e il software devono essere ampliati per permettere una migliore gestione.
9.1.1 Schema a blocchi del nuovo sistema
In figura figura 9.1 è possibile vedere uno schema a blocchi del sistema completo. La filosofia di acquisizione è identica a quella realizzata nel precedente sistema; si rendono necessarie solo piccole modifiche hardware.
GENERATORE DI CORRENTE COSTANTE SENSORI AD8400 AD8400 PIC16F877 AD623 MULTIPLEXERS PDIUSBD12 USB SOFTWARE VISUALC++ Gain Ref A/D 1 16 2 1 1 1 3 3 13 4 4 1 Scheda a microcontrollore (Device) Front-end analogico OCX Host
Figura 9.1: Schema a blocchi
In particolare, sono stati aggiunti due potenziometri digitali (AD8400) che regolano il guadagno e l’offset dell’AD623 secondo un algoritmo implementato nel firmware del microcontrollore.
Il comando per i multiplexers arriva adesso dal microcontrollore ed è analogo a quello della scheda da laboratorio. La conversione analogico digitale è eseguita dal convertitore A/D integrato nel PIC.
Nel lato “device-host”, il PDIUSBD12 permette l’interpretazione dei segnali differenziali provenienti dal device verso l’host e viceversa, consentendo la comunicazione durante il processo di enumerazione caratteristica del protocollo USB e nel trasferimento dei dati acquisiti.
Questo circuito della Philips è molto utile in quanto permette aggirare la parte analogica del protocollo USB, mentre la parte di messaggistica riguardante l’enumerazione e il trasferimento dati è completamente gestito dal firmware del PIC.
In figura 9.2 è mostrata la realizzazione pratica della scheda a microcontrollore.
Figura 9.2
9.2 Microcontrollore PIC16F877
Il PIC (Peripheral Interface Controller) è un integrato della Microchip Technology, che dispone in un unico dispositivo di tutti i circuiti necessari a realizzare un completo sistema digitale programmabile e tipici di un sistema a microprocessore.
Esiste un’ampia gamma di PIC, in risposta alle diverse esigenze di progetto, che si differenziano per numero di linee di I/O, per tipo di memoria, per dotazione di dispositivi.
Le alte prestazioni del PIC, soprattutto in termini di velocità (clock fino a 20MHZ), sono da attribuire a caratteristiche comunemente riscontrabili nei processori di tipo R.I.S.C. (Reduced Intruction Set Computing), in particolare all’architettura di tipo Harvard, che prevede la separazione tra la parte di memoria riservata al programma e quella contenente i dati e l’accesso ad esse tramite bus indipendenti che permette l’acquisizione contemporanea dell’istruzione e dei dati. Il bus per le istruzioni, a 14 bit anziché 8 come quello per i dati, è dimensionato in modo tale che ogni istruzione possa essere prelevata con un solo accesso alla memoria. Durante l’esecuzione di un’istruzione, la successiva è prelevata dalla memoria (struttura a due livelli di pipeline). Le istruzioni sono in numero ridotto ed ognuna richiede un solo ciclo macchina ad eccezione di quelle che prevedono dei salti.
In figura 9.3 è data la piedinatura del PIC16F877:
In figura 9.4 è dato il diagramma a blocchi:
Figura 9.4
E’ visibile la EEPROM da 256 locazioni a 8 bytes per la memorizzazione di dati, la RAM di 368x8 bytes suddivisa in quattro banchi (figura 9.5), la memoria di programma di tipo FLASH di 8Kx14 words.
Il microcontrollore è dotato di tre timers interni capaci di lavorare in parallelo all’esecuzione del programma; è disponibile anche un watchdog per gestire eventi anomali.
Il PIC16F877 è stato scelto perché dispone di alcune caratteristiche che sono state giudicate utili a costruire un sistema compatto; risulta magari sovradimensionato, ma in relazione al fatto che deve essere in grado di supportare eventuali futuri miglioramenti.
È presente ed è stato utilizzato un convertitore A/D a 10 bit e 8 canali. Esso è servito a convertire la tensione rilevata sull’uscita dell’amplificatore differenziale AD623. Riprendendo il discorso lasciato in sospeso alla fine del paragrafo 6.1.4, il tempo di conversione da analogico a digitale è direttamente proporzionale all’impedenza totale vista dall’ingresso del convertitore verso l’esterno; con un valore di impedenza di 10KΩ la conversione avviene in poco meno di 20µsec (50KHz); quindi, nel dimensionamento del filtro RC passa basso, è stato deciso di imporre impedenze molto al di sotto di tale valore per sfruttare al meglio il convertitore.
In figura 9.6, tratta dal datasheet del microcontrollore, sono riportati i passi da seguire per calcolare il tempo di conversione:
Il PIC dispone di quattro porte a 8 bit e una a 4 bit, variamente configurabili secondo l’utilizzo richiesto; tramite esse il PIC è connesso e dialoga con gli altri dispositivi della scheda, con i potenziometri per la regolazione del guadagno e dell’offset di tensione, con i multiplexers per selezionare il canale, con il PDIUSBD12 per trasmettere i dati acquisiti via USB.
Da notare che alcuni pin sono di tipo open-drain, ed è preferibile utilizzarli come ingressi.
9.3 Potenziometri digitali AD8400
Sono circuiti integrati programmabili che simulano l’effetto di un potenziometro analogico, disponibili in versioni da 1KΩ, 10KΩ, 50KΩ, 100KΩ, e ad uno, due o quattro canali usabili come potenziometri indipendenti.
Gli AD8400 hanno 8 piedini (figura 9.7), tre dei quali corrispondo a quelli di un comune potenziometro analogico, gli altri cinque servono a controllare la logica interna.
I piedini 1, 7, 8 sono quelli equivalenti ad un normale potenziomentro; il piedino 6 e il 2 sono l’alimentazione.
Il piedino 3 (/CS), attivo basso, serve a predisporre l’integrato alla programmazione, abilitando, insieme al piedino 5 di clock (CLK), il registro a 10 bit che supporta l’indirizzamento interno e la codifica del valore del potenziometro al piedino 7 (W) (figura 9.8).
Il piedino 4 è l’ingresso per i dati ricevuti con protocollo seriale a 10 bit.
Figura 9.8: Schema a blocchi dell’AD8400
Fornendo il clock, dopo avere abilitato il circuito portando a livello basso
/CS, è possibile inviare 10 bit tramite il pedini SDI all’AD8400 affinché sia
regolato il piedino W di partizione resistiva: i due bit più significativi indicano il canale (essi sono sempre 00 perché l’AD8400 ne possiede uno soltanto); gli 8 bit seguenti codificano la resistenza tra il piedini W e i piedini A e B; ovviamente sono posibili 256 passi per il partitore resistivo.
In figura 9.9 è illustrata la temporizzazione dettagliata da seguire per programmare il potenziometro digitale.
Figura 9.9
La temporizzazione segue lo standard di comunicazione SPI a tre terminali. La linea SDO è rilevante solo nell’AD8403.
9.4 Interfaccia PDIUSBD12
Come accennato in precedenza, questo integrato gestisce la parte analogica del protocollo USB. In figura 9.10 è riportata la piedinatura dell’integrato.
Figura 9.10
In figura 9.11 è illustrato lo schema a blocchi del PDIUSBD12:
Il transceiver analogico, insieme a resistori esterni, interfaccia l’integrato con l’USB.
Il voltage regulator fornisce un riferimento di 3,3V (come richiesto dal protocollo USB) per il resistore di pull-up esterno da 1,5KΩ e alimenta il transceiver.
È presente un PLL (Phase Locked Loop) con intervallo di funzionamento da 6MHz a 48MHz, funzionante con un cristallo da 6MHz. L’uso di un cristallo a bassa frequenza permette di limitare le interferenze elettromagnetiche (EMI).
Il circuito bit clock recovery acquisisce il clock dal bus USB.
Il Philips SIE (Serial Interface Engine) implementa il protocollo USB in modo autonomo, senza programmazione esterna. Esso svolge le seguenti funzioni:
• riconoscimento del pattern di sincronizzazione • conversione da parallelo a seriale
• riconoscimento degli indirizzi • bit stuffing/destuffing
• generazione e controllo del CRC (Cyclic Redundancy Check) • generazione e verifica del PID (Product ID)
• handshake
Il SoftConnect è un sistema che permette di effettuare la negoziazione della connessione inviando un opportuno comando, con il microcontrollore, che attiva il pull-up per il pin D+ con un resistore da 1,5KΩ interno al PDIUSBD12;
normalmente il pull-up è fatto con un resistore discreto e la negoziazione avviene appena il cavo USB è connesso ai dispositivi alimentati.
La RAM e la MMU hanno funzioni di buffer per rendere compatibile la trasmissione USB con quella parallela del dispositivo che è connesso al PDIUSBD12.
L’interfaccia parallela/DMA è il circuito fisicamente connesso al microcontrollore. È vista esternamente come una memoria e può gestire un flusso parallelo a 8 bit di dati e 1 bit di indirizzo, anche multiplexati, oppure un trasferimento di dati in modalità DMA (Direct Memory Access).
9.5 Interfaccia USB per la comunicazione con PC
La scelta di interfacciare la scheda col protocollo USB è scaturita da considerazioni oggettive: l’USB è lo standard che ha pressoché soppiantato la comunicazione seriale e parallela poiché presenta molti vantaggi rispetto ad esse. L’USB consente scambio di dati a maggiori velocità, agevole connessione e migliore gestione delle periferiche.
Se il dispositivo che usa il protocollo USB può sottostare a certe limitazioni, non è necessario scrivere i drivers ma è sufficiente definire degli opportuni descrittori che informano il sistema operativo, dietro sua richiesta, del tipo di periferica connessa e del tipo di dati che essa può inviare e ricevere.
Le limitazioni nell’uso della classe HID, e quindi i requisiti delle periferiche che sfruttano l’HID, possono essere sinteticamente riassunte come segue:
• il firmware della periferica deve rigidamente rispettare il protocollo, pena la perdita di informazione
• ogni transazione di dati deve avvenire in pacchetti standard: o 8 bytes per l’USB low speed (fino a 1,5Mb/sec) o 64 bytes per l’USB full speed (fino a 12Mb/sec) o 1024 bytes per l’USB full speed (fino a 480Mb/sec)
• la massima velocità di trasferimento risulta limitata e non garantita: o fino a 800 bytes/sec contro 192kbytes/sec in modalità bulk
per il trasferimento low speed
o fino a 64000 bytes/sec contro 1.5Mbytes/sec in modalità bulk per il trasferimento high speed
o fino a 24576 Mbytes/sec contro 60Mbytes/sec in modalità bulk per il trasferimento full speed
La scheda con microcontrollore descritta in questo capitolo sottostà alle limitazioni suddette, poiché non si hanno assolutamente grosse quantità di dati da trasferire per volta e non ci sono particolari specifiche di elevata velocità di trasferimento.
Quindi l’uso dell’HID è stato molto vantaggioso nello sviluppo del firmware e del software.
9.5.1 Descrittori di periferica
Durante il processo di enumerazione (che consiste nel riconoscimento da parte del sistema operativo del dispositivo con cui è interfacciato) sono trasferiti dal device all’host, su richiesta di quest’ultimo, una serie di descrittori di seguito brevemente riportati:
• DEVICE DESCRIPTORS: questi descrittori rappresentano la periferica: infatti qualsiasi periferica USB può avere un solo device descritptor, che dà informazioni, ad esempio, sulla versione USB supportata, VendorID, productID e numero di configurazioni del dispositivo
• CONFIGURATION DESCRIPTORS: qualsiasi periferica USB può avere diversi configuration descriptors; questi descrittori specificano come la periferica deve essere alimentata, la massima potenza richiesta e il numero di interfacce possibili
• INTERFACE DESCRIPTORS: questo tipo di descrittori dà informazioni sul numero di endpoint
• REPORT DESCRIPTOR: questo descrittore specifica il protocollo e il significato assegnato ai dati che la periferica fornisce. Infatti, grazie a questa conoscenza, il sistema operativo può utilizzare fra le classi HID quella più adatta
• ENDPOINT DESCRIPTORS: questo genere di descrittori sono utilizzati per descrivere altri tipi di endpoint oltre a EP0; danno informazioni sulla direzione e sul tipo di trasferimento dati, sul valore dell’intervallo di polling
• STRING DESCRIPTORS: sono descrittori opzionali e permettono di associare delle stringhe alfanumeriche alla periferica
Tutti i descrittori sono stati scelti in funzione delle specifiche esigenze di progetto e sono memorizzati come tabella nella memoria di programma (ROM) del microcontrollore. Il firmware completo è riportato in Appendice A.
Nel Report Descriptor deve essere comunicato anche il numero dei byte che l’host manda al device e viceversa. Nel nostro caso si è deciso di inviare dall’host verso il device 5 bytes e 17 bytes nel senso inverso.
I 5 bytes servono per inviare un messaggio al device per comunicargli cosa gli si richieda. Questi bytes saranno filtrati e saranno effettuate le operazioni richieste. In realtà 5 bytes sono molto più di quelli necessari, ma anche in questo caso sono stati considerati i futuri sviluppi.
I 17 bytes di risposta sono corrispondenti alle 8 acquisizioni sui sensori, ciuscuna di 2 bytes (di cui solo 10 bit sono significativi). Quindi, nei 17 bytes, 16 bytes sono le acquisizioni e un byte è un messaggio per l’host, che allo stato attuale non è necessario, ma anch’esso potrà essere usato nelle successive versioni del firmware.
9.6 Flusso del firmware
In figura 9.7 è dato un diagramma di flusso del programma implementato, che esemplifica la strategia adottata per l’acquisizione dei dati e il loro invio al PC: INIZIALIZZAZIONE DEL PIC16F877 CALIBRAZIONE DEL FRONT-END ANALOGICO (OFFSET E GUADAGNO) HANDSHAKE DI IDENTIFACAZIONE DELLA PERIFERICA USB ATTESA DI RICHIESTA DEI DATI DALL’HOST
Figura 9.7: Diagramma di flusso del firmware
ACQUISIZIONE DEI DATI E INVIO
ALL’HOST
FALSO
9.7 Interfaccia PC
Come accennato, l’interfaccia di alto livello fa uso del controllo ActiveX™ denominato UsbDaqOcx, realizzato appositamente per la gestione USB del sistema hardware di acquisizione descritto nei paragrafi precedenti. Tale sistema è stato progettato per consentire la generica acquisizione di segnali analogici. Nella versione attuale possono essere gestiti un massimo di otto canali e le informazioni sono filtrate dal controllo OCX.
Di seguito sono elencate le quattro funzionalità principali dell’interfaccia pubblica (interfaccia utente):
• BOOL UsbDaqOcx::Connect(long vendorID, long productID) • BOOL UsbDaqOcx::Disconnect()
• BOOL UsbDaqOcx::IsConnected()
• BOOL UsbDaqOcx::ReadChannels(double* ratedCapacity, double* channels)
I primi tre metodi sopra elencati sono di facile comprensione. In particolare, il metodo Connect consente di individuare una determinata periferica USB tramite gli identificatori di produzione (VID e PID). Il cuore della comunicazione risiede nel metodo ReadChannels, tramite il quale il client invia all’OCX un vettore di otto ratedCapacity i cui elementi indicano i valori di fondoscala per ogni canale da acquisire. Un valore di fondoscala pari a 0.0 indica che il canale corrispondente non dovrà essere preso in considerazione. Al termine della comunicazione con la periferica, i valori acquisiti sono restituiti nel vettore channels, anch’esso di otto
elementi, e l’i-esimo elemento è scalato nell’intervallo [0, ratedCapacity(i)]. Tutti i metodi menzionati restituiscono un valore pari a FALSE in caso di errore di comunicazione o di errore di trasferimento di dati, altrimenti TRUE.
L’interfaccia di alto livello, denominata HoodDlg e realizzata in ambiente MicrosoftVisualC++™, comunica con la periferica hardware USB in maniera trasparente tramite il controllo UsbDaqOcx prima descritto. L’interfaccia si occupa della sincronizzazione delle operazioni di comunicazione, nonché della visualizzazione ed esportazione dei dati acquisiti. In figura 9.8 è mostrata l’interfaccia grafica del software di alto livello.
Figura 9.8: Interfaccia grafica di HoodDlg
Tramite l’interfaccia di alto livello è possibile stabilire una connessione con la periferica hardware USB identificandola tramite gli identificatori VendorID e ProductID richiesti dal protocollo HID e definiti all’interno del firmware. Nell’interfaccia è inoltre impostato l’intervallo di tempo (espresso in millisecondi) tra due successive acquisizioni degli otto canali. Tale intervallo, dovendo sottostare alle esigenze del sistema operativo, è soggetto a leggere variazioni e dunque è mostrato all’utente per dare indicazioni circa le prestazioni riguardanti la velocità d’esecuzione del software. I dati relativi alle acquisizioni sono automaticamente scalati nell’intervallo specificato dal fondoscala, espresso in Volt, indicato tramite RatedCapacity. Durante l’acquisizione lo stato del controllo
UsbDaqOcx è visualizzato tramite quattro led grafici, il cui significato, dall’alto
verso il basso, è il seguente:
1. stato della connessione (verde = connesso, rosso = non connesso)
2. trasmissione dati (verde= trasmissione, nero = nessuna trasmissione)
3. ricezione dati (verde = ricezione, nero = nessuna ricezione)
4. errore (verde = nessun errore, rosso = errore)
Al termine dell’acquisizione, i dati relativi agli otto sensori risiedono nella RAM del PC e possono essere esportati in un file di testo sottoforma di matrice di numeri reali. Tale matrice ha nove colonne ed un numero di righe pari al numero di acquisizioni effettuate. Nella i-esima riga la prima colonna indica il tempo, espresso in millisecondi, della i-esima acquisizione; nelle successive 8 colonne sono indicati i valori di tensione, espressi in Volt, relativi agli altrettanti sensori durante la i-esima acquisizione.
Nel diagramma di figura 9.10 è illustrata la struttura a strati della programmazione in ambiente Windows, che riassume il funzionamento e la struttura gerarchica delle varie parti:
HoodDlg
Figura 9.10
L’intera architettura descritta, comprendente la scheda a microcontrollore, il software HoodDlg con il controllo UsbDaqOcx e le libreria del sistema operativo, sostituisce l’architettura precedente costituita dalla scheda NI6025E e dall’ambiente di programmazione LabView™, consentendo di limitare costi, ingombro e di aumentare la portabilità del sistema.
Attualmente l’interfaccia di alto livello ha funzionalità essenziali e la visualizzazione grafica non è stata curata per ragioni di efficienza e di semplicità.
USBDaqOCX CHidDevice Windows COM DLL USB API Driver USB Hub USB
9.8 Test e sviluppi futuri
Per il futuro è previsto un ampliamento del firmware del microcontrollore: sarà implementato, in parallelo al software, la possibilità di scegliere un numero ed una sequenza arbitraria di canali e il reset via firmware, saranno migliorate le procedure di calibrazione dell’offset e del guadagno dell’amplificatore da strumentazione, ottimizzata la routine di acquisizione e invio dei dati per renderla ancora più effeciente.
Il software avrà un’interfaccia ampliata che permetterà all’utente di scegliere, oltre all’avvio ed allo stop delle misure, anche il numero di cicli da effettuare, quali e quanti canali di acquisizione attivare, il reset del sistema.
Messa a punto una versione definitiva della scheda, si potrà procedere alla sua realizzazione su circuito stampato per avere una maggiore affidabilità, robustezza meccanica e dimensioni ridotte.
Le misure che saranno ottenute dalla scheda a microcontrollore saranno accuratamente confrontate con quelle realizzate per mezzo della scheda NI6025E, per appurare il buon funzionamento dell’elettronica.
È prevista una campagna di misure estensive nell’arco di alcuni mesi, da condurre con la scheda a microprocessore, per verificare la stabilità della risposta dei sensori ed eventualmente stimarne un tempo di vita medio.
