Partager via

Pilotes de périphériques pour les appareils sur SerCx2-Managed ports série

  • Article

En règle générale, un port série géré par SerCx2 est connecté en permanence à un périphérique. Ce périphérique est contrôlé par un pilote de périphérique qui envoie des demandes d’E/S au port série. Ces demandes transfèrent des données vers et depuis l’appareil, et configurent l’état du port série. Les demandes d’E/S envoyées par le pilote de périphérique sont gérées conjointement par SerCx2 et un pilote de contrôleur série associé.

Souvent, les contrôleurs série sont contenus dans les circuits intégrés Système sur une puce (SoC). Parmi les exemples de périphériques qui peuvent être connectés au port série d’un contrôleur série sur une puce SoC, citons les appareils GPS, LAN sans fil, caméra et Bluetooth.

Le pilote de périphérique pour le périphérique connecté en série est généralement un pilote KMDF ( Kernel-Mode Driver Framework ) ou UMDF ( User-Mode Driver Framework ). Pour communiquer avec cet appareil, le pilote de périphérique doit d’abord ouvrir une connexion logique au contrôleur série et recevoir un handle de fichier auquel le pilote peut envoyer des demandes d’E/S. Pour plus d’informations, consultez Ouverture d’un port série SerCx2-Managed.

Dans cette page

Architecture du pilote série

Le diagramme de blocs suivant montre les couches de logiciels et de matériel qui forment les chemins de communication entre un périphérique (en bas du diagramme) et le pilote périphérique de cet appareil (en haut du diagramme). Dans cet exemple, le périphérique est connecté au port du contrôleur série et à une broche d’interruption sur le contrôleur GPIO.

Diagramme montrant les couches logicielles et matérielles d’un périphérique sur un port série géré par SerCx2.

Le pilote de périphérique dans cet exemple est un pilote UMDF qui envoie des demandes d’E/S au périphérique. Ces demandes se déplacent dans le chemin de communication indiqué sur le côté gauche du diagramme. Les requêtes sont gérées par SerCx2 et le pilote de contrôleur série. Le pilote de périphérique peut demander des opérations d’E/S qui définissent la configuration matérielle du port série (par exemple, modifier le débit en bauds) et qui transfèrent des données vers et depuis le périphérique via le port série. Pour plus d’informations, consultez Chemin de la demande d’E/S.

Les interruptions de l’appareil périphérique se déplacent vers le haut via le chemin de communication sur le côté droit du diagramme précédent. Comme indiqué dans le coin inférieur droit de ce diagramme, la broche d’interruption de l’appareil périphérique est connectée à une broche sur un contrôleur d’E/S à usage général (GPIO). Cette broche GPIO est configurée pour recevoir des signaux d’interruption de l’appareil périphérique. Dans une plateforme matérielle basée sur SoC, un contrôleur GPIO joue fréquemment le rôle de contrôleur d’interruption programmable. Pour plus d’informations, consultez Chemin d’interruption.

Les deux blocs indiqués en gris dans le diagramme sont des modules fournis par le système. L’extension d’infrastructure GPIO (GpioClx) est disponible à partir de Windows 8. Comme SerCx2, GpioClx est une extension de KMDF. GpioClx exécute des fonctions communes à divers contrôleurs GPIO. GpioClx fonctionne avec un pilote de contrôleur GPIO qui gère toutes les opérations spécifiques au matériel dans le contrôleur GPIO. Pour plus d’informations, consultez Vue d’ensemble de la prise en charge des pilotes GPIO.

Chemin d’accès à la demande d’E/S

Pour transmettre des données au périphérique, le pilote de périphérique envoie une demande d’écriture (IRP_MJ_WRITE) au contrôleur série. Pour recevoir des données à partir du périphérique, le pilote de périphérique envoie une demande de lecture (IRP_MJ_READ) au contrôleur série.

En outre, Windows définit un ensemble de demandes de contrôle d’E/S d’appareil (IOCTL) que le pilote de périphérique peut utiliser pour effectuer diverses opérations de contrôle d’E/S spécifiques aux contrôleurs série. Voici des exemples d’opérations de contrôle d’E/S que le pilote de périphérique peut demander :

  • Définissez le débit en bauds auquel le port série transmet et reçoit des données.
  • Définissez les intervalles de délai d’attente pour les demandes de lecture et d’écriture.
  • Spécifiez un ensemble d’événements matériels au niveau du port série pour lequel le pilote périphérique reçoit des notifications.

SerCx2 prend en charge la plupart des mêmes IOCTL série que le pilote série de boîte de réception, Serial.sys et la version 1 de l’extension de l’infrastructure série (SerCx). Pour plus d'informations :

Chemin d’interruption

Comme indiqué dans le diagramme d’architecture du pilote série , le périphérique utilise la broche GPIO pour envoyer des interruptions d’appareil au pilote de périphérique. En réponse à un signal d’interruption de l’appareil périphérique, le contrôleur GPIO signale une interruption matérielle (appelée interruption principale ) au processeur. Le système d’exploitation dirige cette interruption vers l’ISR de GpioClx. Ensuite, GpioClx identifie la broche GPIO à l’origine de l’interruption et recherche l’identificateur d’interruption système globale (GSI) pour l’interruption virtuelle (appelée interruption secondaire ) de l’appareil périphérique. GpioClx fournit le GSI au HAL, et celui-ci appelle l’ISR du pilote périphérique. Pour gérer l’interruption, le pilote de périphérique envoie généralement une ou plusieurs demandes d’E/S au périphérique au moyen de SerCx2 et du pilote de contrôleur série. Pour plus d’informations sur les interruptions primaires et secondaires, consultez Interruptions GPIO.

Les interruptions GPIO ne sont qu’un moyen pour le pilote de périphérique de recevoir des notifications d’événements matériels dans le périphérique. Une autre façon consiste pour le pilote périphérique à demander des notifications de SerCx2 et du pilote de contrôleur série lorsque certains types d’événements matériels se produisent au niveau du port série. Par exemple, le pilote de périphérique peut demander à être averti lorsque le contrôleur série reçoit des données série de l’appareil périphérique. Pour demander ces notifications, le pilote de périphérique envoie une demande de IOCTL_SERIAL_SET_WAIT_MASK au périphérique pour spécifier un ensemble d’événements à surveiller, puis envoie une demande IOCTL_SERIAL_WAIT_ON_MASK pour commencer à écouter ces événements. Ces demandes sont gérées par SerCx2, avec l’aide du pilote de contrôleur série. Pour plus d’informations sur les types d’événements que le pilote de périphérique peut surveiller, consultez SERIAL_EV_XXX qui sont décrits dans IOCTL_SERIAL_SET_WAIT_MASK.

Toutefois, le contrôleur série peut détecter les événements matériels uniquement lorsqu’il est dans l’état d’alimentation de l’appareil D0. Si le contrôleur série est à faible consommation d’énergie, le pilote de périphérique ne peut pas s’appuyer sur les notifications du contrôleur série pour savoir quand, par exemple, le périphérique dispose de nouvelles données que le pilote peut lire. Dans ce cas, l’appareil périphérique doit envoyer un signal d’interruption (ou, peut-être, un signal de veille) via une broche GPIO. Un contrôleur GPIO consomme très peu d’énergie et reste généralement actif une fois que la plupart des autres appareils sont entrés dans des états de faible puissance.