Aperçu des pilotes de périphériques SPB
Un pilote de périphérique SPB contrôle un périphérique connecté à un simple bus périphérique (SPB). Les registres matériels de ce périphérique ne sont accessibles que par l’intermédiaire du SPB. Pour lire ou écrire sur le périphérique, le pilote doit envoyer des requêtes d’E/S au contrôleur SPB. Seul ce contrôleur peut initier les transferts de données vers et depuis le périphérique via le SPB.
À partir de Windows 8, Windows prend en charge les pilotes pour les périphériques sur les simples bus périphériques (SPB). Les SPB, tels que I2C et SPI, sont largement utilisés pour se connecter à des dispositifs de capteurs à faible vitesse, tels que des accéléromètres, des dispositifs GPS et des moniteurs de niveau de batterie. Cet aperçu décrit comment un pilote de périphérique SPB, en coopération avec d’autres composants du système, contrôle un périphérique connecté à un SPB.
Un pilote de périphérique SPB peut être conçu pour utiliser soit le User-Mode Driver Framework (UMDF), soit le Kernel-Mode Driver Framework (KMDF). Pour plus d’informations sur le développement d’un pilote UMDF, veuillez consulter la section Premiers pas avec UMDF. Pour plus d’informations sur le développement d’un pilote KMDF, veuillez consulter la section Premiers pas avec Kernel-Mode Driver Framework.
Informations de configuration du périphérique
Les registres matériels d’un périphérique connecté à un SPB ne sont pas mappés en mémoire. Le périphérique ne peut être accessible qu’à travers le contrôleur SPB, qui transfère les données de manière séquentielle vers et depuis le périphérique via le SPB. Pour effectuer des opérations d’E/S, le pilote de périphérique SPB envoie des requêtes d’E/S au périphérique, et le contrôleur SPB effectue les transferts de données nécessaires pour compléter ces requêtes. Pour plus d’informations sur les requêtes d’E/S qui peuvent être envoyées aux périphériques sur les SPB, veuillez consulter la section Utilisation de l’interface de requête d’E/S SPB.
Le diagramme suivant montre un exemple de configuration matérielle dans laquelle un SPB, ici un bus I2C, connecte deux périphériques à un module Système sur une puce (SoC). Les périphériques sont externes au module SoC et se connectent à quatre broches du module. Le module SoC contient le processeur principal (non montré), ainsi qu’un contrôleur I2C et un contrôleur d’entrées/sorties générales (GPIO). Le processeur utilise le contrôleur I2C pour transmettre des données séquentiellement vers et depuis les deux périphériques. Les lignes de requête d’interruption de ces périphériques sont connectées à deux broches GPIO configurées comme entrées d’interruption. Lorsqu’un périphérique signale une demande d’interruption, le contrôleur GPIO relaie l’interruption au processeur.
Comme le contrôleur GPIO et le contrôleur I2C dans cet exemple sont intégrés au module SoC, leurs registres matériels sont mappés en mémoire et peuvent être directement accessibles par le processeur. Cependant, le processeur ne peut accéder aux registres matériels des deux périphériques que de manière indirecte, via le contrôleur I2C.
Un SPB n’est pas un bus Plug and Play (PnP) et, par conséquent, ne peut pas être utilisé pour détecter et configurer automatiquement de nouveaux périphériques connectés au bus. Les connexions de bus et d’interruption d’un périphérique connecté à un SPB sont fréquemment permanentes. Même si le périphérique peut être débranché d’un emplacement, cet emplacement est généralement dédié au périphérique. De plus, un SPB ne fournit pas de chemin matériel intégré pour relayer les demandes d’interruption d’un périphérique sur le bus au contrôleur du bus. Au lieu de cela, le chemin matériel pour les interruptions est séparé du contrôleur du bus.
Le fournisseur de la plateforme matérielle stocke les informations de configuration pour un périphérique connecté à un SPB dans le firmware ACPI de la plateforme. Lors du démarrage du système, le pilote ACPI énumère les périphériques sur le bus pour le gestionnaire PnP. Pour chaque périphérique énuméré, ACPI fournit des informations sur les connexions de bus et d’interruption du périphérique. Le gestionnaire PnP stocke ces informations dans une base de données appelée hub de ressources.
Lorsque le périphérique démarre, le gestionnaire PnP fournit au pilote du périphérique un ensemble de ressources matérielles qui encapsulent les informations de configuration stockées dans le hub de ressources pour le périphérique. Ces ressources comprennent un ID de connexion et un numéro d’interruption. L’ID de connexion encapsule les informations de connexion au bus, telles que le contrôleur SPB, l’adresse du bus et la fréquence d’horloge du bus. Avant que des requêtes d’E/S puissent être envoyées au périphérique, le pilote doit d’abord utiliser l’ID de connexion pour ouvrir une connexion logique avec le périphérique. Le numéro d’interruption est une ressource d’interruption Windows à laquelle le pilote peut connecter sa routine de service d’interruption (ISR). Le pilote peut facilement être porté d’une plateforme matérielle à une autre car l’ID de connexion et le numéro d’interruption sont des abstractions de haut niveau qui masquent les informations spécifiques à la plateforme concernant les connexions physiques du bus et des interruptions.
Couches logicielles et matérielles
Le diagramme en blocs suivant montre les couches de logiciels et de matériels qui connectent un périphérique sur un SPB à un programme d’application qui utilise le périphérique. Le pilote de périphérique SPB dans cet exemple est un pilote UMDF. Le périphérique (en bas du diagramme) est un capteur (par exemple, un accéléromètre). Comme dans le diagramme précédent, le périphérique est connecté à un bus I2C et signale des demandes d’interruption via une broche sur un contrôleur GPIO.
Les trois blocs en gris sont des modules fournis par le système. À partir de Windows 7, l’extension de classe de capteur est disponible en tant qu’extension spécifique aux capteurs pour l’UMDF. À partir de Windows 8, l’extension de framework SPB (SpbCx) et l’extension de framework GPIO (GpioClx) sont disponibles en tant qu’extensions du KMDF qui remplissent des fonctions spécifiques aux contrôleurs SPB et aux contrôleurs GPIO, respectivement.
En haut du diagramme précédent, l’application appelle les méthodes de l’API du capteur ou de l’API de localisation pour communiquer avec le capteur. Grâce à ces appels, l’application peut envoyer des requêtes d’E/S au périphérique et recevoir des notifications d’événements du périphérique. Pour plus d’informations sur ces API, veuillez consulter la section Présentation de la plateforme des capteurs et de localisation dans Windows.
Lorsque l’application appelle une méthode qui nécessite une communication avec le pilote de périphérique SPB, l’API du capteur ou l’API de localisation crée une requête d’E/S et l’envoie au pilote de périphérique SPB. Le module d’extension de classe de capteur assiste le pilote dans le traitement de ces requêtes d’E/S. Lorsque le pilote reçoit une nouvelle requête d’E/S, il la transmet immédiatement à l’extension de classe de capteur, qui met la requête en file d’attente jusqu’à ce que le pilote soit prêt à la traiter. Si une requête d’E/S de l’application nécessite le transfert de données vers ou depuis le périphérique, le pilote de périphérique SPB crée une requête d’E/S pour ce transfert et envoie la requête au contrôleur I2C. Ces requêtes sont traitées conjointement par SpbCx et le pilote du contrôleur I2C.
SpbCx est un composant fourni par le système qui gère les files d’attente de requêtes d’E/S pour un contrôleur SPB, tel que le contrôleur I2C dans cet exemple. Le pilote du contrôleur I2C, qui est fourni par le fournisseur de matériel pour le contrôleur, gère toutes les opérations spécifiques au matériel dans le contrôleur I2C. Par exemple, le pilote du contrôleur accède aux registres matériels mappés en mémoire du contrôleur pour initier des transferts de données vers et depuis le périphérique via le bus I2C.
Le périphérique signale une demande d’interruption lorsqu’un événement matériel se produit et nécessite l’attention du pilote de périphérique SPB ou de l’application en mode utilisateur. La ligne d’interruption du périphérique est connectée à une broche GPIO configurée pour recevoir des demandes d’interruption. Lorsque le périphérique signale une interruption à la broche GPIO, le contrôleur GPIO signale une interruption au processeur. En réponse à cette interruption, le gestionnaire de piège d’interruption du noyau appelle l’ISR de GpioClx. Cet ISR interroge le pilote du contrôleur GPIO, qui accède ensuite aux registres matériels mappés en mémoire du contrôleur GPIO pour identifier la broche GPIO à l’origine de l’interruption. Pour désactiver l’interruption, le pilote du contrôleur GPIO efface (si l’interruption est déclenchée par un front) ou masque (si elle est déclenchée par niveau) la demande d’interruption à la broche GPIO. L’interruption doit être désactivée pour empêcher le processeur de prendre la même interruption à nouveau lorsque le gestionnaire de piège retourne. Pour une interruption déclenchée par niveau, l’ISR dans le pilote de périphérique SPB doit accéder aux registres matériels du périphérique pour effacer l’interruption avant que la broche GPIO puisse être démasquée.
Avant que le gestionnaire de piège d’interruption du noyau ne retourne, il planifie l’exécution de l’ISR dans le pilote de périphérique SPB à IRQL = PASSIVE_LEVEL. À partir de Windows 8, un pilote UMDF peut connecter son ISR à une interruption que le pilote reçoit en tant que ressource d’interruption abstraite Windows ; pour plus d’informations, veuillez consulter la section Gestion des interruptions. Pour déterminer quel ISR appeler, le système d’exploitation recherche l’interruption virtuelle qui est attribuée à la broche GPIO à l’origine de l’interruption et trouve l’ISR qui est connecté à l’interruption. Cette interruption virtuelle est étiquetée comme une interruption secondaire dans le diagramme précédent. En revanche, l’interruption matérielle du contrôleur GPIO est étiquetée comme une interruption principale.
Étant donné que l’ISR dans le pilote de périphérique SPB s’exécute au niveau passif, l’ISR peut utiliser des requêtes d’E/S synchrones pour accéder aux registres matériels du périphérique. L’ISR peut attendre que ces requêtes soient terminées. L’ISR, qui s’exécute avec une priorité relativement élevée, doit retourner dès que possible et différer tout traitement en arrière-plan pour une interruption à une routine de travail qui s’exécute avec une priorité inférieure.
En réponse à l’interruption secondaire, le pilote de périphérique SPB poste un événement dans l’extension de classe de capteur, qui notifie l’application en mode utilisateur de l’événement via l’API du capteur ou l’API de localisation.