Aplicaciones de controlador Bluetooth en Robtica.

CAPTULO 5: USB Y EL PROTOCOLO HID

Aunque ya hemos tratado estos aspectos, de forma que se entendiera como funciona el mando mientras hacamos la descripcin del mismo. A continuacin ahondamos en estos conceptos para as construir unas slidas bases que sostengan nuestro trabajo.

5.1. VISIN GENERAL DE USB

Nuestro mando usa la tecnologa HID propia de BT, pero acabamos de ver que sta ha sido tomada directamente de las especificaciones USB. Por eso es interesante introducir esta tecnologa que a primera vista puede parecer un poco oscura, pero que no lo es en absoluto[13]. Con frecuencia los fabricantes tienen la necesidad de disear dispositivos sencillos de entrada/salida. Estos agentes tienden a usar tecnologas a las que se encuentran acostumbrados. Este es el caso de RS-232 y RS-485. Pero a medida que la tecnologa avanza, los puertos serie se hacen cada vez menos comunes. La razn? La velocidad de transferencia es reducida y la escalabilidad escasa. En este contexto aparece la tecnologa USB, que soluciona los mismos problemas, a travs de una tecnologa que ya no es cara y que mejora las limitaciones anteriores. Un dispositivo USB (Universal Serial Bus) proporciona la informacin sobre sus caractersticas mediante descriptores. A partir de ah, un cliente puede solicitar que el dispositivo trabaje para l, si su clase y capacidades son acordes. Hay 2 propiedades importantes en todos los dispositivos USB, su Vendor ID, VID, y su Product ID, PID. Estos valores identifican el tipo de dispositivo. Hay que tener en cuenta que las aplicaciones no pueden acceder directamente a los puertos USB, ya que el S.O. no lo permite. De hecho lo que hace Windows, en este caso, es asignar un 1

Aplicaciones de controlador Bluetooth en Robtica.

driver a un dispositivo concreto. Es con este ltimo con el que interactuamos. De hecho el cdigo del driver no hay que implementarlo. En este sentido, un programa para USB sobre Windows puede tener 2 modos, que se refieren al nivel de privilegio en el acceso a la memoria, recursos,... Los dos modos son: usuario, que es el modo en el que corren las aplicaciones, y kernel, que es el modo al que tienen acceso los drivers USB. En la figura 5.1 podemos observarlo de forma ms clara.

Aplicaciones
APIs de Windows

USER MODE

Subsistema Win 32

I/O Request Packet KERNEL MODE

Client drivers (function drivers )

Figura 5.1. Modos de privilegio sobre un dispositivo USB

Aunque no es un aspecto importante en este trabajo, cuando se escribe el cdigo para un controdor para dispositivos USB, se usa el compilador C incluido en la DDK de Windows, y as generar el cdigo que finalmente se aloja en el Windows Driver Model, WDM, que contiene todos los drivers para Windows. Veamos con ms detalle la figura anterior, para as comprender mejor el concepto de drivers por capas. El detalle se representa en la figura 5.2. Como vemos cada capa se encarga de comunicacin, mejorando as la eficiencia. un subproceso de la

5.2. TRANSFERENCIA DE DATOS USB

Como ejemplo, veamos los pasos que se dan en una transferencia USB para la adquisicin de datos de un dispositivo USB por parte de una aplicacin de usuario. Se usar un Driver 2

Aplicaciones de controlador Bluetooth en Robtica.

Especfico de Dispositivo cliente.

Aplicaciones

Class Client Driver defines a user interface for a class

Vendor Specific Client Driver defines a user interface for a custom hardware

Class or vendor specific client driver

Class or vendor specific client driver

CLIENT DRIVER OPTIONS

Generic parent driver used by some composite devices

USB HUB DRIVER (USBHUB.SYS) USB CONTROLLER DRIVER (USBPORT.SYS)

Miniport driver High Speed

Miniport driver Low Speed

Miniport driver Full Speed

