Proyecto de Grado

Interfaz USB genrica para comunicacin con dispositivos electrnicos

Informe Final
A/C Andrs Aguirre, A/C Pablo Fernndez y A/C Carlos Grossy.

Tutores: MSc Ing. Gonzalo Tejera y MSc Ing. Alexander Sklar

Instituto de Computacin - Facultad de Ingeniera

Universidad de la Repblica Oriental del Uruguay

14 de diciembre de 2007

Resumen
Debido a que en general los dispositivos electrnicos existentes (sensores, actuadores, displays, ADCs, DACs, etc.) utilizan mltiples interfaces y protocolos de comunicacin ajenos al contexto de las computadoras personales, genera que la interaccin no sea una tarea trivial y en general implique desarrollar soluciones particulares para lograr su integracin. Esta heterogeneidad motiva la bsqueda de un medio de comunicacin existente en un PC, lo sucientemente verstil para satisfacer la mayora de los requerimientos. Desde hace unos aos la tecnologa USB se ha convertido en un estndar, lo que ha llevado a una proliferacin de dispositivos y un auge en su uso. La facilidad de uso, ancho de banda y funcionalidad Plug&Play son algunas de las caractersticas ms atractivas para utilizar al USB como medio de comunicacin. La motivacin de este proyecto se centra en lograr de una manera sencilla, la comunicacin entre una PC y un conjunto de dispositivos electrnicos no necesariamente pensados para interactuar con una computadora. La solucin est conformada por un hardware construido a medida basado en un microcontrolador, con rmware congurable va software por medio de USB y conjunto de elementos de software que permiten la comunicacin y manejo de los dispositivos desde las aplicaciones de usuario. El rmware desarrollado se caracteriza por su modularidad y extensibilidad, mientras que en el software del PC se destaca su orientacin a objetos, soporte de mltiples instancias de hardware y de varias plataformas. Todos los elementos funcionan en conjunto de forma de dar una respuesta integral a la problemtica permitiendo ocultar a los ojos de los usuarios toda la complejidad de la interaccin con los dispositivos electrnicos. Entre las principales contribuciones de este proyecto se destacan el desarrollo de un framework que permite acelerar la integracin de dispositivos electrnicos con el PC por medio de la tecnologa USB, pues slo se necesita incorporar la funcionalidad especca para el manejo de los mismos. Tambin permite un alto grado de reutilizacin de las funcionalidades especcas ya construidas, pues por medio de su composicin se puede elaborar una nueva solucin para el manejo de dispositivos ms complejos o compuestos. A su vez el relevamiento del estado del arte de la tecnologa USB y de los microcontroladores y drivers existente hoy en da que la soportan, requiri un gran esfuerzo y es considerado como un aporte de este proyecto. Este proyecto habilita ampliar el horizonte de utilizacin por parte de un PC de elementos fsicos as como el universo de usuarios que lo utilizan, logrando reducir la brecha de conocimientos necesarios para resolver las problemticas de conectividad e interaccin con dispositivos.

Palabras claves: USB, Microcontroladores, Framework de desarrollo, Controladoras de entrada / salida, Prototipado rpido, Programacin embebida.

Agradecimientos
Gonzalo Tejera y Alexander Sklar por la oportunidad de hacer el proyecto, apoyo e invaluables consejos durante el desarrollo del mismo. A nuestros compaeros de trabajo y superiores por su tolerancia, en particular a Cristina Lovesio. Texas Instruments, Microchip, Freescale, Philips por sus donaciones de muestras de semiconductores. Agradecimientos personales:

Carlos Grossy agradece a: Virginia Lpez, madre y hermanos por su paciencia y apoyo durante este proyecto. Rafael Fernndez agradece a: familia y Claudia Garca por su paciencia y apoyo durante este proyecto y Noelia Pissani por su colaboracin al conseguir chas USB hardware.

Andrs Aguirre agradece a: Omar Aguirre, Fabiana Bianchi y Ana Dorelo por la paciencia y apoyo constante.

ndice general
I Generalidades
1. Introduccin
1.1. 1.2. 1.3. 1.4. 1.5. 1.6. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qu es el proyecto? Que no es el proyecto Objetivos

15
17
17 18 18 19 20 21

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Organizacin del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Etapas del proyecto

2. Resumen del estado del arte

2.1. USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.3. 2.3.1. 2.3.2. 2.3.3. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.4.4. Caractersticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transferencias Enumeracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descriptores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jerarqua de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funcionamiento:

23
23 23 24 25 25 25 26 26 27 27 28 30 31 31 33 35 36 36 37 38 39

Opciones de conectividad USB

Transceivers USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conversores USB a interfaz serial o paralela . . . . . . . . . . . . . . . . . Controladores de perifricos . . . . . . . . . . . . . . . . . . . . . . . . . . Decisiones tomadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . .

Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herramientas de depuracin . . . . . . . . . . . . . . . . . . . . . . . . . . Decisiones tomadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DevaSys - USB I2C / IO

Proyectos relacionados

Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II Arquitectura
3. Introduccin 4. Arquitectura en el Baseboard
4.1. 4.2. Baseboard Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firmware 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.2.6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduccin

41
43 47
47 49 49 52 55 59 59 61

Base Firmware

User Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funcionamiento general Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Programacin y conguracin . . . . . . . . . . . . . . . . . . . . . . . . . 7

NDICE GENERAL

5. Arquitectura en el PC
5.1. 5.2. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . USB4all API 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5. 5.3. 5.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduccin Logic Log

65
65 66 66 67 70 77 79 80 84

Public Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection to USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

USB4all Library

Generic Driver USB

6. Comunicacin
6.1. Protocolo de Comunicacin 6.1.1. 6.1.2. 6.2. 6.2.1. 6.2.2. 6.2.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handler Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Admin Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87
87 88 89 92 93 95 96

Interaccin USB4all API

USB4all Firmware Operacin openDevice . . . . . . . . . . Operaciones sendData y receiveData . Operacin closeDevice . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7. Decisiones de Diseo e Implementacin

7.1. 7.2. 7.3. Decisiones Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Decisiones en el Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Decisiones en el PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99
99 100 101

III Experimentos y Resultados

8. Artefactos construidos
8.1. 8.2. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware 8.2.1. 8.2.2. 8.2.3. 8.3. 8.3.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evolucin del Baseboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adapterboards Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . USB4all baseboard utility . . . . . . . . . . . . . . . . . . . . . . . . . . .

103
105
105 105 105 107 108 112 112

Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9. Conclusiones y Trabajo a Futuro

9.1. 9.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabajo a Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

113
113 116

A. Glosario B. Herramientas de la Gestin del Proyecto

B.1. L X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Y B.2. CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3. Mantis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.4. Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125 133
133 133 134 134

Lista de algoritmos
1. 2. 3. 4. 5. Pseudocdigo de la operacin Pseudocdigo de la operacin Pseudocdigo Pseudocdigo

main

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54 58 58 58 61

Mecanismo para almacenar las referencias en memoria de programa del mdulo.

init . . . . de la operacin release . . del la operacin interrupt

10

LISTA DE ALGORITMOS

ndice de guras
1.1. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. Lnea de tiempo de las actividades del proyecto. . . . . . . . . . . . . . . . . . . . Topologa tipo estrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jerarqua de Descriptores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comunicacin virtual entre un dispositivo y el host . . . . . . . . . . . . . . . . . Diagrama lgico y tabla de verdad del Transceiver USB Cuadro comparativo de los microcontroladores Imagen de la informacin analizada. USB Explorer 200 Diagrama en bloques del FT232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitectura del WinDriver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 24 25 26 27 28 30 31 34 35 36 37 38 39 43 44 48 50 51 52 56 57 59 62 62 63 65 67 69 70 71 72 74 76 77 80 81 82 83 85 87 88

2.10. DevaSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12. Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13. CUI 3.1. 3.2. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Componentes fsicos del sistema USB4all. Componentes

USB4all System.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Identicacin de los componentes del Componentes del

baseboard. . . . . . . . . . . . . . . . . USB4all rmware . . . . . . . . . . . . . . . . . . . . . . Usb4all rmware compuesto por base rmware, dos proxies y user modules user modules

Diagrama de capas en rmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relacin entre los vnculos manejados por los

user module. . . . . Componentes del USB4all rmware.

Estructura de un Proceso de desarrollo y deploy del

y los endpoints USB.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

USB4all rmware. 4.10. Mapa de memoria de programa del baseboard. . . . .

5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. Subsistemas de la

Programacin del bootloader en el microcontrolador del

baseboard

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Diagrama de los elementos de la solucin existentes en el PC. . . . . . . . . . . .

baseboards. Componentes del subsistema Logic .

Escenario de uso con dos Clases del componente

API. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Diagrama de capas de la comunicacin en el PC.

HandlerLayer. . . . . . . Clases del componente CommandLayer. . . . . . Clases del componente DescriptorLayer. . . . . . Componentes del subsistema Connection to USB.

5.10. Dependencias para el uso de las librera orientada a objetos

5.11. Diagrama de clases de la librera orientada a objetos . . . . . . . . . . . . . . . . 5.12. Diagrama de estados que ocurren dentro de las instancias de baseboard y device 5.13. Diagrama de secuencia de uso simple de la library . . . . . . . . . . . . . . . . . 5.14. Ejemplo de apertura y envi de datos por un endpoint. . . . . . . . . . . . . . . . 6.1. 6.2. Stack de protocolos denido y capas . . . . . . . . . . . . . . . . . . . . . . . . .

Paquetes utilizados por el stack de protocolos . . . . . . . . . . . . . . . . . . . . 11

12

NDICE DE FIGURAS

6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9.

Formato de paquete para intercambio de datos utilizado por el Paquete de pedido del comando Paquete de Paquete de Paquete de Paquete de

Formato de paquete para el intercambio de datos utilizado por el

6.10. Paquete de 6.11. Paquete de 6.12. Paquete de

open . . . . . . . . . . . . . respuesta del comando open . . . . . . . . . . . pedido del comando close . . . . . . . . . . . . respuesta del comando close . . . . . . . . . . pedido del comando GET_USER_MODULES_SIZE . respuesta del comando GET_USER_MODULES_SIZE pedido del comando GET_USER_MODULES_LINE . respuesta del comando GET_USER_MODULES_LINE

handler protocol. . admin protocol

89 89 89 90 90 90 91 91 91 91 92 94 95 97 106 107 108 108 109 109 110 111 111 118 119

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.13. Interaccin API - Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

openDevice . . . . . . . 6.15. Diagrama de secuencia de la operacin sendData y receiveData 6.16. Diagrama de secuencia de la operacin closeDevice . . . . . . .
6.14. Diagrama de secuencia de la operacin 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 9.1. 9.2. Evolucin del

adapterboard. . Imagen del stepper motor adapterboard . . . . .

Imagenes del USB4all-Protoboard

Baseboard

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dispositivo motor paso a paso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dispositivo sensor de temperatura. . . . . . . . . . . . . . . . . . . . . . . . . . . Dispositivo display 7 segmentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de funcionamiento USB4bot. . . . . . . . . . . . . . . . . . . . . . . . . Imagenes de la construccin y vericacin del USB4bot. Evento Sumo.uy 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Idea de asincronismo de futuro

Wireless USB Hub (F5U302) de Belkin . . . . . . . . . . . . . . . . . . . . . . . .

ndice de cuadros
4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 5.1. 5.2. 5.3.

USB4all rmware. Handler Manager . . . . . . . . . . . Interfaz del Dynamic Polling . . . . . . . . . . . Interfaz del Dynamic ISR . . . . . . . . . . . . . Interfaz de un User Module . . . . . . . . . . . . Interfaz de los Interrupt Proxies. . . . . . . . . . Interfaz de los Polling Proxies. . . . . . . . . . .
Caractersticas del diseo del Interfaz del Interfaz del componente

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51 53 54 55 56 60 61 68 69 72 73 73 74 75 75 77 78 79 82 83 83 85

u4aAPI.

. . . . . . . . . . . . . . . . . . . . . . . . . . .

iHandlerLayer . . . . 5.4. Operaciones de la interfaz iAdminHandlerLayer. 5.5. Interfaz de la clase HandlerPackager. . . . . . . . 5.6. Interfaz de la clase ModuleMap . . . . . . . . . . 5.7. Operaciones de la interfaz iCommandLayer . . . 5.8. Interfaz de la clase CommandPackager. . . . . . 5.9. Operaciones de la interfaz iDescriptorLayer . . . 5.10. Operaciones de la interfaz iDriverLayer. . . . . . 5.11. Operaciones de la interfaz iPlatformLayer. . . . . 5.12. Operaciones de la clase USB4allBaseboard. . . . . 5.13. Operaciones de la clase abstracta USB4allDevice 5.14. Operaciones de la clase abstracta USB4allDevice
Operaciones de la interfaz

Detalle de las operaciones del componente

u4aAPI.

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.15. Interfaz para el intercambio de conguracin entre el driver y la aplicacin.

13

14

NDICE DE CUADROS

Parte I

Generalidades

15

Captulo 1

Introduccin
En los primeros meses del ao 2006 las inquietudes personales de los miembros del grupo motivaron la gestacin de la idea bsica del proyecto que nalmente deriv en la presentacin como propuesta del mismo. En un comienzo se contaba con muchas ideas muy ambiciosas pero con muy pocos conocimientos sobre la mayora de las reas involucradas. Ms all de las limitaciones de conocimientos y la amplitud de las reas a investigar se pens que era un buen desafo para realizar como proyecto de grado. Gracias a los tutores que en su momento notaron la viabilidad de la idea y la apoyaron, se present una propuesta ante la Comisin de Proyectos que posteriormente fue aprobada. De inmediato se destino la totalidad del tiempo al aprendizaje de las tecnologas relacionadas para poder contar con un conocimiento bsico con que realizar un relevamiento del estado del arte adecuado. Esto fue una tarea muy exigente y requirio ms tiempo del planicado pero permiti seleccionar y plasmar de mejor manera todas las ideas generales que se tenan al comienzo del proyecto en un conjunto inicial de requerimientos.

1.1.

Motivacin

Durante muchos aos la nica forma de interactuar con dispositivos externos desde a un computador personal (Personal Computer) (PC) fueron los puertos seriales y paralelos, esto llevo a que se utilizaran ampliamente en multiplicidad de dispositivos. Sus principales carcteristicas son su simplicidad de manejo va software y facilidad de inclusin en distintos dispositivos. En la ltima dcada han aparecido nuevos medios o canales de comunicacin, tales como Bluetooth, Fidelidad Inalmbrica (Wireless Fidelity) (WiFi), FireWire, Bus Universal en Serie (Universal Serial Bus) (USB), etc. Estos permitieron mejorar las velocidades de comunicacin y calidad de datos y lentamente tornaron a los puertos paralelos y seriales en obsoletos, hasta llegar al da de hoy en que se obtienen slo de manera opcional en los nuevos PC. Dentro de todas estas nuevas tecnologas que aparecieron la que tuvo mayor aceptacin y difusin entre los usuarios fue el USB, debido a su facilidad y versatilidad de escenarios de uso. Esta simplicidad desde el punto de vista del usuario de los dispositivos USB tiene como contrapartida una mayor complejidad para los desarrolladores de software y hardware, lo cual es un gran problema al momento de interactuar con dispositivos electrnicos. Frente a estas adversidades que presenta el entorno actual aparece la necesidad de buscar una forma de reducir el grado de complejidad y conocimientos necesarios para poder desarrollar software que utilice la tecnologa USB. Al mismo tiempo, se requiere una plataforma base que incorpore componentes de hardware reutilizables y que en conjunto formen una solucin genrica para la comunicacin con dispositivos electrnicos diversos. En el contexto de lo antedicho aparecen un conjunto de desafos como son el desarrollo de controladores (drivers) y construccin de piezas de hardware que brinde una solucin genrica reutilizable, desplazando el manejo de los casos particulares a componentes especcos. Esto proporciona el benecio de evitar que cada vez que se necesite conectar un nuevo dispositivo, se comience desde cero. A su vez permite recuperar y potenciar la caracterstica de facilidad de manejo que posean los puertos seriales y paralelos, explotando todas las capacidades brindadas por USB. 17

18

CAPTULO 1.

INTRODUCCIN

Otra motivacin importante que posee este proyecto es poder construir sistemas que se basen en la conjuncin de dispositivos electrnicos simples con las capacidades de procesamiento, almacenamiento y comunicacin de los PC actuales de forma de poder resolver una gran variedad de situaciones complejas y distintas, centrando principalmente la coordinacin de las actividades en el PC.

1.2.

Qu es el proyecto?

Es una solucin a la necesidad de comunicar de forma sencilla y genrica dispositivos electrnicos no necesariamente pensados para interactuar con un PC, la solucin se basa en tres puntos: un componente de hardware, un medio de comunicacin (USB), una arquitectura conformada por software, rmware, un pila de protocolos de comunicacin y un driver USB genrico. El componente de hardware es una interfaz o adaptador que permite comunicar los dispositivos externos con el PC, se busca que sea lo ms abarcativo posible de forma de permitir la conexin de un gran nmero de dispositivos como son: sensores, actuadores, conversores analgico digital (Analog Digital Conversor) (ADC), conversores digital analgico (Digital Analog Conversor) (DAC), robots, etc. Adems de utilizar interfaces seriales estndar, tambin se desea la facilidad de poder denir interfaces propias, para ello el hardware no tiene predenido conectores para un puerto serial u otra interfaz sino que posee un nico conector genrico congurable dinamicamente por software. Como se mencion en la seccin 1.1, la seleccin de la tecnologa USB como medio de comunicacin se debe adems de lo ya descripto, por su disponibilidad actual en todos los PC, sus caractersticas enchufar y listo (Plug and Play) y enchufado en caliente (Hot Plug) para la conguracin y conexin (evitando el la necesidad de desarmar el PC para agregar un nuevo dispositivo). La arquitectura es lo que permite integrar los componentes de hardware y la tecnologa USB para lograr el comportamiento deseado. Una de sus cualidades ms importante es que permite ocultar las complejidades de la comunicacin USB y brindar al programador de aplicaciones una manera sencilla de interactuar con los dispositivos por medio de lenguajes de alto nivel. Para lograr sto, es necesario contar con un protocolo que facilite y estandarice la comunicacin, un driver USB que permita manejar el traco de informacin en forma genrica, un rmware que habilite el procesamiento y toma de decisiones sobre el comportamiento de los dispositivos en el propio hardware, una interfaz de programacin de aplicaciones (Application Programming Interface) (API) que brinde las funcionalidades mnimas para interactuar con los dispositivos y una biblioteca en lenguaje orientado a objetos que permita el rpido y fcil uso de la solucin. Se busca que la arquitectura sea modular y extensible de manera de permitir una administracin sencilla de los componentes de rmware encargados del manejo de los dispositivos, logrando de sta forma la fcil adecuacin de la solucin para el uso con nuevos dispositivos. Lo antedicho permite la reutilizacin de funcionalidades ya implementadas (dependiendo de las caractersticas de los dispositivos) en la construccin mediante composicin de nuevas soluciones. Todos estos atributos permiten que el usuario programador se concentre en la interaccin con el dispositivo electrnico y no en la forma o medio de comunicacin.

1.3.

Que no es el proyecto

Durante el desarrollo de este proyecto fueron apareciendo un conjunto de conceptos errneos sobre el alcance y caractersticas de uso de la solucin, a continuacin intentaremos detallar que elementos no forman parte de la solucin construida.

No es un adaptador USB:

En general la solucin se subestima pues se entiende que

simplemente es una especie de adaptador USB a una interfaz especca como son la serial o paralela. Esto es totalmente errneo, ya que si fuera un adaptador se perdera la generalidad y parte de las prestaciones USB adems de no poder incorporar funcionalidades especcas para el manejo de los dispositivos en dicho hardware. Adems se obligara a que todo el procesamiento de la interaccin con los dispositivos fuera desde el PC y reducido a un nico tipo de interfaz, es decir no se podran interactuar con un motor paso a paso serial y un termmetro de interfaz inter-circuitos integrados (Inter Integrated Circuit) (I mismo tiempo.

C)

al

1.4.

OBJETIVOS

19

No es un hub USB:

Este proyecto apunta a permitir la conexin de dispositivos que

no poseen la interfaz USB en forma nativa, pues seria un contrasentido conectarlos por medio de nuestra solucin y no en rma directa. Adems se perdera todo el soporte de drivers estndar y aplicaciones de uso general que ya vienen con los sistemas operativos que soportan USB.

No es un dispositivo especco:

Una de las motivaciones de este proyecto es poder

interactuar con la mayor cantidad posible de dispositivos electrnicos, los cuales poseen distintas necesidades de conexin e interfaces. Si se tomara partido por algunos tipos de dispositivos se limitara el alcance del uso de la solucin, lo que no es deseado. Adems, tampoco se busca que la solucin sea una especie de plataforma para la construccin de dispositivos USB especcos como pueden ser mouses, memorias o cmaras web pues los sistemas operativos no podran reconocerlos como tales.

No es slo hardware: Lo primero que se atina a pensar cuando se ve la solucin es que

es una pieza de hardware que resuelve toda la problemtica, pero en realidad la solucin es ms amplia pues incluye un rmware que ejecuta en el componente de hardware y un software que funciona como contraparte en el PC. Su accionar en forma conjunta es lo que permite dar respuesta a las necesidades planteadas.

No es necesario crear un driver para cada dispositivo: La utilizacin de un driver

USB genrico y de una arquitectura abierta y extensible que permite la incorporacin de funcionalidad especca para el manejo de cada dispositivo por medio de la programacin en alto nivel de su comportamiento, evita la creacin de drivers particulares para cada uno de ellos.

1.4.

Objetivos

El objetivo principal de este proyecto es poder interactuar con dispositivos electrnicos no necesariamente pensados para ser usados desde un PC por medio de una solucin que conjuga: un hardware base reutilizable, una arquitectura de software modular y extensible y el medio de comunicacin USB. A continuacin se detallan un conjunto de objetivos ms especcos que logran satisfacer el objetivo principal previamente descrito: Disear e implementar un hardware en forma de una placa base que resuelva la problemtica de la comunicacin USB con el PC y brinde una interfaz para conectar los dispositivo electrnicos. Disear e implementar una arquitectura de software modularizada y extensible que permita denir en el rmware de la placa base sus caractersticas fsicas, los protocolos de comunicacin y las funcionalidades especcas para la interaccin con cada dispositivo. En el PC se cuente con una API para la interaccin con el hardware y con una biblioteca de clases orientadas a objetos para la integracin con aplicaciones de alto nivel. Construir un diseo que permita que la solucin sea multiplataforma, priorizando su implementacin para Windows y Linux. Disear y construir un driver genrico USB propio modo ncleo. Desarrollar un conjunto de utilitarios para la conguracin de la placa base y carga de los mdulos de manejo especco de dispositivos por medio del USB. Ocultar la complejidad USB sin perder las cualidades inherentes, la tecnologa USB es ms compleja que las soluciones serial o paralela, por lo tanto es vital poder ocultar la complejidad de esta interfaz para que el usuario se preocupe solamente de la problemtica de la interaccin con el dispositivo y no en la forma en que se comunica.

para la plataforma Linux que corra en

1 Se entiende por driver genrico aquel que puede obtener la informacin propia del dispositivo, enviar y recibir datos.

20

CAPTULO 1.

INTRODUCCIN

Construir un caso de uso (prototipo) relevante que permita mostrar las cualidades funcionales y tcnicas de la solucin implementada. La solucin debe poseer un modo de funcionamiento extra (modo fachada) simulacin del comportamiento de un dispositivo USB especco.

que permita

reutilizar los drivers y aplicaciones de usuario ya existentes en el PC por medio de la

1.5.

Organizacin del documento

y Resultados,

Este documento est organizado en tres partes: adems de los apndices:

Glosario

Generalidades, Arquitectura y Experimentos Herramientas. Esta organizacin pretende

en primer lugar hacer una introduccin al proyecto y a las tecnologas utilizadas, para luego centrarse en los distintos elementos y caractersticas de la arquitectura de software y nalmente presentar los productos construidos as como las conclusiones y trabajos a futuro que deja el proyecto.

En la parte Generalidades del documento se encuentran los captulos:

Captulo 1 - Introduccin:
ciones, objetivos y alcance. Se presenta como fue la gestacin del proyecto, sus motiva-

Captulo 2

Resumen del Estado del Arte:

Las reas que involucran este proyecto

son diversas pero las que se presentan en este captulo son las ms relevantes para sentar las bases de conceptos bsicos y vocabulario. Comienza mostrando la tecnologa USB por medio de su topologa, caractersticas de comunicacin (velocidades, tipos de transferencias, etc.), proceso de enumeracin y jerarqua de dispositivos estndar. Luego se describen las caractersticas principales de los modelos de drivers de las plataformas Windows y Linux y presentan algunas de las opciones existentes actualmente. Tambin se analizan algunas de las opciones de conectividad USB, contrastando sus caractersticas y prestaciones, para luego justicar la seleccionar de una de ellas en la implementacin del hardware del proyecto. Por ltimo se comentan algunos proyectos relacionados mostrando sus ventajas y falencias. Cabe destacar que las imagenes utilizadas en este captulo son extraidas de los documentos, artculos y libros citados en la bibliografa del documento Estado del Arte [2].

En la parte Arquitectura del documento se encuentran los captulos:

Captulo 3
-

Introduccin:

Se presentan los elementos fsicos de la solucin as como

los componentes de la arquitectura de software.

Captulo 4 - Arquitectura

en el Baseboard: Se detallan los componentes electrnicos

(microcontrolador, conectores, relojes, etc.) que constituyen el hardware base de la solucin. Adems se introducen los distintos elementos de rmware que permiten la comunicacin y manejo de los dispositivos, esta presentacin abarca no slo la descripcin a nivel de diseo de los componentes sino que tambin se explica brevemente como es el proceso de programacin y conguracin del rmware del hardware base.

Captulo

5 -

Arquitectura en el PC:

Se detallan los elementos que conforman la

arquitectura de software de la solucin en el PC, presentando sus principales caractersticas funcionales y diseo detallado. Tambin se presenta el diseo de una propuesta de clases base para facilitar el uso de la solucin desde un lenguaje orientado a objetos como es Java y por ltimo se explica las caractersticas ms importantes de un driver genrico implementado durante el proyecto.

Captulo 6 - Comunicacin: En este captulo se hace especial hincapi en la descripcin

del funcionamiento en conjunto de todos los elementos de la arquitectura de software, mostrando en detalle como es el ujo de ejecucin de sus principales funcionalidades, adems de presentar los protocolos de comunicacin que dene la solucin.

2 Este

objetivo se elimin posteriormente del alcance del proyecto, por ms detalles ir a la seccin 7.1.

1.6.

ETAPAS DEL PROYECTO

21

Captulo 7 - Decisiones

de diseo e Implementacin: Durante el desarrollo de este

proyecto fueron apareciendo distintas dicultades o alternativas al enfrentarse con ciertos temas y para los cuales se tuvo que tomar una postura, este captulo muestra las decisiones de diseo ms importantes que se tomaron justicando el porque de las mismas.

En la parte Experimentos y Resultados del documento se encuentran los captulos:

Captulo
8 -

Artefactos construidos:

Este captulo hace un repaso de los artefactos

de software y hardware que se fueron construyendo durante el desarrollo del proyecto. Se describen entre otras cosas, como fue evolucionando el hardware base de la solucin y los prototipos de dispositivos que se construyeron para su vericacin.

Captulo

9 -

Conclusiones y Trabajo a futuro:

Como cierre del documento se pre-

sentan las conclusiones del proyecto por medio de las caractersticas ms importantes de la solucin construida y de los aportes que brinda la misma. Como forma de cierre se describen posibles trabajos a futuro de este proyecto tanto en el rea de investigacin como de mejoras e incorporaciones de funcionalidades a las ya existentes. En los apndices del documento se encuentran el glosario de los trminos utilizados as como la descripcin de las herramientas utilizadas para la documentacin, noticacin y seguimiento de errores, publicacin de informacin del proyecto en la web, etc.

1.6.

Etapas del proyecto

Ao 2006
1/10 - 1/12 Ambiente Desarrollo 1/10 - 15/12 Construccin Baseboard 1/10 - 15/12 Diseo 1/3 - 1/5 Propuesta del proyecto 1/5 - 20/10 Estado del Arte

15/12 - 31/12 Vacaciones

Ao 2007
1/1 - 1/3 Licencia y Examen 1/3 - 1/5 Prototipado 1/5 - 1/7 Implementacin 1/7 - 1/8 Examen 1/8 - 9/11 Implementacin 1/8 - 25/11 Testing 1/8 - 10/12 Documentacin

1/3 - 1/7 Construccin BaseBoard 1/3 - 1/7 Diseo

Figura 1.1: Lnea de tiempo de las actividades del proyecto.

22

CAPTULO 1.

INTRODUCCIN

Captulo 2

Resumen del estado del arte

Este captulo tiene como objetivo introducir al lector en los conceptos ms relevantes necesarios para comprender el vocabulario utilizado a lo largo del documento, para profundizar ms en estos temas, se puede consultar el documento de estado del arte [2].

2.1.

USB

En esta seccin se brinda un resumen sobre los conceptos ms importantes de la tecnologa USB, los cuales sirven para poder comprender todos lo conceptos que se desarrollarn en los siguientes captulos de este documento. Para profundizar ms sobre estos conceptos se puede consultar la bibliografa relacionada [7, 5, 24, 15]

2.1.1. Caractersticas generales

El USB es un estndar [15] que dene un bus utilizado para conectar perifricos a el PC. La principal caracterstica que tiene es que la conexin es muy sencilla, ya que utiliza un nico conector para conectar a travs de un bus serie todos los dispositivos. En l se denen los conectores y los cables, una topologa especial tipo estrella para conectar hasta 127 dispositivos y protocolos que permiten la deteccin y conguracin automtica de los dispositivos conectados. USB 1.0 soporta dos tasas de transferencia diferentes, una baja de 1,5 Mbps para la conexin de dispositivos lentos de bajo coste (joysticks, ratones) y otra alta de hasta 12 Mbps para la conexin de dispositivos que requieren un mayor ancho de banda (discos o CD-ROMs). A mediados del ao 2000 aparece la versin 2.0, que multiplica la velocidad del bus por un factor de 30 o 40, llegando a alcanzar una velocidad de 480 Mbps, con una diferencia de costo casi inapreciable. Es compatible con la versin anterior y utiliza los mismos cables y conectores, nicamente se necesitan nuevos concentradores (Hubs) que soporten la versin 2.0. Estos hubs son algo ms complejos que los anteriores, ya que tienen que manejar el trco de datos de tres velocidades distintas sin ser excluyentes entre ellas. Cabe tambin destacar que USB 2.0 nunca llegar a reemplazar completamente a USB 1.0, ya que existen algunos tipos de dispositivos, como los dispositivos de interfaz humana (human interface devices) (HID) (teclados, ratones y joysticks)[17], que no requieren las altas velocidades que alcanza esta nueva versin y que nicamente encareceran el dispositivo. Anteriormente los perifricos se conectaban mapeados directamente en direcciones de entrada/salida (E/S), se les asignaba una direccin especca y en algunos casos un canal de acceso directo a memoria (direct memory access)(DMA). Esta situacin conduca a tener conictos en la asignacin de estos recursos, puesto que siempre han estado bastante limitados en el ordenador. Adems cada dispositivo tena su propio puerto de conexin y utilizaba sus cables especcos, lo que daba lugar a un incremento de los costos. Debido a que a cada dispositivo se le tenan que asignar unos recursos especcos la deteccin del mismo deba hacerse a la hora de arrancar el sistema y nunca se poda incorporar un nuevo dispositivo cuando el sistema estaba en marcha. Los dos aspectos fundamentales que motivaron la realizacin de este estndar fueron la necesidad de congurar de forma sencilla los perifricos conectados al ordenador y la necesidad de aumentar el nmero de puertos disponibles. 23

24

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Este estndar dene una topologa de conexin en estrella, tal como se muestra en la gura 2.1, por medio de la incorporacin de varios hubs conectados en serie. Cada concentrador se conecta por un lado al ordenador, que contiene una o dos interfaces de este tipo en la placa base, o a otro hub y, por otro lado, se conecta a varios dispositivos o incluso a otro hub. De este modo pueden existir perifricos que vengan ya preparados con nuevos conectores USB para incorporar nuevos dispositivos, hasta un total de 127, todos ellos funcionando simultneamente. Los hubs tienen la misin de ampliar el nmero de dispositivos que se pueden conectar al bus. Son concentradores cableados que permiten la conexin simultnea de mltiples dispositivos y lo ms importante es que se pueden concatenar entre s ampliando la cantidad de puertos disponibles para los perifricos. El hub detecta cundo un perifrico es conectado o desconectado a/de uno de sus puertos, noticndolo de inmediato al controlador de USB. Tambin realiza funciones de acoplamiento de las velocidades de los dispositivos ms lentos. Existe una gran variedad de dispositivos USB que se conectan todos al mismo bus. La caracterstica ms importante es que todos ellos utilizan el mismo tipo de cable y de conector y se conectan de la misma forma tan sencilla. El host decide qu dispositivo puede acceder al bus.

USB Host Controller Virtual Root Hub

Device

Hub

Device

Device

Hub

Device

Device

Figura 2.1: Topologa tipo estrella

Figure 1: USB Topology

Desde el punto de vista lgico un dispositivo (comnmente llamado funcin) posee un conjunto de endpoints, los que le permiten enviar y recibir datos. Un conjunto de endpoints forma parte de concepto de mayor abstraccin llamado interfaz y es el que va a especicar cuales son las caractersticas de comunicacin de un dispositivo.

2.1.2. Transferencias
USB est diseado para manejar distintos tipos de perifricos con una gran variedad de requerimientos como lo son la frecuencia de transferencia, tiempo de respuesta y correccin de errores. El estndar dene cuatro tipos de transferencias las que manejan diferentes necesidades. De esta manera los dispositivos pueden utilizar los tipos de transferencias que mejor se adecuen para sus propsitos. Las transferencias de

control, son las nicas que tienen funciones denidas por la especi-

cacin USB. Permiten al host leer informacin acerca del dispositivo, asignarle una direccin, seleccionar conguraciones y otras caractersticas. Tambin pueden enviar pedidos especcos del vendedor. Todos los dispositivos USB deben soportar este tipo de transferencias. Las transferencias

bulk estn pensadas para situaciones donde la latencia de la transferencias

no es crtica, como enviar un archivo a una impresora, recibir datos de un scanner, o acceder

Downstream

Upstream

2.1.

USB

25

a un archivo en un disco. Para estas aplicaciones son llamativas las transferencias rpidas pero los datos pueden esperar si es necesario. Si el bus est muy ocupado las transferencias bulk son retardadas, pero si el bus est libre son muy rpidas. Slo los dispositivos full y high speed pueden hacer transferencias bulk. Las transferencias

interrupt son para dispositivos que deben la atencin del host o dispoisochronous

sitivos peridicamente. Aparte de las transferencias de control, son la nica forma de transferir datos para los dispositivos low-speed. Teclados y mouses utilizan este tipo de transferencias para enviar informacin. Las transferencias tienen un tiempo de envo garantizado, pero no poseen

control de errores. Son usadas para transmitir datos multimedia en aplicaciones de tiempo real. Es el nico tipo de transferencia que no soporta retransmisin de datos recibidos con error. Slo los dispositivos full y high speed pueden utilizarlas.

2.1.3. Descriptores
Los descriptores USB son estructuras de datos, o bloques de informacin con formato, que le permiten al host aprender acerca de un dispositivo. Cada descriptor contiene informacin acerca del dispositivo como un todo o un elemento del dispositivo como puede verse en la gura 2.2. Todos los dispositivos USB deben responder a pedidos para los descriptores USB estndar. El dispositivo THE UNIVERSAL SERIAL BUS 1 debe guardar informacin de los descriptores y responder a sus pedidos. 7

Device Descriptor

Configuration 1

Configuration 2

Interface 0 AS0

Interface 1 AS1

Interface 0 AS0

Interface 0 AS1

Interface 1 AS0

Endpoint 1

Endpoint 2

Endpoint 3

More Endpoint Descriptors

Figure 2: Jerarqua de Descriptores Figura 2.2:USB Descriptor Hierarchy

