GPIO-Based Hardwareressourcen

Ab Windows 8 stehen die allgemeinen I/O-Pins (GPIO), die von einem GPIO-Controllertreiber gesteuert werden, anderen Treibern als vom System verwaltete Hardwareressourcen zur Verfügung. GPIO-E/A-Pins, die als Dateneingaben oder Datenausgabe konfiguriert sind, stehen als neue Windows-Ressourcentyp, GPIO-E/A-Ressourcen, zur Verfügung. Darüber hinaus sind GPIO-Interrupt-Pins, die als Interruptanforderungseingaben konfiguriert sind, als normale Windows-Interruptressourcen verfügbar.

Eine GPIO-E/A-Ressource stellt eine Gruppe von einem oder mehreren GPIO-Pins dar, auf die der Treiber für ein Peripheriegerät zugreifen kann. Windows blendet Details zur zugrunde liegenden Implementierung der GPIO-I/O-Pins aus, sodass Peripheriegerätetreiber geschrieben werden können, um abstrakte GPIO-E/A-Ressourcen zu bearbeiten. Peripheriegerätetreiber, die diese abstrakten Ressourcen verwenden, können unabhängig von der GPIO-Controllerhardware, die die Ressourcen implementiert, plattformübergreifend funktionieren. Eine GPIO-E/A-Ressource wird durch ein WDFIOTARGET-Handle dargestellt, das diese Ressource dem spezifischen GPIO-Controllertreiber zuordnet, der die zugrunde liegenden GPIO-Pins oder -Pins besitzt.

In der Regel kann ein E/A-Pin auf einem GPIO-Controller entweder für die Eingabe oder für die Ausgabe konfiguriert werden, abhängig von den Funktionen der Controllerhardware und des Geräts, das physisch mit dem Pin verbunden ist. Daher kann ein Treiber eine logische Verbindung mit diesem Pin für Schreib- oder Lesevorgänge öffnen, aber nicht für beides. Diese Einschränkung wird jedoch von der Hardware und nicht von der GPIO-Frameworkerweiterung (GpioClx) auferlegt. Wenn die Hardware die Konfiguration eines E/A-Pins sowohl für die Eingabe als auch für die Ausgabe ermöglicht, ermöglicht GpioClx einem Treiber das Öffnen einer logischen Verbindung mit dem Pin für Lese- und Schreibvorgänge.

Für GPIO-Pins, die als Interruptanforderungseingaben konfiguriert sind, wird die Tatsache, dass eine Interruptanforderung von einem GPIO-Pin anstelle eines Interruptcontrollers oder einer dedizierten Interruptanforderungszeile vom Betriebssystem implementiert wird, vollständig abstrahiert. GPIO-Interrupts werden den Peripheriegerätetreibern als abstrakte Interruptressourcen angezeigt. Die Abstraktion dieser Ressourcen wird vom GPIO-Treiberstapel und von der Hardwarestraktionsebene (HAL) unterstützt. Daher können Peripheriegerätetreiber, die Interruptressourcen verwenden, weitgehend Details zur zugrunde liegenden Implementierung dieser Ressourcen ignorieren. Weitere Informationen finden Sie unter GPIO Interrupts.

Das folgende Diagramm zeigt eine Beispielzuordnung von GPIO-basierten Ressourcen zu zwei Peripheriegerätetreibern:

Im vorherigen Diagramm werden die folgenden drei GPIO-basierten Ressourcen dem Peripheriegerätetreiber A zugewiesen:

• Zwei Dateneingabe-Pins
• Datenausgabe-Pin
• Ein Interrupt-Eingabe-Pin

Die folgenden beiden GPIO-basierten Ressourcen werden dem Peripheriegerätetreiber B zugewiesen:

• Daten-Eingabe-Pin
• Ein Interrupt-Eingabe-Pin

Treiber A und B erhalten ihre zugewiesenen Ressourcen in ihren EvtDevicePrepareHardware-Rückruffunktionen . Wenn ein Treiber als Ressource eine Gruppe von einem oder mehreren GPIO-E/A-Pins empfängt, kann der Treiber eine Verbindung mit diesen Pins öffnen, um darauf zuzugreifen. Der Treiber ruft ein WDFIOTARGET-Handle ab, um die Verbindung zu identifizieren und E/A-Anforderungen an dieses Handle zu senden, um von diesen Pins zu lesen oder auf sie zu schreiben.

Codebeispiele, die zeigen, wie Sie eine Verbindung mit einer Reihe von GPIO-E/A-Pins herstellen und E/A-Anforderungen an diese Pins senden, finden Sie in den folgenden Themen:

Verbinden eines KMDF-Treibers mit GPIO-I/O-Pins

