Condividi tramite

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

  • Articolo

Questo articolo 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 alle applicazioni un modo per 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 articolo:

  1. Se il dispositivo appartiene a una classe di dispositivo USB per cui Windows include un driver posta in arrivo, non è necessario scrivere un driver.
  2. Se il dispositivo non ha un driver di classe fornito da Microsoft e solo una singola applicazione accede al dispositivo, caricare WinUSB come driver di funzione.
  3. Se si accede al dispositivo da applicazioni simultanee e il dispositivo non dispone di endpoint isocroni, scrivere un driver client basato su UMDF.
  4. Se le soluzioni driver di classe, WinUSB o UMDF non sono opzioni che funzionano, 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 consiste nell'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 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 in base 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:

  • Inizializzazione del driver quando vengono rilevati nuovi dispositivi
  • Risparmio energia
  • Operazioni I/O
  • Rimozione di dispositivi a sorpresa
  • Gestione dello stato
  • 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 dispositivi USB supportata da Microsoft.

    In tal caso, il driver di classe corrispondente viene caricato come driver di dispositivo. Per un elenco delle classi di dispositivo per le quali Windows include un driver di posta in arrivo, vedi Driver di classe di dispositivi 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 isocroni.

    • Il dispositivo deve 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 meteo 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 flashing del firmware.

      Per semplificare l'invio di richieste a Winusb.sys da parte delle applicazioni, è disponibile una DLL in modalità utente, Winusb.dll, che espone le funzioni WinUSB. Un'applicazione può chiamare tali funzioni per accedere al dispositivo, configurarlo e trasferire i dati agli endpoint del dispositivo.

      WinUSB non è un'opzione se:

    • Il dispositivo è accessibile da più applicazioni.

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

      A partire da Windows 8, è stato aggiunto un ID compatibile all'installazione di 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 di hardware non sono tenuti a 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. Prima di tutto, determinare se un particolare modello di driver soddisfa i requisiti. Alcune considerazioni di progettazione sono basate sul fatto che si desideri che il dispositivo USB sia accessibile da più applicazioni simultanee e supporti lo streaming dei dati tramite endpoint isocroni.

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

  • Framework driver in modalità utente (UMDF)

    UMDF fornisce interfacce del driver di dispositivo (DDI) che un driver client può usare per l'integrazione con 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 avanzate del debugger e strumenti di traccia per i driver in modalità utente. UMDF si basa sul modello a oggetti del 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 interrupt.

      I driver eseguiti in modalità utente possono accedere solo allo spazio indirizzi utente (virtuale) e comportano un rischio inferiore per il sistema. I driver in modalità kernel possono accedere allo spazio degli indirizzi del sistema e alle strutture di sistema interne. Un driver in modalità kernel codificato male potrebbe causare problemi che interessano altri driver o il sistema e alla fine 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 possono usare tutte le API Win32. Ad esempio, i driver possono chiamare API come 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 isocroni.

      Nota

      Windows 8.1 ha introdotto 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.

  • Kernel-Mode Driver Framework (KMDF)

    KMDF è stato progettato per semplificare l'estensione dei modelli di driver per supportare nuovi tipi di hardware. KMDF fornisce DDI e strutture di dati che semplificano l'implementazione dei driver USB in modalità kernel rispetto ai driver WDM (Windows Driver Model). Inoltre, KMDF fornisce destinazioni di input/output (I/O) specializzate 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 viene 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 selezionato di routine WDM. Ad esempio, per eseguire trasferimenti isocroni, un driver client basato su KMDF può inviare URL in stile WDM che descrivono la richiesta allo stack di driver USB. Tali driver sono denominati driver ibridi in questo set di documentazione.

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

    I driver WDM puri 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 include modelli driver in modalità utente USB e driver in modalità kernel USB che generano il codice di avvio rispettivamente per un driver client USB UMDF e KMDF. Il codice del modello inizializza un oggetto dispositivo di destinazione USB per abilitare la comunicazione con l'hardware. Per altre informazioni, vedere gli articoli seguenti:

Per informazioni su come implementare driver UMDF e KMDF, vedere il libro Microsoft Press Developing Drivers with the Windows Driver Foundation( Sviluppo di driver con Windows Driver Foundation).

Confronto tra funzionalità WinUSB, UMDF, KMDF

La tabella seguente riepiloga le funzionalità dei driver USB basati su WinUSB, UMDF e i driver USB basati su KMDF.

Funzionalità WinUSB UMDF KMDF
Supporta più applicazioni simultanee No Sì Sì
Isola lo spazio indirizzi del driver dallo spazio indirizzi dell'applicazione No Sì No
Supporta trasferimenti bulk, interrupt e control Sì Sì Sì
Supporta trasferimenti isocroni Sì 4 No Sì
Supporta l'installazione di driver in modalità kernel, ad esempio i driver di filtro, come 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 11 Sì Sì Sì
Windows 10 Sì Sì Sì
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 isocroni sono supportati in Windows 8.1 o versioni successive di Windows.

Tutti gli SKU client delle versioni a 32 bit di Windows XP con SP2 supportano WinUSB. WinUSB non è nativo di Windows XP, deve essere installato con il coinstallatore WinUSB. Tutti gli SKU di Windows Vista e le versioni successive di Windows supportano WinUSB.