USB DRIVER STACK

Hardware

Figura 5.2. Drivers USB: modelo de Windows

--En primer lugar, antes de que una aplicacin pueda comunicarse con un dispositivo, al conectarlo, Windows reconoce el dispositivo y el driver a usar. A continuacin la aplicacin obtiene un manejador que identifica al dispositivo y habilita la comunicacin. --Lo siguiente es iniciar la transferencia de datos. Puede inicarse cuando la transferencia sea requerida por la aplicacin o bien al arrancar directamente. --A partir de este momento, una aplicacin, por ejemplo escrita en lenguaje C#, necesita comunicarse con los driver client. Para ello se usan APIs, que incluyen funciones para abrir la comunicacin, intercambio de datos,... con el driver de cliente. Los datos que son ledos o se escriben, se almacenan en un buffer que se especifica en la llamada a la API. De esta forma, una llamada a la funcin ReadFile no siempre recupera datos del dispositivo sino que lo que realmente leemos son datos almacenados 3

Aplicaciones de controlador Bluetooth en Robtica.

en el buffer. Los sistemas finales (aplicaciones) pueden usar distintos tipos de transferencias de datos: transferencias controladas, transferencia masiva, por interrupcin o sncronas. Las transferencias masivas y sncronas se usan en dispositivos que transfieren gran cantidad de datos a rfagas, como cmaras o impresoras. Los otros tipos se usan para comunicaciones rpidas de notificaciones y respuestas. Como vemos hay muchas clasificaciones para los dispositivos USB, cada una con su protocolo. Pero de entre ellos hay una que es el que nos interesa en nuestro caso: dispositivos de interfaz humana.

5.3. GUIDS
Los GUIDs, Globally Unique Identifier, son valores de 128 bits que identifican unvocamente una clase o entidad. Windows posee 2 tipos de clases de dispositivos, cada uno de ellos identificados por sus GUIDs unvocas: -Clases de configuracin del dispositivo, Device Setup GUID: abarca una serie de dispositivos que Windows instala de la misma forma. En Windows tenemos la devguid.h que define el GUID para muchos dispositivos. -Clases de interfaz de dispositivo, GUID Device Interface Classes: Proporcionan a las aplicaciones la forma de comunicarse con un driver asignado a un dispositivo de la clase. Esta GUID puede usarla la aplicacin, incluso para requerir el aviso del estado de la conexin de un dispositivo.

5.4. BREVE RESEA SOBRE FUNCIONES API

Segn la cuestin anterior, nos damos cuenta que el desarrollador de aplicaciones debe situarse un nivel por encima en cuanto a la creacin de su software, ya que la parte ms directa con la interfaz USB se encuentra escondida de cara a l.

Aplicaciones de controlador Bluetooth en Robtica.