2.1.4. Enumeracin
Antes de que las aplicaciones puedan comunicarse con un dispositivo, el host necesita aprender acerca de los dispositivos y asignarle un driver. La enumeracin es el intercambio de informacin que acompaa a estas tareas. El proceso incluye asignacin de una direccin para el dispositivo, lectura de descriptores desde el dispositivo, asignacin y carga de un driver, y seleccin de una conguracin que especique los requerimientos de consumo de energa, endpoint y otras caractersticas. El dispositivo luego est listo para transferir datos usando cualquiera de los endpoints asignados en su conguracin.

2.1.5. Jerarqua de clases

Cuando un grupo de dispositivos o interfaces comparten muchos atributos o proveen o requieren de servicios similares, tienen sentido denir los atributos y servicios en una especicacin de clase. Como es el caso de las clases HID que dene dispositivos de interaccin con una persona como lo son teclados, mouses, joysticks, etc o la clase de instrumentos musicales de interfaz digital (musical instrument digital interface) (MIDI) [16] que dene instrumentos. Los sistemas operativos pueden proveer drivers para las clases en comn, eliminando la necesidad de que los vendedores de dispositivos tengan que proveer los drivers para los dispositivos en esas clases.

26

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Cuando un dispositivo en una clase soportada tiene una caracterstica nica o habilidades no incluidas en el driver, se puede proveer un driver de ltro para mantener las caractersticas agregadas y las habilidades, en lugar de escribir un driver completo. Una especicacin de clase puede denir valores para los tems en los descriptores estndar, como tambin descriptores class-specic.

2.1.6. Funcionamiento:
Los dispositivos tienen asociados canales lgicos unidireccionales, llamados pipes, que conectan al host controlador con una entidad lgica en el dispositivo llamada endpoint. Los datos son enviados en paquetes de largo variable. Tpicamente estos paquetes son de 64, 128 o ms bytes. Los endpoints y sus respectivos pipes, son numerados del 0 al 15 en cada direccin, por lo cual un dispositivo puede tener hasta 32 endpoints (16 de entrada y 16 de salida). La direccin se considera siempre desde el punto de vista del host controlador. As un endpoint de salida ser un canal que transmite datos desde el host controlador al dispositivo. Un endpoint solo puede tener una nica direccin. El endpoint 0 (en ambas direcciones) est reservado para el control del bus.

Figura 2.3: Comunicacin virtual entre un dispositivo y el host

Cuando un dispositivo es conectado al bus USB, el host controlador le asigna una direccin nica de siete bits (mediante el proceso de enumeracin) que es utilizada luego en la comunicacin para identicar el dispositivo. Luego, el host controlador consulta continuamente a los dispositivos para ver si tienen algo para enviar, de manera que ningn dispositivo puede enviar datos sin la solicitud previa explcita del host controlador. Para acceder a un endpoint se utiliza una conguracin jerrquica de la siguiente manera: un dispositivo (llamado funcin) conectado al bus tiene un nico descriptor de dispositivo, quien a su vez tiene uno (o varios) descriptores de conguracin. Estos ltimos guardan generalmente el estado del dispositivo (ej: activo, suspendida, ahorro de energa, etc). Cada descriptor de conguracin tiene uno (o ms) descriptores de interfaz. Y stos ltimos nalmente son los que contienen los endpoint, que a su vez pueden ser reutilizados entre varias interfaces (y distintas conguraciones) como muestra la gura 2.2.

2.2.

Opciones de conectividad USB

Debido a que los objetivos de este proyecto incluyen el desarrollo de un hardware, se debieron relevar las soluciones de conectividad USB entre el hardware a construir y la PC. Si bien hay muchos tipos de soluciones realizadas por un varios productores de semiconductores, luego de hacer un relevamiento se pudo realizar una categorizacin de ellas. Dentro de estas categoras, slo se dejaron aquellas que no eran kits de desarrollo, y se muestran a continuacin:

2.2.

OPCIONES DE CONECTIVIDAD USB

27

Transceivers USB Conversores USB a serial o paralelo Controladores de perifricos

Externos Embebido en un microcontrolador

Se realiz una primera aproximacin a todas las soluciones y luego se profundiz en aquellas que eran ms apropiadas para los requerimientos de este proyecto, priorizndose aquellas en las cuales era posible conseguir muestras gratis. A continuacin se brinda un breve resumen de cada una las categoras relevadas, seleccionando para ello algunos representantes de cada una de ellas.

2.2.1. Transceivers USB

La principal responsabilidad de los transceptores (transceivers) USB es encapsular la capa fsica y realizar una interfaz con otros dispositivos programables. Esto slo incluye una traduccin de los voltajes que codican la transmisin de informacin en dos seales D+ y D-, a un conjunto de seales para su posterior procesamiento de capas superiores realizadas por otros dispositivos. En las capas superiores se debe realizar un manejo de transacciones y endpoints, entre otros. De esta forma estos son dispositivos muy simples, que a los sumo incorporan reguladores de voltaje, y detectores de conexin, lo que los hace muy baratos. Como representantes de esta categora se seleccionaron el que convierte.

USB1T20

de

Fairchild,

y el

Philips ISP110x.

En la gura 2.4 se

muestra un diagrama lgico de las seales que traduce y la tabla de verdad de los valores lgicos

Figura 2.4: Diagrama lgico y tabla de verdad del Transceiver USB

2.2.2. Conversores USB a interfaz serial o paralela

Otra de las posibilidades existentes para facilitar la conectividad entre el PC y un hardware va USB es mediante el uso de conversores. La idea aqu, es que el conversor funciona como una caja negra, en donde uno de los extremos de la interfaz utilizada es USB y en el otro es serial o paralelo, segn el conversor en cuestin. De esta forma, para el hardware que se desea conectar es transparente la forma en que los datos llegan al PC. Si se hace la analoga con conectividad en redes, podra pensarse que se crea un tnel entre el Host USB y el conversor por donde pasa la informacin de la interfaz del hardware externo. El conversor es visto en general por el PC como un puerto serial y as lo utilizan tambin las aplicaciones de usuario. El representante elegido en este caso es el

FT232BM

de

FTDI

y su diagrama en bloques se muestra

en la gura 2.5. Los componentes ms importantes de izquierda a derecha son: el transceiver USB, el motor de interfaz serial (serial interface engine)(SIE), el motor de protocolo USB y el transmisor-receptor asncrono universal (universal asynchronous receiver-transmitter)(UART). Del transceiver ya se ha hablado con anterioridad, el SIE junto con el motor de protocolos USB tiene la responsabilidad de manejar transferencias en endpoints predeterminados por la interfaz

28

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Figura 2.5: Diagrama en bloques del FT232

CDC. Luego el componente controlador UART FIFO, que con ayuda de los buers de memoria compartida realizan las transferencias de datos con el Host USB. Este componente tambin sirve para setear la conguracin del UART (velocidad, paridad, etc). Finalmente a la derecha de la gura se encuentra el UART que es donde se conecta el hardware va una interfaz serial.

Otras caractersticas que tiene este conversor son:

Cumple con el estndar USB 2.0 (Full speed) Velocidad de 300 a 3M bauds Manejo de handshaking y seales de modem. Bit Bang mode: Transforma las seales de control en puerto de E/S de 8 bits. Interfaz con EEPROM para caracterizar VID, PID, etc. Drivers de puerto COM virtual para Windows, MacOS y Linux.

2.2.3. Controladores de perifricos

Estos dispositivos incorporan un transceiver USB y la lgica para el manejo del protocolo. En estos es congurable adems un nmero variable de endpoints y tipos de transferencias, as como tambin descriptores de dispositivo, interfaz, VID, PID, etc. Pueden encontrarse en dos modalidades: externos o embebidos en un microcontrolador. Teniendo en cuenta los requerimientos que se tenan para el proyecto de grado, resultaba ms atractivo el uso de estas soluciones por sobre las estudiadas en las secciones 2.2.1 y 2.2.2. A continuacin se describen algunas de sus principales caractersticas, pero un estudio ms completo de todos los chips o microcontroladores que se comentan en esta seccin se encuentra en el documento de Estado del Arte [2].

2.2.

OPCIONES DE CONECTIVIDAD USB

29

2.2.3.1. Controladores de perifricos externos

Estos dispositivos, como ya dijimos, manejan las comunicaciones USB al nivel de transacciones y endpoints y adems es visto como otro perifrico ms para los microcontroladores o microprocesadores con los cuales interactan. Vale la pena aclarar que estos dispositivos no son autnomos sino que deben interactuar con microcontroladores o microprocesadores para realizar parte de sus tareas, a diferencia de los conversores que se presentaron en la seccin 2.2.2. Una de las ventajas ms importantes que tiene, es el poco impacto que causa su aplicacin en sistemas ya existentes, es decir, si se quiere agregar la funcionalidad a un dispositivo ya existente en un microcontrolador, slo hay que agregar rmware necesario para el manejo del USB y no migrar todo a otra solucin que utilice un controlador de perifricos embebido. En esta seccin se tom como representante el ISP1581 de Philips. A continuacin se presentan las principales caractersticas relacionadas con la conectividad USB: Cumplen con el estndar USB 2.0 y soporta velocidades high y full. 7 Endpoints de entrada, 7 de salida. Soporta double buer. Soporta todos los tipos de transferencias 8Kb de memoria FIFO integrada. Interfaces con un microcontrolador:

Interfaz de bus independiente para la mayora de los microcontroladores/microprocesadores (12.5 MByte/s) Interfaz DMA de alta velocidad (12.8 Mbyes/s) Interfaz directa con perifricos ATA/ATAPI

Conexin al bus USB controlada por software (SoftConnect tm) Data transceiver y regulador de voltaje de 3.3 V integrados

2.2.3.2. Controladores de perifricos embebidos

En este tipo de soluciones, se incorpora dentro del mismo microcontrolador el hardware necesario para conectarse directamente al Host USB. Brinda las mismas funcionales que el controlador de perifricos externo pero con algunas diferencias. Normalmente es utilizado como un perifrico ms y utiliza registros dedicados y un tipo de memoria especial, a veces llamada RAM de doble puerto (Dual Port RAM) para intercambiar informacin con el microcontrolador, adems de un poseer una rama completa de interrupciones asociadas a los eventos USB. La comunicacin en los casos relevados se maneja a nivel de endpoints y el manejo de transferencias es manejado por rmware con el soporte de hardware de este perifrico especial, comnmente conocido como SIE. Una desventaja que genera el hecho de que se utiliza un recurso embebido en un microcontrolador, es que se genera una dependencia con la arquitectura ste. Esta opcin amerit tener un relevamiento ms completo que los anteriores, debido a que fue evaluado como la opcin ms adecuada para los requerimientos del proyecto y que una decisin en favor de una u otra opcin poda tener consecuencias importantes. Los dispositivos relevados fueron: TSUB3210 de Texas Instruments PIC18F4550 de Microchip AT90USB1287 de Atmel En este caso se presenta el cuadro 2.6 que muestra un comparativo con los aspectos considerados relevantes a la hora de realizar una seleccin del dispositivo a utilizar para el proyecto. Las caractersticas detalladas de cada uno de estos microcontroladores se encuentran en el documento de Estado del Arte [2].

30

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Arquitectura Velocidad Package Memoria de programa Memoria datos USB 2.0 (full y low speed) Eeprom Modo Bajo Consumo Pines de E/S Timers I2C SPI USART Canales PWM A/D Otros

TUSB3210 CISC (8052) 12 Mhz TQFP 64 *6K ROM, 8K RAM (Firmware) 768 bytes 512 Bytes compartida, 3 endp IN, 3 OUT. transferencias interrupt y bulk no Si Hasta 36 3 de 16 bits Master No No No No Bootloader I2C o USB, niveles de prioridad en interrupciones, soporte multiproducto Poca, algunas notas de aplicacin.

PIC18F4550 Harvard RISC 75+8 inst 48 Mhz TQFP 44, QFN 44, DIP 40 32Kb Flash autoprogramable por software 2 Kb 1024 Bytes compartida, hasta 32 endp con ping pong buffering, soporta todas las transferencias 256 bytes NanoPower, 3 modos Sleep Hasta 35 1 de 8 bits 3 de 16 bits Master/Slave Master/Slave Si Hasta 2 de 10 bits de resolucion 13 canales 10 bits Soporte bootloader, prioridad de interrupciones programables, multiplicador por hardware, 2 comparadores analgicos, Streaming Paralel Port. ICSP e ICD Bloqueo de secciones de mem. Mucha, recursos en la web, muchas notas de aplicacin, framework USB MPLAB, 3ras partes, varios compiladores

AT90USB1287 Harvard RISC 135 inst 16 Mhz TQFP 64, QFN 64 128Kb Flash autoprogramable por software 8 Kb (hasta 64 KB externos) 832 bytes compartida, 6 endpoints con ping pong buffering, soporta todas las transferencias 4 Kbytes Si, 6 Modos Sleep Hasta 48 2 de 8 bits 2 de 16 bits TWI* Master/Slave Master/Slave Si Hasta 6 de 2-16 bits de resolucion 8 canales 10 bits Soporte bootloader, vector de interrupciones con prioridad fija, multiplicacion por hardware, mparadores analgicos,modos bajo consumo, USB OTG,Bloqueo de secciones de mem. JTAG. Poca, Framework USB, algunas notas de aplicacin. AVR Studio 4, 3ras partes

Documentacin

Entornos de desarrollo En general los de 8052, de 3eras partes, algunos gratuitos. y compiladores

Figura 2.6: Cuadro comparativo de los microcontroladores

2.2.4. Decisiones tomadas

Luego de evaluar las posibilidades con que se cuenta para brindar conectividad USB al hardware que se desea construir, se decidi que la opcin ms adecuada para este proyecto era utilizar microcontroladores con controladores de perifricos USB embebidos. Esta eleccin se realiz teniendo en cuenta que los conversores USB a serial o paralelo no permiten el grado de generalidad en la conguracin requerido ya que utilizan una interfaz de dispositivo USB ja que no puede modicarse, ni tampoco los tipos de transferencias que maneja. Adems, tambin debemos considerar que las dems opciones no eran totalmente autnomas, ya que de todas formas precisaban un microcontrolador para el manejo del protocolo USB. Tambin vale la pena resaltar que ya desde una primera instancia era atractivo el uso de un microcontrolador para lograr cumplir con requerimientos de facilidad de conguracin y manejo de dispositivos electrnicos diversos ya que iban a simplicar notoriamente el hardware. Realizada esta eleccin lo que restaba era seleccionar alguna de las opciones relevadas. Lo primero que se not fue que el microcontrolador TSUB3210 brindaba pocas prestaciones en cuanto a perifricos que soportaba de manera embebida, as como pocos recursos y baja velocidad de USB en comparacin con los otros dos. Eso motiv que la eleccin quedara entre el PIC18F4550 y el AT90USB1287 y para ello se tuvieron en cuenta los siguientes criterios: Aspectos Tcnicos: el AT90USB1287 en general en sus recursos disponibles de hardware es superior al PIC18F4550. Documentacin: Hay una mayor documentacin y notas de aplicacin disponible del PIC18F4550. Infraestructura y conocimientos previos:

Experiencia previa (materia Taller de rmware dictada en FING) Conocimiento de la arquitectura y herramientas de desarrollo por los integrantes del equipo. Hardware de programacin/debugging disponible. Kit de desarrollo PICDEM FS USB disponible (para experimentacin previa mientras no se realizara el hardware).

Disponibilidad y facilidad para soldar

PIC18F4550 disponible en la plaza uruguaya. PIC18F4550 disponible en package DIP40.

En funcin de los puntos que consideramos relevantes, si bien tcnicamente el AT90USB1287 es superior en muchos aspectos al PIC18F4550, hubo otros aspectos que tambin se tuvieron en

2.3.

DRIVERS

31

cuenta para la eleccin nal, como ser la documentacin, los conocimientos previos y disponibilidad en los que el PIC18F4550 era superior a la otra opcin. Finalmente, teniendo en cuenta estos aspectos se tom la decisin de usar el PIC18F4550 para la implementacin del hardware en este proyecto de grado.

2.3.

Drivers

En el contexto de este proyecto de grado, uno de las reas de conocimiento que se estudiaron fueron los distintos tipos de drivers de las plataformas Windows y Linux, as como las herramientas de construccin y depuracin de drivers. No todos los elementos estudiados se usaron posteriormente en el desarrollo del proyecto, solamente fueron aprovechados los conocimientos sobre el modelado de drivers en Linux y algunas herramientas de desarrollo como son LibUSB y MPUSBAPI Library de Microchip. Para un mayor detalle de todo lo relevado y estudiado (modelos de drivers y herramientas de desarrollo y depuracin de drivers), leer el documento Estado del Arte [2]. En las siguientes subsecciones se presentaran las herramientas utilizadas, junto con algunas otras herramientas de desarrollo y depuracin de carcter comercial que son muy usadas en la actualidad.

2.3.1. Herramientas de desarrollo

Con la aparicin del USB se han multiplicado la cantidad de perifricos que se pueden conectar a un PC, esto es debido entre otras cosas a la facilidad de uso y conguracin. Esta simplicidad se basa en una complejidad mayor a la hora de desarrollar un driver de un dispositivo, ya que se necesita tener conocimientos de como funciona la tecnologa USB, as como de los detalles internos del funcionamiento del sistema operativo. Durante el proceso de relevamiento del estado del arte se estudiaron las siguientes herramientas de desarrollo de driver USB: Windows DDK

Linux DDK

MPUSBAPI Library LibUSB LibUSB-Win32 jUSB y JSR80. Por ms detalle ver el documento del Estado del Arte [2]. A continuacin se presenta la herramienta ms usada a nivel comercial y las utilizadas en este proyecto.

WinDriver

KernelDriver

USBIO

RapidDriver

JCommUSB

2.3.1.1. Jungo Ltd. - WinDriver USB 8.02

WinDriver
es un juego de herramientas de desarrollo que simplica la creacin de drivers monolticos de dispositivos. Incluye un ambiente grco de desarrollo, API's, utilitarios de diagnstico y depuracin y ejemplos que permiten un rpido desarrollo de drivers de alto rendimiento.

Q: How does WinDriver work?

development time by enabling you to use your standard development

Figura 2.7: Arquitectura del WinDriver.

32

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Caractersticas
Soporta las especicaciones USB 1.x y 2.0. Se accede al hardware USB a travs de una aplicacin grca de usuario sin tener que escribir una sola lnea de cdigo. WinDriver posee un ayudante que genera un esqueleto del cdigo del controlador personalizado para un dispositivo en particular. El esqueleto del cdigo del controlador cumple con las caractersticas del WDM. Posee un ambiente grco para la depuracin, que permite monitorear los eventos y datos relacionados al driver. Adems de los dispositivos conectados directamente al PC, se pueden detectar dispositivos conectados por medio de un Hub USB. Se puede visualizar toda la informacin referente al dispositivo, como son los juegos de descriptores, nmero de serie, etc. Tipos de licencias y precios:

Node-Lock: Floating: 3-Pack:

USD 3.000

USD 6.000

USD 6.000

Requerimientos
Algunos de los sistemas operativos soportados: Windows 98, Windows ME, Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Linux y Linux Embedded 2.4 - 2.6 (x86 32-bit y 64-bit; IA64; Power PC 32-bit). Compiladores: GCC, cualquier otro compilador ANSI C, Borland Delphi, Visual Basic 6.0, Visual C#.Net, Visual Basic.Net. Se necesita un espacio libre en disco duro de entre 26 y 34 MB dependiendo del sistema operativo.

2.3.1.2. Microchip Technology Inc. - MPUSBAPI Library 1.0

Es una API que provee acceso al puerto USB a aplicaciones que funcionan en sistemas

(MCHPFSUSB),

operativos Windows. Forma parte del paquete gratuito

Microchip Full-Speed USB Solutions

que permite el desarrollo de aplicaciones de usuario y de rmwares para la

comunicacin con dispositivos USB, adems como parte del paquete cuenta con un driver USB de propsito general (clase Custom USB). Sus principales caractersticas son: Soporta los estndares USB 1.x y 2.0. Soporta el uso de 32 endpoints. La API es una biblioteca de vinculacin dinmica (DLL), para su fcil integracin a los proyectos de desarrollo. Soporta los sistemas operativos: Windows 98SE, Windows ME, Windows 2000 y Windows XP. Es una herramienta gratuita.

2.3.

DRIVERS

33

2.3.1.3. LibUSB 0.1.12

Es un proyecto GNU-LGPL desarrollado para sistemas operativos del estilo Unix y tiene como meta la creacin de una biblioteca que permita a aplicaciones de usuario poder comunicarse con dispositivos USB sin importar el sistema operativo. La versin estable de este proyecto es la 0.1.12 y fue diseada para tener una fuerte analoga con las especicaciones USB, sin embargo su implementacin es muy pobre debido a la existencia de mucho cdigo rgido (hardcode) lo que trae como resultado que se pierdan algunas caractersticas del diseo. Las principales caractersticas de este producto son: Fue diseado para soportar el estndar USB 1.x, aunque tambin puede soportar el 2.0. Los tipos de datos usan estructuras abstractas para mantener la portabilidad de representacin de la informacin. Soportan todos los tipos de transferencia y todas las peticiones estndar de la especicacin USB. Soporta los sistemas operativos: Linux, FreeBSD, NetBSD, OpenBSD, Darwin/MacOS X. Es una herramienta gratuita.

2.3.1.4. LibUSBWin32
Este proyecto es una migracin del proyecto

LibUSB

a la plataforma Windows, esta biblioteca

permite a las aplicaciones de usuario comunicarse con cualquier dispositivo USB en Windows de una forma genrica sin la necesidad de codicar ninguna lnea de un controlador modo ncleo. Las principales caractersticas de este producto son: Puede ser usado como un controlador ltro o como un controlador base de un dispositivo simultaneamente. Las funcionalidades son 100 % compatibles con el proyecto LibUSB. Soporta transferencias del tipo control, bulk e interrupt y todas las peticiones estndar de la especicacin USB. Soporta los sistemas operativos: Windows 98SE, Windows ME, Windows 2000 ,Windows XP. Es una herramienta gratuita.

2.3.2. Herramientas de depuracin

Dentro del grupo de herramientas de depuracin de drivers y dispositivos existen dos grandes clases: los analizadores software que permiten analizar los distintos eventos que suceden en el PC y los analizadores hardware que permiten analizar el traco de informacin a nivel fsico, pues se ubican entre el PC y el dispositivo a controlar. Durante el relevamiento del estado del arte se estudiaron las siguientes herramientas de depuracin software y hardware: SourceUSB USB Monitor Tracker 110

, USBInfo, USB Monitor Pro, Advanced USB Port y USB Explorer 200, Conquest USB y SBAE-30B. A

Monitor

Bus Hound

USB

pesar que se estudiaron, no

fueron utilizadas en el desarrollo del proyecto, ya que no fue necesario llegar a tan bajo nivel en anlisis en la comunicacin. A continuacin se presenta un ejemplar de herramienta de depuracin software y hardware.

2.3.2.1. SourceQuest Inc.- SourceUSB 2.0

Es un analizador USB va software que trabaja a nivel del host y que permite registrar las peticiones entrada/salida USB, eventos y invocaciones de funciones de bajo nivel entre los componentes de la pila de drivers USB. Su funcionamiento se basa en un drivers modo ncleo que se instala en el sistema operativo y coexiste con la pila de drivers USB de Windows y una aplicacin de alto nivel para visualizar la informacin recolectada. Es un complemento ideal para un analizador va hardware que registra las transacciones del canal pues brinda una visin desde la perspectiva del host.

34

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Caractersticas
Soporta los estndares USB 1.x y 2.0. No utiliza drivers ltro para capturar la informacin, esto le permite poder registrar todas las peticiones de entrada/salida que suceden durante la enumeracin o remocin de un dispositivo. Captura de todas las IOCtrl internas de USB y IOCtrl modo usuario para los host controllers, hub y dispositivos HID. Se puede ver en detalle la composicin (paquetes Setup, URB's, descriptores, etc.) y las distintas etapas (junto con sus estados) por las que pasan todas las peticiones USB de entrada/salida. Captura de todos los IRP de energa y Pnp y eventos remotos. Licencias y precios:

Single User: 4-User:

USD 595

USD 1.995 USD 3.995

10-User:

Requerimientos
Sistemas operativos soportados: Windows 2000, Windows XP, Windows Server 2003 y Windows Vista Hardware requerido:

Placa base Intel o compatible de 32-bit. USB Host Controller (UHCI, OHCI, EHCI).

Figura 2.8: Imagen de la informacin analizada.

2.3.

DRIVERS

35

2.3.2.2. ElliSys Srl - USB Explorer 200

El

USB Explorer 200

es un analizador de protocolo USB 2.0 de alto rendimiento, que ayuda a

desarrollar de dispositivos USB de mejor calidad y en menos tiempo. Se encarga de monitorear los eventos USB y registrar el trco de informacin que intercambia por el cable USB, usualmente entre un PC y un dispositivo. Durante la captura del trco, se despliega en tiempo real en una estructura jerrquica y ordenada cronolgicamente la informacin de las transacciones, paquetes, as como la decodicacin de las peticiones estndar o de clases y los descriptores USB.

Caractersticas
Anlisis del trco a velocidades low, full y high. Anlisis no intrusivo del trco y con una alta impedancia en la prueba. Alto grado de decodicacin de las peticiones estndar y descriptores. Deteccin y medicin de los estados del bus USB y protocolos de bajo nivel. Ediciones y Precio:

Standard:

USD 2.999 USD 5.999

Professional:

Figura 2.9: USB Explorer 200

Requerimientos
Procesador Pentium III 600 MHz o superior. 512 MB de memoria RAM. Host controller USB 2.0. Windows 2000 y Windows XP.

2.3.3. Decisiones tomadas

Luego de relevado el estado del arte de las herramientas de desarrollo y depuracin de drivers y junto con la decisin tomada de utilizar el PIC18F4550 como microcontrolador del hardware a desarrollar, se vi oportuno utilizar la

MPUSBAPI Library. Principalmente se tom esta decisin,

buscando reutilizar el driver genrico USB que viene con la biblioteca de Microchip y centrar los esfuerzos de construccin de drivers modo kernel para la plataforma Linux. Otra decisin tomada fue la eleccin de los productos LibUSB y LibUSBWin32 como opciones de driver modo usuario a utilizar en el proyecto, ms all de algunas limitaciones en la implementacin (no soportan todos los tipos de transferencias USB) detectadas en el relevamiento, siguen siendo aceptables como opcin.

36

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Finalmente, se descart el uso de herramientas de depuracin de drivers va software

hardware, pues en el caso del primer tipo, las opciones relevadas sola funcionan en la plataforma Windows y no sirven para depurar un driver que ejecuta en Linux. Para el segundo tipo de herramientas de depuracin el porque de su no utilizacin se debe estrictamente a sus costos econmicos, los cuales escapan ampliamente del contexto del proyecto.

2.4.

Proyectos relacionados

A continuacin se presentarn algunos de los proyectos relacionados y sus principales caractersticas, del total de los que fueron relevados [1, 4, 6, 10, 12, 13, 14, 21, 30, 36]. Muchos de los proyectos relevados solamente se centralizaban en el hardware y daban un driver que no aprovechaba las transferencias USB, ya que por simplicidad reutilizaban drivers del sistema operativo asignados a clases especicas de dispositivos. El soporte de rmware que brindan es mnimo, dejando al usuario toda la tarea de desarrollo de este.

2.4.1. DevaSys - USB I2C / IO

Este proyecto [13] utiliza el microcontrolador CypressAN2131QC. Es un proyecto comercial y est fundamentalmente centrado en la comunicacin con dispositivos del tipo I C.Algunas de sus caractersticas son:

20 bits I/O. Interfaz I C. Onboard 16KB I C EEPROM. Conector para hardware I C Bootloader Incluye API

Puntos dbiles:
ciones Isochronous, Bulk, Interrupt. Utiliza USB low speed. No tiene mdulos como PWM, serial, conversores A/D. Solo brinda driver para Windows.

Figura 2.10: DevaSys

Usa transacciones de control para todas las comunicaciones, por tanto no utiliza transac-

La API no ofrece una forma de comunicacin genrica, solo est pensada para manejo de perifricos jos (I

y E/S digital).

No posee una arquitectura bsica que permita agregar mdulos programados por el usuario.

Puntos fuertes:
Permite un diseo modular al poseer un conector para agregar los circuitos diseados por los usuarios. Permite tener mltiples placas. Bastante memoria.

1 Ms all de esta decisin, en los hechos se lleg a utilizar la herramienta de depuracin SourceUSB, para detectar un problema en el driver genrico USB de la biblioteca de Microchip para el tipo de transferencia isochronous).

2.4.

PROYECTOS RELACIONADOS

37

La API est bien documentada.

Permite la conguracin de los pins de E/S.

Se puede actualizar el rmware mediante el Bootloader.

2.4.2. Arduino
Es un proyecto [6] Software y Hardware libre, que ya tiene bastante tiempo el cual surgi como una placa que se conectaba por serial y luego se incorpor USB. Utiliza el microcontrolador Atmega8 de Atmel. Posee un lenguaje de programacin propio llamado Wiring, el cual es un C reducido. Sus caractersticas principales son:

14 pins de E/S digital 6 pins de E/S analgica (A/D y PWM) Comunicacin serial

Figura 2.11: Arduino

Puntos dbiles:
Utiliza el conversor serial-USB FT232BL/TR [20] no aprovechando el ancho de banda, requerimientos de tiempo y arbitracin de las transferencias USB. Utilizar el conversor tampoco permite reenumerarse como una clase de dispositivo conocido.

No tiene una arquitectura bsica donde el usuario pueda agregar dinmicamente mdulos programados por l.

Puntos fuertes:
Hay muchos ejemplos en la pgina

Pueden congurarse los pins de E/S

Incorpora Bootloader

Posee PWM

Hay drivers para Linux, Windows, MacOS (pero son los que trae el conversor serial - USB).

Posee un modo de operacin Stand Alone el cual le permite funcionar estando desconectado de la PC.

Tiene un IDE propio.

38

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

2.4.3. Wiring
Las caractersticas principales de este proyecto [36] son:

43 pins de E/S digital 8 entradas analgicas 6 salidas PWM 2 puertos serial puertos I C. 8 pins para interrupciones externas 28 KB de memoria de programa ash Figura 2.12: Wiring

Puntos dbiles:
Utiliza el conversor serial-USB FT232BL/TR Entonces no aprovecha el ancho de banda, requerimientos de tiempo y arbitracin de las transferencias USB. Utilizar el conversor tampoco permite reenumerarse como una clase de dispositivo conocido. No tiene una arquitectura bsica donde el usuario pueda agregar dinmicamente mdulos programados por l.

Puntos Fuertes:
Drivers para Linux Windows y MacOS (pero son los que proporciona el adaptador Serial - USB) Trae muchos pins para E/S Mucha memoria de programa Permite congurar los pins de E/S Posee gran cantidad de ejemplos en la pgina Hardware libre Pueden utilizarse los 8 pins analgicos como pins adicionales para E/S digital. Posee IDE propio

2.4.

PROYECTOS RELACIONADOS

39

2.4.4. CUI
Una caracterstica interesante de este proyecto [10] es que utiliza el microcontrolador PIC18F4550 de Microchip el cual fue seleccionado para realizar el

USB4all

32 KB de memoria 5 puertos generales de E/S 13 entradas A/D

Puntos dbiles:

Figura 2.13: CUI

No proporciona software ni rmware, solo se brinda una placa con rea de prototipado Tanto el driver como el bootloader son los que proporciona Microchip en su Framework ver Framework de Microchip. Pocos ejemplos y documentacin inexistente. No da soporte para Linux Solo se puede usar enumerndose como clases conocidas por Linux. No tiene una arquitectura bsica donde el usuario pueda agregar dinamicamente mdulos programados por l.

Puntos fuertes:
No utiliza conversores a USB Hardware libre Es actual (el proyecto est en funcionamiento an y se usa como base de otros proyectos).

40

CAPTULO 2.

RESUMEN DEL ESTADO DEL ARTE

Parte II

Arquitectura

41

Captulo 3

Introduccin
La solucin construida est compuesta por un PC, piezas de hardware y software especialmente diseadas y los dispositivos con los que se quiere interactuar. En la gura 3.1 se muestra un diagrama de conexin fsica de los componentes, entre los que se destacan: el

Adapterboards. El Baseboard

Baseboard

y los

es un dispositivo USB que funciona como controladora entrada/salida congu-

rable y permite conectar dispositivos electrnicos que se comunican utilizando diversos protocolos e interfaces diferentes a la del USB. Para poder conectarse con el PC el un conector USB y para la conexin con los dispositivos y/o de 40 pines llamado de aqu en ms El

U4APort

baseboard cuenta con adapterboards un puerto estndar

que agrupa un conjunto de seales congurables

dinmicamente tales como seales analgicas, puertos digitales, interfaces seriales, etc.

Adapterboard

la circuitera necesaria para la conexin de los dispositivos electrnicos al cuenta con un

baseboard, para ello U4APort y los elementos necesarios para la conexin de los dispositivos especcos.

es una pieza de hardware que tiene como funcin principal encapsular toda

AdapterBoard Motor

BaseBoard

PC AdapterBoard
Figura 3.1: Componentes fsicos del sistema USB4all.

Sensor

adapterboards

La gura 3.1 muestra un PC con un

baseboard

conectado por medio de un cable USB, dos al

conectados a un motor y a un sensor de temperatura y nalmente un cable plano

multihilo (ribbon cable) que permite conectar los

adapterboards

baseboard.

La idea de fondo

de la solucin es enviar y recibir datos desde el PC por un nico medio (USB) para que luego el

baseboard transforme esa informacin mediante su procesamiento en seales abiertas que cumplen
con los distintos protocolo e interfaces que requieren de los dispositivos. Vale destacar que toda la lgica de transformacin de la informacin recae sobre el

baseboard

y no en los

adapterboards

que

sol se encargan de cuestiones de conexin de los dispositivos (tratamiento de seales, circuiteria para el manejo de potencias, etc.). Para una justicacin ms en detalle de este concepto ver la seccin 7.1. 43

44

CAPTULO 3.

INTRODUCCIN

Figura 3.2: Componentes

USB4all System.

Luego de haber presentado un panorama general de los elementos fsicos de la solucin, nos adentramos un poco ms para presentar su arquitectura de software. La gura 3.2 es una vista interna de los elementos mencionados anteriormente, que permite visualizar los distintos componentes de software y rmware, que buscan satisfacer el objetivo principal de poder interactuar con dispositivos electrnicos desde un PC. A continuacin se presentan brevemente los componentes que constituyen la arquitectura y en los captulos siguientes se explicaran en detalle:

USB4all System

Es el nombre del sistema construido y reparte sus funcionalidades entre el

software del PC y el rmware del

baseboard. Su funcin es brindar a las aplicaciones de usuario

que corren en el PC servicios de alto nivel para la comunicacin con los dispositivos electrnicos, similar a los provistos por los sistemas operativos para la gestin de archivos (abrir, cerrar, leer, etc.).

USB4all Firmware
Es la parte del sistema que reside en el

baseboard

y se encarga de transformar la informacin

provenientes del PC (va USB) a las seales elctricas (va

los dispositivos deseados. Se divide en tres grandes componentes:

Modules.

U4APORT ) necesarias para controlar Base Firmware, Proxies y User

Base Firmware:
Es el componente responsable de manejar el puerto USB del

baseboard,

implementar el pro-

tocolo de transporte y el de gestin de vnculos lgicos. Encapsula las funcionalidades bsicas indispensables de la solucin por medio de un conjunto de servicios que permiten la expansin del

USB4all rmware

mediante la incorporacin de

ejecucin concurrente que permite instanciar de forma dinmica varios

user modules. A su vez ofrece un entorno de user modules.

User Modules:
Son los componentes intercambiables del sistema que permiten encapsular la lgica de un dispositivo especico y su protocolo de comunicacin con las aplicaciones de usuario. Se acoplan al

45

del

base rmware de forma similar a plugins permitiendo expandir de esta manera las funcionalidades USB4all rmware.

Proxies:
Es un representante en software de los mdulos de hardware existentes en el microcontrolador y su principal funcin es encapsular y abstraer la complejidad del manejo del hardware de forma de brindar servicios de ms alto nivel a los electrnicos, son la forma que tienen los

user modules para la comunicacin con los dispositivos user modules para acceder al hardware de manera

