Übersicht über SPB-Peripheriegerätetreiber

Ein SPB-Peripheriegerätetreiber steuert ein Peripheriegerät, das mit einem einfachen Peripheriebus (SPB) verbunden ist. Die Hardwareregister dieses Geräts sind nur über SPB verfügbar. Um vom Gerät zu lesen oder darauf zu schreiben, muss der Treiber E/A-Anfragen an den SPB-Controller senden. Nur dieser Controller kann Datenübertragungen zum und vom Gerät über den SPB initiieren.

Ab Windows 8 bietet Windows Treiberunterstützung für Peripheriegeräte auf einfachen Peripheriebussen (SPBs). SPBs, z. B., I²C und SPI, werden häufig für die Verbindung mit Sensorgeräten mit niedriger Geschwindigkeit verwendet, wie etwa Beschleunigungsmessern, GPS-Geräten und Batteriestandsmonitoren. In dieser Übersicht wird beschrieben, wie ein SPB-Peripheriegerätetreiber in Zusammenarbeit mit anderen Systemkomponenten ein an SPB angeschlossenes Peripheriegerät steuert.

Ein SPB-Peripheriegerätetreiber kann erstellt werden, um entweder das User-Mode Driver Framework (UMDF) oder das Kernel-Mode Driver Framework (KMDF) zu verwenden. Weitere Informationen zum Entwickeln eines UMDF-Treibers finden Sie unter Erste Schritte mit UMDF. Weitere Informationen zum Entwickeln eines KMDF-Treibers finden Sie unter Erste Schritte mit dem Kernel-Mode Driver Framework.

Informationen zur Gerätekonfiguration

Die Hardwareregister eines über SPB angeschlossenen Peripheriegeräts werden nicht in den Speicher abgebildet. Auf das Gerät kann nur über den SPB-Controller zugegriffen werden, der Daten seriell über den SPB zum und vom Gerät überträgt. Um E/A-Vorgänge auszuführen, sendet der SPB-Peripheriegerätetreiber E/A-Anforderungen an das Gerät und der SPB-Controller führt die Datenübertragungen durch, die zum Abschließen dieser Anforderungen erforderlich sind. Weitere Informationen zu den E/A-Anforderungen, die an Peripheriegeräte auf SPBs gesendet werden können, finden Sie unter Verwenden der SPB-E/A-Anforderungsschnittstelle.

Das folgende Diagramm zeigt eine Beispielhardwarekonfiguration, bei der ein SPB (in diesem Fall ein I²C-Bus) zwei Peripheriegeräte mit einem SoC-Modul (System on a Chip) verbindet. Die Peripheriegeräte befinden sich außerhalb des SoC-Moduls und werden an vier Pins des Moduls angeschlossen. Das SoC-Modul enthält den Hauptprozessor (nicht angezeigt), sowie einen I²C-Controller und einen allgemeinen I/O-Controller (GPIO). Der Prozessor verwendet den I²C-Controller, um Daten seriell an und von den beiden Peripheriegeräten zu übertragen. Die Interrupt-Anforderungspositionen dieser Geräte sind mit zwei GPIO-Pins verbunden, die als Interrupt-Eingänge konfiguriert sind. Wenn ein Gerät eine Interrupt-Anforderung signalisiert, leitet der GPIO-Controller den Interrupt an den Prozessor weiter.

Da der GPIO-Controller und der I²C-Controller in diesem Beispiel in das SoC-Modul integriert sind, sind ihre Hardwareregister im Speicher abgebildet und können vom Prozessor direkt aufgerufen werden. Der Prozessor kann jedoch nur indirekt über den I²C-Controller auf die Hardwareregister der beiden Peripheriegeräte zugreifen.

Ein SPB ist kein Plug & Play-Bus (PnP) und kann daher nicht verwendet werden, um neue Geräte, die an den Bus angeschlossen sind, automatisch zu erkennen und zu konfigurieren. Die Bus- und Interrupt-Verbindungen eines über SPB angeschlossenen Geräts sind häufig permanent. Auch wenn das Gerät von einem Steckplatz getrennt werden kann, ist dieser Steckplatz in der Regel dem Gerät zugeordnet. Darüber hinaus bietet ein SPB keinen In-Band-Hardwarepfad für die Weiterleitung von Interrupt-Anforderungen von einem Peripheriegerät auf dem Bus an den Bus-Controller. Stattdessen ist der Hardwarepfad für Interrupts vom Buscontroller getrennt.

