Partilhar via


Arquitetura de stack de drivers USB com função dual

Os controladores de função dupla USB agora são suportados no Windows, começando com o Windows 10 para edições de área de trabalho (Home, Pro, Enterprise e Education) e o Windows 10 Mobile.

Introdução

O recurso de função dupla USB torna possível que um sistema seja um dispositivo USB ou um host USB. A especificação detalhada para a função dupla USB pode ser encontrada na página de informações de USB On-the-Go do USB-IF.

O recurso de função dupla permite que um dispositivo móvel, como um telefone ou um tablet, se designe como sendo um dispositivo ou um host.

Quando um dispositivo móvel está no modo de função, ele é conectado a um PC ou a algum outro dispositivo que atua como host para o dispositivo móvel conectado.

Quando um dispositivo móvel está no modo host, os usuários podem conectar seu dispositivo, como um mouse ou teclado. Nesse caso, o dispositivo móvel hospeda dispositivos conectados.

Ao fornecer suporte para função dupla USB no Windows 10, oferecemos os seguintes benefícios:

  • Conectividade com dispositivos periféricos móveis via USB, que oferece uma maior largura de banda de dados em comparação com protocolos sem fio como Bluetooth.
  • A opção de carregamento da bateria por USB enquanto estiver ligado e a comunicar-se com outros dispositivos USB (desde que o suporte de hardware necessário esteja presente).
  • Habilite os clientes que provavelmente possuirão um dispositivo móvel, como um smartphone para todo o seu trabalho. Esse recurso permite maior produtividade em um cenário de encaixe com fio, onde um dispositivo móvel encaixa e, portanto, hospeda dispositivos periféricos.

A tabela a seguir mostra a lista de drivers de classe de host que estão disponíveis nas edições desktop e mobile do Windows.

Drivers de classe de host USB Windows 10 Móvel Windows 10 para versões para desktop
Hubs USB (USBHUB) Yes Sim (desde o Windows 2000)
HID - Teclado/Ratones (HidClass, KBDCLass, MouClass, KBDHid, MouHid) Yes Sim (desde o Windows 2000)
Armazenamento em massa USB (Bulk & UASP) Yes Sim (desde o Windows 2000)
Controlador de anfitrião USB genérico (WinUSB) Yes Sim (desde o Windows Vista)
Entrada/saída de áudio USB (USBAUDIO) Yes Sim (desde o Windows XP)
Dispositivos seriais (USBSER) Yes Sim (a partir do Windows 10)
Bluetooth (BTHUSB) Yes Sim (desde o Windows XP)
Impressão (usbprint) Não Sim (desde o Windows XP)
Digitalização (USBSCAN) Não Sim (desde o Windows 2000)
WebCam (USBVIDEO) Não Sim (desde o Windows Vista)
Protocolo de transferência de mídia (iniciador MTP) Não Sim (desde o Windows Vista)
NDIS remoto (RNDIS) Não Sim (desde o Windows XP)
IP sobre USB (IPoverUSB) Não Sim (Novo para Windows 10)

Os drivers de classe na tabela foram selecionados com base na telemetria de classe de dispositivo e com base nos principais cenários selecionados para o Windows 10. Planeamos incluir um número limitado de controladores de anfitrião de terceiros na caixa de entrada para suportar dispositivos-chave no Windows 10 Mobile. E para o Windows 10 para edições de desktop, esses drivers estão disponíveis no site do OEM ou via Windows Update (WU).

Para o Windows 10 Mobile, os drivers de terceiros que não estão incluídos na caixa de entrada não estão disponíveis no Windows Update. A pegada de disco da pilha USB Host + HID é mantida pequena. É por isso que nem todos os drivers de classe e alguns drivers de terceiros estão incluídos na caixa de entrada para o Windows 10 Mobile. Um OEM que deseje disponibilizar drivers de terceiros pode usar um pacote de suporte de placa (BSP) para adicioná-los às imagens do sistema operacional para seus dispositivos móveis.