compartida o exclusiva. Esta funcionalidad puede visualizarse como una capa de abstraccin del hardware (hardware abstraction layer)(HAL), es decir, una capa que permite ocultar los detalles especcos de una plataforma, de forma de brindar servicios independientes del hardware sobre el que sta se apoya.

USB4all API
base rmware.
Es el componente del sistema que reside en el PC y constituye la contraparte funcional del Su misin es brindar a las aplicaciones de usuario una interfaz para la creacin de vnculos lgicos con los conectados a distintos

user modules de forma de interactuar con los dispositivos electrnicos baseboards. Este componente se desarroll como una biblioteca de vincu-

lacin dinmica que soporta varias plataformas y drivers lo que permite ampliar el espectro de lenguajes de alto nivel que la utilizan as como ocultar la complejidad inherente de la tecnologa USB.

USB4all Library
El componente

USB4all Library

se ubica por encima del

orientado a objetos sobre los servicios que brinda la

API.

USB4all API

y brinda un manejo y dispositivos.

Est formado por una jerarqua de

clases base implementada en Java, que encapsulan los conceptos como debe implementar el protocolo de comunicacin con el nuevo

baseboards

Esto permite extender fcilmente la solucin para el manejo de nuevos dispositivos, pues slo se

user module

especco reutilizando

todos los servicios de gestin ya implementados en las clases base.

Generic Driver:
Dado que el objetivo primordial es construir una solucin genrica, no es factible la reutilizacin de drivers de clases USB denidas como HID, clase de dispositivos de comunicacin (comunications device class) (CDC) [18], mass storage, etc., debido a que limita las clases de transferencias, la cantidad de endpoints a utilizar y la lgica de interaccin con el dispositivo. Por lo tanto nuestra solucin se basa en que los drivers que utiliza deben ser de la clase

Custom

denida por el estndar USB para poder utilizar todos los tipos de transferencias sin restricciones de la cantidad de endpoints y delegar la lgica de interaccin con los dispositivos a las capas superiores de la arquitectura. En los siguientes captulos se estudiar en detalle cada uno de los componentes que conforman el

USB4all System

mostrado sus componentes internos, su funcionamiento y relacin entre

los componentes.

46

CAPTULO 3.

INTRODUCCIN

Captulo 4

Arquitectura en el Baseboard
4.1. Baseboard Hardware

El

baseboard

es el hardware bsico para permitir la conexin fsica entre el PC y los dispositi-

vos electrnicos con los cuales se quiere interactuar. Su principal componente es el microcontrolador PIC18F4550 de Microchip encapsulado en el formato dos en lnea (Dual In-line Package) (DIP), que se conecta al

baseboard

mediante un zcalo. El resto de los componentes proveen al

microcontrolador de funciones bsicas; ellos son: un oscilador principal y uno secundario opcional, componentes para el control de voltaje de alimentacin, dos pulsadores y un diodo emisor de luz (Ligth Emitting Diode) (LED) para indicar que el USB. El

baseboard

baseboard

est conectado al puerto

cuenta con un conector USB tipo B para la conexin con el PC, un conector para conectar dispositivos electrnicos directamente con las entra-

RJ11 para conectar un programador/debugger (por ejemplo MPLAB ICD2) y un conector de 40 pines llamado

U4APort

das/salidas del microcontrolador, o mdulos adaptadores (de aqu en ms de mediana y alta potencia.

adapterboards )

para

cuando se precisa por ejemplo algn tipo de acondicionamiento de seal o manejo de dispositivos

El

baseboard

constituye la piedra angular de una solucin de hardware modular, pues contiene

el hardware bsico para la comunicacin mediante USB con el PC y provee de un conector de interfaz sencilla para comunicarse con

adapterboards,

delegando en estos las funciones mnimas

necesarias para la comunicacin con dispositivos electrnicos especcos.

El

baseboard

posee varias cualidades, en donde se pueden destacar su pequeo tamao, su

robustez, y su simplicidad. Desde un principio se intent minimizar su tamao, ya que ste componente de hardware siempre est presente en todas las soluciones de conexin de dispositivos con el PC. Su tamao de 70x60 mm (en su mayor parte ocupado por los conectores y el zcalo del microcontrolador) habilita la generacin de dispositivos pequeos. La robustez est dada por el uso de conectores mecnicamente resistentes y soldados directamente al

baseboard

con

longitudes mnimas de terminales de los componentes y la ausencia de cables o conexiones que se puedan doblar o quebrar con un uso normal. El circuito impreso es simple y utiliza slo una faz de cobre, lo que facilita su fabricacin y reduce los costos asociados.

Finalmente, la eleccin de componentes estndar y tecnologa through-hole, que al contrario que la tecnologa de montaje supercial (Surface Mount Technology) (SMT), permite cambiar fcilmente el microcontrolador en caso de que se dae, adems de facilitar el montaje del

board. Es de destacar que la mayora de los elementos que conforman el baseboard

detalles en cuanto a su diagrama lgico y construccin leer el documento [3]. 47

base-

con excepcin

del conector USB tipo B se encuentran en el mercado uruguayo a un costo razonable. Por ms

48

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

Figura 4.1: Identicacin de los componentes del

baseboard.

En la gura 4.1 muestra la distribucin de los principales componentes del 1.

baseboard.

Microcontrolador PIC18F4550: Este microcontrolador es el responsable del manejo de

toda la interaccin entre el USB y los dispositivos nales o del microcontrolador ver el documento [3].

adapterboards. Por ms detalles adapterboards

2.

U4APort:

Este conector se utiliza para la conexin con

que contienen o

permiten interactuar con el hardware del dispositivo especco que se desea utilizar. Sus pines incluyen a casi todos los pines del microcontrolador, adems de pines de alimentacin de 5 voltios derivada del conector USB. Dentro de este conjunto de encuentran los que simplemente unen los pines del conector del con dispositivos de baja potencia (leds, otros chips, etc.) y los el funcionamiento del dispositivo (motores, relays, etc.). 3.

adapterboards, se baseboard directamente adapterboard que proveen

cualquier tipo de acondicionamiento de seales, o controladores de mediana potencia para

Conector USB tipo B: Permite conectar el baseboard Conector RJ11 para programador/debugger:
componente que integra el rmware del

con el PC mediante un cable USB

A-B estndar, igual al utilizado en impresoras, scanners, etc. 4. Permite conectar el

baseboard

a un

programador/debugger, por ejemplo el MPLAB IDC2. Como programador se utiliza para la grabacin del bootloader por nica vez. Tambin se utiliza si desea debuggear cualquier

baseboard.

5.

Botn de Reset: Pulsar este botn causa el reseteo del microcontrolador y por tanto el
cierre de todas las comunicaciones de los programas de aplicacin con el de ello y dependiendo del estado del botn de bootloader del modo normal donde interacta mediante la

USB4all API

baseboard. Luego baseboard, ste reinicia en

con aplicaciones en el PC, o en

modo bootloader para una actualizacin del rmware. 6.

Botn de Bootloader:
botn de reset, el

baseboard

Si se mantiene apretado el botn de bootloader y se pulsa el inicia en modo bootloader. En este modo se puede actualizar

4.2.

FIRMWARE

49

el rmware del

baseboard

mediante una aplicacin dedicada a tal sentido en el PC va USB.

Si el botn de bootloader no es oprimido mientras se resetea, entonces el en modo normal. 7.

baseboard

entra

Cristal de 20 MHz: Cristal utilizado para la generacin de una seal de reloj principal
para el microcontrolador.

8.

Cristal de reloj 32.768 kHz y jumper: Al cerrar el jumper se establece el circuito que
habilita el uso del oscilador de 32.768 kHz para su uso en aplicaciones relacionadas con reloj de tiempo real (Real Time Clock) (RTC).

9.

LED: El led se enciende cuando el baseboard est conectado al PC mediante un cable USB.
adapterboard baseboard
interacta con uno (o construidos dirigirse

Por ms detalles de la constitucin del baseboard, as como de su programacin y actualizacin de rmware leer el documento[3]. Como se dijo anteriormente, el varios) quiere utilizar desde el PC. Para ver en detalle algunos de los a la seccin 8.2.2. que incluyen o permiten la conexin con los elementos electrnicos que se

adapterboards

4.2.

Firmware

4.2.1. Introduccin
El corazn del

baseboard

est constituido por el microcontrolador PIC18F4550 de Microchip

y una de las claves para lograr las caractersticas deseadas en el marco de este proyecto de grado es un buen diseo de su rmware. La principal responsabilidad del rmware es la de permitir una interfaz congurable entre el USB y el(los) dispositivo(s) electrnicos conectado(s). Debido a que el objetivo nal es facilitar la comunicacin con dispositivos electrnicos diversos, el rmware debe tener la capacidad de proveer servicios genricos de comunicacin, as como permitir la conexin de un conjunto de dispositivos especcos. Las caractersticas de diseo y calidad que se pensaron para el rmware son las siguientes:

Modular: Esto incluye identicar funcionalidades y responsabilidades especcas y encapsularlas en mdulos. Algunos de estos mdulos podrn ser intercambiables y para ello se van a precisar interfaces bien denidas.

Extensible:

Esta caracterstica incluye el diseo de un ncleo genrico estable, al cual

se le pueden ir realizando extensiones de manera sencilla y ordenada para el manejo de dispositivos o funcionalidades especcas.

Diseo basado en capas: Para la comunicacin con los dispositivos se utiliza una aproximacin basada en capas en donde cada capa ofrece servicios a una capa superior y utiliza los servicios brindados por una capa inferior. Las capas tienen responsabilidades claras y utilizan una pila (stack) de protocolos para su implementacin.

Congurable:

Se delega la conguracin de la mayor cantidad posible de elementos al

software que corre en el PC. La idea es mantener un rmware relativamente jo y canalizar hacia el software del PC (que es ms poderoso y ms sencillo de realizar) las conguraciones especcas a utilizar en cada caso.

Facilidad de uso:

Esta caracterstica signica eliminar (o minimizar) la necesidad de

programacin por los usuarios nales. Para el caso que se deba programar, el usuario debe concentrarse nicamente en la lgica para el manejo del dispositivo especco a utilizar. Para ello se dan las interfaces necesarias as como una metodologa para la programacin. El resto de las interacciones entre el USB y los controladores del PC queda oculto para el usuario.

Reusabilidad: La clave es pensar en una arquitectura basada en componentes intercambiables. En funcin de realizar componentes o mdulos para implementar extensiones al rmware de manera ordenada, y manteniendo cierta independencia entre estas, es posible el reuso de los componentes realizados por otros desarrolladores.

50

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

Independencia de plataforma: El el diseo de la arquitectura se realiza abstrayndose

lo ms posible del microcontrolador a utilizar. Esto facilita portar las implementaciones en otros microcontroladores. Con esas metas en mente se logra la primera divisin del diseo del rmware del microcontrolador del

baseboard

(de aqu en ms

USB4all rmware )

en componentes, tal como se observa en la

gura 4.2. A continuacin se detalla cada uno de estos componentes:

User Module : Encapsula la lgica especca para el manejo de un determinado dispositivo o conjunto de dispositivos. Pueden utilizar servicios de

prox ies,

o si la interaccin es

muy simple, utilizar el hardware directamente (modo exclusivo), por ejemplo usar puertos de entrada/salida directamente con el dispositivo conectado. Estos mdulos pueden verse como adaptadores especcos a un dispositivo y son los que en general deban ser implementados por los usuarios. Como ejemplos tenemos

user modules

encargados de la interaccin

con motores paso a paso, termmetros digitales, etc.

user modules. Permiten un user modules, por ejemplo

los distintos

Proxy : Brinda servicios para facilitar el manejo del hardware del microcontrolador a los
uso sencillo y logran compartir recursos utilizados por varios permiten utilizar el bus I C por varios

user modules.

stos

componentes estn diseados segn el patrn de diseo Observer para poder noticar a

user modules

interesados el suceso de un evento. responsable de toda la inter-

Base Firmware : est es la porcin del USB4all rmware

la interfaz y los servicios necesarios a los varios

accin con el PC mediante USB, la conguracin dinmica del

user modules

user modules.

baseboard

y de brindar

Normalmente se van a instanciar

de manera simultnea, por lo que es responsabilidad del

base rmware

el manejo de un nmero variable de stos. Tambin tiene la responsabilidad de brindar interfaces especcas para facilitar el uso de interrupciones por parte de los

proxies.

Figura 4.2: Componentes del

USB4all rmware

En el cuadro 4.1 de la siguiente pgina, se detalla como el diseo del

USB4all rmware

en

sus tres componentes bsicos est vinculado con las caractersticas de diseo y calidad buscadas.

4.2.

FIRMWARE

51

Caracterstica Descripcin
Modularidad Est presente en las tres componentes, si bien se puede aplicar directamente a los user modules y a los proxies debido a su relacin uno a uno con un dispositivo o hardware especico dentro del microcontrolador, la idea de modularidad tambin subyace en cada uno de los subcomponentes del base rmware . Est vinculada en gran medida con los user modules , pues brinda una manera de que la solucin puede extenderse para manejar una gran cantidad de dispositivos especcos. Est presente en los servicios de comunicacin proporcionados por el base rmware a los user modules . Esto independiza el mecanismo de comunicacin entre los user modules y su contraparte del lado del PC. Est relacionada estrechamente con el componente base rmware , pues facilita la interaccin con otros componentes en el software del PC para permitir congurar el baseboard esttica y dinmicamente durante la ejecucin de un programa de aplicacin del PC. Est relacionada con la utilizacin de interfaces claras entre el base rmware y los user modules , en donde se delegan slo algunas funciones especcas en los user modules , dejando el grueso de la comunicacin encapsulado en el base rmware . Se basa fuertemente en que los user modules (y proxies ) se relacionan con el base rmware mediante una interfaz que deben implementar. Existe una especie de contrato entre las responsabilidades que deben ser implementadas tanto en el base rmware como en los user modules . De esta manera si un desarrollador genera un user module para interactuar con un dispositivo, se vuelve reutilizable en diversas aplicaciones. A modo de ejemplo, luego de realizado un user module para manejar un motor paso a paso, ste puede utilizarse en un robot, en un plotter, etc.
Cuadro 4.1: Caractersticas del diseo del

Extensibilidad Basado en capas Conguracin exible Facilidad de uso Reuso

USB4all rmware.

En la gura 4.3 se muestra un ejemplo del a paso y un sensor de temperatura. El llama se utiliza el

stepper motor module y para controlar el tiempo de encendido de cada bobina del motor, timer proxy y para controlar el sensor de temperatura, existe el temperature sensor user module que conoce el protocolo de comunicacin serial del sensor particular.

USB4all rmware, para controlar un motor paso user module encargado de interactuar con el motor se

Figura 4.3:

Usb4all rmware

compuesto por

base rmware, dos proxies

user modules

el

user modules y proxies en el momento de generar rmware. En la siguiente seccin pasaremos a ver en detalle el base rmware.
permiten la integracin de varios

base rmware

Es interesante notar que los y otros

proxies.

user modules

pueden acoplarse de manera muy sencilla con el

Esta forma de diseo, junto con algunas tcnicas utilizadas,

USB4all

52

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

4.2.2. Base Firmware

Como se explic anteriormente, el diseo del

base rmware persigue como objetivo encapsular

la complejidad de la comunicacin USB, el cual es alcanzado exportando interfaces claras, que permiten utilizar estos servicios por los usuarios. Tambin se busca que la arquitectura sea extensible, brindndole al usuario mecanismos que le permitan extender el rmware con nuevas funcionalidades de manera muy sencilla, esto es resuelto agrupando en el lo que es fundamental para el funcionamiento elemental del los

baseboard

base rmware, solamente

y mediante la exportacin

de interfaces se dejan las funcionalidades especicas para que sean implementadas dentro de

user modules.

Para lograrlo el

tiempo coexistir varios estn ejecutando al El

base rmware provee un entorno en el cual pueden al mismo user modules y que el usuario logre tener la sensacin de que todos ellos mismo tiempo, sin la necesidad de modicar el base rmware cuando se

desea agregar un nuevo mdulo.

base rmware

est compuesto por dos grandes componentes, diseados siguiendo un enfo-

que en capas como muestra la gura 4.4, con funcionalidades bien denidas en cada una de ellas. Cada capa est construida a partir de la inferior y tiene el propsito de ofrecer ciertos servicios a la capa superior. Estos servicios se logran implementar mediante el protocolo de comunicacin que cada capa del y el

base rmware

mantiene con su contra parte en el PC, esto se explica

en la seccin 6.1. Se mantiene una comunicacin virtual entre las capas equivalentes en el PC

USB4all rmware,

la cual es implementada mediante la utilizacin de las capas inferiores,

para el intercambio de paquetes. Cada paquete est compuesto de un header con informacin para la capa en el otro extremo y la carga til a intercambiar. A continuacin se detallan las caractersticas de cada uno de los componentes del

base rmware.

Figura 4.4: Diagrama de capas en rmware

4.2.2.1. Handler Manager

La capa del medio en la gura 4.4, a la cual denominamos los componentes fundamentales del gestin de los para diferenciar a qu

handlers, los cuales son identicadores que utiliza el componente USB4all API user module enviar datos. La relacin entre un user module y un handler es de uno a uno. A su vez un handler identica de forma nica a un nmero de endpoint, asignado al user module por el cual este va a comunicarse con el PC. Este mdulo es responsable de almacenar una tabla encargada de mapear para cada handler que endpoint lo utiliza y a que user module pertenece. Otra de las responsabilidades del Handler Manager es procesar los paquetes recibidos mediante la inspeccin de su header, determinar a que user module corresponden e invocar a la
parmetro la carga til del paquete. Para poder lograr esta tarea se utiliza la tabla de mapeo

USB4all rmware.

Handler Manager

es uno de

Tiene como principal responsabilidad la

funcin de dicho mdulo que se encarga de atender la llegada de nuevos datos, pasndole como

handler

- endpoint -

user module.

4.2.

FIRMWARE

53

Utiliza como servicios para realizar sus tareas, los expuestos por la capa de acceso al medio USB, para poder de esta manera recibir y enviar paquetes. La capa de acceso al medio USB est implementada en hardware por el microcontrolador y se accede a ella mediante la escritura y lectura de ciertas posiciones del espacio de memoria, que estn mapeadas con los buers de cada endpoint. Para simplicar esta tarea el Para que los

handler manager

expone buers que se corresponden con

los buers de los endpoints, simplicando la lectura y escritura del endpoint.

user modules

puedan comunicarse, deben registrarse en el

Esto se realiza mediante la operacin que la registra. Luego el

setHandlerReceiveFunction

en la que los

registran la funcin que va a ser encargada de manejar los datos recibidos

handler manager

handler manager. user modules para el user module

utiliza la referencia obtenida a la funcin registrada,

como callback para ser invocada cada vez que se reciben datos por algn endpoint, dirigidos a un

user module
tarea es

USBRead.

(identicado por su nmero de

handler ). La operacin encargada de realizar dicha

Operacin
setHandlerReceiveFunction

Descripcin
Recibe como argumentos un handler y un puntero a funcin, y registra a esa funcin como manejador de los datos que lleguen para ese handler. No recibe argumentos. Lee cada endpoint y si para uno de ellos hay nuevos datos se procesa el header extrayendo el handler , luego se invoca la funcin registrada como manejador de ese handler . Recibe como argumentos un handler y un largo. Construye el header y lo coloca al comienzo de los datos ya ingresados a escribir en el mensaje a ser enviado. Recibe como argumento un handler y a partir de este obtiene el buer asociado para escribir al endpoint correspondiente al handler pasado por argumento.

USBRead

USBWrite

getSharedBuffer

Cuadro 4.2: Interfaz del

Handler Manager

La operacin

USBWrite

es utilizada por los

ltima operacin que exporta el

handler

user modules para enviar handler manager es getSharedBuffer, user modules

datos hacia el PC. La la cual a partir de un

pasado por parmetro devuelve el buer correspondiente al endpoint que tiene asignado, para obtener buers por donde pueden escribir

esta operacin es utilizada por los datos por el USB.

4.2.2.2. Admin Module

Sobre la capa

Handler Manager

encarga de las tareas de gestin de los

modules

almacenados en el

user baseboard, inicializacin. Cuando se estudie el protocolo que mantiene

como ser apertura, cierre, listado de

se encuentra la capa llamada

user modules,

Admin Module,

esta capa se

esta capa, se vern en ms detalle las tareas que lleva a cabo. Como vimos en la seccin anterior el

utiliza para determinar a que

handler - endpoint - user module, la cual se user module va dirigido un paquete, el admin module le suministra la informacin necesaria al handler manager para que pueda poblar la tabla.
utiliza una tabla para mapear Como es comn en las arquitecturas en capas, el protocolo de las capa superior viaja como

handler manager

payload en el paquete de la capa inferior, como veremos en forma ms detallada en la seccin 6.1, el paquete correspondiente al Handler Manager. El especicando el

admin module

viaja como payload del paquete correspondiente al

Admin Module al igual que los user modules debe registrarse en el handler manager handler en el cual atiende, ya que su estructura es similar a la de un user module, con la salvedad de que en lugar de registrarse al momento de ser abierto, el admin module se registra al momento de inicializarse el sistema. Se asigna el handler 0 para que atienda el admin module, este handler es reservado para el admin module y no puede ser utilizado por los user modules. La funcin registrada para atender los datos que llegan al handler 0 es la encargada

54

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

de implementar el protocolo correspondiente al 6.1. Al mismo nivel que el jo a diferencia del de usuario), en

admin module, el cual se explicar en la seccin

