Partager via

Choisir un modèle de pilote pour développer un pilote client USB

  • Article

Cet article fournit des instructions pour choisir le meilleur modèle de pilote pour le développement d’un pilote client USB qui agit comme pilote de fonction de l’appareil.

Les fabricants d’appareils USB doivent souvent fournir un moyen aux applications d’accéder aux fonctionnalités de l’appareil. Pour choisir le meilleur mécanisme d’accès à un périphérique USB, commencez par l’approche la plus simple et passez à des solutions plus complexes uniquement si nécessaire. La liste suivante récapitule les choix abordés dans cet article :

  1. Si votre appareil appartient à une classe de périphérique USB pour laquelle Windows inclut un pilote de boîte de réception, vous n’avez pas besoin d’écrire un pilote.
  2. Si votre appareil n’a pas de pilote de classe fourni par Microsoft et qu’une seule application accède à l’appareil, chargez WinUSB en tant que pilote de fonction.
  3. Si l’appareil est accessible par des applications simultanées et que votre appareil n’a pas de points de terminaison isochroniques, écrivez un pilote client basé sur UMDF.
  4. Si le pilote de classe, WinUSB ou les solutions UMDF ne sont pas des options qui fonctionnent pour vous, écrivez un pilote client basé sur KMDF.
  5. Si une fonctionnalité particulière n’est pas prise en charge par KMDF, écrivez un pilote hybride qui appelle des routines WDM.

L’approche la plus courante consiste à implémenter un pilote de périphérique (appelé pilote client USB dans ce jeu de documentation) et à fournir un package d’installation qui installe le pilote en tant que pilote de fonction dans la pile de périphériques au-dessus de la pile de pilotes USB fournie par Microsoft. Le pilote client expose une interface d’appareil que les applications peuvent utiliser pour obtenir le handle de fichier de l’appareil. Les applications peuvent ensuite utiliser ce handle de fichier pour communiquer avec le pilote en appelant des API Windows.

L’écriture d’un pilote personnalisé aux exigences de l’appareil est le moyen le plus flexible de fournir l’accès à un périphérique USB. Toutefois, l’implémentation d’un pilote nécessite beaucoup de travail. Le pilote doit effectuer des tâches complexes, telles que :

  • Initialisation du pilote quand de nouveaux appareils sont détectés
  • Gestion de l'alimentation
  • Opérations d’E/S
  • Suppression surprise de l’appareil
  • Gestion de l’état
  • Nettoyage lorsque l’appareil est supprimé

Avant de choisir d’écrire un pilote, posez les questions suivantes :

Pouvez-vous utiliser un pilote fourni par Microsoft ?

Vous n’avez peut-être pas besoin d’écrire un pilote si :

  • Votre appareil appartient à une classe d’appareil USB prise en charge par Microsoft.

    Dans ce cas, le pilote de classe correspondant est chargé en tant que pilote de périphérique. Pour obtenir la liste des classes d’appareils pour lesquelles Windows inclut un pilote de boîte de réception, consultez les pilotes de classe de périphérique USB inclus dans Windows.

  • Votre appareil n’appartient pas à une classe d’appareil.

    Pour ces appareils, évaluez les fonctionnalités de l’appareil pour déterminer si vous pouvez charger le WinUSB fourni par Microsoft (Winusb.sys) en tant que pilote de fonction de l’appareil. L’utilisation de WinUSB est la meilleure solution si :

    • Votre appareil est accessible par une seule application.

    • Votre appareil prend en charge les points de terminaison en bloc, d’interruption ou d’isochronous.

    • Votre appareil est destiné à fonctionner avec un ordinateur cible exécutant Windows XP avec Service Pack 2 (SP2) et les versions ultérieures de Windows.

      Le chargement de WinUSB en tant que pilote de fonction offre une alternative plus simple à l’implémentation d’un pilote USB personnalisé. Par exemple, WinUSB est l’approche recommandée pour une station météorologique électronique accessible uniquement par une application empaquetée avec l’appareil. Il est également utile pour la communication de diagnostic avec un appareil et pour le microprogramme flashing.

      Pour faciliter l’envoi de requêtes à Winusb.sys, nous fournissons une DLL en mode utilisateur, Winusb.dll, qui expose les fonctions WinUSB. Une application peut appeler ces fonctions pour accéder à l’appareil, la configurer et transférer des données vers les points de terminaison de l’appareil.

      WinUSB n’est pas une option si :

    • Votre appareil est accessible par plusieurs applications.

    • Votre appareil dispose de fonctions qui ont déjà une prise en charge en mode noyau dans le système d’exploitation Windows. Par exemple, pour les fonctions modem (qui prennent en charge TAPI) ou les fonctions LAN (que NDIS prennent en charge), vous devez utiliser l’interface prise en charge par le pilote Usbser.sys pour gérer les périphériques modem avec un logiciel en mode utilisateur.

      À compter de Windows 8, nous avons ajouté un ID compatible à l’installation inf pour WinUSB. Si le microprogramme de l’appareil contient cet ID compatible, WinUSB est chargé par défaut en tant que pilote de fonction pour l’appareil. Cela signifie que les fabricants de matériel ne sont pas tenus de distribuer des fichiers INF pour leurs appareils WinUSB. Pour plus d’informations, consultez Appareil WinUSB.

