Freigeben über


USB-Dual-Role-Treiberstapelarchitektur

USB-Dual-Role-Controller werden jetzt in Windows unterstützt, beginnend mit Windows 10 für Desktop-Editionen (Home, Pro, Enterprise und Education) und Windows 10 Mobile.

Einführung

Die USB-Dual-Role-Funktion ermöglicht es einem System, entweder ein USB-Gerät oder ein USB-Host zu sein. Die detaillierte Spezifikation für die USB-Dual-Role finden Sie auf der USB-IF-Informationsseite USB-On-The-Go.

Mit der Dual-Role-Funktion kann sich ein mobiles Gerät wie etwa ein Telefon oder ein Tablet selbst als Gerät oder Host kennzeichnen.

Wenn sich ein mobiles Gerät im Funktionsmodus befindet, ist es an einen PC oder ein anderes Gerät angeschlossen, das als Host für das angeschlossene mobile Gerät fungiert.

Wenn sich ein mobiles Gerät im Hostmodus befindet, können Benutzer ihr Gerät, beispielsweise eine Maus oder eine Tastatur, anschließen. In diesem Fall hostet das mobile Gerät angeschlossene Geräte.

Durch die Unterstützung der USB-Dual-Role in Windows 10 bieten wir die folgenden Vorteile:

  • Konnektivität zu mobilen Peripheriegeräten über USB, das im Vergleich zu drahtlosen Protokollen wie Bluetooth eine größere Datenbandbreite bietet.
  • Die Möglichkeit, den Akku über USB aufzuladen, während eine Verbindung zu anderen USB-Geräten besteht und diese kommunizieren (sofern die erforderliche Hardware-Unterstützung vorhanden ist).
  • Unterstützen Sie Kunden, die höchstwahrscheinlich für ihre gesamte Arbeit ein mobiles Gerät wie beispielsweise ein Smartphone besitzen. Diese Funktion ermöglicht eine verbesserte Produktivität in einem kabelgebundenen Docking-Szenario, in dem ein mobiles Gerät andockt und somit Peripheriegeräte hostet.

Die folgende Tabelle zeigt die Liste der Hostklassentreiber, die in den Desktop- und Mobilversionen von Windows verfügbar sind.

USB-Hostklassentreiber Windows 10 Mobile Windows 10-Desktopeditionen
USB-Hubs (USBHUB) Ja Ja (seit Windows 2000)
HID – Tastatur/Mäuse (HidClass, KBDCLass, MouClass, KBDHid, MouHid) Ja Ja (seit Windows 2000)
USB-Massenspeicher (Massenspeicher & UASP) Ja Ja (seit Windows 2000)
Generischer USB-Hosttreiber (WinUSB) Ja Ja (seit Windows Vista)
USB-Audio ein/aus (USBAUDIO) Ja Ja (seit Windows XP)
Serielle Geräte (USBSER) Ja Ja (seit Windows 10)
Bluetooth (BTHUSB) Ja Ja (seit Windows XP)
Drucken (usbprint) No Ja (seit Windows XP)
Scannen (USBSCAN) No Ja (seit Windows 2000)
WebCam (USBVIDEO) No Ja (seit Windows Vista)
Media Transfer Protocol (MTP Initiator) No Ja (seit Windows Vista)
Remote-NDIS (RNDIS) No Ja (seit Windows XP)
IP über USB (IPoverUSB) No Ja (Neu für Windows 10)

Die Klassentreiber in der Tabelle wurden auf Grundlage der Geräteklassentelemetrie und auf Grundlage der für Windows 10 ausgewählten Schlüsselszenarien ausgewählt. Wir planen, eine begrenzte Anzahl von Host-Treibern von Drittanbietern in den Posteingang aufzunehmen, um wichtige Geräte unter Windows 10 Mobile zu unterstützen. Und für Windows 10 für Desktop-Editionen sind diese Treiber entweder auf der Website des OEM oder über Windows Update (WU) verfügbar.

