Condividi tramite

Scelta di un modello di driver per lo sviluppo di un driver client USB

  • Articolo

Questo argomento fornisce linee guida per la scelta del modello di driver migliore per lo sviluppo di un driver client USB che funge da driver di funzione del dispositivo.

I produttori di dispositivi USB devono spesso fornire un modo per consentire alle applicazioni di accedere alle funzionalità del dispositivo. Per scegliere il meccanismo migliore per accedere a un dispositivo USB, iniziare con l'approccio più semplice e passare a soluzioni più complesse solo se è necessario. L'elenco seguente riepiloga le scelte descritte in questo argomento:

  1. Se il dispositivo appartiene a una classe di dispositivo USB per cui Windows include un driver in arrivo, non è necessario scrivere un driver.
  2. Se il dispositivo non ha un driver di classe fornito da Microsoft e il dispositivo è accessibile da una singola applicazione, caricare WinUSB come driver di funzione.
  3. Se il dispositivo deve essere accessibile da applicazioni simultanee e il dispositivo non dispone di endpoint isochronous, scrivere un driver client basato su UMDF.
  4. Se driver di classe, soluzioni WinUSB o UMDF non sono opzioni che funzionano per l'utente, scrivere un driver client basato su KMDF.
  5. Se una particolare funzionalità non è supportata da KMDF, scrivere un driver ibrido che chiama routine WDM.

L'approccio più comune è stato quello di implementare un driver di dispositivo, (definito driver client USB in questo set di documentazione) e fornire un pacchetto di installazione che installa il driver come driver di funzione nello stack di dispositivi sopra lo stack di driver USB fornito da Microsoft. Il driver client espone un'interfaccia del dispositivo che le applicazioni possono usare per ottenere l'handle di file del dispositivo. Le applicazioni possono quindi usare questo handle di file per comunicare con il driver chiamando le API di Windows.

La scrittura di un driver personalizzato ai requisiti del dispositivo è il modo più flessibile per fornire l'accesso a un dispositivo USB. Tuttavia, l'implementazione di un driver richiede molto lavoro. Il driver deve eseguire attività complesse, ad esempio l'inizializzazione del driver quando vengono rilevati nuovi dispositivi, gestione energia, operazioni di I/O, rimozione delle sorprese, gestione dello stato e pulizia quando il dispositivo viene rimosso. Prima di scegliere di scrivere un driver, porre le domande seguenti:

È possibile usare un driver fornito da Microsoft?

Potrebbe non essere necessario scrivere un driver se:

  • Il dispositivo appartiene a una classe di dispositivo USB supportata da Microsoft.

    In tal caso, il driver di classe corrispondente viene caricato come driver di dispositivo. Per un elenco di classi di dispositivo per cui Windows include un driver in arrivo, vedere Driver di classe di dispositivo USB inclusi in Windows.

  • Il dispositivo non appartiene a una classe di dispositivo.

    Per tali dispositivi, valutare le funzionalità del dispositivo per determinare se è possibile caricare WinUSB (Winusb.sys) fornito da Microsoft come driver di funzione del dispositivo. L'uso di WinUSB è la soluzione migliore se:

    • Il dispositivo è accessibile da una singola applicazione.

    • Il dispositivo supporta endpoint bulk, interrupt o isochronous.

    • Il dispositivo è destinato a funzionare con un computer di destinazione che esegue Windows XP con Service Pack 2 (SP2) e versioni successive di Windows.

      Il caricamento di WinUSB come driver di funzione offre un'alternativa più semplice all'implementazione di un driver USB personalizzato. Ad esempio, WinUSB è l'approccio preferito per una stazione meteorologica elettronica accessibile solo da un'applicazione che viene inserita nel pacchetto con il dispositivo. È utile anche per la comunicazione diagnostica con un dispositivo e per il firmware flashing.

      Per semplificare l'invio di richieste a Winusb.sys, è possibile fornire una DLL in modalità utente, Winusb.dll, che espone funzioni WinUSB. Un'applicazione può chiamare queste funzioni per accedere al dispositivo, configurarla e trasferire i dati agli endpoint del dispositivo.

      WinUSB non è un'opzione se:

    • Il dispositivo è accessibile da più applicazioni.

    • Il dispositivo ha funzioni che dispongono già del supporto in modalità kernel nel sistema operativo Windows. Ad esempio, per le funzioni modem (che TAPI supporta) o le funzioni LAN (supportate da NDIS), è necessario usare l'interfaccia supportata dal driver Usbser.sys per gestire i dispositivi modem con software in modalità utente.

      In Windows 8 è stato aggiunto un nuovo ID compatibile all'installazione inF per WinUSB. Se il firmware del dispositivo contiene tale ID compatibile, WinUSB viene caricato per impostazione predefinita come driver di funzione per il dispositivo. Ciò significa che i produttori hardware non sono necessari per distribuire i file INF per i dispositivi WinUSB. Per altre informazioni, vedere Dispositivo WinUSB.

Se si scrive un driver client USB, quale modello di driver è migliore?

La risposta dipende dalla progettazione del dispositivo. In primo luogo, determinare se un particolare modello di driver soddisfa i requisiti. Alcune considerazioni sulla progettazione si basano su se si vuole che il dispositivo USB sia accessibile da più applicazioni simultanee e supporti lo streaming dei dati tramite endpoint isochronous.

