Gestione della comunicazione tra scheda di acquisizione e sistema di elaborazione

La soluzione scelta per il collegamento della scheda hardware, descritta nel capitolo precedente, con il PC, è l’utilizzo di un’interfaccia USB, uno standard che sta progressivamente sostituendo quelli precedenti, come la comunicazione seriale e quella parallela, rispetto alle quali consente una gestione più efficace delle periferiche e una maggiore velocità di scambio dei dati. Grazie anche alla complessità del protocollo, con l’USB è possibile gestire praticamente tutti i tipi di periferica interfacciabili con un PC, caratteristica che, nel nostro caso, ha consentito di massimizzare le potenzialità di generalizzazione dell’architettura realizzata.

Una descrizione del protocollo USB, non esaustiva ma utile per comprenderne il funzionamento e reali potenzialità e limiti, viene fornita nel primo paragrafo. Successivamente, vengono descritti il firmware implementato nel microcontrollore e le modalità in cui la comunicazione viene gestita sia dal lato del microcontrollore stesso che da quello del PC.

5.1 Il protocollo USB

Il protocollo USB (Universal Serial Bus) è un’architettura di comunicazione seriale bidirezionale, nata per rispondere a problemi relativi al PC come la richiesta di un numero maggiore di porte disponibili o il collegamento alla linea telefonica, e più in

generale per soddisfare requisiti di flessibilità, velocità e contemporaneamente basso costo e facilità d’uso, dovuti alla necessità di un’ulteriore espansione e potenziamento dei PC.

In questo paragrafo faremo una descrizione dell’architettura generale di un sistema di comunicazione USB e dei formati utilizzati per la trasmissione dei dati; infine, vedremo le caratteristiche più importanti della classe HID, alla quale la scheda realizzata appartiene.

Per approfondimenti sull’argomento che, vista la sua complessità e gli scopi del presente lavoro, non può essere trattato in modo dettagliato, si rimanda a [26], [27] e [28].

5.1.1 Architettura generale di un sistema USB

In generale, un sistema USB è formato da un controllore (host), un insieme di dispositivi simultaneamente accessibili e una complessa modalità di interconnessione tra i dispositivi e di comunicazione tra questi e il controllore. L’host, responsabile e coordinatore di tutti gli accessi al bus, contiene un hub integrato, detto root hub, e rappresenta il vertice del sistema di comunicazione USB. Questo può essere raffigurato con una topologia ad albero stratificata, come evidenziato nella figura 5.1.

I dispositivi USB [26] si dividono in hub, ai quali possono essere connessi altri dispositivi, e funzioni, cioè periferiche con una o più funzionalità come stampanti, modem o scanner. Possono inoltre avere varie velocità: nella versione 1.1 dell’USB sono supportati dispositivi Low Speed o Full Speed, che scambiano dati con velocità rispettivamente di 1.5 e 12 Mbits/s; nella versione 2.0 sono stati aggiunti i dispositivi

High Speed, che hanno una velocità di 480 Mbits/s. Infine, sono raggruppati in classi

che definiscono comportamenti, protocolli e driver comuni per dispositivi con funzionalità simili; ad esempio ci sono gli HID (Human Interface Devices), come mouse e tastiere, i Communication devices come i modem e i Display devices come i monitor.

endpoint (EP), ovvero sorgenti o destinazioni indipendenti di dati che costituiscono i

terminali del flusso di comunicazione tra l’host e il dispositivo. Ogni endpoint è contraddistinto da un endpoint number e da una direzione dei dati: IN (dal dispositivo all’host) o OUT (dall’host al dispositivo). Appena un nuovo dispositivo viene collegato al bus comincia il processo di enumerazione, attraverso il quale l’host lo riconosce, gli assegna un indirizzo e ne abilita una configurazione. Questo succede, ad esempio, subito dopo il collegamento di un dispositivo ad una porta USB del PC. L’indirizzo del dispositivo, l’endpoint number e la direzione dei dati permettono l’identificazione univoca di ogni endpoint da parte dell’host. Questa modalità di comunicazione è schematizzata in figura 5.2.

