Peripheriegerätetreiber für Geräte an SerCx2-Managed seriellen Ports

In der Regel ist ein von SerCx2 verwalteter serieller Port dauerhaft mit einem Peripheriegerät verbunden. Dieses Gerät wird von einem Peripherietreiber gesteuert, der E/A-Anforderungen an den seriellen Port sendet. Diese Anforderungen übertragen Daten an und vom Gerät und konfigurieren den Zustand des seriellen Ports. E/A-Anforderungen, die vom Peripherietreiber gesendet werden, werden gemeinsam von SerCx2 und einem zugehörigen seriellen Controllertreiber verarbeitet.

Häufig sind serielle Controller in integrierten SoC-Leitungen (System on a Chip) enthalten. Beispiele für Peripheriegeräte, die möglicherweise mit dem seriellen Port eines seriellen Controllers auf einem SoC-Chip verbunden sind, sind GPS-, Wlan-, Kamera- und Bluetooth-Geräte.

Der Peripherietreiber für das serielle Peripheriegerät ist in der Regel ein Kernelmodus-Treiberframework (KMDF) oder ein UMDF-Treiber (User-Mode Driver Framework ). Um mit diesem Gerät zu kommunizieren, muss der Peripherietreiber zuerst eine logische Verbindung mit dem seriellen Controller öffnen und ein Dateihandle empfangen, an das der Treiber E/A-Anforderungen senden kann. Weitere Informationen finden Sie unter Öffnen eines SerCx2-Managed seriellen Ports.

Auf dieser Seite

• Architektur des seriellen Treibers
• E/A-Anforderungspfad
• Interruptpfad

Architektur des seriellen Treibers

Das folgende Blockdiagramm zeigt die Ebenen von Software und Hardware, die die Kommunikationspfade zwischen einem Peripheriegerät (am unteren Rand des Diagramms) und dem Peripherietreiber dieses Geräts (oben im Diagramm) bilden. In diesem Beispiel ist das Peripheriegerät mit dem Port des seriellen Controllers und mit einem Interrupt-Pin auf dem GPIO-Controller verbunden.

Der Peripherietreiber in diesem Beispiel ist ein UMDF-Treiber, der E/A-Anforderungen an das Peripheriegerät sendet. Diese Anforderungen durchlaufen den auf der linken Seite des Diagramms angezeigten Kommunikationspfad. Die Anforderungen werden von SerCx2 und dem seriellen Controllertreiber verarbeitet. Der Peripherietreiber kann E/A-Vorgänge anfordern, die die Hardwarekonfiguration des seriellen Ports festlegen (z. B. die Baudrate ändern) und daten über den seriellen Port an und vom Peripheriegerät übertragen. Weitere Informationen finden Sie unter E/A-Anforderungspfad.

Interrupts vom Peripheriegerät wandern durch den Kommunikationspfad auf der rechten Seite des vorherigen Diagramms nach oben. Wie in der unteren rechten Ecke dieses Diagramms dargestellt, ist der Interruptpin des Peripheriegeräts mit einem Pin an einem GPIO-Controller (General Purpose E/O) verbunden. Dieser GPIO-Pin ist für den Empfang von Interruptsignalen vom Peripheriegerät konfiguriert. Auf einer SoC-basierten Hardwareplattform spielt ein GPIO-Controller häufig die Rolle eines programmierbaren Interruptcontrollers. Weitere Informationen finden Sie unter Interruptpfad.

Die beiden grau dargestellten Blöcke im Diagramm sind vom System bereitgestellte Module. Die GPIO-Frameworkerweiterung (GpioClx) ist ab Windows 8 verfügbar. Wie SerCx2 ist GpioClx eine Erweiterung von KMDF. GpioClx führt Funktionen aus, die einer Vielzahl von GPIO-Controllern gemeinsam sind. GpioClx arbeitet mit einem GPIO-Controllertreiber, der alle hardwarespezifischen Vorgänge im GPIO-Controller verwaltet. Weitere Informationen finden Sie unter GPIO-Treiberunterstützung– Übersicht.

E/A-Anforderungspfad

Um Daten an das Peripheriegerät zu übertragen, sendet der Peripherietreiber eine Schreibanforderung (IRP_MJ_WRITE) an den seriellen Controller. Um Daten vom Peripheriegerät zu empfangen, sendet der Peripherietreiber eine Leseanforderung (IRP_MJ_READ) an den seriellen Controller.

