2012-01-30 14 views
6

Me pregunto si alguien puede ayudar en absoluto, un poco un problema especial esto.Reemplace Windows USB Class Driver con un controlador personalizado?

Tengo una aplicación que necesita para leer y analizar una serie de dispositivos USB (no simultáneamente, cada uno se ejecuta en pruebas separadas y en teoría podría ejecutarse en diferentes máquinas).

Cada uno de los dispositivos USB se basa en la clase USB HID, y son fabricados por diferentes compañías, ninguno de estos dispositivos USB está diseñado para ejecutarse en PC, pero están diseñados para una plataforma diferente, pero a los fines de: probando los dispositivos que el cliente ha solicitado que la aplicación de prueba se ejecute desde una PC.

Algunos de los dispositivos se iniciarán, serán reconocidos por Windows que inicializarán e iniciarán correctamente utilizando el controlador de clase HID genérico integrado en Windows, los dispositivos comenzarán a enviar los paquetes de datos correctos de los datos que se probarán.

Algunos de los dispositivos se iniciarán, serán reconocidos por Windows que intentarán iniciarlos pero no los inicializarán completamente, dejándolos en un estado medio inicializado. Esto está bien, ya que puedo usar mi analizador de protocolo beagle para capturar los paquetes de inicialización de la plataforma original y luego usar la biblioteca LibUSBDotNet para replicar los paquetes restantes en la secuencia de inicialización y hacer que comiencen a enviar los paquetes correctamente.

El problema que tengo es con un dispositivo en particular (aunque hay algunos más que aún no he probado, por lo que es muy posible que uno de ellos también muestre el mismo problema). El problema es que el controlador de clase de Windows HID reconoce el dispositivo y trata de inicializarlo e iniciarlo, esto funciona después de una moda y el dispositivo comienza a enviar datos.

El problema es que los datos que se envían son diferentes a los que se envían a la plataforma original (que contiene solo un subconjunto de los datos completos). Es como si Windows hubiera inicializado el dispositivo en un modo diferente.

Cuando capturo los paquetes de inicialización desde la PC y la plataforma original utilizando mi analizador de protocolo USB veo que Windows está enviando algunos paquetes de inicialización ligeramente diferentes. Usando LibUSBDotNet para reenviar los paquetes correctos una vez que Windows ya ha comenzado, el dispositivo parece no tener ningún efecto.

