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 !, pero acabamos de "er que #sta ha sido tomada directamente de las especificaciones $% . &or eso es interesante introducir esta tecnologa que a primera "ista puede parecer un poco oscura, pero que no lo es en absoluto'()*. +on frecuencia los fabricantes tienen la necesidad de dise,ar dispositi"os sencillos de entrada-salida. .stos agentes tienden a usar tecnologas a las que se encuentran acostumbrados. .ste es el caso de /%01)1 y /%0234. &ero a medida que la tecnologa a"an5a, los puertos serie se hacen cada "e5 menos comunes. 67a ra5n8 7a "elocidad de transferencia es reducida y la escalabilidad escasa. .n este conte9to aparece la tecnologa $% , que soluciona los mismos problemas, a tra"#s de una tecnologa que ya no es cara y que mejora las limitaciones anteriores. $n dispositi"o $% :Universal Serial Bus; proporciona la informacin sobre sus caractersticas mediante descriptores. A partir de ah, un cliente puede solicitar que el dispositi"o trabaje para #l, si su clase y capacidades son acordes. Hay 1 propiedades importantes en todos los dispositi"os $% , su Vendor ID, VID, y su Product ID, PID. .stos "alores identifican el tipo de dispositi"o. Hay que tener en cuenta que las aplicaciones no pueden acceder directamente a los puertos $% , ya que el %.<. no lo permite. De hecho lo que hace =indo>s, en este caso, es asignar un 1

Aplicaciones de controlador Bluetooth en Robtica.