Figura 5. 1: rappresentazione topologica di un sistema di comunicazione USB [27]. Si riconoscono l’host, al quale fa capo l’intero bus, e alcuni hub, ognuno dei quali può essere collegato a più dispositivi o funzioni (node nella figura).

Il raggruppamento degli endpoint in un’unità funzionale che svolge una delle possibili funzioni del dispositivo (pensiamo, ad esempio, ad un fax/scanner/stampante) è detto interfaccia. A livello software lo scambio di dati tra un host e un endpoint

avviene attraverso un canale di comunicazione logico detto pipe.

Altre caratteristiche di un endpoint sono i suoi requisiti di frequenza di accesso al bus, la dimensione massima dei pacchetti di dati che può mandare o ricevere e il tipo di trasferimento di dati che supportano. Questi ultimi sono parametri di caratterizzazione anche per le pipes.

Figura 5.2: dettaglio del sistema di comunicazione USB, i cui sono rappresentati i collegamenti tra l’host e gli endpoint di due dispositivi [26].

5.1.2 Formati di trasferimento dei dati

I trasferimenti di dati tra l’host e un dispositivo possono essere di quattro tipi:

control, interrupt, isochronous e bulk transfers. Ognuno di questi è formato da una

combinazione dei quattro pacchetti standard dell’USB: i token packets, che indicano il tipo di transizione: In, Out o Setup (ovvero control transfers); i data packets, che contengono l’informazione che si vuole trasferire e possono essere di tipo 0 o 1; gli

impossibilità di mandarne o riceverne da parte del dispositivo (NAK) o un messaggio di errore (STALL); gli start of frame packets, che indicano l’inizio di un nuovo frame.

Ognuno di questi pacchetti è costituito a sua volta da un certo numero di campi che possono essere di sei tipi diversi: Sync, con cui ogni pacchetto deve cominciare e che serve per sincronizzare il clock del trasmettitore e del ricevitore; PID (Packet ID), che indica il tipo di pacchetto che sta per essere inviato; ADDR, che specifica l’indirizzo;

ENDP, che indica il numero dell’endpoint; CRC, tramite il quale viene effettuato il

controllo di ridondanza ciclico; EOP, che indica al fine del pacchetto.

I trasferimenti di tipo isocrono (isochronous) sono periodici e continui, e tipicamente contengono segnali dipendenti dal tempo come quelli audio o video, garantendo l’accesso alla larghezza di banda dell’USB con una latenza limitata.

I bulk transfers, non supportati dai dispositivi low-speed, sono destinati alla trasmissione di grandi quantità di dati, come l’immagine generata da uno scanner; non si hanno garanzie di larghezza di banda o latenza.

I trasferimenti a interrupt tipicamente sono dedicati a supportare le richieste di dispositivi che mandano piccole quantità di dati non frequentemente, ma con latenza limitata. Si tratta di interruzioni un po’ particolari, in quanto è l’host che interroga periodicamente l’endpoint di interrupt, perciò il dispositivo che genera l’interruzione deve aspettare la richiesta di dati, cosa che avviene con un IN token packet (si ha in questo caso un’interruzione di tipo IN). Quando questa avviene, se il dispositivo ha un’interruzione in coda trasmette i dati e riceve in risposta un ACK; in caso contrario, restituisce un NAK, o uno STALL se avviene qualche errore sull’endpoint. Anche l’host può generare un’interruzione: in tal caso manderà al dispositivo un OUT token packet seguito dai dati di interrupt, e riceverà in risposta un ACK (interruzione di tipo OUT).

I control transfers sono usati dall’host per operazioni di comando o di controllo e per configurare il dispositivo durante l’enumerazione. In questa fase l’host comunica con gli EP0 IN e OUT (che devono essere supportati da tutti i dispositivi) attraverso la Default Control Pipe. Questi trasferimenti sono composti da tre stadi: il Setup Stage, che contiene l’indirizzo e l’endpoint number nel token packet e il tipo di richiesta nel data

packet; un Data Stage opzionale di tipo IN o OUT a seconda del tipo di richiesta; lo

Status Stage, che indica se la ricezione o trasmissione dei dati ha avuto o meno

successo.

In particolare, il setup packet del Setup Stage ha la struttura rappresentata nella figura 5.3.