admin module se encuentran los user modules, cuyo protocolo no es admin module y es compartido con su contraparte en el PC (la aplicacin particular el Admin Module implementa una interfaz idntica a los user module user modules, no nos vamos a detener en esta base rmware y sern explicados en mayor detalle en la

presentada en el cuadro 4.5, con la diferencia de que su protocolo es prejado y dedicado a las tareas de gestin que se mencionaron. Sobre los seccin, ya que no forman parte del seccin 4.2.3.

4.2.2.3. Main Loop Algoritmo 1 Pseudocdigo de la operacin main

main: initializeSystem() loop USBTasks() polling() USBRead() endloop

Debido a que utilizamos un microcontrolador con una aplicacin dedicada sin ningn sistema operativo, se debe poseer de algn ciclo que permita que el microcontrolador contine ejecutando siempre el verse en el algoritmo 1. Su interaccin consta de inicializar el

initializeSystem,

USB4all rmware, esta es la tarea del Mainloop cuyo pseudocdigo puede baseboard mediante la operacin

luego le pasa el control al microcontrolador para que realice las tareas co-

rrespondientes al USB, luego ejecuta la funciones registradas por los mdulos para hacer poll y por ltimo lee los datos recibidos por los endpoints.

4.2.2.4. Dynamic Polling y Dynamic ISR

Los componentes para facilitar a lo

dynamic polling y dynamic ISR implementan el patrn de diseo Observer user modules y/o proxies el manejo de la entrada/salida con los mdulos de
registran y desregistran funciones que desean que se ejecuten repeti-

hardware del microcontrolador. Su responsabilidades son brindar un mecanismo por el cual los

user modules

proxies

damente. Ambos persiguen los mismos objetivos, pero cada uno se especializa en mecanismos diferentes como son polling e interrupciones. Una funcionalidad que comparten es la de poder asignar tiempo de procesador a los

user modules

proxies

registrados en ellos, dndole la sen-

sacin al usuario de que todos ejecutan al mismo tiempo. Para ello el de despachador que utiliza la poltica round robin y el atencin de todas las interrupciones El

dynamic ISR

dynamic polling

auspicia

implementa la rutina de

dynamic polling

interacta con los

que es exportada por ste mdulo. En el cuadro 4.3 pueden verse el conjunto de operaciones que denen la interfaz de

de forma de que en cada iteracin del

Mainloop

user modules ,

permitindoles registrar sus funciones,

sean invocados mediante la operacin

polling

l dynamic polling.

Operacin
addPollingFunction

Descripcin
Recibe por parmetro una referencia a una funcin, la cual es registrada para ser ejecutada cada ves que se invoque a la operacin polling. Recibe por parmetro una referencia a una funcin, la cual es des registrada del mecanismo de polling. Al ser invocada, ejecuta todas las funciones registradas en el mecanismo de polling.
Cuadro 4.3: Interfaz del

removePollingFunction polling

Dynamic Polling

4.2.

FIRMWARE

55

Anlogamente existe un mecanismo de registro similar, en el que en lugar de utilizarse polling se utiliza el mtodo de interrupciones como manejador de

2 interrupciones

y es implementado por el

y la operacin

interruption

dynamic ISR.

ste se instala

se encarga de noticar el

suceso de una interrupcin a los que se registraron. El orden de invocacin se realiza segn la poltica FIFO, esto permite implementar un mecanismo para el manejo de prioridades, dado que el primero que se registra es el primero en ser noticado. En el cuadro 4.4 puede verse el conjunto de operaciones que denen la interfaz del

dynamic ISR .

Operacin
addISRFunction removeISRFunction interruption

Descripcin
Recibe por parmetro una referencia a una funcin, la cual es registrada para ser ejecutada cada ves que se invoque a la operacin interruption. Recibe por parmetro una referencia a una funcin, la cual es des registrada del mecanismo de interrupcin. Al ser invocada, ejecuta todas las funciones registradas en el mecanismo de interrupcin.
Cuadro 4.4: Interfaz del

Dynamic ISR

En caso de querer utilizar un recurso (mdulo de hardware presente en el microcontrolador) por ms de un debe a que a los

user module , es necesario hacerlo utilizando el mecanismo de proxies . Esto se user modules desconocen la presencia de otros mdulos registrados, por lo que proxies

se genera el problema de no saber cual de ellos debe blanquear la bandera de evento indicado. Uno de los usos de los sobre los es asumir sta responsabilidad de forma de centrar en un nico componente toda la tarea, eliminando el problema previamente mencionado. Por ms detalles

proxies , ir a la seccin 4.2.5.

Si por el contrario, se desea usar un recurso de hardware del microcontrolador en forma exclusiva por un necesidad de los

user module , se puede utilizar directamente el mecanismo de dynamic ISR proxies .

sin

4.2.2.5. Loader Module

admin module user modules implementan (pertenecientes a su interfaz) para poder ser anexados al base rmware y de esta manera el admin module puede acceder a las operaciones que los user modules necesitan exponer para que el admin module sea capaz de inicializarlos y cerrarlos. Los servicios implementados proporcionan mecanismos similares a los de reection [27] en algunos lenguajes de programacin. Este mdulo
Tambin existe un mdulo llamado el cual brinda servicios al que le permiten obtener referencias a las operaciones que los se explicar en ms detalle en la seccin 4.2.3 en cuyo contexto ser ms evidente su motivacin.

loader module

4.2.3. User Modules

Como mencionamos en la seccin anterior, los al

user modules

son los encargados de implemen-

tar la lgica particular encargada de resolver las funcionalidades que el usuario desea incorporar

baseboard, sin preocuparse de aspectos tales como la comunicacin por el medio USB. Cada user module se identica por su nombre e implementa la interfaz del user module (ver cuadro 4.5), para que el base rmware sea capaz de anexar al USB4all rmware la lgica que implementa cada user module. Este conjunto de operaciones, es fundamental para que los user modules puedan colaborar con el base rmware, sto forma parte de un contrato entre el base rmware y el user module, donde el user module tiene la obligacin de implementar esas funciones y a cambio obtiene el benecio de ser ejecutadas por el base rmware en los momentos
estipulados.

1 En el caso del microcontrolador PIC puede congurarse cada una de las banderas de hardware para que dispare una interrupcin en el ujo de ejecucin o no. El dynamic ISR se encarga de atender aquellas banderas que disparan interrupciones. 2 Se entiende como manejador de interrupciones, a una rutina que adems de la atencin de la interrupcin se encarga de salvar y recuperar el contexto (puntero de programa, registros de estado y trabajo).

56

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

Operacin Descripcin
init

Momento en que se ejecuta

Al abrir el user module . Al cerrar el user module. Cuando se envan datos al handler del user module que implementa dicha operacin. Al ocurrir una interrupcin o cada cierto tiempo, dependiendo del mecanismo de entrada/salida utilizado.

Release Received

Inicializa el mdulo de usuario y registra en el handler manager la operacin encargada de manejar nuevos datos. Libera los recursos utilizados por el user module . Operacin encargada de manejar nuevos datos. Operacin encargada de procesar entrada/salida mediante mecanismo de polling o interrupciones como fue descripto en la seccin 4.2.2
Cuadro 4.5: Interfaz de un

ProcessIO

User Module

Los

user modules

manejan los vnculos lgicos que le permiten comunicarse con las aplica-

rmware

ciones de usuario en PC mediante USB, dichos vnculos son una abstraccin que brinda el de los endpoints que USB utiliza. Cada

user module

base

tiene un vnculo que utiliza un est constituido por el

endpoint para enviar y otro recibir datos. En la gura 4.5 podemos ver que el vnculo lgico del nejados por los por el por el

user module 1

endpoint 1 IN que le permite enviar y el endpoint 2 OUT que le permite recibir. Los vnculos maObserver, donde los

user modules son consecuencia directa de la implementacin del patrn de diseo user modules juegan el rol de observadores de los datos que son recibidos base rmware, siendo el mecanismo de recepcin del user module totalmente asincrnico user module.
Al permitirse tener un endpoint de entrada distinto al de salida, como se

para l. Por el contrario el mecanismo utilizado para enviar datos, es invocado directamente muestra en la gura 4.5 para el caso del

user module 1, es posible tener un tipo de transferencia

de recepcin distinto al utilizado para el envi de datos.

Capa de Acceso al medio USB

Endpoint 2 IN

Endpoint n IN

Vnculos Lgicos Manejados por la tecnologa USB

Endpoint 1 IN

Endpoint 1 OUT

Base Firmware

Endpoint 2 OUT

Endpoint n OUT

Vnculos Lgicos Manejados por los User Modules

User Module 1

User Module 2

User Module n

Figura 4.5: Relacin entre los vnculos manejados por los

user modules

y los endpoints USB.

4.2.

FIRMWARE

57

Para poder resolver lo que fue comentado en la seccin 4.2.2 y evitar que el usuario deba realizar cambios al desde el los

base rmware al agregar un user module , se busca eliminar las dependencias base rmware hacia ellos. En particular las dependencias que se busca eliminar son nombres de las operaciones utilizados en cada user module , ya que no es posible tener ms
3

de una operacin con igual nombre en ms de mdulo . Como solucin a esta problemtica se guardan y utilizan referencias a posiciones de memoria donde estn denidas las operaciones en lugar de accederlas por medio de su nombre, ms adelante en esta seccin se explicar en detalle como se generan y almacenan en el Los el

user modules

USB4all rmware

estas referencias.

guardan referencias a las operaciones que el

base rmware

necesita en

lugares jos en memoria de programa (por ms detalles ver seccin 4.2.6), de esta manera

admin module

puede encontrar las referencias en tiempo de ejecucin y utilizndolas como

callbacks puede acceder a las funcionalidades de los mdulos sin depender de cada mdulo particular. Las referencias a las operaciones

init

release

junto con el nombre del mdulo

deben almacenarse en una estructura especial en algn lugar determinado, para que puedan ser localizados en tiempo de ejecucin y utilizados por el gura 4.6 donde se observa un ejemplo para el caso de un llamado

admin module como puede verse en la user module que implementa la lgica

de control de un motor. Para llevar a cabo estas tareas existe un componente en el rmware

loader module

que se encarga de manejar la estructura antes descrita y proporcionar

operaciones para obtener las posiciones de cada operacin a partir de su nombre.

Tabla de referencias a operaciones en mdulos

Motor

MotorModule

Release() User module Init()

Figura 4.6: Estructura de un

user module.

Es necesario contar con algn mecanismo que de manera sencilla permita almacenar la estructura que contiene las referencias a las operaciones exportadas por un mdulo (que se necesitan como punto de inicio) y su nombre en un lugar predecible en memoria de programa. Tambin es necesario que este mecanismo sea general para poder extenderlo a varios mdulos, ya que al mismo tiempo puede haber varios cargados en memoria, para ello se utiliza un espacio de memoria continuo, donde de manera implcita se almacena una tabla, donde en cada la de sta se encuentra el nombre del Se adecu el linker script

user module

y las referencias a las operaciones que expone en su

interfaz y son necesarias como punto de inicio.

utilizado, para poder implementar el espacio de memoria continuo

mencionado, mediante una seccin denida en el linker script, la cual nos permite almacenar en memoria de programa la estructura de mapeo. Las secciones especicadas en el linker script permiten denir un espacio y asignarle un nombre, luego se puede utilizar la directiva

pragma

[29] para almacenar variables o constantes en dicha seccin, puede verse un pequeo ejemplo en el algoritmo 2. De esta manera, se soluciona el problema de encontrar las referencias a las operaciones que se precisan como punto de inicio del

user module

en lugares determinados.

3 Esta restriccin se debe a que si existiern ms de un user module con operaciones de igual nombre, el linkeditor no podra resolver cual de las referencias debe utilizar. 4 El linker script es utilizado por el linker, para describir como las secciones en el archivo origen son mapeadas en el archivo de salida.

58

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

Algoritmo 2 Mecanismo para almacenar las referencias en memoria de programa del mdulo.

#pragma romdata user uTab motorModuleTable = {&MotorInit,&MotorRelease,&userMotorConfigure,"motor"}; #pragma code Donde user es el nombre de la seccin y uTab es un estructura para almacenar las posiciones de memoria

de las operaciones que exporta el mdulo y su nombre.

La operacin la funcin

init como se ve en el algoritmo 3, se encarga de registrar en el handler manager received del user module, mediante la invocacin de la operacin setHandlerReceiveFunction

con los parmetros: posicin en memoria de la funcin y el la recepcin datos al

user module.

handler,

permitiendo de esta forma

Tambin se encarga de registrar la operacin

el mecanismo de entrada/salida deseado (polling o interrupt), para que el

user module

ProcessIO

en

realice

entrada/salida con los mdulos de hardware presentes en el microcontrolador. Para tal fn, el

user module
operacin

puede registrarse en el

dynamic polling

mediante la operacin

(ver el cuadro 4.3) si desea utilizar el mecanismo de polling o en el

addISRFunction

dynamic ISR

addPollingFunction

mediante la

(ver el cuadro 4.4) si desea utilizar interrupciones.

Algoritmo 3 Pseudocdigo de la operacin init

init(handler): guardo handler instalo manejador de recepcin de datos en el handler manager instalo operacin ProcessIO en mecanismo de polling o de interrupciones obtengo buffer para escribir en el endpoint asignado y guardo referencia a l
Otra responsabilidad de la operacin

init es guardar el handler

asignado para el mdulo, (el

cual es pasado por parmetro) y obtener a partir de este, el buer de memoria compartida correspondiente al endpoint asignado para escribir por USB, esto es resuelto mediante la operacin cree una conexin lgica con un determinado las operaciones que el el las operaciones. La operacin

getSharedBuffer. La operacin init es invocada en el momento que desde el PC se pide que se

base rmware, y el usuario no debe preocuparse de ello, slo debe concentrarse en la lgica de
ProcessIO

user module

user module. Determinar en que momento invocar

expone es una de las tareas del framework implementado por

ser ejecutada automticamente cada cierto tiempo (si se utiliza

polling) o cuando ocurre una interrupcin en el microcontrolador (si se utilizan interrupciones), adems debe contener la lgica necesaria para atender los eventos generados por el mundo exterior y tambin puede utilizar los servicios que brinda el el PC la ocurrencia de dicho evento. La operacin

handler manager

para comunicar a

received es la encargada de implementar el protocolo que mantiene el mdulo

con su contraparte en el PC y luego de ser registrada en el vez que se reciban datos en el implementa. La operacin por el

baseboard

con destino el

handler manager, es invocada cada handler asociado al user module que la

init
y es ejecutada

base rmware

release,

libera los recursos reservados por la operacin

al invocarse un pedido de cierre de la conexin lgica para dicho mdulo

desde el PC, puede verse su pseudocdigo en el algoritmo 4.

Algoritmo 4 Pseudocdigo de la operacin release

release(handler): libera referencia al buffer de escritura del endpoint desinstalo manejador de recepcin de datos desinstalo operacin ProcessIO
Para enviar datos, un mediante la operacin

endpoint del user module. Como el user modules y los endpoints, el user module no tiene porque preocuparse de cual es su endpoint, el user module slo es responsable del handler y el handler manager se encarga de resolver a que endpoint corresponde.
de memoria compartida en la posicin correspondiente al

USBWrite,

user module debe utilizar los servicios expuestos por el handler m anager
previo a esto se debe escribir los datos a enviar en el buer

handler manager

mantiene el mapeo entre los

4.2.

FIRMWARE

59

4.2.4. Funcionamiento general

En la gura 4.7, se muestra un diagrama que resume el funcionamiento de lo explicado hasta el momento. El diseo del

USB4all rmware

est fuertemente inuenciado por el patrn de diseo

Observer para implementar el mecanismo de noticacin de eventos. Con una lnea punteada pueden verse las invocaciones correspondientes a la operacin cuales son implementadas mediante callbacks.

notify

del mencionado patrn, las

Dynamic Pooling

Poll

Main Loop USBRead

Register

Notify

Receive USBWrite/Register

Handler Manager

Send

Receive

UserModule n

Init/Release

AdminModule

Register

Notify

ResolveAddress

Dynamic ISR

LoaderModule

Figura 4.7: Componentes del

USB4all rmware.

El funcionamiento del rmware comienza por el a la operacin

module
al

Luego se ejecuta la operacin

USBRead del Handler Manager para que lea los datos que llegaron baseboard y pueda noticar al user module destinatario de los mismos. Para esto, previamente el user module debe de haberse registrado. Si el destinatario de los datos es el admin module, usualmente va a ser necesario invocar operaciones de los user modules, como por ejemplo init, release. Para ello se utilizan los servicios del loader module, que resuelve las referencias a las operaciones del user module. Este mecanismo hace posible que el base rmware no este atado a los user modules cargados. Normalmente los user modules o el admin module deben enviar datos hacia el PC, as como
responder a los comandos recibidos. Para ello pueden escribir en el puerto USB utilizando la operacin

proxies

Poll

del componente

main loop, el cual se encarga de invocar Dynamic Pooling para que le asigne tiempo a cada user

registrado para utilizar el CPU (donde puede realizar E/S o lo que desee).

USBWrite

que exporta el

El otro mecanismo con que cuentan los noticar al ocurrir alguna interrupcin.

Handler Manager. user modules

proxies

para responder a eventos,

es mediante el uso de interrupciones. Para ello, pueden registrarse con el

Dynamic ISR

que los

4.2.5. Proxies
Un

proxy

tiene la responsabilidad de brindar servicios para facilitar el manejo del hardware

del microcontrolador a los lgica en los

user modules,

user modules.

Esto adems de contribuir con el aislamiento de la

permite el uso de recursos de hardware compartidos. Vale la pena

mencionar, que cuando se quiere compartir un recurso por ms de un

user module, no hay mucho

que se pueda realizar para imponer restricciones en cuanto al manenejo del hardware. Esto trae aparejados problemas en la mutuo exclusin de los recursos, ya que en el microcontrolador utilizado no hay instrucciones privilegiadas a nivel de hardware que corran slo en modo kernel.

60

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

De esta forma, aunque se pudiera hacer un sistema operativo, o algn componente que llevara el control de qu directamente. En los sistemas operativos actuales (de los PCs), hay componentes que se encargan del manejo centralizado de los recursos de hardware y son la nica puerta de entrada para su acceso. De esta forma el sistema operativo es capaz de serializar el acceso a los recursos compartidos de manera adecuada. Para poder lograr tal control, se debe tener apoyo del lado del hardware y como se dijo no est disponible para el caso del microcontrolador utilizado. Teniendo en cuenta este escenario, slo se puede aspirar a dar algunos lineamientos y esperar a que el programador los siga. Ante este problema, lo que se suguiere es que haya un

user module

usa que recurso de hardware, no se puede impedir que ellos accedan

proxy

que gestione los eventos que genera un determinado hardware (lo reconozca y apague las

banderas adecuadas), ya que los llamados luego de un registrados al

proxy

notify

en un

user modules no saben de antemano el orden en que van a ser dynamic polling o dynamic ISR. De esta manera todos los

son avisados del suceso del evento y no recae en ellos las responsabilidades

de reconocimiento y apagado de las banderas. Para la construccin de estos componentes, se utiliza el patrn de diseo Observer para noticar a todos los

user modules
y

registrados del suceso de un evento en el hardware. Dentro de

esos servicios se encapsulan las funcionalidades para interactuar con mdulos de hardware del microcontrolador en dos modalidades: mediante interrupciones y mediante polling, dando lugar a los

interrupt proxies

polling proxies

respectivamente. A continuacin se muestra en detalle

cada uno de ellos.

4.2.5.1. Interrupt proxies

Los

interrupt proxies

son particularmente tiles cuando deben noticarse eventos disparados

mediante interrupciones, como suele suceder con mdulos de timer, puertos seriales, etc. De esta manera puede implementarse un varios

user modules

proxy

para un Timer del microcontrolador, y permitir a debe implementar la interfaz mostrada

sean noticados del evento overow del registro contador del Timer. Para la

interaccin con el resto del rmware, el en el cuadro 4.6.

interrupt proxy

Operacin
initFunctions addFunction removeFunction config interrupt

Descripcin
Inicializa las funciones de callback. Recibe como parmetro una referencia a funcin. Agrega una funcin a la coleccin de callbacks a ser llamada al producirse una interrupcin. Recibe como parmetro una referencia a funcin. Remueve esa funcin de la coleccin de callbacks. Recibe parmetros necesarios para congurar el proxy . Congura el hardware del microcontrolador segn los parmetros recibidos. No recibe parmetros. Esta rutina es invocada desde el DynamicISR al producirse una interrupcin.
Cuadro 4.6: Interfaz de los

Interrupt Proxies.

La operacin

initFunctions

llamada por nica vez desde el El uso tpico de los

proxies

base rmware

es la encargada de inicializar la coleccin de callbacks y es (o luego de un reset).

por parte de los

user modules proxy

es la aplicacin del patrn de diseo

Observer de la siguiente forma: La operacin

modules

config

para conguracin del

es llevada a cabo por uno de los

user

con los parmetros adecuados.

Al inicializarse, el

addFunction

user module

registra una funcin de callback mediante la operacin

que debe ser ejecutada al ocurrir la interrupcin procesada por el

proxy.

Al realizarse un release del

user module, ste utiliza la operacin removeFunction, ya que

no est ms interesado en ser noticado de la ocurrencia de una interrupcin.

4.2.

FIRMWARE

61

El

proxy

al ejecutar su operacin

as, entonces el

proxy registra la funcin de callback interrupt, en el DynamicISR. Luego, agrega

se desregistra del

addFunction verica si es la primer funcin en registrarse, si es removeFunction, si es la ltima operacin en removerse,

la funcin pasada como parmetro en su coleccin de funciones de callbacks. Un procedimiento anlogo sucede al invocarse la operacin entonces el

proxy

La operacin

interrupt es el anlogo al notify del patrn Observer y realiza las acciones que

dynamicISR.

se muestran en el algoritmo 5.

Algoritmo 5 Pseudocdigo del la operacin interrupt

interrupt(): Si es la interrupcin esperada: Para cada funcin de callback F registrada en la coleccin Invoca F Apaga las banderas para la interrupcin procesada. Retorna
Otras operaciones pueden agregarse en caso de ser necesarias dadas las responsabilidades del por ejemplo, si se tratara de un

proxy,

una operacin de

send

proxy

que enva datos por un puerto serial, se le agrega

que pueden ejecutar los

user modules

para enviar datos por el mdulo

de hardware del microcontrolador adecuado.

4.2.5.2. Polling proxies

Los

polling proxies

son tiles cuando se quiere esperar por un evento realizando polling sobre

algn mdulo de hardware. Deben implementar una interfaz similar a la de los pero la gran diferencia es que los desde los

dynamic polling

polling proxies

interrupt proxies, dynamicISR.

polling
De

son llamados mediante la operacin

, en vez de ser llamada la operacin

esta forma peridicamente es ejecutada la operacin descriptas en

user modules registrados para ese evento. El resto de las interacciones son anlogas a las interrupt proxy. Para la interaccin con el resto del base rmware, el polling proxy

polling,

interrupt

desde

la que a su vez invoca a todos

debe implementar la interfaz mostrada en el cuadro 4.7.

Operacin
initFunctions addFunction removeFunction config polling

Descripcin
Inicializa las funciones de callback. Recibe como parmetro una referencia a funcin. Agrega una funcin a la coleccin de callbacks a ser llamada al producirse una interrupcin. Recibe como parmetro una referencia a funcin. Remueve esa funcin de la coleccin de callbacks. Recibe parmetros necesarios para congurar el proxy . Congura el hardware del microcontrolador segn los parmetros recibidos. No recibe parmetros. Esta rutina es invocada desde el DynamicPolling peridicamente.
Cuadro 4.7: Interfaz de los

Polling Proxies.

4.2.6. Programacin y conguracin

Luego de haber denido los elementos que componen el cin del rmware dentro microcontrolador del congurar el

USB4all rmware, se hace necesario

presentar algunos detalles referentes a su implementacin para explicar como se realiza la graba-

baseboard

baseboard

y con que mecanismos se cuenta para

como dispositivo USB.

ware

Lo primero a considerar, es que se utiliza un bootloader para la grabacin del

USB4all rm-

dentro del microcontrolador. El bootloader es una pequea aplicacin ubicada al principio

de la memoria de programa, cuya nalidad es la de grabar un rmware dentro del microcontrolador que se transere desde el PC mediante USB. Este bootloader es grabado por nica vez en el

62

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

microcontrolador utilizando un programador (por ejemplo MPLAB IDC2) mediante el conector RJ11 presente en el

baseboard, esto se muestra en la gura 4.8.

Bootloader Bootloader.hex

Aplicacin de programacin (MPLAB IDE)

Programador MPLAB ICD2 (hardware)

Baseboard
(A travs de conn. RJ11)

Transferencia del bootloader a travs del programador por nica vez

Figura 4.8: Programacin del bootloader en el microcontrolador del

baseboard

El

baseboard

de aqu en ms podr ser iniciada en dos modos, el modo bootloader y el modo

normal. Para iniciarla en modo bootloader, se deber mantener apretado el pulsador bootloader luego de soltar el pulsador de reset. De otra forma el adquiriendo el control

USB4all rmware.

baseboard,

iniciar en modo Normal,

PROYECTO MPLAB IDE

User Module 1 userModule1.h userModule1.c Usb4all Base Firmware Headers (.h) Code (.c) Archivos Fuente User Module N userModuleN.h userModuleN.c Proxy N proxyN.h proxyN.c Proxy 1 proxy1.h proxy1.c

MPLAB C18

Compilador

Object files *.o

Archivos Objeto

MPLINK linker

Linker script usb4all.lkr

Linker y archivo linker script

USB4all Firmware Usb4all.hex

Archivos de salida

Aplicacin Bootloader en el PC
Transferencia del usb4all firmware a travs de un cable USB

Baseboard
(en modo bootloader)

Figura 4.9: Proceso de desarrollo y deploy del

USB4all rmware.

4.2.

FIRMWARE

63

El

USB4all rmware, proxies

est implementado en C, especcamente para el compilador MPLAB

C18 de Microchip. Para generar ste rmware es necesario utilizar un proyecto que se brinda a manera de template. Dentro del proyecto se encuentran todos los fuentes del deben agregar los y los

user modules

base rmware

y se

que sean necesarios para la solucin a construir. El

siguiente paso es compilar y linkeditar todos los fuentes, lo que da como resultado la generacin de un archivo .hex, que describe una imagen de memoria de programa que debe ser grabada en el microcontrolador. Finalmente esta imagen es transferida al microcontrolador, utilizando el bootloader. El proceso se muestra en la gura 4.9.

4.2.6.1. Organizacin de la memoria de programa

Para la implementacin de mecanismos de eliminacin de dependencias del

base rmware

de los componentes y para la conguracin de los descriptores USB se dividi la memoria de programa en regiones jas. En la gura 4.10 se muestra el mapa de memoria de programa del microcontrolador.

Bootloader

0000h 07FFh 0800h 0829h 082Ah 08FFh 0900h 0BFFh 0C00h 0C09h 0C10h 0CFFh 0D00h

Interrupt vector remapping USB init USB descriptors USB configuration descriptor pointers USB string descriptors pointers USB4ALL base firmware

User modules table Proxies init table User space

2FFFh 3000h 3179h 3180h 31FFh 3200h

7FFFh

Figura 4.10: Mapa de memoria de programa del

baseboard.

La primer rea de memoria de programa es ocupada, como ya dijimos, por el cdigo del bootloader. Esta es la nica seccin del mapa de memoria impuesta debido a las facilidades que otorga el hardware para este cometido, para la dems reas fueron jadas tratando de maximizar el espacio para

rmware:

user modules

proxies. A continuacin se describen las dems reas del USB4all

Interrupt vector remapping: Es una pequea rea de memoria de programa en donde

estn mapeados los vectores de reset, e interrupciones de alta y baja prioridad. Aqu es donde las aplicaciones subidas por el bootloader ubican los saltos a sus funciones de main y manejadores de interrupciones, al igual que como lo haran si no estuviera el bootloader, pero sumando un oset de 0x0800. A modo de ejemplo, luego de un reset, el microcontrolador setea el contador de instrucciones en 0x0000 y comienza a ejecutar el cdigo ubicado en dicha posicin. Aqu el bootloader puede dependiendo del estado del botn de bootloader del

baseboard

iniciar en modo de ejecucin Normal o Bootloader.

En el modo Normal realiza un salto a la posicin de memoria 0x0800, donde se encuentra un nuevo salto al main loop del

base rmware.

Eso mismo sucede con los vectores de

interrupciones. Las direcciones de los nuevos vectores se hallan sumando un oset de 0x0800 a la direcciones predenidas en el hardware del microcontrolador. En el

modo Bootloader

64

CAPTULO 4.

ARQUITECTURA EN EL BASEBOARD

el

baseboard

permanecer esperando que se enve el

USB4all rmware,

que ser grabado

dentro de la misma EEPROM del microcontrolador a partir de la direccin 0x0800.

USB Init:

Aqu se encuentra el cdigo encargado de la inicializacin de los recursos

del microcontrolador destinados a la comunicacin USB. Se inicializan los registros de la memoria compartida del microcontrolador, indicando tamao y posicin de los buers de los endpoints, tipos de transferencia y direccin de la misma.

USB descriptors: Aqu se encuentran almacenados todos los descriptores USB utilizados
por el

baseboard.

Entre ellos se encuentran los descriptores del dispositivo, conguracin,

interfaces, endpoints y string. Estn codicados segn las especicaciones del captulo 9 del estndar USB [15].

USB conguration descriptor pointers: Son punteros hacia posiciones especcas del
rea

USB descriptors.

Son utilizados por el

base rmware

en el momento de la enumera-

cin del dispositivo. Incluyen cantidad de interfaces, consumo de energa, y dentro de las interfaces: cantidad de endpoints, cdigo de clase, de subclase, etc.

USB String descriptor pointers:

USB descriptors.
producto.

Son punteros hacia posiciones especcas del rea

Son utilizados por el

base rmware

en el momento de la enumeracin

del dispositivo. Incluyen strings, que son descripciones, normalmente en ingles del tipo de producto USB. Adems tambin son utilizados para contener un nmero de serie del

USB4all base rmware: En esta rea se almacena todo el cdigo correspondiente al base
rmware. rmware

User module table: En esta rea ja de memoria se ubica la tabla utilizada por el base
para encontrar las funciones de los

user modules. Esta tabla est descripta en la

seccin 4.2.3.

Proxies init table: Tabla con punteros al cdigo de las operaciones init de los proxies.
Esta tabla es utilizada por el

base rmware

para inicializar todos los

proxies.

modules

User Space:
y

proxies.

En esta rea de memoria de programa se almacena el cdigo de los

user

Esta manera de organizar la memoria de programa tiene las siguientes ventajas: 1.

rmware

Provee de medios al base rmware para quedar desacoplado de las conguraciones USB y de la cantidad de user modules y proxies . Dado que el USB4all
dene donde comienza cada rea de memoria de programa, el

base rmware

pue-

de localizar el cdigo de las funciones o de los datos necesarios para la realizacin de su trabajo. Para el acceso a datos o a cdigo jo, su uso es directo, ya que conoce la direccin de inicio del rea y su estructura. Para el caso donde la cantidad de elementos almacenados es variable, como es el caso de los

user modules

proxies,

se utilizan listas de referencias

a las operaciones de cada uno de ellos. De esta manera, conociendo el inicio de la tabla y su estructura es posible recorrerla y ubicar las operaciones de cada uno. 2.

Permite la conguracin de los recursos USB del baseboard en instancias posteriores. Dado que el base rmware accede a las reas de inicializacin y descriptores USB
en posiciones de memoria jas, es posible modicar nicamente estas reas especcas para cambiar los recursos y propiedades USB asignados al todo el mecanismo.

baseboard sin necesidad de modicar USB4all rmware. En la seccin 8.3 se muestra una aplicacin que automatiza este

Captulo 5

Arquitectura en el PC
5.1. Introduccin

Como ya se mencion en la introduccin de la arquitectura de la solucin (ver el captulo 3), existen tres elementos en el PC: la biblioteca de clases Java, la

USB4all API

y los drivers

USB genricos. El primero de ellos permite el uso de la solucin por parte de las aplicaciones de usuario, el segundo se encarga entre otras cosas de las funcionalidades de comunicacin y gestin de los vnculos lgicos con los

user modules

y por ltimo, el tercer elemento se encarga

del manejo fsico del puerto USB del PC. La gura 5.1 permite visualizar las dependencias que se dan entre estos tres elementos. Ade-

API

ms se observa que las aplicaciones de usuario pueden interactuar directamente con el o por intermedio de la biblioteca de clases (

USB4all Library ),

USB4all

tambin se desprende que

existen distintas opciones de drivers USB genricos. Por un lado estn los drivers que corren completamente en modo protegido dentro del sistema operativo y por otro, los llamados drivers modo usuario que exponen sus funcionalidades por medio de bibliotecas a los programas de alto nivel. El resto de las secciones de este captulo estn destinadas a explicar en profundidad cada uno de los elementos que existen en el PC, comenzando por la

USB4all API.

Figura 5.1: Diagrama de los elementos de la solucin existentes en el PC.

65

66

CAPTULO 5.

ARQUITECTURA EN EL PC

5.2.

USB4all API

5.2.1. Introduccin
El pilar del lado del PC sobre el cual se edica una parte importante de las funcionalidades de la arquitectura es el subsistema

USB4all API

(de aqu en ms:

API ).

Dentro de todas

sus responsabilidades sobresale la de brindar a los programas de aplicacin (alto nivel) una interfaz nica y bien denida que les permita el manejo de el(los) dispositivo(s) electrnico(s) conectado(s) a el plataformas. Para cumplir con estas responsabilidades la o canales lgicos con el

baseboard

y por otro lado, la interaccin con los drivers USB de las distintas

USB4all rmware baseboard. API

API

tiene la capacidad de establecer vnculos

por medio del uso de la tecnologa USB logrando

encapsular y hacer transparente a los programas de aplicacin toda la complejidad de la comunicacin entre el PC y el Las principales caractersticas de calidad y funcionalidad son las siguientes: estn organizadas que se seleccionaron en el diseo de la

Modular: Se busca que las funcionalidades que forman parte de la API

en componentes con responsabilidades e interfaces claramente denidas.

Facilidad de uso:

Para reducir la dicultad al mnimo en el uso de la

API

por parte

de los programas de aplicacin, se ofrece una interfaz pblica completa pero mnima en cuanto a la cantidad de primitivas que expone, comparable con las funcionalidades que ofrecen los sistemas operativos para el manejo de archivos a bajo nivel.

Diseo basado en capas:

componentes de la

Debido a sus responsabilidades con los programas de apli-

caciones y los drivers USB se necesita tener un alto grado de desacoplamiento entre los responsabilidades bien denidas. Adems algunos de los componentes de la

API, para ello se opt por un modelado en capas donde cada una tiene API mantienen una estrecha relacin con el USB4all rmware debido a que implementan los protocolos de comunicacin y como se vi en la seccin 4.2.1, los componentes del USB4all rmware
la

tambin estn organizados en capas, lo que rearma el enfoque tomado para el diseo de

API.

Portabilidad: El diseo exible permite el uso de la API

Windows y Linux.

en distintas plataformas (sistema

operativos) con un impacto menor en cuanto a su implementacin. Los escenarios de uso principales que se plantearon como objetivos en este proyecto de grado son las plataformas

Conexin orientada a user modules: Las conexiones que se establecen entre el PC y

el

baseboard

para la comunicacin entre las aplicaciones de usuario y los

user modules

se

instrumentan por medio de vnculos lgicos bidirecionales. Cada uno de estos vnculos lgicos estn asociados a un nico par de endpoints del pues se busca optimizar la utilizacin de los recursos existentes en el la tecnologa USB.

baseboard, pero no en forma exclusiva, baseboard. Adems

este enfoque de vnculos, busca aprovechar los distintos tipos de transferencias que posee

Soporte de mltiples baseboards : Se busca que la API

te con varios

baseboards

pueda trabajar concurrentemen-

que estn conectadas a el PC de forma de permitir la escalabilidad

de la cantidad de dispositivos electrnicos que se pueden controlar al mismo tiempo por un nico programa de aplicacin.

Registro de la comunicacin: Se considera importante registrar la informacin que se

intercambia entre la

API

y el

USB4all rmware

de forma de brindar a los desarrolladores

de programas de aplicacin y del rmware una herramienta para la vericacin de sus programas. Su implementacin respeta la restriccin de no afectar el desempeo del funcionamiento de la arquitectura y es por eso que el tipo de informacin que recolecta es reducido. Como una primera aproximacin al modelado de capas de la

API

se pueden distinguir tres

Logic

grandes subsistemas en el diseo. La gura 5.2 ilustra estos tres subsistemas: y

Connection to USB.

Public Interface,

5.2.

USB4ALL API

67

Figura 5.2: Subsistemas de la

API.

El subsistema

para que stos puedan establecer conexiones con el dispositivos electrnicos. El subsistema

Public Interface expone un conjunto de primitivas a los programas de aplicacin baseboard y as poder comunicarse con los Logic
es el responsable de establecer y administrar los vnculos lgicos que se

dan en la comunicacin entre la Y por ltimo el subsistema lograr brindar al subsistema

API

y el

USB4all rmware y para ello implementa los protocolos

de comunicacin que estn denidos en la arquitectura.

Connection to USB

es el responsable del manejo del puerto USB

del PC de forma de ocultar todas las asimetras de las distintas plataformas y drivers USB para

Logic

una visin homognea del medio USB.

Como lo muestra claramente la gura 5.2 estos subsistemas estn diseados siguiendo un modelo de capas en la cual la capa

Public Interface

es la que interacta con los programas de

aplicacin recepcionando y devolviendo informacin, la capa

Logic

es quien tiene la capacidad

establecer y administrar las conexiones, procesar los datos que se intercambian entre el ltimo la capa

baseboard

para transformarlos en mensajes segn lo establecidos en los protocolos de comunicacin y por

Connection to USB

recibe y enva estos mensajes desde y hacia el

baseboard

por

medio del puerto USB que maneja. Ahora analizaremos en profundidad cada uno de estos subsistemas para poder describir sus componentes, caractersticas y funcionalidades particulares as como sus puntos de contacto con el

base rmware

y con las caractersticas de diseo anteriormente mencionadas.

5.2.2. Public Interface

El subsistema

Public Interface

est compuesto nicamente por el componente

cual dene el conjunto de primitivas que permiten la comunicacin con el

baseboard.

u4aAPI,

el

5.2.2.1. U4aAPI
Este componente est diseado siguiendo el patrn Singleton [22] para poder brindar un nico punto de acceso a la

API

y lograr por este medio un mayor control y orden en la interaccin

entre los programas de aplicacin y el sistema. Como se ve en la tabla 5.1 la comunicacin con el

USB4all rmware

se resuelve bsicamente

por medio de cinco operaciones (las primeras en la tabla) muy simples e intuitivas, las cuales se asemejan mucho a las primitivas existentes en la mayora de los sistemas operativos para el manejo de archivos a bajo nivel. Por medio de estas cualidades del componente satisfacer la caracterstica de calidad facilidad de uso, buscada en el diseo de la

u4aAPI API.

se logra

Al igual que en el manejo de archivos donde la apertura da como resultado un identicador

leID

nico que permite al sistema operativo identicarlo, la arquitectura dene el concepto de

Modu-

como un identicador nico de cada uno de los vnculos lgicos que se establecen entre el

openDevice.

PC y un

user module

de un

baseboard, sta referencia es obtenida como resultado de la operacin

68

CAPTULO 5.

ARQUITECTURA EN EL PC

Operacin
openDevice configDevice sendData receiveData closeDevice qtyBaseBoards getBaseBoardSerial qtyUserModules getUserModuleName resetBaseBoard initAPI apiVersion firmwareVersion

Descripcin
Crear un vnculo o canal lgico con un user module existente en el ubs4all rmware . Se utiliza para enviar al user module una conguracin inicial de las propiedades de los proxies que utiliza. Enva informacin al user module que se indica como destinatario. Verica si existe informacin enviada por el user module que se indica como emisor y la obtiene. Destruye el vnculo lgico con un user module y libera los recursos que utilizaba el canal. Devuelve la cantidad de baseboards conectados al PC. Dado un ndice i, obtiene el nmero de serie del i-simo baseboard conectado a el PC. Devuelve la cantidad de user modules presentes en un baseboard . Dado un ndice i, obtiene el nombre de i-simo user module presente en un baseboard . Indica al base rmware de un baseboard que debe cerrar todos los user modules activos. Inicializa la conexin con los baseboards conectados a el PC. Obtiene el nmero de versin de la API . Obtiene el nmero de versin del base rmware de un baseboard .
Cuadro 5.1: Interfaz del componente

u4aAPI.

handler que se explic en la seccin 4.2.2 pero distinto a la vez, moduleID que se utilizan en la API son el resultado de la combinacin de los nmeros de serie y los handler que se utilizan en el Base Firmware. Los nmeros de serie son identicadores nicos de los baseboards y son utilizados para reconocerlas, permitiendo de esta forma que la API pueda trabajar con varios de ellos al mismo tiempo.
Este concepto es similar al pues los Como ya se vi en la seccin 2.1.3, los nmeros de serie se almacenan en un descriptor bsico del tipo String, opcional en el estndar USB y que la arquitectura lo convierte en obligatorio para su adecuado funcionamiento. Para la correcta utilizacin de la operacin ros de series de los

baseboard

openDevice

as como los nombres de los

para ello existen las operaciones

getUserModuleName.

qtyBaseBoards, getBaseBoardSerial, qtyUserModules

user module

es necesario obtener los nmeque ellos almacenan, y

nectados al puerto USB del PC, la segunda permite obtener el nmero de serie del

baseboard user modules existentes en un baseboard y obtener sus nombres segn su orden de registro en el base rmware. En la gura 5.3 se presenta un escenario hipottico de un PC con dos baseboards conectados
conectado en i-simo lugar. Las otras dos operaciones permiten consultar la cantidad de por medio del puerto USB y dos dispositivos electrnicos (antena y display) conectados cada uno a un

La primera operacin permite consultar la cantidad de baseboards co-

baseboard distinto, uno de ellos posee el nmero de serie 100 y tiene almacenados los user module de nombre Motor y Antena y el otro se identica con el nmero de serie 200 y posee los user module de nombre Display y Termmetro. Este ejemplo trata de explicar en forma visual como resuelve la API el problema de identicar
unvocamente cada uno de los vnculos lgicos que se crean desde el PC cuando existen varios

baseboards

conectados. Como muestra el cuadro de texto de la gura 5.3, las invocaciones de

las operaciones

qtyBaseBoards, getBaseBoardSerial, qtyUserModules y getUserModuleName

permiten obtener la informacin necesaria para poder crear las conexiones con los las invocaciones de la operacin como resultado los

moduleID

openDevice

de los

user module

de distintos

baseboards y baseboards tienen

1 y 2.

5.2.

USB4ALL API

69

USB

BaseBoard Antena
qtyBaseBoards() 2 getBaseBoardSerial(1) getBaseBoardSerial(2) Serial Number : 100

{100} {200}

2 qtyUserModules(100) getUserModuleName(100,1) getUserModuleName(100,2) qtyUserModules(200) 2 getUserModuleName(200,1) getUserModuleName(200,2) openDevice(100,Antena) openDevice(200,Display)

{Motor} {Antena}

{Display} {Termometro} {ModuleID = 1} {ModuleID = 2}

PC

USB

BaseBoard Display
Serial Number : 200

Figura 5.3: Escenario de uso con dos

baseboards.

Operacin

Parmetros de entrada

Parmetros de salida

No

openDevice

configDevice

moduleID moduleID

de serie del baseboard Nombre del user module Tipo de envo Tipo de recepcin Conguracin a enviar Largo del dato Dato a enviar Largo del dato Tiempo mximo de envo

sendData

receiveData closeDevice qtyBaseBoards getBaseBoardSerial qtyUserModules getUserModuleName resetBaseBoard initAPI apiVersion firmwareVersion

moduleID moduleID

Entero Caracter Entero Entero Entero Caracter Entero Entero Caracter Entero Entero Entero

moduleID

Entero

xito

Lgico

xito

Lgico

Entero

ndice No de serie del No de serie del ndice No de serie del

baseboard baseboard baseboard baseboard

Entero Entero Entero Entero Entero

Dato recibido Largo xito xito # baseboards No de serie # user modules Nombre user module Largo

Carcter Entero Lgico Lgico Entero Entero Entero Carcter Entero

No de serie del

Entero

Versin Versin

Entero Entero

Cuadro 5.2: Detalle de las operaciones del componente

u4aAPI.

70

CAPTULO 5.

ARQUITECTURA EN EL PC

La tabla 5.2 muestra los parmetros de entrada y de salida de las operaciones del componente

u4aAPI,

como se puede ver las operaciones

apiVersion

firmwareVersion

tienen

caracter nicamente informativo sobre las versiones de los subsistemas que componen la arquitectura mientras que las operaciones

getUserModuleName
de entrada el

qtyBaseBoards, getBaseBoardSerial, qtyUserModules y resetBaseBoard

permiten obtener informacin de los

baseboard

y de sus e

El resto de las operaciones con las excepciones de

initAPI
y

user module.

(que explica-

remos ms adelante) son las destinadas a la comunicacin y debido a eso tienen como parmetro

moduleID

para poder indicar a la

API

que vnculo lgico est invocando la ope-

racin. Otra caracterstica destacable que poseen las primitivas ejecucin de la operacin. Por ltimo estn las operaciones mera permite noticarle a un la

sendData

receiveData
e

es la

posibilidad de indicar por medio de uno de sus parmetros un tiempo mximo (timeout) para la

baseboard

resetBaseBoard

que debe cerrar todos sus

user modules

initAPI,

la pri-

activos de forma

de simular una accin de reset fsica y la segunda se utiliza para inicializar los componentes de

API

previo a su uso para la comunicacin.

En la siguiente seccin estudiaremos a fondo el subsistema y

y la forma en que interactan entre ellos y con los componentes de los subsistemas

Connection to USB.

Logic, analizando sus componentes Public Interface

5.2.3. Logic
El subsistema

Logic

es el ms importante de los tres subsistemas que componen la

API,

debido a que nuclea a la mayor parte de los componentes y adems es responsable de establecer y administrar los vnculos lgicos que se establecen con los constituye el objetivo principal de la

API.

baseboards

conectadas al PC, que

Sus componentes buscan satisfacer las caractersticas de diseo: modular y basado en capas, de forma de lograr un bajo acoplamiento y una alta cohesin de las funcionalidades, adems de permitir un fcil entendimiento de como funcionan en conjunto. Para alcanzar estos objetivos, el subsistema

HandlerLayer y CommandLayer que son las contrapartes en el PC de los componentes handler manager y admin module del base rmware del baseboard (ver secciones 4.2.2.1 y 4.2.2.2). Adems se encuentra el componente DescriptorLayer, que tiene como responsabilidad la interaccin con el subsistema connection to USB de forma de proveer a los componentes que implementan los protocolos de comunicacin la informacin de los descriptores USB y baseboards de una forma simple, dejando la mayor complejidad a las capaz inferiores de la API.
que dene la arquitectura por medio de dos componentes llamados

logic

implementa los protocolos de comunicacin

Figura 5.4: Componentes del subsistema

Logic

Como se ve en la gura 5.4, los componentes

cargados de ofrecer los servicios necesarios al subsistema

CommandLayer y HandlerLayer son los enpublic interface para que este pueda

5.2.

USB4ALL API

71

cumplir con el servicio de comunicacin que ofrece a los programas de aplicacin y por otro lado el componente

descriptorlayer

(que no implementa los protocolos de comunicacin) utiliza los

servicios que ofrece el subsistema y

connection to USB

para simplicar la informacin relacionada

con la tecnologa USB de forma de facilitar el funcionamiento de los componentes

handlerlayer.

commandlayer

Figura 5.5: Diagrama de capas de la comunicacin en el PC.

La gura 5.5 muestra en forma resumida los principales elementos que constituyen el mo-

Application

delado en capas de la comunicacin con los

baseboards.

En primer lugar se encuentra la capa

que corresponde a los programas de aplicacin que corren en el PC y su nivel de

comunicacin es con los

handlerlayer to USB

user modules,

luego se observa los ya mencionados

commandlayer

que se encargan del manejo de los mensajes por medio de los protocolos de comuni-

cacin que dene la arquitectura (ver seccin 6.1). La siguiente capa es el subsistema tintas plataformas y por ltimo, se encuentra la capa

connection

que permite la estandarizacin del acceso a los drivers USB que se existen en las dis-

USB Media

que representa a los drivers y

puertos USB de la PC. A continuacin se analizan las caractersticas ms importantes as como sus funcionalidades especcas de cada uno de los componentes que constituyen el subsistema

logic.

5.2.3.1. HandlerLayer
integra el

handlerlayer es la contraparte en el PC del componente handler manager que base rmware y al igual que ste, es el responsable del envo y recepcin de los mensajes que se intercambian los programas de aplicacin y los user modules. Para cumplir con dicha tarea implementa el handler protocol denido en la arquitectura y se encarga del almacenamiento de los vnculos lgicos que se establecen con los baseboards. El handlerlayer dene las interfaces iHandlerLayer e iAdminHandlerLayer para ofrecer sus funcionalidades, la primera se expone al subsistema public interface (componente u4aAPI ) que
El componente la utiliza para la recepcin y envo de datos mientras que la segunda que extiende la interfaz

ihandlerlayer se expone al componente commandlayer base rmware como se estudiara en la prxima seccin.

que la utiliza para enviar mensajes al

En la gura 5.6 se observa el conjunto de clases que constituyen al

handlerlayer,

as como

son sus relaciones y quien de ellas implementa las interfaces que dene el componente.

72

CAPTULO 5.

ARQUITECTURA EN EL PC

Figura 5.6: Clases del componente

HandlerLayer.

A continuacin para cada una de estas clases se explicarn sus caractersticas principales y se describirn sus operaciones.

ModuleManager
las interfaces

La clase

ModuleManager

es la responsable de orquestar el funcionamiento

de todo el componente y de esa forma permitir el trco de mensajes as como la persistencia de los vnculos lgicos. A causa de esa responsabilidad es la clase encargada de implementar

ihandlerlayer e iadminhandlerlayer para ofrecer a los componentes u4aAPI commandlayer las funcionalidades que requieren para su funcionamiento.

Operacin
send

Descripcin
Enva al user module identicado por el moduleID pasado por parmetro un dato. Opcionalmente se puede indicar por parmetro un tiempo mximo de ejecucin (timeout). Recibe un dato del user module identicado por el moduleID pasado por parmetro. Opcionalmente se puede indicar por parmetro un tiempo mximo de espera (timeout). Enva al user module identicado por el moduleID pasado por parmetro un dato para que pueda congurarse.
Cuadro 5.3: Operaciones de la interfaz

receive

configure

iHandlerLayer

send y receive que permiten el trco de mensajes y al igual que las operaciones homlogas del
componente para el envo o recepcin de mensajes y por ltimo se encuentra la operacin permite enviar informacin a un

El cuadro 5.3, muestra las operaciones de la interfaz

ihandlerlayer

que dene las operaciones

u4aAPI. Tambin aceptan parmetros para indicar los tiempos mximos aceptados user module
configure
que para que este pueda congurarse.

iadminhandlerlayer, que se descriptorlayer (getU4ABoards, requestDscIn, requestDscOut) pues consultan informacin de los descriptores USB y de los baseboards, las relacionadas con la clase modulemap (registerModule, existsModule, unregisterModule,
El cuadro 5.4 en cambio, muestra las operaciones de la interfaz pueden agrupar en tres grupos: las relacionadas con el componente

unregisterAllModule, getSerialNumber, getHandlerID)

nes propias de la clase

pues permiten el registro y consulta y las operaciones

de la informacin de los vnculos lgicos que se almacenan en ella y por ltimo las operacio-

configure

que se heredan de la interfaz

modulemanager (buildModuleID ihandlerlayer ).

send, receive

5.2.

USB4ALL API

73

Operacin
getU4ABoards requestEpIn requestEpOut registerModule unregisterModule unregisterAllModule existsModule getSerialNumber getHandlerID buildModuleID

Descripcin
Obtiene la lista de nmeros de serie de los baseboards conectados a el PC. Solicita un nmero de endpoint que utilice un tipo de transferencia particular que permita la recepcin de datos de un baseboard dado. Solicita un nmero de endpoint que utilice un tipo de transferencia particular que permita el envo de datos a un baseboard dado. Registra un vnculo lgico. Desregistra un vnculo lgico. Desregistra todos los vnculo lgico registrados. Consulta si ya est registrado o no un vnculo lgico (moduleID ). Devuelve el nmero de serie asociado al vnculo lgico identicado por un moduleID pasado por parmetro. Devuelve el handler asociado al vnculo lgico identicado por un moduleID pasado por parmetro. Construye un moduleID utilizando un nmero de serie de un baseboard y un handler de un user module .

Cuadro 5.4: Operaciones de la interfaz

iAdminHandlerLayer.

HandlerPackager
protocol
y

La clase

HandlerPackager

se especializa en el conocimiento del

handler

(ver seccin 6.1.1) y debido a sto ser encarga del empaquetado y desempaquetado de

los mensajes que llegan al componente por medio de sus dos nicas operaciones

unbuildPackage

buildPackage

como se explica en la gura 5.5.

Operacin
buildPackage

Descripcin
Empaqueta segn indica el handler protocol un conjunto de datos pasados como parmetro en un estructurado que dene la arquitectura (hndPackage). Dado un mensaje del handler protocol desempaqueta su contenido y lo devuelve en un estructurado que dene la arquitectura (hndPackageResponse).
Cuadro 5.5: Interfaz de la clase

unbuildPackage

HandlerPackager.

ModuleMap
recibir datos, el de cada vnculo

La clase

encarga de almacenar la informacin (

Map y se moduleID, los endpoints USB asignados para enviar y nmero de serie del baseboard y el handler asignado por el base rmware ) lgico que se crea en la API. La clave del Map son los valores moduleID y
implementa el tipo abstracto de datos (TAD)

ModuleMap

su implementacin fue pensada para evitar la duplicacin de claves de forma de garantizar que la informacin de cada vnculo lgico sea almacenada una nica vez. Como muestra el cuadro 5.6 las operaciones de la clase son las tpicas del TAD, con la salvedad de que no existe una nica operacin (getEndpointSend,

getEndpointRecv, getSerial

get

para obtener el valor almacenado en el

separado cada uno de los valores que el

Map

getHandler)

Map

sino cuatro operaciones

que permiten obtener por

almacena asociado a cada

moduleID.

74

CAPTULO 5.

ARQUITECTURA EN EL PC

Operacin
add

Descripcin
Crea una nueva entrada en el Map utilizando el parmetro moduleID como clave y como valores asociado los nmeros de endpoints asignados para la comunicacin, el nmero de serie del baseboard y el handler del user module . Elimina del Map la entrada con clave igual al valor moduleID pasado como parmetro. Consulta si el moduleID pasado como parmetro ya existe o no en el Map. Consulta si el Map posee alguna entrada creada o si est vaco. Devuelve la cantidad de entradas que almacena el Map. Devuelve el moduleID ubicado en la i-sima posicin del Map. Devuelve el nmero de endpoint para envo de datos asociado al moduleID pasado como parmetro. Devuelve el nmero de endpoint de recepcin de datos asociado al moduleID pasado como parmetro. Devuelve el nmero de serie del baseboard asociado al moduleID pasado como parmetro. Devuelve el handler del base rmware asociado al moduleID pasado como parmetro.
Cuadro 5.6: Interfaz de la clase

remove exists isEmpty size getModuleID getEndpointSend getEndpointRecv getSerial getHandler

ModuleMap

5.2.3.2. CommandLayer
Otro de los componentes que forman parte del subsistema contraparte en el PC del componente el

admin module

importante es la gestin de los vnculos lgicos que

Admin Protocol
El

logic es el commandlayer, que es la base rmware. Su responsabilidad ms existen en la API y para ello implementa
del que expone al componente

gestin como son del subsistema

commandlayer dene la public interface

OPEN, CLOSE, etc. Por ms detalles de este protocolo ver la seccin 6.1.2.
interfaz

que es un protocolo jo que dene un conjunto de comandos orientados a la

iCommandLayer

u4aAPI

para que este pueda ofrecer a los programas de aplicacin las

funcionalidades de creacin y destruccin de vnculos lgicos con los

user modules.

Figura 5.7: Clases del componente

CommandLayer.

Como muestra la gura 5.7 el componente commandlayer est compuesto por la clase CommandManager que se encarga de implementar la lgica para la gestin de los vnculos lgicos y por la clase CommandPackager que se ocupa del empaquetado y desempaquetado de los mensajes que se intercambian entre el PC y el baseboard al establecerse o eliminarse las conexiones. A continuacin se describen las operaciones y caractersticas principales de estas dos clases as como de la implementacin de la interfaz

icommandlayer.

5.2.

USB4ALL API

75

CommandManager
componente

Esta clase es la encargada de la gestin del proceso de creacin y des-

truccin de vnculos lgicos, para ello implementa la interfaz

cin. Adems, utiliza la interfaz

recibir los mensajes que dene el

iadminhandlerlayer para poder realizar las tareas de enviar admin protocol y poder almacenar la informacin asociada los vnculo lgicos que se establecen en la API.

u4aAPI

icommandlayer

que expone al y a

para que esta pueda ofrecer sus funcionalidades a las programas de aplica-

Operacin
open

Descripcin
Crea un vnculo lgico con un user module de un baseboard . Recibe como parmetros el nombre del user module , los tipos de transferencias de envo y recepcin de datos y el nmero de serie del baseboard y devuelve como identicador del vnculo un moduleID . Destruye el vnculo lgico identicado por el moduleID pasado como parmetro y libera los recursos utilizados por la conexin. Obtiene los nmeros de serie de los baseboard conectados a el PC. Devuelve los nombres de los user modules existentes en el baseboard que se identica por el nmero de serie pasado como parmetro. Indica al baseboard que se identica por el nmero de serie pasado por parmetro que debe destruir todos los vnculos lgicos activos en l. Devuelve el nmero de versin del subsistema base rmware del baseboard conectado a el PC que se identica por el nmero de serie pasado como parmetro. Devuelve el nmero de versin del sistema API .

close getBoards getModules reset getFirmwareVersion

getApiVersion

Cuadro 5.7: Operaciones de la interfaz

iCommandLayer

Como muestra el cuadro 5.7 la interfaz

icommandlayer

dene las operaciones

open

close
y

para la creacin y destruccin de vnculos lgicos. Para poder utilizar correctamente la operacin

open

es necesario obtener los nmeros de serie de las

getModules.

nombres de los

user module

baseboard

conectadas al PC as como los

que ellas almacenan, para esto existen las operaciones

Por ltimo est la operacin

lgicos existentes con un

baseboard

reset

getBoards

que se encarga de destruir todos los vnculos

dado liberando todos los recursos involucrados de forma de

simular va software el resultado de reiniciar fsicamente el microcontrolador del

baseboard.

CommandPackager

La clase CommandPackager se especializa en el conocimiento del admin protocol y debido a sto se encarga del empaquetado y desempaquetado de los mensajes que llegan al componente por medio de sus dos nicas operaciones se explica en la gura 5.8.

buildPackage y unbuildPackage como

Operacin
buildPackage unbuildPackage

Descripcin
Empaqueta segn indica el admin protocol un conjunto de datos pasados como parmetro en un estructurado que dene la arquitectura (CommPackage). Dado un mensaje del admin protocol desempaqueta su contenido y lo devuelve en un estructurado que la arquitectura (CommPackageResponse).
Cuadro 5.8: Interfaz de la clase

CommandPackager.

76

CAPTULO 5.

ARQUITECTURA EN EL PC

5.2.3.3. DescriptorLayer
El ltimo elemento que integra el subsistema criptores de los sable de la

logic

es el componente

DescriptorLayer.

Sus

principales obligaciones son: el procesamiento y almacenamiento de la informacin de los desnmeros de serie de los

baseboards conectados a el PC, el almacenamiento de las vinculaciones de los baseboards con los identicadores de instancia1 y por ltimo ser responconexin entre los subsistemas logic y connection to USB de forma de permitir el descriptorlayer
dene la interfaz para permitirle el intercambio de mensajes con los

iDescriptorLayer que expone al componente user modules y la solicitud de los nmeros de descriptores existentes en los baseboards que cumplen con un tipo de transferencia dado. Para poder brindar los servicios anteriormente mencionados utiliza la interfaz iDriverLayer perteneciente al subsistema connection to USB para poder enviar y recibir mensajes del puerto handlerlayer
El componente USB y obtener la informacin sin procesar de los descriptores USB (formato estndar [5]) de los

envo y recepcin de mensajes hacia el puerto USB.

baseboards

conectados a los puertos USB del PC.

DescriptorManager

Como muestra la gura 5.8 el componente

puesto nicamente por la clase y nmeros de serie de los

DescriptorManager

que implementa la interfaz

descriptorlayer est comidescriptorlayer connection to USB

que le

para brindar los servicios de mensajera (envo y recepcin) y consulta de los descriptores USB

baseboards

al componente

nalidades que se exponen en la interfaz

iDriverLayer

handlerlayer.

Para ello utiliza las funcio-

del subsistema

permiten comunicarse con el medio USB como veremos en la prxima seccin. Para el almacenamiento de la informacin procesada de los descriptores USB de los una implementacin genrica del

baseboards

as como de las

vinculaciones de sus nmeros de serie con los identicadores de bajo nivel (instancia) se utiliza

TAD Map.

Figura 5.8: Clases del componente

DescriptorLayer.

lerlayer

La operaciones

send y receive ocian de pasarela para sus homlogas del componente hand-

en la comunicacin con el subsistema

connection to USB, su nico aporte y causa de sus

tienen el cometido de obtener informa-

existencias es que permite aislar los componentes que implementan los protocolos de comunicacin de los que manejan el medio USB de forma de lograr un mayor grado de generalidad. El resto de las operaciones que dene la interfaz cin de los

baseboards

conectados al PC (getU4ABoards y

idescriptorlayer

getInstanceBoard) y de gestionar los

endpoints activos de cada uno de ellos que participan en la comunicacin entre los y los programas de aplicacin (requestDscIn, de los subsistema en que est dividido el

requestDscOut, freeDscIn, freeDscOut). En la

user modules

prxima seccin se analizar en detalle el conjunto de componentes que forman parte del ltimo

USB4all API, el subsistema Connection to USB.

1 Los identicadores de instancias son elementos utilizados en el subsistema reconocer los baseboards a bajo nivel.

connection to USB

para poder

5.2.

USB4ALL API

77

Operacin
send

Descripcin
Enva un paquete de datos al subsistema connection to USB pasando como parmetros: el nmero de serie del baseboard as como el nmero de descriptor USB que debe utilizar para el envo. Recibe un paquete de datos del subsistema connection to USB pasando como parmetros: el nmero de serie del baseboard as como el nmero de descriptor USB que debe utilizar para la recepcin. Devuelve una lista con los nmeros de serie de los baseboards conectados al PC. Solicita un nmero de descriptor USB de recepcin del tipo de transferencia indicado y del baseboard que se identica con el nmero de serie pasado por parmetro. Solicita un nmero de descriptor USB de envo del tipo de transferencia indicado y del baseboard que se identica con el nmero de serie pasado por parmetro. Libera un nmero de descriptor USB de recepcin previamente solicitado. Libera un nmero de descriptor USB de envo previamente solicitado. Devuelve el identicador de instancia que est asociado al nmero de serie pasado como parmetro.
Cuadro 5.9: Operaciones de la interfaz

receive

getU4ABoards requestDscIn

requestDscOut

freeDscIn freeDscOut getInstanceBoard

iDescriptorLayer

5.2.4. Connection to USB

user modules. Por otro lado, tambin se encarga de interactuar con las distintas plataformas en donde ejecuta la API para detectar la cantidad de baseboards conectados al PC y obtener de cada un
genricos para lograr el intercambio de informacin entre los programas de aplicacin y los de ellos la informacin de sus descriptores. y El subsistema

Connection to USB

es responsable de la comunicacin con los drivers USB

PlatformLayer

Para cumplir con estas dos obligaciones el subsistema dene los componentes

DriverLayer

como se observa en la gura 5.9, el primero se encarga del manejo del driver

USB genrico y el segundo posee la lgica para interactuar con el sistema operativo con el n de obtener los descriptores de los

baseboards. Esta separacin de responsabilidades permite generar

una estructura lo ms modular posible de forma de facilitar la extensibilidad de la solucin. Para ms detalles del porqu de esta separacin de funcionalidades leer la seccin 7.3.

Figura 5.9: Componentes del subsistema

Connection to USB.

En las siguientes secciones se describen las principales caractersticas y funcionalidades de los componentes

driverlayer

platformlayer.

78

CAPTULO 5.

ARQUITECTURA EN EL PC

5.2.4.1. DriverLayer
El componente

driverlayer

es el encargado de la comunicacin con las distintas implemen-

taciones de drivers USB genrico que se pueden utilizar como parte de la solucin. Adems, es el responsable de interactuar con el componente el componente del paquetes que intercambian los programas de aplicacin y los

driverlayer,

dene la interfaz

descriptorlayer para la recepcin y envo de user modules. Para sto ltimo iDriverLayer que expone al descriptorlayer para

permitirle entre otras cosas, la creacin y destruccin de las conexiones fsicas con los endpoints

baseboards

y el intercambio de paquetes. Una caracterstica importante de ste componen-

te es que fue diseado para establecer conexiones fsicas con endpoints en forma individual y no a nivel de todo el dispositivo. sto se debe principalmente, a que existen drivers genricos que funcionan con un enfoque de manejo de todo el dispositivo y otros en los que es necesario instanciar la conexin para cada endpoint en forma independiente. La decisin de implementar ste componente con el enfoque de conexin a endpoints individuales no constituye una limitante, pues para los drivers que funcionan con el enfoque de manejo del todo el dispositivo, se puede implementar la lgica necesaria para simular las conexiones con los endpoints en forma individual.

Operacin
getU4ABoards qtyDsc getEndpointDsc openIn openOut close sendInt sendCtrl sendIso sendBulk receiveInt receiveCtrl receiveIso receiveBulk

Descripcin
Devuelve una lista con los nmeros de serie de los baseboards conectados al PC. Devuelve la cantidad de descriptores que posee un baseboard dado. Devuelve la informacin bsica (nmero, tipo y tipo transferencia) del i-simo endpoint de un baseboard . Establece la conexin con un endpoint (entrante o saliente) del tipo de transferencia adecuado de un baseboard y devuelve un identicador nico de la conexin. Cierra la conexin con un endpoint de un baseboard por medio de su identicador. Enva un paquete de datos a un baseboard a travs de un endpoint (del tipo del transferencia adecuado) asociado al identicador de una conexin. Recibe un paquete de datos de un baseboard a travs de un endpoint (del tipo de transferencia adecuado) asociado al identicador de una conexin.

Cuadro 5.10: Operaciones de la interfaz

iDriverLayer.

En el cuadro 5.10 se muestra el conjunto de operaciones que denen la interfaz las operaciones de los

baseboards

getU4ABoards, qtyDsc y getEndpointDsc permiten obtener los nmeros de serie

idriverlayer,

conectados al PC as como la cantidad y la informacin de sus descriptores.

Esta informacin es obtenida del componente seccin) y es utilizada por el componente los endpoints de los distintos