Für Windows 10 Mobile sind die Treiber von Drittanbietern, die nicht im Posteingang enthalten sind, bei Windows Update nicht verfügbar. Der Festplattenbedarf des USB-Host-Stacks + HID wird gering gehalten. Aus diesem Grund sind nicht alle Klassentreiber und einige Treiber von Drittanbietern im Posteingang für Windows 10 Mobile enthalten. Ein OEM, der Treiber von Drittanbietern verfügbar machen möchte, kann ein Board Support Package (BSP) verwenden, um sie zu Betriebssystem-Images für seine Mobilgeräte hinzuzufügen.

Die folgende Tabelle zeigt die Funktionsklassentreiber, die in den mobilen Editionen von Windows verfügbar sind.

Hinweis

Funktionstreiber sind unter Windows 10 für Desktopeditionen nicht verfügbar.

Treiber für USB-Funktionsklassen Windows 10 Mobile Windows 10-Desktopeditionen Hinweise
Media Transfer Protocol (MTP) Responder Ja No Es gibt keine Szenarien für MTP-Responder auf Desktop. P2P-Szenarien zwischen Desktopsystemen wurden über Easy-MigCable über WinUSB aktiviert.
Videoanzeigeausgang (vidstream) Ja No
Generischer USB-Funktionstreiber (GenericUSBFn) Ja No IPoverUSB und andere Flashingszenarien für Desktops benötigen diesen Treiber.

Wir überwachen die Geräteanschlussdaten, um zu erfahren, ob wir bei der Aktualisierung der Beliebtheitsliste der Geräteklassen mehr Unterstützung für Klassentreiber bereitstellen müssen.

Treiberimplementierung

Der Microsoft USB Role Switch-Treiber (URS) ermöglicht es einem Systemimplementierer, die Dual-Role-USB-Funktion ihrer Plattform zu nutzen.

Der URS-Treiber soll eine Dual-Role-Funktionalität für Plattformen bereitstellen, die einen einzelnen USB-Controller verwenden, der über einen einzigen Port sowohl als Host als auch als Peripheriegerät betrieben werden kann. Die Peripherierolle wird auch als Funktionsrolle bezeichnet. Der URS-Treiber verwaltet die aktuelle Rolle des Ports. Der URS-Treiber lädt und entlädt geeignete Softwarestapel basierend auf Hardwareereignissen von der Plattform.

Auf einem System mit einem USB-Micro-AB-Anschluss verwendet der Treiber Hardware-Interrupts, die den Status des ID-Pins am Anschluss anzeigen. Über diesen Pin lässt sich erkennen, ob der Controller bei einer Verbindung die Host-Rolle oder die Funktionsrolle übernehmen muss. Weitere Informationen finden Sie in der USB-On-The-Go-Spezifikation. Auf Systemen mit einem USB Type-C-Anschluss wird vom OEM-Implementierer erwartet, dass er einen Connector-Client-Treiber bereitstellt, indem er die Programmierschnittstellen des USB Type-C Port Controller-Treibers verwendet. Der Client-Treiber kommuniziert mit der von Microsoft bereitgestellten USB Connector Manager-Klassenerweiterung (UcmCx), um alle Aspekte des USB Type-C-Anschlusses zu verwalten, wie etwa CC-Erkennung, PD-Messaging und andere. Zum Rollenwechsel übermittelt der Client-Treiber den Status des USB Type-C-Anschlusses an den URS-Treiber.

Das folgende Diagramm zeigt den USB-Softwaretreiberstapel für einen Dual-Role-Controller, der den URS-Treiber verwendet.

Architektur des USB-Rollenschalter-Treiberstapels.

Der URS-Treiber lädt die im vorhergehenden Diagramm gezeigten Funktions- und Host-Stapel niemals gleichzeitig. Der URS-Treiber lädt je nach Rolle des USB-Controllers entweder den Funktionsstapel oder den Hoststapel.