In beiden Themen öffnet die IoRoutine Funktion im Codebeispiel je nach ReadOperation Parameterwert entweder eine GPIO-E/A-Pinressource für Lesevorgänge oder für Schreibvorgänge. Wenn die Ressource für Lesevorgänge geöffnet wird (DesiredAccess = GENERIC_READ), werden die Pins in der Ressource als Eingaben konfiguriert, und eine an die Pinressource gesendete IOCTL_GPIO_READ_PINS Anforderung liest die Eingabewerte an diesen Pins vor. GpioClx lässt nicht zu, dass eine IOCTL_GPIO_WRITE_PINS-Anforderung an eine Gruppe von Eingabe-Pins gesendet werden soll und schließt eine solche Anforderung mit einem STATUS_GPIO_OPERATION_DENIED-Fehlerstatus ab. Wenn die Pinressource für Schreibvorgänge geöffnet wird (DesiredAccess = GENERIC_WRITE), werden die Pins in der Ressource als Ausgänge konfiguriert, und eine IOCTL_GPIO_WRITE_PINS-Anforderung wird an die Pinressource gesendet und legt die Werte in den Ausgangslatches fest, die diese Pins steuern. Das Senden einer IOCTL_GPIO_READ_PINS-Anforderung an eine Reihe von Ausgabepins liest in der Regel einfach die zuletzt in die Ausgabelatches geschriebenen Werte aus.

Um eine Interruptressource zum Empfangen von Unterbrechungen zu verwenden, muss ein Clienttreiber eine Unterbrechungsdienstroutine (Interrupt Service Routine, ISR) mit dem Interrupt verbinden. In der Regel führt der Treiber diese Verbindung durch Aufrufen der WdfInterruptCreate-Methode (oder möglicherweise der IoConnectInterruptEx-Routine ) durch. Weitere Informationen zu KMDF-Unterbrechungen finden Sie unter Erstellen eines Interrupt-Objekts.

Im Gegensatz zu Plug- und Play-Geräten, die dynamisch mit einer Hardwareplattform verbunden und getrennt werden können, wird ein GPIO-Controllergerät dauerhaft angeschlossen. Darüber hinaus wird davon ausgegangen, dass Verbindungen zwischen GPIO-Pins und einem Peripheriegerät dauerhaft sind. (Wenn das Peripheriegerät von einem Steckplatz getrennt werden kann, dann ist der Steckplatz diesem Gerät zugeordnet.) Daher sind die verfügbaren GPIO-Ressourcen festgelegt und können in der Plattformfirmware angegeben werden. Ebenso wird davon ausgegangen, dass Peripheriegerätetreiber, die GPIO-Ressourcen verwenden, dedizierte Gruppen von GPIO-Ressourcen verwenden. Daher können die Ressourcenanforderungen für diese Gerätetreiber in der Plattformfirmware angegeben werden.

Wenn die Plattformfirmware eine Reihe von GPIO-Pins als GPIO-E/A-Ressource angibt, gibt die Firmware an, ob die Pins in dieser Ressource für Lesevorgänge, Schreibvorgänge oder für Lese- und Schreibvorgänge geöffnet werden können.

Wenn ein Peripheriegerätetreiber mehrere GPIO-E/A-Ressourcen verwendet, muss dieser Treiber die Reihenfolge kennen, in der diese Ressourcen vom PnP-Manager aufgezählt werden. Wenn ein Treiber beispielsweise zwei GPIO-E/A-Pins verwendet, diese Pins jedoch unabhängig und zu separaten Zeiten aufgerufen werden müssen, sollte die Plattformfirmware jeden Pin als separate GPIO-E/A-Ressource beschreiben. Der PnP-Manager listet diese Ressourcen in der Reihenfolge auf, in der sie in der Plattformfirmware beschrieben werden, die mit der vom Treiber erwarteten Reihenfolge übereinstimmen muss.

Nachdem ein Peripheriegerätetreiber eine Verbindung mit einer GPIO-E/A-Ressource öffnet, greift ein IOCTL_GPIO_READ_PINS oder IOCTL_GPIO_WRITE_PINS Anforderung, dass dieser Treiber an diese Verbindung sendet, auf alle Pins in der Ressource zu. Wenn der Treiber manchmal nur auf eine Teilmenge dieser Pins zugreifen darf, muss diese Teilmenge dem Treiber als separate Ressource zugewiesen werden.

Weitere Informationen zu IOCTL_GPIO_READ_PINS Anforderungen, einschließlich der Zuordnung von Dateneingabe-Pins zu den Bits im Anforderungsausgabepuffer, finden Sie unter IOCTL_GPIO_READ_PINS. Weitere Informationen zu IOCTL_GPIO_WRITE_PINS Anforderungen, einschließlich der Zuordnung der Bits im Anforderungseingabepuffer zu Datenausgabe-Pins, finden Sie unter IOCTL_GPIO_WRITE_PINS.