platformlayer (como veremos en la prxima subdescriptorlayer para la creacin de las conexiones con baseboards durante la etapa de inicializacin de la USB4all API.
openIn, openOut, close
y los juegos de operaciones (nmero de series y junto con la informacin de los

Adems, la interfaz dene las operaciones

send
los

receive

lizadas por el

descriptorlayer

para cada uno de los tipos de transferencias USB. Estas operaciones son uti-

baseboards

descriptores) para gestionar las conexiones fsicas que permiten la comunicacin entre el PC y

baseboards.

En el contexto de este proyecto se utilizaron distintas implementaciones de drivers genricos como son: el facilitado por el fabricante Microchip, los drivers modo usuario LibUSb y LibUSBWin32 [25] y el driver construido especialmente para la plataforma Linux y para cada una de ellos se implement una clase particular en C++ que implementa la interfaz genricos y sumado a las caractersticas del componente

idriverlayer.

Con

este mecanismo de extensin de la API para el manejo de distintas implementaciones de drivers

platformlayer

(que veremos ms ade-

5.2.

USB4ALL API

79

lante), se logra satisfacer la caracterstica de funcionalidad de portabilidad que era uno de los objetivos buscados en el diseo de la

API.

5.2.4.2. PlatformLayer
Su misin es encapsular toda la lgica necesaria para la interaccin con las distintas plataformas en que ejecuta la

API

con el n de detectar los

baseboards

conectados al PC y obtener

la informacin de sus descriptores. Este componente dene la interfaz utilizada por el componente

driverlayer

para la obtencin de la informacin de los

Como se ve en el cuadro 5.11 la interfaz dene las operaciones:

findDevices y getDescriptors.

iPlatformLayer que es baseboards. baseboard

y sus

La primera se encarga de interactuar con el sistema operativo para detectar los rica del

descriptores y generar una coleccin con dicha informacin (se utiliza un implementacin gen-

TAD

ap)

y la otra simplemente la devuelve. Ambas son invocadas nicamente en la

inicializacin del componente o remocin de

baseboards

driverlayer

pues la

API

no fue pensada para detectar la adhesin

luego de inicializada la misma.

Operacin
findDevices getDescriptors

Descripcin
Busca la existencia de baseboard conectados al PC y obtiene la informacin de sus descriptores. Devuelve una coleccin con los juegos de descriptores de cada uno de los baseboards detectados.
Cuadro 5.11: Operaciones de la interfaz

iPlatformLayer.

Este componente es fundamental para poder satisfacer la caracterstica de portabilidad buscada en el diseo de la

API.

Tiene como benecios permitir la extensibilidad de la

medio del desarrollo de clases en C++ que implementan la interfaz te

iplatformlayer

API

por

para distintas

plataformas. Adems permite reutilizarlo cuando cambian las implementaciones del componen-

driverlayer

y se mantiene la plataforma. En el marco de este proyecto se desarrollaron dos

implementaciones del componente

platformlayer

para permitir el funcionamiento de la solucin

en las plataformas Linux y Windows.

5.2.5. Log
Una de las caractersticas seleccionadas para el diseo de la y los

API

fue el brindar como parte de

sus funcionalidades un registro del trco de paquetes que se da entre las aplicaciones de usuario

baseboards

conectados al PC. Para ello se desarroll un componente auxiliar llamado

Log,

que implementa el patrn de diseo Singleton y que permite ir almacenando en un archivo de texto de nombre

u4aapi.log

un detalle del trco de paquetes y sus contenidos en un formato

legible. Su interfaz se limita a dos simples operaciones:

printLog

printLogLn

que permiten

escribir en una lnea un mensaje y ingresar un smbolo salto de lnea en el archivo de texto. Como parte del formato que sigue el contenido del archivo de texto todas las lneas comienza con el da-hora en que se ingresa al archivo cada lnea y a continuacin el texto deseado. Este componente no pertenece a ninguno de los subsistemas previamente descritos en esta seccin, pues no participa de la funcin principal de la

API

que es la de comunicacin, sino

que realiza una tarea secundaria que permite la generacin de una base de informacin histrica de la interaccin con los dispositivos que facilita la depuracin y deteccin de errores en la comunicacin.

80

CAPTULO 5.

ARQUITECTURA EN EL PC

5.3.

USB4all Library

La programacin orientada a objetos es uno de los paradigmas de mayor aceptacin en la actualidad, y consiste en utilizar objetos y sus interacciones para disear aplicaciones y programas de computadora. A nes de facilitar el uso de la solucin lidades de la al usuario de poder utilizar libreras orientadas a objetos en donde se encapsulan las funciona-

USB4all, se brinda la posibilidad

USB4all API

de una forma ms intuitiva y ordenada. Existen muchos lenguajes

orientados a objetos, entre los que se destacan C++, Java, Python, VB.NET, C#.NET, etc. Algunas diferencias importantes a la hora de la implementacin entre los lenguajes, son el manejo de la memoria (ej: garbage collector), la posibilidad de herencia mltiple y si el cdigo generado es nativo o corre mediante una maquina virtual o con compilacin JIT. De todas formas el diseo utilizado puede servir como modelo para portar a otros lenguajes las funcionalidades implementadas. En el contexto de este proyecto se presenta una librera que permita un uso orientado a objetos y a la vez sirva de ejemplo de utilizacin de un lenguaje de programacin distinto al que fue realizada la

USB4all API.

Una cualidad que tambin es tomada en cuenta es la

posibilidad de utilizacin de esta librera tanto en entorno Windows como Linux, de manera que las aplicaciones construidas sobre sta sean transparentes al sistema operativo utilizado. Considerando las alternativas existentes fue seleccionada la opcin de Java, que cuenta con las ventajas de ser gratuito, multi-plataforma y de uso extendido. Como contraparte, ste lenguaje utiliza una maquina virtual para la ejecucin de las aplicaciones, por lo que genera algunas dicultades para la programacin en bajo nivel y para la utilizacin de libreras de vnculo dinmico (Dynamic Link Library) (DLL) como lo es la programacin como C++, la interaccin con la

USB4all API. En otros lenguajes de USB4all API sera directa, pero en Java vale la

pena ahondar un poco ms en esta interaccin. Java brinda un mecanismo para la ejecucin de operaciones en libreras de vinculacin dinmica llamado JNI el cual est poco documentado, hay pocos ejemplos disponibles y es necesario compilar ciertos componentes en lenguaje C o C++. En su lugar se decidi utilizar JNative que es un proyecto open source que simplica el uso de libreras de vinculacin dinmica y a su vez encapsula las diferencias de estas entre los distintos sistemas operativos utilizados. La otra decisin de diseo tomada, fue realizar en un componente separado, un envoltorio (Wrapper) de la

USB4all API

de manera de poder realizar

aplicaciones que utilicen directamente los servicios de sta. El componente

tiene como nica responsabilidad el encapsular el llamado a las operaciones de la que en la

USB4allAPIWrapper USB4all API a

los clientes de la misma en Java. Todas las operaciones tienen los mismos nombres y argumentos

API,

slo dieren algunas de las rmas debido a que en Java no es posible utilizar

parmetros de tipos de datos simples pasados por referencia (no son clases) de una funcin como argumentos de salida, como si lo es en C++.

Figura 5.10: Dependencias para el uso de las librera orientada a objetos

En la gura 5.10 se muestra la interaccin entre los distintos componentes y dependencias entre las aplicaciones que utilizan la

USB4all Library.

Aqu se muestra el componente indepen-

5.3.

USB4ALL LIBRARY

81

diente

USB4allAPIWrapper

sobre el que se apoyan tanto las aplicaciones Java que interactan

directamente con las operaciones de la de objetos de la

USB4all Library

USB4all API

como la

USB4all Library. Sobre el modelo

se construyen aplicaciones Java que facilitan toda la interaccin

con los dispositivos electrnicos conectados al

baseboard.

Figura 5.11: Diagrama de clases de la librera orientada a objetos

BaseboardFactory, Usb4allBaseboard y USB4allDevice y representan una abstraccin de los conceptos fundamentales del USB4all System. La clase USB4allBaseboard es el representante en software de la pieza de hardware baseboard y encapsula las funcionalidades de inicializacin, y obtencin de informacin
edicar aplicaciones de manera intuitiva, guiada y sencilla. Estas clases son: del mismo. Este objeto implementa una mquina de estados que ja las operaciones que pueden realizase en cada instante. Es muy simple y slo posee dos estados que se ilustran en la gura 5.12 a la izquierda. Es importante destacar que slo luego de la operacin ware queda ligado con un

En la gura 5.11 se muestra en detalle las tres clases fundamentales, sobre las cuales es posible

baseboard

init el objeto en soft-

y recin en ese instante todas las operaciones subsiguientes

en el objeto impactan el estado del hardware. Otra caracterstica importante es que al efectuar alguna operacin no permitida en la mquina de estados o cualquier otro error contemplado en la arquitectura (no existencia de

user module,

tipos transferencia inexistente, etc) se utiliza el

mecanismo de lanzamiento de excepciones para noticar a los invocantes.

82

CAPTULO 5.

ARQUITECTURA EN EL PC

Figura 5.12: Diagrama de estados que ocurren dentro de las instancias de baseboard y device

A continuacin se muestra un cuadro con una breve descripcin de las operaciones de esta clase:

Operacin
init release

Descripcin
Inicializa el baseboard y realiza el cierre de todos los user modules abiertos. Libera los recursos utilizados, realiza el cierre de todos los user modules abiertos y desasocia todos los objetos USB4allDevices, devolvindolos a su estado inicial. Asocia un device a este USB4allBaseboard . Desasocia un USB4allDevice del USB4allBaseboard . Obtiene una lista de los nombres de los user modules existentes en este baseboard . Obtiene una lista de los nombres de los proxies existentes en este baseboard . Obtiene la versin del base rmware de este baseboard. Setea el nmero de serie del baseboard a utilizar. Obtiene el nmero de serie del baseboard a utilizar.

addDevice releaseDevice getUserModuleNames getProxiesNames getVersion setIdBoard getIdBoard

Cuadro 5.12: Operaciones de la clase

USB4allBaseboard.

al

baseboard

La otra clase importante es el

y encapsula la interaccin con el

USB4allDevice que es el representante del dispositivo conectado user module especco para esta tarea. Esta clase user module
a utilizar, as como tambin las

es abstracta, y las clases que la extienden son las que denen los datos particulares a utilizar, como lo son el tipo de transferencia y nombre del principalmente en implementar el operaciones propias del dispositivo a interactuar. Aqu el trabajo del desarrollador se concentra

receive de la clase padre. La clase USB4allDevice

user protocol,

utilizando para ello las operaciones

send

tambin implementa una mquina de estados

la cual se ilustrada en la gura 5.12 en la parte derecha, de forma de ordenar su utilizacin y tambin utiliza el mecanismo de excepciones para noticar cualquier condicin de error. En la tabla 5.13 se muestran las operaciones de esta clase junto con una breve descripcin:

5.3.

USB4ALL LIBRARY

83

Operacin
setBoard init release send receive

Descripcin
Setea el USB4allBaseboard al cual asociarse (con el baseboard en el cual se quiere comunicar). Realiza la apertura del user module especco para este dispositivo. Realiza el cierre del user module. Enva datos al user module . Recibe datos del user module.
Cuadro 5.13: Operaciones de la clase abstracta

USB4allDevice

Finalmente se encuentra la clase

BaseBoardFactory

que implementa el patrn de diseo

Singleton y es utilizado para facilitar la instanciacin e inicializacin de los y sus operaciones se muestran en la tabla 5.14.

USB4allBaseboards

Operacin
getBaseboards getBoardsSerialNumbers getBaseboardBySerialNum

Descripcin
Devuelve una coleccin de los USB4allBaseboard correspondientes a cada uno de los baseboards conectados al PC. Devuelve una coleccin de los nmeros de serie de los baseboards conectados al PC. Devuelve una instancia del USB4allBaseboard correspondiente a un nmero de serie dado.

Cuadro 5.14: Operaciones de la clase abstracta

USB4allDevice

Las tres clases anteriores constituyen la base de la

USB4allLibrary

sobre la cual se puede

ir extendiendo la biblioteca. Como parte de este proyecto se crearon un conjunto de clases de dispositivos especcos: un sensor de temperatura, un motor paso a paso y un display 7 segmentos de forma de dar ejemplos concretos de implementacin. En la gura 5.13 se muestra un diagrama de secuencia tpico para el uso de un dispositivo desde la aplicacin de usuario.

UserApplication

Singleton BaseboardFactory

: Usb4allBaseboard

TemperatureSensor1

1: baseboards:=getBaseboards()

A travz de usb4allApiWrapper obtiene los numeros de serie de los baseboards conectados al PC que es 1 en este caso 1.1*: Usb4allBaseboard(nroSerieN) 1.2*: init()

2 [size(baseboards)>0]: TemperatureSensor() 3 [size(baseboards)>0]: setBoard(baseboards[0]) 4 [size(baseboards)>0]: init() 5* [size(baseboards)>0]: temp:=getTemp() 6 [size(baseboards)>0]: release()

Figura 5.13: Diagrama de secuencia de uso simple de la library

getTemp

La clase

TemperatureSensor

extiende la clase abstracta

USB4allDevice

y le agrega la funcin

que devuelve la temperatura obtenida por un sensor de temperatura.

84

CAPTULO 5.

ARQUITECTURA EN EL PC

Para implementar esta funcin se utilizan los implementa el protocolo de comunicacin con el el

baseboard.

user module

send

receive

de la clase padre, y con ellos

correspondiente a dicho sensor en

Lo primero que debe realizar la aplicacin de usuario, es obtener los al PC, y para ello invoca la funcin

boardFactory

e interacta con la

USB4allBaseboards. Luego con el nmero de secuencia de 2 y si USB4allBaseboards no es vaca, la aplicacin crea un objeto de la clase TemperatureSensor. Se recuerda que en la clase TemperatureSensor estn denidos los tipos de transferencia, as como el nombre del user module a utilizar por defecto. En los pasos 3 y 4 se enva el USB4allBaseboard en el cual se utilizar el user module correspondiente al sensor
coleccin de objetos de la clase la coleccin devuelta de de temperatura, y se inicializa el mismo, mediante las operaciones veces que sea necesaria la temperatura mediante la operacin implementada en la clase abstracta

cada uno de los

baseboards

USB4all API

getBoards.

Esta operacin est implementada en el

(a travs del

BaseUSB4allApiWrapper ) para obtener

baseboards

conectados

conectados, e instanciarlos adecuadamente para poder devolver una

setBoard

init

respecti-

vamente. A partir de este momento se encuentra todo preparado como para poder obtener las

getTemp.

Finalmente cuando no

se desee utilizar ms el sensor de temperatura, la aplicacin invoca la operacin

USB4all API.
5.4.

USB4allDevice

y realiza el cierre del

handler

release que

es

asociado en la

Generic Driver USB

El driver desarrollado es genrico, esto implica que no est diseado para ninguna de las clases de la jerarqua especca de dispositivos USB, sino que tiene como objetivo soportar todos los tipos de transferencias (Control, Bulk, Interrupt e Isochronous) as como el mximo nmero de endpoints (32) en forma abierta sin implementacin de lgica para un dispositivo particular. Dado que la

USB4all API

encapsula en el PC la implementacin de los protocolo de comu-

nicacin que dene la solucin lleva a que el driver slo sea responsable de la comunicacin e intercambio de informacin de las caractersticas del dispositivo (nmero de serie, descriptores) as como del intercambio de datos. Esta caracterstica de la solucin permite reutilizar el cdigo que implementan los protocolos de comunicacin y evita tener que implementarlos directamente en el driver, ya que son diciles de depurar (ejecutan en modo ncleo). Adems otro de los benecios que trae el no incluir la lgica de los protocolos en los drivers, es que se pueden sustituir por distintas implementaciones o incluso cambiar la plataforma que se utiliza con un impacto mnimo en la solucin. La implementacin del proyecto comenz utilizando el driver genrico que ofrece gratuitamente el fabricante del microcontrolador (Microchip) pues se ya se haba utilizado en las pruebas del mismo durante el relevamiento del estado del arte. La utilizacin de este driver como parte de la solucin no permite satisfacer totalmente los objetivos planteados, pues slo funciona en la plataforma Windows y no en Linux, por lo tanto se tuvo que buscar alguna otra opcin para hacer funcionar el dispositivo bajo ste sistema operativo. Una de las opciones era enumerarse como alguna clase denida para la cual Linux implemente un driver, como ser HID o CDC, pero si se toma esta opcin se termina atado a determinado tipo de transferencia y cantidad de endpoints (los denidos por las interfaces) lo cual es algo que se pretende evitar dado que uno de los principales objetivos del proyecto es que la solucin debe ser lo ms genrica posible. La siguiente opcin fue utilizar LibUSB [25] la cual pareca una muy buena opcin ya que contaba con implementaciones para diferentes sistemas operativos (Linux, FreeBSD, NetBSD, OpenBSD, Darwin, MacOS X, Windows). Se realizaron pruebas con LibUSB y se lograron buenos resultados pero slo permita utilizar tipos de transferencias de control y bulk y no transferencias interrupt e isochronous ni tampoco transferencias asincrnicas. Dado que la ltima versin estable es de hace varios aos, nos hizo suponer que el proyecto haba sido abandonado, por lo tanto se decidi investigar la posibilidad de realizar un driver propio el cual fue desarrollado como un mdulo del kernel de Linux. Para la realizacin del driver se tomaron las siguientes decisiones:

Un le (/dev/usb4all<instancia>) por baseboard conectado: La otra opcin manejada fue tener un le por endpoint el cual simplicaba las transferencias a diferentes endpoints pero diculta el intercambio de descriptores, ya que no se cuenta con un nico punto de acceso. Adems, para el usuario siempre sera ms difcil contar la cantidad de

5.4.

GENERIC DRIVER USB

85

les existentes que pedir a un nico punto de acceso toda la informacin del dispositivo en estructuras de datos claras, as como simplicar la interaccin del driver genrico con la

USB4all API.

Encapsular lo elemental en modo Kernel: Se coloca slo lo elemental en el mdulo

de kernel y se deja para programar en modo usuario (en la

USB4all API )

las tareas que

pueden resolverse a partir de un conjunto de primitivas bsicas exportadas por el driver. De esta manera se puede extender con mayor facilidad y permite depurar con todas las ventajas que se cuentan en el modo usuario. El driver se comunica con las aplicaciones que corren en modo usuario para el intercambio de informacin del dispositivo mediante llamadas IOCTL [9], las cuales implementan un conjunto de primitivas descriptas en la tabla 5.15.

Operacin
GET_DEVICE_DESCRIPTOR GET_ENDPOINT_DESCRIPTOR GET_INTERFACE_DESCRIPTOR GET_CONFIGURATION_DESCRIPTOR GET_STRING_DESCRIPTOR SET_DESC_INDEX SET_IN_ENDPOINT SET_OUT_ENDPOINT SET_TRANSFER_TYPE SET_TIMEOUT

Descripcin
Devuelve el descriptor de dispositivo. Devuelve el descriptor de endpoint. Devuelve el descriptor de interfaz. Devuelve el descriptor de conguracin. Devuelve el string descriptor. Setea un ndice utilizado para obtener un descriptor determinado de los tipos que poseen F de uno por tipo. Setea la direccin del endpoint in a utilizar. Setea la direccin del endpoint out a utilizar. Setea un tipo de transferencia a utilizar. Setea un tiempo de espera mximo para la llegada de los datos.

Cuadro 5.15: Interfaz para el intercambio de conguracin entre el driver y la aplicacin.

El conjunto de operaciones del tipo de esta manera la

USB4all API

get

permiten obtener los descriptores del dispositivo,

puede contar con toda la informacin necesaria para decidir

que tipo de endpoint utilizar o la informacin de la instancia particular como por ejemplo el nmero de serie. Por medio de las operaciones de tipo

set

se cuenta con un mecanismo para

poder congurar el endpoint a utilizar, tipo de transferencia y tiempo de espera (timeout).

User fd = open(/dev/usb4all0)

Driver

ioctl(fd, GET_INTERFACE_DESCRIPTOR) ioctl(fd, SET_DESC_INDEX) ioctl(fd, GET_ENDPOINT_DESCRIPTOR)

ioctl(fd, SET_OUT_ENDPOINT) ioct(fd, SET_IN_ENDPOINT) read(fd) write(fd)

Figura 5.14: Ejemplo de apertura y envi de datos por un endpoint.

86

CAPTULO 5.

ARQUITECTURA EN EL PC

Se implement siguiendo el framework para desarrollo de drivers USB que el kernel implementa [9, 19]. Como podemos ver en la gura 5.14 el primer paso para interactuar con el driver es realizar una llamada open sobre el le denido para el de interfaz asociado al dispositivo

baseboard

baseboard, luego se obtiene el descriptor

con esa informacin se determina cuantos endpoints

se poseen y se puede pasar a obtener sus descriptores como se muestra en el recuadro de la gura. Una vez obtenidos los descriptores de endpoints se cuenta con la informacin para poder setear que endpoint de entrada y salida se va a utilizar. Finalmente el driver se encuentra en un estado donde es posible comenzar a escribir y leer del endpoint seteado mediante las llamadas al sistema read y write. Existen variantes de este caso de uso donde se obtienen otros descriptores como el de device para determinar el nmero de serie del

baseboard

por ejemplo.

Captulo 6

Comunicacin
En este captulo se explica en detalle los protocolos de comunicacin que dene al arquitectura de software y la interaccin entre los componentes del

USB4all API

USB4all rmware.

Se

busca la comprensin por parte del lector de como son los pasos que suceden internamente en la solucin al momento de ejecutar las operaciones que brinda la

USB4all API

a las aplicaciones.

6.1.

Protocolo de Comunicacin

Se deni un stack de protocolos organizado segn las capas que intervienen en la comunicacin entre el llamada

USB4all API

y el

USB4all rmware, dichas capas pueden verse dividiendo a los

componentes de cada subsistema mediante lineas horizontales en la gura 6.1. La capa inferior

Medium access layer

implementa el acceso al medio utilizando el protocolo USB para

comunicarse, esta capa implementa el medio por el cual se comunica fsicamente el PC con el

USB4all.

Figura 6.1: Stack de protocolos denido y capas

da hacia los

Addressing layer se encarga de aspectos de direccionamiento de la informacin dirigiuser modules permitiendo que la informacin enviada por una aplicacin con destino un user module pueda llegar a ste. Esta tarea es de suma importancia ya que los user modules
La capa 87

son los destinatarios nales de la informacin y como comentamos anteriormente en la seccin

88

CAPTULO 6.

COMUNICACIN

4.2.3, generalmente hay varios

user modules

simultaneamente ejecutando en el

baseboard.

Por

lo tanto se debe contar con un mecanismo que permita encaminar correctamente a los paquetes que se envan desde el PC. El protocolo que implementa esta clase fue llamado y es el que permite la comunicacin entre el

handler protocol handler layer y el handler manager, su payload son paquetes denidos por uno de los protocolos de la capa Application layer (user protocol admin protocol) dependiendo cual sea el destinatario de la informacin. Esto es transparente para el protocolo, ya que el admin module fue implementado como un user module, por ms informacin
acerca de esta decisin puede consultarse la seccin 7.2. Luego tenemos la capa

Application layer, la cual dene dos protocolos, el user protocol que user modules, siendo un protocolo abierto1 para que el usuario dena como va a ser la interaccin entre la aplicacin y el user module que controla un dispositivo o caracterstica del hardware. El admin protocol en cambio tiene como nalidad realizar la gestin de los user modules. Cualquiera de estos dos protocolos es el que viaja como payload del protocolo denido por el handler protocol, como puede verse en la gura 6.2.
sirve para comunicar la aplicacin con los

Figura 6.2: Paquetes utilizados por el stack de protocolos

A continuacin se detallan en profundidad cada uno de los protocolos nombrados y los tipos de paquetes que intercambian.

6.1.1. Handler Protocol

handler protocol comunica las capas handler layer en el USB4all API y handler manager USB4all rmware, su objetivo es brindar mecanismos que permiten comunicar una aplicacin con un user module. Habilita enviar datos y congurar un user module. Utiliza el concepto de handler number para poder identicar a que user module se est enviando los datos. En la
El en el gura 6.3, puede verse el paquete denido para el intercambio de datos, su tamao es de 64 bytes como mximo debido a la decisin en la implementacin tomada en este proyecto, por ms detalle ir a la seccin 7.1. El primer campo que dene es el comando

opType,

el cual determina que tipo de operacin se quiere

ejecutar, los posibles valores que pueden tomarse son

send es que el user module

send

config.

La responsabilidad del

para enviar informacin al segundo campo campo

en el clculo. El cuarto campo

pLength, especca el largo del paquete enviado, ste incluye todos los campos del paquete reserved, es reservado para uso futuro. Por ltimo el campo payload encapsula el paquete correspondiente al admin protocol o al user protocol.
1 Se entiende por protocolo abierto en este contexto, a un protocolo que a priori no impone ninguna estructura y que el usuario es libre de implementarla para comunicar las aplicaciones de usuario y los user modules.

user module que ste espera como parmetros de conguracin. El handler number identica al user module destinatario del paquete. El tercer

reciba el payload del paquete. El comando

config se utiliza

6.1.

PROTOCOLO DE COMUNICACIN

89

Op Handler Type Number

3 bits 5 bits

pLength
8 bits

Reserved
8 bits

Payload
0 61 bytes

Figura 6.3: Formato de paquete para intercambio de datos utilizado por el

handler protocol.

6.1.2. Admin Protocol

El

admin protocol

es utilizado para tareas de gestin de los y

abrir, cerrar, y listar los mdulos existentes en el biado por las capas

command layer

user modules, las cuales permiten USB4all rmware. Este protocolo es intercamadmin module y pertenece a la capa application layer de

la jerarqua de capas denidas para la comunicacin.

Command
8 bits

Payload
0 60 bytes

Figura 6.4: Formato de paquete para el intercambio de datos utilizado por el

admin protocol

Como se observa en la gura 6.4, los paquetes intercambiados constan de un campo de un byte y un

payload

command

variable de como mximo 60 bytes, a continuacin se describe cada uno

de los posibles comandos que pueden especicarse y sus correspondientes argumentos que viajan en el payload del paquete.

6.1.2.1. OPEN
Un pedido de open para un

user module
open

se especca mediante un paquete como el que se

ilustra en la gura 6.5, el cual es denido por el por el identicador del comando que especica el endpoint que va a utilizar la que especica el nombre del

admin protocol.

Dicho paquete est compuesto

en el primer campo, luego se encuentra el campo

API

para recibir los datos y el campo

el endpoint que va a utilizar para enviar datos. Por ltimo se encuentra el campo

user module

inEP outEP para moduleName

que se desea abrir.

OPEN
8 bits

inEP
8 bits

outEP moduleName
8 bits 8 bytes

Figura 6.5: Paquete de pedido del comando

open

admin protocol. Dicho paquete est compuesto open en el primer campo y el handler number asignado al user module en el segundo campo, en caso de que el user module no exista o ya est abierto se devuelve
ilustra en la gura 6.6, el cual es especicado por el por el identicador del comando la constante

Una respuesta de

open

para un

user module

se realiza mediante un paquete como el que se

ERROR.

90

CAPTULO 6.

COMUNICACIN

OPEN
8 bits

handlerNumber
8 bits

Figura 6.6: Paquete de respuesta del comando

open

6.1.2.2. CLOSE
base rmware cierre un determinado user module se enva un paquete close como se ilustra en la gura 6.7, el cual es especicado por el admin protocol. Dicho paquete est compuesto por el identicador del comando close en el primer campo y el handler number del user module a cerrar en el segundo.
Cuando se quiere que el de pedido de

CLOSE
8 bits

handlerNumber
8 bits

Figura 6.7: Paquete de pedido del comando

close

La respuesta a este comando se especica con un paquete de respuesta de

se muestra en la gura 6.8, el cual est compuesto por el identicador del comando La constante toma el valor o ya este cerrado.

close como el que close en el

no exista

primer campo y una constante que representa el resultado del comando en el segundo campo.

ACK

en caso de xito o

NACK

en caso de que el

user module

CLOSE
8 bits

handlerNumber
8 bits

Figura 6.8: Paquete de respuesta del comando

close

6.1.2.3. GET_USER_MODULES_SIZE
Su objetivo es obtener la cantidad de user modules cargados en un basboard, junto con el GET_USER_MODULES_LINE implementan el mecanismo por el cual el usuario puede obtener los nombres de los user modules cargados en el USB4all rmware de un baseboard en particular. Esto es muy til ya que a partir de esta informacin es que se puede invocar al comando

open.

Para hacer el pedido se enva un paquete como el que muestra la gura 6.9, el cual especica simplemente el deseo de conocer cuantos identicador del comando.

user modules

hay cargados mediante el campo

6.1.

PROTOCOLO DE COMUNICACIN

91

GET_USER_MODULES_SIZE
8 bits

Figura 6.9: Paquete de pedido del comando

GET_USER_MODULES_SIZE

La respuesta contiene solamente un campo con el identicador del comando como es usual y otro con la cantidad de

user modules

cargados en el

USB4all rmware.

GET_USER_MODULES_SIZE
8 bits

size
8 bits

Figura 6.10: Paquete de respuesta del comando

GET_USER_MODULES_SIZE

6.1.2.4. GET_USER_MODULES_LINE
Una vez obtenido la cantidad de

user modules

cargados en el

condiciones de poder invocar a este comando para determinar el nombre de cada

USB4all rmware, se est en user module

cargado. El funcionamiento es el siguiente: para realizar el pedido se enva un paquete conteniendo el identicador del comando seguido de un campo que especica el nmero de la en la tabla comentada en la gura 4.6 como puede verse en la gura 6.11. El nmero obtenido mediante el comando anterior es til para determinar cuantas son las las que posee la estructura que almacena la informacin de un que posee la tabla. Se decidi hacerlo de esta manera, en lugar de contar con una sola operacin que devuelva la totalidad de los nombres presentes, para lograr simplicar la programacin en el

user module

e ir pidiendo de a una sin excederse en la cantidad

rmware

debido a que es ms sencillo de implementar en la

API

USB4all

a partir de estas dos primitivas.

GET_USER_MODULES_LINE
8 bits

line
8 bits

Figura 6.11: Paquete de pedido del comando

GET_USER_MODULES_LINE

La respuesta, como muestra la gura 6.12, consta del campo identicador del comando y otro campo con un string de ocho caracteres conteniendo el nombre del al identicador pasado.

user module

correspondiente

GET_USER_MODULES_LINE
8 bits

modName
8 bytes

Figura 6.12: Paquete de respuesta del comando

GET_USER_MODULES_LINE

92

CAPTULO 6.

COMUNICACIN

6.1.2.5. CLOSE_ALL
Este comando simplemente sirve para que el

USB4all rmware

cierre todos los

user modules

que estan abiertos. Es til para liberar los recursos al momento de terminar de trabajar con la

baseboard

o el dispositivo a controlar. El paquete es muy sencillo y tanto el pedido como la de

respuesta constan slo del identicador del comando.

6.1.2.6. GET_VERSION
Este comando es utilizado para obtener el nmero de versin del

USB4all rmware,

lo cual

fue til a la hora de realizar el testing debido a que dicho nmero de versin se corresponde con un tag en el sistema de control de versiones (concurrent versions system)(CVS), lo que permite tener un mejor seguimiento del rmware una vez grabado en el microcontrolador. El paquete que se intercambia para una solicitud, consta solamente del identicador del comando correspondiente y el de respuesta adems del identicador tiene un campo con el nmero de versin.

6.2.
La

Interaccin USB4all API

USB4all Firmware

USB4all API

interacta con el

servicio de enviar y recibir datos hacia o desde un

USB4all rmware para poder brindarle al usuario el user module (como vemos en la gura 6.13). user modules

Esto es de suma importancia ya que abstrae al usuario de la tecnologa utilizada como medio fsico (en este caso USB), permitindole concentrarse en la interaccin con el dispositivo a controlar. Todo esto se realiza en un entorno donde dinmicamente se pueden ir instanciando que van a estar activos en simultneo.

Figura 6.13: Interaccin API - Firmware

El permitir que los

user modules

se instancien dinmicamente nos brinda la posibilidad de

module

gestionar ms ecientemente los recursos del microcontrolador del

baseboard,

ya que si un

user

no es abierto, ste no utiliza tiempo de CPU ni los recursos que tenga asignados, salvo

la memoria de programa. La interfaz que brinda la

API

al usuario es similar a la que brindan los sistemas operativos

para el manejo de archivos, la aplicacin comienza creando los vnculos lgicos con los

modules (open)

necesarios para la capa

command layer en el PC la cual es la encargada de generar los paquetes admin module en el USB4all rmware, lo mismo ocurre con los dems mensajes que esta capa maneja, como son el close y de listado de user modules presentes en los
delegados a la capa

que luego le van a permitir enviar y recibir datos. Los mensajes de

user open son

6.2.

INTERACCIN USB4ALL API

USB4ALL FIRMWARE

93

baseboards.

user module, estos mensajes van a API, donde se van a generar los paquetes necesarios para su contraparte en el USB4all rmware (handler manager ), estos paquetes van a contener la informacin necesaria para identicar a que user module es dirigido el paquete. Cabe destacar que los paquetes dirigidos al admin module tambin son direccionados por el handler manager al igual que lo hace para los paquetes destinados a los user modules. Por eso, es que podemos pensar a la capa admin module como la encargada de administrar la tabla de direccionamiento de user modules, que es utilizada por la capa handler manager para poder enviar los datos al user module adecuado. A continuacin se presentan los diagramas de secuencia de las operaciones openDevice, closeDevice, sendData y receiveData que expone la USB4all API a las aplicaciones de usuario, para
En el caso de que la aplicacin envie datos a un ser delegados a la capa

handler layer

en la

poder explicar en forma detallada la sucesin de pasos que se realizan durante la invocacin de estas operaciones, de forma de brindar una visin ms adecuada del funcionamiento interno de toda la solucin

USB4ll.

6.2.1. Operacin openDevice

El diagrama de secuencia de la gura 6.14, muestra la cadena (simplicada) de invocaciones

u4aAPI

y pasos que se suceden cuando una aplicacin de usuario invoca la funcin para abrir un vnculo lgico con un

llegar al

consulta al

commandlayer, el cual, en primera instancia consulta al handlerlayer (a su vez, ste descriptorlayer ) para la obtencin de los nmeros de endpoints a utilizar para el
open
del

user module.

openDevice

del

Esta invocacin se propaga hasta

commandlayer ). Luego se construye un paquete del admin protocol y se invoca la operacin send del handlerlayer, ste construye un paquete del handler protocol y carga como destinatario al admin module (handler 0). El paquete construido es pasado al descriptorlayer, el cual invoca la operacin send apropiada para el tipo de transferencia que utiliza el admin module. Finalmente el driverlayer enva el paquete al driver genrico USB que este utilizando y ste lo enva por el bus USB. Luego del envo del paquete, el ujo de ejecucin vuelve al commandlayer para invocar la operacin receive del handlerlayer. Esta invocacin se propaga hasta llegar al driverlayer en
la que dependiendo del timeout indicado como parmetro se queda esperando la respuesta del

