Partager via


Vue d’ensemble de l’architecture SerCx2

SerCx2 fonctionne avec un pilote de contrôleur série pour permettre la communication entre un pilote de périphérique et un périphérique connecté en série. En règle générale, le contrôleur série est intégré à une puce Système sur puce (SoC) pour fournir une communication à faible nombre de broches avec un périphérique externe à la puce SoC, mais qui est soudé à la même carte de circuit imprimé.

Le diagramme suivant montre le chemin de communication entre un périphérique connecté en série et le pilote de ce périphérique. Ce pilote de périphérique s’exécute en mode noyau ou en mode utilisateur et envoie des demandes d’E/S au port série auquel le périphérique est connecté.

Diagramme montrant le chemin de communication entre un périphérique connecté en série et son pilote, y compris SerCx2 et le pilote de contrôleur série.

SerCx2 et le pilote de contrôleur série s’exécutent en mode noyau et communiquent entre eux via l’interface de pilote de périphérique (DDI) SerCx2. Le pilote du contrôleur série appelle les méthodes de prise en charge du pilote implémentées par SerCx2. SerCx2 appelle des fonctions de rappel d’événement implémentées par le pilote de contrôleur série.

En règle générale, les registres matériels du contrôleur série sont mappés en mémoire. Le pilote du contrôleur série accède directement à ces registres pour configurer le port série et pour transférer des données vers et depuis le périphérique connecté au port série. Pour les transferts de données plus longs, SerCx2 utilise généralement des transferts DMA (non indiqués dans le diagramme précédent).

Les informations dont le pilote de périphérique a besoin pour ouvrir une connexion logique au périphérique sont encapsulées dans un type spécial de ressource matérielle appelée ID de connexion. Pour plus d’informations, consultez ID de connexion pour les périphériques connectés en série.

En règle générale, seuls les pilotes envoient des demandes d’E/S directement à un contrôleur série. Lorsqu’une application en mode utilisateur doit communiquer avec un périphérique connecté en série, le pilote de périphérique de l’appareil agit comme intermédiaire entre l’application et l’appareil. Si l’application doit transférer des données vers ou depuis le périphérique, l’application envoie une demande d’écriture (IRP_MJ_WRITE) ou une demande de lecture (IRP_MJ_READ) au pilote de périphérique, et le pilote de périphérique répond en envoyant une demande d’écriture ou de lecture correspondante au contrôleur série. En outre, le pilote de périphérique peut envoyer des demandes de contrôle d’E/S de périphérique (IOCTL) pour configurer le port série. Pour obtenir la liste des IOCTL pris en charge par SerCx2, consultez Interface de demande d’E/S série.

Le pilote de périphérique qui envoie des demandes d’E/S au contrôleur série est un pilote en mode noyau qui utilise l’infrastructure du pilote en mode noyau (KMDF) ou un pilote en mode utilisateur qui utilise l’infrastructure du pilote en mode utilisateur (UMDF). SerCx2 gère les files d’attente des demandes d’E/S envoyées au contrôleur série par le pilote de périphérique.

En réponse à une demande de lecture ou d’écriture, SerCx2 lance une ou plusieurs transactions d’E/S pour déplacer des données entre le contrôleur série et la mémoire tampon de données dans la demande. Chaque transaction d’E/S utilise des E/S programmées (PIO) ou DMA pour transférer des données entre le contrôleur série et la mémoire tampon de données dans la requête. Les types de transactions d’E/S prises en charge par un pilote de contrôleur série dépendent des fonctionnalités matérielles du contrôleur série. Pour plus d’informations, consultez Vue d’ensemble des transactions D/S SerCx2.