Der Anbieter der Hardwareplattform speichert die Konfigurationsinformationen für ein über SPB angeschlossenes Peripheriegerät in der ACPI-Firmware der Plattform. Während des Systemstarts listet der ACPI-Treiber die Geräte auf dem Bus für den PnP-Manager auf. Für jedes aufgezählte Gerät stellt ACPI Informationen über die Bus- und Interrupt-Verbindungen des Geräts bereit. Der PnP-Manager speichert diese Informationen in einem Datenspeicher, der als Ressourcenhub bezeichnet wird.

Wenn das Gerät gestartet wird, stellt der PnP-Manager den Treiber des Geräts mit einer Reihe von Hardwareressourcen bereit, die die Konfigurationsinformationen verknüpfen, die der Ressourcenhub für das Gerät speichert. Zu diesen Ressourcen gehören eine Verbindungs-ID und eine Interruptnummer. Die Verbindungs-ID verknüpft Busverbindungsinformationen wie den SPB-Controller, die Busadresse und die Bus-Taktfrequenz. Bevor E/A-Anfragen an das Gerät gesendet werden können, muss der Treiber zunächst mithilfe der Verbindungs-ID eine logische Verbindung zum Gerät herstellen. Die Interruptnummer ist eine Windows-Interruptressource, an die der Treiber seine Interrupt-Serviceroutine (ISR) anschließen kann. Der Treiber kann problemlos von einer Hardwareplattform auf eine andere portiert werden, da es sich bei der Verbindungs-ID und der Interruptnummer um Abstraktionen auf hoher Ebene handelt, die plattformspezifische Informationen über den physischen Bus und die Interruptverbindungen ausblenden.

Software- und Hardwareebenen

Das folgende Blockdiagramm zeigt die Software- und Hardwareebenen, die ein Peripheriegerät auf einem SPB mit einem Anwendungsprogramm verbinden, das das Gerät verwendet. Der SPB-Peripheriegerätetreiber in diesem Beispiel ist ein UMDF-Treiber. Das Peripheriegerät (unten im Diagramm) ist ein Sensorgerät (z. B. ein Beschleunigungsmesser). Wie im vorherigen Diagramm ist das Peripheriegerät mit einem I²C-Bus verbunden und signalisiert Interrupt-Anforderungen über einen Pin auf einem GPIO-Controller.

Die drei grau dargestellten Blöcke sind vom System bereitgestellte Module. Ab Windows 7 ist die Sensorklassenerweiterung als sensorspezifische Erweiterung für die UMDF verfügbar. Ab Windows 8 sind die SPB-Frameworkerweiterung (SpbCx) und die GPIO-Frameworkerweiterung (GpioClx) als Erweiterungen für KMDF verfügbar, die Funktionen ausführen, die jeweils spezifisch für SPB-Controller und GPIO-Controller sind.

Oben im vorherigen Diagramm ruft die Anwendung die Methoden in der Sensor-API oder der Standort-API auf, um mit dem Sensorgerät zu kommunizieren. Über diese Aufrufe kann die Anwendung E/A-Anforderungen an das Gerät senden und Ereignisbenachrichtigungen vom Gerät empfangen. Weitere Informationen zu diesen APIs finden Sie in der Einführung in die Sensor- und Standortplattform in Windows.

Wenn die Anwendung eine Methode aufruft, die eine Kommunikation mit dem SPB-Peripheriegerätetreiber erfordert, erstellt die Sensor-API oder die Standort-API eine E/A-Anforderung und sendet sie an den SPB-Peripheriegerätetreiber. Das Sensorklassenerweiterungsmodul unterstützt den Treiber bei der Behandlung dieser E/A-Anforderungen. Wenn der Treiber eine neue E/A-Anforderung erhält, übergibt er diese sofort an die Sensorklassenerweiterung, die die Anforderung in die Warteschlange stellt, bis der Treiber bereit ist, sie zu verarbeiten. Wenn eine E/A-Anforderung der Anwendung die Übertragung von Daten an oder vom Peripheriegerät erfordert, erstellt der SPB-Peripheriegerätetreiber eine E/A-Anforderung für diese Übertragung und sendet die Anforderung an den I²C-Controller. Solche Anforderungen werden gemeinsam von SpbCx und dem I²C-Controllertreiber verarbeitet.