Si vous écrivez un pilote client USB, quel modèle de pilote est le mieux ?

La réponse dépend de la conception de votre appareil. Tout d’abord, déterminez si un modèle de pilote particulier répond à vos besoins. Certaines considérations relatives à la conception sont basées sur le fait que vous souhaitez que l’appareil USB soit accessible par plusieurs applications simultanées et prend en charge la diffusion en continu des données via des points de terminaison isochronous.

Si vous choisissez d’écrire un pilote, voici vos options :

  • Infrastructure de pilote en mode utilisateur (UMDF)

    UMDF fournit des interfaces de pilote de périphérique (DDIS) qu’un pilote client peut utiliser pour s’intégrer à des composants Windows tels que le gestionnaire de Plug-and-Play et Power Manager. UMDF fournit également des objets cibles spécialisés pour les périphériques USB, qui extraitnt le matériel en mode utilisateur et simplifient les opérations d’E/S pour le pilote. Outre les interfaces UMDF, WDF fournit des extensions de débogueur améliorées et des outils de suivi pour les pilotes en mode utilisateur. UMDF est basé sur le modèle objet de composant (COM) et le développement d’un pilote en mode utilisateur est plus facile pour un développeur C++.

    Implémentez un pilote client basé sur UMDF pour un périphérique USB dans les cas suivants :

    • L’appareil est accessible simultanément par plusieurs applications.

    • L’appareil prend en charge les transferts en bloc ou d’interruption.

      Les pilotes qui s’exécutent en mode utilisateur peuvent accéder uniquement à l’espace d’adressage de l’utilisateur (virtuel) et présentent un risque moindre pour le système. Les pilotes en mode noyau peuvent accéder à l’espace d’adressage système et aux structures système internes. Un pilote en mode noyau mal codé peut entraîner des problèmes qui affectent d’autres pilotes ou le système, et éventuellement bloquer l’ordinateur. Par conséquent, un pilote en mode utilisateur peut être plus sûr qu’un pilote en mode noyau en termes de sécurité et de stabilité.

      Un autre avantage des pilotes en mode utilisateur est qu’ils peuvent utiliser toutes les API Win32. Par exemple, les pilotes peuvent appeler des API telles que Winsock, Compression, API de chiffrement, etc. Ces API ne sont pas disponibles pour les pilotes en mode noyau.

      Un pilote client basé sur UMDF n’est pas une option pour les périphériques USB qui prennent en charge les points de terminaison isochrones.

      Remarque

      Windows 8.1 a introduit la version 2.0 de UMDF. Avec UMDF version 2.0, vous pouvez écrire un pilote UMDF dans le langage de programmation C qui appelle de nombreuses méthodes disponibles pour les pilotes KMDF. Vous ne pouvez pas utiliser UMDF version 2.0 pour écrire des pilotes de filtre inférieurs pour USB.

  • Framework de pilote en mode noyau (KMDF)

    KMDF a été conçu pour faciliter l’extension des modèles de pilotes pour prendre en charge de nouveaux types de matériel. KMDF fournit des DDIs et des structures de données qui facilitent l’implémentation des pilotes USB en mode noyau que les pilotes WDM (Driver Model) windows précédents. En outre, KMDF fournit des cibles d’entrée/sortie spécialisées (E/S) que vous pouvez utiliser pour écrire un pilote client entièrement fonctionnel qui utilise la pile de pilotes USB Microsoft.

    Dans certains cas où une fonctionnalité particulière n’est pas exposée via KMDF, le pilote doit appeler des routines WDM. Le pilote n’a pas besoin d’implémenter l’ensemble de l’infrastructure WDM, mais utilise des méthodes KMDF pour accéder à un ensemble sélectionné de routines WDM. Par exemple, pour effectuer des transferts isochronous, un pilote client basé sur KMDF peut envoyer des URI de style WDM qui décrivent la requête à la pile de pilotes USB. Ces pilotes sont appelés pilotes hybrides dans cet ensemble de documentation.

    KMDF prend également en charge le modèle de pilote port-miniport. Par exemple, un pilote miniport de diffusion en continu du noyau (tel qu’une webcam USB) qui utilise la diffusion en continu du noyau sur le bord supérieur peut utiliser des objets cibles d’E/S USB KMDF pour envoyer des requêtes à la pile de pilotes USB. Les pilotes NDIS peuvent également être écrits à l’aide de KMDF pour les bus basés sur le protocole tels que USB.

    Les pilotes WDM purs sont difficiles à écrire, complexes et non robustes. Avec l’évolution de KMDF, l’écriture de ce type de pilote n’est plus nécessaire.