Da questa si vede che l’host può inviare tre tipologie di richieste (bit D6_D5):

Standard Requests, comuni a tutti i dispositivi USB; Class Requests, comuni ai

dispositivi appartenenti ad una determinata classe; Vendor Requests, che variano da un dispositivo all’altro. Inoltre, ognuna di queste richieste può essere indirizzata a vari livelli (bit D4_D0): dispositivo, interfaccia, endpoint o altro.

Figura 5. 3: dettaglio del setup packet del Setup Stage di un Control Transfer [26].

Vediamo un po’ più in dettaglio i tre tipi di richieste standard, indirizzate rispettivamente a livello di dispositivo (Standard Device Requests), di interfaccia

(Standard Interface Requests )e di endpoint (Standard Enpoint Requests). Le Standard Device Requests, dettagliate in figura 5.4, sono otto [26]:

• GET_STATUS Request, alla quale il dispositivo risponde indicando se è alimentato o se deve prendere l’alimentazione dal bus;

• CLEAR_FEATURE e SET_FEATURE Requests, usate per impostare determinate caratteristiche del dispositivo;

• SET_ADDRESS Request, usata durante l’enumerazione per assegnare un indirizzo (indicato nel campo wValue) al dispositivo;

Figura 5.4: dettaglio delle Standard Device Requests [26], per ognuna delle quali vengono specificati i campi indicati in figura 5.3.

• SET_DESCRIPTOR e GET_DESCRIPTOR Requests, tramite le quali l’host può aggiornare o richiedere al dispositivo uno dei possibili descrittori (descriptors). Questi consistono in una strutture di dati aventi ognuna una composizione ben definita e contenenti informazioni sul dispositivo a vari livelli. I tipi più comuni di descrittore, organizzati gerarchicamente ad albero come in figura 5.5, sono: il

Device Descriptor, unico per ogni dispositivo, che dà informazioni come il

produttore, la classe e il numero di configurazioni possibili; i Configuration

Descriptors, che indicano, ad esempio, la modalità di alimentazione e la quantità

interfacce che questa ha; gli Interface Descriptors, che descrivono gli endpoint dell’interfaccia corrispondente; gli Endpoint Descriptors, che specificano i parametri caratterizzanti (direzione, dimensione massima dei pacchetti, etc.) dell’endpoint cui si riferiscono. Opzionamene, ci possono essere poi degli

String Descriptors, che forniscono stringhe contenenti informazioni sul

dispositivo (ad esempio il nome).

• GET_CONFIGURATION e SET_CONFIGURATION Requests, usate rispettivamente per richiedere la configurazione corrente e abilitare il dispositivo.

Le Standard Interface Requests sono cinque: GET_STATUS (che restituisce lo stato dell’interfaccia), CLEAR_FEATURE, SET_FEATURE, GET_INTERFACE e

SET_INTERFACE.

Le Standard Enpoint Requests, infine, sono di quattro tipi: GET_STATUS,

CLEAR_FEATURE, SET_FEATURE e SYNCH_FRAME.

Figura 5. 2: organizzazione gerarchica dei descrittori di un dispositivo USB [26].

5.1.3 La classe HID

Merita un ulteriore approfondimento la classe HID, che raggruppa i dispositivi usati dall’uomo per controllare le operazioni di un sistema informatico, in quanto, come

vedremo nel prossimo paragrafo, è quella scelta per la scheda realizzata. Oltre quelli già elencati, altri esempi sono i dispositivi di gioco o simulazione e strumenti di misura che non richiedono l’interazione umana ma forniscono dati in un formato simile agli altri HID, come termometri o voltmetri.

Un HID [28] comunica con l’host usando sia la Interrupt In che la Control pipe. La prima costituisce il canale di ricezione delle interruzioni generate dal dispositivo e di trasmissione di dati a bassa latenza a quest’ultimo; la seconda viene utilizzata per rispondere alle richieste di controllo standard dell’USB, ricevere dati dall’host e trasmettere dati in seguito ad un’interrogazione da parte dell’HID driver. Più in particolare, nell’Interrupt pipe il dispositivo trasmette dati all’host organizzandoli in una o più transizioni, con un formato predefinito, che nel loro complesso costituiscono un