envo y recepcin de datos (los tipos de transferencias son parmetros de la operacin

baseboard, el main loop invoca peridicamente la operacin USBRead handler manager, para vericar si llegaron nuevos mensajes. Cuando llega el mensaje de apertura del user module enviado desde el PC, el handler manager lo procesa para obtener su payload, verica quin es el user module destinatario (en ste caso el admin module ) e invoca su operacin receive. El admin module procede a obtener el payload del paquete, verica si el nombre del user module indicado en el mismo est registrado en el base rmware (getUserTableDirection y existsTableEntry). Luego pide al loader module la direccin de memoria (getModuleInitDirection) de la operacin init del mdulo, pide al handler manager que realice el alta del user module en la tabla de mdulos activos (newHandlerTableEntry), obteniendo como resultado el handler del mismo. Finalmente invoca a la operacin init del user module, la cual almacena el handler que lo identica, le indica al handler manager la funcin del mdulo que debe llamar, para que el user module pueda recepcionar los mensajes enviados desde
Mientras tanto en el del el PC (getHandlerReceiveFunction) y nalmente, obtiene la direccin del buer de envo hacia el PC (getSharedBuffer). Al volver al apertura y se enva al

xito de la apertura.

admin module, se crea un paquete del admin protocol con la respuesta de la handler manager (USBWrite), ste construye el paquete del handler protocol

y lo enva al bus USB. Al llegar el mensaje al PC, el driver genrico USB devuelve el mensaje al

driverlayer que esperaba la respuesta del baseboard. Una vez que el ujo de ejecucin vuelve al handlerlayer, este obtiene el payload del paquete y lo devuelve al commandlayer que determina si la operacin de apertura del user module fue exitosa o no. Si fue exitosa, el mensaje recibido posee el handler asignado por el handler manager al user module abierto. Finalmente, el commandlayer registra toda la informacin relacionada al user module (registerModule) en el handlerlayer, construye el moduleID y lo devuelve a la aplicacin de usuario.

94

CAPTULO 6.

COMUNICACIN

Figura 6.14: Diagrama de secuencia de la operacin

openDevice

6.2.

INTERACCIN USB4ALL API

USB4ALL FIRMWARE

95

6.2.2. Operaciones sendData y receiveData

Figura 6.15: Diagrama de secuencia de la operacin

sendData

receiveData

El diagrama de secuencia de la gura 6.15, muestra la cadena (simplicada) de invocacio-

receiveData del u4aAPI

nes y pasos que se suceden cuando una aplicacin de usuario invoca la funciones para enviar y recibir informacin desde y hacia los ro se observa la invocacin de la operacin invocacin se propaga hasta el

handlerlayer

sendData por parte del programa de aplicacin, esta

donde se construye el paquete del

user module. Prime-

sendData

handler protocol,

96

CAPTULO 6.

COMUNICACIN

luego es enviado al

descriptorlayer (send),

de ah al

driverlayer

y nalmente el driver genrico

USB, que lo enva por el bus USB. Luego de realizado esto, se devuelve la respuesta de envo exitoso o no al programa de aplicacin. Algn momento despus el ejecuta la funcin load y el

handler

USBRead del handler manager receive

main loop

del

base rmware
en el

del paquete para identicar el

user module

y encuentra un mensaje nuevo. Obtiene el paydestinatario y una vez identicado

invoca la operacin

(que corresponde a la funcin que registr el

user module

momento de la apertura) y termina.

u4aAPI,

baseboard. Esta invocacin atraviesa los distintos componentes de la USB4all API hasta llegar al driverlayer donde queda esperando
pues se quiere recibir un mensaje proveniente del (segn el timeout indicado como parmetro) hasta que llegue un mensaje. En algn momento despus, sucede un evento (polling o interrupcin) en un dispositivo o en el que genera la invocacin de la operacin especca, genera un paquete del al PC y se lo pasa al

Ms abajo en el diagrama de secuencia, aparece la invocacin de la primitiva

receiveData del

user protocol con la informacin que el mdulo desea enviar handler manager (USBWrite) que construye un paquete del handler protocol

processIO

de un

user module.

baseboard

mismo,

ste ejecuta su lgica

y lo enva al bus USB. Cuando el driver genrico USB detecta que lleg el mensaje se lo pasa pasa el

driverlayer, que se haba quedado esperando algn mensaje del baseboard. Luego ese mensaje handlerlayer, donde se obtiene el payload con la informacin enviada por el baseboard y

nalmente se devuelve dicho payload al programa de aplicacin.

6.2.3. Operacin closeDevice

El diagrama de secuencia de la gura 6.16, muestra la cadena (simplicada) de invocaciones

u4aAPI

y pasos que se suceden cuando una aplicacin de usuario invoca la funcin

llegar al

protocol e invoca la operacin send del handlerlayer, ste construye un protocol y carga como destinatario al admin module (handler 0). El paquete construido es pasado al descriptorlayer, el cual invoca la operacin de send apropiada para el tipo de transferencia que utiliza el admin module. Finalmente el driverlayer enva el paquete al driver genrico USB
que este utilizando y ste lo enva el bus USB. Luego del envo del paquete, el ujo de ejecucin vuelve al propaga hasta llegar al

que se quiere cerrar se est usando (existsModule). Luego construye un paquete del

commandlayer, el cual, en primera instancia consulta al handlerlayer

para cerrar un vnculo lgico con un

user module.

closeDevice
si el

del

Esta invocacin se propaga hasta

user module admin paquete del handler

commandlayer para invocar la operacin receive del handlerlayer. Esta invocacin se driverlayer en la que dependiendo del timeout indicado como parmetro

se queda esperando la respuesta del xito del cierre.

Mientras tanto en el baseboard, el main loop invoca peridicamente la operacin USBRead del handler manager, para vericar si llegaron nuevos mensajes. Cuando llega el mensaje de cierre del user module enviado desde el PC, el handler manager lo procesa para obtener su payload, verica quin es el user module destinatario (en ste caso el admin module ) e invoca su operacin receive. El admin module procede a obtener el payload del paquete, le pide al handler manager que desregistre al user module identicado por el handler que viene en el payload de la tabla de mdulos activos (removeHandlerTableEntry). Luego pide al loader module la direccin de memoria (getModuleReleaseDirection) de la operacin Al volver al

release

del mdulo y nalmente la

admin module, se crea un paquete del admin protocol con la respuesta del cierre y handler manager (USBWrite), ste construye el paquete del handler protocol y lo enva al bus USB. Al llegar el mensaje al PC, el driver genrico USB devuelve el mensaje al driverlayer que esperaba la respuesta del baseboard. Una vez que el ujo de ejecucin vuelve al handlerlayer, este obtiene el payload del paquete y lo devuelve al commandlayer que determina si la operacin de cierre del user module fue exitosa o no. Si fue exitosa, el commandlayer desregistra toda la informacin relacionada al user module (unregisterModule) en el handlerlayer y devuelve el
se enva al resultado de la operacin a la aplicacin.

invoca.

6.2.

INTERACCIN USB4ALL API

USB4ALL FIRMWARE

97

Figura 6.16: Diagrama de secuencia de la operacin

closeDevice

98

CAPTULO 6.

COMUNICACIN

Captulo 7

Decisiones de Diseo e Implementacin

Introduccin
El diseo y la construccin de los distintos elementos de la solucin fu fruto de un proceso de desarrollo, que busco en todo momento seguir los objetivos planteados en el proyecto, trantando de respetar los distintos puntos de vista y aportes de forma de alcanzar un producto nal que represente los intereses de todos los integrantes del equipo. Algunos temas fueron motivo de discusin ya que no se lograron congenear las distintas visiones y fue necesario debatir en profundidad para lograr llegar a una decisin nal sobre el tema. Esta seccin intenta describir algunos de estos temas polmicos, mostrando las distintas alternativas existentes y como fu que se tomaron las decisiones, las misma se presentan divididas en tres grupos: que hacen referencia a temas que afectaban a toda la solucin y nalmente

rmware
7.1.

Decisiones en el PC.

Decisiones generales Decisiones en el

Decisiones Generales

Modo de uso Fachada

Este modo de uso de la solucin era uno de los objetivos planteados en este proyecto, la idea de fondo de su funcionamiento era poder simular el comportamiento de un dispositivo USB clasicado dentro del estndar, de forma de aprovechar los drivers especcos y todas las aplicaciones ya existentes en el PC. Un ejemplo de este modo fachada es la utilizacin de un conjunto de sensores de presin de forma tal que desde el PC se los reconozca como una batera MIDI, por ejemplo el golpear un sensor sera reconocido en l como un golpe de platillo. Luego de comenzado el diseo e implementacin inicial del proyecto se reconsider su inclusin dentro del alcance del mismo, pues se observ que a pesar de que tcnicamente era viable e interesante su aplicacin, existan varias opciones para su realizacin pero demasiado costosas en cuanto al tiempo. Adems no se lograba llegar a una arquitectura que permitiera unicar las dos modalidades de uso en forma armnica sino que la realizacin de una iba en contra sentido de las funcionalidades de la otra, como si fueran dos proyectos disjuntos. Teniendo en cuenta lo antes mencionado y que esta modalidad de uso era un objetivo secundario se decidi sacarla del alcance del proyecto y dejarla como trabajo a futuro (ver seccin 9.2 para ms detalles).

Adapterboard sin lgica programable

Una de las decisiones tomadas en el diseo de toda la solucin fue que los tuvieran lgica programable ya que esta funcionalidad recae sobre el los

user modules

adapterboard no conbaseboard donde ejecutan

que son los encargados de encapsular el conocimiento para la interaccin con es considerado en nuestra arquitectura como un conjunto de componentes

los dispositivos o en su defecto en las aplicaciones de usuario que corren en el PC. Bsicamente un

adapterboard

de hardware encargados de la conexin entre los 99

baseboards

y los dispositivos electrnicos que

100

CAPTULO 7.

DECISIONES DE DISEO E IMPLEMENTACIN

se quieren manejar. La expresin mnima que puede tener un contenga un

U4APort

adapterboard

es una placa que

y una salida que consista en la seleccin de un conjunto de seales para

conectar al dispositivo. El escenario tpico de uso es cuando existe una incompatibilidad entre las caractersticas de las seales del voltajes, diferentes potencias, etc.

baseboard

y del dispositivo a utilizar, por ejemplo diferentes

Tamao mximo de paquetes

El microcontrolador utilizado en este proyecto soporta velocidades de trasmisin Low y Full, lo implica segn el estndar USB una restriccin en los tamaos mximos de datos que se pueden trasmitir para los distintos tipos de transferencias. Frente a esta limitante se pensaron distintas alternativas como denir transacciones de paquetes, de forma de lograr superar esta cota y brindar a los ojos de los usuarios la exibilidad (slo limitada por los recursos de memoria disponibles en el ideas lentamente se fueron descartando pues introducan un grado de complejidad en el manejo de la memoria del microcontrolador para el almacenamiento temporal de los paquetes en trco y generaba una ineciencia importante del uso de la memoria frente aquellos casos en que no se necesitaba transaccionar paquetes. Todo esto llev a tomar la decisin de denir un nico tamao mximo de paquete de 64 bytes, que cumple en el mayor grado posible con los topes mximos establecidos en el estndar USB para los cuatro tipos de transferencias, logrando evitar de esta forma introducir en los protocolos de comunicacin:

baseboard ) en el tamao de la informacin que se puede enviar o recibir. Estas

handler protocol

admin protocol

y en lgica del

base rmware

los

mecanismos necesarios para la transaccionalidad de paquetes. Cabe destacar que a nivel del

user protocol,

la fragmentacin de la informacin a enviar o

recibir queda abierta a que los desarrolladores de antemano los volmenes de memora requeridos.

user modules

y de aplicaciones de usuario

puedan denir transacciones de mensajes como parte de su interaccin mutua, pues conocen de

7.2.

Decisiones en el Firmware

Carga y descarga de user modules a demanda

Esta idea surge frente a la realidad de la programacin del rmware de los microcontroladores, en los que se estila recompilar todos los cdigos fuentes cada vez que se realiza un cambio en los mismos. Para nuestra arquitectura esta prctica atenta contra la extensibilidad, modularidad y amigabilidad de uso, pues implica la modicacin del cdigo fuente del un (diseado para ser un ncleo estable en la solucin) cada vez que se quiera agregar o eliminar

base rmware

user module.

base rmware

La primera aproximacin a una solucin denitiva fue la eliminacin de las referencias del a los

user modules

por medio de la indireccin en la referencia de sus ubicaciones

base rmware y dejar USB4all rmware. El siguiente paso para lograr una independencia total entre los user modules y el resto de los componentes del USB4all rmware implicaba agregar un grado de indireccin en las referencias que utilizan los user modules hacia el resto de los componentes, esto se dej de lado no tanto por su aporte tcnico sino por su benecio minimal de funcionalidad y considerando que el base rmware es jo no vala la pena incurrir en la implementacin de esta caracterstica.
resulta una tcnica interesante dado permite evitar la recompilacin del abierto la cantidad de

en la memoria de programa del microcontrolador (por ms detalle ver la seccin 4.2.3), lo que

user modules

que se quieren agregar al

Por otro lado, ms all de poder resolver el tema de las dependencias mutuas entre los componentes del

USB4all rmware

existe el problema de donde ubicar cada

user module

en la

memoria de programa del microcontrolador y la resolucin de la localizacin de sus variables en memoria de datos. Todo esto fue debidamente investigado y se lleg a la conclusin de que es viable pero se decidi acotar su alcance, optndose por cargar un conjunto de fuerte en cuanto a la funcionalidad de poder cargar y descargar

user modules

al

mismo tiempo en una nica transaccin como si fueran un bloque. Esto no implica una restriccin

user modules

para ser usados en

distintos escenarios, simplemente se renuncia a que la carga sea dinmica.

7.3.

DECISIONES EN EL PC

101

Optimizacin de performance del handler manager

Como se explic en la seccin 4.2.2.1 el endpoints denidos en el

handler manager

es el encargado de la recepcin

y envo de los datos provenientes desde el PC por medio de la lectura y escritura de los distintos

baseboard. A continuacin explicaremos en concreto las optimizaciones

realizadas y sus justicaciones:

Optimizacin en la recepcin: Intuitivamente tendra sentido slo realizar el escrutio

de aquellos endpoints que estn siendo usados por algn vinculo lgico de un

user module,

pero a la hora de la implementacin el costo de consultar y almacenar en una estructura de datos que endpoint est activo en cada momento resulta mayor al que simplemente se tendra si se consultan todos. Esto tiene un sentido prctico ya que la tecnologa USB permite la existencia de como mximo diecisis endpoints y normalmente en el se denen en el entorno de cuatro.

baseboard

Optimizacin en el envo: El handler manager brinda un servicio a los user modules que
les permite obtener un buer de memoria de datos para que carguen en l la informacin que desean enviar al el PC (es el payload del buer fuera local al

handler manager

handler protocol ).

Lo normal sera que ese

para respetar el ocultamiento de informacin entre

capas pero por cuestiones de performance y optimizacin en el uso de memoria se decidi brindar la referencia de la posicin en la memoria compartida del endpoint asignado al

user module

para el envo de datos.

Admin module implementado como user module

Como parte del proceso de diseo de la arquitectura de software se observ que el componente

application layer ) en la estructura en capas de la comunicacin. Estos factores llevaron a tomar la decisin de implementar el admin module como un user module con la particularidad de que no necesita la
ambos se les asocia un para identicarlos y coexisten en la misma capa ( apertura en forma explcita desde el PC sino que se instancia durante el proceso de inicializacin del

admin module

tena muchos puntos de contacto con los

handler

user modules

como ser que a

base rmware.

Esta decisin tiene como ventaja la reutilizacin de todo el mecanismo de direccionamiento de paquetes que implementa el el componente en forma independiente del resto del

handler manager, adems se habilita la posibilidad de actualizar base rmware. Este enfoque se inspira en la

escencia del diseo de micro-kernels [31], en donde se mantiene dentro del ncleo del sistema lo mnimo indispensable y se traslada a mdulos toda la funcionalidad que puede ser actualiza o mejorada en forma independiente del mismo.

7.3.

Decisiones en el PC

USB4all API usa el patrn de diseo Singleton

Durante la tarea de construccin del diseo de alto nivel de la arquitectura de software de este proyecto, se detect la necesidad de que el subsistema

USB4all API

tuviera ciertas caracte-

rsticas que permitieran un uso sencillo y ordenado por parte de las aplicaciones de usuario que interactan con los dispositivos. La idea de utilizar el patrn Singleton [22] en la implementacin de la interfaz pblica de la misma, genera la ventaja inherente de que exista una nica instancia en memoria de la

USB4all API.

Esto tiene como benecios el evitar la existencia de mltiples instancias de la misma en las aplicaciones de usuario que llevaran a la necesidad de tener mecanismos de sincronizacin y control para evitar la apertura simultnea del mismo datos de un

user module

o el acceso a los datos que

llegan desde el medio USB en forma errnea, es decir, recibir en una instancia del

user modules

USB4all API

no registrado en ella.

Separacin del manejo del driver de la obtencin de los descriptores del baseboard

102

CAPTULO 7.

DECISIONES DE DISEO E IMPLEMENTACIN

La

USB4all API

basa su funcionamiento en la obtencin de la informacin de los descrip-

tores de cada uno de los un

baseboards

conectados al PC, de forma de identicar sus nmeros de

series y cantidades y tipos de endpoints. Esta informacin es utilizada por la

baseboard

API

para identicar

en particular o para saber si existen determinados endpoint que manejan los tipos

de transferencias de recepcin y envi requeridos al establecerse los vnculos lgicos con los

module.

user

Las opciones de drivers que se utilizaron en este proyecto para las distintas plataformas presentan distintas funcionalidades, algunas soluciones slo brindan las prestaciones para enviar y recibir datos y otras adems permiten obtener la informacin de los descriptores de los dispositivos USB. Esta diferencia entre las distintas implementaciones de los drivers genricos junto con la posibilidad de obtener la informacin de los descriptores del sistema operativo directamente, llev a tomar la decisin de aislar la lgica necesaria para la obtencin de los descriptores de los

baseboards

de la lgica de envo y recepcin de datos, logrando as no depender de la opcin de

driver seleccionada.

Adems, esta decisin tiene como benecio el encapsular en un nico componente de la toda la lgica de obtencin de descriptores de los quiere ejecutar la solucin, logrando independizar

API baseboard para cada plataforma en que se a la API del uso de drivers que soporten la

obtencin de la informacin de los descriptores y permitiendo reutilizar la lgica de obtencin de descriptores entre los distintos drivers de una plataforma.

Un le por baseboard conectado

En los sistemas Unix todos los componentes de hardware se mapean a un descriptor de archivo por lo tanto se estudiaron dos opciones para la interaccin entre el driver genrico que se construyo y las aplicaciones de usuario. Una de ellas era tener un descriptor de archivo para cada endpoint que existe en el

baseboard,

esta opcin simplica el uso del driver pues elimina

la necesidad de congurar el tipo de transferencia, direccin del endpoint, etc. previo al envi o recepcin de datos pero tiene como desventaja el aumento en la complejidad del manejo del conjunto endpoints pues no existe nico punto de acceso. La otra opcin es tener un nico descriptor de archivo para todo el

baseboard

y por medio

de l poder obtener la informacin de los endpoint disponibles utilizando previo al envo o recepcin de datos una etapa de conguracin del endpoint que se desea manipular. Debido a la mayor simplicidad en la implementacin se opt por esta ltima opcin ms all del esfuerzo de conguracin previo a cada comunicacin con el driver aunque al ser reducida la cantidad de las mismas se logr encapsular en funcionalidades claramente denidas.

Parte III

Experimentos y Resultados

103

Captulo 8

Artefactos construidos
8.1. Introduccin
En el marco de este proyecto fue necesario la construccin de un conjunto de artefactos de software, hardware y rmware, de los cuales algunos de ellos son parte estructural de la arquitectura, como es el caso del

baseboard, en el cual se presenta una descripcin de su proceso adapterboards, user modules, proxies
y dispositivos que

de evolucin destacando las principales caractersticas de cada etapa. Adems se construyeron un conjunto de aplicaciones de usuario, permitieron mostrar las cualidades tcnicas as como la viabilidad del uso de la solucin en escenarios reales y de prototipados rpidos. Adems se hace una descripcin de un utilitario que se entrega en forma conjunta con la solucin y que permite la conguracin de las propiedades del

baseboard.

8.2.

Hardware

Uno de las requisitos ineludibles para la conexin con dispositivos electrnicos externos al PC es el uso de un hardware mediante el cual interactuar con dichos dispositivos. En el contexto de este proyecto, si bien se poda haber optado por usar un kit de desarrollo y adaptarlo a tales nes, se consider desde un primer momento el desafo del diseo y la construccin de un hardware a medida como parte del los objetivos. Esta decisin, si bien aumenta la complejidad del proyecto pues involucra reas de conocimiento que no estn abarcadas en la carrera de computacin, permite por un lado disminuir los costos y el tamao del hardware, ya que slo se utilizan los elementos adecuados para tal n y no los elementos extra que normalmente contienen los kits de desarrollo. Otra ventaja obtenida en el diseo construido, es la forma modular y constructiva lo que contribuye al reuso y extensibilidad de las capacidades del mismo. Para el desarrollo y construccin de los prototipos se intent utilizar siempre que fue posible muestras comerciales gratuitas, principalmente de microcontroladores y sensores, tanto para disminuir los costos, como por la dicultad de conseguir algunas de estas piezas en la plaza de semiconductores uruguaya. En algunas ocasiones tambin fue necesario reciclar componentes de partes de hardware en desuso, como es el caso del conector USB. Para la construccin de circuitos impresos en general se utiliz la tcnica que consiste en el planchado de una transparencia (realizada en impresora lser) en una chapa laminada FR10, luego de lo cual, se sumerge la chapa en percloruro frrico para eliminar el cobre sobrante. Excepcionalmente para una versin ya depurada de el

baseboard

se recurri a el encargo de

fabricacin del mismo a la empresa ENEKA SA. Si bien se realizaron ms prototipos de los que se describen en esta seccin slo se presentaran los ms relevantes.

8.2.1. Evolucin del Baseboard

Como ya se explic es el componente de hardware que siempre est presente para interactuar con dispositivos electrnicos desde el PC. Esta es la parte de hardware que sufri ms cambios a lo largo del proyecto, y debido a ello se desea comentar algunas instancias en su proceso de desarrollo. Hubo cinco versiones en su proceso de desarrollo y a continuacin de detallan las motivaciones, caractersticas y nalidades que tuvo cada versin: 105

106

CAPTULO 8.

ARTEFACTOS CONSTRUIDOS

Versin 0.2: En esta primera versin el trabajo se concentr principalmente en lograr un

diseo del circuito impreso pequeo y compacto, logrando una distribucin de los componentes principales adecuada para que sea cmodo el acceso fsico a los conectores RJ11, USB y

U4Aport, as como tambin facilidad de uso de los pulsadores. Era importante mi-

nimizar la longitud de algunas pistas de cobre, como tambin eliminar el uso de cables para realizar saltos entre pistas cuando no era posible rutearlas en una sola faz de cobre, pero sto no fue prioritario. A pesar de que la motivacin de la creacin de este prototipo no persegua que fuera funcional (no era necesario soldar los componentes), igual se testeo la tcnica de planchado de transparencia para obtener experiencia. En la parte superior izquierda de la gura 8.1 se muestra una imagen de la placa con sus componentes principales.

Versin 0.4: Luego de haber ubicado los componentes principales, la meta fue acercarse
a un prototipo funcional del mismo, para ello en la versin 0.4 se mejor el ruteo y ancho de las pistas, debido a que se not en la version anterior a veces quedaban en contacto algunas de ellas luego del proceso de planchado. Otra caracterstica que tambin se mejor fue el aumento del ancho de las pistas alrededor de los agujeros, pues en algunos casos, luego de perforados en la placa, quedaba muy poco cobre para soldar el componente de manera robusta. Otra requerimiento que se estim necesario, fue dejar espacio en las 4 esquinas como para realizar agujeros que permitieran armar la placa a un gabinete, para ello se modic la posicin de la cha RJ11 y USB para que estuvieran ms juntas y hacia el medio de la placa. En esta versin tampoco fueron soldados los componentes. En la imagen superior derecha de la gura 8.1 se ve la cara posterior del observar el diagramado de las pistas.

baseboard

pudindose

Figura 8.1: Evolucin del

Baseboard

Versin 0.6:

Esta versin fue la primera en la que se plante alcanzar un prototipo

funcional. Se agreg alrededor de la placa un borde de cobre que sirve de tierra, se soldaron todos los componentes y se teste. Al conectarse al PC, se not que tena un funcionamiento errtico, as como tambin se sucedan errores espordicos en su programacin (errores de checksum al grabar el rmware). Luego de revisado el circuito se observ la omisin de un componente (capacitor para la regulacin de voltaje USB). Al agregar de manera provisoria el mismo, resulto en un funcionamiento correcto y ausencia de errores aleatorios, logrando satisfacer el objetivo planteado. Esta versin se muestra en la parte inferior izquierda de la gura 8.1.

8.2.

HARDWARE

107

Versin 0.8: Se agreg el componente omitido en la versin anterior, se ensancharon las

pistas de transmicin de voltaje de alimentacin (Vcc y Gnd) en todo el circuito. Tambin se eliminaron algunas pistas de conexin entre el microcontrolador y el

U4Aport

para evitar

problemas de programacin en caso de que haya algn dispositivo conectado en el momento de utilizar el programador ICD2 para grabar el bootloader en el microcontrolador. Para tener ms espacio, una esquina se sustituyeron las resistencias de 1/4 por 1/8 de watt y se juntaron un poco ms los pulsadores de bootloader y reset. Tambin se minimiz la longitud del trazo de las pistas de datos de USB para disminuir interferencias de dichas seales al llegar al microcontrolador.

Versin 1.0: Esta es la versin nal del baseboard

y su objetivo principal era permitir que

sea fcilmente replicable. Para atender esta necesidad se deban generar archivos en uno de los formatos estndar para la fabricacin automtica de circuitos impresos (GERBER), de manera de que se pueda encargar a un tercero su fabricacin. Si bien se trata de un estndar, cada proveedor requiere algunas caractersticas y nombres de archivos particulares, en nuestro caso se opt realizarlos (utilizando el servicio PLAKA-circuitos impresos) en ENEKA SA. Finalmente se logr obtener un

baseboard

de manera satisfactoria utilizando

esta forma de construccin. El resultado nal, luego de soldados todos los componentes se muestra en la parte inferior derecha de la gura 8.1. Como resultado de este proceso evolutivo por el cual fue transitando el un hardware con un diseo adecuado y construccin reproducible del de los objetivos del proyecto. En la siguiente seccin se muestran

baseboard se logr obtener baseboard, completando uno los distintos adapterboards y

dispositivos que se fueron construyendo durante el desarrollo del proyecto.

8.2.2. Adapterboards
8.2.2.1. USB4all-protoboard
adapterboard cumple una funcin simple pero muy til a la hora de prototipar dispoadapterboards complejos que requieren ms hardware), facilitando la seleccin de las seales provenientes del baseboard (U4Aport ) mediante cables nos para posteriormente conectarlos a un protoboard. Como ya se dijo anteriormente, este adapterboard es muy sencillo, ya que slo cumple la funcin de seleccionar algunas seales del U4Aport para su posterior uso. En la gura 8.2 se muestra este adapterboard, como vemos consiste en un conector que por medio de un cable un cable chato de 40 pines se conecta al baseboard y por otro lado un par de zcalos
Este sitivos (o torneados SIL de 20 pines que permiten encastrar los cables nos para llevar las seales necesarias a un protoboard. La disposicin de estos zcalos permiten obtener facilmente las seales provenientes del microcontrolador, pues estn ordenadas de la misma manera que ste. Tambin se cuenta con un par zcalos de cinco pines a los costados para obtener las lineas de alimentacin de tierra y 5 volts provenientes del conector USB del PC.

Figura 8.2: Imagenes del USB4all-Protoboard

adapterboard.

108

CAPTULO 8.

ARTEFACTOS CONSTRUIDOS

8.2.2.2. Stepper motor adapterboard

Como no es posible conectar directamente las seales de salida del bobinas del motor paso a paso unipolar, es necesario un cuatro mosfets de potencia, junto con algunas

baseboard para manejar las adapterboard. Este est compuesto por resistencias. Este adapterboard slo se prototip

en un protoboard, utilizando el USB4all-protoboard. Como tampoco es suciente la potencia brindada por el USB, se necesita una fuente externa de energa para poder hacer funcionar el motor. En la gura 8.3 se muestra una foto del mismo.

Figura 8.3: Imagen del stepper motor

adapterboard

8.2.3. Dispositivos
8.2.3.1. Motor paso a paso (unipolar)
Utilizando el

adapterboard

mostrado en la seccin 8.2.2.2 se puede conectar un motor paso a

paso unipolar. Este dispositivo es muy simple y con la lgica de mediante comandos tales como Se realizaron dos

user modules, el primero llamado motor interrupt proxy

mover(pasos,sentido), setVelocidad(velocidad), stop().

para un testeo de la lgica del manejo que controla los tiempos de encendido de

user modules

se puede controlar

del motor paso a paso pero que utilizaba un mecanismo de polling para medir el tiempo, y luego otro llamado motorISR que utiliza un las bobinas mediante el mecanismo de interrupciones En la gura 8.4 se muesta una imagen del

baseboard, USB4all-protoboard, stepper motor adapterboard, motor y fuente externa.

Figura 8.4: Dispositivo motor paso a paso

8.2.

HARDWARE

109

8.2.3.2. Sensor de Temperatura

Este dispositivo est implementado mediante un sensor de temperatura de Texas Instrument TMP101 que utiliza la interfaz Serial Peripheral Interface (SPI) obtenido como una muestra gratuita. Hubo que realizar un conversor de SMT a DIP para poder utilizarlo en el protoboard. Tambin utiliz USB4all-protoboard para realizar las conexiones de las seales utilizadas. En la imagen 8.5 se puede observar ste dispositivo.

Figura 8.5: Dispositivo sensor de temperatura.

8.2.3.3. Display
Este dispositivo est implementado mediante un display de siete segmentos, y una resistencia de 330 Ohm para cada uno de ellos. El

user module

correspondiente para su manejo permite,

a partir de un nmero recibido desde el PC transformarlo en las seales de cada segmento del display necesarias para la construccin visual del nmero. En la imagen 8.6 se puede observar ste dispositivo.

Figura 8.6: Dispositivo display 7 segmentos

110

CAPTULO 8.

ARTEFACTOS CONSTRUIDOS

8.2.3.4. USB4bot
La construccin del USB4bot se realiz en el marco de un prototipado rpido para la 4ta competencia de sumo robtico [32] organizada por el grupo MINA del Instituto de computacin (InCo). Para ello se implement un enlace inalmbrico con el robot. El

user module que controla un radiocontrol para facilitar el adapterboard utilizado consta de dos DAC que permiten

convertir seales digitales en analgicas para generar distintos niveles de voltajes que logran simular el movimiento fsico de los controles de direccin del radiocontrol, que a la postre se convierten en distintas velocidades en los motores del robot.

Figura 8.7: Diagrama de funcionamiento USB4bot.

Este es un caso tpico de un dispositivo que no fue pensado para interactuar con un PC y mucho menos con la tecnologa USB. En la gura 8.7 se muestra de manera esquemtica todos los componentes que interactan para poder controlar el robot mediante el PC. Se contaba con la inteligencia del robot de la edicin anterior del campeonato realizada en Java (jugador BOTija), por lo que tambin se utilizaron todas las capas de software construidas dentro del PC, el driver USB genrico construido para Linux y la

USB4all Library.

Si nos centramos en lo que reere

slo a la comunicacin entre el PC y el radiocontrol los elementos o artefactos que debieron ser construidos o integrados junto a sus tiempos asociados a su elaboracin y testing se muestran a continuacin: Creacin del

user module

USB4bot: 2 horas/hombre.

Extencin del componente USB4allDevice correspondiente a la 15 minutos/hombre. Integracin BOTija

USB4all Library (USB4bot):

USB4all Library :

Esta integracin result ser muy sencilla, ya que

slo hubo que cambiar algunas lneas: 15 minutos/hombre.

Adapterboard :

la mayor parte del tiempo fue insumida en la construccin de los DAC.

Hubo que modicar el radiocontrol sacando hacia el exterior las seales provenientes de los potenciometros de los controles de direccin para poder inyectarle seales a n de simular el movimiento de los mismos. Esto llev un tiempo aproximado de 10 horas/hombre.

8.2.

HARDWARE

111

Teniendo en cuenta estos tiempos, que son signicativamente menores que el tiempo de construccin y calibracin del robot, se considera un tiempo ms que apropiado para la integracin con un dispositivo no pensado para interactuar con un PC. En la gura 8.8 se muestra el testing del prototipo de un DAC conectado a un un voltmetro y leds para visualizar el estado de cada uno de los bits de entrada al DAC y vericar su correcto funcionamiento. Adems, se visualizan parte de los componentes de hardware del robot, as como una de las luchas en Campeonato Uruguayo de Sumo Robtico edicin 2007 [32].

Figura 8.8: Imagenes de la construccin y vericacin del USB4bot.

Figura 8.9: Evento Sumo.uy 2007

112

CAPTULO 8.

ARTEFACTOS CONSTRUIDOS

8.3.

Software

Adems de todo el software y rmware que componen la arquitectura, tambin se realizaron diversas aplicaciones de usuario, las cuales utilizan en algunos casos la directamente la

USB4all API

USB4all Library y en otros

para vericar su equivalencia de uso. Tambin se construy un

programa utilitario que permite la conguracin del

se describe las caractersticas de esta herramienta, llamada

baseboard en forma amigable. A continuacin USB4all baseboard utility.

8.3.1. USB4all baseboard utility

Esta herramienta es la encargada de dos tareas principales: por un lado la conguracin de los descriptores USB y por otro, la tarea de carga de

user modules

proxies

al

baseboard.

Esta

aplicacin fue desarrollada en Java, lo que permite su uso en varias plataformas. En lo que reere a la conguracin de los descriptores, este utilitario permite denir toda la informacin que el dispositivo USB intercambia con el PC en el proceso de enumeracin. En el caso del

baseboard

en particular, son de vital importancia la denicin tanto de la cantidad

y tipo de endpoints que ste contiene, como tambin el nmero de serie con el cual se va a identicar. Es importante destacar lo poderosa que es esta funcionalidad y lo sencillo que es utilizarla, ya que este tipo de conguracin normalmente est restringida a su implementacin mediante cdigo de rmware jo. Dado que uno de los objetivos iniciales fue brindar facilidad de uso, inclusive a usuarios con muy poco conocimiento, fue necesario invertir un tiempo importante para la implementacin de un mecanismo muy sencillo de usar. El camino elegido para realizar esta funcionalidad fue la de generacin de cdigo fuente de manera automtica as como su posterior grabacin en el microcontrolador por medio de un

user module

dedicado a tales nes, el

Bootloader module.

Debido a la interaccin que debe realizarse con un proyecto de MPLAB, compilador y linkeditor, adems de haber sido necesario un conocimiento en detalle de el formato de los archivos .HEX, hacen de esta aproximacin una solucin compleja de implementar, pero permite un uso muy sencillo. Si bien estn implementados todos los mecanismos necesarios para esta tarea, no se lleg a la meta de brindar una interfaz grca de modo que el usuario pueda pueda interactuar de manera ms amigable. Provisoriamente se brinda un ejemplo de cdigo fuente que puede ser modicado a los efectos de congurar un

baseboard

con los descriptores deseados.

La otra tarea que lleva a cabo este utilitario es la carga de

Para realizar esto, slo es necesario seleccionar de un conjunto de

user modules y proxies al baseboard. user modules y proxies, los

cuales van a ser cargados en la memoria de programa del microcontrolador. Como ellos ocupan memoria de programa en espacios reservados segn el mapa de memoria presentado en la seccin 4.2.6 pueden grabarse de manera independiente al resto del rmware. Para la realizacin de este mecanismo tambin se necesit una interaccin con un proyecto MPLAB, compilador y linkeditor para poder luego grabar el conjunto de elementos seleccionados. Una aclaracin importante es que debido a la dependencia que se agregan en las dos tareas principales de este mdulo con el MPLAB, compilador y linkeditor MPLAB C18 limitan el uso de este utilitario a la plataforma Windows.

Captulo 9

Conclusiones y Trabajo a Futuro

9.1. Conclusiones
El desarrollo de este trabajo planteo una variedad de desafos como ser la construccin de los baseboards y la programacin de su microcontrolador entre otros, que mediante un importante esfuerzo de investigacin y experimentacin se pudieron superar. Una caracterstica particular de este proyecto fue el proceso de maduracin que sufrieron sus objetivos en las primeras etapas de trabajo, pues se comenz con un conjunto inicial muy general y luego del esfuerzo importante de investigacin del estado del arte de las distintas temticas involucradas (desconocidas para el grupo) se logr depurarlos a un conjunto de objetivos ms concretos pero igual de ambiciosos a los propuestos inicialmente. Esto tuvo como consecuencia que la fase de investigacin del estado del arte y denicin del alcance del proyecto se extendiera ms de lo deseable y junto con una dicultad mayor a la esperada en el aprendizaje de las tcnicas de construccin del hardware y programacin de su rmware impactaron en forma negativa en el tiempo de nalizacin del proyecto. De todas formas se contaron con algunos elementos que permitieron mitigar en parte la duracin del proyecto, como fueron, el curso Taller de Firmware dictado por la Facultad de Ingeniera y la placa PICDEM FSUSB de Microchip proporcionada por el tutor que se utilizaron en la experimentacin realizada en las primeras etapas de desarrollo. La utilizacin durante todo el proyecto de herramientas como Wiki [33] para la documentacin y actas de reuniones, Mantis [28] para el reporte y seguimiento de defectos y fallas y CVS [11] para el control de cambios de los cdigos fuentes y documentacin, permitieron una buena coordinacin del trabajo entre los integrantes del equipo y se evalu como positivo. Otro aspecto relevante de destacar del proceso de implementacin fue la estrategia de aislar los desarrollos del

USB4all rmware, drivers y USB4allApi

por medio del uso de algunos prototipos

descartables que permitieron reducir los posibles factores de riesgo, lograr un mayor grado de paralelismo en la programacin y facilitar la integracin a posterior.

Caractersticas de la solucin construida

Al nal de este trabajo se pudieron cumplir con casi la totalidad de los objetivos propuestos para este proyecto destacando las siguientes caractersticas de la solucin.

Integral: La solucin est compuesta por hardware y software que permite ocultar toda la
complejidad existente entre las aplicaciones de usuario y los dispositivos electrnicos. Del estudio del estado del arte se vi que en general, las soluciones existentes se dividen en las que slo contemplan el hardware (algunas incluyendo un soporte mnimo para la PC) y las que se centran en la problemtica de los drivers del PC y no en las dos reas al mismo tiempo en forma conjunta.

Dispositivo genrico: El baseboard

se clasica en el estndar USB como un dispositivo

Custom y no en otra clase especca, que limitara a un subconjunto los dispositivos a conectar. Esta caracterstica genera que los sistemas operativos no puedan asignar un driver por defecto como lo haran frente a clases de dispositivos especcos como son HID, CDC, Audio, etc. Para solucionar esta dicultad se utiliza nico driver USB genrico que 113

114

CAPTULO 9.

CONCLUSIONES Y TRABAJO A FUTURO

implementa todos los tipos de transferencias de forma de no necesitar un driver especico para cada dispositivo en particular.

Protocolo abierto y user modules inteligentes: La solucin brinda un protocolo de

comunicacin entre las aplicaciones de usuario y los los

user modules

sin restricciones en cuan-

to a su contenido permitiendo el uso de los mismos a demanda. Si adems sumamos que

user modules

tienen la libertad de implementar con mayor o menor grado de inteligen-

cia el manejo de los dispositivos, obtenemos una forma de solucionar la interaccin con dispositivos cuyas restricciones de tiempo no pueden ser procesados desde las aplicaciones de usuario en el PC.

Constructivo: Brinda la posibilidad de componer las funcionalidades de manejo de dispositivos que brindan los

user modules

en las aplicaciones de usuario del PC de forma

de resolver problemas de mayor tamao y complejidad. En otras palabras, la aplicacin de usuario del PC se encarga de manipular a cada uno de los dispositivos electrnicos participantes de la solucin de forma de lograr un accionar en conjunto. Esto redunda en multiplicidad de benecios, entre los que se destacan: la reutilizacin de

user modules

en

distintos escenarios de uso, la delegacin de la complejidad de la coordinacin (lgica) entre ellos hacia la aplicacin de usuario donde se cuenta con mayor cantidad recursos, facilidad de programacin y nivel de abstraccin evitando la programacin directa del rmware del microcontrolador.

Multi-instancia de baseboards: La capacidad de manejar dispositivos electrnicos no

est limitada a un solo baseboard por PC, sino que la solucin fue diseada para soportar varias instancias de baseboards en forma conjunta. En otras palabras, si las posibilidades de conexin de dispositivos en un baseboard se ven excedidas frente al problema a resolver, simplemente se puede conectar otro baseboard al PC y conectar los dispositivos faltantes sin que este tengo un impacto importante en la aplicacin de usuario. Esta caracterstica hace que las soluciones sean escalables en el tiempo, ya que al aumentar las necesidades de manejo de dispositivos de una solucin ya existente simplemente se deben agregar nuevos baseboards para el manejo de los dispositivos adicionales.

Multi-plataforma:

El diseo fue pensado para soportar cualquier plataforma debido a

que su ncleo solo utiliza funciones estndar de C++ [8] y se encapsulan las funcionalidades de interaccin con los sistemas operativos y drivers en forma estructurada para cada plataforma especca. Dentro del alcance de este proyecto solo se implement para funcionar en las plataformas Linux y Windows.

Multi-lenguaje de programacin para aplicaciones: Las funcionalidades bsicas del

sistema en el PC (

USB4all API )

estn disponibles como una biblioteca de vinculacin

dinmica (.dll en Windows o .so en Linux), lo que permite que sea utilizada por cualquier lenguaje de alto nivel que soporte este tipo de bibliotecas.

Orientacin a objetos: Para facilitar el uso de la solucin as como ampliar el espectro

de usuarios, se propuso a manera de ejemplo una jerarqua de clases que logra abstraer los conceptos de baseboard y dispositivos en clases base, las que habilitan la especializacin para dispositivos particulares por parte de los usuarios. Esto genera el benecio de utilizar las caractersticas de los lenguajes orientados a objetos sin perder las funcionalidades que se brindan a nivel

USB4all API.

No uso de conversores USB-Serial: A diferencia de otras soluciones que hacen uso de

conversores USB-Serial se opto por no utilizarlo debido a que esto sacrica gran parte de las prestaciones que ofrece la tecnologa USB como son los tipos de transferencias, cantidad de endpoints, tamaos de buers y velocidades de trasmisin entre otras. Esta eleccin nos permite tener un mayor grado de granularidad y exibilidad para la asignacin de los recursos USB a los

user modules,

as como evitar los posibles cuellos de botella en la

comunicacin que introduce utilizar dicho conversor.

Costos econmicos: La casi totalidad de los costos de la solucin se centran en los elementos que conforman el hardware del

baseboard, los cuales rondan en el mercado uruguayo

para una unidad un valor de $700 pesos (USD 32) el microcontrolador y los componentes

9.1.

CONCLUSIONES

115

electrnicos y alrededor de $500 (USD 23) la fabricacin del circuito impreso en ENEKA. Estos precios convierten al producto en una opcin que compite con otras soluciones tanto open source como propietarias.

Open Source Software y Hardware: La totalidad de los fuentes del software y rmware
se encuentra a disposicin de la comunidad bajo la licencia GNU-GPL [23] y para el hardware se presentan los esquemticos, el diseo del PCB incluyendo formato Gerber y toda la documentacin de construccin asociada a n de que sea fcilmente reproducible.

Aportes de la solucin
La solucin construida permite resolver algunas falencias detectadas luego de relevar el estado del arte, as como cumplir satisfactoriamente con el objetivo primario de este proyecto de grado adems de introducir innovaciones propias. A continuacin se muestra un resumen de los aportes ms signicativos de la solucin:

Extensin del dominio de accin del PC y dispositivos: Esta caracterstica puede

verse desde dos pticas distintas, la del PC y la de los dispositivos electrnicos. Desde el PC se logra expandir las capacidades de interaccin con el mundo fsico que lo rodea, permitiendo aumentar los recursos disponibles con que normalmente cuenta. Esta posibilidad habilita plantear nuevos escenarios de uso as como resolver necesidades ya existentes. Desde la perspectiva de los dispositivos electrnicos, la interaccin con el PC les permite contar con los recursos de procesamiento, almacenamiento y comunicacin del mismo logrando expandir sus capacidades de uso. A modo de ejemplo, si pensamos en un dispositivo sencillo como un sensor de temperatura que normalmente slo funciona como un termmetro indicando la temperatura en un display, al incorporarle las capacidades de un PC se puede llevar una estadstica de temperaturas por perodos de tiempo, publicar la temperatura en una pagina web en tiempo real, etc. Esto es til en los escenarios donde ya se cuenta con un PC y se le agrega la capacidad de interaccin con dispositivos electrnicos, tambin es aplicable cuando se intenta dar uso a PCs antiguas (Pentium I o superiores) como recurso dedicado, y nalmente para la creacin de sistemas embebidos en los cuales con ms frecuencia se utilizan placas madre de PC en formato reducido con los sistemas operativos habituales. Resumiendo, el sistema USB4all permite obtener lo mejor de ambos mundos.

Desarrollo guiado y amigable: Como parte de la solucin se presenta una metodologa

de uso e implementacin que permite un desarrollo guiado y amigable para la perspectiva de un programador. Para acelerar los tiempos de aprendizaje en el uso del sistema, se proveen de templates o esqueletos de los

user modules

y proxies en el rmware y una jerarqua

de clases base en Java de las cuales se pueden extender para la realizacin de dispositivos especcos. Estos templates son ejemplos que denen los contratos necesarios que deben ser respetados para la integracin con las dems partes del sistema que logran abstraer al usuario de toda la complejidad inherente a la tecnologa USB y de los vnculos lgicos entre las aplicaciones de usuario y los

user modules.

Otra caracterstica relacionada con lo amigable de la solucin, es que a diferencia de otros productos relevados en el estado del arte que proveen una solucin slo para el hardware o slo para el software, USB4all elimina por completo los problemas de integracin entre el hardware y software, ya que brinda una respuesta integral a ambas problemticas. Por ltimo el

USB4all system

cuenta con un utilitario con interfaz grca que permite la

denicin de los descriptores USB, la generacin de su cdigo fuente, compilacin y actualizacin del baseboard, sin la utilizacin de un programador (va USB). Esta informacin es utilizada por el baseboard al momento de enumerarse como dispositivo USB en el PC, para diferenciarse de otros baseboard, as como para establecer los vnculos lgicos entre las aplicaciones de usuario y los

user modules.

Perles de usuarios: El sistema USB4all

jerarqua de clases, los

contempla a distintas clases de usuarios sepa-

rndolos en bsicos, avanzados y especialistas segn su nivel de conocimiento de la solucin. Los usuarios bsicos son aquellos que slo desarrollan aplicaciones de usuario utilizando la

user modules,

los adapterboard, los proxies y los dispositivos elec-

trnicos ya existentes para lograr manejarlos en forma coordinada. Luego estn los usuarios

116

CAPTULO 9.

CONCLUSIONES Y TRABAJO A FUTURO

avanzados que poseen un mayor grado de conocimiento de la arquitectura y dispositivos hardware permitindoles adems del desarrollo de aplicaciones de usuario la construccin de

user modules

siguiendo los templates, construccin de adapterboards y el desarrollo

de nuevas clases que extiendan la jerarqua de dispositivos. Por ltimo estn los usuarios especialistas que adems de todo lo descrito anteriormente poseen un conocimiento detallado de la arquitectura

USB4all

(microcontrolador, plataforma, drivers, USB, etc.) que

los habilita a construir proxies, extender el uso de la API a otras plataformas o drivers y poder hacer cambios funcionales en los propios componentes del sistema.

Fomenta la colaboracin entre usuarios: Debido a que solucin es de carcter libre

(open source software y hardware) y los

user modules, proxies

y clases de la jerarqua

son autocontenidos e intercambiables, se favorece el reuso de los mismo frente a distintos escenarios y se habilita la colaboracin entre usuarios. Esto ltimo tiene como ventaja que los usuarios bsicos (la mayora) se benecien de los aportes de usuarios con mayor nivel de conocimiento que compartan sus aportes de forma de crear una comunidad.

Apoyo a tiempo real: La facilidad de incorporar funcionalidad especca por medio de

los

user modules

y el manejo el mecanismo de atencin de interrupciones del

dynamicISR,

permiten mejorar las condiciones de atencin de eventos que requieren respuestas en tiempo real debido a que se evita el tiempo de latencia en la comunicacin que existira si la lgica se encontrara en el PC. El nivel de complejidad de las respuestas a estos eventos determina si pueden ser implementadas en los

user modules

o necesariamente deben residir

en el PC, para este ltimo escenario la tecnologa USB ofrece la alternativa del tipo de transferencia Interrupt el cual permite consultar frecuentemente (cada 100 ms por ejemplo) si los dispositivos poseen informacin para enviar al PC. Estas dos caractersticas dejan abierto al usuario la posibilidad de construir soluciones que combinen la atencin de eventos directamente desde los las necesidades de los problemas.

user modules

o desde el PC segn

Driver USB genrico para Linux: Se implement un modulo de kernel que auspicia de
driver USB del

baseboard

donde sol se colocaron los elementos necesarios para la obtencin

de los descriptores USB y de los mecanismos para lograr el envo y recepcin de datos. Cabe destacar que este driver no slo funciona con esta solucin sino que puede ser usado para manejar cualquier tipo de dispositivo USB.

user modules, la existencia de una jerarqua de clases Java que modela los dispositivos baseboard para distintos usos, permiten brindar una base inicial para el desarrollo de nuevas
rar electrnicos, la posibilidad de congurar los descriptores USB y la reutilizacin del soluciones que disminuye los tiempos de construccin, integracin y vericacin a la vez que facilita su elaboracin pues el desarrollador se centra nicamente en el comportamiento del dispositivo electrnico y no en como es la comunicacin desde el PC.

Prototipos rpidos: La conjuncin de caractersticas tales como: la facilidad de incorpo-

9.2.

Trabajo a Futuro

La solucin construida durante este proyecto de grado alcanz la mayora de los objetivos planteados inicialmente, durante el proceso se fueron incorporando nuevas caractersticas a las ya planicadas y tambin fueron necesarios ajustes en su alcance. A continuacin se presentan los posibles trabajos a futuro separados en tres grupos: objetivos eliminados del alcance, oportunidades de mejora e investigacin.

Objetivos eliminados del alcance

Actualizacin de User Module va USB en forma independiente: La idea principal
consiste en tener un mecanismo de carga y descarga de

user modules

similar al proporciotambin

nado por el sistema operativo Linux. Con esto se obtiene el benecio de no ser necesario recompilar todo los fuentes para agregar, eliminar o modicar un

user module,

se proporciona un mecanismo que permite comenzar con un entorno mnimo e ir extendindolo segn las necesidades del usuario. Otra ventaja es que se elimina la necesidad del

9.2.

TRABAJO A FUTURO

117

uso del entorno de desarrollo para extender el rmware, con lo cual se facilita el uso para los usuarios bsicos, este mecanismo tambin permite compartir de forma muy sencilla

user modules
en el

entre usuarios similar al mecanismo de plugins. Actualmente se cuenta con la

facilidad por medio de un utilitario (solo disponible para plataforma Windows) de cargar todo el conjunto de

user modules sobrescribiendo los contenidos previamente existentes USB4all Firmware, por ms informacin referirse a la seccin 8.3.1. Un problema

relacionado con este tema es resolver la fragmentacin que se genera al cargar y descargar mdulos dinmicamente.

Aplicacin Bootloader en PC integrada a utilitario desarrollado: Actualmente se

utiliza la aplicacin de Microchip (slo para Windows) para interactuar con el bootloader que se encuentra en el rmware, dado que se tuvo que investigar el formato del HEX para la aplicacin utilitaria desarrollada, la idea es reutilizar el conocimiento para integrarla a la aplicacin existente. De esta forma se elimina la dependencia de aplicaciones de terceros y se cuenta con una aplicacin integrada la cual es multi-plataforma. Para lograr esto se debera modicar el bootloader.

USB4all API

para que interacte con los

baseboards

en modo

Transferencias iscronas (no soportada por los drivers existentes): LibUSB actualmente no soporta transferencias iscronas, Microchip segn la documentacin de su driver las soporta pero le fueron encontrados bugs, pero como es propietario no se cuenta con los fuentes para solucionarlo. Esta fue una de las motivaciones para el desarrollo del driver propio para Linux, pero por temas de tiempo se dejo para trabajo futuro brindar soporte a ese tipo de transferencia en nuestro driver.

Modo de uso Fachada: Como ya se explic en la seccin 7.3 del captulo Decisiones de
diseo e implementacin, ste modo de uso de la solucin se elimin del alcance del proyecto, de todas formas sigue siendo un escenario interesante para la creacin de un proyecto paralelo. Se propone como trabajo a futuro la investigacin de distintas alternativas que logren satisfacer adecuadamente los requerimientos de esta modalidad de uso.

Oportunidades de mejora
Mejorar la robustez: Actualmente el manejo de errores implementado a nivel del USB4all
API
es muy simple, slo informa si se produjo un error o no, se debera contar con una clasicacin de los errores de forma de noticar adecuadamente a las aplicaciones de usuario cual es el problema. Frente a un conjunto de situaciones anormales como son la ausencia de baseboards conectados al PC o la remocin de ellos durante la ejecucin de una aplicacin de usuario no existen mecanismos adecuados para su manejo. Se debera poder ampliar las funcionalidades del sistema de forma de poder detectar los cambios (adicin o remocin) de los baseboards conectados al PC y actuar en consecuencia. Se debera incorporar a las funcionalidades del sistema sincronizacin de la informacin.

USB4all

la posibilidad de recupe-

racin de los vnculos lgicos ante fallas en el PC o en los baseboards por medio de la

Mejoras al Scheduler:
user modules
y el

El actual mecanismo que utiliza el

tiempo de CPU del microcontrolador a aquellos

user modules

base rmware

para asignar

que lo requieren utiliza una

poltica de round robin sin cotas de tiempo (se aspira a un accionar cooperativo entre los

base rmware ).

Se cree conveniente la incorporacin de una tcnica de

manejo de prioridades que permita que algunos

user modules

pueden acceder con mayor de forma de evitar

frecuencia a tiempos de CPU que otros. Otra mejora interesante, sera la implementacin de un mecanismo de expropiacin del CPU que utiliza un la inanicin del resto de los

user modules.

user module

Modo Stand Alone: La solucin se dise para la interaccin con dispositivos electrnicos
desde un PC, esto implica que exista una conexin fsica permanente con el mismo para su funcionamiento. Durante el desarrollo de este proyecto se vi con inters el empleo en escenarios de funcionamiento independientes del PC (desconectado). Por ejemplo, para implementar una red de sensores que adquieran datos meteorolgicos, los almacenen de

118

CAPTULO 9.

CONCLUSIONES Y TRABAJO A FUTURO

forma temporal para posteriormente transferirlos al PC va USB para su procesamiento. Para esto sera necesario realizar algunos cambios en la circuitera del fuente externa. Adems se debera cambiar el (open) de los

baseboard

para

resolver el conicto que presenta la doble alimentacin de energa desde el USB y una

base rmware

para que sea capaz de detectar

si est conectado a un PC o no y mediante un nuevo mdulo encapsular toda la apertura

user modules

existentes en el

baseboard.

Asincronismo:
los

La actual implementacin de la solucin fue pensada para un escenario

sincrnico donde las aplicaciones de usuario tienen el protagonismo en la comunicacin con

baseboards

(formato comando/respuesta), de todas formas se puede simular un com-

portamiento asincrnico a expensas de no compartir los endpoints entre los y realizar un

receiveData

user modules
tuviera un

bloqueante en un hilo de proceso separado para cada vnculo

lgico abierto. La inclusin de un mecanismo de asincronismo implicara que el recepcin de datos desde el

USB4all API

hilo de proceso por cada endpoint de entrada de forma de bloquearse a la espera de la

baseboard,

como se ve en la gura 9.1. Cuando llega un dato

debera analizarlo para identicar a que aplicacin corresponde entregarlo. El benecio principal de esta mejora sera poder compartir el uso de un endpoint determinado por varias aplicaciones. Para ello, la

USB4all API

debera implementar un mecanismo de mutua

exclusin para la noticacin del uso del recurso compartido (endpoint). Cabe sealar que la actual implementacin no posee ningn tipo de espera activa.

Figura 9.1: Idea de asincronismo de futuro

USB4all baseboard utility en Linux: El utilitario USB4all baseboard utility

es depen-

diente de los proyectos MPLAB y el compilador MPLAB C18, por lo que actualmente esta aplicacin no puede utilizarse desde la plataforma Linux. Se investig y en algunos foros en Internet se ha comentado de instalaciones exitosas de MPLAB en Linux mediante WINE [34]. Como trabajo a futuro se propone experimentar y efectuar los cambios necesarios en la aplicacin

USB4all baseboard utility

de manera de lograr su funcionamiento tambin en

este sistema operativo.

Investigacin
Wireless USB:
Durante el desarrollo de este proyecto de grado se liber el estndar Wireless USB 1.0 [35] que implementa la comunicacin inalmbrica entre los dispositivos

9.2.

TRABAJO A FUTURO

119

USB y la PC. Este nuevo estndar abre las puertas a una nueva dimensin de conectividad USB a la vez que introduce nuevo desafos, los cuales son atractivos para la investigacin y/o experimentacin. En lo referente al producto impacto que puede tener el uso de

USB4all se ve con inters el estudio del Wireless USB Hub (F5U302) de Belkin que permitira prescindir del cable USB que conecta el PC con los baseboards. Esto sera el primer paso en
el estudio de la temtica a la espera de que los fabricantes de microcontroladores ofrezcan versiones compatibles con el nuevo estndar.

Figura 9.2: Wireless USB Hub (F5U302) de Belkin

Portabilidad a Mac OS, Solaris y otros sistemas operativos:

En el contexto de

este proyecto se seleccionaron las plataformas Windows y Linux para su implementacin, aunque el diseo de la arquitectura contempla la utilizacin en cualquier plataforma que soporte la tecnologa USB. Por este motivo es desaante la migracin a otros sistemas operativos de los cuales los miembros de este proyecto no tienen experiencia an como son MacOS, Solaris, etc.

120

CAPTULO 9.

CONCLUSIONES Y TRABAJO A FUTURO

Bibliografa
[1] Active Wire, http://www.activewireinc.com/, ltimo acceso diciembre 2007.

(Citado en la pgina 36.)

- FING, 2007.

[2]

AGUIRRE, Andrs; FERNNDEZ, Rafael; GROSSY, Carlos; Estado del Arte; UDELAR

(Citado en las pginas 20, 23, 28, 29 y 31.)

[3] AGUIRRE, Andrs; FERNNDEZ, Rafael; GROSSY, Carlos; Manual de Usuario USB4All; UDELAR - FING, 2007.

(Citado en las pginas 47, 48 y 49.)

[4] AID, http://www.student.ocad.on.ca/~aid_dev/, ltimo acceso diciembre 2007.

(Citado en la pgina 36.)

[5]

ANDERSON, Don; USB System Architecture (USB 2.0); Second edition, 2001.

(Citado en las pginas 23 y 76.) (Citado en las pginas 36 y 37.)

Third Edition, 2005.

[6]

Arduino, http://www.arduino.cc/en/, ltimo acceso noviembre del 2007.

[7]

AXELSON, Jan; USB Complete, Everithing You Need to Develop Custom USB Peripherals;

(Citado en la pgina 23.)

[8] C and C++ Standards, http://home.att.net/~jackklein/c/standards.html, ltimo acceso 26 de noviembre del 2007.

(Citado en la pgina 114.)

[9]

CORBET, Jonathan; RUBINI, Alessandro; KROAH-HARTMAN, Greg. Linux device drivers. 3rd Edition, O' Reilly Media, 2005.

(Citado en las pginas 85 y 86.) (Citado en las pginas 36 y 39.)

viembre del 2007.

[10] CUI, http://www.create.ucsb.edu/~dano/CUI/, ltimo acceso noviembre del 2007.

[11] CVS, Concurrent Versions System, http://www.nongnu.org/cvs, ltimo acceso 26 de no-

(Citado en las pginas 113 y 133.)

[12] Data Translation, http://www.datx.com/products/dataacquisition/usb/dt9835.asp, ltimo acceso diciembre 2007.

(Citado en la pgina 36.)

2007.

[13] DevaSys - USB I2C, http://www.devasys.com/usbi2cio.htm, ltimo acceso noviembre del

(Citado en la pgina 36.)

[14] Elexol, http://www.elexol.com/IO_Modules/, ltimo acceso diciembre 2007.

(Citado en la pgina 36.)

2007.

[15] Estndar USB 2.0, http://www.usb.org/developers, ltimo acceso 26 de noviembre del

(Citado en las pginas 23 y 64.)

121

122

BIBLIOGRAFA

[16] Estndar USB para la clase MIDI, http://www.usb.org/developers/devclass_docs/, ltimo acceso 26 de noviembre del 2007.

(Citado en la pgina 25.)

[17] Estndar USB para la clase HID, http://www.usb.org/developers/devclass_docs/, ltimo acceso 26 de noviembre del 2007.

(Citado en la pgina 23.)

[18] Estndar USB para la clase CDC, http://www.usb.org/developers/devclass_docs/, ltimo acceso 26 de noviembre del 2007.

(Citado en la pgina 45.)

[19] FLIEGL, Detlef; Programming Guide for Linux USB Device Drivers, Departamento de Informtica, Universidad Tcnica de Munich, 2000.

(Citado en la pgina 86.)

bre del 2007.

[20] FT232BL/TR, http://www.ftdichip.com/Products/FT232BM.htm, ltimo acceso noviem-

(Citado en la pgina 37.)

[21] Gainer, http://gainer.cc/, ltimo acceso diciembre 2007.

(Citado en la pgina 36.)

[22] GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John Design Patterns: elements of reusable object-oriented software 1st Edition, Addison-Wesley Professional Computing Series, 1994.

(Citado en las pginas 67 y 101.)

[23] GNU-GPL, The GNU General Public License, http://www.gnu.org/licenses, ltimo acceso 26 de noviembre del 2007.

(Citado en la pgina 115.) (Citado en la pgina 23.)

[24] HYDE, John;USB Design by Example, A Practical Guide to Building I/O Devices, 1999.

[25] LIBUSB, http://libusb.sourceforge.net, ltimo acceso en julio del 2007.

(Citado en las pginas 78 y 84.) (Citado en la pgina 133.)

[26] Lyx, http://www.lyx.org, ltimo acceso 26 de noviembre del 2007.

[27] MANDANY; ISLAM; KOUGIOURIS: CAMPBELL, Reication and Reection in C++ An Operating Systems Perspective.

(Citado en la pgina 55.)

del 2007.

[28] MANTIS de USB4all, http://usb4all.dyndns.org/mantis/, ltimo acceso 26 de noviembre

(Citado en las pginas 113 y 134.)

[29] Microchip Technology Inc.; MPLAB C18 C Compiler User's Guide, 2005.

(Citado en la pgina 57.)

ciembre 2007.

[30] Morphy Planning's USB-IO, http://www.fexx.org/usbio/index-en.html, ltimo acceso di-

(Citado en la pgina 36.)

[31] SILBERSCHATZ, Abraham; LABS, Bell; GALVIN, Peter B., Sistemas Operativos 5 cin, Addison-Wesley Longman Inc., 1999.

Edi-

(Citado en la pgina 101.)

del 2007.

[32] Sumo.uy, http://www.ng.edu.uy/inco/eventos/sumo.uy/, ltimo acceso 26 de noviembre

(Citado en las pginas 110 y 111.)

[33] WIKI, Portada - USB4ALL http://usb4all.dyndns.org/wiki/ ,ltimo acceso 26 de noviembre del 2007.

(Citado en las pginas 113 y 134.)

BIBLIOGRAFA

123

[34] WINE, http://www.winehq.org/, ltimo acceso diciembre 2007.

(Citado en la pgina 118.)

[35] Wireless Universal Serial Bus Specication 1.0, http://www.usb.org/developers/wusb/docs/, ltimo acceso 26 de noviembre del 2007.

(Citado en la pgina 118.)

[36] Wiring, http://wiring.org.co/ioboard/index.html, ltimo acceso noviembre del 2007.

(Citado en las pginas 36 y 38.)

124

BIBLIOGRAFA

Apndice A

Glosario
En esta seccin deniremos algunos trminos bsicos para el entendimiento del material contenido en ste informe.

ACK:

Abreviatura de

Ack nowledgement

(Asentimiento positivo), en comunicaciones entre

computadores, es un mensaje que se enva para conrmar que un mensaje o un conjunto de mensajes han llegado. Si el terminal de destino tiene capacidad para detectar errores, el signicado de ACK es "ha llegado y adems ha llegado correctamente".

ADC:

Acrnimo de

Analog D igital C onversor

(Conversor Analgico-Digital), es un circuito

integrado electrnico que convierte seales continuas a nmeros digitales discretos.

ANSI_C: API:

Nombre con que se conoce vulgarmente la versin del lenguaje C estandarizado por

el Instituto Nacional Estadounidense de Estndares (sigla en ingls ANSI) en el ao 1989. Sigla de

Application P rogramming I nterface (Interfaz de Programacin de Aplicaciones),

es el conjunto de funciones y procedimientos que ofrece cierta librera para ser utilizado por otro software como una capa de abstraccin. Una buena API hace ms fcil desarrollar un programa mediante el suministro de todos los elementos de construccin.

ATA:

Acrnimo de

Advanced T echnology Attachment

(Tecnologa Avanzada de Fijacin), es

una interfaz estndar para conectar dispositivos de almacenamiento como discos duros y unidades de CD-ROM dentro de los computadores personales.

ATAPI: B:

Acrnimo de

Advanced T echnology Attachment P acket I nterface

(Interfaz de Pa-

quetes de Tecnologa Avanzada de Fijacin), es una extensin de la interfaz ATA y permite conectar medio removibles. Lenguaje de programacin creado en 1969 por Ken Thompson con contribuciones de Dennis Ritchie en los Laboratorios Bell, predecesor del lenguaje de programacin C.

Bit:

Acrnimo de

B inary Dig it (Dgito Binario), es un dgito del sistema de numeracin binario.

Bluetooth:

Es el nombre comn de la especicacin industrial IEEE 802.15.1, que dene un

estndar global de comunicacin inalmbrica que posibilita la transmisin de voz y datos entre diferentes dispositivos mediante un enlace por radiofrecuencia segura, globalmente y sin licencia de corto rango.

Boot-Loader: BSD: Byte:

Es un rmware que permite la rpida descarga de programas en los microcon-

troladores. En el caso de los PIC, el boot-loader permite descargar programas directamente desde el PC sin necesidad de utilizar ningn tipo de grabador. Acrnimo de Berkeley Software Distribution (Distribucin de Software Berkeley) y se

utiliza para identicar un sistema operativo derivado del sistema Unix nacido a partir de los aportes realizados a este sistema por la Universidad de California en Berkeley. Unidad bsica de almacenamiento de informacin que hace referencia a una secuencia

de ocho bits contiguos. Tambin se utiliza el termino octeto como sinnimo preciso de la cantidad de bits que representa. 125

126

APNDICE A.

GLOSARIO

ByteCode: Es un cdigo intermedio ms abstracto que el cdigo mquina. C: Lenguaje de programacin creado en 1972 por Ken Thompson y Dennis
Laboratorios Bell como evolucin del anterior lenguaje B.

M. Ritchie en los

C++:

Lenguaje de programacin, diseado a mediados de los aos 1980, por Bjarne Stroustrup,

como extensin del lenguaje de programacin C. Se puede decir que C++ es un lenguaje que abarca tres paradigmas de la programacin: la programacin estructurada, la programacin genrica y la programacin orientada a objetos.

Callback: CDC: Chip:

(Retro llamada) Es un cdigo ejecutable que es pasado como argumento a otro

cdigo. Esto permite a una capa de software de ms bajo nivel invocar una rutina (o funcin) denida en una capa de ms alto nivel. Acrnimo de

C omunications D evice C lass

(Clase de Dispositivo de Comunicaciones),

es una de las clases que dene el estndar USB y permite clasicar a los dispositivos segn su comportamiento esperado. Sinnimo de circuito integrado, es una pastilla muy delgada en la que se encuentran una

enorme cantidad (del orden de miles o millones) de dispositivos microelectrnicos interconectados, principalmente diodos y transistores, adems de componentes pasivos como resistencias o condensadores.

COM:

Acrnimo de

C omponent O bject M odel

(Modelo de Objetos de Componentes), es una

plataforma de Microsoft para componentes de software introducida en 1993. Permite la comunicacin entre procesos y la creacin dinmica de objetos en cualquier lenguaje de programacin que soporte dicha tecnologa.

CPU:

Sigla de

C entral P rocessing U nit

(Unidad Central de Procesos), es el componente en

una computadora digital que interpreta las instrucciones y procesa los datos contenidos en los programas de computadora. Es la parte que constituye el cerebro de cualquier computadora, es el encargado de realizar y dirigir todas las funciones.

CVS:

Acrnimo de

C oncurrent V ersrions S ystem

(Sistema de Control de Versiones), es una

aplicacin informtica que mantiene el registro de todo el trabajo y de los cambios los elementos (cdigo fuente principalmente) que forman un proyecto (programa) y permite que distintas personas (desarrolladores) colaboren entre s.

DAC:

Sigla de

D igital Analog C onversor (Conversor digital-analgico), es un dispositivo para

Es un sistema que subyace en MacOS, cuya primera versin fue liberada en 2001

convertir datos digitales en seales de corriente o de tensin analgica.

DarwinBSD: DIL: DIP: DLL:

para funcionar en ordenadores Macintosh. Vase DIP. Acrnimo de

D ual I n-line P ackage,

es un tipo de circuito integrado alojado en una

carcasa rectangular y de dos las paralelas de pines de conexin elctrica. Acrnimo de

D ynamic Link Library (Biblioteca de Vinculacin Dinmica), por vinculaD irect M emory Access (Acceso Directo a Memoria), es una caracterstica

cin dinmica se entiende que las subrutinas de la biblioteca son cargadas en un programa de aplicacin en tiempo de ejecucin.

DMA:

Acrnimo de

de los computadores modernos, que permite a ciertos componentes de hardware dentro del computador, a acceder al sistema de memoria para lectura y/o escritura en forma independiente al CPU.

Driver: E/S:

(Controlador) Programa que permite al sistema operativo interactuar con un disposi-

tivo, haciendo una abstraccin del hardware y proporcionando una interfaz -posiblemente estandarizada- para usarlo. Abreviatura

E ntrada/ S alida, es la coleccin de interfaces que usan las distintas unidades

funcionales de un sistema de procesamiento de informacin para comunicarse con otras, o las seales enviadas a travs de esas interfaces.

127

EEPROM:

Acrnimo de

E lectrically E rasable P rogrammable Read O nly M emory (Memoria

de Slo Lectura Programable y Borrable Elctricamente), es un tipo de memoria ROM que puede ser programado, borrado y reprogramado elctricamente. Slo puede ser borrada y reprogramada entre 100.000 y 1.000.000 de veces.

FIFO:

Acrnimo de

F irst I n, F irst O ut

(Primero en Entrar, Primero en Salir), es un mto-

do utilizado en estructuras de datos, contabilidad de costes y teora de colas. Guarda la analoga con las personas que esperan en una cola y van siendo atendidas en el orden en que llegan.

FireWire: Firmware: FreeBSD:

Vase IEEE 1394. Es un bloque de instrucciones de programa para propsitos especcos, grabado en

una memoria tipo ROM, que establece la lgica de ms bajo nivel que controla los circuitos electrnicos de un dispositivo. Es un sistema operativo libre basado en los sistemas BSD para ordenadores perso-

nales basado en los CPU de arquitectura Intel.

Free_Software: FSF:

(Software Libre) Es la denominacin del software , que una vez obtenido,

puede ser usado, copiado, estudiado, modicado, mejorado y redistribuido libremente de forma de beneciar a toda la comunidad. Acrnimo de

F ree S oftware F oundation (Fundacin para el Software Libre), es una orga-

nizacin creada en octubre de 1985 por Richard Stallman y otros entusiastas del Software Libre con el propsito de difundir este movimiento. Una de las principales funciones de la FSF es dar cobertura legal, econmica y logstica al Proyecto GNU.

GNU: GPL: HAL:

Acrnimo recursivo de

G NU is N ot U nix

(GNU No es Unix), es un sistema operativo

de computadores compuesto enteramente por software libre. Se lo conoce tambin como Proyecto GNU y fue iniciado por Richard Stallman en 1983. Acrnimo de

G eneral P ublic License (Licencia Pblica General), es una licencia creada H ardware Abstraction Layer

por la FSF a mediados de los aos 80, y est orientada principalmente a proteger la libre distribucin, modicacin y uso de software. Acrnimo de (Capa de Abstraccin de Hardware), es un

elemento del sistema operativo que funciona como interfaz entre el software y el hardware del sistema, proveyendo una plataforma de hardware consistente sobre la cual correr las aplicaciones.

HEX:

Su nombre formal es

Intel HEX

y corresponde a un formato de archivo para trans-

mitir informacin binaria de aplicaciones programadas para microcontroladores, ROMs o cualquier otro tipo de chip. ste formato es uno de los ms viejos disponibles para este propsito y se usa desde los aos 1970. El formato es un archivo de texto, donde cada lnea contiene valores hexadecimales que codican una secuencia de datos y sus corrimientos o direcciones absolutas.

HID:

Acrnimo de

H uman I nterface D evices (Dispositivo de Interfaz Humana), es un tipo de

dispositivo de un computador, que interacta directamente con seres humanos, tomando y/o devolviendo informacin.

Hot_Plug: Hot_Swap: I/O: I2C:

(Enchufado en caliente) Vase Hot Swap. (Sustitucin en caliente) Hace referencia a la capacidad de algunos componentes

hardware para realizar su instalacin o sustitucin sin necesidad de detener o alterar la operacin normal de la computadora donde se alojan. Abreviatura de Acrnimo de

I nput/ O utput, vase E/S.

(Inter Circuitos Integrados), es un bus de comuni-

I nter-I ntegrated C ircuit

caciones serie diseado por Phillips en el ao 1992.

128

APNDICE A.

GLOSARIO

IDE:

Acrnimo de

I ntegrated D evelopment E nvironment

(Entorno integrado de desarrollo),

es un programa compuesto por un conjunto de herramientas (un editor de cdigo, un compilador, un depurador y un constructor de interfaz grca) para brindar un marco de trabajo amigable a un programador.

IEEE_1394:

Conocido como FireWire por Apple Inc. y como i.Link por Sony, es un estndar

multiplataforma para entrada/salida de datos en serie a gran velocidad. Suele utilizarse para la interconexin de dispositivos digitales como cmaras digitales y videocmaras a computadoras.

IEEE_802: IRP:

Es un comit y grupo de estudio de estndares perteneciente al Instituto de Inge-

nieros Elctricos y Electrnicos (IEEE), que acta sobre Redes de Ordenadores, concretamente y segn su propia denicin sobre redes de rea local y redes de rea metropolitana. Acrnimo de

I /O Request P acket (Paquete de Peticin E/S), es una estructura de modo I nput/ O utput C on t ro l (Control entrada/salida), la llamada de sistema

kernel que es usada por WDM para comunicarse internamente y con el sistema operativo.

IOCTL: ISR: Java:

Acrnimo de

ioctl en los sistemas basados en Unix, permite a una aplicacin controlar o comunicarse con un driver de dispositivo fuera de los usuales read/write de datos. Acrnimo de

I nterrupt S ervice Routine

(Rutina de Servicio de Interrupcin), es una

rutina (callback) en un sistema operativo o driver de dispositivo encargada de atender una interrupcin del hardware. Su ejecucin es disparada por la recepcin de la interrupcin. Lenguaje de programacin orientado a objetos desarrollado por Sun Microsystems a prin-

cipios de los aos 1990. El lenguaje en s mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos ms simple y elimina herramientas de bajo nivel como punteros.

JIT: JNI:

Sigla de

J ust I n T ime (Compilacin en tiempo de ejecucin), es una tcnica para mejoJ ava N ative I nterface, es un framework de programacin que permite que un

rar el rendimiento de sistemas de programacin que compilan a bytecode, consistente en traducir el bytecode a cdigo mquina nativo en tiempo de ejecucin. Sigla de

programa escrito en Java ejecutado en la mquina virtual Java pueda interactuar con programas escritos en otros lenguajes como C, C++ y ensamblador.

Jumper: kB:

Elemento para interconectar dos terminales de manera temporal sin tener que efectuar

una operacin que requiera herramienta adicional, dicha unin de terminales cierran el circuito elctrico del que forma parte. (kilobyte) Es una unidad de informacin o de almacenamiento informtico equivalente a mil bytes o 1.024 bytes, dependiendo el contexto. Puede ser abreviado como: K, KB, Kbytes.

Kernel: kHz: LED:

(Ncleo) Es la parte fundamental de un sistema operativo. Es el software encargado

de gestionar los recursos del sistema. (kilohertz) Unidad de frecuencia equivalente a mil ciclos por segundo. Sigla de

Light E mitting D iode

(Diodo emisor de luz), es un dispositivo semiconductor

(diodo) que emite luz cuasi-monocromtica, es decir, con un espectro muy angosto, cuando se polariza de forma directa y es atravesado por una corriente elctrica.

LGPL:

Acrnimo de

Lesser G eneral P ublic License (Licencia Pblica General Menor), es una

licencia que aplica generalmente a bibliotecas y permite a programas privativos (no libres) utilizar las bibliotecas como parte de sus trabajos. Esta licencia mantiene trminos ms laxos que la GPL en que necesariamente todas las partes deben ser Software Libre.

Linux:

Es la denominacin de un sistema operativo tipo Unix (creado en 1992) y el nombre de

un kernel (creado por Linus Torvalds en 1991). Es uno de los paradigmas ms prominentes del Software Libre y del desarrollo del cdigo abierto.

129

MacOS: MB: Mb:

Acrnimo de

M acintosh O perating S ystem

(Sistema Operativo de Macintosh), es el

nombre del primer sistema operativo de Apple Computer para las computadoras Macintosh. (megabyte) Es una unidad de informacin o de almacenamiento informtico equivalente a

106 bytes

220

bytes dependiendo el contexto. Puede ser abreviado como Mbyte.

(megabit) Es una unidad de informacin o de almacenamiento informtico equivalente un milln de bits. Puede ser abreviado como Mbit.

Mbps: MHz: MIDI:

(megabit per second) Es una unidad tasa de transferencia de datos equivalente a un

milln de bits por segundo. Puede ser abreviado como Mbit/s o mbps). (megahertz) Unidad de frecuencia que equivale a un milln de ciclos por segundo. Acrnimo de