Darüber hinaus definiert Windows eine Reihe von Geräte-E/A-Steuerungsanforderungen (IOCTLs), die der Peripherietreiber verwenden kann, um verschiedene E/A-Steuerungsvorgänge auszuführen, die für serielle Controller spezifisch sind. Im Folgenden finden Sie Beispiele für E/A-Steuerungsvorgänge, die der Peripherietreiber anfordern kann:

• Legen Sie die Baudrate fest, mit der der serielle Port Daten sendet und empfängt.
• Legen Sie die Timeoutintervalle für Lese- und Schreibanforderungen fest.
• Geben Sie eine Reihe von Hardwareereignissen am seriellen Port an, für den der Peripherietreiber Benachrichtigungen empfängt.

SerCx2 unterstützt viele der gleichen seriellen IOCTLs wie der serielle Posteingangstreiber, Serial.sys und Version 1 der Serial Framework-Erweiterung (SerCx). Weitere Informationen finden Sie unter:

• Sehen Sie sich die Tabelle in Serial E/O Request Interface an, um zu ermitteln, ob SerCx2 eine bestimmte serielle IOCTL unterstützt.
• Ausführliche Beschreibungen aller seriellen IOCTLs, die von der seriellen E/A-Anforderungsschnittstelle von Windows definiert werden, finden Sie unter Anforderungen zur Steuerung von seriellen Geräten.
• Eine kurze Einführung in Serial.sys, SerCx und SerCx2 finden Sie unter Übersicht über serielle Controllertreiber .

Interruptpfad

Wie im Diagramm zur Architektur des seriellen Treibers gezeigt, verwendet das Peripheriegerät den GPIO-Pin, um Geräteunterbrechungen an den Peripherietreiber zu senden. Als Reaktion auf ein Interruptsignal vom Peripheriegerät signalisiert der GPIO-Controller dem Prozessor einen Hardware-Interrupt (als primärer Interrupt bezeichnet). Das Betriebssystem leitet diesen Interrupt an den ISR von GpioClx weiter. Als Nächstes identifiziert GpioClx, welcher GPIO-Pin den Interrupt verursacht hat, und sucht den globalen Systemunterbrechungsbezeichner (Global System Interrupt, GSI) für den virtuellen Interrupt ( als sekundärer Interrupt bezeichnet) des Peripheriegeräts. GpioClx stellt die GSI an die HAL bereit, und die HAL ruft den ISR des Peripherietreibers auf. Um den Interrupt zu verarbeiten, sendet der Peripherietreiber in der Regel eine oder mehrere E/A-Anforderungen über SerCx2 und den seriellen Controllertreiber an das Peripheriegerät. Weitere Informationen zu primären und sekundären Interrupts finden Sie unter GPIO Interrupts.

GPIO-Interrupts sind nur eine Möglichkeit für den Peripherietreiber, Benachrichtigungen über Hardwareereignisse im Peripheriegerät zu empfangen. Eine andere Möglichkeit besteht darin, dass der Peripherietreiber Benachrichtigungen von SerCx2 und dem seriellen Controllertreiber anfordert, wenn bestimmte Arten von Hardwareereignissen am seriellen Port auftreten. Der Peripherietreiber kann beispielsweise bitten, benachrichtigt zu werden, wenn der serielle Controller serielle Daten vom Peripheriegerät empfängt. Um diese Benachrichtigungen anzufordern, sendet der Peripherietreiber eine IOCTL_SERIAL_SET_WAIT_MASK Anforderung an das Peripheriegerät, um eine Reihe von zu überwachenden Ereignissen anzugeben, und sendet dann eine IOCTL_SERIAL_WAIT_ON_MASK Anforderung, um mit der Überwachung dieser Ereignisse zu beginnen. Diese Anforderungen werden von SerCx2 mit Hilfe des seriellen Controllertreibers verarbeitet. Weitere Informationen zu den Ereignistypen, die der Peripherietreiber überwachen kann, finden Sie unter SERIAL_EV_XXX , die in IOCTL_SERIAL_SET_WAIT_MASK beschrieben werden.

Der serielle Controller kann Hardwareereignisse jedoch nur erkennen, wenn er sich im D0-Gerätestromzustand befindet. Wenn sich der serielle Controller in einem Energiesparzustand befindet, kann sich der Peripherietreiber nicht auf Benachrichtigungen vom seriellen Controller verlassen, um z. B. zu erfahren, wann das Peripheriegerät neue Daten für den Treiber zum Lesen hat. In diesem Fall muss das Peripheriegerät ein Interruptsignal (oder vielleicht ein Wakesignal) über einen GPIO-Pin senden. Ein GPIO-Controller verbraucht nur sehr wenig Strom und bleibt in der Regel aktiv, nachdem die meisten anderen Geräte leistungsarm sind.