Report. Un’eccezione a questa modalità ci comunicazione è costituita da dispositivi

come mouse o tastiere, che richiedono un supporto del BIOS (Boot Devices), i quali utilizzano un altro protocollo, il Boot Protocol. Per altri dispositivi si può scegliere il tipo di protocollo da usare.

Un Report può essere inviato anche nella Control Pipe come risposta ad una Class

Request dell’HID, la GET_REPORT. La struttura in cui sono organizzati i dati del

Report di un HID è dettagliata in un descrittore proprio di questa classe, il Report

Descriptor. Nell’albero dei descrittori, questo si trova sotto l’HID Descriptor, il quale a

sua volta si dirama dall’Interface Descriptor. Nell’HID Descriptor sono contenute informazioni come il numero dei descrittori di classe (pari almeno a uno, il Report Descriptor) e la lunghezza del Report Descriptor. Quest’ultimo, invece, non è costituito semplicemente da una tabella di valori, bensì è formato da vari campi che forniscono informazioni sui dati trasmessi dal dispositivo, come il valore minimo e quello massimo e la lunghezza dei dati restituiti in risposta a varie richieste dall’host. In seguito alla richiesta di un Report Descriptor, un’applicazione è in grado di sapere come maneggiare i dati provenienti dal dispositivo e per cosa questi possono essere usati.

Altri tipi di richiesta proprie dell’HID sono: SET_REPORT Request, che permette all’host di inviare un Report al dispositivo (che può anche ignorare la richiesta);

impostare l’intervallo di tempo minimo che deve intercorrere tra due eventi nella Interrupt pipe; GET_PROTOCOL e SET_PROTOCOL Requests, tramite le quali l’host legge e cambia il protocollo del dispositivo (Boot o Report).

5.2 Firmware del microcontrollore per la gestione

della scheda e della comunicazione con il PC

A questo punto possiamo esaminare il programma implementato nel microcontrollore e le sue varie fasi di esecuzione, approfondendo in particolare le modalità di utilizzo del protocollo USB per la comunicazione tra il microcontrollore e il PC. Tale comunicazione, come detto, è resa possibile dal PDIUSBD12, che svolge la funzione di interfaccia.

5.2.1 Flusso del firmware

Nel momento in cui la scheda viene collegata all’alimentazione, il microcontrollore provvede innanzitutto ad abilitare il PDIUSBD12. La comunicazione tra i due integrati avviene tramite i comandi specifici di quest’ultimo, che sono di tre tipi [23]:

•

abilitazione del dispositivo. Tra questi vi sono il Set Address/Enable, che assegna l’indirizzo al dispositivo e abilita la funzione, il Set Endpoint/Enable, che abilita l’endpoint su cui deve avvenire la comunicazione e il Set DMA, che consente l’abilitazione e la gestione del DMA.

•

gestire la comunicazione tra PDI e microcontrollore. Alcuni comandi di questo tipo sono: Read Interrupt Register, tramite il quale i microcontrollore legge sul bus del PDI l’origine di un interrupt; Read Buffer e Write Buffer, che permettono di accedere al buffer in lettura e in scrittura; Clear Buffer, con cui il

microcontrollore pulisce il buffer dopo la lettura dei dati; Validate Buffer, con cui indica la validità dei dati scritti sul buffer;

•

un segnale di resume per 10 ms, e il Read Current Frame Number, che restituisce il numero di frame dell’ultimo SOF ricevuto con successo.

Figura 5.6: diagramma di flusso del firmware. Subito dopo il collegamento del circuito all’alimentazione, vengono inizializzati i registri del microntrollore e viene avviata la procedura di abilitazione del PDIUSBD12. A questo punto il programma entra in un ciclo in cui verifica se sul PDI è arrivata una richiesta di interruzione sugli EP (EP0 In, EP0 Out, EP1 IN e EP1 Out): se questo avviene, legge il tipo di interruzione ed entra nella subroutine specifica di risposta. Una volta che questa si è conclusa con successo, il programma torna al ciclo principale.

Nella fase di abilitazione il microcontrollore provvede tra l’altro, con i comandi di inizializzazione, alla disattivazione del DMA e all’abilitazione dell’EP1 (l’EP0 è abilitato per default).