Mi problema es que tengo que evitar que Windows intente inicializar el dispositivo utilizando el controlador de clase HID estándar, he intentado eliminar el controlador en el Administrador de dispositivos pero aún lo inicializa (y el controlador se reasigna mágicamente en el dispositivo gerente). He hecho un poco de investigación y hay alternativas posibles:

  1. crear un controlador específico que Windows le asignará a la VID en particular/PID del dispositivo, pero que no hace nada, entonces puedo usar para enviar el LibUSBDotNet correcta secuencia de inicialización al dispositivo desde mi propio código.

  2. usar algo como WinUSB para crear un controlador adecuado para el dispositivo (o, posiblemente, para crear un controlador "muerto" como 1.

¿Un conductor con un VID específica/PID Definido ser utilizado por Windows es preferible a su controlador de clase HID USB incorporado? De lo contrario, estaría perdiendo el tiempo yendo por esta ruta?

Nota, mi mac inicializa correctamente el dispositivo problemático, y le he preguntado al cliente si la aplicación se puede desarrollar para Mac y su respuesta fue frustrante solo para Windows.

No tengo experiencia en escribir controladores adecuados para Windows, aunque tengo experiencia en hablar con USB a un nivel relativamente bajo (por lo que esa parte no se preocupa demasiado). ¿Alguien puede sugerir un buen curso de acción (antes de perder potencialmente semanas investigando cómo escribir controladores para la PC solo para encontrar que mi curso de acción seleccionado no puede ofrecer lo que requiero).

Cualquier ayuda o sugerencia muy apreciada.

Gracias, ricos


Agregado después de probar las sugerencias a continuación:

He intentado utilizar el asistente inf LibUsbDotNet para crear los archivos necesarios y los instala y esto pareció funcionar - sin duda el dispositivo era ahora aparece en el Administrador de Dispositivos como un dispositivo libusb-win32, no como dispositivo HID y el controlador asociado era el controlador libusb. Incluso después de hacer esto, el dispositivo aún parece inicializarse y comenzar a enviar el tipo incorrecto de paquetes de datos, aunque ahora esos paquetes ya no son manejados por el controlador de clase y simplemente se pierden.

También me encontré con Zadig que tiene un asistente de creación de inf similar para WinUSB y esto tuvo exactamente el mismo resultado.

Un colega ha sugerido que podría no ser Windows el que está cambiando el dispositivo a este modo, sino el dispositivo que identifica que está conectado a una máquina de Windows y se cambia a este modo. Sospecho que este es el caso, en cuyo caso estoy atascado, es hora de tener otra conversación con el cliente.

Muchas gracias por la ayuda.

+1

¿Puede hacer que esta pregunta sea más concisa? Dudo que mucha gente lea todo eso. –

Respuesta

4

Está utilizando libusb-win32 como un controlador de filtro; es decir, el controlador del dispositivo HidUsb se asigna y se carga para su dispositivo, pero luego el controlador libusb-win32 se carga en la parte superior y le da acceso sin obstáculos al hardware.

Si no desea que un HidUsb (o cualquier otro controlador de clase) realice ninguna comunicación "en su nombre", simplemente asocie libusb-win32 como un controlador de dispositivo con su hardware. Para esto, tendrías que crear un archivo .INF asociándolo con el VID/PID/Revisión de cada dispositivo USB. Si recuerdo correctamente, libusb-win32 incluso viene con una utilidad para generar dichos archivos .INF.

Si instala este archivo .INF, p. con PnpUtil.exe (disponible en Vista o superior), es posible que aún tenga problemas en los que, aunque sea una mejor coincidencia que el controlador HID genérico, el controlador HID aún esté seleccionado.

El controlador HID genérico hace coincidir los dispositivos con sus ID compatibles (es decir, mediante una clase de interfaz USB) mientras que los identificadores de hardware (que tienen mayor prioridad) coinciden. Sin embargo, Windows puede dar prioridad a otros aspectos, como que su controlador no esté firmado. Leer: How Windows Selects Drivers

Afortunadamente, incluso en ese escenario, la firma de los conductores con un certificado autogenerado (use CertUtil.exe, MakeCat.exe y SignTool.exe) no es demasiado difícil.

+0

Gracias, hay mucha información realmente útil allí. Sí, estoy usando un filtro que he instalado a través de LibUSBDotNet. Intentaré como sugieres e instales a través de un archivo inf. Investigo todas tus sugerencias y te cuento cómo me llevo. –

+0

Vea el comentario agregado anterior, su solución funciona porque evita que el controlador de la clase se cargue y detiene el procesamiento posterior por parte del controlador de la clase, desafortunadamente el mínimo necesario que requiere Windows para identificar el dispositivo y cargar el controlador alternativo es suficiente para desencadenar el problema . Gracias por la ayuda, ha sido un ejercicio muy útil para aprender sobre los controladores de dispositivos, etc. –

+0

En un dispositivo simple, Windows solo hace un banal "obtener el descriptor del dispositivo" y "obtener el descriptor de configuración". Si se trata de un dispositivo compuesto, se adquirirán algunos más descriptores. En ningún caso, Windows lee/escribe en los puntos finales ni realiza extrañas solicitudes de control en esta etapa. Cuando dice "controlador alternativo", ¿se carga realmente un controlador alternativo para el dispositivo y, de ser así, qué controlador es? – Ilya

Cuestiones relacionadas