Choix d’un modèle de pilote pour le développement d’un pilote client USB

  • Article

Cette rubrique fournit des instructions pour le choix du meilleur modèle de pilote pour le développement d’un pilote client USB qui joue le rôle de pilote de fonction du périphérique.

Les fabricants de périphériques USB doivent souvent fournir aux applications un moyen d’accéder aux fonctionnalités de l’appareil. Pour choisir le meilleur mécanisme pour accéder à 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 cette rubrique :

  1. Si votre appareil appartient à une classe de périphériques 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 ne dispose pas d’un pilote de classe fourni par Microsoft et que l’appareil est accessible par une seule application, chargez WinUSB en tant que pilote de fonction.
  3. Si l’appareil doit être accessible par des applications simultanées et que votre appareil n’a pas de points de terminaison isochroques, écrivez un pilote client basé sur UMDF.
  4. Si les solutions de pilote de classe, WinUSB ou 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 a été d’implémenter un pilote de périphérique (appelé pilote client USB dans cet ensemble de documentation) et de 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 de périphérique 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 les API Windows.

L’écriture d’un pilote personnalisé en fonction des 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 l’initialisation du pilote lorsque de nouveaux appareils sont détectés, la gestion de l’alimentation, les opérations d’E/S, la suppression de surprise, la gestion de l’état et le 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’aurez peut-être pas besoin d’écrire un pilote dans les cas suivants :

  • Votre appareil appartient à une classe de périphérique 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 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 (Winusb.sys) fourni par Microsoft en tant que pilote de fonction de l’appareil. L’utilisation de WinUSB est la meilleure solution si :

    • Une seule application accède à votre appareil.

    • Votre appareil prend en charge les points de terminaison en bloc, les interruptions ou les points de terminaison isochrone.

    • 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éo é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 clignotement du microprogramme.

      Pour permettre aux applications d’envoyer facilement des 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, le configurer et transférer des données vers les points de terminaison de l’appareil.

      WinUSB n’est pas une option si :

    • Plusieurs applications accèdent à votre appareil.

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

      Dans Windows 8, nous avons ajouté un nouvel 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 est le meilleur modèle de pilote ?

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 le périphérique USB soit accessible à plusieurs applications simultanées et prend en charge la diffusion en continu de données via des points de terminaison isochronaux.

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 Plug-and-Play Manager et Power Manager. UMDF fournit également des objets cibles spécialisés pour les périphériques USB, ce qui extrait le matériel en mode utilisateur et simplifie 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 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 utilisateur (virtuel) et posent un risque beaucoup moins élevé 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 provoquer 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 tirent parti de 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 UMDF n’est pas une option pour les périphériques USB qui prennent en charge les points de terminaison isochroques.

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

  • Infrastructure du pilote en mode noyau (KMDF)

    KMDF a été conçu pour rendre les modèles de pilotes faciles à étendre 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 par rapport aux pilotes WDM (Windows Driver Model) antérieurs. En outre, KMDF fournit des cibles d’entrée/sortie (E/S) spécialisées que vous pouvez utiliser pour écrire un pilote client entièrement fonctionnel qui utilise la pile de pilotes MICROSOFT USB.

    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 isochrones, un pilote client basé sur KMDF peut envoyer des URB de style WDM qui décrivent la demande à 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 instance, 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 des protocoles tels qu’USB.

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

Microsoft Visual Studio 2012 inclut des modèles usb User-Mode Driver et USB Kernel-Mode Driver qui génèrent du code de démarrage pour un pilote client USB UMDF et KMDF, respectivement. Le code du modèle initialise un objet de périphérique cible USB pour activer la communication avec le matériel. Pour plus d'informations, voir les rubriques suivantes :

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.

Comparaison des fonctionnalités WinUSB, UMDF et KMDF

Le tableau suivant récapitule les fonctionnalités de WinUSB, des pilotes USB basés sur UMDF et des pilotes USB basés sur 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, les interruptions et les transferts de contrôle Oui Oui Oui
Prend en charge les transferts isochrone Oui4 Non Oui
Prend en charge l’installation de pilotes en mode noyau, tels que les pilotes de filtre, en tant que couche superposée sur la pile USB Non Non Oui
Prend en charge la suspension sélective et l’état d’attente/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 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 No 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 isochronieux 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 SP2supportent WinUSB. WinUSB n’est pas natif de Windows XP ; il doit être installé avec le co-programme d’installation WinUSB. Toutes les références SKU Windows Vista et les versions ultérieures de Windows prennent en charge WinUSB.