Una volta completata questa fase, il microcontrollore rimane in un ciclo in cui controlla, tramite il comando Read Interrupt Register, se è arrivata una richiesta di interruzione al PDI da parte dell’host e, eventualmente, su quale endpoint: EP0 In, EP0 Out, EP1 In o EP1 Out. A seconda dell’origine dell’interruzione, il microcontrollore avvia una diversa procedura di risposta.

In figura 5.6 è rappresentato il diagramma di flusso del firmware.

5.2.2 Trasferimenti sull’EP0

Sull’EP0 In e sull’EP0 Out del PDI arrivano, da parte del sistema operativo, le richieste standard della comunicazione USB, viste nel paragrafo 5.1, in seguito alle quali il microcontrollore richiama la parte di programma in cui è contenuta la procedura di risposta. Gli accessi in scrittura avvengono sull’EP0 In.

In particolare, subito dopo il collegamento della scheda al PC comincia, attraverso questi due canali, il processo di enumerazione, in cui il sistema operativo raccoglie le informazioni essenziali sulla periferica connessa e le sue caratteristiche, come il consumo di potenza, la modalità di alimentazione e il numero e tipo di endpoint. Dopo aver ricevuto queste informazioni, l’host assegna al dispositivo un indirizzo e abilita una configurazione, consentendo il trasferimento di dati sul bus.

In generale la sequenza dei passi in cui avviene l’enumerazione dipende dal tipo di sistema operativo. Tipicamente in questa fase viene richiesto anche di fornire un driver, che però può non servire se il dispositivo è compreso all’interno di determinate modalità di funzionamento, nel qual caso è sufficiente definire i descrittori standard del protocollo USB e inviarli all’host se richiesti.

Nel caso del sistema realizzato i descrittori, ognuno dei quali è stato configurato in base a specifiche esigenze di progetto, si trovano in una tabella contenuta nella memoria di programma del microcontrollore (vedi Appendice B). In seguito alla richiesta da

parte dell’host di uno specifico descrittore, questo viene prelevato dalla tabella e trasmesso sull’EP0 In.

Nel Device Descriptor, tra le altre cose, il dispositivo viene definito come una periferica Low Speed di classe HID. Quest’ultima caratteristica implica, tra l’altro, alcune importanti limitazioni: il non rispetto del protocollo da parte del firmware ha come conseguenza la perdita dei dati; ogni transazione deve avvenire in pacchetti con un numero fissato di byte, pari a 8 per le periferiche Low Speed; la massima velocità non è garantita. Tuttavia, le specifiche di progettazione in termini di quantità e velocità di trasferimento dei dati consentono alla scheda realizzata di rientrare largamente in queste limitazioni, e nel complesso l’utilizzo dell’HID è stato molto vantaggioso per lo sviluppo del software.

Nel Report Descriptor vengono indicati il numero di byte di cui devono essere composti i Report sull’EP1 In e Out, pari rispettivamente a 17 e a 5.

Altre informazioni contenute nei descrittori sono il fatto che la periferica sia autoalimentata (nel Configuration Descriptor) e il numero di endpoint pari a 2 (nell’Interface Descriptor).

5.2.3 Trasferimenti sull’EP1

Sull’EP1 In e sull’EP1 Out arrivano le richieste di interruzione generate dall’utente attraverso un’interfaccia software ad alto livello (vedi paragrafo successivo).

Le richieste inviate con queste interruzioni avvengono tramite comandi creati ad hoc per il controllo della scheda realizzata. Ognuno di questi comandi è definito all’interno del software ad alto livello, mentre nel firmware del microcontrollore, come detto, si trova la procedura di risposta. L’host invia il comando trasmettendo un

OUTPUT_REPORT, costituito da 5 byte, dei quali il primo indica il codice del comando

specifico da cui dipende il significato degli altri quattro. Il microcontrollore esegue la procedura di risposta e alla fine invia all’host un INPUT_REPORT di 17 byte; di questi, il primo è un codice che indica che tale procedura è stata eseguita correttamente (MSG_OK), mentre gli altri sedici dipendono dal tipo di comando. Le caratteristiche di