M usical I nstrument D igital I nterface

(Interfaz Digital de Instrumen-

tos Musicales). Es un protocolo estndar que permite a los computadores, sintetizadores, secuenciadores y otros dispositivos musicales electrnicos, comunicarse entre si para la generacin de sonidos.

MPLAB:

Es un editor IDE gratuito, destinado a productos de la marca Microchip. Este editor

es modular, permite seleccionar los distintos microprocesadores soportados, adems de permitir la grabacin de estos circuitos integrados directamente al programador.

MPLAB_C18:

Es un compilador C compatible con ANSI C y completo para la familia PIC18

de PICmicro de 8-bits.

MPLAB_ICD2: NACK:

Depurador (con la caracterstica de depuracin directa en el circuito) y pro-

gramador del rmware de los microcontroladores de la empresa Microchip. Acrnimo de

N egative Ack nowledgement (Asentimiento negativo), en comunicaciones

entre computadoras, es un mensaje que se enva para informar de que en la recepcin o procesamiento de los datos ha habido un error.

NetBSD: Ohm:

Es un sistema operativo del tipo Unix basado en los sistemas BSD, de distribucin

libre y de cdigos fuentes abiertos. (Ohmnio) Es la unidad de resistencia elctrica en el Sistema Internacional de Unidades.