A tabela a seguir mostra os drivers de classe de função que estão disponíveis nas edições móveis do Windows.

Observação

Os drivers de função não estão disponíveis no Windows 10 para edições desktop.

Drivers de classe de função USB Windows 10 Móvel Windows 10 para versões para desktop Observações
Respondente MTP (Media Transfer Protocol) Yes Não Não há cenários para o responder MTP no ambiente de trabalho. Cenários de comunicação P2P entre sistemas Desktop foram ativados via Easy-MigCable usando WinUSB.
Saída de exibição de vídeo (vidstream) Yes Não
Driver de função USB genérico (GenericUSBFn) Yes Não IPoverUSB e outros cenários de atualização de firmware no ambiente desktop precisam deste driver.

Monitoramos os dados de anexos de dispositivos para determinar se precisamos fornecer suporte adicional para drivers de classe conforme a lista de popularidade das classes de dispositivos é atualizada.

Implementação do driver

O driver Microsoft USB Role Switch (URS) permite que um implementador de sistema aproveite a capacidade USB de função dupla de sua plataforma.

O driver URS destina-se a fornecer funcionalidade de função dupla para plataformas que usam um único controlador USB que pode operar em funções de host e periférico em uma única porta. A função periférica também é conhecida como papel funcional. O driver URS gerencia a função atual da porta. O driver URS carrega e descarrega pilhas de software apropriadas, com base em eventos de hardware da plataforma.

Em um sistema que possui um conector USB micro-AB, o driver utiliza interrupções de hardware que indicam o estado do pino ID no conector. Este pino é usado para detetar se o controlador precisa assumir a função de host ou a função de dispositivo numa conexão. Para obter mais informações, consulte a especificação USB On-The-Go. Em sistemas com um conector USB Type-C, espera-se que o implementador OEM forneça um driver de cliente de conector usando as interfaces de programação de driver de conector USB Type-C. O driver do cliente comunica-se com a extensão de classe do Gerenciador de Conector USB (UcmCx) fornecida pela Microsoft, para gerir todos os aspetos do conector USB Type-C, como deteção de CC, mensagens de PD e outros. Para a troca de função, o driver do cliente comunica o estado do conector Type-C USB ao driver URS.

O diagrama a seguir mostra a pilha de drivers de software USB para um controlador de dupla função que usa o driver URS.

Arquitetura de pilha de driver para mudança de função USB.

O driver URS nunca carrega as pilhas de função e host mostradas no diagrama anterior simultaneamente. O driver URS carrega a pilha de funções ou a pilha de host, consoante a função do controlador USB.

Requisitos de hardware

Se você estiver desenvolvendo uma plataforma que aproveite o driver URS, para fornecer funcionalidade USB de função dupla, os seguintes requisitos de hardware devem ser atendidos:

  • Controlador USB

    Esses drivers são fornecidos pela Microsoft como drivers incluídos.

    Synopsys DesignWare Core USB 3.0 controlador. Caixa de entrada INF: UrsSynopsys.inf.

    Chipidea High-Speed Controlador OTG USB. Caixa de entrada INF: UrsChipidea.inf.

  • Interrupções do pino de identificação

    • Uma ou mais interrupções de pinos de identificação para sistemas Type-C não USB são implementadas de uma de duas maneiras:

      1. Duas interrupções acionadas por borda: uma que é acionada quando o pino de ID no conector é aterrado, e outra que é acionada quando o pino de ID está flutuando.
      2. Uma única interrupção ativa em ambos os estados que está no nível ativo quando o pino de ID está aterrado.
  • Enumeração do controlador USB

    O controlador USB de função dupla deve ser enumerado pelo ACPI.

  • Suporte de software

    O driver URS espera uma interface de software que permite o controle do VBus sobre o conector. Esta interface é específica do SoC. Entre em contato com seu fornecedor de SoC para obter mais detalhes.