configurazione di questi trasferimenti, come il numero di byte, sono indicate nel Report Descriptor, come detto nel paragrafo precedente.

Seguendo queste modalità sono stati implementati tre tipi di comando:

•

comando ne legge il secondo byte e setta con il suo valore il potenziometro digitale di controllo della valvola. Invia poi un INPUT_REPORT costituito da MSG_OK seguito da sedici byte di valore qualunque.

•

valore OFF a 10 bit con cui impostare il valore della tensione in ingresso al convertitore A/D per tutti i canali, mentre il quarto contiene il dato con cui programmare il potenziometro digitale del secondo stadio di amplificazione per impostare il guadagno voluto dall’utente. Una volta letti i dati, il microcontrollore setta questo potenziometro, poi impone per ogni canale una tensione in ingresso al convertitore A/D il più possibile vicina al valore:

V OFF V_{off 10} 2 5 ⋅ = (5.1)

Questo avviene tramite un algoritmo che, per ogni canale, effettua una serie di acquisizioni, confrontando di volta in volta il valore ottenuto, memorizzato nei registri ADRESH e ADRESL (vedi paragrafo 4.3.4), con OFF; in base a questo, regola il potenziometro di offset fino a quando, con approssimazioni successive, la differenza tra il valore acquisito e OFF risulta minima. Infine, invia un INPUT_REPORT costituito da MSG_OK seguito da sedici byte di valore qualunque.

•

il settaggio del bit i-esimo indica che bisogna fare un’acquisizione dal canale con indirizzo i. Il microcontrollore salva questo byte in un registro, ne legge i bit uno alla volta e per ogni bit settato imposta il multiplexer con l’indirizzo corrispondente ed effettua un’acquisizione. Considerando che il convertitore

A/D è a 10 bit, per ognuna di queste sono necessari due byte. I risultati vengono salvati di volta in volta, tramite indirizzamento indiretto, in una tabella di 16 byte in cui ogni coppia consecutiva corrisponde all’acquisizione di un canale: i primi due byte contengono il risultato dell’acquisizione dal canale con indirizzo 0, il terzo e il quarto byte quello dell’acquisizione dal canale con indirizzo 1, e così via. Se da un canale l’acquisizione non viene effettuata (perché il bit corrispondente non è settato) la coppia di byte corrispondente della tabella viene saltata. Una volta compiute queste operazioni, viene inviato un INPUT_REPORT in cui il primo byte corrisponde al MSG_OK, mentre negli altri sedici viene posta la tabella.

5.3 Interfaccia di comunicazione sul lato PC

La comunicazione USB dal lato PC è gestita automaticamente dal sistema operativo durante la fase di enumerazione. Per le fasi successive, è stato utilizzato l’ambiente di programmazione Microsoft® VisualC++® per consentire la gestione della scheda da parte dell’utente.

In particolare, è stata realizzata una struttura software in cui un’interfaccia grafica di alto livello, implementata nel software denominato ChewingDialog, consente all’utente di inviare alla periferica USB i comandi visti nel paragrafo precedente (MOVE, CALIBRATE e GET_DATA), oltre a quelli per l’attivazione e la disattivazione della connessione. Il software si occupa anche della sincronizzazione delle operazioni di comunicazione e della scrittura su file dei dati acquisiti.