Podemos decir que si, por ejemplo, trabajamos con la plataforma .NET, con la que hemos trabajado en este proyecto, ya estamos en este nivel superior ya que da soporte a partes comunes, a travs de componentes y clases, y a travs de un lenguaje intermedio portable. Hay un problema, y es que .NET hasta ahora no es capaz de dar soporte a todas las tareas, por ejemplo para el manejo de dispositivos USB. Nos vemos obligados al uso de APIs (Application Programming Interface) que nos brindan una serie de funciones y mtodos que se encuentran en libreras, para ser usadas por otro software como una capa de abstraccin. No obstante, a largo plazo el objetivo de .NET es eliminar la necesidad de uso de APIs. Pongamos un ejemplo para aclarar estos conceptos. Supongamos que queremos controlar el movimiento del cursor del ratn en un PC. Supongamos que trabajamos en Visual Studio .NET, un lenguaje disponible para .NET. Rpidamente pensamos en buscar una clase de la biblioteca .NET que permita esto, de la misma forma que encontramos el componente Serial Port para manejar el puerto serie como un nivel de abstraccin. Observamos que no existe tal librera en .NET. Pues bien, si buscamos en la biblioteca Win32, que almacena todas las APIs, encontramos user32.dll, una API que contiene funciones para control de dispositivos. Uno de ellos es el ratn. Como vemos, tanto APIs como .NET nos proporcionan mtodos y clases para acceder a los dispositivos, trabajando nosotros en un nivel de abstraccin superior. Podemos preguntarnos ahora, si los dos hacen lo mismo, cul es la diferencia entre uno y otro? Aqu entra en juego el concepto de Managed y Unmanaged code, cdigo administrado y no administrado: -Las APIs de Windows se componen de archivos .h, donde se almacena la declaracin de la funcin, por un lado, y por otro archivos .dll donde est el cdigo de la funcin. Estas usan cdigo no administrado, de forma que las dll usan cdigo mquina ya compilado. Al hacer uso de ellas se ejecutan directamente en la CPU, de forma que no tenemos control sobre las mismas. -.NET usa cdigo administrado que se compila en un lenguaje intermedio, MSIL, que despus es ejecutado a travs del Common Language Runtime. La gestin de nuestro cdigo tiene ventajas, ya que nuestro cdigo es portable entre mquinas y entre lenguajes de distinto tipo. Tambin existe gestin de la memoria, de forma 5

Aplicaciones de controlador Bluetooth en Robtica.

que se libera la memoria usada y otras tareas de forma automtica. Esta ltima puede verse como un inconveniente, ya que el programador no tiene control directo sobre la memoria. Como la plataforma .NET no da soporte a todas las tasks, en el desarrollo de la misma se ha dado libertad al programador de usar cdigo no administrado en sus aplicaciones, as tambin promover la difusin de esta plataforma. Si usamos cdigo no administrado en nuestro cdigo administrado, hay que asegurar un cambio correcto. As por ejemplo para usar los datos devueltos por una API, los datos deben ordenarse (marshalling). As se hace lo necesario para que estos datos estn disponibles al cdigo administrado: copiar datos a memoria administrada y/o convertir tipos de datos. Por ltimo hay que decir que cuando decidimos usar APIs Win32 nos puede llevar mucho tiempo decidir cul es la funcin que se ajusta a nuestras necesidades y la dll necesaria. En [12] tenemos un gran recurso donde estn todas las APIs documentadas. Algunas APIs muy usadas son: -setupapi.dll: Se encarga de la deteccin de dispositivos. -kernell32.dll: Relacionado con la apertura de comunicaciones con los dispositivos. -user32.dll: dispositivos. Funciones relativas a comunicacin con los

5.5. INTRODUCCIN A HID

HID (Human Interface Device) es una de las clases que nos aporta USB. Si abrimos el Panel de control de Windows podemos ver los drivers para ellos(figura 5.3). HID surge con la idea de hacer sencilla la implementacin de drivers y aplicaciones de usuario para un dispositivo dado. La idea a priori es dar soporte a teclados, ratones, controladores de juego, con los que tenga que interactuar un usuario. Ms all del nombre de la clase, es fcil extender el uso a dispositivos de usuario que cumplan con los requerimientos que se imponen sobre la clase.

Aplicaciones de controlador Bluetooth en Robtica.

Fig. 5.3: Panel de control: dispositivos HID

En HID, el intercambio de datos se hace a travs de Reports, de los que ya hemos hablados. No son ms que estructuras con un cierto formato flexible, y que pueden manejar muchos tipos de datos. Cada report tiene un tamao fijo. Adems se conoce como responder a los datos de un cierto report, as, saber que report usar para la respuesta. En general hay 3 tipos de reports: de entrada, salida y de caractersticas. Como mencionamos antes, en USB hay distintos tipos de transferencias. En el caso de HID slo se usan las tranferencias de control y por interrupcin. Por otro lado, en HID se usan descriptores que contienen el tamao de los datos que van contenidos en los reports, as como informacin adicional. Windows tiene acceso exclusivo a los reports de entrada de los dispositivos, ratones, teclados,..., de modo y forma que las aplicaciones no pueden leer directamente los reports asociados a ellos, pulsaciones de ratn, movimientos, pulsaciones de teclado,... En su lugar, el Sistema Operativo controla todos estos detalles de bajo nivel, y la aplicacin interactua con el driver del S.O. a travs de un manejador proporcionado.