Hardwareanforderungen

Wenn Sie eine Plattform entwickeln, die den URS-Treiber nutzt, um Dual-Role-USB-Funktionalität bereitzustellen, müssen die folgenden Hardwareanforderungen erfüllt sein:

  • USB-Controller

    Diese Treiber werden von Microsoft als In-Box-Treiber bereitgestellt.

    Synopsys DesignWare Core USB 3.0 Controller. Inbox INF: UrsSynopsys.inf.

    Chipidea High-Speed USB OTG Controller. Inbox INF: UrsChipidea.inf.

  • ID-Pin-Interrupts

    • Ein oder mehrere ID-Pin-Interrupts für Nicht-USB-Typ-C-Systeme werden auf eine der zwei Arten implementiert:

      1. Zwei Edge-gesteuerte Interrupts: einer wird ausgelöst, wenn der ID-Pin am Anschluss geerdet ist, und ein anderer wird ausgelöst, wenn der ID-Pin unverankert ist.
      2. Ein einzelner aktiver Interrupt, der sich auf aktiver Ebene befindet, wenn der ID-Pin geerdet wird.
  • USB-Controllerenumeration

    Der USB-Dual-Role-Controller muss ACPI-enumeriert werden.

  • Softwaresupport

    Der URS-Treiber erwartet eine Softwareschnittstelle, die die Steuerung von VBus über den Konnektor ermöglicht. Diese Schnittstelle ist SoC-spezifisch. Wenden Sie sich an Ihren SoC-Anbieter, um weitere Informationen zu erhalten.

Diese USB-OTG-Features werden in Windows nicht unterstützt:

  • Accessory Charger Adapter Detection (ACA).
  • Session Request Protocol (SRP).
  • Host Negotiation Protocol (HNP).
  • Attach Detection Protocol (ADP).

ACPI-Systemkonfiguration

Um den URS-Treiber zu verwenden, müssen Sie eine ACPI-Definitionsdatei für Ihr System erstellen. Darüber hinaus gibt es einige treiberbezogene Überlegungen, die Sie berücksichtigen müssen.

Hier ist eine Beispiel-ACPI-Definition für einen USB-Dual-Role-Controller.

//
// You may name the device whatever you want; we don't depend on it being called 'URS0'.
//
Device(URS0)
{
    //
    // Replace with your own hardware ID. Microsoft will add it to the inbox INF,
    // or you may choose to author a custom INF that uses Needs & Includes directives
    // to include sections from the inbox INF.
    //
    Name(_HID, "ABCD1234")

    Name(_CRS, ResourceTemplate() {
        //
        // The register space for the controller must be defined here.
        //
        Memory32Fixed(ReadWrite, 0xf1000000, 0xfffff)


        //
        // The ID pin interrupts, if you are using two edge-triggered interrupts.
        //
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1001}
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1002}

        //
        // Following is an example of a single active-both interrupt.
        //
        // GpioInt(Edge, ActiveBoth, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x12}
        //

        //
        // For a Type-C platform, you do not need to specify any interrupts here.
        //
    })

    //
    // This child device represents the USB host controller. This device node is in effect
    // when the controller is in host mode.
    // You may name the device whatever you want; we don't depend on it being called 'USB0'.
    //
    Device(USB0)
    {
        //
        // The host controller device node needs to have an address of '0'
        //
        Name(_ADR, 0)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt.
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x10}
        })
    }

    //
    // This child device represents the USB function controller. This device node is in effect
    // when the controller is in device/function/peripheral mode.
    // You may name the device whatever you want; we don't depend on it being called 'UFN0'.
    //
    Device(UFN0)
    {
        //
        // The function controller device node needs to have an address of '1'
        //
        Name(_ADR, 1)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt (this could be the same as the one defined in
            // the host controller).
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x11}
        })
    }
}

