Escolher um modelo de driver para desenvolver um driver de cliente USB

Este tópico fornece diretrizes para escolher o melhor modelo de driver para desenvolver um driver cliente USB que atua como o driver de função do dispositivo.

Os fabricantes de dispositivos USB geralmente devem fornecer uma maneira de os aplicativos acessarem os recursos do dispositivo. Para escolher o melhor mecanismo para acessar um dispositivo USB, comece com a abordagem mais simples e vá para soluções mais complexas somente se necessário. A lista a seguir resume as opções discutidas neste tópico:

  1. Se o dispositivo pertencer a uma classe de dispositivo USB para a qual o Windows inclui um driver de caixa de entrada, você não precisa escrever um driver.
  2. Se o dispositivo não tiver um driver de classe fornecido pela Microsoft e o dispositivo for acessado por um único aplicativo, carregue o WinUSB como o driver de função.
  3. Se o dispositivo precisar ser acessado por aplicativos simultâneos e seu dispositivo não tiver pontos de extremidade isócronos, escreva um driver de cliente baseado em UMDF.
  4. Se as soluções de driver de classe, WinUSB ou UMDF não forem opções que funcionem para você, escreva um driver cliente baseado em KMDF.
  5. Se um recurso específico não tiver suporte do KMDF, escreva um driver híbrido que chame rotinas do WDM.

A abordagem mais comum foi implementar um driver de dispositivo (chamado de driver de cliente USB neste conjunto de documentação) e fornecer um pacote de instalação que instala o driver como o driver de função na pilha de dispositivos acima da pilha de driver USB fornecida pela Microsoft. O driver cliente expõe uma interface de dispositivo que os aplicativos podem usar para obter o identificador de arquivo do dispositivo. Os aplicativos podem usar esse identificador de arquivo para se comunicar com o driver chamando APIs do Windows.

Escrever um driver personalizado para os requisitos do dispositivo é a maneira mais flexível de fornecer acesso a um dispositivo USB. No entanto, implementar um driver requer muito trabalho. O driver deve executar tarefas complexas, como inicialização de driver quando novos dispositivos são detectados, gerenciamento de energia, operações de E/S, remoção surpresa, gerenciamento de estado e limpeza quando o dispositivo é removido. Antes de optar por escrever um driver, faça as seguintes perguntas:

Você pode usar um driver fornecido pela Microsoft?

Talvez você não precise escrever um driver se:

  • Seu dispositivo pertence a uma classe de dispositivo USB compatível com a Microsoft.

    Nesse caso, o driver de classe correspondente é carregado como o driver do dispositivo. Para obter uma lista de classes de dispositivo para as quais o Windows inclui um driver de caixa de entrada, consulte Drivers de classe de dispositivo USB incluídos no Windows.

  • Seu dispositivo não pertence a uma classe de dispositivo.

    Para esses dispositivos, avalie os recursos do dispositivo para determinar se você pode carregar o WinUSB (Winusb.sys) fornecido pela Microsoft como o driver de função do dispositivo. Usar o WinUSB é a melhor solução se:

    • Seu dispositivo é acessado por um único aplicativo.

    • Seu dispositivo dá suporte a pontos de extremidade em massa, de interrupção ou isócronos.

    • Seu dispositivo destina-se a trabalhar com um computador de destino executando o Windows XP com Service Pack 2 (SP2) e versões posteriores do Windows.

      Carregar o WinUSB como o driver de função fornece uma alternativa mais simples para implementar um driver USB personalizado. Por exemplo, WinUSB é a abordagem preferencial para uma estação meteorológica eletrônica que é acessada apenas por um aplicativo que é empacotado com o dispositivo. Também é útil para comunicação de diagnóstico com um dispositivo e para firmware flash.

      Para facilitar o envio de solicitações para aplicativos para Winusb.sys, fornecemos uma DLL no modo de usuário, Winusb.dll, que expõe as funções do WinUSB. Um aplicativo pode chamar essas funções para acessar o dispositivo, configurá-lo e transferir dados para os pontos de extremidade do dispositivo.

      O WinUSB não será uma opção se:

    • Seu dispositivo é acessado por vários aplicativos.

    • Seu dispositivo tem funções que já têm suporte ao modo kernel no sistema operacional Windows. Por exemplo, para funções de modem (às quais o TAPI dá suporte) ou funções LAN (às quais o NDIS dá suporte), você deve usar a interface à qual o driver de Usbser.sys dá suporte para gerenciar dispositivos modem com software de modo de usuário.

      Em Windows 8, adicionamos uma nova ID compatível à instalação do INF para WinUSB. Se o firmware do dispositivo contiver essa ID compatível, o WinUSB será carregado por padrão como o driver de função para o dispositivo. Isso significa que os fabricantes de hardware não são obrigados a distribuir arquivos INF para seus dispositivos WinUSB. Para obter mais informações, consulte Dispositivo WinUSB.

Se você escrever um driver de cliente USB, qual modelo de driver é melhor?

A resposta depende do design do seu dispositivo. Primeiro, determine se um modelo de driver específico atende aos seus requisitos. Algumas considerações de design são baseadas em se você deseja que o dispositivo USB seja acessado por vários aplicativos simultâneos e dê suporte ao streaming de dados por meio de pontos de extremidade isócronos.