Aplicaciones de controlador Bluetooth en Robtica.

5.6. DETECTANDO UN DISPOSITIVO HID

Cuando conectamos un HID a un PC con Windows XP, el S.O. lo detecta e intenta localizar un driver para l. Incluso si no se encuentra un driver adecuado, la Windows Device Manager confirmar que el dispositivo est conectado y cumple con la clase HID. A partir de ah, Windows enva un mensaje de tipo WM_DEVICECHANGE. A partir de aqu empieza nuestro trabajo como desarrolladores: --Obtener el GUID de la interfaz de dispositivo: Mediante la funcin HidD_GetHidGuid, de hid.dll, obtenemos la GUID que Windows usa para identificar un cierto tipo de dispositivo (por ejemplo el de la clase HID), parmetro que ya ha sido descrito y que es necesario en el resto del proceso. --Obtener la lista de dispositivos: Usando la GUID obtenida, y llamando a SetupDiGetClassDevs, de setupapi.dll, se obtiene un Device Information Set que contiene informacin de los dispositivos de la clase instalados (por tanto se especifica el GUID obtenido). Mejor dicho, lo que se hace con esta funcin es reservar un bloque de memoria que alberga un array con una entrada por dispositivo conectado de la clase especificada. --Obtener detalles de cada dispositivo: Una vez obtenido el Info Set, mediante la funcin SetupDiEnumDeviceInterfaces, que encontramos en la misma dll, enumeramos cada entrada. Cada llamada a esta funcin llena una nueva estructura de tipo DeviceInterfaceData que contiene detalles de un dispositivo de la clase que est conectado. Si queremos enumerar todos los conectados tendremos que hacer una llamada para cada uno. --Obtener la ruta de interfaz del dispositivo: Todava no hemos llegado al final. Tenemos que usar la funcin SetupDiGetDeviceInterfaceDetail para llenar una estructura de tipo DeviceInterfaceDetail, que finalmente contiene una cadena que alberga la ruta del dispositivo (similar a la ruta de un fichero). A partir de esta informacin podremos comunicarnos con el dispositivo, as como encontrar su VID/PID, para comprobar si es el que estamos buscando.

Aplicaciones de controlador Bluetooth en Robtica.

--Liberar toda la memoria consumida: Tras estas operaciones, debemos liberar el espacio de memoria que hemos ocupado con las estructuras anteriores (recordar que estamos usando cdigo y memoria no administradas, de forma que .NET no va a liberarla por nosotros). Esto se hace mediante una llamada a SetupDiDestroyDevice-InfoList.

5.7. TRANSFERENCIA DE DATOS

Una vez obtenida la ruta de dispositivo, abierto como si de un fichero se tratase. ste puede ser

Para eso usamos la API de Kernell32.dll, CreateFile. Esta funcin devuelve un manejador que habilita la comunicacin con el dispositivo, con l podemos intercambiar por ejemplo, reports de la clase HID. Cuando el manejador es obtenido, se puede pasar a un objeto de flujo de fichero (FileStream) para hacer lecturas y escrituras como si de un fichero se tratase. La verdadera usamos operaciones de entrada/salida proceso principal, potencialidad de esto se obtiene si adems de lectura y escritura asncronas: el proceso se lleva a cabo en un hilo independiente al y que no lo bloquea.

Podemos programar el aviso de que ha tenido lugar algn evento. De esta forma nos llega la notificacin del evento, y definir un mtodo que se ejecute cuano ourra. Todo ocurre en un hilo distinto. Ms adelante veremos como se han resuelto estas cuestiones de forma ms concreta, en el entorno de programacin con el que hemos trabajado.