Estas funcionalidades USB OTG não são suportadas no Windows:

  • Deteção de adaptador de carregador de acessórios (ACA).
  • Protocolo de solicitação de sessão (SRP).
  • Protocolo de Negociação de Host (HNP).
  • Anexar protocolo de deteção (ADP).

Configuração do sistema ACPI

Para usar o driver URS, você deve criar um arquivo de definição ACPI para o seu sistema. Além disso, há algumas considerações relacionadas com o driver que tem de ter em conta.

Aqui está um exemplo de definição ACPI para um controlador USB de função dupla.

//
// 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}
        })
    }
}

Aqui estão algumas explicações para as principais seções do arquivo ACPI:

  • URS0 é a definição ACPI para o controlador USB de função dupla. O driver URS é carregado neste dispositivo ACPI.

  • USB0 e UFN0 são dispositivos filhos dentro do escopo da URS0. USB0 e UFN0 representam as duas subpilhas enumeradas pelo driver URS, bem como as pilhas de anfitrião e de função, respetivamente. _ADR é o meio pelo qual ACPI faz a correspondência entre essas definições de dispositivo e os objetos de dispositivo criados pelo driver URS.

  • Se o controlador usar a mesma interrupção para ambas as funções, a mesma interrupção do controlador pode ser descrita em ambos os dispositivos filho. Mesmo nesse caso, a interrupção ainda pode ser descrita como "Exclusiva".

  • Você pode fazer adições a este arquivo de definição ACPI conforme necessário. Por exemplo, você pode definir quaisquer outros métodos ou propriedades necessárias em qualquer um dos dispositivos no arquivo de definição ACPI. Tais adições não interferem com o funcionamento do driver URS. Quaisquer outros recursos que são necessários em qualquer uma das pilhas também podem ser descritos no _CRS do dispositivo apropriado.

O driver URS atribui IDs de hardware ao host e às pilhas de funções. Essas IDs de hardware são derivadas da ID de hardware do dispositivo URS. Por exemplo, se você tiver um dispositivo URS cuja ID de hardware seja ACPI\ABCD1234, o driver URS criará IDs de hardware para o host e pilhas de funções da seguinte maneira:

  • Conjunto de hosts: URS\ABCD1234&HOST

  • Pilha de funções: URS\ABCD1234&FUNCTION

Pacotes de instalação do driver INF

Os pacotes de drivers 3rd-party podem depender deste esquema, se necessário.

Se você é um IHV ou um OEM e está pensando em fornecer seu próprio pacote de driver, aqui estão algumas coisas a considerar:

  • Pacote de driver URS

    O ID de hardware para o controlador de função dupla em cada plataforma é adicionado à caixa de entrada INF para URS. No entanto, se por algum motivo o ID não puder ser adicionado, o IHV/OEM pode fornecer um pacote de driver com um INF que necessita/inclui o INF na caixa de entrada e corresponde ao seu ID de hardware.

    Este pacote de controladores é necessário quando o IHV/OEM requer a presença de um controlador de filtro na pilha de controladores.

  • Pacote de driver do host

    É necessário um pacote de driver fornecido por IHV/OEM que Precisa/Inclui a caixa de entrada usbxhci.inf e corresponde ao ID de hardware do dispositivo host. A correspondência de ID de hardware seria baseada no esquema descrito na seção anterior.

    Este pacote de controladores é necessário quando o IHV/OEM requer que um controlador de filtro esteja presente na pilha de controladores.

    Há trabalho em andamento para fazer com que o driver URS atribua a ID compatível com XHCI para o dispositivo host.

  • Pacote de driver de função

    É necessário um pacote de driver fornecido por IHV/OEM que Precisa/Inclui a caixa de entrada Ufxsynopsys.inf e corresponde ao ID de hardware do dispositivo periférico. A correspondência de ID de hardware seria baseada no esquema descrito na seção anterior.

    O IHV/OEM também pode incluir um driver de filtro no pacote de driver.

Ver também