Su nombre se deriva del apellido del fsico alemn Georg Simon Ohm, autor de la Ley de Ohm.

OpenBSD: PC:

Es un sistema operativo libre tipo Unix, multiplataforma, basado en los sistemas

BSD. Es un descendiente de NetBSD, con un foco especial en la seguridad y la criptografa. Sigla de

P ersonal C omputer

(Computadora Personal), trmino genrico utilizado para

referirse a microcomputadores que se basan en un microcontrolador Intel o compatible.

PCB:

Sigla de

P rinted C ircuit B oard

(Circuito Impreso), es un medio para sostener mec-

nicamente y conectar elctricamente componentes electrnicos, a travs de rutas o pistas de material conductor, grabados desde hojas de cobre laminadas sobre un sustrato no conductor.

PIC:

Son una familia de microcontroladores tipo RISC fabricados por Microchip Technology Inc. y derivados del PIC1650, originalmente desarrollado por la divisin de microelectrnica de General Instruments. El nombre actual no es un acrnimo, en realidad el nombre completo es PICmicro.

PID:

Acrnimo de

P roduct ID (Identicador de Producto), es un identicador nico asignado

(Enchufar y listo) Se reere a la tecnologa que permite a un dispositivo

por el USB-IF a los productos fabricados por las empresas registradas.

Plug_and_Play: Plug-In:

informtico ser conectado a una computadora sin tener que congurar el mismo. (Enchufar en) Pequeo programa que aade alguna funcin a otro programa, habi-

tualmente de mayor tamao. Un programa puede tener uno o ms conectores.

130

APNDICE A.

GLOSARIO

Polling: Proxy: PWM:

(Escrutio) Reere a la toma de muestras en forma activa del estado de un dispositivo

externo, por medio de un programa sincrnico. Este concepto se usa normalmente asociados a escrutinios de E/S. (Intermediario, Apoderado) En su forma ms general, es una clase que funciona como

interfaz de otra, logrando ocultar su verdadera identidad. Sigla de

P ulse W idth M odulation

(Modulacin en el ancho del pulso). Forma de

codicar un valor anlogo en una onda digital, de forma que el ciclo de trabajo est en relacin con el valor a codicar.

Python: QFN: RAM:

Es un lenguaje de programacin (interpretado) que soporta mltiples paradigmas de

programacin (funcional, orientado a objetos y imperativo) y fue creado por Guido van Rossum en el ao 1990. Acrnimo de

Q uad F lat Package N o Lead (Encapsulado Cuadrado Plano Sin Conecto(Memoria de acceso aleatorio), es una memoria de

res), es un encapsulado de circuito integrado para montaje supercial donde los conectores de componentes no se extienden fuera del encapsulado. Sigla de

Random Access M emory

semiconductores en la que se puede escribir o leer informacin. Es voltil, es decir, pierde su contenido al desconectar la energa elctrica.

Ribbon_Cable:

(Cable Cinta) Tambin conocido como cable plano multihilo, es un cable con

muchos cables conductores que corren en forma paralela unos con otros sobre el mismo plano. Como resultado, el cable es ancho y chato en vez de redondo. Su nombre proviene de la semejanza de estos cables con un pedazo de cinta. Son normalmente utilizados en perifricos internos de un computador personal.

ROM: RTC: SIE:

Sigla de

Read O nly M emory Real T ime C lock

(Memoria de slo lectura), es una memoria de semicon-

ductores que puede leerse pero no modicarse. La ROM suele almacenar la conguracin del sistema o el programa de arranque de la computadora. Acrnimo de (Reloj de Tiempo Real), es un reloj un computador (la

mayora de las veces en forma de circuito integrado) que permite mantener la pista del tiempo actual. Acrnimo de

S erial I nterface E ngine (Motor de Interfaz Serial), es un circuito integrado

que normalmente se encarga de la recepcin y envo de datos de las transacciones y trabaja en conjunto con el transceiver USB y los endpoints. El SIE no interpreta o utiliza los datos, slo enva los datos que estn disponibles para hacerlo y almacena los datos recibidos.

SIL:

Acrnimo de

S ingle I n-Line Package,

es un tipo de circuito integrado alojado en una

carcasa que posee una nica la de pines de conexin elctrica.

SMT:

Sigla de

S urface M ount T echnology

(Tecnologa de montaje supercial), es un mto-

do para la construccin de circuitos electrnicos en el que los componentes se montan directamente sobre la supercie de los circuito impreso.

Solaris: SPI:

Es un sistema operativo desarrollado por Sun Microsystems. Es un sistema certicado

como una versin de Unix. Aunque Solaris en s mismo an es software propietario, la parte principal del sistema operativo se ha liberado como Software Libre. Sigla de

S erial P eripherical I nterface (Bus de Interfaz de Perifricos Serie), es un estnT ipo Abstracto de D atos
(Abstract Data Type), es una especicacin de

dar de comunicaciones, usado principalmente para la transferencia de informacin entre circuitos integrados en equipos electrnicos.

TAD:

Acrnimo de

un conjunto de datos y un conjunto de operaciones que pueden ser realizadas sobre los datos.

Through-Hole_Technology:
en el lado opuesto.

(Tecnologa A Travs de Oricio) Se reere al esquema utilizado

para el montaje de componentes electrnicos, que implica la insercin de los pines de los componentes en oricios perforados en el circuito electrnico impreso y el soldado al circuito

131

TimeOut:

(Tiempo vencido) Hace referencia a la conclusin intencional de una tarea incom-

pleta luego de superado un tiempo lmite estipulado para su conclusin en forma normal.

Transceivers: UART:

(Transceptores) Es un dispositivo que realiza funciones tanto de transmicin

como de recepcin, utilizando componentes de circuito comunes para ambas funciones. Acrnimo de

U niversal Asynchronous Receiver T ransmitter

(Transmisor Receptor

Asncrono Universal), es un circuito integrado (o parte de uno) usado para comunicaciones seriales en computadores que forma parte de los puertos seriales de computadores personales o perifricos.

Unix: URB:

Es un sistema operativo portable, multitarea y multiusuario; desarrollado en principio

por un grupo de empleados de los laboratorios Bell de AT&T, entre los que guran Ken Thompson, Dennis Ritchie y Douglas McIlroy. Acrnimo de

U SB Request B lock

(Peticin en Bloque USB), son estructuras utilizadas

a nivel de los sistemas operativos, que permiten la conguracin de los dispositivos y transmicin de datos. Estas estructuras son enviadas por medio de un IRP a la capas inferiores de la pila de drivers.

USB:

Sigla de

U niversal S erial B us (Bus Universal en Serie), es una interfaz que provee un es-

tndar de bus serie para conectar dispositivos a un ordenador personal. Fue creado en 1996 por IBM, Intel, Northern Telecom, Compaq, Microsoft, Digital Equipment Corporation y NEC.

USB_Hub: VID: WiFi:

(Concentrador USB) Es un dispositivo que permite tener varios puertos USB a

partir de uno slo. Acrnimo de

V endor ID (Identicador de Vendedor), es un identicador nico asignado Wi reless Fi delity. Es un conjunto de estndares para redes inalmbricas W ine I s N ot an E mulator
(Wine no es un emulador), es

por el USB-IF a las empresas (previo registro) que quieren fabricar dispositivos USB. Acrnimo de

basados en las especicaciones IEEE 802.11.

WINE:

Acrnimo recursivo de

una reimplementacin de la API de Windows (en sus versiones de 16-bits y 32-bits) para sistemas operativos basados en Unix bajo plataformas Intel.

Windows:

(Microsoft Windows) Es un sistema operativo con interfaz grca para computado-

ras personales propiedad de la empresa Microsoft.

Wireless_USB:

(USB Inalmbrico) Es un protocolo de comunicacin inalmbrico por radio

con gran ancho de banda que combina la sencillez de uso de USB con la versatilidad de las redes inalmbricas. En mayo del 2006 se aprob la especicacin del nuevo estndar que se abrevia como W-USB o WUSB.

Wrapper:

(Envoltura) Es una clase que se utiliza para transformar una interfaz en otra, de

tal modo que una clase que no pudiera utilizar la primera, haga uso de ella a travs de la segunda.

132

APNDICE A.

GLOSARIO

Apndice B

Herramientas de la Gestin del Proyecto

B.1. L X Y

A E edicin de texto usando L T X, por lo que hereda todas sus capacidades (notacin cientca,

Lyx [26] es un programa grco multiplataforma creado por Matthias Ettrich que permite la

edicin de ecuaciones, creacin de ndices, etctera). Se trata de un procesador de textos en el que el usuario no necesita pensar en el formato nal de su trabajo, sino slo en el contenido y su estructura (WYSIWYM)(Lo Que Ve Es Lo Que Quieres Decir, por sus siglas en Ingls), por lo que puede ser utilizado para editar documentos grandes (libros) o con formato riguroso (tesis, artculos para revistas cientcas), con facilidad. La decisin de utilizar esta herramienta se debi ms all de todas las caractersticas previamente descritas, a que su formato es texto y no binario, lo que permite el trabajo en forma concurrente sobre el documento, as como la utilizacin de herramientas de control de versin como es CVS.

B.2.

CVS

CVS [11] utiliza una arquitectura cliente-servidor: un servidor guarda la(s) versin(es) actual(es) del proyecto y su historial. Los clientes se conectan al servidor para sacar una copia completa del proyecto. Esto se hace para que eventualmente puedan trabajar con esa copia y ms tarde ingresar sus cambios con comandos GNU. Tpicamente, cliente y servidor se conectan utilizando Internet, pero con el sistema CVS el cliente y servidor pueden estar en la misma mquina. El sistema CVS tiene la tarea de mantener el registro de la historia de las versiones del programa de un proyecto solamente con desarrolladores locales. Originalmente, el servidor utilizaba un sistema operativo similar a Unix, aunque en la actualidad existen versiones de CVS en otros sistemas operativos, incluido Windows. Los clientes CVS pueden funcionar en cualquiera de los sistemas operativos ms difundidos. Varios clientes pueden sacar copias del proyecto al mismo tiempo. Posteriormente, cuando actualizan sus modicaciones, el servidor trata de acoplar las diferentes versiones. Si esto falla, por ejemplo debido a que dos clientes tratan de cambiar la misma lnea en un archivo en particular, entonces el servidor deniega la segunda actualizacin e informa al cliente sobre el conicto, que el usuario deber resolver manualmente. Si la operacin de ingreso tiene xito, entonces los nmeros de versin de todos los archivos implicados se incrementan automticamente, y el servidor CVS almacena informacin sobre la actualizacin, que incluye una descripcin suministrada por el usuario, la fecha y el nombre del autor y sus archivos log. En el contexto de este proyecto fue prioritario la utilizacin de este tipo de herramienta, de forma de permitir a cada integrante del grupo trabajar en sus casas optimizando los tiempos sin perder el control del cdigo generado. 133

134

APNDICE B.

HERRAMIENTAS DE LA GESTIN DEL PROYECTO

B.3.

Mantis

Mantis es una aplicacin web que permite el reporte de errores y su posterior seguimiento. Est escrito en PHP y requiere una base de datos (MySQL, MS SQL, PostgreSQL son soportados) y un servidor web. Mantis puede ser instalado sobre las plataformas Windows, Mac OS, OS/2 y una variedad de sistemas operativos Unix. Casi cualquier navegador web debera ser capaz de funcionar como cliente. La interfaz de usuario utiliza un cdigo de colores para distintas cuestiones que facilitan al usuario reconocer de una sola mirada los estados de varios tems. Tambin posee una gran cantidad de opciones de ordenamiento y ltrado para facilitar la ubicacin de un problema en particular. Durante la etapa de implementacin y vericacin fue utilizado para ir reportando errores [28] y asignando responsables de investigarlos y corregirlos, logrando de esta forma centralizar la informacin de los errores y no dejando lugar para olvidos.

B.4.

Wiki

Un wiki es un sitio web colaborativo que puede ser editado por varios usuarios. Los usuarios de una wiki pueden as crear, modicar, borrar el contenido de una pgina web, de forma interactiva, fcil y rpida; dichas facilidades hacen de la wiki una herramienta efectiva para la escritura colaborativa. La tecnologa wiki permite que pginas web alojadas en un servidor pblico (las pginas wiki) sean escritas de forma colaborativa a travs de un navegador web, utilizando una notacin sencilla para dar formato, crear enlaces, etc, conservando un historial de cambios que permite recuperar fcilmente cualquier estado anterior de la pgina. Cuando alguien edita una pgina wiki, sus cambios aparecen inmediatamente en la web, sin pasar por ningn tipo de revisin previa. En el contexto de este proyecto se utilizo un wiki propia [33], que ocio de sitio web del proyecto y facilito toda la gestin de publicacin de documentacin, pginas web de sitios de inters para el proyecto. Adems, fue muy utilizado para registrar de una forma gil y de rpido acceso las planicaciones y actas de las reuniones que se fueron realizando durante todo el proceso.