Desesperación desarrollando driver
Publicado por HySTD (1 intervención) el 21/06/2008 19:13:09
Hola buenas! Estoy desarrollando (con fines didácticos) un driver para Windows XP de una Webcam por USB Creative. El controlador de la camara es el 0V511+ (de Omnivision). El datasheet está bastante bien, pero falta alguna que otra información.
Me encuentro desarrollandolo con las DDK y Driver Studio 2.7. El problema que tengo es que usa dos endpoints, uno es el de control (endpoint 0) de entrada salida (con lo cual tenemos dos direcciones 0x80 y 0x00), y el otro es Isócrono de entrada (endpoint 1), para la transferencia de video. Hasta ahí bien.
Viendo el datasheet, se observa que utiliza una compresión hardware del fabricante en el módulo OmniCE. Asi que decidí, dejarlo por el momento y hacer pruebas más sencillas de comunicación. Una de ellas consiste en eneceder y apagar el diodo LED que tiene. Dicho diodo es accesible mediante el registro 55h de la cámara. El problema que tengo es acceder a dicho registro.
Está claro que si usa el endpoint 0 para las transferencias de control, entonces el objeto a utilizar es de tipo KUsbLowerDevice, y su método BuildVendorRequest. Pero para ello debo saber los valores de algunos parámetros, por ejemplo Request y Value. Decidí para ello, usar un sniffer para USB, con los drivers originales de la cámara. Viendo el tráfico a través del USBD, observo el contenido de los paquetes URB. Se puede observar que los valores Request y Value permanecen constantes para cualquier tipo de petición y que lo único que varía es el parámetro Index (1 byte), cuyo contenido siempre oscila entre 10 y BF que son curiosamente el mapa de memoria de los registros, con lo cual, la hipótesis que tengo es que Index contiene la dirección del registro a acceder.
Haciendo cientos de pruebas, no conseguí nada, solo un montón pantallazos azules de volcado de memoria...
Otro detalle importante que aparece en el datasheet es que dice que la cámara entra en modo suspensión si pasados 3 milisegundos no se tranfiere ninguna información. Con lo cual he podido deducir que no puedo acceder bien al registro porque ya está en ese modo (como un standby). Pero el fabricante no facilita información al respecto sobre cómo "despertarla".
Tengo muchas dudas, y no sé si estoy realizando correctamente el procedimiento:
En el método Write (KIrp I) {...} lo que hago es lo siguiente:
PURB miurb; //Declaro una variable que apuntará a la estructura URB a mandar al USBD
miurb=m_Lower.BuildVendorRequest(pBuffer, dwTotalSize, 0x00, 0x00, 0x02, false, false, NULL, 0x55, URB_FUNCTION_VENDOR_DEVICE, NULL); //Construimos el URB a partir del IRP que llegue de la aplicación (pBuffer), y usamos los valores Request y Value que observé en el Sniffer, 0x02 para datos de salida, y 0x03 para datos de entrada. Por último 0x55 es Index, la dirección del registro a acceder.
m_Lower.SubmitUrb(mirub, NULL, NULL, 0); //Enviamos el URB al USBD.
Haciendo ésto aparece un pantallazo azul... ¿qué está fallando?
Buscando en "Google code search", he observado drivers para Linux para el controlador 0V511+. El problema es que según esos drivers, los parámetros se pasan en Request y Value (lo que en el sniffer era constante), y además no hace nada extraño... usa las funciones de la API del kernel "usb_control_msg" y "usb_sndctrlpipe", en esta última, especificando el endpoint 0. Lo que su homólogo equivale a BuildVendorRequest para las DDK.
Aquí les dejo la información del chip 0V511+: http://mxhaard.free.fr/spca50x/Doc/Omnivision/ds_511P.pdf
Un saludo y gracias de antemano.
Me encuentro desarrollandolo con las DDK y Driver Studio 2.7. El problema que tengo es que usa dos endpoints, uno es el de control (endpoint 0) de entrada salida (con lo cual tenemos dos direcciones 0x80 y 0x00), y el otro es Isócrono de entrada (endpoint 1), para la transferencia de video. Hasta ahí bien.
Viendo el datasheet, se observa que utiliza una compresión hardware del fabricante en el módulo OmniCE. Asi que decidí, dejarlo por el momento y hacer pruebas más sencillas de comunicación. Una de ellas consiste en eneceder y apagar el diodo LED que tiene. Dicho diodo es accesible mediante el registro 55h de la cámara. El problema que tengo es acceder a dicho registro.
Está claro que si usa el endpoint 0 para las transferencias de control, entonces el objeto a utilizar es de tipo KUsbLowerDevice, y su método BuildVendorRequest. Pero para ello debo saber los valores de algunos parámetros, por ejemplo Request y Value. Decidí para ello, usar un sniffer para USB, con los drivers originales de la cámara. Viendo el tráfico a través del USBD, observo el contenido de los paquetes URB. Se puede observar que los valores Request y Value permanecen constantes para cualquier tipo de petición y que lo único que varía es el parámetro Index (1 byte), cuyo contenido siempre oscila entre 10 y BF que son curiosamente el mapa de memoria de los registros, con lo cual, la hipótesis que tengo es que Index contiene la dirección del registro a acceder.
Haciendo cientos de pruebas, no conseguí nada, solo un montón pantallazos azules de volcado de memoria...
Otro detalle importante que aparece en el datasheet es que dice que la cámara entra en modo suspensión si pasados 3 milisegundos no se tranfiere ninguna información. Con lo cual he podido deducir que no puedo acceder bien al registro porque ya está en ese modo (como un standby). Pero el fabricante no facilita información al respecto sobre cómo "despertarla".
Tengo muchas dudas, y no sé si estoy realizando correctamente el procedimiento:
En el método Write (KIrp I) {...} lo que hago es lo siguiente:
PURB miurb; //Declaro una variable que apuntará a la estructura URB a mandar al USBD
miurb=m_Lower.BuildVendorRequest(pBuffer, dwTotalSize, 0x00, 0x00, 0x02, false, false, NULL, 0x55, URB_FUNCTION_VENDOR_DEVICE, NULL); //Construimos el URB a partir del IRP que llegue de la aplicación (pBuffer), y usamos los valores Request y Value que observé en el Sniffer, 0x02 para datos de salida, y 0x03 para datos de entrada. Por último 0x55 es Index, la dirección del registro a acceder.
m_Lower.SubmitUrb(mirub, NULL, NULL, 0); //Enviamos el URB al USBD.
Haciendo ésto aparece un pantallazo azul... ¿qué está fallando?
Buscando en "Google code search", he observado drivers para Linux para el controlador 0V511+. El problema es que según esos drivers, los parámetros se pasan en Request y Value (lo que en el sniffer era constante), y además no hace nada extraño... usa las funciones de la API del kernel "usb_control_msg" y "usb_sndctrlpipe", en esta última, especificando el endpoint 0. Lo que su homólogo equivale a BuildVendorRequest para las DDK.
Aquí les dejo la información del chip 0V511+: http://mxhaard.free.fr/spca50x/Doc/Omnivision/ds_511P.pdf
Un saludo y gracias de antemano.
Valora esta pregunta
0