Übersicht über die SerCx2-Architektur
SerCx2 arbeitet mit einem seriellen Controllertreiber zusammen, um die Kommunikation zwischen einem Peripherietreiber und einem seriellen Peripheriegerät zu ermöglichen. In der Regel ist der serielle Controller in einen SoC-Chip (System on a Chip) integriert, um die Kommunikation mit einer geringen Pinanzahl mit einem Peripheriegerät zu ermöglichen, das sich außerhalb des SoC-Chips befindet, aber an dieselbe Druckplatine gelöt wird.
Das folgende Diagramm zeigt den Kommunikationspfad zwischen einem seriellen Peripheriegerät und dem Treiber für dieses Gerät. Dieser Peripherietreiber wird entweder im Kernelmodus oder im Benutzermodus ausgeführt und sendet E/A-Anforderungen an den seriellen Port, mit dem das Peripheriegerät verbunden ist.
SerCx2 und der serielle Controllertreiber werden beide im Kernelmodus ausgeführt und kommunizieren über die SerCx2-Gerätetreiberschnittstelle (DDI). Der serielle Controllertreiber ruft Treiberunterstützungsmethoden auf, die von SerCx2 implementiert werden. SerCx2 ruft Ereignisrückruffunktionen auf, die vom seriellen Controllertreiber implementiert werden.
In der Regel sind die Hardwareregister des seriellen Controllers speicherseitig zugeordnet. Der treiber für serielle Controller greift direkt auf diese Register zu, um den seriellen Port zu konfigurieren und Daten an und von dem Peripheriegerät zu übertragen, das mit dem seriellen Port verbunden ist. Für längere Datenübertragungen verwendet SerCx2 in der Regel DMA-Übertragungen (nicht im vorherigen Diagramm dargestellt).
Die Informationen, die der Peripherietreiber benötigt, um eine logische Verbindung mit dem Peripheriegerät zu öffnen, sind in einer speziellen Art von Hardwareressource gekapselt, die als Verbindungs-ID bezeichnet wird. Weitere Informationen finden Sie unter Verbindungs-IDs für seriell verbundene Peripheriegeräte.
In der Regel senden nur Treiber E/A-Anforderungen direkt an einen seriellen Controller. Wenn eine Anwendung im Benutzermodus mit einem seriellen Peripheriegerät kommunizieren muss, fungiert der Peripherietreiber für das Gerät als Vermittler zwischen der Anwendung und dem Gerät. Wenn die Anwendung Daten an das oder vom Peripheriegerät übertragen muss, sendet die Anwendung eine Schreibanforderung (IRP_MJ_WRITE) oder eine Leseanforderung (IRP_MJ_READ) an den Peripherietreiber, und der Peripherietreiber antwortet, indem er eine entsprechende Schreib- oder Leseanforderung an den seriellen Controller sendet. Darüber hinaus kann der Peripherietreiber I/O-Steuerungsanforderungen (I/O Control Requests, IOCTLs) senden, um den seriellen Port zu konfigurieren. Eine Liste der von SerCx2 unterstützten IOCTLs finden Sie unter Serielle E/A-Anforderungsschnittstelle.
Der Peripherietreiber, der E/A-Anforderungen an den seriellen Controller sendet, ist entweder ein Kernelmodustreiber, der das Kernelmodustreiberframework (KMDF) verwendet, oder ein Benutzermodustreiber, der das User-Mode Driver Framework (UMDF) verwendet. SerCx2 verwaltet die Warteschlangen von E/A-Anforderungen, die vom Peripherietreiber an den seriellen Controller gesendet werden.
Als Reaktion auf eine Lese- oder Schreibanforderung initiiert SerCx2 eine oder mehrere E/A-Transaktionen, um Daten zwischen dem seriellen Controller und dem Datenpuffer in der Anforderung zu verschieben. Jede E/A-Transaktion verwendet entweder programmierte E/A (PIO) oder DMA, um Daten zwischen dem seriellen Controller und dem Datenpuffer in der Anforderung zu übertragen. Die Typen von E/A-Transaktionen, die von einem seriellen Controllertreiber unterstützt werden, hängen von den Hardwarefunktionen des seriellen Controllers ab. Weitere Informationen finden Sie unter Übersicht über SerCx2-E/A-Transaktionen.