Microsoft Visual Studio inclut le pilote usb en mode utilisateur et les modèles de pilote en mode noyau USB qui génèrent du code de démarrage pour un pilote client USB UMDF et KMDF, respectivement. Le code de modèle initialise un objet d’appareil cible USB pour activer la communication avec le matériel. Pour plus d’informations, consultez les articles suivants :

Pour plus d’informations sur l’implémentation des pilotes UMDF et KMDF, consultez le livre Microsoft Press Developing Drivers with the Windows Driver Foundation.

WinUSB, UMDF, comparaison des fonctionnalités KMDF

Le tableau suivant récapitule les fonctionnalités de WinUSB, de pilotes USB basés sur UMDF et de pilotes USB KMDF.

Fonctionnalité WinUSB UMDF KMDF
Prend en charge plusieurs applications simultanées Non Oui Oui
Isole l’espace d’adressage du pilote de l’espace d’adressage de l’application Non Oui Non
Prend en charge les transferts en bloc, d’interruption et de contrôle Oui Oui Oui
Prend en charge les transferts isochrones Oui4 Non Oui
Prend en charge l’installation des pilotes en mode noyau, tels que les pilotes de filtre, en tant que couche sur la pile USB Non Non Oui
Prend en charge l’interruption sélective et l’état d’attente/de veille Oui Oui Oui

Le tableau suivant récapitule les options WDF prises en charge par différentes versions de Windows.

Version de Windows WinUSB UMDF KMDF
Windows 11 Oui Oui Oui
Windows 10 Oui Oui Oui
Windows 8 Oui Oui Oui
Windows 7 Oui Oui Oui
Windows Vista Oui1 Oui1 Oui
Windows Server 2003 Non Non Oui
Windows XP Oui2 Oui2 Oui
Microsoft Windows 2000 Non Non Oui3

Oui1 : WinUSB et UMDF sont pris en charge uniquement sur les versions x86 et x64 de Windows.

Oui2 : WINUSB et UMDF sont pris en charge dans Windows XP avec Service Pack 2 (SP2) ou versions ultérieures de Windows.

Oui3 : KMDF est pris en charge dans Windows 2000 avec SP4 ou versions ultérieures de Windows.

Oui4 : Les transferts isochronous sont pris en charge dans Windows 8.1 ou versions ultérieures de Windows.

Toutes les références SKU clientes des versions 32 bits de Windows XP avec SP2 prennent en charge WinUSB. WinUSB n’est pas natif de Windows XP, il doit être installé avec le coinstallateur WinUSB. Toutes les références SKU Windows Vista et versions ultérieures de Windows prennent en charge WinUSB.