Per la gestione della comunicazione, ChewingDialog utilizza un controllo ActiveX di Windows (protocollo COM) denominato USBChewingOcx; questo, a sua volta, fa uso della libreria di medio livello CHidDevice, appositamente realizzata per la gestione di una periferica USB che comunica con il protocollo HID. Questa libreria, infine, utilizza altre librerie software a basso livello di Windows, di tipo API (Application Program

operativo.

In figura 5.7 è rappresentato un diagramma a blocchi che descrive la gerarchia software di comunicazione.

Figura 5.7: diagramma a blocchi della struttura software per la gestione del sistema. L’utente utilizza il programma ChewingDialog, contenente una semplice interfaccia grafica con cui può inviare al firmware, attraverso la struttura rappresentata, i comandi Connect, Disconnect, MOVE, CALIBRATE e GET_DATA.

Le funzioni principali utilizzate dall’utente tramite ChewingDialog e definite all’interno di USBChewingOcx sono (vedi Appendice C):

• BOOL CUsbChewingOcx::Connect(long vendorID, long productID), che effettua la connessione alla periferica USB individuandola tramite il VendorID e il ProductID indicate nel Device Descriptor;

• BOOL CUsbChewingOcx::Disconnect(), che disconnette la periferica;

• BOOL CUsbChewingOcx::Move(double openCoeff), che invia il comando MOVE al microcontrollore. Il numero reale openCoeff rappresenta il coefficiente di apertura della mandibola, che il programma traduce nel valore D, prelevato dall’OUTPUT_REPORT dal microcontrollore e memorizzato, come abbiamo visto, nel potenziometro digitale di comando della valvola, in base alla relazione:

256 ⋅ = openCoeff

D (5.2)

• BOOL CUsbChewingOcx::Calibrate(double offsetV, double gain), che invia il comando CALIBRATE. I numeri reali offsetV e gain rappresentano rispettivamente il valore della tensione di offset con cui l’utente intende impostare i canali e il valore di guadagno del secondo stadio di amplificazione del circuito. A partire da questi parametri il software calcola i numeri interi OFF e Dg (rispettivamente a 10 e 8 bit) da trasmettere al microcontrollore per regolare l’offset e impostare il potenziometro di guadagno, dalle seguenti relazioni (per la seconda vedi paragrafo 4.4.4; per la prima notiamo che, in base al paragrafo precedente, otteniamo banalmente che offsetV =Voff ):

(

)

• BOOL CUsbChewingOcx::GetData(double* ratedCapacity, double* channels),

ratedCapacity indica il fondoscala cui adeguare i valori delle acquisizioni

dall’i-esimo canale; una volta scalati, tali valori vengono memorizzati, nella stessa posizione, nel vettore channels. Ovvero, se x è il valore a 10 bit acquisito i dall’i-esimo canale del multiplexer, avremo:

[ ]

[ ]

Mettere ratedCapacity[i]=0 indica che non bisogna fare acquisizioni dal canale

corrispondente. In base a questo, il software imposta il valore del secondo byte dell’OUTPUT_REPORT, che indica al microcontrollore da quali canali deve eseguire le acquisizioni (vedi paragrafo 5.2.3).

Durante l’utilizzo dell’interfaccia lo stato del controllo OCX è rappresentato da quattro led grafici (vedi figura 5.8) che indicano rispettivamente (dall’alto al basso): stato della connessione (verde = connesso, rosso = non connesso); trasmissione dati (verde = trasmissione in corso, nero = nessuna trasmissione); ricezione dati (verde = ricezione, nero = nessuna ricezione); errore (verde = nessun errore, rosso = errore).

Figura 5.8: interfaccia grafica di ChewingDialog. I led grafici rappresentano lo stato del controllo OCX.

La semplice interfaccia grafica realizzata rappresenta, in realtà, una soluzione provvisoria per verificare il funzionamento della comunicazione con la scheda e la corretta esecuzione dei comandi. Nella versione definitiva verrà sostituita dal driver per

l’interfacciamento con ARI (vedi capitolo 6).

Le funzioni principali della libreria CHidDevice utilizzate dal controllo ActiveX, per

la definizione delle quali rimandiamo al listato delle parti principali del programma in Appendice C, sono: Open, che consente la connessione al dispositivo USB; Close, che

disabilita tale connessione; Read, che preleva un INPUT_REPORT; Write, che

trasmette un OUTPUT_REPORT. Tutte queste funzioni restituiscono un valore booleano, pari a TRUE se le operazioni vanno a buon fine.

Utilizzando l’interfaccia grafica, sono state eseguite delle misure in cui, dopo aver impostato dei valori di guadagno e di offset, si sono effettuate una serie di acquisizioni dai due canali della scheda realizzata; i risultati venivano man mano inseriti in un file. Acquisendo i dati in corrispondenza di un ingresso nullo, si è verificato che i valori salvati su questo file coincidevano, a meno di un errore minimo, con il valore precedentemente impostato per l’offset, appurando così il corretto funzionamento della comunicazione.