Vue d’ensemble de la prise en charge USB et du double rôle
Un bus série universel (USB) fournit une interface série extensible, enfichable Plug-and-Play qui garantit une connexion standard et peu coûteuse pour les périphériques tels que les claviers, les souris, les joysticks, les imprimantes, les scanneurs, les périphériques de stockage, les modems et les caméras de visioconférence.
Lorsque nous parlons de périphériques USB, la pile de fonctions USB fait référence à un groupe de pilotes énumérés et chargés par le gestionnaire de Plug-and-Play, et un périphérique USB composite peut prendre en charge plusieurs interfaces dans une même configuration.
Bien que la plupart de ce dont nous parlons dans cet article concerne le double rôle pour USB 2.0, plus communément appelé USB On-The-Go ou USB OTG ou OTG, il est également utile de connaître l’USB 3.0 et la façon dont il diffère de l’USB 2.0.
L’OTG USB définit deux rôles pour les appareils : OTG A-device et OTG B-device, en spécifiant le côté qui fournit l’alimentation au lien et qui est l’hôte initialement. Étant donné que chaque contrôleur OTG prend en charge les deux rôles, ils sont souvent appelés contrôleurs « double rôle » plutôt que « contrôleurs OTG ». D’autre part, USB 3.0 peut transformer des appareils en hôtes ou en périphériques. Certains appareils peuvent prendre l’un ou l’autre rôle en fonction du type détecté à l’autre extrémité. Ces types de ports sont appelés DRD (Dual-Role-Data). Lorsque deux appareils de ce type sont connectés, les rôles sont attribués de manière aléatoire, mais un échange peut être commandé à partir de chaque extrémité.
Architecture de la fonction USB dans Windows 10 IoT Standard
Lorsque la plateforme IoT Windows 10 agit comme un périphérique USB, elle utilise l’une des configurations suivantes. Chaque configuration a une ou plusieurs interfaces USB. Pour prendre en charge correctement l’OTG USB sur Windows 10 IoT, plusieurs éléments doivent être pris en charge.
Composants que les OEM doivent fournir
Les oem doivent fournir des composants des deux côtés , pour le côté périphérique USB et éventuellement pour le côté hôte USB.
Prise en charge des oem pour les deux côtés
Chaque périphérique USB a un VID et un PID uniques, qui l’identifient. Un oem, en tant que fabricant d’un périphérique USB Windows IoT, doit les fournir. Les oem peuvent demander au consortium USB et obtenir leur VID d’entreprise (s’ils n’en ont pas déjà), puis choisir un PID qui sera unique pour ce produit. Quand Windows 10 IoT avec la fonctionnalité USBFN est connecté à un PC, il agit en tant que périphérique USB (quelle que soit la fonctionnalité à choisir comme définie dans myUSBFN.sys), avec ces « VID_nnn » et « PID_NNN ». Cette combinaison VID et PID est ensuite utilisée par le PC hôte pour rechercher les pilotes appropriés à charger (myUSB.sys).
Prise en charge du côté de l’appareil
Fonctionnalités à inclure dans FFU pour la génération d’images avec USBFN activé
- L’image IoT doit contenir les packages nécessaires, à savoir ufx01000.sys et usbfnclx.sys. Ils sont tous deux fournis avec le package
Microsoft-IoTUAP-USBFN-Class-Extension-Package.cabsuivant . Les oem doivent utiliser une balise « fonctionnalité » appropriée dans leur fichier XML, qui répertorie toutes les fonctionnalités incluses dans le FFU. Par exemple, dans le fichier BoardTestOEMInput.xml, l’entrée<Feature>IOT_USBFN_CLASS_EXTENSION</Feature>suivante est incluse dans<Microsoft>la section Fonctionnalités.
Pilote de basculement de rôle USB
- Pour l’OTG USB, les oem doivent fournir l’entrée de table ACPI correcte (myOTGacpi) pour le pilote de commutation de rôle USB et le pilote lui-même (*myURS.sys).
Pilote du contrôleur de fonction USB
- Cela dépend du matériel utilisé par les oem. Microsoft fournit des pilotes de contrôleur de fonction USB pour deux chipsets OTG USB populaires : Synopsys et ChipIdea.
- Si un oem choisit d’utiliser un autre chipset OTG USB, l’OEM doit fournir son propre matériel de contrôleur de fonction USB (myfunctioncontroller.sys).
Pilotes de classe de fonction USB
- Au moins un pilote de classe de fonction USB doit être fourni.
- Ce pilote implémente des fonctionnalités de périphérique USB spécifiques. Il détermine ce que l’appareil apparaîtra du côté de l’hôte, ainsi que ce qu’il fera. Par exemple, il peut apparaître comme un appareil de communication série ou comme un appareil de stockage de masse ou un appareil de type complètement personnalisé (myUSBFN.sys).
Configuration du périphérique de fonction USB
- Lorsque la plateforme IoT est en mode périphérique USB, elle peut fonctionner sous une ou plusieurs configurations. Chaque configuration utilisée doit être ajoutée et ses propriétés doivent être spécifiées.
Propriétés communes
- Il existe des propriétés communes pour toutes les configurations de fonction USB de la plateforme IoT. Il incombe finalement au oem de spécifier des entrées de descripteur USB standard telles que VID, PID, DeviceClass, DeviceProtocol, Manufacturer string, numéro de série, etc.
- Ces propriétés courantes sont définies dans le Registre à l’emplacement suivant :
HKLM\System\ControlSet001\Control\USBFN\default
BcdDevice=0x1
bDeviceClass=0x0
bDeviceProtocol=0x0
bDeviceSubClass= 0x0
idProduct= 0xc0c0
idVendor=0x045e
iManufacturer=1
iSerialNumber=3
ManufacturerString=OEMname
ProductString="Windows IOT"
Important
Les valeurs ci-dessus sont à des fins de démonstration uniquement et ne peuvent être utilisées dans aucun produit. Le fabricant OEM doit remplacer ces champs d’espace réservé par des valeurs réelles dans chaque entrée ci-dessus.
Propriétés par configuration
Les configurations sont stockées dans un Registre sous la clé suivante : HKLM\SYSTEM\ControlSet001\Control\USBFN\Configurations
Par défaut, une configuration de fonction USB par défaut vide est incluse dans le FFU, comme défini dans : HKLM\SYSTEM\ControlSet001\Control\USBFN\Configurations\default
Cette configuration par défaut vide entraîne l’affichage de la plateforme IoT en tant qu’appareil Windows IoT pour lequel aucun pilote n’est installé côté hôte.
Chaque configuration doit spécifier certaines propriétés, telles que la liste d’interface. La plateforme IoT peut fonctionner en tant que périphérique USB avec différentes configurations, définies par des interfaces USB exposées d’un périphérique USB à un hôte USB.
HKLM\System\CurrentControlSet\Control\USBFN\Configurations\Default
InterfaceList =
InterfaceDescriptor =
InterfaceGUIDE =
Actuellement, la configuration sélectionnée est celle qui sera en vigueur lors de la connexion au chaud USB : HKLM\SYSTEM\ControlSet001\Control\USBFN
Exemples de configurations
Configuration unique
- Doit contenir au moins une interface
- Il peut s’agir d’une configuration par défaut
- Lorsqu’elle est connectée à un PC, la plateforme IoT apparaît comme ce type de périphérique USB (par exemple, modem ou stockage).
HKLM\SYSTEM\ControlSet001\Control\USBFN\Configurations\default,InterfaceList = "MODEM\0MTP"
Configuration composite
- Contient une liste d’interfaces avec des paramètres supplémentaires
- Lorsqu’elle est connectée à un PC, la plateforme IoT s’affiche sous la forme d’un périphérique USB composite avec plusieurs unités (c’est-à-dire un appareil MTP, un appareil série, un appareil personnalisé).
HKLM\SYSTEM\ControlSet001\Control\USBFN\Configurations\mycfg,InterfaceList = "MODEM\0MTP"
Les interfaces USBFN sont énumérées dans le Registre sous la clé suivante : HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\USBFN\Interfaces
Chaque entrée d’interface USB doit contenir une valeur de descripteur d’interface et un GUID d’interface.
Prise en charge du côté hôte
Si un oem choisit d’implémenter une interface USB standard (par exemple, stockage de masse) côté appareil, un PC hôte peut utiliser des pilotes Windows dans la boîte pour ce type de périphérique USB. Si un OEM implémente une interface USB personnalisée côté appareil, il est nécessaire pour l’OEM de développer un pilote hôte Windows pour ce périphérique de fonction USB personnalisé.