Elección de un modelo de controlador para desarrollar un controlador de cliente USB
En este tema se proporcionan instrucciones para elegir el mejor modelo de controlador para desarrollar un controlador cliente USB que actúa como controlador de funciones del dispositivo.
Los fabricantes de dispositivos USB a menudo deben proporcionar una manera de que las aplicaciones accedan a las características del dispositivo. Para elegir el mejor mecanismo para acceder a un dispositivo USB, comience con el enfoque más sencillo y pase a soluciones más complejas solo si es necesario. En la lista siguiente se resumen las opciones descritas en este tema:
- Si el dispositivo pertenece a una clase de dispositivo USB para la que Windows incluye un controlador de bandeja de entrada, no es necesario escribir un controlador.
- Si el dispositivo no tiene un controlador de clase proporcionado por Microsoft y se accede al dispositivo mediante una sola aplicación, cargue WinUSB como controlador de función.
- Si las aplicaciones simultáneas deben acceder al dispositivo y el dispositivo no tiene puntos de conexión isócronos, escriba un controlador de cliente basado en UMDF.
- Si el controlador de clase, WinUSB o las soluciones umDF no son opciones que funcionan automáticamente, escriba un controlador de cliente basado en KMDF.
- Si kmDF no admite una característica determinada, escriba un controlador híbrido que llame a rutinas de WDM.
El enfoque más común ha sido implementar un controlador de dispositivo (denominado controlador de cliente USB en este conjunto de documentación) y proporcionar un paquete de instalación que instale el controlador como controlador de función en la pila de dispositivos encima de la pila de controladores USB proporcionados por Microsoft. El controlador cliente expone una interfaz de dispositivo que las aplicaciones pueden usar para obtener el identificador de archivo del dispositivo. Después, las aplicaciones pueden usar este identificador de archivo para comunicarse con el controlador llamando a las API de Windows.
Escribir un controlador personalizado para los requisitos del dispositivo es la manera más flexible de proporcionar acceso a un dispositivo USB. Sin embargo, la implementación de un controlador requiere mucho trabajo. El controlador debe realizar tareas complejas, como la inicialización del controlador cuando se detectan nuevos dispositivos, la administración de energía, las operaciones de E/S, la eliminación de sorpresas, la administración de estado y la limpieza cuando se quita el dispositivo. Antes de elegir escribir un controlador, haga las siguientes preguntas:
- ¿Puede usar un controlador proporcionado por Microsoft?
- Si escribe un controlador de cliente USB, ¿qué modelo de controlador es mejor?
¿Puede usar un controlador proporcionado por Microsoft?
Es posible que no necesite escribir un controlador si:
El dispositivo pertenece a una clase de dispositivo USB compatible con Microsoft.
En ese caso, el controlador de clase correspondiente se carga como controlador de dispositivo. Para obtener una lista de las clases de dispositivo para las que Windows incluye un controlador de bandeja de entrada, consulte Controladores de clase de dispositivo USB incluidos en Windows.
El dispositivo no pertenece a una clase de dispositivo.
Para estos dispositivos, evalúe las características del dispositivo para determinar si puede cargar WinUSB (Winusb.sys) proporcionado por Microsoft como controlador de funciones del dispositivo. El uso de WinUSB es la mejor solución si:
Una sola aplicación accede al dispositivo.
El dispositivo admite puntos de conexión masivos, de interrupción o isócronos.
El dispositivo está pensado para trabajar con un equipo de destino que ejecute Windows XP con Service Pack 2 (SP2) y versiones posteriores de Windows.
Cargar WinUSB como controlador de funciones proporciona una alternativa más sencilla a la implementación de un controlador USB personalizado. Por ejemplo, WinUSB es el enfoque preferido para una estación meteorológica electrónica a la que solo accede una aplicación empaquetada con el dispositivo. También es útil para la comunicación de diagnóstico con un dispositivo y para el firmware parpadeante.
Para facilitar que las aplicaciones envíen solicitudes a Winusb.sys, proporcionamos un archivo DLL en modo de usuario, Winusb.dll, que expone las funciones de WinUSB. Una aplicación puede llamar a esas funciones para acceder al dispositivo, configurarla y transferir datos a los puntos de conexión del dispositivo.
WinUSB no es una opción si:
Varias aplicaciones acceden al dispositivo.
El dispositivo tiene funciones que ya tienen compatibilidad con el modo kernel en el sistema operativo Windows. Por ejemplo, para funciones de módem (que TAPI admite) o funciones LAN (que admite NDIS), debe usar la interfaz que admite el controlador Usbser.sys para administrar dispositivos módems con software en modo de usuario.
En Windows 8, hemos agregado un nuevo identificador compatible a la instalación de INF para WinUSB. Si el firmware del dispositivo contiene ese identificador compatible, WinUSB se carga de forma predeterminada como controlador de función para el dispositivo. Esto significa que los fabricantes de hardware no son necesarios para distribuir archivos INF para sus dispositivos WinUSB. Para obtener más información, consulte Dispositivo WinUSB.
Si escribe un controlador de cliente USB, ¿qué modelo de controlador es mejor?
La respuesta depende del diseño del dispositivo. En primer lugar, determine si un modelo de controlador determinado cumple sus requisitos. Algunas consideraciones de diseño se basan en si quiere que varias aplicaciones simultáneas accedan al dispositivo USB y admitan el streaming de datos a través de puntos de conexión isócronos.
Si decide escribir un controlador, estas son sus opciones:
Marco de controlador en modo de usuario (UMDF)
UMDF proporciona interfaces de controlador de dispositivo (DDIs) que un controlador cliente puede usar para integrarse con componentes de Windows, como Plug and Play Manager y Power Manager. UMDF también proporciona objetos de destino especializados para dispositivos USB, que abstraen el hardware en modo de usuario y simplifican las operaciones de E/S para el controlador. Además de las interfaces de UMDF, WDF proporciona extensiones de depurador mejoradas y herramientas de seguimiento para controladores en modo de usuario. UMDF se basa en el modelo de objetos componentes (COM) y el desarrollo de un controlador en modo de usuario es más fácil para un desarrollador de C++.
Implemente un controlador de cliente basado en UMDF para un dispositivo USB en los casos siguientes:
Varias aplicaciones acceden al dispositivo simultáneamente.
El dispositivo admite transferencias masivas o de interrupción.
Los controladores que se ejecutan en modo de usuario solo pueden acceder al espacio de direcciones del usuario (virtual) y suponer un riesgo mucho menor para el sistema. Los controladores en modo kernel pueden acceder al espacio de direcciones del sistema y a las estructuras del sistema internas. Un controlador en modo kernel mal codificado podría causar problemas que afectan a otros controladores o al sistema y, finalmente, bloquear el equipo. Por lo tanto, un controlador en modo de usuario puede ser más seguro que un controlador en modo kernel en términos de seguridad y estabilidad.
Otra ventaja de los controladores en modo de usuario es que aprovechan todas las API de Win32. Por ejemplo, los controladores pueden llamar a api como Winsock, Compression, Encryption API, etc. Esas API no están disponibles para los controladores en modo kernel.
Un controlador de cliente basado en UMDF no es una opción para los dispositivos USB que admiten puntos de conexión isócronos.
Nota Windows 8.1 presenta la versión 2.0 de UMDF. Con la versión 2.0 de UMDF, puede escribir un controlador UMDF en el lenguaje de programación C que llama a muchos de los métodos que están disponibles para los controladores KMDF. No puede usar UMDF versión 2.0 para escribir controladores de filtro inferiores para USB.
Marco de controlador en modo kernel (KMDF)
KMDF se diseñó para facilitar la extensión de los modelos de controladores para admitir nuevos tipos de hardware. KMDF proporciona DDIs y estructuras de datos que facilitan la implementación de controladores USB en modo kernel que los controladores anteriores de Windows Driver Model (WDM). Además, KMDF proporciona destinos especializados de entrada y salida (E/S) que puede usar para escribir un controlador de cliente totalmente funcional que use la pila de controladores USB de Microsoft.
En determinados casos en los que una característica determinada no se expone a través de KMDF, el controlador debe llamar a rutinas de WDM. El controlador no necesita implementar toda la infraestructura de WDM, pero usa métodos KMDF para acceder a un conjunto select de rutinas de WDM. Por ejemplo, para realizar transferencias isócrónicas, un controlador de cliente basado en KMDF puede enviar direcciones URL de estilo WDM que describen la solicitud a la pila del controlador USB. Estos controladores se denominan controladores híbridos en este conjunto de documentación.
KMDF también admite el modelo de controlador port-miniport. Por ejemplo, un controlador de miniporte de streaming de kernel (como una cámara web USB) que usa el streaming de kernel en el borde superior puede usar objetos de destino de E/S USB kmDF para enviar solicitudes a la pila del controlador USB. Los controladores NDIS también se pueden escribir mediante KMDF para buses basados en protocolos, como USB.
Los controladores WDM puros son difíciles de escribir, complejos y no sólidos. Con la evolución de KMDF, ya no es necesario escribir este tipo de controlador.
Microsoft Visual Studio 2012 incluye plantillas de controlador del modo de usuario USB y controlador del modo kernel USB que generan código de inicio para un controlador de cliente USB UMDF y KMDF, respectivamente. El código de plantilla inicializa un objeto de dispositivo de destino USB para habilitar la comunicación con el hardware. Para obtener más información, consulte los temas siguientes:
- Escribir el primer controlador de cliente USB (UMDF)
- Escribir el primer controlador de cliente USB (KMDF)
Para obtener información sobre cómo implementar controladores UMDF y KMDF, consulte el libro de Microsoft Press Developing Drivers with the Windows Driver Foundation.
Comparación de características de WinUSB, UMDF, KMDF
En la tabla siguiente se resumen las funcionalidades de los controladores USB basados en WINUSB, UMDF y los controladores USB basados en KMDF.
| Característica | WinUSB | UMDF | KMDF |
|---|---|---|---|
| Admite varias aplicaciones simultáneas | No | Sí | Sí |
| Aísla el espacio de direcciones del controlador del espacio de direcciones de la aplicación. | No | Sí | No |
| Admite transferencias masivas, de interrupción y de control | Sí | Sí | Sí |
| Admite transferencias isócrónicas | Sí 4 | No | Sí |
| Admite la instalación de controladores en modo kernel, como los controladores de filtro, como una capa excesiva en la pila USB. | No | No | Sí |
| Admite la suspensión selectiva y el estado de espera/reactivación. | Sí | Sí | Sí |
En la tabla siguiente se resumen las opciones de WDF compatibles con distintas versiones de Windows.
| Versión de Windows | WinUSB | UMDF | KMDF |
|---|---|---|---|
| Windows 8 | Sí | Sí | Sí |
| Windows 7 | Sí | Sí | Sí |
| Windows Vista | Sí1 | Sí1 | Sí |
| Windows Server 2003 | No | No | Sí |
| Windows XP | Sí2 | Sí2 | Sí |
| Microsoft Windows 2000 | No | No | Sí3 |
Sí1: WinUSB y UMDF solo se admiten en versiones basadas en x86 y x64 de Windows.
Sí 2: WINUSB y UMDF se admiten en Windows XP con Service Pack 2 (SP2) o versiones posterioresde Windows.
Sí 3: KMDF se admite en Windows 2000 con SP4 o versiones posterioresde Windows.
Sí 4: Las transferencias isocronas se admiten en Windows 8.1 o versiones posterioresde Windows.
Todas las SKU de cliente de las versiones de 32 bits de Windows XP con SP2support WinUSB. WinUSB no es nativo de Windows XP; debe instalarse con el co-instalador de WinUSB. Todas las SKU de Windows Vista y versiones posteriores de Windows admiten WinUSB.