dri"er a un dispositi"o concreto. .s con este ?ltimo con el que interactuamos. De hecho el cdigo del dri"er no hay que implementarlo. .n este sentido, un programa para $% sobre =indo>s puede tener 1 modos, que se refieren al ni"el de pri"ilegio en el acceso a la memoria, recursos,... 7os 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 dri"ers $% . .n la figura 4.( podemos obser"arlo de forma mAs clara.

Aplicaciones
APIs de Windows

USER MODE

Subsistema Win 32

I/O Request Packet KERNEL MODE

Client drivers (function drivers )

Bigura 4.(. Codos de pri"ilegio sobre un dispositi"o $%

Aunque no es un aspecto importante en este trabajo, cuando se escribe el cdigo para un controdor para dispositi"os $% , se usa el compilador + incluido en la DDD de =indo>s, y as generar el cdigo que finalmente se aloja en el Windows Driver Model, =DC, que contiene todos los dri"ers para =indo>s. Eeamos con mAs detalle la figura anterior, para as comprender mejor el concepto de dri"ers por capas. .l detalle se representa en la figura 4.1. +omo "emos cada capa se encarga de comunicacin, mejorando as la eficiencia. un subproceso de la

5.2. TRANSFERENCIA DE DATOS USB

+omo ejemplo, "eamos los pasos que se dan en una transferencia $% para la adquisicin de datos de un dispositi"o $% por parte de una aplicacin de usuario. %e usarA un Dri"er 2

Aplicaciones de controlador Bluetooth en Robtica.

.specfico de Dispositi"o 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 DRI ER OPTIONS

Generic parent dri"er used by some composite de"ices

USB HUB %"&'$" (USBHUB)S*S) USB CO !"O##$" %"&'$" (USB(O"!)S*S)

Miniport driver High Speed

Miniport driver Low Speed

Miniport driver Full Speed

US! DRI ER STACK

Hardware

Bigura 4.1. Dri"ers $% @ modelo de =indo>s

00.n primer lugar, antes de que una aplicacin pueda comunicarse con un dispositi"o, al conectarlo, =indo>s reconoce el dispositi"o y el dri"er a usar. A continuacin la aplicacin obtiene un manejador que identifica al dispositi"o y habilita la comunicacin. 007o siguiente es iniciar la transferencia de datos. &uede inicarse cuando la transferencia sea requerida por la aplicacin o bien al arrancar directamente. 00A partir de este momento, una aplicacin, por ejemplo escrita en lenguaje +F, necesita comunicarse con los driver client. &ara ello se usan A&Is, que incluyen funciones para abrir la comunicacin, intercambio de datos,... con el dri"er de cliente. 7os datos que son ledos o se escriben, se almacenan en un buffer que se especifica en la llamada a la A&I. De esta forma, una llamada a la funcin /eadBile no siempre recupera datos del dispositi"o sino que lo que realmente leemos son datos almacenados 3

Aplicaciones de controlador Bluetooth en Robtica.

en el buffer. 7os sistemas finales :aplicaciones; pueden usar distintos tipos de transferencias de datos@ transferencias controladas, transferencia masi"a, por interrupcin o sncronas. 7as transferencias masi"as y sncronas se usan en dispositi"os que transfieren gran cantidad de datos a rAfagas, como cAmaras o impresoras. 7os otros tipos se usan para comunicaciones rApidas de notificaciones y respuestas. +omo "emos hay muchas clasificaciones para los dispositi"os $% , cada una con su protocolo. &ero de entre ellos hay una que es el que nos interesa en nuestro caso@ dispositi"os de interfa5 humana.

5.3. GUIDS
7os G$IDs, Globally Unique Identifier, son "alores de (13 bits que identifican un"ocamente una clase o entidad. =indo>s posee 1 tipos de clases de dispositi"os, cada uno de ellos identificados por sus G$IDs un"ocas@ 0+lases de configuracin del dispositi"o, Device Setu GUID@ abarca una serie de dispositi"os que =indo>s instala de la misma forma. .n =indo>s tenemos la dev!uid." que define el G$ID para muchos dispositi"os. 0+lases de interfa5 de dispositi"o, GUID Device Interface #lasses@ &roporcionan a las aplicaciones la forma de comunicarse con un dri"er asignado a un dispositi"o de la clase. .sta G$ID puede usarla la aplicacin, incluso para requerir el a"iso del estado de la cone9in de un dispositi"o.

5.4. BREVE RESEA SOBRE FUNCIONES API

%eg?n la cuestin anterior, nos damos cuenta que el desarrollador de aplicaciones debe situarse un ni"el por encima en cuanto a la creacin de su soft>are, ya que la parte mAs directa con la interfa5 $% se encuentra escondida de cara a #l.

Aplicaciones de controlador Bluetooth en Robtica.

&odemos decir que si, por ejemplo, trabajamos con la plataforma .N.!, con la que hemos trabajado en este proyecto, ya estamos en este ni"el superior ya que da soporte a partes comunes, a tra"#s de componentes y clases, y a tra"#s de un lenguaje intermedio portable. Hay un problema, y es que .N.! hasta ahora no es capa5 de dar soporte a todas las tareas, por ejemplo para el manejo de dispositi"os $% . Nos "emos obligados al uso de A&Is :$ lication Pro!ra%%in! Interface& que nos brindan una serie de funciones y m#todos que se encuentran en libreras, para ser usadas por otro soft>are como una capa de abstraccin. No obstante, a largo pla5o el objeti"o de .N.! es eliminar la necesidad de uso de A&Is. &ongamos un ejemplo para aclarar estos conceptos. %upongamos que queremos controlar el mo"imiento del cursor del ratn en un &+. %upongamos que trabajamos en Visual Studio .'(), un lenguaje disponible para .N.!. /Apidamente pensamos en buscar una clase de la biblioteca .N.! que permita esto, de la misma forma que encontramos el componente Serial Port para manejar el puerto serie como un ni"el de abstraccin. <bser"amos que no e9iste tal librera en .N.!. &ues bien, si buscamos en la biblioteca =in)1, que almacena todas las A&Is, encontramos user)1.dll, una A&I que contiene funciones para control de dispositi"os. $no de ellos es el ratn. +omo "emos, tanto A&Is como .N.! nos proporcionan m#todos y clases para acceder a los dispositi"os, trabajando nosotros en un ni"el de abstraccin superior. &odemos preguntarnos ahora, si los dos hacen lo mismo, 6cuAl es la diferencia entre uno y otro8 Aqu entra en juego el concepto de Mana!ed y Un%ana!ed code, cdigo administrado y no administrado@ 07as A&Is de =indo>s se componen de archi"os ."* donde se almacena la declaracin de la funcin, por un lado, y por otro archi"os .dll donde estA el cdigo de la funcin. .stas usan cdigo no administrado, de forma que las dll usan cdigo mAquina ya compilado. Al hacer uso de ellas se ejecutan directamente en la +&$, de forma que no tenemos control sobre las mismas. 0.N.! usa cdigo administrado que se compila en un lenguaje intermedio, MSI+, que despu#s es ejecutado a tra"#s del #o%%on +an!ua!e ,unti%e. 7a HgestinI de nuestro cdigo tiene "entajas, ya que nuestro cdigo es portable entre mAquinas y entre lenguajes de distinto tipo. !ambi#n e9iste gestin de la memoria, de forma 5

Aplicaciones de controlador Bluetooth en Robtica.

que se libera la memoria usada y otras tareas de forma automAtica. .sta ?ltima puede "erse como un incon"eniente, ya que el programador no tiene control directo sobre la memoria. +omo la plataforma .N.! 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 tambi#n promo"er la difusin de esta plataforma. %i usamos cdigo no administrado en nuestro cdigo administrado, hay que asegurar un cambio correcto. As por ejemplo para usar los datos de"ueltos por una A&I, los datos deben ordenarse :%ars"allin!;. As se hace lo necesario para que estos datos est#n disponibles al cdigo administrado@ copiar datos a memoria administrada y-o con"ertir tipos de datos. &or ?ltimo hay que decir que cuando decidimos usar A&Is =in)1 nos puede lle"ar mucho tiempo decidir cuAl es la funcin que se ajusta a nuestras necesidades y la dll necesaria. .n '(1* tenemos un gran recurso donde estAn todas las A&Is documentadas. Algunas A&Is muy usadas son@ 0setu a i.dll@ %e encarga de la deteccin de dispositi"os. 0kernell-..dll@ /elacionado con la apertura de comunicaciones con los dispositi"os. 0user-..dll@ dispositi"os. Bunciones relati"as a comunicacin con los

5.5. INTRODUCCIN A HID

HID :/u%an Interface Device; es una de las clases que nos aporta $% . %i abrimos el &anel de control de =indo>s podemos "er los dri"ers para ellos:figura 4.);. HID surge con la idea de hacer sencilla la implementacin de dri"ers y aplicaciones de usuario para un dispositi"o dado. 7a idea a priori es dar soporte a teclados, ratones, controladores de juego, con los que tenga que interactuar un usuario. CAs allA del nombre de la clase, es fAcil e9tender el uso a dispositi"os de usuario que cumplan con los requerimientos que se imponen sobre la clase.

Aplicaciones de controlador Bluetooth en Robtica.

Big. 4.)@ &anel de control@ dispositi"os HID

.n HID, el intercambio de datos se hace a tra"#s de ,e orts* de los que ya hemos hablados. No son mAs que estructuras con un cierto formato fle9ible, y que pueden manejar muchos tipos de datos. +ada report tiene un tama,o fijo. AdemAs se conoce como responder a los datos de un cierto report, as, saber que report usar para la respuesta. .n general hay ) tipos de reports@ de entrada, salida y de caractersticas. +omo mencionamos antes, en $% hay distintos tipos de transferencias. .n el caso de HID slo se usan las tranferencias de control y por interrupcin. &or otro lado, en HID se usan descriptores que contienen el tama,o de los datos que "an contenidos en los reports, as como informacin adicional. =indo>s tiene acceso e9clusi"o a los reports de entrada de los dispositi"os, ratones, teclados,..., de modo y forma que las aplicaciones no pueden leer directamente los reports asociados a ellos, pulsaciones de ratn, mo"imientos, pulsaciones de teclado,... .n su lugar, el %istema <perati"o controla todos estos detalles de bajo ni"el, y la aplicacin interactua con el dri"er del %.<. a tra"#s de un manejador proporcionado.

Aplicaciones de controlador Bluetooth en Robtica.

5.6. DETECTANDO UN DISPOSITIVO HID

+uando conectamos un HID a un &+ con =indo>s J&, el %.<. lo detecta e intenta locali5ar un dri"er para #l. Incluso si no se encuentra un dri"er adecuado, la Windows Device Mana!er confirmarA que el dispositi"o estA conectado y cumple con la clase HID. A partir de ah, =indo>s en"a un mensaje de tipo =CKD.EI+.+HANG.. A partir de aqu empie5a nuestro trabajo como desarrolladores@ ++Obtener el ,U&% de la interfa- de dispositivo. Cediante la funcin HidDKGetHidGuid, de "id.dll, obtenemos la G$ID que =indo>s usa para identificar un cierto tipo de dispositi"o :por ejemplo el de la clase HID;, parAmetro que ya ha sido descrito y que es necesario en el resto del proceso. ++Obtener la lista de dispositivos. $sando la G$ID obtenida, y llamando a Setu DiGet#lassDevs, de setu a i.dll, se obtiene un Device Infor%ation Set que contiene informacin de los dispositi"os de la clase instalados :por tanto se especifica el G$ID obtenido;. Cejor dicho, lo que se hace con esta funcin es reser"ar un bloque de memoria que alberga un array con una entrada por dispositi"o conectado de la clase especificada. ++Obtener detalles de cada dispositivo. $na "e5 obtenido el Info %et, mediante la funcin Setu Di(nu%DeviceInterfaces* que encontramos en la misma dll, enumeramos cada entrada. +ada llamada a esta funcin llena una nue"a estructura de tipo DeviceInterfaceData que contiene detalles de un dispositi"o de la clase que estA conectado. %i queremos enumerar todos los conectados tendremos que hacer una llamada para cada uno. ++Obtener la ruta de interfa- del dispositivo. !oda"a no hemos llegado al final. !enemos que usar la funcin Setu DiGetDeviceInterfaceDetail para llenar una estructura de tipo DeviceInterfaceDetail* que finalmente contiene una cadena que alberga la ruta del dispositi"o :similar a la ruta de un fichero;. A partir de esta informacin podremos comunicarnos con el dispositi"o, as como encontrar su EID-&ID, para comprobar si es el que estamos buscando.

Aplicaciones de controlador Bluetooth en Robtica.

++#iberar toda la memoria consumida. !ras 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 .N.! no "a a liberarla por nosotros;. .sto se hace mediante una llamada a Setu DiDestroyDevice0Info+ist.

5.7. TRANSFERENCIA DE DATOS

$na "e5 obtenida la ruta de dispositi"o, abierto como si de un fichero se tratase. #ste puede ser

&ara eso usamos la A&I de 1ernell-..dll* #reate2ile. .sta funcin de"uel"e un manejador que habilita la comunicacin con el dispositi"o, con #l podemos intercambiar por ejemplo, reports de la clase HID. +uando el manejador es obtenido, se puede pasar a un objeto de flujo de fichero :2ileStrea%; para hacer lecturas y escrituras como si de un fichero se tratase. 7a "erdadera usamos operaciones de entrada-salida proceso principal, potencialidad de esto se obtiene si ademAs de lectura y escritura asncronas@ el proceso se lle"a a cabo en un hilo independiente al y que no lo bloquea.

&odemos programar el a"iso de que ha tenido lugar alg?n e"ento. De esta forma nos llega la notificacin del e"ento, y definir un m#todo que se ejecute cuano ourra. !odo ocurre en un hilo distinto. CAs adelante "eremos como se han resuelto estas cuestiones de forma mAs concreta, en el entorno de programacin con el que hemos trabajado.