Como escolher um modelo de driver desenvolvendo um driver 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 passe para soluções mais complexas somente se for necessário. A lista a seguir resume as opções discutidas neste tópico:
- 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 precisará escrever um driver.
- 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.
- Se o dispositivo precisar ser acessado por aplicativos simultâneos e seu dispositivo não tiver pontos de extremidade isócronos, escreva um driver cliente baseado em UMDF.
- 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.
- Se um recurso específico não tiver suporte do KMDF, escreva um driver híbrido que chame rotinas WDM.
A abordagem mais comum tem sido implementar um driver de dispositivo (denominado como um 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. Em seguida, os aplicativos podem usar esse identificador de arquivo para se comunicar com o driver chamando APIs do Windows.
Escrever um driver personalizado de acordo com 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 do 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?
- Se você escrever um driver de cliente USB, qual modelo de driver é melhor?
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 com suporte da Microsoft.
Nesse caso, o driver de classe correspondente é carregado como o driver de 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 é compatível com endpoints em massa, de interrupção ou isócronos.
Seu dispositivo deve funcionar com um computador de destino que executa 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, o WinUSB é a abordagem preferencial para uma estação meteorológica eletrônica que é acessada apenas por um aplicativo empacotado com o dispositivo. Também é útil para comunicação de diagnóstico com um dispositivo e para atualizar o firmware.
Para facilitar o envio de solicitações para Winusb.sys aplicativos, fornecemos uma DLL no modo de usuário, Winusb.dll, que expõe as funções 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 é 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 (compatíveis com TAPI) ou funções de LAN (compatíveis com NDIS), você deve usar a interface compatível com o driver Usbser.sys para gerenciar dispositivos de modem com software de modo de usuário.
No Windows 8, adicionamos uma nova ID compatível ao INF para instalação do WinUSB. Se o firmware do dispositivo contiver essa ID compatível, o WinUSB será carregado por padrão como o driver de função do 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 (Estrutura de Driver de Modo de Usuário)
O UMDF fornece DDIs (interfaces de driver de dispositivo) que um driver cliente pode usar para integração com componentes do Windows, como o Plug and Play Manager 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 de depurador aprimoradas 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 suporta 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 do 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, travar o computador. Portanto, um driver de modo de usuário pode ser mais seguro do que um driver de 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 de modo kernel.
Um driver cliente baseado em UMDF não é uma opção para dispositivos USB que dão suporte a pontos de extremidade isócronos.
Observação 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. Você não pode 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 tornar os modelos de driver fáceis de estender para oferecer suporte a novos tipos de hardware. O KMDF fornece DDIs e estruturas de dados que tornam os drivers USB no modo kernel mais fáceis de implementar do que os drivers WDM (Windows Driver Model) anteriores. Além disso, o KMDF fornece destinos de E/S (entrada/saída) especializados que você pode usar para escrever um driver 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 de miniporta de porta. 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.
Os 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 modo de usuário USB e driver de modo kernel USB que geram código inicial para um driver de cliente USB UMDF e KMDF, respectivamente. O código do modelo inicializa um objeto de dispositivo de destino USB para permitir a comunicação com o hardware. Para Mais informações, consulte os seguintes 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 |
---|---|---|---|
Suporta vários aplicativos simultâneos | Não | Sim | Sim |
Isola o espaço de endereço do driver do espaço de endereço do aplicativo | Não | Sim | No |
Suporta transferências em massa, interrupção e controle | Sim | Sim | Sim |
Suporta transferências isócronas | Sim 4 | Não | Sim |
Suporta a instalação de drivers de modo kernel, como drivers de filtro, como uma camada subjacente na pilha USB | Não | No | Sim |
Suporta suspensão seletiva e o estado de espera/ativação | Sim | Sim | Sim |
A tabela a seguir resume as opções do WDF compatíveis com diferentes versões do Windows.
Versão do Windows | WinUSB | UMDF | KMDF |
---|---|---|---|
Windows 8 | Sim | Sim | Sim |
Windows 7 | Sim | Sim | Sim |
Windows Vista | Sim1 | Sim1 | Sim |
Windows Server 2003 | Não | No | Sim |
Windows XP | Sim2 | Sim2 | Sim |
Microsoft Windows 2000 | Não | No | Sim3 |
Sim 1: WinUSB e UMDF têm suporte apenas em versões baseadas em x86 e x64 do Windows.
Sim 2: WINUSB e UMDF são suportados no Windows XP com Service Pack 2 (SP2) ou versões posteriores do Windows.
Sim 3: o KMDF é compatível com o Windows 2000 com SP4 ou versões posteriores do Windows.
Sim 4: As transferências isócronas são suportadas no Windows 8.1 ou versões posteriores do Windows.
Todos os SKUs de cliente das versões de 32 bits do Windows XP com SP2 dão suporte ao WinUSB. O WinUSB não é nativo do Windows XP; ele deve ser instalado com o co-instalador WinUSB. Todos os SKUs do Windows Vista e versões posteriores do Windows dão suporte ao WinUSB.