Hier sind einige Erläuterungen für die Hauptabschnitte der ACPI-Datei:

  • URS0 ist die ACPI-Definition für den USB-Dual-Role-Controller. Der URS-Treiber wird auf diesem ACPI-Gerät geladen.

  • USB0 und UFN0 sind untergeordnete Geräte im Bereich von URS0. USB0 und UFN0 stellen die beiden untergeordneten Stapel dar, die vom URS-Treiber aufgezählt werden, bzw. die Host- und Funktionsstapel. _ADR ist das Mittel, mit dem ACPI diese Gerätedefinitionen mit den Geräteobjekten abgleicht, die der URS-Treiber erstellt.

  • Wenn der Controller denselben Interrupt für beide Rollen verwendet, kann derselbe Controller-Interrupt auf beiden untergeordneten Geräten beschrieben werden. Selbst in diesem Fall kann der Interrupt weiterhin als „Exklusiv“ bezeichnet werden.

  • Sie können bei Bedarf Ergänzungen zu dieser ACPI-Definitionsdatei vornehmen. Sie können beispielsweise alle anderen erforderlichen Methoden oder Eigenschaften auf einem der Geräte in der ACPI-Definitionsdatei festlegen. Solche Ergänzungen beeinträchtigen den Betrieb des URS-Treibers nicht. Alle anderen Ressourcen, die in einem der Stapel erforderlich sind, können auch im _CRS des entsprechenden Geräts beschrieben werden.

Der URS-Treiber weist dem Host- und Funktionsstapel Hardware-IDs zu. Diese Hardware-IDs werden von der Hardware-ID des URS-Geräts abgeleitet. Wenn Sie beispielsweise über ein URS-Gerät verfügen, dessen Hardware-ID ACPI\ABCD1234 ist, erstellt der URS-Treiber Hardware-IDs für den Host- und Funktionsstapel wie folgt:

  • Host-Stapel: URS\ABCD1234&HOST

  • Funktionsstapel: URS\ABCD1234&FUNCTION

INF-Treiberinstallationspakete

Treiberpakete von Drittanbietern können bei Bedarf eine Abhängigkeit von diesem Schema annehmen.

Wenn Sie ein IHV oder OEM sind und darüber nachdenken, Ihr eigenes Treiberpaket bereitzustellen, sollten Sie Folgendes berücksichtigen:

  • URS-Treiberpaket

    Die Hardware-ID für den Dual-Role-Controller auf jeder Plattform wird dem Posteingangs-INF für URS hinzugefügt. Wenn die ID jedoch aus irgendeinem Grund nicht hinzugefügt werden kann, kann der IHV/OEM ein Treiberpaket mit einem INF bereitstellen, das den Posteingang INF benötigt/einschließt und deren Hardware-ID entspricht.

    Dieses Treiberpaket ist erforderlich, wenn für den IHV/OEM ein Filtertreiber im Treiberstapel vorhanden sein muss.

  • Hosttreiberpaket

    Ein vom IHV/OEM bereitgestelltes Treiberpaket, das den Posteingang usbxhci.inf benötigt/enthält und der Hardware-ID des Hostgeräts entspricht, ist erforderlich. Die Hardware-ID-Übereinstimmung basiert auf dem im vorherigen Abschnitt beschriebenen Schema.

    Dieses Treiberpaket ist erforderlich, wenn für den IHV/OEM ein Filtertreiber im Treiberstapel vorhanden sein muss.

    Derzeit wird daran gearbeitet, dass der URS-Treiber die XHCI-kompatible ID für das Hostgerät zuweist.

  • Funktionstreiberpaket

    Ein vom IHV/OEM bereitgestelltes Treiberpaket, das den Posteingang Ufxsynopsys.inf benötigt/enthält und der Hardware-ID des Peripheriegeräts entspricht, ist erforderlich. Die Hardware-ID-Übereinstimmung basiert auf dem im vorherigen Abschnitt beschriebenen Schema.

    Der IHV/OEM kann auch einen Filtertreiber in das Treiberpaket aufnehmen.

Siehe auch