SpbCx ist eine vom System bereitgestellte Komponente, die die Warteschlangen von E/A-Anforderungen für einen SPB-Controller verwaltet, z. B. den I2C-Controller in diesem Beispiel. Der I²C-Controllertreiber, der vom Hardwareanbieter für den Controller bereitgestellt wird, verwaltet alle hardwarespezifischen Vorgänge im I²C-Controller. Beispielsweise greift der Controller-Treiber auf die im Speicher abgebildeten Hardwareregister des Controllers zu, um Datenübertragungen zum und vom Peripheriegerät über den I²C-Bus zu initiieren.

Das Peripheriegerät signalisiert eine Interruptanforderung, wenn ein Hardwareereignis auftritt, das die Aufmerksamkeit des SPB-Peripheriegerätetreibers oder der Benutzermodusanwendung erfordert. Die Interrupt-Position vom Peripheriegerät ist mit einem GPIO-Pin verbunden, der für den Empfang von Interrupt-Anfragen konfiguriert ist. Wenn das Gerät einen Interrupt an den GPIO-Pin signalisiert, signalisiert der GPIO-Controller einen Interrupt an den Prozessor. Als Reaktion auf diesen Interrupt ruft der Interrupt-Trap-Handler des Kernels den ISR von GpioClx auf. Dieser ISR fragt den GPIO-Controller-Treiber ab, der dann auf die im Speicher abgebildeten Hardwareregister des GPIO-Controllers zugreift, um den unterbrechenden GPIO-Pin zu identifizieren. Um den Interrupt stummzuschalten, löscht der GPIO-Controller-Treiber die Interrupt-Anforderung am GPIO-Pin (wenn es sich um einen vom Edge ausgelösten Interrupt handelt) oder maskiert sie (wenn er auf einer Ebene ausgelöst wurde). Der Interrupt muss stummgeschaltet werden, um zu verhindern, dass der Prozessor denselben Interrupt erneut entgegennimmt, wenn der Trap-Handler zurückgegeben wird. Bei einem auf einer Ebene ausgelösten Interrupt muss der ISR im SPB-Peripheriegerätetreiber auf die Hardwareregister des Peripheriegeräts zugreifen, um den Interrupt zu löschen, bevor die Maskierung des GPIO-Pins aufgehoben werden kann.

Bevor der Interrupt-Trap-Handler des Kernels zurückgegeben wird, plant er die Ausführung des ISR im SPB-Peripheriegerätetreiber bei IRQL = PASSIVE_LEVEL. Ab Windows 8 kann ein UMDF-Treiber seinen ISR mit einem Interrupt verbinden, den der Treiber als abstrakte Windows-Interruptressource empfängt. Weitere Informationen finden Sie unter Behandeln von Interrupts. Um zu bestimmen, welcher ISR aufgerufen werden soll, sucht das Betriebssystem nach dem virtuellen Interrupt, der dem unterbrechenden GPIO-Pin zugewiesen ist, und findet den ISR, der mit dem Interrupt verbunden ist. Dieser virtuelle Interrupt wird als sekundärer Interrupt im vorherigen Diagramm bezeichnet. Im Gegensatz dazu wird der Hardware-Interrupt vom GPIO-Controller als primärer Interrupt bezeichnet.

Da der ISR im SPB-Peripheriegerätetreiber auf passiver Ebene ausgeführt wird, kann der ISR synchrone E/A-Anforderungen verwenden, um auf die Hardwareregister im Peripheriegerät zuzugreifen. Der ISR kann bis zum Abschluss dieser Anforderungen blockiert werden. Der ISR, der mit relativ hoher Priorität ausgeführt wird, sollte so schnell wie möglich zurückgegeben werden und die gesamte Hintergrundverarbeitung für einen Interrupt an eine Arbeitsroutine weitergeben, die mit niedrigerer Priorität ausgeführt wird.

Als Reaktion auf den sekundären Interrupt veröffentlicht der SPB-Peripheriegerätetreiber ein Ereignis in der Sensorklassenerweiterung, das die Benutzermodusanwendung über die Sensor-API oder die Standort-API über das Ereignis benachrichtigt.