L'hardware ha fascino, non c'è dubbio. Chi ha la passione per il software come il sottoscritto, sente un sapore particolare nel programmare un microcontrollore e toccare con mano il proprio operato sul "metallo".
La porta seriale ha sempre svolto il mestiere di jolly per interfacciare qualsiasi tipo di periferica e anche i programmatori hanno avuto vita piuttosto semplice nell'usare la seriale.
Poi è arrivata la USB. Bella, veloce e pratica ma decisamente ostile per un developer. Il perché è semplice. Le categorie di device (e quindi di driver) dipendono dalla funzione svolta. Perciò se il device è un mouse o una tastiera, Windows sa già cosa fare e quindi basta il device generico "HID" (Human Interface Device). Al di fuori di questo è necessario un device driver specifico dal produttore.
A parte il fatto che con lo scempio di driver che ci sono in giro, tremo tutte le volte che ne devo installare uno, ma qui vado offtopic, il problema è che il device driver non basta ma:
- ho bisogno di documentazione per sapere come comunicare con il device
- in alcuni casi ho bisogno di un sdk
- la periferica spesso è in uso esclusivo per una sola applicazione
A semplificare un pochino le cose molti device fanno finta di essere madrelingua USB e si limitano a usare un dispositivo USB to Serial che usa la USB come protocollo fisico ma viene visto come seriale da Windows. Ma questo non risolve tutto in particolare il problema dell'uso esclusivo.
L'uso esclusivo è un problema grosso, pensiamo ad esempio ad un GPS, tradizionalmente un device seriale (over bluetooth di solito) di cui più applicazioni possono avere bisogno.
Poi arriva Windows 7 e un nuovo layer di API specifiche per i sensori e la storia cambia radicalmente.
Il device ed il suo driver non devono cambiare nulla rispetto a prima. Se il device ha bisogno di un driver questo continua ad esistere. Se invece usa la seriale, continuerà a non dover fare nulla.
Le Sensor API hanno però bisogno di un altro driver, molto più semplice, parliamo di un oggetto COM multithreading in usermode sviluppato con il device driver kit "UMDF" (User Mode Driver Framework). Le funzioni di questo driver sono:
- normalizzare il dialogo tra Windows e il device in modo 'standard'. In questo driver vengono affogata la flowchart di comunicazione con il device: il protocollo di comunicazione.
- normalizzare il contenitore dei dati affiancando un timestamp che indichi quando sono stati campionati
- gestire la "ownership" del device. Quindi il nuove driver funge da proprietario e fa da gateway per tutte le applicazioni che vogliono usare quel device
- garantire la continuità della comunicazione da un altro processo, quello del driver. Se quindi freezo la mia applicazione e poi riprendo dopo qualche secondo, i dati mi arrivano tutti perché il driver sa dove ero arrivato.
Chi realizza il driver? Si spera che il produttore veda un business in questo ma chiunque sappia comunicare con il device al vecchio modo può realizzare questo driver "wrapper". Naturalmente C++ e COM sono necessari ma il codice da scrivere è proprio poco.
Poi arriviamo noi che sviluppiamo applicazioni. Scarichiamo il CodePack, e con poche righe di C# (o vb.net, o F#, ...) si accede ai dati del sensore. Poi avviamo due, tre, quattro istanze dell'applicazione e tutte possono accedere a questi dati ... cool!
L'architettura delle Sensor API prevede la categorizzazione dei sensori: accelerometri, sensori di luce, GPS (fisici o virtuali basati su WiFi), ma anche di creare nuove categorie.
A TechDays/WPC farò vedere anche i sensori (compresi i device driver UMDF) nella mia sessione sulle novità delle API in Windows 7/2008 R2.