Se si sceglie di scrivere un driver, ecco le opzioni seguenti:

  • Framework driver in modalità utente (UMDF)

    UMDF fornisce interfacce del driver di dispositivo (DDI) che un driver client può usare per l'integrazione con i componenti di Windows, ad esempio Plug and Play Manager e Power Manager. UMDF fornisce anche oggetti di destinazione specializzati per i dispositivi USB, che astraggono l'hardware in modalità utente e semplificano le operazioni di I/O per il driver. Oltre alle interfacce UMDF, WDF offre estensioni e strumenti di traccia del debugger avanzati per i driver in modalità utente. UMDF si basa sul modello a oggetti componente (COM) e lo sviluppo di un driver in modalità utente è più semplice per uno sviluppatore C++.

    Implementare un driver client basato su UMDF per un dispositivo USB nei casi seguenti:

    • Il dispositivo è accessibile simultaneamente da più applicazioni.

    • Il dispositivo supporta trasferimenti bulk o interruzioni.

      I driver che vengono eseguiti in modalità utente possono accedere solo allo spazio indirizzi utente (virtuale) e rappresentano un rischio molto più basso per il sistema. I driver in modalità kernel possono accedere allo spazio indirizzi del sistema e alle strutture di sistema interne. Un driver in modalità kernel non codificato potrebbe causare problemi che influiscono su altri driver o sul sistema e infine arrestano il computer. Pertanto, un driver in modalità utente può essere più sicuro di un driver in modalità kernel in termini di sicurezza e stabilità.

      Un altro vantaggio dei driver in modalità utente è che sfruttano tutte le API Win32. Ad esempio, i driver possono chiamare API, ad esempio Winsock, Compressione, API di crittografia e così via. Queste API non sono disponibili per i driver in modalità kernel.

      Un driver client basato su UMDF non è un'opzione per i dispositivi USB che supportano endpoint isochronous.

      Nota Windows 8.1 introduce la versione 2.0 di UMDF. Con UMDF versione 2.0, è possibile scrivere un driver UMDF nel linguaggio di programmazione C che chiama molti dei metodi disponibili per i driver KMDF. Non è possibile usare UMDF versione 2.0 per scrivere driver di filtro inferiori per USB.

  • Framework driver in modalità kernel (KMDF)

    KmDF è stato progettato per semplificare l'estensione dei modelli di driver per supportare nuovi tipi di hardware. KmDF fornisce DDIs e strutture di dati che rendono i driver USB in modalità kernel più facili da implementare rispetto ai driver WDM (Windows Driver Model). Inoltre, KMDF fornisce destinazioni di input/output specializzate (I/O) che è possibile usare per scrivere un driver client completamente funzionale che usa lo stack di driver USB Microsoft.

    In alcuni casi in cui una particolare funzionalità non è esposta tramite KMDF, il driver deve chiamare routine WDM. Il driver non deve implementare l'intera infrastruttura WDM, ma usa i metodi KMDF per accedere a un set di routine WDM selezionato. Ad esempio, per eseguire trasferimenti isochronous, un driver client basato su KMDF può inviare URL in stile WDM che descrivono la richiesta allo stack di driver USB. Tali driver sono chiamati driver ibridi in questo set di documentazione.

    KMDF supporta anche il modello di driver porta-miniport. Ad esempio, un driver miniport di streaming del kernel (ad esempio una webcam USB) che usa lo streaming del kernel sul bordo superiore può usare gli oggetti di destinazione USB I/O di KMDF per inviare richieste allo stack di driver USB. I driver NDIS possono essere scritti anche usando KMDF per gli autobus basati su protocollo, ad esempio USB.

    I driver WDM pure sono difficili da scrivere, complessi e non affidabili. Con l'evoluzione di KMDF, la scrittura di questo tipo di driver non è più necessaria.

Microsoft Visual Studio 2012 include rispettivamente modelli di driver e driver USB User-Mode Kernel-Mode USB che generano il codice iniziale per un driver client USB UMDF e KMDF. Il codice modello inizializza un oggetto dispositivo di destinazione USB per abilitare la comunicazione con l'hardware. Per altre informazioni, vedere gli argomenti seguenti:

Per informazioni su come implementare i driver UMDF e KMDF, vedere il libro Microsoft Press Sviluppo driver con Windows Driver Foundation.

Confronto tra funzionalità WinUSB, UMDF, KMDF

La tabella seguente riepiloga le funzionalità di driver USB basati su UMDF e driver USB basati su UMDF e driver USB basati su KMDF.

Funzionalità WinUSB UMDF KMDF
Supporta più applicazioni simultanee No Sì Sì
Isola lo spazio degli indirizzi del driver dallo spazio indirizzi dell'applicazione No Sì No
Supporta trasferimenti bulk, interruzioni e controlli Sì Sì Sì
Supporta trasferimenti isochronous Sì 4 No Sì
Supporta l'installazione di driver in modalità kernel, ad esempio i driver di filtro, come un livello overlying nello stack USB No No Sì
Supporta la sospensione selettiva e lo stato di attesa/riattivazione Sì Sì Sì

La tabella seguente riepiloga le opzioni WDF supportate da versioni diverse di Windows.

Versione di Windows WinUSB UMDF KMDF
Windows 8 Sì Sì Sì
Windows 7 Sì Sì Sì
Windows Vista Sì1 Sì1 Sì
Windows Server 2003 No No Sì
Windows XP Sì2 Sì2 Sì
Microsoft Windows 2000 No No Sì3

Sì1: WinUSB e UMDF sono supportati solo nelle versioni basate su x86 e x64 di Windows.

Sì2: WINUSB e UMDF sono supportati in Windows XP con Service Pack 2 (SP2) o versioni successive di Windows.

Sì3: KMDF è supportato in Windows 2000 con SP4 o versioni successive di Windows.

Sì4: i trasferimenti isochrono sono supportati in Windows 8.1 o versioni successive di Windows.

Tutti gli SKU client delle versioni a 32 bit di Windows XP con SP2support WinUSB. WinUSB non è nativo di Windows XP; deve essere installato con il co-installer WinUSB. Tutti gli SKU di Windows Vista e versioni successive di Windows supportano WinUSB.