Arquitetura de pilha de driver de função dupla USB
Os controladores de função dupla USB agora têm suporte no Windows, começando com edições do Windows 10 para desktop (Home, Pro, Enterprise e Education) e Windows 10 Mobile.
Introdução
O recurso de função dupla USB possibilita que um sistema seja um dispositivo USB ou host USB. A especificação detalhada para função dupla USB pode ser encontrada na página de informações USB on the Go da USB-IF.
O recurso de função dupla permite que um dispositivo móvel, como um telefone ou um tablet, se designe como um dispositivo ou um host.
Quando um dispositivo móvel está no modo de função, ele é conectado a um computador ou a algum outro dispositivo que atua como um 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 um 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 largura de banda de dados maior em comparação com protocolos sem fio como Bluetooth.
- A opção de carregamento da bateria por USB enquanto estiver conectado e se comunicando com outros dispositivos USB (desde que o suporte de hardware necessário esteja presente).
- Capacitar os clientes que provavelmente possuem 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, em que um dispositivo móvel encaixa e, portanto, hospeda dispositivos periféricos.
A tabela a seguir mostra a lista de drivers de classe de host disponíveis nas edições para área de trabalho e móvel do Windows.
| Drivers de classe de host USB | Windows 10 Mobile | Edições do Windows 10 para desktop |
|---|---|---|
| Hubs USB (USBHUB) | Sim | Sim (desde o Windows 2000) |
| HID - Teclado/Mouses (HidClass, KBDCLass, MouClass, KBDHid, MouHid) | Sim | Sim (desde o Windows 2000) |
| Armazenamento em massa USB (Em massa & UASP) | Sim | Sim (desde o Windows 2000) |
| Driver de host USB genérico (WinUSB) | Sim | Sim (desde o Windows Vista) |
| Entrada/saída de áudio USB (USBAUDIO) | Sim | Sim (desde o Windows XP) |
| Dispositivos seriais (USBSER) | Sim | Sim (desde o Windows 10) |
| Bluetooth (BTHUSB) | Sim | 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 de 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 Windows 10. Planejamos incluir um número limitado de drivers de host de terceiros para dar suporte aos principais dispositivos no Windows 10 Mobile. E para edições do Windows 10 para desktop, esses drivers estão disponíveis no site do OEM ou por meio do 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. O volume de disco da pilha de host USB + HID é mantido pequeno. É por isso que nem todos os drivers de classe e alguns drivers de terceiros estão incluídos na caixa de entrada do Windows 10 Mobile. Um OEM que deseja disponibilizar drivers de terceiros pode usar um BSP (Pacote de Suporte de Placa) 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 nas edições do Windows 10 para desktop.
| Drivers de classe de função USB | Windows 10 Mobile | Edições do Windows 10 para desktop | Observações |
|---|---|---|---|
| Respondente do Protocolo de transferência de mídia (MTP) | Sim | No | Não há cenários para o respondente de MTP na área de trabalho. Cenários P2P entre sistemas da área de trabalho foram habilitados via Easy-MigCable via WinUSB. |
| Exibição de saída de vídeo (fluxo de vídeo) | Sim | No | |
| Driver de função USB genérico (GenericUSBFn) | Sim | No | IPoverUSB e outros cenários de flash da área de trabalho precisam desse driver. |
Monitoramos os dados de anexo do dispositivo para nos informar se precisamos fornecer mais suporte ao driver de classe à medida que a lista de popularidade da classe do dispositivo é atualizada.
Implementação do driver
O driver URS (USB Role Switch) da Microsoft permite que um implementador do sistema aproveite o recurso 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 atribuição de função. 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 tem um conector micro-AB USB, o driver usa interrupções de hardware que indicam o estado do pino de ID no conector. Esse pino é usado para detectar se o controlador precisa assumir a função de host ou a função em uma conexão. Para obter mais informações, consulte a especificação On-The-Go do USB. Em sistemas com um conector USB do Tipo C, espera-se que o implementador OEM forneça um driver cliente de conector usando as interfaces de programação do driver do Conector USB do Tipo C. O driver cliente se comunica com a extensão de classe do Gerenciador de Conectores USB fornecida pela Microsoft (UcmCx) para gerenciar todos os aspectos do conector USB do Tipo C, como detecção de CC, mensagens PD e outros. Para alternância de função, o driver cliente comunica o estado do conector USB do tipo C ao driver URS.
O diagrama a seguir mostra a pilha de driver de software USB para um controlador de função dupla que usa o driver URS.
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, dependendo da função do controlador USB.
Requisitos de hardware
Se você estiver desenvolvendo uma plataforma que aproveita o driver URS para fornecer funcionalidade USB de função dupla, os seguintes requisitos de hardware deverão ser atendidos:
Controlador USB
Esses drivers são fornecidos pela Microsoft como drivers nativos.
Controlador Synopsys DesignWare Core USB 3.0. INF de Caixa de entrada: UrsSynopsys.inf.
Controlador USB OTG de alta velocidade Chipidea. INF de Caixa de entrada: UrsChipidea.inf.
Interrupções de pino de ID
Uma ou mais interrupções de pino de ID para sistemas não USB do Tipo C são implementadas de duas maneiras:
- Duas interrupções disparadas por borda: uma que é disparada quando o pino de ID no conector é aterrado e outra que é disparada quando o pino de ID está flutuando.
- Uma única interrupção active-both que está no nível ativo quando o pino de ID está aterrado.
Enumeração do controlador USB
O controlador de função dupla USB deve ser enumerado por ACPI.
Suporte do software
O driver URS espera uma interface de software que permita o controle do VBus pelo conector. Essa interface é específica do SoC. Entre em contato com o fornecedor do SoC para obter mais detalhes.
Não há suporte para esses recursos USB OTG no Windows:
- Detecção do ACA (Adaptador do Carregador Acessório).
- SRP (Protocolo de Solicitação de Sessão).
- HNP (Protocolo de Negociação de Host).
- ADP (Protocolo de Detecção de Anexo).
Configuração do sistema ACPI
Para usar o driver URS, você deve criar um arquivo de definição ACPI para seu sistema. Além disso, existem algumas considerações relacionadas ao driver que você deve levar em consideração.
Aqui está um exemplo de definição de ACPI para um controlador de função dupla USB.
//
// 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 seções principais do arquivo ACPI:
URS0 é a definição ACPI para o controlador de função dupla USB. O driver URS é carregado neste dispositivo ACPI.
USB0 e UFN0 são dispositivos filho dentro do escopo do URS0. USB0 e UFN0 representam as duas pilhas filho enumeradas pelo driver URS e as pilhas de host e função, respectivamente. _ADR é o meio pelo qual a ACPI corresponde a essas definições de dispositivo com os objetos de dispositivo que o driver URS cria.
Se o controlador usar a mesma interrupção para ambas as funções, a mesma interrupção do controlador poderá 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 esse arquivo de definição ACPI, conforme necessário. Por exemplo, você pode definir quaisquer outros métodos ou propriedades necessários em qualquer um dos dispositivos no arquivo de definição ACPI. Essas adições não interferem na operação do driver URS. Quaisquer outros recursos necessários em qualquer uma das pilhas também podem ser descritos no _CRS do dispositivo apropriado.
O driver URS atribui IDs de hardware às pilhas de host e função. 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 as pilhas de funções da seguinte maneira:
Pilha de host: URS\ABCD1234&HOST
Pilha de funções: URS\ABCD1234&FUNCTION
Pacotes de instalação do driver INF
Pacotes de driver de terceiros podem ter uma dependência desse esquema, se necessário.
Se você for um IHV ou um OEM e estiver pensando em fornecer seu próprio pacote de driver, aqui estão alguns itens a serem considerados:
Pacote de drivers URS
A ID de hardware para o controlador de função dupla em cada plataforma é adicionada à INF da caixa de entrada para URS. No entanto, se, por algum motivo, a ID não puder ser adicionada, o IHV/OEM poderá fornecer um pacote de driver com um INF que precisa/inclui o INF da caixa de entrada e corresponde à ID de hardware.
Esse pacote de driver é necessário quando o IHV/OEM exige que um driver de filtro esteja presente na pilha de driver.
Pacote de drivers de host
É necessário um pacote de driver fornecido por IHV/OEM que precisa/inclui a caixa de entrada usbxhci.inf e corresponde à ID de hardware do dispositivo host. A correspondência de ID de hardware seria baseada no esquema descrito na seção anterior.
Esse pacote de driver é necessário quando o IHV/OEM exige que um driver de filtro esteja presente na pilha de driver.
Há um 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 à 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.