Sulla scia del fermento intorno alla nuova runtime per l’interfacciamento con dispositivi a sensore introdotta in Windows 7, abbiamo realizzato un dispositivo “end-to-end” che permette al sistema operativo di utilizzare un accelerometro a 3 assi (l’ADXL-330, reso famoso dai controller della Wii, che ne hanno accelerato, senza giochi di parole, la diffusione) come periferica di tipo “sensore”, come illustrato nell’immagine che segue, in cui è mostrato il dispositivo all’interno del Device Manager di Windows:
Chi ha già dato un’occhiata alle Sensor API, avrà notato che Microsoft ha già classificato in categorie i sensori previsti (di movimento, biometrici, elettrici, ecc.) e per molti di essi è stato già fatto un tentativo di standardizzazione in termini di struttura dei dati esposti. Nel realizzare il nostro dispositivo ci siamo pertanto attenuti a tale categorizzazione, con l’intento di far funzionare il tutto senza toccare neanche una riga del client realizzato per l’hardware “ufficiale” che ha accompagnato già dalle prime dimostrazioni la SensorAPI di Windows 7, ossia la scheda della Freescale, con l’indubbio valore aggiunto però di funzionare in maniera completamente wireless!
Tale compatibilità “binaria”, oltre a richiedere che il dispositivo sia “decorato” dagli appositi metadati, ha imposto anche uno “shaping” dei dati ben preciso, attraverso l’inclusione all’interno di un contenitore (denominato “report”) in verità di per se’ molto poco tipizzato. Nel caso del nostro dispositivo, ad esempio, un sensore di movimento a tre assi ha richiesto che il report fosse costituito da un Dictionary contenente una coppia chiave-valore in cui la chiave fosse rappresentata da un ben preciso guid ed il valore da una lista di tre valori decimali (relativi alle componenti dell’accelerazione misurata in ciascuno dei tre assi).
Oltre alla realizzazione “fisica” della scheda, il dispositivo ha richiesto ovviamente la realizzazione di un apposito driver, in questo caso rappresentato da una dll (il driver in questione è infatti un UMDF e non un driver kernel, appoggiandosi in gran parte ad un’infrastruttura basata su architettura COM) compilata tramite il compilatore C++ contenuto nel WinDDK, l’SDK che Microsoft mette a disposizione per lo sviluppo di device driver. Il driver in questione (la scrittura del quale ha rappresentato effettivamente la parte più “rognosa” dello sviluppo del prototipo) viene installato in Windows 7 mediante un tool (devcon.exe) che, per tramite di un altro componente di supporto (il cosiddetto “CoInstaller”) ed un file .inf (analogo a quello di una qualsiasi altro device driver), registra effettivamente il nuovo dispositivo nel sistema.
Una volta registrato, il dispositivo diventa quindi disponibile per tutte le applicazioni, indipendentemente dal fatto che questo ad esempio utilizzi “risorse” tipicamente ad uso esclusivo da parte di un solo processo (come una porta seriale, ad esempio). Nel Pannello di Controllo il dispositivo viene reso effettivamente visibile attraverso la spunta del checkbox di attivazione, come illustrato nell’immagine seguente:
Lo screenshot sottostante mostra più istanze dello stesso client (puramente diagnostico, in questo caso) collegate alla medesima fonte dati costituita dal dispositivo in questione. L’interfaccia del client mostra sinteticamente l’accelerazione misurata su ciascuno degli assi (come riferimento, ogni “tick” rappresenta circa 0.5 G di accelerazione):
Il dispositivo (prototipale) ospiterà presto altri sensori (il che spiega il nome, dopo tutto), ma per il momento si presenta così:
A questo punto non ci rimane che trovare un utilizzo plausibile per un dispositivo potenzialmente in grado di comunicare ad esempio la propria inclinazione al nostro PC a 1.6 km di distanza…un cucchiaione da paiolo remotizzato che dall’interno dell’auto ci permette di girare la polenta sui fornelli durante tutto il tragitto tra ufficio e casa?