GPIO-Treiberunterstützung – Übersicht
Ab Windows 8 vereinfacht die GPIO-Frameworkerweiterung (GpioClx) das Schreiben eines Treibers für ein GPIO-Controllergerät. Darüber hinaus bietet GpioClx Treiberunterstützung für Peripheriegeräte, die eine Verbindung mit GPIO-Pins herstellen. GpioClx, eine vom System bereitgestellte Erweiterung des Kernelmodustreiberframeworks (KMDF), führt Verarbeitungsaufgaben aus, die für Mitglieder der GPIO-Geräteklasse üblich sind.
In dieser Übersicht werden die folgenden Themen erläutert:
GPIO-Controllertreiber
Hardwareanbieter stellen Treiber bereit, um ihre GPIO-Controller zu steuern. Ein GPIO-Controllertreiber ist ein KMDF-Treiber, der alle hardwarespezifischen Vorgänge für einen GPIO-Controller verwaltet. Der GPIO-Controllertreiber arbeitet mit GpioClx zusammen, um E/A-Anforderungen für Gruppen von GPIO-Pins zu verarbeiten, die als Dateneingaben und Datenausgaben konfiguriert sind. Darüber hinaus arbeitet dieser Treiber mit GpioClx zusammen, um Interruptanforderungen von GPIO-Pins zu verarbeiten, die als Interrupteingaben konfiguriert sind.
Ein GPIO-Controllergerät verfügt über eine bestimmte Anzahl von GPIO-Pins. Diese Pins können physisch mit Peripheriegeräten verbunden werden. GPIO-Pins können als Dateneingaben, Datenausgaben oder Interruptanforderungseingaben konfiguriert werden. In der Regel ist ein GPIO-Pin für ein Peripheriegerät reserviert und nicht von zwei oder mehr Geräten freigegeben. Verbindungen zwischen GPIO-Pins und Peripheriegeräten sind behoben und können vom Benutzer nicht geändert werden (z. B. durch Entfernen eines Peripheriegeräts und Ersetzen durch ein anderes Gerät). Daher kann die Zuweisung von GPIO-Pins zu Peripheriegeräten in der Plattformfirmware beschrieben werden.
Das folgende Diagramm zeigt den GPIO-Controllertreiber und GpioClx.
Der GPIO-Controllertreiber und GpioClx kommunizieren miteinander über die GpioClx Device-Driver-Schnittstelle (DDI). Der GPIO-Controllertreiber ruft Treiberunterstützungsmethoden auf, die von GpioClx implementiert werden. GpioClx ruft Ereignisrückruffunktionen auf , die vom GPIO-Controllertreiber implementiert werden.
Der GPIO-Controllertreiber greift direkt auf die Hardwareregister des GPIO-Controllergeräts zu.
GpioClx verarbeitet E/A-Anforderungen von den Treibern für Peripheriegeräte, die physisch eine Verbindung mit GPIO-Pins herstellen. GpioClx übersetzt diese E/A-Anforderungen in einfache Hardwarevorgänge, die durch Aufrufen der Vom GPIO-Controllertreiber implementierten Ereignisrückruffunktionen ausgeführt werden. Um beispielsweise Daten aus einer Gruppe von GPIO-Pins zu lesen oder Daten in einen Satz von GPIO-Pins zu schreiben, ruft GpioClx Ereignisrückruffunktionen wie CLIENT_ReadGpioPins und CLIENT_WriteGpioPins auf. GpioClx verwaltet die E/A-Warteschlangen für den GPIO-Controller und entlastet dadurch den GPIO-Controllertreiber von dieser Aufgabe.
Darüber hinaus verarbeitet GpioClx primäre Interrupts vom GPIO-Controllergerät und ordnet diese Interrupts sekundären Interrupts zu, die von Peripheriegerätetreibern verarbeitet werden. Primäre Interrupts sind Interrupts, die von Hardwaregeräten generiert werden. Sekundäre Interrupts werden vom Betriebssystem als Reaktion auf bestimmte primäre Interrupts generiert. Sowohl primäre als auch sekundäre Interrupts werden durch globale Systemunterbrechungen (GSIs) identifiziert. Die ACPI-Firmware für die Hardwareplattform weist GSIs primären Interrupts zu, und zur Laufzeit weist das Betriebssystem GSIs sekundären Interrupts zu.
Beispielsweise weist die Firmware dem Hardware-Interrupt vom GPIO-Controller einen GSI zu, und das Betriebssystem weist einem GPIO-Pin, der als Interrupteingabe konfiguriert ist, einen GSI zu.
GpioClx implementiert einen ISR, der die hardwaregenerierten primären Interrupts vom GPIO-Controllergerät verarbeitet. Wenn ein Peripheriegerät einen Interrupt für einen GPIO-Pin angibt und Interrupts für diesen Pin aktiviert und enttarnt werden, unterbricht der GPIO-Controller den Prozessor. Als Reaktion plant der Kernel-Trap-Handler die Ausführung des GpioClx-ISR. Um den GPIO-Pin zu identifizieren, der den Interrupt verursacht hat, ruft gpioClx ISR die CLIENT_QueryActiveInterrupts Ereignisrückruffunktion auf, die vom GPIO-Controllertreiber implementiert wird. Der GpioClx-ISR sucht dann nach dem GSI, der diesem Pin zugewiesen ist, und übergibt diesen GSI an die Hardware abstraction Layer (HAL). Die HAL generiert einen sekundären Interrupt durch Aufrufen des ISR, der für diese GSI registriert ist. Dieser ISR gehört zum Treiber für das Peripheriegerät, das den Interrupt ursprünglich behauptet hat.
Weitere Informationen zu primären und sekundären Interrupts finden Sie unter GPIO Interrupts.
Treiber für Peripheriegeräte, die GPIO-Pins verwenden
Beim Start listet der Plug & Play-Manager (PnP) sowohl PnP-Geräte als auch Nicht-PnP-Geräte auf. Bei Nicht-PnP-Geräten, die über feste Verbindungen mit GPIO-Pins verfügen, fragt der PnP-Manager die Plattformfirmware ab, um zu ermitteln, welche GPIO-Pins diesen Geräten als systemverwaltete Hardwareressourcen zugewiesen sind.
Der KMDF-Treiber für ein Peripheriegerät empfängt die zugewiesenen Hardwareressourcen während eines EvtDevicePrepareHardware-Rückrufs . Diese Ressourcen können GPIO-Pins enthalten, die als Datenausgaben, Dateneingaben oder Interruptanforderungseingaben konfiguriert sind.
Eine GPIO-E/A-Ressource ist ein neuer Windows-Ressourcentyp in Windows 8. Diese Ressource besteht aus einem Satz von mindestens einem GPIO-Pin, der entweder als Dateneingaben oder Als Datenausgaben verwendet werden kann. Wenn ein Peripheriegerätetreiber eine GPIO-E/A-Ressource für Lesevorgänge öffnet, verwendet der Treiber alle Pins in der Ressource als Dateneingaben. Wenn ein Treiber eine GPIO-E/A-Ressource für Schreibvorgänge öffnet, verwendet der Treiber alle Pins in der Ressource als Datenausgaben. Codebeispiele, die zeigen, wie ein Treiber für Peripheriegeräte eine logische Verbindung mit einer Reihe von GPIO-E/A-Pins öffnet, finden Sie in den folgenden Themen:
Verbinden eines KMDF-Treibers mit GPIO-E/A-Pins
Ein GPIO-Pin, der als Interrupteingabe konfiguriert ist, wird einem Treiber als normale Windows-Interruptressource zugewiesen. Die Abstraktion der Interruptressource blendet die Tatsache aus, dass ein Interrupt möglicherweise durch einen GPIO-Pin anstelle eines programmierbaren Interruptcontrollers implementiert werden kann. Daher kann der Treiber eine GPIO-basierte Interruptressource genauso behandeln wie jede andere Interruptressource.
Um auf die GPIO-Pins in einer GPIO-E/A-Ressource zuzugreifen, muss ein Peripheriegerätetreiber eine logische Verbindung mit den Pins herstellen. Ein KMDF-Treiber ruft die WdfIoTargetOpen-Methode auf, um die Verbindung zu öffnen. Über diese Verbindung kann der Treiber E/A-Anforderungen an die GPIO-Pins senden. Der Treiber sendet IOCTL_GPIO_READ_PINS Anforderungen zum Lesen von Daten von diesen Pins (wenn es sich um Eingabenadeln handelt) oder IOCTL_GPIO_WRITE_PINS Anforderungen zum Schreiben von Daten in sie (wenn es sich um Ausgabepins handelt).
Um Interrupts vom GPIO-Pin in einer Interruptressource zu empfangen, muss ein Peripheriegerätetreiber seine Interruptdienstroutine (ISR) registrieren, um Interrupts von der Interruptressource zu empfangen, die von diesem Pin implementiert wird. Ein KMDF-Treiber ruft die WdfInterruptCreate-Methode auf, um einen ISR mit dem Interrupt zu verbinden.