Se você optar por escrever um driver, aqui estão suas opções:

  • UMDF (User-Mode Driver Framework )

    O UMDF fornece DDIs (interfaces de driver de dispositivo) que um driver de cliente pode usar para integrar com componentes do Windows, como o Gerenciador de Plug and Play e o Power Manager. O UMDF também fornece objetos de destino especializados para dispositivos USB, que abstraem o hardware no modo de usuário e simplificam as operações de E/S para o driver. Além das interfaces UMDF, o WDF fornece extensões avançadas do depurador e ferramentas de rastreamento para drivers de modo de usuário. O UMDF é baseado no COM (modelo de objeto de componente) e o desenvolvimento de um driver de modo de usuário é mais fácil para um desenvolvedor C++.

    Implemente um driver cliente baseado em UMDF para um dispositivo USB nos seguintes casos:

    • O dispositivo é acessado simultaneamente por vários aplicativos.

    • O dispositivo dá suporte a transferências em massa ou de interrupção.

      Os drivers executados no modo de usuário podem acessar apenas o espaço de endereço do usuário (virtual) e representam um risco muito menor para o sistema. Os drivers no modo kernel podem acessar o espaço de endereço do sistema e as estruturas internas do sistema. Um driver de modo kernel mal codificado pode causar problemas que afetam outros drivers ou o sistema e, eventualmente, travam o computador. Portanto, um driver de modo de usuário pode ser mais seguro do que um driver no modo kernel em termos de segurança e estabilidade.

      Outra vantagem dos drivers de modo de usuário é que eles aproveitam todas as APIs do Win32. Por exemplo, os drivers podem chamar APIs como Winsock, Compactação, APIs de criptografia e assim por diante. Essas APIs não estão disponíveis para drivers no modo kernel.

      Um driver de cliente baseado em UMDF não é uma opção para dispositivos USB que dão suporte a pontos de extremidade isócronos.

      Observação Windows 8.1 apresenta a versão 2.0 do UMDF. Com o UMDF versão 2.0, você pode escrever um driver UMDF na linguagem de programação C que chama muitos dos métodos disponíveis para drivers KMDF. Não é possível usar o UMDF versão 2.0 para gravar drivers de filtro inferiores para USB.

  • KMDF (Kernel-Mode Driver Framework )

    O KMDF foi projetado para facilitar a extensão dos modelos de driver para dar suporte a novos tipos de hardware. O KMDF fornece DDIs e estruturas de dados que facilitam a implementação de drivers USB no modo kernel do que os drivers anteriores do WDM (Modelo de Driver do Windows). Além disso, o KMDF fornece destinos de E/S (entrada/saída) especializados que você pode usar para escrever um driver de cliente totalmente funcional que usa a pilha de driver USB da Microsoft.

    Em determinados casos em que um recurso específico não é exposto por meio do KMDF, o driver deve chamar rotinas WDM. O driver não precisa implementar toda a infraestrutura do WDM, mas usa métodos KMDF para acessar um conjunto selecionado de rotinas do WDM. Por exemplo, para executar transferências isócronas, um driver cliente baseado em KMDF pode enviar URBs no estilo WDM que descrevem a solicitação para a pilha de driver USB. Esses drivers são chamados de drivers híbridos neste conjunto de documentação.

    O KMDF também dá suporte ao modelo de driver port-miniport. Por exemplo, um driver de miniporto de streaming de kernel (como uma webcam USB) que usa streaming de kernel na borda superior pode usar objetos de destino de E/S USB KMDF para enviar solicitações para a pilha de driver USB. Os drivers NDIS também podem ser gravados usando KMDF para barramentos baseados em protocolo, como USB.

    Drivers WDM puros são difíceis de escrever, complexos e não robustos. Com a evolução do KMDF, não é mais necessário escrever esse tipo de driver.

O Microsoft Visual Studio 2012 inclui modelos de Driver de User-Mode USB e driver de Kernel-Mode USB que geram código inicial para um driver de cliente USB UMDF e KMDF, respectivamente. O código de modelo inicializa um objeto de dispositivo de destino USB para habilitar a comunicação com o hardware. Para obter mais informações, consulte estes tópicos:

Para obter informações sobre como implementar drivers UMDF e KMDF, consulte o livro da Microsoft Press Desenvolvendo drivers com o Windows Driver Foundation.

Comparação de recursos winusb, UMDF, KMDF

A tabela a seguir resume os recursos do WinUSB, drivers USB baseados em UMDF e drivers USB baseados em KMDF.

Recurso WinUSB UMDF KMDF
Dá suporte a vários aplicativos simultâneos No Yes Yes
Isola o espaço de endereço do driver do espaço de endereço do aplicativo No Yes No
Dá suporte a transferências em massa, interrupção e controle Yes Yes Yes
Dá suporte a transferências isócronas Sim 4 Não Yes
Dá suporte à instalação de drivers no modo kernel, como drivers de filtro, como uma camada excessiva na pilha USB No No Yes
Dá suporte à suspensão seletiva e ao estado de espera/ativação Yes Yes Yes

A tabela a seguir resume as opções do WDF compatíveis com versões diferentes do Windows.

Versão do Windows WinUSB UMDF KMDF
Windows 8 Sim Yes Yes
Windows 7 Sim Yes Sim
Windows Vista Sim1 Sim1 Sim
Windows Server 2003 No No Sim
Windows XP Sim2 Sim2 Sim
Microsoft Windows 2000 No Não Sim3

Sim1: o WinUSB e o UMDF têm suporte apenas em versões baseadas em x86 e x64 do Windows.

Sim2: HÁ suporte para WINUSB e UMDF no Windows XP com Service Pack 2 (SP2) ou versões posteriores do Windows.

Sim3: há suporte para KMDF no Windows 2000 com SP4 ou versões posteriores do Windows.

Sim4: há suporte para transferências isócronas em Windows 8.1 ou versões posteriores do Windows.

Todos os SKUs de cliente das versões de 32 bits do Windows XP com SP2support WinUSB. O WinUSB não é nativo do Windows XP; ele deve ser instalado com o co-instalador do WinUSB. Todos os SKUs do Windows Vista e versões posteriores do Windows dão suporte ao WinUSB.