PFC

Departament dInformtica
P ROYECTO F INAL DE C ARRERA D ISEO E IMPLEMENTACIN DE UNA TARJETA DE SENSORIZACIN USB CON HASP BASADA EN HID
Presentado por: D. Miguel ngel Expsito Snchez Burjassot, Septiembre de 2009
Proyecto dirigido por: Rafael Javier Martnez Dur
c Universitat de Valncia - Todos los derechos reservados
A mi madre, que ha dado lo mejor de s misma y ha hecho esto posible. A mi padre, que no pudo ver este proyecto culminado. A mis abuelos por su apoyo.
Agradecimientos
A mi tutor, Rafael Martinez, que me ha brindado la oportunidad de realizar este proyecto. A todos los compaeros del grupo LSyM, en especial a Marta cuya experiencia y sabios consejos han jugado un gran papel y a Alejandro, que sabe dar un toque profesional a todo aquello en lo que se involucra. A Jos Pino, quien siempre ha estado dispuesto a prestarme su ayuda desinteresada. A mis compaer@s de clase, por todos estos aos de amistad y buenos recuerdos. Que no acaben aqu. A mis amigos Rubn y Andrs por su ayuda y paciencia, y porque siempre sern unos corrutos. A Sal, que nunca duda en compartir conmigo su conocimiento tanto tecnolgico como culinario. A Pako y Adrin, que siempre estn ah para lo bueno y para lo malo, y saben reirse de la vida en los momentos en que ms lo necesito. A Esther. Gracias por ser una persona con la que siempre puedo hablar. A mi to Miguel y mi ta Jaci. Os estar eternamente agradecido. A Enrique, Paqui y Gema. Me habeis enseado cmo se escribe familia.
NDICE
CAPTULO 1. Introduccin
1.1. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13 15
CAPTULO 2. Estado del arte

2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Estndares de interconexin entre un computador y sus perifricos 2.2.1. Interfaces Serie . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Interfaces Paralelas . . . . . . . . . . . . . . . . . . . . . 2.2.3. Interfaces Inalmbricas . . . . . . . . . . . . . . . . . . . 2.3. Microcontroladores . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Dispositivos HASP . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Dispositivos de Adquisicin de Datos (DAQ) . . . . . . . . . . . 2.5.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2. Conversor Analogico-Digital (ADC) . . . . . . . . . . . . 2.5.3. Dispositivos de adquisicin de datos integrados . . . . . . 2.5.4. Dispositivos de juegos . . . . . . . . . . . . . . . . . . . 2.6. Arquitectura de un simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
17 17 19 25 26 27 30 31 32 33 33 34 34
CAPTULO 3. Metodologa y materiales

3.1. Metodologa . . . . . . . . . . . . . . . . . . . 3.2. Planicacin de recursos materiales y humanos 3.3. Material . . . . . . . . . . . . . . . . . . . . . 3.3.1. Software . . . . . . . . . . . . . . . . 3.3.2. Hardware . . . . . . . . . . . . . . . . 3.3.3. Planicacin y recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37 38 38 38 41 42
NDICE
CAPTULO 4. Denicin de requisitos y anlisis del sistema

4.1. Especicacin de requisitos . . . . . . . . . . . . . 4.1.1. Requisitos del hardware . . . . . . . . . . 4.1.2. Requisitos del software . . . . . . . . . . . 4.1.3. Requisitos comunes . . . . . . . . . . . . 4.2. Anlisis de alternativas . . . . . . . . . . . . . . . 4.2.1. Conexin del perifrico con el computador 4.2.2. Microcontrolador . . . . . . . . . . . . . . 4.2.3. Lenguaje de programacin . . . . . . . . . 4.3. Seleccin de alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
45 45 46 47 47 47 48 49 51
CAPTULO 5. Diseo e implementacin del hardware

5.1. Diagrama de bloques . . . . . 5.2. Conectores . . . . . . . . . . 5.2.1. Conexin USB . . . . 5.2.2. Conexin los sensores 5.2.3. Otros conectores . . . 5.3. Asignacin de pines . . . . . . 5.4. Alimentacin . . . . . . . . . 5.5. Oscilador . . . . . . . . . . . 5.6. Comunicacin USB . . . . . . 5.7. Conexin de sensores . . . . . 5.7.1. Sensores digitales . . . 5.7.2. Sensores analgicos . 5.8. Resumen . . . . . . . . . . . 5.9. Diseo del esquemtico . . . . 5.10. Implementacin del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
55 56 56 56 57 58 58 59 62 64 64 67 69 70 71
CAPTULO 6. Diseo e implementacin del software

6.1. Introduccin . . . . . . . . . . . . . . . . . . 6.1.1. Endpoints y pipes . . . . . . . . . . . 6.1.2. Descriptores . . . . . . . . . . . . . 6.1.3. La clase HID . . . . . . . . . . . . . 6.2. Algoritmo HASP . . . . . . . . . . . . . . . 6.3. Firmware . . . . . . . . . . . . . . . . . . . 6.3.1. Conguracin del microcontrolador . 6.3.2. Programa . . . . . . . . . . . . . . . 6.3.3. Comunicacin USB . . . . . . . . . 6.3.4. Adquisicin y formateado de datos . . 6.3.5. Implementacin del algoritmo HASP 6.3.6. Programa principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
. 75 . 75 . 76 . 77 . 81 . 83 . 83 . 89 . 90 . 97 . 105 . 105
NDICE
6.3.7. Generacin del ejecutable . . . 6.3.8. Bootloader . . . . . . . . . . . 6.4. Software para el PC . . . . . . . . . . . 6.4.1. Librera HASP . . . . . . . . . 6.4.2. Herramientas complementarias .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
106 106 112 113 121
CAPTULO 7. Pruebas
7.1. 7.2. 7.3. 7.4. Instalacin del dispositivo Prueba de sensores . . . . Prueba HASP . . . . . . . Actualizacin de rmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
127
128 128 128 128
CAPTULO 8. Presupuesto
8.1. 8.2. 8.3. 8.4. Coste de los recursos software Coste de los recursos hardware Coste de recursos humanos . . Coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
131
131 132 133 134
CAPTULO 9. Conclusiones y trabajo futuro
135
9.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
APNDICE A. Planos y fotolitos

A.1. A.2. A.3. A.4. Esquemtico del circuito Listado de componentes Layout del PCB . . . . . Fotolitos del PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
139
141 142 143 144
APNDICE B. Especicaciones
147
B.1. Especicaciones del dispositivo . . . . . . . . . . . . . . . . . . . . . . 148 B.2. Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.3. Imgenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
APNDICE C. Listados de cdigo fuente

C.1. Firmware del microcontrolador C.1.1. lsred_main.c . . . . . C.1.2. lsred_desc.h . . . . . . C.2. Librera libhw . . . . . . . . . C.2.1. libhw.h . . . . . . . . C.2.2. Driver.h . . . . . . . . C.2.3. Protocol.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
151
152 152 154 158 159 159 160
NDICE
C.2.4. LSYMHASP.h . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
NDICE DE TABLAS
5.1. Numeracin y funcin de cada pin [Axe05] . . . . . . . . . . . . . . . . 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9. 6.10. 6.13. 6.11. 6.12. 6.14. 6.15. 6.16. 6.17. 6.18. 6.19. 6.20. 6.21. 6.22. 6.23. 6.24. Tabla de registros de conguracin. . . Conguracin del registro CONFIG1L. Conguracin del registro CONFIG1H. Conguracin del registro CONFIG2L. Conguracin del registro CONFIG3H. Conguracin del registro CONFIG5L. Conguracin del registro CONFIG5H. Conguracin del micro. . . . . . . . . Descriptor de dispositivo . . . . . . . . Descriptor de conguracin . . . . . . . Descriptor HID . . . . . . . . . . . . . Descriptor de interfaz 1 . . . . . . . . . Descriptor de interfaz 2 . . . . . . . . . Descriptor de endpoint 1 (IN) . . . . . . Descriptor de endpoint 2 (IN) . . . . . . Descriptor de endpoint 2 (OUT) . . . . Nmero y tipo de entradas . . . . . . . Interfaz de la librera HASP para PIC18. Comandos aceptados por el bootloader. Interfaz de la capa Driver . . . . . . . Interfaz de la capa Protocol . . . . . Interfaz de la capa LSYMHASP . . . Mensajes de noticacin . . . . . . . . Cdigos de excepcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57 85 86 86 87 88 88 89 89 93 93 93 93 94 94 94 94 103 105 109 115 116 119 119 121
8.1. Costes de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 8.2. Costes de hardware I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
NDICE DE TABLAS
8.3. Costes de hardware II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 8.4. Costes de recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . 133 8.5. Costes totales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.1. Listado de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 142 B.1. Especicaciones del dispositivo . . . . . . . . . . . . . . . . . . . . . . 148 B.2. Especicaciones del dispositivo . . . . . . . . . . . . . . . . . . . . . . 148
NDICE DE FIGURAS
1.1. Evolucin sobre el software ilegal en Espaa de 2003 a 2007 . . . . . . . 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 2.10. 2.11. Interfaz de E/S para un dispositivo generco [CSFBAOSS01] . . . . . . . Cronograma de una transmisin RS-232 a 1600 baudios sin bit de paridad A la izquierda conector DB-25, a la derecha conector DB-9 . . . . . . . . Diagrama del conector USB 3.0 . . . . . . . . . . . . . . . . . . . . . . Tipos A y B del conector USB . . . . . . . . . . . . . . . . . . . . . . . Topologa de USB 2.0 y predecesores . . . . . . . . . . . . . . . . . . . Conectores Firewire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilizacin de microcontroladores por cada sector . . . . . . . . . . . . . Ejemplo de seal digital ideal . . . . . . . . . . . . . . . . . . . . . . . . Ejemplo de seal analgica . . . . . . . . . . . . . . . . . . . . . . . . . Arquitectura de un sistema de simulacin . . . . . . . . . . . . . . . . .
15 18 20 20 22 23 23 25 28 32 33 35 43 53 55 56 57 57 57 58 59 61 61
3.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. El encapsulado SPDIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Diagrama de bloques del sistema . . . . . . . . . . . . . . . . . . . . . . 5.2. Tipos de conectores USB principales, de izquierda a derecha: Micro USB macho, Mini USB tipo B macho, Tipo B macho, Tipo A macho. . . . . . 5.3. Conector USB tipo B macho y hembra. . . . . . . . . . . . . . . . . . . 5.4. Extremos del cable de conexin USB de tipo A-B. . . . . . . . . . . . . . 5.5. Conector USB tipo B para montaje en placa. . . . . . . . . . . . . . . . . 5.6. Diagrama de pines del PIC18F2550 en su encapsulado SPDIP . . . . . . 5.7. Esquema de circuito de alimentacin para un PIC18F2550 alimentado por USB usando su transceptor incorporado. . . . . . . . . . . . . . . . . . . 5.8. Esquema de la circuitera de seleccin de reloj del PIC18F2550 relativa al mdulo USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9. Esquema de conexin de un cristal de cuarzo al PIC18F2550. . . . . . . .
10
NDICE DE FIGURAS
5.10. Tabla de capacidades recomendadas por el fabricante para los condensadores C1 y C2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11. Circuito para la deteccin de un dispositivo de alta velocidad. . . . . . . . 5.12. Circuito para la deteccin de un dispositivo de baja velocidad. . . . . . . 5.13. Fragmento del esquema de la circuitera de control del USB relativo a las resistencias de pull-up internas. . . . . . . . . . . . . . . . . . . . . . . . 5.14. Esquema simplicado de la circuitera de control de un pin de E/S. . . . . 5.15. Esquema de conexin de un pulsador a una entrada digital. . . . . . . . . 5.16. Rango de niveles de tensin y su correspondencia con los niveles lgicos en TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.17. Esquema de conexin de cada entrada digital, X1-1 y X1-2 simbolizan pines del conector de apriete, X2-1 y X2-2 simbolizan los extremos de los cables conectados a estos. . . . . . . . . . . . . . . . . . . . . . . . . 5.18. Conexionado interno de los pines de entrada analgicos al conversor A/D del PIC18F2550. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.19. Esquema de conexin de un potencimetro a un conversor A/D. . . . . . 5.20. Esquema de conexin separado. . . . . . . . . . . . . . . . . . . . . . . 5.21. Esquema de conexin nal. . . . . . . . . . . . . . . . . . . . . . . . . . 5.22. Esquema de conexionado interno tpico de una placa de prototipos ProtoBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9. 6.10. 6.11. 6.12. 6.13. 6.14. 6.15. 6.16. 6.17. 6.18. 6.19. 6.20. Tuberas lgicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jerarqua de descriptores USB. . . . . . . . . . . . . . . . . . . . . . . . Papel de los descriptores de informe en la jerarqua de descriptores USB. Report de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intercambio de informacin HASP. . . . . . . . . . . . . . . . . . . . . . Cadena de desafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Imagen de la salida por consola de la aplicacin de prueba swval. . . . . Diagrama de ujo principal. . . . . . . . . . . . . . . . . . . . . . . . . Endpoints utilizados, direccin y propsito. . . . . . . . . . . . . . . . . Jerarqua de descriptores para el dispositivo . . . . . . . . . . . . . . . . Captura de HID descriptor tool . . . . . . . . . . . . . . . . . . . . . . . Registro de conguracin A/D ADCON1 . . . . . . . . . . . . . . . . . Proceso de toma de una muestra con tiempo de adquisicin de 4 TAD . . Registro de conguracin A/D ADCON2 . . . . . . . . . . . . . . . . . Registro de conguracin A/D ADCON0 . . . . . . . . . . . . . . . . . Funcionamiento de las entradas digitales simuladas. . . . . . . . . . . . . Rebote producido al presionar un pulsador. . . . . . . . . . . . . . . . . Mapa de memoria de un dispositivo con bootloader . . . . . . . . . . . . Pila de capas de la librera libhw . . . . . . . . . . . . . . . . . . . . . .
61 62 63 63 65 66 66
67 68 69 69 70 71 76 77 79 80 82 83 84 84 90 91 92 95 98 99 100 101 103 104 107 114
NDICE DE FIGURAS
11
6.21. 6.22. 6.23. 6.24. 6.25. 6.26. 6.27.
Superclase Driver . . . . . . . . . . . . . . . . . . . . . Mquina de estados de la capa Driver . . . . . . . . . Superclase Protocol . . . . . . . . . . . . . . . . . . Mquina de estados de Protocol . . . . . . . . . . . . Clase LSYMHASP . . . . . . . . . . . . . . . . . . . Mquina de estados de LSYMHASP . . . . . . . . . Diagrama de secuencia de un ciclo del protocolo HASP. .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
116 117 117 118 119 120 122
7.1. Prueba de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.2. Prueba de sistema HASP . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.3. Prueba de actualizacin de mware con lsymash . . . . . . . . . . . . . 130 A.1. A.2. A.3. A.4. Layout: Capa Top y Componentes en rojo, Capa Bottom en verde Fotolito: Cara Top . . . . . . . . . . . . . . . . . . . . . . . . . . Fotolito: Cara Botom . . . . . . . . . . . . . . . . . . . . . . . . Fotolito: Capa de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 144 144 145
B.1. Fotografa del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . 149
12
NDICE DE FIGURAS
CAPTULO 1
INTRODUCCIN
1.1.
MOTIVACIONES
En una sociedad como la actual, en la que el pblico demanda aplicaciones con cada vez mayor nivel de interactividad los desarrolladores buscan nuevas formas de interactuar con los usuarios eliminando las barreras de los perifricos de entrada clsicos como el teclado y el ratn mediante el diseo de perifricos especcos para la tarea que se realiza. El campo de la simulacin por computador ha experimentado un auge en los ltimos aos debido en gran medida al rpido avance del hardware y de la tecnologa en general. Las nuevas tcnicas de visualizacin, computacionalmente inviables en el pasado y el abaratamiento del hardware tanto para visualizacin, contando las nuevas GPUs con un numero mayor de transistores y ms potencia de clculo que el procesador central o CPU, como para la captura de la entrada del usuario, siendo barata y ecaz la utilizacin de perifricos tales como trackers, proyectores de vdeo o sistemas de visin esteroscpica que aumentan considerablemente la inmersin del usuario dentro del entorno simulado. Todo esto hace posible que ms personas puedan beneciarse de la tecnologa, que est siendo ampliamente implantada, entre otros campos, en el formativo para entrenamiento sin riesgos ni altos costes asociados de futuros profesionales, como es el caso por ejemplo del manejo de maquinaria de obra civil. El desarrollo de un simulador suele estar enfocado a un campo muy concreto y a la realizacin repetitiva de un conjunto de tareas y maniobras especco (ya sea conducir un camin o manejar una gra). Uno de los principales objetivos durante el desarrollo consiste en lograr la mayor inmersin posible del usuario en el entorno simulado, lo que en la mayora de casos descarta al tradicional teclado y ratn como principal mtodo de entrada, lo que podra provocar que la aplicacin perdiese gran parte de su funcin didactica. Este aspecto puede ser mejorado si la entrada del usuario proviene de un dispositivo lo ms parecido posible al utilizado en la vida real. Por lo tanto resulta interesante desde el punto de vista de la simulacin, que exista una correspondencia entre el tipo concreto de simulador y el tipo de perifricos de entrada/salida para la interaccin con el usuario que se utilizan.
14
1.1. MOTIVACIONES
Sin embargo los dispositivos de control usados en la vida real distan mucho de ser perifricos aptos para un ordenador personal, y varan mucho en forma y tecnologa de unos a otros, teniendo cada uno sus propias interfaces elctricas y lgicas. De esta manera se plantea el problema consistente en capturar la entrada de uno de estos dipositivos para entregrsela al simulador, para que este a su vez pueda actualizar en consecuencia el estado de la simulacin y producir resultados en su visualizacin grca o de retorno al propio perifrico en forma de seales luminosas, o de variaciones en sus indicadores o actuadores. No obstante, todos los dispositivos de control reales suelen tener caractersticas comunes, siendo la principal el hecho de que estn formados por transductores y sensores elctricos tales como pulsadores o potencimetros, cuyos niveles de tensin se pueden medir para obtener una entrada adecuada. De manera que estos dispositivos pueden ser adaptados para ser convertidos en perifricos aptos para formar parte de un simulador. Por otra parte, el uso indebido de la tecnologa acarrea consecuencias que impactan negativamente en la evolucin y el desarrollo la industria ya que no solo disminuye los ingresos, sino que tambin redunda en menos I+D y disminuye las inversiones en desarrollo de marketing. En los ltimos aos, el uso de software ilegal en Espaa no ha hecho ms que aumentar en relacin a Europa Occidental [AGM08] como se desprende de la gura 1.1, ocupando el decimo segundo puesto del ranking mundial de prdidas producidas por piratera. Las copias ilegales tanto de software como de cualquier material amparado por derechos de autor est castigada con diversas penas por la ley y las fuerzas de seguridad en gran nmero paises, lo cual no consigue sino mitigar este impacto sin llegar a obtener unos resultados aceptables. Con el fn de reducir al mnimo estas actividades delictivas, desde hace ms de dos dcadas se vienen desarrollando y utilizando tecnologas, unas veces basadas total o parcialmente en teoremas que llevan existiendo ms de cincuenta aos como es el caso de la criptografa, y otras totalmente nuevas, la implementacin ya sea por software (nmeros de serie, activacin telemtica ...) o por hardware (dispositivos de bloqueo) siempre est destinada nicamente a limitar en la medida de lo posible la reproduccin o difusin no autorizadas de dichos materiales. Resulta por tanto de gran utilidad en la interseccin de ambos campos combinar en un mismo dispositivo la capacidad de proporcionar al simulador la entrada del usuario (pulsacin de botones, movimientos, ...) de manera adaptada a ste, y la de proteccin del software contra la reproduccin ilegal, aprovechando el hecho de que el dispositivo ser necesario para controlar la simulacin, y se distribuye al menos uno con cada copia del software. El presente proyecto surge de la necesidad de incorporar un componente en el interior de una botonera real de control de una gra torre, que le permita conectarse a un PC para la utilizacin del simulador de entrenamiento en el manejo de este tipo de gra, y aprovechar el desarrollo del hardware para aplicar una proteccin anticopia algo ms robusta que los mtodos tradicionales por software. Para terminar es preciso sealar que el diseo ser totalmente reutilizable para cual-
CAPTULO 1. INTRODUCCIN
15
Figura 1.1: Evolucin sobre el software ilegal en Espaa de 2003 a 2007 quier otro simulador o aplicacin relacionada.
1.2.
OBJETIVOS
El objetivo principal del presente proyecto es: Disear y construir un dispositivo hardware perifrico intermediario entre los transductores de los mandos de control de una maquinaria real y un computador que adems ofrezca un sistema de validacin de software, obteniendo as un dispositivo hbrido que proporcione ambas funcionalidades. El desarrollo de una librera software y herramientas adicionales necesarias que permitan al computador acceder a las funciones proporcionadas por dicho dispositivo perifrico. Las principales caractersticas que debe tener el dispositivo son: El dispositivo estar fsicamente conectado al computador mediante el bus USB 1 y a los transductores, con el n de aislar el tipo concreto de dispositivo de control del computador en el que se utilice. No requerir alimentacin externa. Tomar muestras sobre el estado de los sensores y comunicar las lecturas de manera adecuada al computador. El dispositivo validar el software de forma segura, robusta, y no penalizar a aquellos usuarios que posean una copia legtima del software.
1
La eleccin del bus USB como interfaz con el computador ser justicada en las posteriores secciones.
16
1.2. OBJETIVOS
Tiene que ofrecer dicultades contra la ingeniera inversa de dicha proteccin. A continuacin se enumeran las caractersticas que debe cumplir la librera software: La librera se encargar de la monitorizacin contnua del estado de conexin del dispositivo. Ser la responsable de asegurarse de que el dispositivo es autentico mediante el intercambio de mensajes. Noticar al software protegido de eventos producidos en relacin a los apartados anteriores para que ste pueda actuar en consecuencia. Ser transparente para el programador. Ocupar los mnimos recursos tanto espaciales como temporales en el computador como sea posible. Tendr un diseo modular y estar construida sobre un lenguaje de programacin de alto nivel y de uso comn.
CAPTULO 2
ESTADO DEL ARTE
2.1.
INTRODUCCIN
En la presente seccin se realiza un estudio de la tecnologa actual y alternativas existentes para abordar los problemas anteriormente presentados. El objetivo de dicho estudio es recabar y evaluar las distintas alternativas disponibles para determinar las ms adecuadas para el presente proyecto.
2.2.
ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS
Todo computador cuenta con un subsistema de Entrada/Salida encargado de la comunicacin con el mundo exterior. Se compone de un conjunto de mdulos que comunican la CPU con dispositivos externos deniendo un interfaz, y contienen lgica necesaria para liberar a la misma de tareas necesarias para esta comunicacin como pueden ser el control de ujo o la conversin serie a paralelo. A diferencia de lo que ocurre con los accesos a memoria en los que la CPU gobierna totalmente el proceso, dado que genera todas las seales de control implicadas, en transferencias de E/S la responsabilidad es tanto de la CPU como del propio perifrico, puesto que ste es en denitva un elemento que funciona de forma independiente [CSFBAOSS01]. En denitiva, estos mdulos controlan y se comunican con perifricos externos de forma paralela a la CPU, al mismo tiempo que aislan a la misma del tipo de perifrico y de sus caractersticas (velocidad de transmisin, ancho de palabra ...). Se construyen en torno a un estndar para permitir la interconexin de diversos perifricos de fabricantes distintos. Los mdulos de E/S pueden conectarse directamente al bus del procesador, o a un bus dedicado de E/S como se muestra en la gura 2.1). En el caso ms comn: El registro de estado contiene informacin que permite a la CPU conocer el estado actual del perifrico. En el registro de datos se cargan los ltimos datos recibidos desde el perifrico, o
18
2.2. ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS
Figura 2.1: Interfaz de E/S para un dispositivo generco [CSFBAOSS01] que se desean transmitir (a menudo se emplean colas FIFO para interrumpir menos a la CPU). El controlador de interfaz contiene la lgica que controla el perifrico segn su estndar, adems de recibir rdenes desde la CPU y noticarle eventos mediante lneas de interrupcin (no se han representado en la ilustracin). El mdulo de E/S puede as ser capaz de copiar los datos a un destino especco sin intervencin de la CPU mediante transferencias DMA1 , bien leer o escribir datos de forma activa, o hacerlo como resultado de una interrupcin. A continuacin se describen los estndares e interfaces ms importantes para la interconexin de perifricos con un computador, clasicndolos en tres categoras: Serie: Los datos son transmitidos mediante el uso de una sola lnea elctrica. Paralela: Los datos son transmitidos mediante el uso de varias lneas elctricas que transportan datos de forma simultnea. Inalmbrica: No se emplean lneas para la transmisin entre el perifrico y el interfaz, sino que se utiliza algn enlace basado en radio o haz de luz, sin embargo s se emplean entre el interfaz y la CPU.
Direct Memory Access o Acceso Directo a Memoria, es como se llama al controlador que permite la transferencia de bloques de informacin entre dos mdulos conectados al bus sin intervencin activa de la CPU.
1
CAPTULO 2. ESTADO DEL ARTE
19
2.2.1.
Interfaces Serie
Las interfaces serie son las ms utilizadas debido a su gran exibilidad y al reducido nmero de hilos necesario en comparacin con las interfaces paralelas. En este tipo de interfaz los bits viajan uno a uno a travs de una lnea, y se codica cada estado de un bit (cero o uno) con un nivel de tensin. Por lo tanto se necesita algn mecanismo de control para asegurar que el destinatario de la transmisin captura estos bits en el momento preciso. Es aqu donde se hace la distincin entre interfaces serie sncronas y asncronas. En las interfaces sncronas, las lneas de datos van acompaadas de algn tipo de seal de control, ya sea una seal de reloj, o seales de solicitud y reconocimiento. En el primer caso, el emisor genera una seal de reloj de forma que el bit presente en la lnea deja de ser vlido con el inicio de un nuevo ciclo, momento en el que se coloca el siguiente bit en la lnea, se puede elegir tanto en el anco ascendente como en el descendente. En el segundo caso, se utilizan dos lneas, una de peticin desde el emisor hasta el receptor, y otra de reconocimiento desde el receptor al emisor. El emisor activa la seal de peticin al poner un nuevo bit en la lnea, y lo mantendr hasta que el receptor conrme que lo ha recibido activando la lnea de reconocimiento, momento en el que se repite el ciclo. Presentan la ventaja de que el receptor funcionar a la frecuencia determinada por estas seales de control, de esta forma el emisor y el receptor determinan la velocidad de transferencia. En las interfaces asncronas, tanto emisor como receptor deben estar sincronizados, puesto que slo se usan lneas de datos. El emisor enva los bits a una frecuencia determinada y el receptor debe capturarlos en los instantes de tiempo precisos, por lo tanto el desvo entre los relojes de emisor y receptor debe ser mnimo. Por otra parte es necesario enviar informacin de sincronizacin, en unos casos marcando el inicio de una transferencia para que el receptor sepa cuando debe empezar a capturar, o en otros utilizando codicaciones como Manchester, que no utiliza niveles de tensin para sealizar el estado de un bit, sino transiciones entre estos. Las interfaces serie asncronas suelen implementar control de errores mediante un bit de paridad. La velocidad de transferencia se mide en baudios, que en este caso coincide con bits por segundo.
Interfaz Serie RS-232

Se trata de la norma denida por la EIA 2 , que establece un interfaz para el intercambio en serie de datos entre un DTE (equipo terminal de datos), y un DCE (normalmente un modem, pero puede ser otro dispositivo). La transmisin puede ser asncrona o sncrona, utilizndose niveles de tensin de -3 a -15 V para el nivel bajo lgico y de +3 a +15 V para el nivel alto. Est diseado para distancias cortas (hasta 15 metros), y para velocidades de transmisin de no ms de 20 kilobytes/segundo. Para la comunicacin asncrona se genera un bit de inicio de la transmisin (nivel ba2
Electronic Industries Alliance
20
Figura 2.2: Cronograma de una transmisin RS-232 a 1600 baudios sin bit de paridad
Figura 2.3: A la izquierda conector DB-25, a la derecha conector DB-9 jo), y un bit de nal de la transmisin (nivel alto), as como un bit de paridad opcional (vase g 2.2). Cuando la lnea est inactiva permanece a nivel alto. Permite la comunicacin simplex, half duplex o full duplex, con lneas dedicadas para el control de ujo. Esto es til en el caso de que el receptor procese los datos a una velocidad menor de la que los reciba, ya que puede sealizar al emisor para que detenga temporalmente la transmisin. La conexin se realiza mediante un conector de tipo DB-25, pero es ms comn encontrar conectores de tipo DB-9 (g 2.3), ms baratos y pequeos. El mdulo de E/S encargado de la comunicacin serie se llama UART (Transceptor asncrono universal), o USART (Transceptor sncrono y asncrono universal). La gran mayora de los PCs incorporan al menos uno, pero debido a la prdida de popularidad de este tipo de enlace en los ltimos aos, cada vez es ms dicil encontrarlo, sobretodo en equipos porttiles.
USB
USB es en la actualidad el interfaz de facto para la conexin de perifricos a un computador. El estndar USB fue libreado en 1996 por Compaq, NEC, Northern Telecom, IBM, DEC, Intel y Microsoft, consorcio conocido como el USB-IF3 que respalda
3
USB Implementers Forum
21
su estandarizacin. La principal razn que propici su desarrollo fue que los puertos RS232 y Centronics tradicionales se estaban empezando a convertir en un cuello de botella a medida que la tecnologa avanzaba, adems de otras razones como la necesidad de incrementar el nmero de puertos disponibles o el no tener que adquirir tarjetas especiales, que consuman recursos limitados del PC (rangos de memoria y lneas de interrupcin que se conguraban manualmente). Proporciona una gran exibilidad en cuanto a que admite la conexin de una enorme diversidad de perifricos, as como otras caractersticas como la capacidad de multiplicar el nmero de puertos disponibles mediante el uso de concentradores USB, la conexin y conguracin en caliente (sin apagar la mquina) de hasta 127 dispositivos en el mismo bus, o el hecho de que proporciona alimentacin a los perifricos de forma que si su consumo se encuentra dentro de unos lmites no es necesaria una fuente de alimentacin externa. La especicacin inicial (USB 1.0) soporta nicamente la velocidad de 1.5 Mbps para dispositivos lentos como teclados o joysticks. Estos dispositivos son llamados de baja velocidad. En 1998 se public una revisin: USB 1.1, en la que se aadi un nuevo tipo de transferencia para facilitar el desarrollo de perifricos de interfaz humana como ratones o teclados y el incremento de la velocidad de transferencia hasta 12 Mbps deniendo la clase de dispositivos de velocidad completa, utilizado para dispositivos ms rpidos como las unidades de almacenamiento. Posteriormente, en el ao 2000 se liber la especicacin USB 2.0, con el anexo al USB-IF de las compaias Lucent, Philips y HP. Su principal mejora respecto a su predecesor fue un gran incremento en la velocidad de transferencia, llegando hasta los 480 Mbps (dispositivos de alta velocidad). Es totalmente compatible con USB 1.0 y 1.1, ya que comparte los mismos conectores y cables pero los concentradores deben soportarlo porque han de permitir la convivencia de trcos de tres velocidades distintas, lo que los hace ms complejos. Para garantizar la compatibilidad, un concentrador 2.0 al que se le conecta un dispositivo ms lento adapta la velocidad de forma adecuada. Los fabricantes optan por seguir fabricando dispositivos que cumplen la norma USB 1.1 si no necesitan grandes tasas de transferencia para mantener la compatibilidad con equipos viejos. En 2001 el USB-IF, de la necesidad de comunicar distintos perifricos entre s sin la necesidad de un computador equipado con un host USB, public la especicacin USB OTG (On The Go), que dene una norma segn la cual los perifricos pueden implementar una funcionalidad de host reducida para la comunicacin directa punto a punto de dispositivos tales como cmaras fotogrcas e impresoras. El 17 de Noviembre de 2008, se anunci que la versin 1.0 de la especicacin de USB 3.0 estaba completa. El nuevo estndar, tambin conocido como SuperSpeed USB, proporciona un nuevo modo de transferencia de 4.8 Gbps, pudiedonse obtener 3.2 Gbps reales tras la carga que supone el protocolo. En modo SuperSpeed, la comunicacin es full-dplex puesto que existen dos pares de lneas diferenciales nuevos para la comu-
22
Figura 2.4: Diagrama del conector USB 3.0 nicacin en ambos sentidos. El host no interroga constantemente al dispositivo, lo que redunda en una gestin mucho ms eciente de la energa. USB 3.0 proporciona hasta 900 mA de corriente, suponiendo un incremento del 80 % respecto a su predecesor. Se mantiene la retrocompatibilidad con USB 2.0 y anteriores pero el conector cambia ligeramente para acomodar las nuevas lneas, aunque los conectores tradicionales de tipo A podrn conectarse a receptculos de USB 3.0, no ocurriendo lo mismo con los de tipo B [UIb]. Se espera que los primeros productos comerciales basados en USB 3.0 estn disponibles a partir de 2010. Los componentes de USB son tres: Host: Es el mdulo de E/S encargado de controlar todo el bus, asignar direcciones, gestionar la potencia y la alimentacin, controlar errores y comunicarse con el computador. Los ordenadores personales pueden estar equipados con ms de uno. Concentrador: Permite conectar varios dispositivos USB a un solo puerto gestionando todos los aspectos relacionados con su enumeracin y funcionamiento. Puede servir como fuente de alimentacin adicional. Dispositivo: Es el perifrico propiamente dicho, actua como extremo en la comunicacin El estndar USB dene desde las especicaciones lgicas hasta las mecnicas para conseguir la mayor compatiblidad entre dispositivos fabricados por distintas compaas. Utiliza una topologa basada en estrella (g 2.6). Cada dispositivo se conecta a un puerto del concentrador raz, o a otro concentrador lo que permite acoplarlos en cascada para multiplicar el nmero de puertos disponibles y conectar hasta un total de 127 dispositivos. La conexin es muy rpida y sencilla y no es necesario reiniciar el sistema ya que
23
Figura 2.5: Tipos A y B del conector USB
Figura 2.6: Topologa de USB 2.0 y predecesores el concentrador raz es noticado de la conexin y desconexin de nuevos dispositivos y ste es congurado y puesto en marcha de inmediato. Presenta gran inmunidad al ruido debido a que para la transmisin de datos se emplea un par de cables trenzados con seal diferencial y apantallados, que proporcionan una comunicacin half-duplex (o de un solo sentido simultneamente). La longitud mxima del cable es de alrededor de 5 metros [Axe05]. Tambin se incluyen dos lneas que proporcionan 5V de alimentacin (hasta 500 mA) y tierra, que en muchos casos es suciente para alimentar el perifrico. Los datos se transmiten en cdigo NRZI (No retorno a cero invertido), que incluye informacin de sincronizacin. Los dispositivos USB contienen en su memoria informacin sobre sus caractersticas, entre las principales y comunes a todos: Norma USB soportada (1.0, 1.1 o 2.0)
24
Ancho de banda requerido Potencia consumida Datos del fabricante y nmero de serie Esta informacin se organiza en descriptores, que forman un cdigo binario. Cuando el dispositivo se conecta, el hub ms cercano detecta una variacin de tensin entre sus lneas de datos. En este momento el perifrico pasa por un proceso llamado enumeracin en el que el host lo reconoce, le asigna una direccin (nica en el bus), un ancho de banda mximo y notica al sistema operativo de su presencia, el cual intentar cargar un controlador compatible. Durante este proceso, el host interroga al dispositivo obteniendo sus descriptores que le proporcionan la informacin necesaria para llevar a cabo esta tarea. Para iniciar la comunicacin el host enva un comando acompaado de la direccin del dispositivo destinatario, lo que da lugar a una transferencia. Existen cuatro tipos de transferencia soportadas por el protocolo USB: Control: Se utilizan para el control del bus, como la noticacin al host de la conexin de un nuevo dispositivo, o la asignacin de una direccin de bus. Interrupcin: Son utilizadas por los dispositivos que requieren la atencin eventual del host, fundamentalmente dispositivos de interfaz humana como joysticks, ratones o teclados. Masiva o Bulk: Se usan para transmitir grandes bloques de datos de forma eciente que usan todo el ancho de banda disponible. Su uso est centrado en dispositivos de almacenamiento, impresoras, etc. Iscrona: Estas transferencias garantizan una latencia mxima pero no que los datos sean correctos, tienen un ancho de banda mnimo garantizado. Se utiliza cuando se requiere una tasa de transferencia constante y resulta aceptable perder datos. Casos de uso frecuente son dispositivos de audio y vdeo. Es preciso sealar que las velocidades mximas de USB no son reales puesto que en la realidad el intercambio de transferencias de control y para otros propsitos consumen una parte. Los dispositivos USB que llevan el logotipo ocial del USB-IF han superado un proceso de validacin del dispositivo. Para obtener esta validacin se han de realizar una serie de pruebas, estas dependen del tipo de dispositivo y de su velocidad. Finalmente hay que enviar al USB-IF un formulario con la informacin sobre el dispositivo y el resultado de los tests [UIa].
25
Figura 2.7: Conectores Firewire
IEEE-1394 o FireWire
El IEEE-1394, tambin conocido como Firewire es el estndar de comunicaciones de alta velocidad desarrollado por Apple y Sony a mediados de los 90. Es un estndar para la conexin a dispositivos que requieren gran ancho de banda y que ha sido rpidamente adoptado. Sus principales caractersticas son: Alcanza una velocidad sostenida de 400 Mbps. Permite la conexin de un mximo de 63 dispositivos, que pueden comunicarse entre s. Acepta longitudes de cable de hasta 4.25 m. Puede garantizar una distribucin de los datos en perfecta sincrona. Permite la desconexin y conexin durante el uso sin tener que reiniciar el sistema (plug & play). Se alimenta por el propio bus, proporcionando hasta 25 V, suciente para muchos discos duros de alto rendimiento y bateras de carga rpida. Todo lo anterior lo hace idneo para aplicaciones multimendia como la edicin de vdeo digital en la que se requiere una alta tasa de transferencia y se precisa una latencia mnima. En la actualidad, tanto PCs como Macintosh estn equipados con puertos FireWire, y existe en el mercado una amplia gama de dispositivos desde reproductores de vdeo, sistemas de entretenimiento domstico, dispositivos de grabacin de audio profesional hasta unidades de almacenamiento masivo. Dada su superioridad en cuanto a ancho de banda respecto a USB, es un estndar a tener en cuenta para el tipo de aplicaciones anteriormente mencionadas, pero presenta la desventaja de ser ms caro de implementar.
2.2.2.
Interfaces Paralelas
Las interfaces paralelas se caracterizan por transmitir varios datos por lneas independientes de forma simultanea, lo que permite aumentar el ancho de banda. El tradicional
26
puerto paralelo, basado en conector DB-25 est tambin desapareciendo progresivamente debido a sus prestaciones, lo que lleva a que los fabricantes opten por interfaces ms modernos para la conexin de sus dispositivos.
Puerto paralelo Centronics

Fue diseado por la compaia Centronics Data Computer Corporation para sus primeras impresoras matriciales empleando un conector de 36 pines que rpidamente pas a conocerse como conector Centronics. Posteriormente, cuando IBM implement el interfaz paralelo en el IBM PC, emplearon el conector DB-25 en el lado del PC, dejando el conector original de 36 pines en el lado de la impresora. Consta de 8 lneas de datos, y otras 10 de control, utiliza niveles de tensin TTL y soporta velocidades de hasta 100 Kbytes/s. Es muy susceptible al ruido electromagntico debido a que las lneas no estn balanceadas y la norma no dene ningn tipo de blindaje. Ms tarde fue reemplazado por el estndar IEEE-1284, que especica los modos adicionales EPP4 , ECP5 , el modo 4 bits y el modo 8 bits. Estos nuevos modos permiten la comunicacin bidireccional y el control de errores incrementando las tasas de transferencia debido a que los protocolos son implementados por hardware. En el caso de los PC, la BIOS permite seleccionar el modo de operacin del puerto paralelo.
2.2.3.
Interfaces Inalmbricas
Bluetooth
Bluetooth es un conjunto de especicaciones denidas por el Bluetooth Special Interest Group para el intercambio de datos sin cables a travs de cortas distancias. Trabaja en la banda ISM de 2.4 GHz. Puede conectar varios dispositivos en redes de rea personal (PAN) gestionando la sincronizacin. Para la transmisin utiliza una tecnologa llamada frequency hopping spread spectrum, o espectro expandido por salto de frecuencias que cambia la frecuencia de transmisin de acuerdo a un patrn basado en 79 frecuencias distintas en su modo bsico. Este sistema permite alcanzar una tasa de transferencia de datos de 1 Mbit/s. Bluetooth proporciona una forma de conectarse e intercambiar informacin entre dispositivos como telfonos mviles, ordenadores, impresoras, sistemas GPS, cmaras digitales y consolas de videojuegos entre otros. Esto se consigue mediante el uso de perles que agrupan las caractersticas comunes a una clase de dispositivos (audio, teclados, almacenamiento, ...).
4 5
Enhanced Parallel Port, o Puerto Paralelo Mejorado Extended Capabilities Port, o Puerto con capacidades extendidas
27
Existen tres clases de dispositivos segn la potencia consumida y su alcance, variando entre 1 y 100 metros. La versin 2.0+EDR6 alcanza los 3 Mbits/s. La especicacin Bluetooth est basada en un protocolo formado por capas: LMP (Link Management Protocol) Utilizado para controlar el enlace de radio entre dos dispositivos. Se implementa en el controlador. L2CAP (Logical Link Control & Adaptation Protocol) Se utiliza para multiplexar mltiples conexiones lgicas entre dos dispositivos usando diferentes protocolos de ms alto nivel. Proporciona segmentacin y reensamblado de los paquetes transmitidos. SDP (Service Discovery Protocol) Permite a los dispositivos descubrir qu servicios soportan los otros, y qu parmetros se utilizan para conectarse a ellos. Cada servicio se identica con un UUID7 . HCI (Host/Controller Interface) Estandariza la comunicacin entre la pila de capas del protocolo Bluetooth y el controlador (el circuito integrado Bluetooth). Esta estandarizacin permite reemplazar el circuito integrado con cambios mnimos. Segn los protocolos utilizados se necesitan capas adicionales. Cada dispositivo Bluetooth puede comunicarse con hasta siete dispositivos en un grupo de usuarios inalmbrico ad-hoc de hasta 8 dispositivos, conocido como piconet.
2.3.
MICROCONTROLADORES
Se entiende como controlador un sistema especializado y encargado de controlar un proceso o un conjunto de procesos altamente relacionados entre s. Este tipo de dispositivos ha evolucionado desde su construccin exclusivamente con lgica discreta hace tres dcadas, a su implementacin mediante el uso de un microprocesador rodeado de toda su circuitera de soporte (memoria, lgica de seleccin, de interrupciones, E/S ...) en una tarjeta de circuito impreso, y nalmente a la miniaturizacin de todos estos componentes en un solo chip, denominado microcontrolador. Las razones principales para el uso de un microcontrolador en lugar de una mquina de propsito general son [Per05]: Gestin eciente de procesos Aumento de la abilidad Reduccin del tamao, consumo y coste
6 7
Enhanced Data Rate, o Tasa de datos mejorada Universally Unique Identier o Identicador universalmente nico
28
2.3. MICROCONTROLADORES
Mayor exibilidad Por tanto un microcontrolador es un circuito integrado que contiene los elementos de un computador minimalista para gobernar o controlar parte de un sistema mayor en el que, gracias a su reducido tamao, suele estar incorporado. Al estar dotados de un alto grado de especializacin, contienen perifricos de aplicacin especca. Segn [Axe97] se pueden encontrar microcontroladores en todo tipo de cosas en la actualidad. Cualquier dispositivo que mida, almacene, controle, calcule, o visualice informacin es un candidato para ser gobernado por un microcontrolador. El uso ms extendido de estos lo encontramos (como puede verse en la gura 2.8) en el sector de la informtica, donde pueden encontrarse en perifricos tales como teclados o impresoras. Son un producto de la rpida evolucin de la tecnologa.
Figura 2.8: Utilizacin de microcontroladores por cada sector Puesto que los microcontroladores, como ya se ha explicado son sistemas especializados para una aplicacin concreta, y no mquinas de propsito general como podra serlo un PC, existe en el mercado una inmensa cantidad modelos, que ofrecen muy diversas combinaciones de caractersticas. Mientras que unos presentan cantidades de memoria RAM mayores, otros disponen de caractersticas DSP8 , e incluso recientemente han aparecido microcontroladores con caractersticas tan exticas como la integracin en el mismo chip de lgica programable [ST], o microcontroladores compuestos por varias CPUs independientes [Par]. De esta manera es responsabilidad del ingeniero realizar la eleccin correcta atendiendo a los requisitos de la tarea para la que se va a emplear con el n de minimizar los costes de hardware y software, aspecto de vital importancia si se opta por la produccin masiva del producto nal. Los principales factores a tener en cuenta en la eleccin de un microcontrolador son: Velocidad
Digital Signal Processing o Procesado Digital de Seal es una arquitectura SIMD que permite la aplicacin de operaciones sobre conjuntos de datos de forma eciente.
8
29
Es necesario asegurarse de que el sistema va a ser capaz de ejecutar su tarea en el tiempo requerido. Nmero y tipo de lneas de Entrada y Salida Estas deben ofrecer un interfaz adecuado para los sensores o el resto de componentes del sistema para minimizar la circuitera externa necesaria. Herramientas de desarrollo disponibles Es imprescindible poder contar con el software (compilador, depurador, documentacin), y el hardware (programador/ICD 9 ). En su memoria ROM slamente reside un programa encargado del control de una aplicacin determinada (tareas tpicas de estos son la adquisicin de datos desde sensores, la comunicacin de informacin o el control de otros dispositivos externos). Al ser un programa de aplicacin especca, que reside en una memoria de estado slido, y que gestiona el hardware a bajo nivel, podemos catalogarlo como rmware. Estos programas se ejecutan en bucle innito, ya que corren sobre la mquina desnuda y no existe un sistema operativo subyacente al que devolver el control tras la nalizacin del mismo. El rmware debe ser cargado en la memoria no voltil del microcontrolador, a este proceso se conoce como programacin. Los microcontroladores suelen ser programados con la ayuda de un dispositivo programador especco proporcionado por el fabricante, aunque hoy en da casi todos ofrecen la caracterstica de reprogramabilidad ICSP10 . Una vez programado, el microcontrolador queda listo para ejecutar el cdigo rmware residente en su memoria. Debido a la gran variedad existente en el mercado, que ofrece innumerables familias de microcontroladores se pueden hacer muchas clasicaciones, siendo uno de los factores ms signicativos para ello la cantidad y tipo de perifricos integrados, que comnmente suelen ser: CPU Memoria ROM (EEPROM/PROM/FLASH) para almacenamiento del programa y datos constantes. Memoria RAM para almacenamiento de variables. Dispositivos de comunicacin y control USART, I2C, SPI, Paralelo, USB, Ethernet
In Circuit Debugging, o Depuracin en Circuito es un mtodo que permite depurar la aplicacin rmware sin tener que extraer el microcontrolador de su ubicacin en la placa de circuito impreso del sistema microcontrolado. 10 In-Circuit Serial Programming, o programacin serie en el circuito se entiende como la capacidad de ser reprogramados en la propia placa de circuito impreso en la que estan instalados sin necesidad de extraerlos.
9
30
2.4. DISPOSITIVOS HASP
Comparadores de tensin analgicos Controladores Puertos de E/S digitales Conversores A/D y D/A Moduladores de seal por anchura de pulsos (PWM) Multiplicadores de frecuencia de reloj (PLL), divisores de frecuencia y osciladores incorporados Watchdog 11 Circuitera adicional de soporte a todo lo anterior (lgica de seleccin, arbitrado de buses, circuitos de proteccin ...) Otro factor relevante para establecer una clasicacin es el ancho de palabra de la CPU, siendo los ms comunes de 4 y 8 bits por ser econmicos y sucientes para muchas aplicaciones. Los principales fabricantes de microcontorladores son Microchip, Freescale, Intel, Texas Instruments, Philips, Renesas, Cypress Semiconductor y National Semiconductor entre otros, pero es la gama de microcontroladores PIC del fabricante Microchip la que goza de mayor popularidad entre profesionales y acionados. Este xito se debe en gran parte a su precio, su disponibilidad y sus herramientas de desarrollo.
2.4.
DISPOSITIVOS HASP
El trmino HASP viene de las siglas inglesas Hardware Against Software Piracy, o hardware contra la piratera del software. Reciben este nombre los dispositivos destinados a limitar el uso de un determinado software a su legtimo propietario y evitar as la distribucin ilegal que se produce rpidamente por Internet, y en menor medida por otros medios. Esta tecnologa, debido al incremento de coste que supone se suele implementar en paquetes de software muy costosos y software de mercado vertical, como CAD o edicin de audio profesional, donde las prdidas econmicas derivadas del uso ilegal pueden ser signicativas. Un dipositivo HASP debe estar conectado fsicamente a la mquina que ejecuta el software durante todo el periodo de uso del mismo. La proteccin ms dbil consiste en que el software compruebe si el dispositivo est presente, lo que suele implementarse como una funcin que devuelve simplemente true o false. El ataque a esta proteccin consiste en desensamblar y trazar el programa para aislar la instruccin de salto condicional que hace que el software funcione o no. La
Sistema basado en un temporizador que evita que el dispositivo quede atrapado en un bucle innito, o bloqueado por otra causa.
11
31
instruccin se reemplaza con otra que siempre salta a la misma direccin incondicionalmente, lo que da lugar a un ejecutable parcheado. Un sistema ms seguro y ms utilizado consiste en el intercambio contnuo de mensajes cifrados entre el host y el dispositivo. De esta manera el dispositivo debe ejecutar un algoritmo capaz de mantener este dilogo, lo que requiere de informacin secreta codicada nicamente en los dispositivos HASP originales. Los dispositivos HASP modernos incorporan como ya se ha comentado encriptacin, y tcnicas de fabricacin destinadas a evitar la ingeniera inversa. Tpicamente incluyen memoria no voltil donde almacenan informacin sobre la licencia y un microprocesador que ejecuta partes del software en el propio dispositivo, convirtiendose as en criptoprocesadores seguros. Sin embargo los investigadores de seguridad advierten que los dispositivos an no solucionan el problema del trusted client, de forma que si se le da a un usuario un mensaje cifrado, el algoritmo y la clave, el sistema es potencialmente inseguro, incluso con el algoritmo y la clave codicados en el hardware [Gra05]. Por otro lado, si esto sucede los dispositivos HASP pueden ser clonados, producindose versiones no autorizadas del mismo, o creando drivers emuladores que simulan la conexin y el comportamiento del dispositivo. Los dispositivos HASP con reloj contienen un reloj de tiempo real independiente al del sistema operativo para los fabricantes que requieren manejar perodos de uso acotados como el alquiler. La empresa lder en tecnologas hardware de seguridad es Aladdin, que cuenta con un catlogo de llaves HASP USB que implementan encriptacin AES de 128 bits, y un completo sistema de certicados, rmas digitales y validacin telemtica tanto para validacin de software, como para uso de servicios on-line o acceso a redes corporativas. Aladdin ofrece kits de desarrollo gratuitos [AKS]. Las llaves HASP se comercializan por lotes con precios desde 3130 e[Ste09].
2.5.
DISPOSITIVOS DE ADQUISICIN DE DATOS (DAQ)
Los sistemas de adquisicin de datos se utilizan para medir y registrar seales que pueden ser obtenidas de dos maneras: Las que se originan a partir de la medicin directa de magnitudes elctricas, componentes contnuas, frecuencias y resistencias. Las que se originan a partir de transductores, como galgas extensiomtricas o termopares. Las operaciones esenciales de un sistema de adquisicin de datos incluyen la manipulacin de seales analgicas, medicin, conversin y manejo de datos digitales, y programacin y control interno. Un sistema de adquisicin de datos digital se compone de los siguientes elementos:
32
2.5. DISPOSITIVOS DE ADQUISICIN DE DATOS (DAQ)
Figura 2.9: Ejemplo de seal digital ideal
2.5.1.
Componentes
Transductor: Transforma parmetros fsicos en seales elctricas, reconocibles por el sistema de adquisicin. Acondicionamiento de seal: Es un subsistema que contiene la circuitera que da soporte al transductor. Por lo general esta circuitera puede proporcionar la energa de excitacin, circuito de equilibrio y elementos de calibracin especcos del transductor. Tambin amplica, modica o ltra ciertas partes de la seal de salida proporcionada por el transductor a unos niveles aceptables por las siguientes fases. Multiplexor: Acepta varias entradas analgicas y las conecta secuencialmente a un instrumento de medicin. Conversor analgico-digital (ADC o Analog to Digital Converter). Convierte el voltaje analgico a su equivalente digital. Es el nico elemento totalmente indispensable de un sistema de adquisicin de datos, y podra constituir uno por s mismo. Unidad de proceso de datos: Colecciona, monitoriza y almacena los datos tomados. Hay muy diversos tipos de dispositivos de Adquisicin de Datos que se pueden clasicar atendiendo principalmente al tipo de seales que adquieren:
Digital
Las seales digitales, en contraste con las seales analgicas, no varan en forma continua, sino que cambian en pasos o en incrementos discretos. La mayora de las seales digitales utilizan cdigos binarios o de dos estados. En el marco de este proyecto, las seales digitales se asocian a los pulsadores, ya que estos tienen dos estados (pulsado/no pulsado) al igual que la seal.
Analgica
Las seales analgicas varan de forma contnua. Los transductores analgicos suelen generar una seal elctrica analgica de valor (voltaje) proporcional a la magnitud medida
33
Figura 2.10: Ejemplo de seal analgica (presin, temperatura, ngulo de giro...). Un ejemplo de transductor es una clula fotovoltaica, que genera a su salida una corriente proporcional a la intensidad de luz incidente en ella, o el potencimetro que produce como salida un cambio en la resistencia, relacionada con la posicin angular del eje. En nuestro caso las seales analgicas se asocian con las palancas y joysticks, ya que en ltima instancia estn construidos con potencimetros, que son transductores analgicos, y tienen un recorrido contnuo y suave. Las seales analgicas plantean adems el problema de su conversin. Al necesitar transmitirse a un sistema inherentemente digital como lo es un computador, tienen que pasar por una fase de conversin previa, llamada muestreo. El dispositivo encargado de realizar esta conversin se denomina conversor A/D (Analgico a Digital).
2.5.2.
Conversor Analogico-Digital (ADC)
El conversor analgico-digital es como ya se ha dicho el elemento ms importante de un sistema de adqusicin de datos. Existen varios tipos de conversor, segn la circuitera empleada para realizar la conversin, pero todos tienen en comn los siguientes parmetros que pueden evaluarse como factores de calidad: Tiempo de conversin: Se conoce como tiempo de conversin al tiempo que transcurre desde que comienza una conversin hasta que esta naliza y se obtiene el dato correspondiente a la salida. Cuanticacin: Es la divisin del recorrido de la seal en un rango de valores discretos. Este parmetro es importante ya que determina el nivel de detalle.
2.5.3.
Dispositivos de adquisicin de datos integrados
Los dispositivos de adquisicin de datos integrados contienen toda la circuitera necesaria en una carcasa, y se comunican mediante algn tipo de bus con un computador.
34
2.6. ARQUITECTURA DE UN SIMULADOR
Estos dispositivos suelen presentar las siguientes desventajas: Demasiado grandes y costosos. Normalmente utilizan controladores y protocolos propietarios, permitiendo el acceso a la informacin a travs de un interfaz de programacin (API). Tienen un consumo elevado y requieren una fuente de alimentacin externa. La precisin con que se realizan las medidas suele ser excesiva para el propsito de este proyecto.
2.5.4.
Dispositivos de juegos
Los dispositivos de juego como joysticks o gamepads son un buen ejemplo de cmo se traducen las pulsaciones y movimientos del usuario en un ujo de datos comprensible por una aplicacin, por lo que les prestamos especial atencin. Al estar destinados a un pblico general, son dispositivos de sobremesa que proporcionan en la actualidad conectividad y compatibilidad mediante el uso del bus USB o mediante tecnologas inalmbricas como Bluetooth.
2.6.
ARQUITECTURA DE UN SIMULADOR
Un simulador est formado principalmente por tres mdulos interconectados entre s y cada uno con una misin especca como puede verse en la gura 2.11. El Subsistema de simulacin dinmica es el encargado de simular algortmicamente el comportamiento fsico de los elementos que intervienen en la simulacin, incluyendo las leyes de la fsica y cmo estas les afectan. Recibe la entrada del usuario, de esta forma el estado de la simulacin puede verse afectado por la accin del mismo. El Subsistema visual tiene como nica tarea representar la informacin de la simulacin de manera visual, es decir: genera todos los grcos visibles por el usuario. Recibe la informacin del estado actual del subsistema de simulacin dinmica para generar imagenes actualizadas. El Puesto de control permite al operador realizar operaciones como iniciar o parar la simulacin, y otras tareas como la recoleccin de estadsticas sobre la sesin y el progreso del alumno.
35
Figura 2.11: Arquitectura de un sistema de simulacin
36
2.6. ARQUITECTURA DE UN SIMULADOR
CAPTULO 3
METODOLOGA Y MATERIALES
3.1.
METODOLOGA
En la actualidad, el desarrollo de casi todos los proyectos se apoya en una metodologa de trabajo, por lo general depurada desde la experiencia adquirida con anteriores proyectos. La metodologa del diseo siempre suele ser dependiente de la naturaleza del proyecto as como de los requisitos impuestos y las preferencias del personal a cargo de su ejecucin. Esta trata de cuanticar y planicar los aspectos ms fundamentales del proyecto como los recursos necesarios (materiales y de personal), y el coste temporal y econmico derivado del mismo. El desarrollo del presente proyecto se ha dividido en ocho fases que se enumeran a continuacn: Revisin bibliogrca. Para comenzar, se realiza una recopilacin de informacin acerca de las plataformas sobre las que se va a trabajar, as como memorias de trabajos similares a este. Especicacin de requisitos. En esta fase se denirn los requisitos que debe cumplir el producto nal, deniendo parmetros como el rendimiento y consumo elctrico requeridos, o tamao. Tambin se analiza el alcance del proyecto y las distintas alternativas disponibles. Denicin de la arquitectura del sistema. Aqu se realizar una seleccin de los componentes ms apropiados de forma que se cumplan los requisitos. Tambin se estudiarn alternativas para otros aspectos como la conexin con el computador, la arquitectura del software, o el diseo del sistema HASP. Diseo e implementacin del hardware y software. En este apartado se lleva a cabo, una vez denidas las especicaciones, la arquitectura y los componentes, el desarrollo de los esquemas de la circuitera y la construccin de un prototipo inicial en
38
3.2. PLANIFICACIN DE RECURSOS MATERIALES Y HUMANOS
una placa proto-board, ya que los simuladores de depuracin de los microcontroladores presentan limitaciones que pueden limitar el correcto testeo del dispositivo, como las uctuaciones en las entradas, o la comunicacin USB con el computador. Tambin se desarrolla todo el software que corre tanto en el microcontrolador como en el PC. Pruebas y depuracin. En esta fase se prueba el prototipo inicial para comprobar que cumple las especicaciones y que por lo tanto es seguro pasar a la siguiente fase del diseo sin que ello repercuta en prdidas econmicas. Diseo del prototipo nal. Con la arquitectura hardware y software validada, se procede al diseo de una placa de circuito impreso, o PCB usando un programa de CAD, que genera cheros de fabricacin de PCBs estndar. A continuacin se fabrica una placa de forma manual mediante el insolado, se programa el microcontrolador y se monta junto con el resto de los componentes. Pruebas nales. Una vez fabricado el prototipo se realizan una serie de pruebas para comprobar su correcto funcionamiento antes de pasar a la fase nal. Redaccin. Finalmente se realiza la redaccin de la presente memoria del proyecto que incluye el procedimiento seguido y los resultados obtenidos.
3.2.
PLANIFICACIN DE RECURSOS MATERIALES Y HUMANOS
En esta planicacin se tienen en cuenta los recursos necesarios para el desarrollo del proyecto y la fabricacin del prototipo. Los costes asociados se mostrarn en el captulo Presupuesto.
3.3. 3.3.1.
MATERIAL Software
Durante el desarrollo de este proyecto se han utilizado Microchip MPLAB, CCS PICC PCWH, Microchip C18, Microchip MPASM, USB-IF Descriptor Tool, Eagle, Microsoft Windows DDK, Visual C++ Express y el sistema operativo Windows XP x64 Edition, que se pasan a describir a continuacin:
Microchip MPLAB
Se trata del entorno de desarrollo integrado de Microchip para toda su familia de microcontroladores. Integra un conjunto de herramientas para el trabajo con estos dispositivos, entre las ms destacadas: Editor de texto. Permite la edicin del cdigo fuente y colorea la sintaxis.
CAPTULO 3. METODOLOGA Y MATERIALES
39
Simulador. Visualiza en pantalla el estado de la mquina: registros, memoria (RAM / ROM / EEPROM / ...), perifricos... Tambin muestra la direccin de la instruccin en ejecucin y su traduccin en lenguaje de alto nivel asociada. Permite generar estmulos en sus pines de entrada y visualiza las salidas. Programador. Con la ayuda de un dispositivo programador compatible, carga el rmware compilado en la memoria ROM del microcontrolador y verica los datos escritos. Tambin escribe la palabra de conguracin, establece algunas informaciones del usuario y permite borrar el chip. Depurador ICD. Mediante un dispositivo depurador compatible, carga en el microcontrolador un subprograma que se comunica con el PC para monitorizar en el propio chip el estado de la ejecucin. Congurador de dispositivo. Posibilita la edicin de la conguracin del dispositivo y la visualiza en una forma legible por humanos. Integrado con compiladores como C18, CCS PICC, o HI-TECH, y con ensambladores como MPASM.
Microchip MPASM
Ensamblador para la familia de microcontroladores PIC, se suministra con archivos de cabecera que denen constantes simblicas que contienen deniciones especcas para cada tipo de microcontrolador. Est integrado en MPLAB y es gratuito.
Microchip C18
C18 es el compilador de lenguaje C de Microchip para la familia de microcontroladores PIC18. El lenguaje compilado sigue la especicacin C, pero no cumple el estndar ANSI/ISO debido a algunas restricciones dependientes de la plataforma, y a la inclusin de algunas palabras clave cualicadoras, como la palabra rom, que colocada delante del tipo de dato en una declaracin de variable especica que se trata de una constante almacenada en memoria ROM. Incluye multitud de libreras para el manejo de alto nivel de los recursos del chip, y proporciona construcciones del lenguaje orientadas a tareas especcas de bajo nivel como la atencin de interrupciones o la inclusin de fragmentos escritos en cdigo ensamblador. Se integra completamente con con el entorno de desarrollo integrado MPLAB y cuenta con una versin de estudiante gratuita con la nica limitacin de dejar de hacer optimizaciones sobre el cdigo generado tras un periodo de tiempo desde su instalacin.
CCS PICC PCWH

El compilador CCS PICC es una potente herramienta para el desarrollo de rmware escrito en C para microcontroladores PIC.
40
3.3. MATERIAL
Como ventajas frente al compilador C18 de Microchip, la edicin PCWH de PICC soporta las familias de microcontroladores PIC10, PIC12, PIC16,y PIC18. Y la edicin completa (PCWHD) soporta adems de los anteriores, la familia de microcontroladores de 16 bits PIC24, y la familia con DSP integrado dsPIC. PICC genera cdigo ms pequeo que C18 puesto que tiene 307 funciones preprogramadas en patrones de cdigo parametrizables y accesibles al usuario como llamadas a funciones C, en lugar de estar programadas en cdigo C en libreras separadas que han de ser tambin compiladas. Es posible localizar variables y fragmentos de cdigo en posiciones especcas de memoria, entre las herramientas de depuracin incluye una variante de la llamadas a la funcin printf y scanf de la librera estandar de C para la depuracin por el puerto RS-232. Otra de sus principales caractersticas es que mediante la denicin de la frecuencia del oscilador, y de la conguracin, PICC parametriza automticamente todas las caractersticas directamente dependientes de la velocidad de reloj como el uso del puerto RS-232, o las funciones de espera activa. Incluye muchos programas de ejemplo multiplataforma que tomar como referencia para diseos nuevos. Es facilmente integrable en el entorno MPLAB, y funciona bajo Windows 95, 98, ME, NT4, 2000, XP, Vista, 7, y Linux.
USB-IF descriptor tool

Se trata de una herramienta diseada por el USB Implementers Forum, de uso gratuito y disponible para su descarga en su pgina web que asiste al diseo de descriptores para dispositivos USB de tipo HID1 . Presenta un editor de descriptores que muestra al usuario una lista de todas las posibles opciones en cada momento. Una vez completo permite la validacin del mismo simulando el comportamiento de la parte software del sistema operativo encargada de ello. Finalmente convierte el descriptor en lenguaje simblico a cdigo binario y puede exportarlo en varios formatos, principalmente un formato interno para poder cargarlo en la misma herramienta y proseguir el trabajo ms adelante, o como archivo de cabecera de C .h, donde dene un vector de elementos de 8 bits inicializado a sus correspondientes valores.
Eagle
Eagle es un popular paquete de CAD para el diseo de PCBs. Se compone de tres programas: El Schematic Editor que sirve para disear el esquemtico terico del circuito y validarlo en base a unas reglas de conectividad elctrica. El Layout Editor genera el fotolito de la placa partiendo del esquema terico y permite su edicin. El Autorouter utiliza algoritmos de rutado para dibujar las pistas que conectan los componentes de la
1
Human Interface Device, o Dispositivo de Interfaz humana que ser explicado en posteriores secciones.
41
placa, soporta hasta 16 capas de seales y da al usuario a elegir ciertos parmetros basados en costes que inuyen en la estrategia de rutado. Finalmente, el CAM Processor genera los archivos para su fabricacin, ya sea obteniendo un fotolito para insolado, o mediante cheros Gerber estndares para la fabricacin en instalaciones equipadas con maquinaria de control numrico.
Microsoft Windows Server 2003 SP1 DDK

Microsoft Windows Driver Development Kit es un conjunto de herramientas para el desarrollo de drivers bajo los sistemas operativos Windows. Se compone de libreras, documentacin, ejemplos y herramientas para la compilacin y prueba de drivers especcos para que un dispositivo hardware en desarrollo funcione bajo Windows Server 2003, Windows XP y Windows 2000 tanto en sus ediciones de 32 bits como de 64 bits. Est bien soportado y hay una comunidad de desarrolladores on-line a la que se puede acudir en busca de ayuda.
Visual C++ Express

Forma parte del entorno de desarrollo Visual Studio 2005 de Microsoft. Compila programas escritos en lenguaje ISO C++ a cdigo mquina para producir archivos ejecutables, o a cdigo CLR2 , realizando optimizaciones para incrementar la velocidad de ejecucin debido a que hace uso de las instrucciones SIMD del procesador como las SSE2. Cuenta con gran nmero de libreras como las MFC que simplica el desarrollo de aplicaciones con interfaz de usuario. La versin express es de uso gratuito, pero carece de algunas herramientas como el generador de instaladores que empaqueta las aplicaciones desarrolladas para su distribucin.
Windows XP x64 edition

La edicin de 64 bits del popular sistema operativo de Microsoft explota las capacidades de las CPUs modernas que cuentan con esta arquitectura (AMD64, EM64T), mientras permite la ejecucin de programas escritos para las ediciones de 32 bits mediante el subsistema WoW64 (Windows on Windows) que emula el entorno de ejecucin de un sistema de 32 bits utilizando unas libreras de traduccin que convierten las llamadas a funciones del sistema operativo. Sin embargo, requiere drivers diseados especcamente para esta arquitectura.
3.3.2.
Hardware
El hardware utilizado para la realizacin del proyecto es el siguiente:

Common Language Runtime es un cdigo desarrollado por Microsoft, que es interpretado por la mquina virtual .NET runtime framework
2
42
3.3. MATERIAL
Diseo
PC porttil Athec Sense con procesador Core 2 Duo a 2.4 GHz, y 2 Gb de memoria RAM DDR2 corriendo el sistema operativo Windows XP x64 Edition, unidad lectora/regrabadora de DVD y 3 puertos USB 2.0.
Fabricacin y montaje
Programador/Depurador Microchip ICD2 para la programacin del microcontrolador. Se emplear un soldador de 40W para el montaje de las placas, un multmetro digital con display LCD para su comprobacin, y una placa proto-board para realizar el primer montaje.
3.3.3.
Planicacin y recursos humanos
En cuanto a la distribucin de recursos humanos, todas las tareas han sido realizadas por el proyectista, sin embargo se supone que se dividen las tareas entre un ingeniero al que se le aplica un salario estimado de 11.26 e/hora y un tcnico a quien se le aplica un salario de 8 e/hora. Las tareas del primero son el diseo y programacin, y las del segundo el montaje y fabricacin de placas. En el diagrama de Gantt se puede observar que las tareas de diseo e implementacin de rmware y software se realizan en paralelo puesto que ambos estn ntimamente ligados. Ambas tareas comienzan una vez construido el prototipo en la placa proto-board porque es necesario durante la depuracin.
43
Figura 3.1: Diagrama de Gantt
44
3.3. MATERIAL
CAPTULO 4
DEFINICIN DE REQUISITOS Y ANLISIS DEL SISTEMA
En este captulo se van a denir los requisitos que debe cumplir el producto nal, para poder evaluar las alternativas disponibles y elegir las que ms se acomoden a ellos, en cuanto a hardware (microcontrolador y resto de componentes), como a software (lenguaje y herramientas utilizadas).
4.1.
ESPECIFICACIN DE REQUISITOS
En el primer captulo se hizo una breve explicacin de los requisitos del proyecto. Ahora es el momento de exponerlos todos, deniendolos con ms detalle.
4.1.1.
Requisitos del hardware
El dispositivo estar conectado fsicamente al computador y a los transductores del dispositivo de control real (botonera). El dispositivo ser de fcil conexin y desconexin y ser compatible con la mayor variedad de computadores posible. Debe tener un tamao ptimo para su montaje dentro del espacio libre disponible en una botonera. El mnimo espacio disponible que se ha observado dentro de las botoneras de uso ms comn es de 38 x 58 mm, medida que se tendr en cuenta en el diseo de la PCB No requerir alimentacin externa, y tendr un bajo consumo. Esto ser un factor a tener en cuenta al seleccionar el interfaz de conexin con el computador. Debe permitir obtener el estado de 10 sensores digitales, y de 10 sensores que pueden ser bien digitales o bien analgicos.
46
4.1. ESPECIFICACIN DE REQUISITOS
Tomar muestras sobre el estado de los sensores y comunicar las lecturas de manera adecuada al computador Lo cual implica seleccionar un microcontrolador equipado con conversores A/D y que sea sucientemente rpido para ejecutar estas tareas. No requerir la instalacin de drivers y ser completamente Plug & Play 1 . El dispositivo validar el software de forma segura, robusta, y no penalizar a aquellos usuarios que posean una copia legtima del software Deber comunicarse con el computador y establecer un dilogo contnuo para vericar que el dispositivo es vlido. Tiene que ofrecer dicultades contra la ingeniera inversa de dicha proteccin. El diseo debe ser apto para su fabricacin en serie.
4.1.2.
Requisitos del software
El rmware contenido en el microcontrolador ser actualizable por el usuario nal sin requerir ninguna intervencin tcnica que implique abrir o desmontar el aparato. De esta forma se reserva la posibilidad de realizar un mantenimiento del rmware post-venta, liberando actualizaciones en caso de que se detecte algn error o se mejore alguna caracterstica. La librera del lado del computador se encargar de la monitorizacin contnua del estado de conexin del dispositivo. Ser la responsable de asegurarse de que el dispositivo es autentico mediante el intercambio de mensajes. Noticar al software protegido de eventos producidos en relacin a los apartados anteriores para que ste pueda actuar en consecuencia. Ser transparente para el programador. Ocupar los mnimos recursos tanto espaciales como temporales en el computador como sea posible. Tendr un diseo modular y estar construida sobre un lenguaje de programacin de alto nivel y de uso comn.
Conectar y utilizar. Se llama as a los perifricos que no requieren ninguna conguracin ni reinicio de la mquina para su puesta en funcionamiento
1
CAPTULO 4. DEFINICIN DE REQUISITOS Y ANLISIS DEL SISTEMA
47
4.1.3.
Requisitos comunes
La arquitectura general debe permitir ampliaciones futuras del sistema como la adicin de ms sensores, o la comunicacin inalmbrica con el computador.
El sistema completo correr sobre el sistema operativo Windows (XP, Vista y 7) tanto en sus versiones de 32 como de 64 bits, permitiendo opcionalmente su compatibilidad con otros.
4.2.
ANLISIS DE ALTERNATIVAS
Partiendo de los requisitos descritos anteriormente, en esta seccin se van a exponer distintas alternativas y se tomarn las decisiones de diseo necesarias justicndolas en cada caso.
4.2.1.
Conexin del perifrico con el computador
Este debe ser el primer aspecto a considerar, ya que inuir decisivamente en la eleccin de los componentes. Debido a las limitaciones de tamao mximo del PCB, y de coste es deseable que el microcontrolador sea el nico circuito integrado. Por lo tanto dependiendo del interfaz de comunicacin elegido, habr que seleccionar un microcontrolador que incorpore un transceptor compatible con el estndar, lo cual a su vez inuir en el resto de componentes. De los interfaces expuestos en el captulo 2, que son los ms extendidos en el campo de la informtica, se descartan inmediatamente los interfaces paralelos puesto que no se desean cables complejos, y la aplicacin no requiere gran ancho de banda. Siendo el periodo tpico de muestreo de 10 ms. Otro factor que los descartan es su poca presencia en los equipos informticos de escritorio de hoy en da. En cuanto a los interfaces serie, se descarta trivialmente el RS-232 por la misma razn de haber quedado obsoleto, y porque no proporciona alimentacin. Respecto a los inalmbricos, por el momento quedan tambin descartados ya que requieren bateras, que a su vez requieren circuitos de monitorizacin de carga lo que encarecer el precio unitario, no obstante se podrn implementar en un futuro. Finalmente la decisin se encuentra entre el bus USB y el bus Firewire, por lo que habr que hacer una comparacin tcnica de los factores clave de ambos para poder tomar la decisin. Como se ha expuesto anteriormente, tanto USB como FireWire permiten la conexin de diversos dispositivos al computador, pero la velocidad de FireWire es muy superior a la de USB, ambos proporcionan alimentacin y estn estandarizados y extendidos.
48
4.2. ANLISIS DE ALTERNATIVAS
4.2.2.
Microcontrolador
El microcontrolador, como elemento principal del diseo debe satisfacer la mayor parte de los requisitos denidos al principio del captulo, y atendiendo a los criterios fundamentales de seleccin de un microcontrolador descritos en el captulo 2 y a los requisitos del proyecto, para tomar la decisin se tendrn en cuenta los siguientes parmetros: Velocidad de clculo La CPU debe ejecutar instrucciones a una velocidad suciente como para realizar las operaciones de E/S y los clculos necesarios en un intervalo de tiempo mximo. En la actualidad casi todos los microcontroladores tienen una frecuencia de reloj variable que se puede ajustar segn los requisitos para llegar a un compromiso entre potencia de cmputo y consumo elctrico. Mdulos integrados El proyecto requiere la eleccin de un microcontrolador que tenga incorporados mdulos que le permitan realizar ciertas tareas como conversin Analgico-Digital y comunicacin USB. El uso de un microcontrolador con mdulos incorporados est destinado a reducir el nmero de componentes en placa, y por tanto el coste, el tiempo de desarrollo, el consumo total, y el espacio en placa. Por otra parte, en muchos casos el microcontrolador contiene mdulos que no se utilizan porque no son necesarios, pero que no suponen un gran coste adicional, y debido a sus otras caractersitcas son rmes candidatos a ser seleccionados entre toda la gama del fabricante. Factor de forma y encapsulado Resulta muy importante que el encapsulado del chip sea adecuado para la fabricacin de un prototipo, esto es, que tenga un tamao y una conguracin de pines apta para su soldadura manual en una placa de circuito impreso, o su insercin en una placa proto-board. Los fabricantes suelen ofrecer distintos encapsulados para el mismo dispositivo, con lo que es posible utilizar uno para la fase de construccin del prototipo, y otro diferente para el producto nal. Herramientas de desarrollo y documentacin disponibles El hecho de que se trate de una plataforma popular implica en muchos casos que el fabricante proporciona gran cantidad de documentacin, que existen buenas herramientas de desarrollo, y sobretodo, que hay muchos proyectos ya desarrollados y ejemplos disponibles, lo cual es de gran ayuda. Ademas si se cuenta con experiencia previa en el desarrollo con esa plataforma se reduce considerablemente el tiempo de desarrollo. Pines de E/S
49
El microcontrolador deber contar con sucientes pines de entrada y salida para esta aplicacin, lo que debe evaluarse teniendo en cuenta la arquitectura del sistema que se haya diseado para poder cuanticar esta necesidad. Consumo El consumo debe ser apropiado para que pueda funcionar exclusivamente con la corriente suministrada por el bus USB. Muchos microcontroladores estn preparados para funcionar con poca corriente o con bateras, y disponen de modos especiales de bajo consumo. Memoria Habr que estimar la cantidad de memoria necesaria para acometer las tareas de las que se compone el funcionamiento del sistema (muestreo, algoritmo anticopia, comunicacin USB) para poder determinar la cantidad de memoria tanto voltil como no voltil que se necesita. Arquitectura En muchos casos, los microcontroladores de 8 bits son sucientes, pero hay que evaluar la potencia de clculo necesaria para seleccionar la arquitectura de menor coste que se adapte a los requisitos del proyecto.
4.2.3.
Lenguaje de programacin
Es importante seleccionar los lenguajes de programacin ms adecuados de entre la gran diversidad existente. El lenguaje, unido a las herramientas de desarrollo van a inuir mucho en el tiempo de desarrollo del software.
Lenguaje de programacin para el microcontrolador

De entre los lenguajes ms usados destacan Basic, C y ensamblador. Basic Originalmente fue desarrollado como una herramienta fcil de usar para principiantes, con lo que presenta una sintaxis muy sencilla, y cercana unos pocos aspectos al lenguaje natural o pseudocdigo, por ello es el preferido de acionados que no tienen gran experiencia en programacin. Por esta misma razn se encuentran en la red gran cantidad de recursos relacionados con el lenguaje. C C ha demostrado a lo largo de tres dcadas su exibilidad, puesto que con l se han programado compiladores, juegos, sistemas operativos, drivers y un inmenso etctera. C est razonablemente cerca del lenguaje mquina, permitiendo trabajar con punteros y direcciones de memoria mientras mantiene su caracterstica de lenguaje de alto nivel.
50
4.2. ANLISIS DE ALTERNATIVAS
Ensamblador Es el lenguaje de ms bajo nivel, y por tanto ms cercano a la mquina, esto lo hace totalmente dependiente de la misma. Ofrece la posibilidad de escribir cdigo muy eciente, para lo cual hay que conocer muy bien la mquina en la que se ejecuta. Sin embargo es muy poco portable y difcil de mantener. Su uso est extendido en el mbito de los microcontroladores bien porque el fabricante no proporcione herramientas de ms alto nivel, o bien porque se pretenda optimizar el rendimiento y el consumo.
Lenguaje de programacin para el PC

De entre los lenguajes ms utilizados actualmente para la programacin bajo Windows se pueden citar: Java Java es un lenguaje de programacin orientada a objetos muy popular. Se trata de un lenguaje interpretado que requiere de la mquina virtual de Java. Se utiliza en multitud de aplicaciones desde juegos hasta aplicaciones web empresariales. Es muy escalable, y utiliza una sintaxis similar en varios aspectos a la de C++. Su rendimiento est ligado a la eciencia del compilador y de la mquina virtual que lo ejecuta. Sus limitaciones en cuanto acceso a bajo nivel al sistema tambin las determina la mquina virtual. Sin embargo se pueden crear bindings para exponer funciones nativas de la plataforma de forma que queden accesibles desde la mquina virtual. Visual C++ Se trata de un entorno de desarrollo integrado para lenguajes C y C++. Se usa especcamente para el desarrollo y depuracin de aplicaciones escritas para las APIs de Microsoft Windows, DirectX y .NET. Utiliza las Microsoft Foundation Classes de forma extensiva para el desarrollar aplicaciones basadas en entorno grco. El entorno de desarrollo cuenta con herramientas como IntelliSense, que muestra de manera visual las construcciones del lenguaje, depuracin remota, editar y continuar o resaltado de la sintaxis. Cuando se compila para .NET se pueden introducir algunos elementos ajenos a C++ para hacer uso extensivo de sus caractersticas como el recolector de basura. Visual Basic Es un lenguaje de programacin basado en objetos (no orientado a objetos) propietario de Microsoft, cuya primera versin se present en 1991. Se trata de un dialecto del lenguaje BASIC con extras aadidos. Al igual que Java es un lenguaje interpretado que requiere de una DLL que contiene la mquina virtual para su ejecucin. Sin embargo ofrece la posibilidad de compilar directamente a cdigo nativo. Existen muchas bibliotecas que facilitan el acceso a muchas funciones del sistema operativo y a la integracin con otras aplicaciones. Debido a su similitud con el lenguaje BASIC posee una curva de apredizaje muy rpida. Sin embargo, presenta inconvenientes como que al ser propietario complica
51
su portabilidad, no permite secciones de cdigo escrito en ensamblador, permite el uso de variables sin declarar, no incluye operadores de desplazamiento de bits, y no tiene instrucciones de preprocesamiento por citar los principales. Visual C# Se trata de un lenguaje de programacin desarrollado y estandarizado por Microsoft, cuya sintaxis bsica deriva del C/C++, y forma parte de la plataforma .NET. El lenguaje est normalizado por la ECMA2 desde diciembre de 2001. C# soporta todas las caractersticas propias del paradigma de programacin orientada a objetos: encapsulacin, herencia y polimorsmo. Otra de sus principales caractersticas es la gestin automtica de memoria, dado que al formar parte de la plataforma .NET tiene a su disposicin el recolector de basura de este, y la posibilidad de acceder a cdigo nativo escrito de forma no orientada a objetos.
4.3.
SELECCIN DE ALTERNATIVAS
Una vez mostradas las alternativas disponibles para el desarrollo de este proyecto se pasa a la toma de decisiones sobre la ms apropiada en cada caso. Es necesario denir en primer lugar el estndar de comunicacin utilizado para la conexin de el dispositivo desarrollado con el computador, para lo cual debe tomarse una decisin entre utilizar Firewire, o USB. Precisamente debido a la mayor velocidad de FireWire (de 200 a 800 Mbps) respecto a USB es ms caro de implementar y por ello su uso est restringido a aplicaciones que demandan esos anchos de banda como la edicin digital de audio y vdeo o el almacenamiento masivo, sin embargo USB ofrece en su versin ms lenta una velocidad ms que suciente para la aplicacin desarrollada (1.5 Mbps), y un coste mucho menor, adems de que hay una gran oferta de microcontroladores con transceptor USB incorporado de muy bajo coste. Por otro lado, USB ofrece una losofa de interconexin Plug & Play, de manera que se pueden conectar hasta 127 dispositivos sin necesidad de reiniciar la mquina, y en muchos casos, instalar drivers. Muchos dispositivos que no son computadores de propsito general incluyen puertos USB, como consolas de videojuegos, autorradios, etc. Y ofrecen compatibilidad plug & play con ciertas clases de perifricos USB: (unidades de almacenamiento, joysticks y otros dispositivos de entrada . . . ). Hace un uso del ancho de banda ptimo ya que dispone de varios tipos de transferencias, y tambin optimiza el consumo elctrico, pudiendo poner en modo de bajo consumo a un dispositivo USB que no se est utilizando. Finalmente, aunque USB presente una complejidad aadida al uso de otros interfaces ms simples como el RS-232, existe una gran cantidad de herramientas que facilitan el desarrollo de perifricos que utilizan este estndar, y tanto su especicacin como otra documentacin est disponible en la red de manera gratuita, lo que facilita en gran medida el diseo.
2
European Computer Manufacturers Association
52
4.3. SELECCIN DE ALTERNATIVAS
Todo ello hace que USB sea la opcin elegida. En cuanto a la seleccin del microcontrolador, se opta por un modelo de la amplia gama de microcontroladores del fabricante Microchip. Las razones fundamentales para elegir a este fabricante son la experiencia previa con productos del mismo, que tiene en catlogo una gran variedad de modelos, divididos en tres gamas, que se adaptan a gran nmero de aplicaciones, y que ya se cuenta con experiencia previa en el uso de estos microcontroladores. Todos estn construidos en torno a una arquitectura comn, lo que permite que una vez se ha desarrollado para una, migrar a otra sea extremadamente fcil. Una vez decidido el fabricante, se debe buscar un microcontrolador que cumpla las siguientes caractersticas: Su arquitectura debe ser de 8 bits puesto que no se requiere gran potencia de clculo y ya se cuenta con experiencia previa en esta familia. Debe disponer de un mdulo USB que requiera poca o ninguna circuitera externa adicional. Su memoria de programa debe ser reprogramable, y adems tiene que poder ser reprogramada por rmware sin necesidad de un programador externo para permitir su actualizacin mediante USB. Tiene que estar disponible en encapsulado SPDIP3 (g. 4.1), puesto que es el ms adecuado para la fabricacin de prototipos. Debe disponer de conversores A/D para muestrear los transductores analgicos (potencimetros). Debe disponer de puertos de entrada digitales para muestrear los transductores digitales. No debe consumir ms de 100 mA Debe tener disponibilidad suciente para la adquisicin de lotes de cientos de unidades, y mantener su disponibilidad durante el tiempo suciente para que no sea necesario migrar a otro debido al cese de su fabricacin con el tiempo. Tras realizar varias bsquedas paramtricas en el catlogo on-line de Microchip, se ha seleccionado el modelo PIC18F2550. En el momento de la redaccin de esta memoria, el fabricante dispone 250 microcontroladores de 8 bits, teniendo 49 de ellos transceptor USB 2.0 integrado. Se proporciona tambin de manera gratuita el entorno de desarrollo MPLAB IDE, de gran cantidad de documentacin y de soporte tcnico 24/7.
3
Skinny Plastic Dual In-Line, es un tipo de encapsulado para su montaje a travs de agujeros
53
Figura 4.1: El encapsulado SPDIP Este modelo es un microcontrolador de 8 bits con 32 Kbytes de memoria ROM de tipo Flash, y 2 Kbytes de memoria de tipo SRAM. La CPU soporta frecuencias de reloj de hasta 48 MHz, ofreciendo una velocidad de 12 MIPS. Incluye una memoria EEPROM de 256 bits accesible por rmware para el almacenamiento no voltil de parmetros necesarios en tiempo de ejecucin. Dispone tambin de un conversor A/D de 10 bits conectado a un multiplexor analgico de 10 canales. lo que satisface los requisitos. Tiene tambin incorporado un transceptor USB 2.0 de velocidad completa (hasta 12 Mbps), que soporta todos los tipos de transfrencias, adems cuenta con sucientes pines de entrada/salida digitales, y con resistencias de pull-up internas cuya utilidad se comprobar ms adelante. El etiquetado de esta familia de microcontroladores se compone de la familia, seguida del voltaje de operacin, el tipo de memoria, y nalmente el modelo concreto. De esta manera, el PIC18F2550 es de la familia PIC18, funciona a 5 V (puesto que no incorpora una L, que signicara Low Voltaje (3.3 V)), utiliza memoria Flash (denotado por la F, y el modelo es el 2550. Las memoria ash es ms rpida que la EEPROM y tiene un tiempo de vida mximo de 10.000 a 100.000 ciclos de borrado-reprogramacin segn el tipo de memoria. La memoria Flash debe ser borrada antes de ser reprogramada, y se borra a nivel de bloques. En lo referente al lenguaje de programacin, para el microcontrolador se ha seleccionado C, puesto que es eciente, se cuenta con buenos conocimientos sobre su sintaxis, permite el acceso a bajo nivel a la mquina, y secciones escritas en cdigo ensamblador. En denitiva permite un mayor control de todos los aspectos del funcionamiento del microcontrolador. Adems para la plataforma PIC18 existe gran cantidad de software y libreras disponible on-line. En cuanto al lenguaje de programacin para el PC, descartamos Java porque uno de los objetivos es que sea lo ms eciente posible, y ocupe los mnimos recursos del mismo de manera que no ralentice el funcionamiento del simulador o de la aplicacin que usa el dispositivo, por otra parte Java no permite el acceso directo a USB, siendo necesaria una librera nativa de bindings. El resto de opciones podran ser vlidas, pero se opta por C++ por permitir un acceso directo a la API de USB proporcionada por el sistema operativo, orientado a objetos,
54
4.3. SELECCIN DE ALTERNATIVAS
eciente, y uno de los lenguajes de uso comn ms extendidos, redundando en una mayor facilidad para la ampliacin y mantenimiento del cdigo. Para la programacin del microcontrolador se utiliza el compilador CCS por generar un cdigo ms pequeo que C18, y permitir el diseo ms rpido del rmware. Pero tambin se utilizar el compilador C18 y el ensamblador MPASM como se explicar ms adelante. El tipo de dispositivo ser USB 2.0 de velocidad completa (12 Mbps). Esta conguracin permitir aadir ms funciones en el futuro que requieran ms ancho de banda.
CAPTULO 5
DISEO E IMPLEMENTACIN DEL HARDWARE
En este punto ya se tiene suciente informacin para abordar el diseo del perifrico. En primer lugar se va a disear el esquema de la circuitera del perifrico, que desglosaremos en: conectores, asignacin de pines, alimentacin, oscilador, comunicacin USB, y conexin de sensores.
5.1.
DIAGRAMA DE BLOQUES
De acuerdo con las especicaciones y los componentes seleccionados, se elabora el diagrama de boques representado en la gura 5.1.
Figura 5.1: Diagrama de bloques del sistema Como se puede apreciar, el nico componente del sistema es el microcontrolador PIC18F2550, que satisface todas las exigencias del proyecto. Al disponer de un conversor A/D de 10 canales integrado, permite la conexin de las lneas que transportan las seales a medir (debidamente acondicionadas) directamente a los pines del integrado sin requerir un conversor externo. Por otra parte, el transceptor USB integrado es toda la electrnica que necesita para la conexin al bus USB [Tec07].
56
5.2. CONECTORES
Sin embargo como veremos en las siguientes secciones, sern necesarios unos pocos componentes discretos externos como condensadores y resistencias, y un cristal de cuarzo.
5.2.
CONECTORES
El primer requisito del hardware es que el dispositivo estar conectado fsicamente al computador y a los transductores de la botonera. Por lo tanto se van a seleccionar los conectores apropiados para este propsito.
5.2.1.
Conexin USB
Existen fundamentalmente cuatro tipos de conectores USB, mostrados en la gura 5.2. La norma USB 1.0 y 2.0 slo dene los conectores tipo A y tipo B (tanto macho como hembra), pero algunos fabricantes han desarrollado conectores ms pequeos, ms aptos para dispositivos porttiles, como el mini y el micro USB, que estan disponibles al pblico. Otros fabricantes utilizan conectores propietarios, que estn basados en otro conector mecnico pero mantienen las seales de USB.
Figura 5.2: Tipos de conectores USB principales, de izquierda a derecha: Micro USB macho, Mini USB tipo B macho, Tipo B macho, Tipo A macho. Para este proyecto se ha determinado que el conector ms adecuado es el tipo B hembra (g. 5.5), por tres razones: tiene gran disponibilidad, el conector no es de montaje supercial lo que facilitar su soldadura manual, y la existencia de cables de conexin tipo A-B macho para su conexin con el computador (vease gura 5.4), ya que tanto los puertos presentes en los computadores como en los concentradores USB son de tipo A hembra.
5.2.2.
Conexin los sensores
En cuanto a la conexin con los sensores, para proporcionar una buena conexin, facilitar el montaje y reducir el coste se opta por conectores de apriete, de paso 2.54 mm que estn disponibles en bloques de tres y diez elementos y tienen un tamao adecuado para
CAPTULO 5. DISEO E IMPLEMENTACIN DEL HARDWARE
57
Pin 1 2 3 4
Color Rojo Blanco Verde Negro
Funcin VCC (4.4 - 5.25 V) D- (Datos) D+ (Datos) GND (Tierra)
Cuadro 5.1: Numeracin y funcin de cada pin [Axe05]
Figura 5.3: Conector USB tipo B macho y hembra.
su montaje en la placa. Los sensores se conectarn empleando cables desde el conector de apriete hasta los pulsadores o potencimetros del dispositivo sensorizado.
5.2.3.
Otros conectores
Finalmente, para permitir la instalacin y retirada del microcontrolador sin usar soldaduras se coloca un zcalo de 28 pines.
Figura 5.4: Extremos del cable de conexin USB de tipo A-B.
Figura 5.5: Conector USB tipo B para montaje en placa.
58
5.3. ASIGNACIN DE PINES
5.3.
ASIGNACIN DE PINES
La asignacin de pines suele ser uno de los primeros pasos al disear un sistema microcontrolado una vez decidido el microcontrolador (en adelante micro) a utilizar.
Figura 5.6: Diagrama de pines del PIC18F2550 en su encapsulado SPDIP Como muestra la gura 5.6, muchos de los pines estn multiplexados de manera que slo pueden ser utilizados para una funcin en un momento determinado. Por tanto es en esta etapa cuando hay que denir cual o cuales de las funciones que ofrece dada pin sern la utilizadas y por tanto qu se debe conectar a cada uno de ellos. Es preciso sealar que la utilizacin de un mdulo interno del micro, como el transceptor USB exige el uso de un conjunto de pines que al estar asignados a ese mdulo, no podrn ser utilizados para ninguna otra de las funciones con las que est multiplexado (a no ser claro, que se deje de utilizar ese mdulo y que la arquitectura lo permita). En las siguientes subsecciones se justicar la asignacin realizada a cada uno de los pines.
5.4.
ALIMENTACIN
Atendiendo a los requisitos, el perifrico no necesitar alimentacin externa, es por ello que hemos escogido una interfaz de conexin que proporciona alimentacin suciente. La alimentacin suministrada por el bus es muy estable, pero contiene ruido de alta frecuencia, por ello se coloca un condensador cermico entre alimentacin y tierra, con una capacidad de 100 nF. Este es un condensador de desacoplo, que cumple una doble funcin: por un lado bloquea las uctuaciones de alta frecuencia de la lnea de alimentacin para mejorar la estabilidad, por otro lado cuando el integrado produce un pico de consumo, el condensador absorbe este pico evitando la cada de tensin en la lnea, su instalacin es frecuente entre los pines de alimentacin de los circuitos integrados.
59
Siguiendo las indicaciones de las hojas de especicaciones para el 18F2550, se implementa el esquema mostrado en la gura 5.7, que incorpora un condensador (200 nF) entre el pin VUSB y tierra. Esto se debe a que el estndar USB dene 3.3 V para las lneas de datos, pero el micro est funcionando a 5 V, que es la tensin que proporcionan las lneas de alimentacin del bus. Por eso existe un regulador de tensin interno que adapta la tensin de 5 V a 3.3 V [Tec07]. El pin VUSB tiene la tensin de salida del regulador, usado para alimentar el transceptor USB interno. Esta tensin puede ser necesaria si se utilizan resistencias de pull-up externas en las lneas de datos, lo cual se explicar en la seccin Comunicacin USB. Si no se necesita, se debe conectar a travs de un condensador a tierra para evitar que ote al dejarlo al aire e introduzca ruido en la circuitera USB interna.
Figura 5.7: Esquema de circuito de alimentacin para un PIC18F2550 alimentado por USB usando su transceptor incorporado. Para nalizar hay que observar que el bus comienza suministrando 100 mA hasta que el host obtiene los descriptores que le informan de la corriente que debe suministrar, y que la corriente tpica mxima del PIC18F2550 es de 5 mA. Por lo tanto el consumo del chip en modo de funcionamiento normal trabajando a una tensin de 5 V es, segn la ley de ohm (ecuacin 5.1), de 25 mW. P =V I Los pines implicados aqu son: VSS (8, 19), VDD (20), VUSB (14). (5.1)
5.5.
OSCILADOR
Como cualquier circuito sncrono, el micro necesita de una fuente de oscilacin que utilizar como seal de reloj. El PIC18F2550 tiene un oscilador interno que puede alimentar la CPU y los mdulos internos, pero debido a los requisitos de frecuencia y estabilidad
60
5.5. OSCILADOR
del mdulo USB se necesita utilizar el oscilador basado en cristal de cuarzo externo que utiliza los pines OSC1 y OSC2 genera una seal de reloj estable, apta para el mdulo USB. El PIC18F4550 puede operar en varios modos de oscilacin, entre los que cabe destacar: XT: Con cristal externo (hasta 4 MHz inclusive) HS: Con cristal externo de alta velocidad (desde 4 hasta 48 MHz) XTPLL: Con cristal externo utilizando el mdulo PLL para multiplicar la frecuencia. HSPLL: dem que el anterior pero con cristal externo de alta velocidad. EC: Con seal de reloj externa alimentada por un pin. INTHS: CPU y perifricos con el oscilador interno pero usando un cristal de alta velocidad para el mdulo USB. Los cristales de cuarzo se basan en las propiedades piezoelctricas de este material para la generacin estable de seales oscilantes, por ello son muy usados como parte de circuitos osciladores. En cuanto a la frecuencia, hay que tener en cuenta que el mdulo USB necesita una entrada de 6 MHz para su funcionamiento como dispositivo de baja velocidad, o de 48 MHz para su funcionamiento como dispositivo de velocidad completa. La gura 5.8 muestra la circuitera de seleccin de reloj del micro, de ella se pueden extraer todas las posibles conguraciones para conseguir la frecuencia adecuada en la entrada del mdulo USB (marcada como USB Peripheral). Puesto que se desea congurar un dispositivo de velocidad completa, la frecuencia que se necesita obtener a la entrada del mdulo USB es de 48 MHz, para ello se ha determinado que se puede utilizar un cristal de 4 MHz con la conguracin que sigue el camino maracado en rojo en la gura 5.9 (de izquierda a derecha). El uso de un cristal de esta frecuencia se debe a que se trata de componentes caros, cuyo precio es generalmente directamente proporcional a la frecuencia que desarrollan, siendo 4 MHz la conguracin mnima para el funcionamiento del sistema. Como se puede ver, la seal pasa por un multiplexor que no divide la frecuencia, para entrar despus a un circuito PLL 1 que eleva la frecuencia de 4 MHz a 96 MHz. Finalmente pasa por un divisor de frecuencia que la escala hasta obtener los 48 MHz deseados, que pasan por un multiplexor nal hacia la entrada del mdulo USB. En cuanto a la frecuencia de la CPU, se toma la seal a 96 MHz a la salida del PLL, y se divide independientemente por dos (multiplexor marcado con CPUDIV), esto pasa por
Phase-Locked Loop, o lazo de seguimiento de fase es un sistema realimentado que multiplica la frecuencia de una seal de entrada
1
61
Figura 5.8: Esquema de la circuitera de seleccin de reloj del PIC18F2550 relativa al mdulo USB. otros dos multiplexores y nalmente va a la entrada de reloj de la CPU, que consecuentemente tambin trabajar a 48 MHz, la velocidad mxima que proporciona 12 MIPS. Recordemos que al ser un dispositivo que no funciona con bateras y que se alimenta a travs del puerto USB el consumo no es una prioridad, y esta frecuencia proporciona una buena velocidad de cmputo para implementar las caractersitcas del proyecto, y permitir otras en un futuro. Esta conguracin ser tenida en cuenta en la posterior fase de desarrollo del rmware. En lo respectivo al oscilador de cuarzo, siguiendo las hojas de especicaciones la conexin debe realizarse de la forma indicada en la gura 5.10.
Figura 5.9: Esquema de conexin de un cristal de cuarzo al PIC18F2550.
Figura 5.10: Tabla de capacidades recomendadas por el fabricante para los condensadores C1 y C2.
62
5.6. COMUNICACIN USB
Figura 5.11: Circuito para la deteccin de un dispositivo de alta velocidad. Segn la tabla mostrada en la gura 5.10 los valores recomendados por el fabricante para los condensadores C1 y C2 son 27 pF. Finalmente, el oscilador tendr un encapsulado de tipo HC49 de forma que su montaje sea fcil. Los pines implicados en esta seccin son OSC1 (9) y OSC2 (10).
5.6.
COMUNICACIN USB
Antes de continuar es necesario explicar cmo funciona el proceso de deteccin de un dispositivo al bus. Puesto que los dispositivos utilizan para el intercambio de datos con el host, transferencias de control que en ltima instancia son un tipo de transferencia USB que puede realizarse a tres velocidades distintas, ya desde el principio se debe conocer la velocidad del dispositivo para poder llevar a cabo este proceso correctamente. El host o hub tiene conectadas a sus lneas de datos D+ y D-, sendas resistencias de pull-down de 15 K La norma dice que un dispositivo de velocidad completa debe llevar la lnea D+ a nivel alto mediante la conexin de una resistencia de pull-up de 1.5 K (ver gura 5.11). Mientras que un dispositivo de baja velocidad llevar la lnea D- a nivel alto de la misma manera (ver gura 5.12). En cuanto a los dispositivos USB 2.0 de alta velocidad, se identican como de velocidad completa, y una vez que el host obtiene sus descriptores se cambia la velocidad, y se desconecta la resistencia de pull-up para balancear la lnea. El PIC18F2550 tiene estas resistencias integradas en el chip y son controlables por
63
Figura 5.12: Circuito para la deteccin de un dispositivo de baja velocidad. rmware, lo que junto con el regulador de tensin de 3.3 V, y el transceptor USB integrado reduce la circuitera externa necesaria para la operacin del bus USB a cero, conectndose las lneas de datos D+ y D- provenientes del conector directamente a los pines D+ y Ddel chip. Tambin se permite el uso de un transceptor USB externo, de un regulador de tensin externo o de ambos, pero se ha escogido este micro especialmente por contar con toda esta circuitera integrada. En la gura 5.13 se pueden apreciar las resistencias de pull-up, el transceptor USB y el regulador de tensin.
Figura 5.13: Fragmento del esquema de la circuitera de control del USB relativo a las resistencias de pull-up internas. Los pines involucrados en esta seccin son D+ (16) y D- (15).
64
5.7. CONEXIN DE SENSORES
5.7.
CONEXIN DE SENSORES
Los sensores que se pretenden conectar a este sistema son, como ya se ha explicado pulsadores y potencimetros presentes en varios tipos de dispositivos de control de maquinaria real. Recordemos que el objetivo es muestrear el estado de 10 sensores digitales (pulsadores) y otros 10 que pueden ser digitales o analgicos (potencimetros).
5.7.1.
Sensores digitales
El micro dispone de pines de E/S digital de propsito general que pueden ser utilizados para este cometido, de manera que se conecte un pulsador a cada pin. Los pines se organizan en puertos nombrados con letras de la A a la E, se utiliza la nomeclatura Rxy para referirse al pin no y del puerto x, (por ejemplo RA3 es el pin no 3 del puerto A). En la versin de 28 pines que estamos utilizando no estn disponibles todos los puertos ni todos los pines en cada puerto. Hay que destacar que cada puerto presenta caractersticas especiales como buffers de entrada schmitt-trigger, o drivers CMOS pero todos los que quedan libres tras las asignaciones realizadas anteriormente tienen en comn que aceptan niveles TTL. Cada pin puede congurarse individualmente como de entrada o de salida mediante la escritura de un registro que comunica con un latch, que a su vez controla un buffer triestado, de manera que cuando se congura como entrada el pin est en estado de alta impedancia y cuando se congura como salida est conectado con el bit correspondiente de su registro de control, vase gura 5.14. Uno de los esquemas de conexin ms tpicos para cuando se dispone de una entrada independiente por pulsador, el cual se ha implementado, es el que se muestra en la gura 5.15, en el que se conecta el pin a VDD a travs de una resistencia de pull-up para limitar el consumo. El pin tambin se conecta a tierra a travs del pulsador tal y como se muestra en la gura 5.15, de forma que cuando se pulsa produce una cada de tensin que lleva al pin a nivel bajo. De esta manera (asumimos que usamos pulsadores en cuyo estado de reposo estn abiertos) si no se est pulsando se podr leer un 1 lgico en esa entrada, y si se est pulsando se leer un 0 lgico. El valor de esta resistencia no es crtico, pero hay que asegurarse de que cuando el pulsador est en reposo la corriente que entre por el pin sea superior al umbral inferior del nivel alto TTL, y que cuando se pulsa el nivel de tensin cae por debajo del umbral superior del nivel bajo TTL, evitando los niveles indenidos. Tal y como se muestra en la gura 5.16 los niveles lgicos TTL son de 0 a 0.8 V para el nivel bajo y de 2 V a 5 V para el nivel alto, quedando la franja entre ambas en un nivel indeterminado que hay que evitar. Valores tpicos de estas resistencias estn en torno a los 10 K - 100 K. Afortunadamente, el PIC18F2550 dispone de resistencias de pull-up internas en todos los pines de entrada del puerto B (8 en total) activables por rmware y que reducen la circuitera externa. Gracias a esto no ser necesario colocar una resistencia externa en cada pin de entrada del puerto B (RBx). Los pulsadores son parte de las botoneras de control, por lo tanto no forman parte del
65
Figura 5.14: Esquema simplicado de la circuitera de control de un pin de E/S.
66
Figura 5.15: Esquema de conexin de un pulsador a una entrada digital.
Figura 5.16: Rango de niveles de tensin y su correspondencia con los niveles lgicos en TTL. circuito y se encontrarn fuera de la placa de circuito impreso. Por esta razn hay que poner las resistencias de pull-up en la placa y conectar el punto donde debe ir el pulsador al pin correspondiente del conector de apriete. De esta forma cuando se monte dentro de la botonera, slo habr que conectar un extremo de los pulsadores a tierra, y el otro a los conectores de apriete (g 5.17). Los pines de entrada digitales que quedan libres tras las asignaciones anteriores son los siguientes (ver gura 5.6): RA(0-5), RC(0,1,2,6,7), RB(0-7), RE3, que suman un total de 20. Si se descartan los que estn multiplexados con una entrada analgica puesto que se necesitan todas las entradas analgicas (ANx) existentes quedan un total de 10: RA4, RC(0-2), RC(6-7), RB(5-7) y RE3. Cada uno de estos pines se conectar con su respectivo pulsador mediante una rplica del circuito descrito en la gura 5.17.
67
Figura 5.17: Esquema de conexin de cada entrada digital, X1-1 y X1-2 simbolizan pines del conector de apriete, X2-1 y X2-2 simbolizan los extremos de los cables conectados a estos.
5.7.2.
Sensores analgicos
Como consta en los requisitos, se deben poder muestrear sensores que pueden ser bien analgicos o bien digitales. Los potencimetros son utilizados en dispositivos de interfaz humana porque son una forma econmica de determinar la posicin angular de un til de control tal como una palanca, o un pedal. Los dispositivos de juego como joysticks, joypads o volantes incorporan estos componentes, y tambin los dispositivos de control de maquinaria real, por lo que el sistema deber ser capaz de determinar la posicin de potencimetros conectados a l. Desde el punto de vista electrnico, un potencimetro es una resistencia a la que se le puede variar su valor mediante el giro de un eje o un elemento deslizante. Se componen de un material resistivo como el grato y de un contacto que se desplaza a lo largo de l. Tpicamente tienen tres terminales, entre dos de los cuales se aplica un voltaje constante. El contacto que se desplaza con el eje est conectado al tercer terminal, de forma que su tensin vara, generalmente de forma lineal, con el ngulo de giro. De esta manera midiendo la tensin de este terminal se puede determinar la posicin angular del eje. Para poder medir esta tensin se ha escogido un micro con conversor A/D de 10 bits de precisin. La gura 5.18 muestra cmo la entrada analgica del conversor A/D est conectada a un multiplexor analgico controlable por rmware que permite seleccionar uno de los diez pines (canales) de entrada analgicos ANx. Ntese que los pines marcados con el superndice (1) slo estn disponibles en la versin de 40 pines, y hay que recordar de la gura 5.6 que los pines ANx que pueden funcionar como entradas analgicas estn multiplexados con Rxy, que son pines de E/S digitales. Esto implica que se debe seleccionar una funcionalidad u otra para cada uno de los pines.
68
Figura 5.18: Conexionado interno de los pines de entrada analgicos al conversor A/D del PIC18F2550.
Como se desprende tambin de la gura, el voltaje de referencia tanto positivo como negativo del conversor es seleccionable entre VCC y el pin AN3 o entre tierra y el pin AN2 respectivamente. Para el conexionado de un potencimetro con uno de los canales analgicos del PIC18F2550 se puede usar como voltaje de referencia positivo el suministrado por el bus USB (5 V), y tierra como voltaje de referencia negativo, de esta manera se optimiza el uso de los pines disponibles. En estas condiciones se debe aplicar una diferencia de potencial de 5 V en los pines del potencimetro para escalar la seal de salida del mismo al rango entero del conversor A/D para obtener as la mayor precisin. De esta manera cuando el potencimetro est en su mnima posicin angular la tensin de salida ser cercana a 0 V, y el valor digital capturado por el conversor ser cercano al mnimo: 0000000000. Igualmente, cuando el potencimetro est en su mxima posicin angular, la tensin de salida ser cercana a los 5 V, capturandose un valor cercano a 1111111111. Cualquier posicin intermedia ser linealmente dependiente del ngulo de giro (asumiendo que se utilice un potencimetro lineal). Con todo ello en mente se construye el circuito mostrado en la gura 5.19.
69
Figura 5.19: Esquema de conexin de un potencimetro a un conversor A/D.
Figura 5.20: Esquema de conexin separado.
Al igual que ocurra con los pulsadores, los potencimetros forman parte de las botoneras y se dejan todas las lneas necesarias para el cableado externo de los mismos en los conectores como muestra la gura 5.20. No obstante, puede darse la situacin de que se desee instalar este sistema de adquisicin de datos en una botonera que no disponga de potencimetros, o que disponga de menos de diez, y sin embargo hayan ms de diez pulsadores que sensorizar. Para estos casos se podr conectar un pulsador a una de las entradas analgicas, para lo cual como ya se explic anteriormente se requiere una resistencia de pull-up por cada uno. Es por ello que las entradas analgicas tendrn una resistencia de pull-up desconectable mediante un jumper, quedando el circuito nal como indica la gura 5.21. En este caso, cuando se sustituya el potencimetro por un pulsador el conversor capturar un nivel de tensin cercano a 5 V con el pulsador en posicin de reposo, y cercano a 0 V cuando est pulsado. En suma, cada uno de los diez canales analgicos tendr una seal digital virtual asociada, cuyo valor depender del nivel de tensin capturado en ese canal, esta estrategia ser explicada con ms detalle en las siguientes secciones. Los pines afectados en esta seccin son los restantes: AN(0-4) y AN(8-12), un total de 10. Cada uno de ellos se conectar con su correspondiente pulsador o potencimetro mediante una rplica del circuito descrito en la gura 5.21.
5.8.
RESUMEN
En resumen, la asignacin nal de pines del micro queda como sigue:
70
5.9. DISEO DEL ESQUEMTICO
Figura 5.21: Esquema de conexin nal.
Pin 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Id RE3 AN0 AN1 AN2 AN3 RA4 AN4 VSS OSC1 OSC2 RC0 RC1 RC2 VUSB
Funcin Entrada digital 0 Entrada analgica 0 Entrada analgica 1 Entrada analgica 2 Entrada analgica 3 Entrada digital 1 Entrada analgica 4 Tierra Cristal de cuarzo Cristal de cuarzo Entrada digital 2 Entrada digital 3 Entrada digital 4 Regulador USB (a tierra)
Pin 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Id DD+ RC6 RC7 VSS VDD AN12 AN10 AN8 AN9 AN11 RB5 RB6 RB7
Funcin Datos USB Datos USB Entrada digital 5 Entrada digital 6 Tierra Alimentacin Entrada analgica 9 Entrada analgica 7 Entrada analgica 5 Entrada analgica 6 Entrada analgica 8 Entrada digital 7 Entrada digital 8 Entrada digital 9
5.9.
DISEO DEL ESQUEMTICO
Con todo lo descrito anteriormente y la ayuda del paquete de software Eagle se crea una versin inical del esquemtico para poder proceder a su montaje en una placa de pruebas.
71
Figura 5.22: Esquema de conexionado interno tpico de una placa de prototipos ProtoBoard
5.10.
IMPLEMENTACIN DEL HARDWARE
Como se coment en el captulo de Metodologa y materiales en primer lugar se utilizar una placa de prototipos proto-board para comprobar que todo el sistema funciona correctamente. Las placas proto-board son placas de reutilizables usadas para construir prototipos de circuitos impresos sin necesidad de soldaduras. Se componen de un panel de plstico con una rejilla donde se insertan los componentes. Presentan un esquema de conexionado interno horizontal y vertical como se muestra en la gura 5.22. Para el conexionado entre pistas se emplea hilo telefnico que permite una insercin limpia. Se utiliza un conector USB tipo B hembra y se sueldan hilos telefnicos a sus cuatro pines, que son insertados en la placa. Para probar la sensoriazcin digital se inserta un pulsador para montaje en placa y se cablea con el microcontrolador. En cuanto a la analgica se hace lo mismo con un potencimetro. Una vez montado el esquema se realizan comprobaciones elctricas sobre la placa. Finalmente se carga en el micro un rmware de demostracin suministrado con el compilador CCS y se conecta por USB a un PC para comprobar que la comunicacin es correcta. Tras haber vericado el diseo en la placa de pruebas se procede a la fabricacin de una placa prototipo. Partiendo del esquema inicial se realizan modicaciones, poniendo especial nfasis en optimizar el tamao de la placa para cumplir los requisitos. El diseo mostrado en el apndice (g. A.1) es el fruto renado de la experimentacin con la placa de prototipos, en la que se ha observado que se puede optimizar el tamao de la placa si se colocan conectores de apriete a ambos lados y cada uno conecta las seales presentes a ese lado del chip. Otra de las optimizaciones ha consistido en utilizar redes de resistencias para la implementacin de los pull-up puesto que son componentes relativamente compactos. Los conectores y redes de resistencias que guran en el esquemtico se han seleccionado teniendo en cuenta su disponibilidad por parte del fabricante, esto justica el uso de redes de 9 resistencias y de bloques de conectores de 10 y 3 unidades.
72
5.10. IMPLEMENTACIN DEL HARDWARE
Con el esquema terminado se procede al diseo de la PCB. Las dimensiones son 58 x 38 mm, se emplean dos caras (mximo permitido por la versin de estudiante de Eagle) con un grosor de pista de 0.6 mm y 0.3 mm. Debido al proceso de fabricacin, un grosor menor podra dar lugar a pistas cortadas. Con el Layout Editor se colocan los componentes y se rutan las pistas de forma manual. Durante el diseo de la PCB se presta especial atencin a cumplir los siguientes objetivos: Las pistas deben tener la menor longitud posible, especialmente las del oscilador y las de datos USB. Prescindir de vas en la medida de lo posible. Facilitar la soldadura manual de los componentes. Colocar los conectores en los bordes de la placa. Colocar un agujero en cada esquina para la sujecin de la placa mediante tornillos. Como resultado de este trabajo, se decide que las redes de resistencias se coloquen debajo del microcontrolador, elevando ste mediante el uso de dos tiras de pines y un zcalo de 28 pines. Puesto que la conguracin analgico o digital de cada uno de los sensores de tipo AD ser jada en fbrica no se instalan jumpers, sino que se puentean o no empleando los pines sobrantes de los otros componentes. El software genera el fotolito de la cara Top (superior), Bottom (inferior), y Componentes (que contiene la serigrafa de los mismos, pero que no se va a utilizar inicialmente) (guras A.2, A.3, y A.4), as como los cheros Gerber que contienen la informacin necesaria para su fabricacin industrial. La placa de prototipo se fabrica de forma manual empleando una placa fotosensible y siguiendo el siguiente procedimiento: 1. Se imprimen los fotolitos en lminas de acetato con una impresora de inyeccin de tinta especial. 2. Se grapan las dos caras teniendo cuidado con que coincidan perfectamente los agujeros de ambas. 3. En una habitacin con baja iluminacin se separa el adhesivo protector de la placa fotosensible y se coloca entre los acetatos. 4. Se exponen ambas caras por un periodo aproximado de 5 minutos a la luz de una insoladora.
73
5. Se sumerge la placa en una solucin de sosa custica que elimina los restos de capa fotosensible en las zonas donde ha incidido la luz. 6. A continuacin se elimina el material conductor de las zonas en las que no ha incidido la luz mediante un proceso llamado atacado que consiste en sumergir la placa en una solucin de agua oxigenada, cido clorhdrico, agua y perxido de hidrgeno a partes iguales. 7. Para terminar el proceso de insolado se frota con algodn y acetona para eliminar los restos de la capa protectora que quedan sobre las pistas. 8. Finalmente se procede al mecanizado de la placa mediante una sierra y un taladro para realizar los oricios por los que pasarn los pines de los componentes, y los de sujecin de la placa. Una vez se ha terminado la fabricacin se procede al montaje de los componentes. Para ello se aplica ux de soldadura sobre los pines y se calientan aportando estao para su jacin. Hay que prestar especial atencin a los pines que actuan como vas, puesto que han de ser soldados por ambas caras. Finalmente se realizan las comprobaciones elctricas correspondientes mediante un polmetro.
74
5.10. IMPLEMENTACIN DEL HARDWARE
CAPTULO 6
DISEO E IMPLEMENTACIN DEL SOFTWARE
En este captulo se desarrollarn los aspectos relativos al diseo e implementacin de las partes software del proyecto.
6.1.
INTRODUCCIN
Antes de entrar en el desarrollo propiamente dicho, es necesario explicar algunos de los fundamentos en los que se basa USB, ya que es necesario conocer ciertos detalles sobre la comunicacin y el proceso de enumerado. Posteriormente se describir el algoritmo utilizado para el sistema HASP, y despus se pasarn a explicar los detalles de la implementacin del rmware desarrollado para el microcontrolador, y software desarrollado para el PC.
6.1.1.
Endpoints y pipes
El ujo de datos que se produce entre el host y un dispositivo USB se organiza de forma lgica en pipes o tuberas. Una tubera es un canal lgico de datos entre ambos. Estas se conectan entre un endpoint o punto nal del dispositivo y la capa de software que controla el hardware USB en el host. Los endpoints vienen congurados de fbrica, estn numerados de forma nica por cada dispositivo y se agrupan en conjuntos que se llaman interfaces, de manera que el control de un perifrico USB puede llevarse a cabo mediante la comunicacin a travs de varios endpoints.
76
6.1. INTRODUCCIN
Figura 6.1: Tuberas lgicas Fsicamente, el host se comunica con los dispositivos cada 1 ms en USB 1.x y cada 125 s en USB 2.0 (tiempo de trama USB) a travs del par de seales diferenciales D+/D- que pasan por el cable. A nivel lgico el software USB congura y administra los dispositivos mediante la tubera por defecto de control. Esta tubera utiliza el endpoint 0, que debe estar soportado por todos los dispositivos USB para su funcionamiento. Durante el proceso de enumeracin que tiene lugar inmediatamente despus de conectar el perifrico, el host obtiene a travs de la tubera por defecto de control la informacin del dispositivo y el resto de puntos nales disponibles en l. Finalmente le asigna una direccin nica en el bus. En el nivel ms alto, el software o driver que hace uso del dispositivo USB se comunica con l a travs de las tuberas conectadas a puntos nales. Como ejemplo se puede denir un dispositivo de almacenamiento en el que se dedique un endpoint para el envo de comandos de lectura y escritura, y otro para la transferencia de datos.
6.1.2.
Descriptores
Como se coment en el estado del arte, los descriptores contienen toda la informacin que el host necesita para identicar al dispositivo y sus caractersticas, y as ser capaz de buscar y cargar el driver adecuado para su puesta en funcionamiento. Los descriptores se organizan en una jerarqua que contiene los siguientes elementos: Descriptor de dispositivo: Indica la versin de USB con la que es compatible el dispositivo, el cdigo del fabricante (asignado por el USB-IF), y el cdigo del producto. Tambin el nmero de descriptores de conguracin presentes. Descriptor de conguracin: Una conguracin es un modo de operacin del dispositivo (por ejemplo una cmara podra operar como webcam o como cmara de fotos). El host debe seleccionar una conguracin y slo puede haber una activa. Este descriptor especica la potencia requerida, y el nmero de interfaces asociados con esa conguracin. En la prctica son raros los dispositivos que ofrezcan ms de una conguracin.
CAPTULO 6. DISEO E IMPLEMENTACIN DEL SOFTWARE
77
Descriptor de interfaz: Estos descriptores contienen el nmero de puntos nales asociado con el interfaz, y la clase de dispositivo a la que pertenece (almacenamiento masivo, HID, impresin, ...). Descriptor de endpoint: Especica el nmero de endpoint, el tipo de transferencias que se realizarn a travs de l (interrupcin, masiva, iscrona, ...), su longitud y su direccin desde el punto de vista del host: (IN=Del dispositivo al host, OUT=Del host al dispositivo). El punto nal 0 es necesario y predenido, por tanto no necesita descriptor. Descriptor de cadena: Contiene una cadena de texto que puede ser referenciada por los descriptores anteriores, ejemplos comunes de cadenas son el nombre del fabricante o el nmero de serie.
Figura 6.2: Jerarqua de descriptores USB.
6.1.3.
La clase HID
La norma USB dene ms de diez clases de dispositivos. Estas clases agrupan un conjunto de caractersticas que son comunes a cierto tipo de dispositivos USB y tienen requisitos de transporte de datos similares. Cuando un dispositivo pertenece a una de estas clases no necesita drivers especcos puesto que sus capacidades y caractersticas estn denidas en un descriptor de clase. El sistema operativo puede utilizar drivers genricos para una clase, lo que libera al fabricante de la obligacin de crear y mantener drivers especcos para diversas plataformas. Las clases de dispositivo se especializan en subclases que indican un tipo de dispositivo ms concreto. En el descriptor de interfaz o de dispositivo gura el cdigo de la clase a la que pertenece el dispositivo. Hay ms de 10 clases denidas en el estndar, siendo las pricipales: Audio Comunicaciones
78
6.1. INTRODUCCIN
HID Impresora Almacenamiento masivo Concentrador Denido por el fabricante La clase HID engloba fundamentalmente, a dispositivos que son utilizados por humanos para controlar el funcionamiento de computadores. Ejemplos tpicos de dispositivos de la clase HID incluyen teclados, ratones y controles de juegos, pero tambin dispositivos que no requieren de interaccin humana pero que proporcionan los datos de forma similar a dispositivos HID, como lectores de cdigos de barras [UI01]. Esto lo hace ideal para satisfacer los requisitos del proyecto por lo que ser la clase de dispositivo usada. Los report descriptors (descriptores de informe) son descriptores especcos de la clase HID que describen el protocolo usado y denen elementos que describen la posicin de un botn o estado, esta informacin se usa para: Determinar a dnde enviar la entrada por ejemplo, enviarla a la API de ratn o joystick Permitir al software asignar funcionalidad a la entrada por ejemplo, usar la entrada de un ratn para mover el cursor por la pantalla Cuando se conecta un dispositivo HID, su descriptor de informe se pasa al driver HID, que lo decodica y se especializa para manejar el dispositivo, dirigiendo los ujos de E/S a donde corresponda (API de teclado, ratn, ...). Los componentes principales de un descriptor de clase HID son: Usage: Los usages, o usos son informacin que el fabricante proporciona sobre qu se est midiendo exactamente (el giro de un volante, la presin de un pedal, el eje de un joystick, ...), y por lo tanto qu se debe hacer con los datos. Los usages se organizan en pginas de uso (usage pages) que denen conjuntos globales (controles de simulacin, perifrico de juegos...), y los identicadores de uso (usage IDs) denen controles especcos como freno, gatillo, o botn izquierdo del ratn. Report: Los reports, o informes indican el formato en el que se transmiten los datos (por ejemplo: 3 campos de 8 bits que codican enteros sin signo de 0 a 1023). Collection: Los collection o colecciones identican la relacin entre dos o ms elementos de datos (por ejemplo: x e y son un punto en 2 dimensiones).
79
Figura 6.3: Papel de los descriptores de informe en la jerarqua de descriptores USB.
Una vez denido el descriptor de informe, el dispositivo debe generar contnuamente informes sobre el estado de los sensores en un intervalo de tiempo denido en el descriptor del endpoint (1 ms como mnimo en USB 1.x), y enviarlos mediante una transferencia de interrupcin. Los datos deben ser formateados de manera que coincidan con lo establecido en el descriptor de informe y enviados secuencialmente. El diseo de descriptores de informe puede llegar a ser muy complejo, por ello para ilustrar esta idea se propone el siguiente ejemplo: en la gura 6.4 se muestra el informe de un joystick de dos ejes y tres botones. En el descriptor se ha denido que la posicin de los ejes se representa con 12 bits de precisin, y que los dos bits ms signicativos de la lectura del eje X se encuentran en el bit 1 y 0 del byte 2, el resto en el byte 1. Con el eje Y sucede de manera similar. En cuanto a los pulsadores su estado se codica con tres bits situados a continuacin de la lectura del eje Y (1 signica pulsado, 0 signica no pulsado), y se rellena el ltimo bit del byte 3 con un valor constante por defecto (0). Observese que la representacin de valores numricos se realiza en formato little endian.
80
6.1. INTRODUCCIN
Figura 6.4: Report de ejemplo Un descriptor de informe HID que cumple estas especicaciones sera el siguiente:
USAGE_PAGE (Generic Desktop) USAGE (Joystick) COLLECTION (Application) COLLECTION (Physical) LOGICAL_MINIMUM (0) LOGICAL_MAXIMUM (4096) USAGE (X) USAGE (Y) REPORT_SIZE (12) REPORT_COUNT (2) INPUT (Data,Var,Abs) END_COLLECTION USAGE_PAGE (Button) USAGE_MINIMUM (Button 1) USAGE_MAXIMUM (Button 3) LOGICAL_MINIMUM (0) LOGICAL_MAXIMUM (1) REPORT_SIZE (1) REPORT_COUNT (3) INPUT (Data,Var,Abs) REPORT_COUNT (1) INPUT (Cnst,Var,Abs) END_COLLECTION Pag. de uso: Perif. genrico de escritorio Tipo concreto: Joystick Col.: Application (Datos reconocibles) Col.:Physical (Coordenadas puntuales) Valor mnimo: 0 Valor mximo: 4096 Uso: Eje X Uso: Eje Y Tamao del informe: 12 bits Nmero de informes: 2 Datos hacia el host (variables) Fn de la coleccin Physical Pag. de uso: Botn Elemento mnimo: 1 (1er botn) Elemento mximo: 3 (3er botn) Valor mnimo: 0 Valor mximo: 1 Tamao del informe: 1 bit Nmero de informes: 3 Datos hacia el host (variables) Tamao del informe: 1 bit Datos hacia el host (constantes) Fn de la coleccin Application
El dispositivo del ejemplo deber cada 10 ms (denido en el descriptor de clase HID, que no se muestra) leer el estado de los dos ejes y los tres botones, alinearlos de la forma que aparece en la ilustracin mediante desplazamientos y operaciones lgicas, y enviarlo mediante una transferencia de tipo interrupcin. Del descriptor hay que destacar que el orden de los datos coincide con el orden en que aparecen sus descripciones, y que el uso de la coleccin Application hace que el sistema operativo reconozca los ejes y botones como tales y as se los muestre a las aplicaciones que mediante la API correspondiente solicitan el acceso a joysticks. Para aclarar el concepto de Application se concretar la idea para el sistema operativo Windows XP:
81
Con este descriptor, Windows lo reconoce como un joystick estndar, e incluso aparece listado en la ventana Dispositivos de juego del panel de control, permitiendo incluso su calibrado. Tambin puede ser usado en cualquier juego de PC para Windows sin ninguna modicacin ni drivers o software adicional, solo hay que indicar que se quiere usar ese dispositivo como entrada en el apartado de conguracin del juego. Las libreras de E/S del usuario como plib [JB], o Microsoft DirectInput sern totalmente compatibles con l, lo que pone de maniesto la importancia de disear correctamente el descriptor HID.
6.2.
ALGORITMO HASP
Tal y como se explic en los primeros captulos, el dispositivo debe comportarse como una llave HASP de forma que su conexin fsica con el computador sea un requisito indispensable para el funcionamiento de un determinado software protegido en el PC. El computador mantiene un dilogo contnuo con el dispositivo durante el cual intercambian informacin. Si el dilogo se interrumpiese o los datos intercambiados no fueran los esperados, el software usuario del sistema HASP en el PC es noticado de ello para que acte en consecuencia (por ejemplo mostrando un aviso al usuario, o bloquendose en modo de demostracin con funcionalidad o tiempo de uso reducido). Una posible implementacin, vlida y ligera consiste en la autenticacin por desaforespuesta, representada en la gura 6.5, y cuyo funcionamiento es el siguiente: Tanto el host como el dispositivo HASP pueden ejecutar un algoritmo f que ha sido implementado en ambos. Este algoritmo toma como entrada una cadena de bits, y con la ayuda de una clave secreta que ambos conocen produce una cadena de bits de salida. El dilogo consiste en lo siguiente: 1. El host genera un mensaje aleatorio x. 2. El host enva este mensaje al dispositivo. 3. Tanto el dispositivo como el host calculan la respuesta con la ayuda de la clave compartida c: y = f(x,c) 4. El dispositivo enva su respuesta de vuelta al host. 5. El host compara la respuesta recibida con su propia respuesta. En funcin de la coincidencia o no de ambas determinar que el dispositivo es falso o no. 6. Se repite todo el proceso tras un intervalo de tiempo. La informacin intercambiada no contiene ningn mensaje relevante, residiendo toda la importancia de ste en la respuesta generada, que tratar de asegurar que al otro lado del bus se est ejecutando el mismo algoritmo, con la misma clave. Estos dos factores son fundamentales para el funcionamiento del sistema.
82
6.2. ALGORITMO HASP
Figura 6.5: Intercambio de informacin HASP. Los dispositivos HASP ms modernos utilizan algoritmos de cifrado simtrico complejos como el AES [AKS], un algoritmo de 128 bits extremadamente robusto, pero computacional y espacialmente costoso, especialmente para dispositivos empotrados. Dados los requisitos, con el n de proponer un algoritmo desconocido para un potencial hacker, se ha optado por el diseo de un pequeo algoritmo de validacin por desafo/respuesta basado en CRC, rpido y que requiere de la intervencin de una clave secreta conocida por ambas partes. Esta clave puede actuar como cdigo de licencia del software protegido, de manera que cada producto de software distinto utilice el mismo algoritmo pero con claves diferentes. La cadena generada por el host (cadena de desafo), es una palabra de 72 bits rellenada con datos aleatorios que contiene una subcadena denominada palabra de informacin. Esta subcadena tiene un tamao de 8 bits, y puede comenzar en cualquier posicin (offset) de la cadena de desafo desde la 1 hasta la 16. Como se ha explicado antes, tanto host (computador) como dispositivo disponen de una clave secreta. Esta clave consiste en un vector de 11 palabras de 16 bits. La palabra de informacin contiene dos campos (enteros sin signo): el offset donde comenzar la palabra de informacin en la prxima cadena que enve el host y un ndice. El primer campo ocupa 4 bits, lo que permite un desplazamiento de 16 posiciones y el ndice ocupa 3 bits, lo que le otorga un rango de 0 a 7. Las posiciones que ocupan en la palabra de informacin se muestran en la gura 6.6. Cuando el dispositivo recibe la cadena de desafo, ya conoce del ciclo anterior el offset donde comienza la palabra de informacin de esta cadena recien recibida, la decodica y obtiene el ndice y el siguiente offset. Este ltimo lo guarda para el siguiente ciclo. A continuacin se concatenan las subcadenas que quedan a la izquerda y a la derecha de la cadena de desafo obtenindose una nueva cadena, c de 64 bits. En el siguiente paso se toma el ndice decodicado de la palabra de informacin y se calcula la funcin XOR de cada byte de c con los elementos del vector de clave comenzando desde el ndice.
83
Figura 6.6: Cadena de desafo Finalmente se calcula el CRC acumulando el cdigo CRC calculado en el ciclo anterior y se obtiene la cadena de respuesta de 64 bits. Obsrvese que, la respuesta en cada ciclo depende de datos calculados en el ciclo anterior (offset de la palabra de informacin y CRC), esto hace que para una cadena de desafo concreta no exista una respuesta concreta sino que ha de considerarse todo el dilogo anterior, lo cual supone una dicultad aadida para un usuario malintencionado. Sin embargo, al iniciar el sistema HASP hay que partir de unos datos (CRC y offset) conocidos puesto que no existe ciclo anterior. Para ello se reserva el primer bit de la cadena de desafo, con este bit puesto a 1 el offset se inicializa a 9 y el CRC a 0. Esto puede suponer un punto debil, puesto que un usuario malintencionado podra enviar al dispositivo slo cadenas de desafo con el primer bit a 1 de forma que las cadenas de respuesta no tengan dependencias con las anteriores. Para probar la idea se ha implementado una aplicacin llamada swval que simula el comportamiento de ambas partes y muestra en pantalla la cadena generada, y las cadenas calculadas tanto por el host como por el dispositivo HASP. Su salida por consola se muestra en la gura 6.8. Los clculos se han realizado en aritmtica de 8 bits de forma que portarlo a la arquitectura PIC18 sea inmediato.
6.3. 6.3.1.
FIRMWARE Conguracin del microcontrolador
La arquitectura PIC18 dispone de un conjunto de registros de conguracin que establecen algunos ajustes globales del microcontrolador, los ms relevantes son los siguientes:
84
6.3. FIRMWARE
Figura 6.7: Procedimiento
Figura 6.8: Imagen de la salida por consola de la aplicacin de prueba swval.
85
Fuente de oscilacin Temporizador de arranque Detector de cada de tensin alimentacin Detector de fallo del reloj Uso del regulador de tensin interno para USB Perro guardin Reset al desbordarse la pila Proteccin contra lectura de reas de cdigo. Ocupan desde la direccin (hexadecimal) 300000 hasta la 3FFFFF. Esta conguracin se almacena en memoria ash. La gura 6.1 muestra la lista de registros de conguracin.
Cuadro 6.1: Tabla de registros de conguracin. A continuacin se explica la conguracin aplicada a los registros relevantes.
Oscilador
Durante la etapa de diseo del hardware se decidi que se necesita una fuente de oscilacin de 4 MHz mediante la conexin de un cristal de cuarzo externo como oscilador primario en modo HSPLL (ya que se utiliza el mdulo PLL), y que esto deba generar los 48 MHz necesarios para la operacin del mdulo USB, como aparece en la gura 5.5. La ruta seguida por las seales de reloj hasta llegar a la CPU, el mdulo USB y el resto de mdulos se controla mediante los registros CONFIG1H y CONFIG1L.
86
6.3. FIRMWARE
Cuadro 6.2: Conguracin del registro CONFIG1L.
Cuadro 6.3: Conguracin del registro CONFIG1H.
87
Mdulo USB y otras conguraciones

Para la operacin del mdulo USB utilizando el regulador de tensin interno es necesario activar el bit VREGEN del registro CONFIG2L
Este registro tambin establece la conguracin de otras caractersticas, como el temporizador de arranque, que mantiene al micro en estado de reset durante un periodo para dar tiempo al cristal de cuarzo a que se estabilice, o el detector de caida de tensin en la alimentacin, que reinicia el micro si la tensin alimentacin desciende por debajo de cierto voltaje. Ambas caractersticas estn activadas. Puesto que el pin RE3, que se corresponde con la entrada digital 0 del diseo est multiplexado con MCLR# (una seal de reset externa), hay que indicar en el registro de conguracin CONFIG3H que la funcin de ese pin es la de entrada digital de propsito general RE3. Tambin resulta til congurar que los pines 4 a 0 del puerto B estn congurados como entradas analgicas ya desde el momento del arranque.
88
6.3. FIRMWARE
Proteccin del cdigo

La arquitectura ofrece la posibilidad de proteger diversos segmentos de cdigo contra la lectura mediante un programador. Si se intenta leer un rea protegida la lectura se realiza, pero todos los datos leidos son 0. Aqu resulta de gran importancia proteger todo el cdigo almacenado en la memoria ROM para evitar la fabricacin no autorizada de rplicas, o el desensamblado del mismo.
89
Resumen
Finalmente la conguracin de estos registros queda como indica la tabla 6.8. Registro CONFIG1L CONFIG1H CONFIG2L CONFIG3H CONFIG5L CONFIG5H Valor 0010 0000 0000 1110 0011 1110 0000 0100 0000 0000 0000 0000
Cuadro 6.8: Conguracin del micro. El resto de registros toman sus valores predeterminados. Estos valores se programan en el momento de cargar el rmware en la memoria Flash del micro. El compilador CCS permite denirlos mediante la siguiente directiva:
1 2
#fuses HSPLL,NOWDT,PROTECT,NOLVP,NODEBUG,USBDIV,PLL1, CPUDIV1,VREGEN,NOMCLR,CPB
6.3.2.
Programa
El rmware realiza las siguientes tareas: Comunicacin USB Adquisicin de datos Formateo y comunicacin de datos Recepcin y envo de las cadenas HASP El bucle principal cumple el diagrama de ujo de la gura 6.9.
90
6.3. FIRMWARE
Figura 6.9: Diagrama de ujo principal.
6.3.3.
Comunicacin USB
El compilador CCS y sus libreras se encargan de los detalles a bajo nivel del hardware del mdulo USB, y gestiona el proceso de enumeracin y las transferencias. Para ello hay que incluir los archivos: pic18_usb.h: Implementa una capa que controla el hardware USB. usb.c: Gestiona el protocolo USB, el proceso de enumeracin y los descriptores. Mediante la siguiente directiva se indica que el perifrico es de velocidad completa:
1
#define USB_USE_FULL_SPEED TRUE Tambin hay que indicar que el dispositivo pertenecer a la clase HID para que se genere el cdigo necesario para manejar el protocolo.
#define USB_HID_DEVICE
TRUE
Endpoints
A continuacin hay que decidir cuantos endpoints se necesitan, la orientacin de los ujos de datos, y su propsito. Para determinarlo hay que analizar las comunicaciones que se producen entre el host y el dispositivo recordando que por una parte se comunica la informacin sobre los sensores, y por otra hay un ujo bidireccional para el intercambio de cadenas de desafo/respuesta. Por lo tanto se propone el uso de dos endpoints, uno de tipo IN y otro de tipo IN OUT.
91
Figura 6.10: Endpoints utilizados, direccin y propsito. Ahora hay que decidir el tamao de cada endpoint. Analicemos en primer lugar el tamao que ocupa un informe sobre el estado de los sensores. Hay que tener en cuenta que la unidad mnima de transmisin es el byte, por lo que hay que redondear estos tamaos a mltiplos de 8 bits: 10 sensores digitales (1 bit) + 10 sensores digitales simulados (1 bit) = 20 bits =>redondeado a 24 bits (3 bytes). 10 sensores digitales (conversin A/D de 10 bits) = 30 bits =>redondeado a 160 bits (20 bytes). Por cada sensor se utilizan 2 bytes para acomodar los 10 bits del resultado de la conversin A/D. En total se necesitan 23 bytes para la transmisin del estado de los sensores, por lo que el endpoint dedicado para ello tendr ese tamao. En cuanto al tamao del endpoint para el sistema HASP segn la denicin del algoritmo se usan 9 bytes del host al dispositivo (OUT), y 8 bytes del dispositivo al host (IN). Despus se activan los endpoints que se van a utilizar (adems del endpoint 0 que es imprescindible), y el tamao de cada uno.
1 2 3 4 5 6 7 8
#define USB_EP1_TX_ENABLE USB_ENABLE_INTERRUPT #define USB_EP1_TX_SIZE 23 #define USB_EP2_TX_ENABLE #define USB_EP2_TX_SIZE 8 #define USB_EP2_RX_ENABLE #define USB_EP2_RX_SIZE 9 USB_ENABLE_INTERRUPT
USB_ENABLE_INTERRUPT
92
6.3. FIRMWARE
Estas sentencias activan los registros de control del mdulo USB que habilitan los endpoints 0 (siempre activo), 1 y 2.
Descriptores
Antes de proceder al diseo de los descriptores recordemos que el propsito es que el host vea las dos funcionalidades del dispositivo, tanto el sistema HASP como el de sensorizacin. Para ello se propone el uso de dos interfaces, de manera que la jerarqua de descriptores quedara como muestra la gura 6.11.
Figura 6.11: Jerarqua de descriptores para el dispositivo El archivo lsred_desc.h contiene los descriptores del dispositivo, denidos como vectores de tipo char constante. El compilador CCS proporciona facilidades para la programacin de descriptores, como constantes con signicado simblico. Se puede extraer el chero de cabecera de descriptores de cualquier ejemplo USB suministrado con el compilador y personalizarlo para la aplicacin que se quiera desarrollar. El archivo lsred_desc.h es una modicacin del ejemplo ex_usb_kmouse que implementa un dispositivo combinado de teclado y ratn. Con esto en mente se disean los siguientes descriptores: El cdigo del fabricante (Vendor ID o VID) es asignado por el USB-IF, pero Microchip cede su VID para el desarrollo de dispositivos USB utilizando sus microcontroladores. El cdigo del producto servir para identicar al dispositivo cuando se conecte, se puede usar una codicacin denida por el diseador de acuerdo a las caractersticas del dispositivo. En este caso la F simboliza que lleva HASP integrado, y el 2 indica que es la segunda versin del producto, la primera fue una implementacin de prueba. En cuanto al nmero de serie al igual que ocurre con el nombre del fabricante o el vendedor, se puede utilizar una cadena ASCII. Luego esta cadena puede ser recuperada por el software para permitir al fabricante llevar un control sobre su produccin, lo que tambin resulta interesante. Para
93
Versin USB Codigo del fabricante Cdigo de producto Versin del producto Cadena del fabricante Cadena del producto Cadena del nmero de serie N. de conguraciones
2.0 Microchip (04D8) F002 0002 LSyM LSyM DAQ Board DAQ-0000 1
Cuadro 6.9: Descriptor de dispositivo Nmero de interfaces soportados Identicador de esta conguracin Opciones de energa Potencia requerida 2 1 Alimentado por el bus 100 mA
Cuadro 6.10: Descriptor de conguracin
este tipo de dispositivos se ha jado un nmero de serie del tipo DAQ-xxxx donde la parte derecha del guin es un nmero que se incrementa en cada dispositivo fabricado. Ms adelante se ver cmo se ha conseguido modicar el nmero de serie una vez programado el microcontrolador sin tener que modicar la cadena constante del chero lsred_desc.h y volver a compilar el rmware. Como se puede observar, se solicitan 100 mA que es ms de lo que necesita el microcontrolador, pero se ha elegido este ajuste para contar con suciente corriente para alimentar posibles futuras ampliaciones del dispositivo. En la siguiente tabla se muestra el descriptor HID utilizado, es el mismo para el interfaz de los sensores que para el HASP, lo nico que cambia es el descriptor de informe.
Versin de HID Cdigo de idioma Tipo de descriptor de informe
1.1 No denido HID
Cuadro 6.13: Descriptor HID
Numero de interfaz Cdigo de clase Nombre de este interfaz
0 HID (0x03) LSyM DAQ Board
Cuadro 6.11: Descriptor de interfaz 1
94
6.3. FIRMWARE
Numero de interfaz Cdigo de clase Nombre de este interfaz
1 HID (0x03) LSyM HASP Device
Cuadro 6.12: Descriptor de interfaz 2
Cdigo de endpoint Direccin Tamao mximo del paquete Intervalo de lectura
1 IN 23 bytes 10 ms
Cuadro 6.14: Descriptor de endpoint 1 (IN)
2 IN 8 bytes 10 ms
Cuadro 6.15: Descriptor de endpoint 2 (IN)
2 OUT 9 bytes 10 ms
Cuadro 6.16: Descriptor de endpoint 2 (OUT)
Con el n de agilizar el diseo de descriptores de informe, el USB-IF proporciona la herramienta Hid Descriptor Tool, que permite la edicin de descriptores de manera visual.
95
Figura 6.12: Captura de HID descriptor tool Con ella se ha generado el siguiente descriptor de informe para la sensorizacin:
USAGE_PAGE (Generic Desktop) Pag. de uso: Perifrico de escritorio USAGE (Game Pad) Uso concreto: Gamepad COLLECTION (Application) COLLECTION (Physical) USAGE (X) Eje X USAGE (Y) Eje Y USAGE (Z) Eje Z USAGE (Rx) Rotacin X USAGE (Ry) Rotacin Y USAGE (Rz) Rotacin Z USAGE (Wheel) Volante USAGE (Slider) Deslizador LOGICAL_MINIMUM (0) Mnimo lgico: 0 LOGICAL_MAXIMUM (1023) Mximo lgico: 1023 REPORT_SIZE (16) Tamao de informe: 16 bits REPORT_COUNT (8) N. de informes: 8 INPUT (Data,Var,Abs) Datos hacia el host (variables) USAGE_PAGE (Simulation Controls) Pag. de uso: Controles de simulacin USAGE (Throttle) Acelerador
96
6.3. FIRMWARE
USAGE (Brake) LOGICAL_MINIMUM (0) LOGICAL_MAXIMUM (1023) REPORT_SIZE (16) REPORT_COUNT (2) INPUT (Data,Var,Abs) USAGE_PAGE (Button) USAGE_MINIMUM (Button 1) USAGE_MAXIMUM (Button 20) LOGICAL_MINIMUM (0) LOGICAL_MAXIMUM (1) REPORT_SIZE (1) REPORT_COUNT (20) INPUT (Data,Var,Abs) REPORT_COUNT (4) INPUT (Cnst,Var,Abs) END_COLLECTION END_COLLECTION
Freno Mnimo lgico: 0 Mximo lgico: 1023 Tamao del informe: N. de informes: 2 Datos hacia el host Botn Primer botn: 1 ltimo botn: 20 Mnimo lgico: 0 Mximo lgico: 1 Tamao del informe: N. de informes: 20 Datos hacia el host N. de informes 4 Datos hacia el host
16 bits (variables)
1 bit (variables) (constantes)
Hay tres aspectos importantes a aclarar sobre el descriptor: En primer lugar el dispositivo se identica como un gamepad puesto que es un perifrico muy parecido y esto asegurar la compatibilidad con libreras de entrada. Otro aspecto importante es que los valores mximo y mnimo van de 0 a 1023 coincidiendo con los 11 bits de precisin del conversor A/D del PIC, esto permite a las libreras de entrada escalar el valor a otros rangos. Sin embargo el tamao del informe es de 16 bits para simplicar el formateado de los datos de salida como se indic antes. Finalmente a cada entrada analgica hay que darle un uso concreto aunque luego no se corresponda con el real tambin para asegurar la compatibilidad. Usando la misma herramienta, se ha generado el siguiente descriptor de informe para el sistema HASP:
USAGE_PAGE (Vendor Defined Page 1) USAGE (Vendor Usage 1) COLLECTION (Application) USAGE_MINIMUM (Vendor Usage 1) USAGE_MAXIMUM (Vendor Usage 1) LOGICAL_MINIMUM (0) LOGICAL_MAXIMUM (255) REPORT_SIZE (8) REPORT_COUNT (8) INPUT (Data,Var,Abs) USAGE_MINIMUM (Vendor Usage 1) USAGE_MAXIMUM (Vendor Usage 1) LOGICAL_MINIMUM (0) LOGICAL_MAXIMUM (255) REPORT_SIZE (8) REPORT_COUNT (9) OUTPUT (Data,Var,Abs) END_COLLECTION Pag uso: definido por el fabricante Uso definido por el vendedor Valor mn definido por el fabricante Valor mx definido por el fabricante Mnimo lgico: 0 Mximo lgico: 255 Tamao del informe: 8 bits Nmero de informes: 8 Datos hacia el host (variables) Valor min definido por el fabricante Valor max definido por el fabricante Mnimo lgico: 0 Mximo lgico: 255 Tamao del informe: 8 bits Nmero de informes: 9 Datos desde el host
97
De este descriptor hay que destacar que se le debe otorgar un valor mnimo y mximo a cada elemento de informe, que el tamao de los informes por el nmero de estos coincide con las especicaciones del algoritmo HASP (9 bytes de salida y 8 bytes de entrada) y que el uso de este interfaz est denido por el fabricante, con lo que no lo identicar como un gamepad y no enviar sus datos a la API de E/S, siendo responsabilidad del software comunicarse con l a bajo nivel.
6.3.4.
Adquisicin y formateado de datos
Una de las tareas fundamentales del micro es la adquisicin del estado de los sensores. En esta subseccin se explica el diseo y la implementacin de esta tarea.
Conguracin del conversor A/D

El microcontrolador PIC18F2550 dispone, como ya se ha comentado de un conversor A/D de 10 bits y 10 canales multiplexados. Este mdulo permite la conversin de un nivel de tensin analgico a su correspondiente valor digital de 10 bits, que aporta un rango digital de 0 a 1023. El voltaje de referencia analgico (Vref+ y Vref-) es seleccionable por software, entre VDD y VSS o el voltaje presente en los pines RA3 y RA2 respectivamente. Este rango de voltajes tambin llamado Vref afecta directamente a la resolucin del conversor segn la ecuacin 6.1. V ref + V ref V ref = 1024 1024
Res =
(6.1)
La mnima diferencia entre Vref+ y Vref- es de 2 V. Recordemos que se pretende utilizar VDD como Vref+ y GND como Vref- para optimizar el uso de los pines. Los pines del chip que vayan a ser usados como entradas analgicas deben congurarse como pines de entrada mediante la escritura en los registros TRIS (de tristate, o triestado) que controlan la direccin de las seales tal y como se mostr en la gura 5.14. Para congurar estos parmetros se escribe en el registro de control ADCON1 (g. 6.13), donde se seleccionan las referencias de tensin y se escoge un patrn de entradas de tipo analgico o digital (ntese que no se permite cualquier combinacin). En este caso seleccionamos las 10 entradas analgicas disponibles como tales (las entradas marcadas con (2) no estn disponibles en la versin del micro de 28 pines que se est utilizando).
98
6.3. FIRMWARE
Figura 6.13: Registro de conguracin A/D ADCON1 El proceso de conversin se compone de dos tiempos: el tiempo de adquisicin y el tiempo de conversin. Durante el primer tiempo el condensador interno del conversor A/D se carga hasta el nivel de la lnea analgica seleccionada, una vez cargado durante el tiempo de conversin se desconecta de la lnea analgica y se transforma este nivel en un valor digital mediante aproximaciones sucesivas. El tiempo de adquisicin se puede programar de manera que el mdulo espere el tiempo necesario antes de realizar la conversin, o se puede hacer de forma manual programando un bucle de espera activa. El TAD es el tiempo de conversin por bit y se dene como el tiempo necesario para determinar el valor de un solo bit del resultado de la conversin. Esta unidad de tiempo debe tener un valor de entre 1.4 s y 25 s si se utiliza una fuente fuente de reloj externa, o de 1 s si se utiliza el oscilador RC interno. El tiempo de adquisicin se puede congurar entre 2 y 20 TAD (el valor recomen-
99
Figura 6.14: Proceso de toma de una muestra con tiempo de adquisicin de 4 TAD
dado es de 2.45 s), mientras que para realizar la conversin se necesitan 11 TAD. La conversin se inicia escribiendo el valor 1 en el bit GO/DONE# del registro ADCON0.
El resultado de la conversin se escribe en los registros ADCONH:ADCONL. El valor de 11 bits puede ser justicado en el registro compuesto de 16 bits a la izquierda o a la derecha segn la conguracin establecida en el registro ADCON0, los bits no usados son rellenados con ceros y se genera una interrupcin. El condensador queda conectado a la lnea analgica para una nueva conversin.
Se utiliza el oscilador RC interno (1 MHz), y un valor de tiempo de conversin automtico de 2 TAD.
Finalmente, con el registro ADCON0 se puede controlar el multiplexor para seleccionar la entrada analgica deseada.
100
6.3. FIRMWARE
Figura 6.15: Registro de conguracin A/D ADCON2
101
Figura 6.16: Registro de conguracin A/D ADCON0 Estos registros son escritos por el compilador CCS mediante llamadas a funciones de alto nivel, pero es imprescindible conocer su funcionamiento para entender las limitaciones del hardware.
Implementacin de la adquisicin de datos

El archivo lsred_main.c contiene el programa principal y otras subrutinas de apoyo. Para la inicializacin del hardware se dene una funcin sensorInit() que hace lo siguiente: Congura la funcin y direccin de cada pin mediante los registros TRIS. Activa los pull-up del puerto B. Selecciona todos los pines ANx como entradas analgicas. Establece el oscilador RC interno del conversor A/D.
102
6.3. FIRMWARE
Selecciona al entrada analgica AN0. El cdigo correspondiente es:

1 2 3 4 5 6 7
SET_TRIS_A(0b10111111); SET_TRIS_B(0b11111111); SET_TRIS_C(0b11000111); PORT_B_PULLUPS(TRUE); setup_adc_ports(ALL_ANALOG); setup_adc(ADC_CLOCK_INTERNAL); set_adc_channel(0); Esta funcin se llama una vez desde el programa principal y deja el hardware listo para realizar las conversiones. Para la generacin del informe HID se dene un vector de tipo char global con el nombre out_data de 23 elementos. El vector es rellenado por la funcin sensorTask(), cuyo funcionamiento es el siguiente: Inicializa a 0 todo el vector. Selecciona el primer canal analgico. Toma una muestra del canal. Copia los 8 bits ms bajos de la conversin en el primer byte del vector. Copia los 2 bits restantes de la conversin en los dos bits menos signicativos del siguiente byte del vector. Repite el proceso con las 9 entradas analgicas restantes incrementando el ndice del vector out_data. El cdigo que realiza esta tarea es:
1 2 3 4 5 6 7 8 9 10 11 12
for(i=0;i<23;i++) out_data[i] = 0x0; ... set_adc_channel(channel); read_adc(ADC_START_ONLY); sample = read_adc(ADC_READ_ONLY); out_data[i] = sample & 0x00FF; out_data[i+1] = (sample & 0x300) >> 8; EvaluarAD(channel, sample); ...
103
Como puede observarse, por cada canal convertido se realiza una llamada a la funcin EvaluarAD(). Antes de explicar su propsito recordemos el nmero total de entradas fsicas del chip: Tipo de entrada Entradas digitales Entradas analgicas Nmero 10 10 ID asignado D0..9 AD0..9
Cuadro 6.17: Nmero y tipo de entradas Sin embargo, en el descriptor se notica al host de que el nmero de entradas digitales no es 10 sino 20. Durante el diseo del hardware se decidi que cada entrada analgica tendra asociada una entrada digital simulada, cuyo valor lgico dependera del valor de la ltima muestra tomada en su entrada analgica correspondiente. Esto permite conectar pulsadores a entradas analgicas cerrando el jumper adecuado. Las entradas digitales reales (que disponen de un pin digital asignado en el chip) se numeran de D0 a D9, y las simuladas de D10 a D19.
Figura 6.17: Funcionamiento de las entradas digitales simuladas. Como se muestra en la gura 6.17, cuando se toma una muestra del canal asociado a la entrada ADx, se evala si el valor est por encima o por debajo de cierto umbral UMBRAL_AD, denido como constante en el programa, si es mayor que el valor de la entrada simulada Dy es 0 (no pulsado) donde y = x+10, si es menor o igual es 1 (pulsado). La funcin Evaluar_AD toma como parmetros la muestra obtenida y el canal x, evala la ecuacin 6.2 y escribe el resultado en el bit correspondiente del vector out_data de informe. El umbral se ha jado en 700 por observar durante las fases de depuracin que es un valor adecuado. Dy = 1 si ADx UMBRAL_AD y = x + 10 0 si ADx > UMBRAL_AD (6.2)
104
6.3. FIRMWARE
Finalmente se realiza la captura de los sensores digitales. Los valores se deben invertir, ya que debemos recordar que segn la clase HID, 0 signica no pulsado y 1 signica pulsado. Sin embargo debido al esquema de conexin mediante pull-up los valores que obtenemos son los complementarios.
1 2 3 4 5 6 7 8 9 10 11
out_data[20] out_data[20] out_data[20] out_data[20] out_data[20] out_data[20] out_data[20] out_data[20]
|= |= |= |= |= |= |= |=
(~D0&0x1); (~D1&0x1)<< (~D2&0x1)<< (~D3&0x1)<< (~D4&0x1)<< (~D5&0x1)<< (~D6&0x1)<< (~D7&0x1)<<
1; 2; 3; 4; 5; 6; 7;
out_data[21] |= out_data[21] |=
(~D8&0x1); (~D9&0x1)<< 1;
Una de las dicultades ms comunes al muestrear el estado de pulsadores a gran velocidad suele ser el problema de los rebotes. Los rebotes son uctuaciones de una seal conectada a un pulsador o switch que se producen al accionarlo, esto ocasiona que la transicin de la seal no sea limpia debido a las imperfecciones del mecanismo y dando lugar a la presencia de niveles lgicos aleatorios durante un corto intervalo de tiempo.
Figura 6.18: Rebote producido al presionar un pulsador. Existen varias soluciones a este problema, desde la instalacin de comparadores de tipo Schmitt Trigger hasta la reduccin de la frecuencia de muestreo. En este caso como los informes se generan cada 10ms esto no supone un problema puesto que el intervalo de tiempo es sucientemente grande como para que la seal se estabilice. Finalmente se enva el informe por el endpoint 1.
1
usb_put_packet(1,out_data,23,USB_DTS_TOGGLE);
105
Funcin hasp_init() sign()
Propsito Inicializa la librera. Recibe una cadena de desafo y devuelve la respuesta.
Cuadro 6.18: Interfaz de la librera HASP para PIC18.
6.3.5.
Implementacin del algoritmo HASP
Para el manejo del sistema HASP se ha implementado una librera que prcticamente contiene el cdigo realizado en la aplicacin de prueba swval. El interfaz de la misma es: La funcin HASPTask() lee la cadena de desafo que ha llegado por el endpoint 2, llama a sign() para obtener la respuesta, y enva esta ltima de nuevo por el endpoint 2.
1 2 3
usb_get_packet(2, data_buffer, 9); sign((ptrWord)data_buffer); usb_put_packet(2, data_buffer, 8, USB_DTS_TOGGLE);
6.3.6.
Programa principal
El programa principal sigue bsicamente el diagrama de ujo representado en la gura 6.9. En primer lugar inicializa el hardware del conversor A/D y los puertos de E/S, la librera USB y la librera HASP. Despus entra en bucle innito en el que atiende el protocolo USB, y peridicamente llama a sensorTask. Si se reciben datos de HASP por el endpoint 2 se llama a HASPTask(). Finalmente se incluye un retardo de 4 ms para esperar antes de generar el siguiente informe. El tiempo invertido en realizar las conversiones aadido al tiempo de espera da un valor cercano a 10 ms.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
sensorInit(); usb_init_cs(); hasp_init(); while (TRUE) { usb_task(); if (usb_enumerated()) { sensorTask(); if (usb_kbhit(2)) { HASPTask(); } } delay_ms(4); }
106
6.3. FIRMWARE
6.3.7.
Generacin del ejecutable
El compilador genera un ejecutable en formato HEX (INHX32) que contiene una imagen de la memoria FLASH y los registros de conguracin mapeados a partir de la direccin 300000. Para programarlo en el chip se debe colocar en el mdulo de programacin y pulsar el botn program del MPLAB. Mediante el programador USB se programa la memoria en cuestin de segundos y el micro queda listo para funcionar.
6.3.8.
Bootloader
Para cumplir todos los requisitos del proyecto se debe dotar al sistema de un mecanismo para la actualizacin del rmware que ejecuta, y de otros parmetros variables como el nmero de serie o la clave HASP. Todo ello debe poder realizarse mediante el enlace USB del micro sin necesidad de extraerlo del circuito impreso y colocarlo en un mdulo de programacin. Las actualizaciones de rmware sern de gran utilidad para los usuarios en caso de que despus de la entrega del producto se detecte algn bug o se realice alguna mejora, permitiendo a este instalar la ltima versin sin requerir una intervencin tcnica. Por otra parte, el poder reprogramar algunos parmetros como el nmero de serie y la clave HASP son tiles para los desarrolladores o durante el proceso de fabricacin. Para cubrir estas necesidades se utilizan Bootloaders o cargadores de arranque. Los Bootloaders son piezas de software que suelen residir en las primeras posiciones de memoria y por lo general no se pueden actualizar. Su propsito es reprogramar el rea de memoria del rmware de aplicacin con datos nuevos recibidos a travs de algn puerto (RS-232, USB, I2C ...). En la actualidad cientos de dispositivos emplean bootloaders, desde reproductores de MP3 hasta consolas de videojuegos. El diseo de bootloaders tiene sentido ya que no se puede reprogramar una zona de cdigo que est siendo ejecutada puesto que puede producir resultados impredecibles al sustituir instrucciones y direcciones de salto por otras nuevas.
Firmware de aplicacin
El rmware de aplicacin es el programa que ejecuta el sistema normalmente cuando no est actualizndose, en este caso se trata del programa descrito en la seccin anterior. Para acomodar un rmware de aplicacin a la presencia de un bootloader se deben realizar algunos cambios en el mismo, siendo el principal la relocalizacin del cdigo para dejar libre el rango de memoria reservado para el bootloader.
Modos de operacin
Cuando arranca el sistema, lo primero en ejecutarse es el bootloader ya que ocupa las primeras posiciones de memoria. En este punto se debe decidir si se requiere una
107
actualizacin (entrando as en modo de actualizacin, o DFU1 ), o debe ceder el control al rmware de aplicacin mediante un salto a su punto de entrada (modo de funcionamiento normal). Esta decisin se puede tomar de varias maneras en funcin del dispositivo del que se trate: Mediante la pulsacin de una combinacin de teclas. Esto slo es viable en dispositivos con teclas, y se ha de escoger una combinacin o tiempos de pulsacin que sea prcticamente imposible que se den durante el funcionamiento normal (p. ej: pulsar el botn POWER y Men durante 20 segundos). Tambin se puede poner una tecla especial para ello. Por software mediante el envo de un comando. Es un mtodo ms able puesto que no requiere intervencin del usuario. Si el dispositivo est conectado de alguna manera mediante un enlace de datos se le puede enviar un comando especial que lo ponga en modo de actualizacin.
Figura 6.19: Mapa de memoria de un dispositivo con bootloader Cuando se est en modo de actualizacin se ejecuta un subprograma que recibe datos por el puerto y los escribe en direcciones de la memoria ash suministradas por el mismo puerto. Tambin suelen permitir el envo de comandos para otras funciones, como lectura de la ash, o reinicio en modo de aplicacin.
Bootloader diolan
Durante la revisin bibliogrca se encontr un bootloader de cdigo abierto para PIC18, liberado bajo licencia GNU GPL por diolan.com, una empresa de sistemas empotrados que lo usa en sus productos. El bootloader est programado usando el compilador
1
Device Firmware Update
108
6.3. FIRMWARE
C18 y el ensamblador MPASM, razn por la que se emplean tambin estas herramientas para su compilacin. Sus caractersticas son:
Tamao reducido: 2 Kb
Comunicacin por USB. Perifrico de clase HID (no requiere drivers)
Encriptacin de datos usando el algoritmo XTEA
Paso de modo aplicacin a DFU por software o mediante pulsador
Estas caractersticas lo hacen perfecto para el propsito de este proyecto. Una de las caractersticas fundamentales aqu es la comunicacin de datos encriptados. Esta caracterstica hace que proporcione al usuario una imagen del rmware cifrada, que pasa por el bus USB cifrada, y se descifra dentro del microcontrolador, que a su vez tiene establecidos los bits de proteccin de cdigo en sus registros de conguracin. El algoritmo XTEA est especialmente indicado para dispositivos empotrados por requerir muy poca memoria RAM y tener un coste computacional escaso. Un sistema es tan dbil como su punto ms dbil, por lo que entregar una imagen del rmware sin cifrar a un usuario para actualizar sus dispositivos podra dar lugar al desensamblado del cdigo y obtencin de claves privadas y fabricacin de rplicas rompiendo as la cadena de seguridad. Por otra parte el uso de la clase HID mantiene el dispositivo driverless, y debe su reducido tamao a que muchas partes de la gestin del bus USB han sido reescritas en ensamblador, y otras innecesarias han sido eliminadas.
Implementacin
En el momento de realizar la implementacin el fabricante no proporciona ningn tipo de documentacin, ni software adicional para controlarlo desde el PC. Se permita nicamente la descarga del cdigo fuente del bootloader para PIC18F4455. Por lo tanto ha sido necesario realizar un estudio del cdigo para determinar su funcionamiento y poder desarrollar las herramientas necesarias para su manejo por USB. El bootloader presenta un interfaz basado en comandos:
109
Comando BOOT_CMD_READ_CODE BOOT_CMD_WRITE_CODE BOOT_CMD_ERASE_CODE BOOT_CMD_GET_FW_VER BOOT_CMD_RESET BOOT_CMD_READ_ID BOOT_CMD_WRITE_ID BOOT_CMD_UNKNOWN
Utilidad Lee un segmento de cdigo de la Flash Escribe un segmento de cdigo a la Flash Borra un segmento de cdigo de la Flash Devuelve la versin del bootloader Reinicia el micro Lee el ID del micro Escribe el ID del micro Usado para control de errores
Cuadro 6.19: Comandos aceptados por el bootloader. Para la comunicacin con el host se utiliza el endpoint 1, con un tamao de paquete de 64 bytes. El primer byte codica el comando a ejecutar, el segundo byte es un identicador de comando que debe suministrar el software y que sirve para enlazar comandos y respuestas. El resto de los bytes depende del comando especco. A continuacin se explican los cuatro comandos que se han utilizado:
BOOT_CMD_READ_CODE
Este comando toma los siguientes argumentos: Byte 3 4 5 6 Contenido Parte baja de la direccin Parte alta de la direccin Reservado Tamao a leer en bytes (mltiplo de 8)
Al enviar este comando, el bootloader lee el rea de cdigo solicitada, la cifra con el algoritmo XTEA y la devuelve mediante una transferencia. Hay que tener en cuenta que los argumentos que toma este comando dejan un total de 58 bytes libres en el paquete, lo que limita el valor mximo del campo que indica el tamao a leer.
BOOT_CMD_WRITE_CODE
Este comando toma los siguientes argumentos: Byte 3 4 5 6 Contenido Parte baja de la direccin Parte alta de la direccin Reservado Tamao a escribir en bytes (mltiplo de 8)
110
6.3. FIRMWARE
Cuando el bootloader recibe este comando, descifra el paquete de datos que lo acompaa y lo escribe en la direccin solicitada. Tiene la misma limitacin de tamao que el anterior.
BOOT_CMD_ERASE_CODE
Este comando toma los siguientes argumentos: Byte 3 4 5 6 Contenido Parte baja de la direccin (debe ser mltiplo de 64) Parte alta de la direccin Reservado Tamao a borrar en bloques de 64 bytes
El comando borra la memoria ash. Puesto que la ash se borra por bloques de 64 bytes el tamao debe estar especicado en bloques de este tamao, y la direccin debe ser un mltiplo. Es necesario recordar que la tecnologa Flash impone que antes de reescribir un rea de memoria primero hay que borrarla.
BOOT_CMD_RESET
El comando no toma ningn argumento, su funcin es reiniciar el micro en modo de funcionamiento normal.
Procedimiento de arranque
El bootloader puede tomar la decisin sobre si arrancar en modo DFU o normal de acuerdo al estado de un jumper externo, o tambin permite el uso de una EEPROM mark, un valor especial grabado en memoria EEPROM cuyo funcionamiento es el siguiente: Cuando el micro arranca, el bootloader comprueba si en la direccin 0 de la memoria EEPROM est presente el valor 5A. Si es as arrancar en modo DFU, el host lo detectar como dispositivo HID genrico y quedar listo para la recepcin de comandos. En caso contrario salta a la direccin 0x800, que coincide con el punto de entrada del rmware de aplicacin. El modo de funcionamiento basado en la EEPROM mark tiene la ventaja de que si la actualizacin queda incompleta, debido a un fallo elctrico, la desconexin accidental del dispositivo o cualquier otra eventualidad al conectarlo de nuevo volver a arrancar en modo DFU en lugar de ejecutar la imagen corrupta del rmware y permitir intentarlo de nuevo tantas veces como sea necesario.
Vendor ID y Product ID
El vendor ID y product ID por defecto son 0x1234 y 0x8765. Estos han sido cambiados a 0x04D8 (Microchip), y 0x0000 para su posterior deteccin en el PC.
111
Punto de entrada
Se necesita algn mecanismo para que el dispositivo pase de modo de funcionamiento normal a modo DFU para actualizar su rmware. Para ello el bootloader tiene un punto de entrada en la direccin 0x0016. Si el rmware de aplicacin realiza un salto a esta direccin se escribe el valor 5A en la EEPROM y despus se ejecuta la instruccin RESET que reinicia el micro por software, en estas condiciones como se ha descrito antes arrancar en modo DFU quedando listo para la actualizacin.
Algoritmo XTEA
El algoritmo XTEA deriva del TEA (Tiny Encryption Algorithm). Es un algoritmo de cifrado por bloques notable por su simplicidad de descripcin e implementacin. No est sujeto a ninguna patente. XTEA opera sobre bloques de 64 bits, usa una clave simtrica de 128 bits y una constante numrica delta. Contiene una estrcutrua de Feistel2 que se ejecuta un nmero determinado de iteraciones, cuantas ms iteraciones, mayor es el nivel de seguridad recomendndose 64 como compromiso entre seguridad y velocidad. Se clasica dentro de los block-cipher. En la implementacin del algoritmo se usan 64 iteraciones, la constante delta tiene un valor predenido y la clave XTEA se ha determinado de forma que su obtencin por fuerza bruta no sea trivial. Estos parmetros se programan como constantes en el archivo xtea.asm que contiene el algoritmo de cifrado y descifrado escrito en ensamblador. La clave XTEA se escribe como una cadena ASCII de 16 caracteres.
Modicaciones hechas al rmware de aplicacin

Para acomodar el bootloader junto con el resto del cdigo y permitir la convivencia entre ambos se han tenido que realizar ciertas modicaciones al rmware de aplicacin que se describen a continuacin: Relocalizacin del cdigo El cdigo generado originalmente estaba diseado para su ejecucin directa, con lo que comenzaba en la direccin 0x0000 (vector de reset). Puesto que esas direcciones estn ocupadas ahora por el bootloader hay que relocalizar el cdigo para que empiece en la direccin 0x0800 que es donde se salta para iniciar el funcionamiento normal. Relocalizacin de vectores de interrupcin Los vectores de interrupcin de la arquitectura PIC18 se encuentran en 0x0008 para interrupciones de alta prioridad y 0x0018 para interrupciones de baja prioridad. Estos vectores hay que relocalizarlos a 0x0808 y 0x0818 respectivamente.
2
Mtodo de cifrado por bloques con una estructura particular
112
6.4. SOFTWARE PARA EL PC
Relocalizacin de constantes reprogramables Las constantes que se quiere poder reprogramar externamente mediante el bootloader como el nmero de serie y la clave HASP tienen que estar situadas en posiciones de memoria mltiplo de 64 bytes para permitir el borrado y posterior reprogramado. Denicin de un comando DFU El dispositivo debe, mediante los interfaces USB denidos originalmente, poder recibir algn comando que provoque el salto al punto de entrada del bootloader para su reinicio en modo de actualizacin de rmware. Para solucionar los dos primeros puntos se escribe la siguiente directiva:
1
#build(reset=0x800,interrupt=0x808) // Solo alta prio. En cuanto a la relocalizacin de constantes reprogramables, se utiliza la direccin 0x7D00 para la cadena ASCII del nmero de serie y 0x7D80 para la clave HASP, teniendo especial cuidado de que el borrado de 64 bytes a partir de cada una de estas direcciones no borre nada ms que las constantes afectadas. Para ello se ha utilizado la directiva #org del compilador que coloca el cdigo que va a continuacin en la direccin especicada. Para el reinicio en modo DFU se aprovecha el interfaz del dispositivo HASP, de manera que si los 6 primeros bytes de la cadena de desafo corresponden con la secuencia ASCII rstCmd se salta al punto de entrada del bootloader, quedando la funcin HASPTask() como sigue:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
void HASPTask(void) { usb_get_packet(2, data_buffer, 9); for(i=0; i<6; i++) if(rstMsg[i] != data_buffer[i]) goto hasp; #asm goto 0x0016 ; Bootloader entry point #endasm hasp: // Sign the string sign((ptrWord)data_buffer); // Send back the signed string usb_put_packet(2, data_buffer, 8, USB_DTS_TOGGLE); }
6.4.
SOFTWARE PARA EL PC
En esta seccin se describe el desarrollo del software que corre en el PC.
113
6.4.1.
Librera HASP
Durante el desarrollo del rmware ya se aclar que la funcionalidad de sensorizacin no necesita de ninguna librera especial, puesto que el uso del item Application del descriptor HID, y su identicacin como gamepad lo hacen compatible con cualquier librera de entrada estndar. Sin embargo, la funcin HASP, al ser un interfaz de uso denido por el fabricante requiere de una comunicacin especializada. Se pretende implementar una librera que se haga cargo de los detalles del hardware y que proporcione al software que la incorpore un interfaz de alto nivel para la utilizacin del sistema HASP. Todo el cdigo fuente ha sido comentado debidamente para generar su documentacin con la herramienta doxygen y se proporciona el cdigo de una aplicacin pruebalib en el CD adjunto que muestra su funcionamiento. La funcin del sistema HASP es, en ltima instancia, proporcionar al software una sola informacin: la copia que se est ejecutando es legal?, y con esta idea en mente se procede al desarrollo de un interfaz que permita al software conocer esta informacin de manera clara y precisa. En primer lugar, hay que tener en cuenta varios factores para el diseo: Se pueden producir diversos eventos en relacin con el hardware: desconexin, error de comunicaciones ... Los eventos suceden de forma asncrona con el funcionamiento del software El protocolo de desafo/respuesta debe obedecer a cierta temporizacin Deben poder utilizarse otros protocolos de validacin de software en caso de que se implementen en un futuro La arquitectura debe ser lo sucientemente general como para permitir la comunicacin HASP mediante otros tipos de bus distintos de USB para facilitar el diseo de futuros perifricos. No debe suponer una carga importante para la CPU No debe consumir grandes recursos Para abordar este diseo se opta por una arquitectura basada en capas. La arquitectura basada en capas se enfoca en la distribucin de roles y responsabilidades de forma jerrquica proveyendo una forma muy efectiva de separacin de responsabilidades. El rol indica el modo y tipo de interaccin con otras capas, y la responsabilidad indica la funcionalidad que est siendo desarrollada [MHH+ 08]. Esta arquitectura resulta muy beneciosa, puesto que proporciona: Abstraccin. La arquitectura basada en capas abstrae la vista del modelo como un todo mientras que provee suciente detalle para entender las relaciones entre capas.
114
Figura 6.20: Pila de capas de la librera libhw Encapsulamiento. El diseo no hace asunciones sobre tipos de datos, mtodos, propiedades o implementacin. Funcionalidad claramente denida. El diseo claramente dene la separacin entre la funcionalidad de cada capa. Los datos uyen hacia y desde las capas en cualquier sentido. Rendimiento. Distribuir las capas entre mltiples sistemas puede incrementar la escalabilidad, tolerancia a fallos y el rendimiento. Alta cohesin. Cada capa tiene una funcionalidad directamente relacionada con la su tarea. Reutilizable. Las capas inferiores no tienen ninguna dependencia con las capas superiores, permitiendo ser reutilizables en otros escenarios. Desacople. La comunicacin entre dos capas est basada en la abstraccin lo que provee un desacople entre ellas.
El nombre de la librera es libhw, ya que ofrece un interfaz con el hardware diseado. La gura 6.20 muestra la pila de capas desarrollada, y la gura 6.4.1 el diagrama de clases. El funcionamiento de cada parte explica a continuacin:
Driver
Esta es la capa encargada de realizar la comunicacin con el dispositivo. La tabla 6.20 muestra el interfaz presentado por la capa Driver.
115
enumerate() send() receive() reset() getState()
Detecta si el dispositivo est presente Enva un paquete de datos al dispositivo Recibe un paquete de datos desde el dispositivo Reinicia la comunicacin Obtiene el estado interno
Cuadro 6.20: Interfaz de la capa Driver Su funcionamiento est gobernado por la mquina de estados de la gura 6.22 que permite el control de las operaciones sobre el hardware en funcin de la presencia del mismo y el estado de las comunicaciones. El estado UNENUM indica que el dispositivo no se ha detectado, bien porque an no se ha llevado a cabo la deteccin mediante la llamada a enumerate(), o bien porque esta deteccin ha sido infructuosa. Durante el porceso de enumerado, el driver pasa al estado enumerating() que dura hasta que se completa el procedimiento. Si se encuentra un dispositivo compatible se pasa al estado OK hasta que se produce un error de comunicaciones pasando al estado DRVERROR, o se desconecta el dispositivo pasndose de nuevo al estado UNENUM. La clase Driver es una superclase abstracta y dene el interfaz que debe proporcionar cualquier driver especializado para manejar un tipo de dispositivo concreto. Las clases derivadas tienen la responsabilidad de manejar las transiciones entre estados de
116
Figura 6.21: Superclase Driver forma correcta y de implementar la comunicacin real con el hardware.
Protocol
La capa Protocol implementa un protocolo de validacin de software basado en intercambio de mensajes. El interfaz ofrecido para su comunicacin con las capas adyacentes es el siguiente: El protocolo dene un buffer de salida para el envo de mensajes y otro de entrada para la recepcin. La entidad que utilice el protocolo deber llamar a preStep() para que la implementacin prepare la cadena a enviar y la coloque en el buffer de salida, despus enviar el mensaje al dispositivo HASP, y recibir la respuesta producindose as init() getOutputBuffer() getInputBuffer() preStep() postStep() reset() getState() Inicializa el protocolo Obtiene un puntero al buffer de salida Obtiene un puntero al buffer de entrada Ejecuta acciones previas al intercambio de datos Ejecuta acciones posteriores al intercambio de datos Reinicia el protocolo Obtiene el estado interno
Cuadro 6.21: Interfaz de la capa Protocol
117
Figura 6.22: Mquina de estados de la capa Driver
Figura 6.23: Superclase Protocol
118
Figura 6.24: Mquina de estados de Protocol el intercambio de datos. Finalmente colocar el mensaje recibido en el buffer de entrada y llamar a postStep() para que se compruebe que es correcto. Su funcionamiento, al igual que ocurre con la capa anterior obedece a la mquina de estados mostrada en la gura 6.26. El protocolo se inicia en el estado STOP, cuando se llama a init() pasa por el estado INITIALIZING, y si la operacin tiene xito llegar al estado OK. Cuando se ejecuta la operacin postStep(), si las comprobaciones del protocolo fallan se pasar al estado PROT_ERROR del que se podr salir llamando a reset(), volvendose de nuevo al estado OK.
LSYMHASP
LSYMHASP es la capa superior, que implementa la API para el uso del sistema. Es la parte ms compleja, puesto que tiene la mayor responsabilidad. Utiliza la capa Driver para comunicarse con el hardware, y gestiona el paso de informacin entre ste y el protocolo implementando un servicio de noticacin de eventos mediante la API. El interfaz que ofrece es el siguiente: El mtodo de noticacin de eventos es mediante una funcin de callback. Esta funcin es llamada por la librera recibiendo como argumento un mensaje codicado como entero. Los mensajes cubren las situaciones del sistema HASP que son de inters para el software que lo implementa: La implementacin ms tpica consiste en asumir que el software debe estar desblo-
119
Figura 6.25: Clase LSYMHASP start() stop() validHWPresent() getSerialString() getPID() Inicializa el sistema HASP Detiene el sistema HASP Devuelve si hay un hardware HASP vlido conectado Obtiene la cadena del nmero de serie del dispositivo conectado Obtiene el PID del hilo Cuadro 6.22: Interfaz de la capa LSYMHASP HWERROR PERROR DISCONNECTED ONLINE INIT INIT_ERROR STOP Error de hardware Error de protocolo No hay dispositivo conectado Dispositivo conectado y funcionando Inicializando sistema Error de inicializacin Sistema detenido
Cuadro 6.23: Mensajes de noticacin
120
Figura 6.26: Mquina de estados de LSYMHASP queado una vez se ha recibido el mensaje ONLINE, y que debe estar bloqueado al recibir cualquier otro mensaje. El funcionamiento del sistema HASP discurre de forma paralela al del software que lo implementa. Para cumplir esto se emplea un hilo que se crea con la llamada a start() y se destruye con la llamada a stop(). La implementacin del hilo contiene el cdigo que realiza la comunicacin con las capas subyacentes y provoca las noticaciones. Esto implica que la funcin de callback es llamada por el propio hilo, con lo que el programador debe tener la precaucin de utilizar los mecanismos de sincronizacin pertinentes si el cdigo contenido en el callback accede a estructuras de datos compartidas con el propio software. El hilo ejecuta un ciclo de validacin (preStep - intercambio de datos - postStep) cada aproximadamente 1 segundo, con lo que pasa la mayor parte del tiempo suspendido suponiendo una carga muy pequea para la CPU. Por ello, tambin hay que tener en cuenta que el tiempo de ejecucin del cdigo contenido en la funcin de callback no tenga una duracin excesiva para no alargar el tiempo del ciclo ni correr el riesgo de bloquearse indenidamente ya que esto ltimo detendra el proceso de validacin sin noticacin alguna. El hilo adems comprueba en todo momento la presencia del dispositivo, si no se detecta en cada ciclo se reenumera en su busca, noticando en todo momento de los eventos producidos y actualizando el estado de la mquina de estados interna. La clase LSYMHASP puede lanzar excepciones como resultado de las llamadas a los mtodos start() o stop(). La clase libhwException que implementa la excepcin
121
EX_THREADSTARTED EX_STOPPED EX_CANTSTOP EX_CANTSTART
El hilo ya ha sido iniciado El hilo ya ha sido detenido No se puede detener el hilo No se puede iniciar el hilo
Cuadro 6.24: Cdigos de excepcin contiene el cdigo del error y una cadena de caracteres opcional con el signicado. Los posbiles errores son: El diagrama de secuencia de la gura 6.27 muestra un ciclo de validacin.
LSYMHASPD2
La clase LSYMHASPD2 es una implementacin de driver para las placas modelo 2 (recordemos que el cdigo de producto era 2 puesto que el primer modelo fue una implementacin de prueba). Deriva de la clase abstracta Driver e implementa los mtodos de esta. La comunicacin a bajo nivel con el dispositivo se ha basado en los ejemplos de Jan Axelson [Axe05] para detectar y comunicarse con dispositivos HID en sistemas Windows empleando el Windows DDK. La implementacin permite obtener el Vendor ID (VID) y el Product ID (PID) de cada uno de los dispositivos HID conectados actualmente al sistema y abrir un manejador al que se desee para poder leer y escribir como si se tratase de un chero. Las lecturas y escrituras son bloqueantes pero se programa un tiempo de espera mximo de 6 segundos de manera que un fallo en la comunicacin o en el dispositivo no inhabiliten el sistema HASP.
LSYMCSVP
LSYMCSVP es la implementacin del protocolo de validacin por desafo-respuesta propuesto al principio de esta seccin. Su nombre son las siglas de Challenging Software Validation Protocol. Su cdigo es el de la parte host de la implementacin de prueba swval con los cmbios mnimos para encapsularlo en una especializacin de Protocol.
6.4.2.
Herramientas complementarias
Para la gestin del cdigo del dispositivo mediante el bootloader se necesita desarrollar herramientas adicionales, que se explican a continuacin.
Herramienta fwcrypt
La herramienta fwcrypt lee una imagen del rmware en formato HEX (INH32) y genera una imagen encriptada en un chero de salida. Este chero es apto para cargarse en el micro mediante el bootloader.
122
Figura 6.27: Diagrama de secuencia de un ciclo del protocolo HASP.
123
El formato HEX de Intel es un chero de texto que contiene la imagen de un programa mediante la descripcin de las direcciones de memoria y los datos que las ocupan. Existen formatos de 6, 16, y 32 bits pero el que genera el compilador es este ltimo. Cada lnea de un chero .HEX se compone de seis partes: Cdigo de inicio: Es el caracter ASCII dos puntos (:) Nmero de bytes: Dos dgitos hexadecimales que codican el nmero de bytes presentes en el campo de datos Direccin: Cuatro dgitos hexadecimales que especican la direccin de comienzo de la secuencia de datos contenida en el campo de datos. Est limitada a 64 Kb y representada en formato big endian Tipo de registro: Dos dgitos hexadecimales codicando el tipo de datos en el campo de datos. Los dos tipos de registros que se han usado son: 00 Registro de datos. El registro de datos contiene datos vlidos. 01 Registro de nal de chero. Debe ser el ltimo. Campo de datos: Secuencia de n bytes de datos (2n dgitos hexadecimales) Checksum: Suma de comprobacin. Se obtiene sumando los bytes de todos los campos, excepto el cdigo de inicio y el checksum y obteniendo el complemento a 2 del byte menos signicativo del resultado. Si los datos son correctos, al sumar los bytes de todos los campos excepto el cdigo de inicio dar un valor cuyo byte menos signicativo es 0 El programa recibe en la lnea de comandos el nombre del chero a cifrar, lo abre y decodica el chero .HEX lnea a lnea ignorando aquellos que estn presentes en una direccin superior a 0x300000 (registros de conguracin) y comprobando el checksum. Los datos se van colocando en un array que simboliza la memoria del microcontrolador. Despus se recorre este array cifrando en bloques de 64 bits con el algoritmo XTEA y la clave XTEA pasada tambin en la lnea de comandos. Finalmente se vuelca este array directamente a un chero de salida. La implementacin de los algoritmos de cifrado y descifrado se muestran a continuacin: Cifrado:
1 2 3 4 5 6
sum, i : Entero sin signo x1: Entero de 32 bits (primera mitad del bloque) x2: Entero de 32 bits (segunda mitad del bloque) XTEA_ITER: N. de iteraciones (64) DELTA: Constante numrica (0x9E3779B9)
124
7 8 9 10 11 12 13 14 15
sum=0; for( i=0; i<XTEA_ITER; i++ ) { x1 += (((x2<<4) ^ (x2>>5)) + x2) ^ (sum + key[sum&0x03]); sum+= DELTA; x2 += (((x1<<4) ^ (x1>>5)) + x1) ^ (sum + $KEY[(sum>>11)&0x03]); } Descifrado:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
sum, i : Entero sin signo x1: Entero de 32 bits (primera mitad del bloque) x2: Entero de 32 bits (segunda mitad del bloque) XTEA_ITER: N. de iteraciones (64) DELTA: Constante numrica (0x9E3779B9) sum = DELTA* XTEA_ITER; for( i=0; i<XTEA_ITER; i++ ) { x2 -= (((x1<<4) ^ (x1>>5)) + x1) ^ (sum + key[(sum>>11)&0x03]); sum-= DELTA; x1 -= (((x2<<4) ^ (x2>>5)) + x2) ^ (sum + key[sum&0x03]); }
Herramienta lsymash
La herramienta lsymash busca el dispositivo en modo DFU (buscando dispositivos HID con Vendor ID 0x04D8 y Product ID 0x0000), toma un archivo de imagen de rmware cifrada a travs de la lnea de comandos y la enva mediante sucesivos comandos BOOT_CMD_WRITE_CODE al bootloader, quien la descifra y escribe en memoria Flash. Es necesario recordar que la memoria Flash debe ser borrada antes de ser programada por lo que antes de enviar los datos se calcula la cantidad de bloques de 64 bytes a borrar mediante la ecuacin 6.3 donde bb es el nmero de bloques a borrar y tp es el tamao del programa en bytes (tamao del chero de entrada). Despus se enva un comando BOOT_CMD_ERASE_CODE por cada 255 bloques (tamao mximo borrable en una sola transaccin debido a que ste se codica con un solo byte). Una vez comienza el envo de los datos del programa cifrados, las direcciones de destino se generan a partir del punto de entrada del rmware de aplicacin (0x800). Para obtener la mxima
125
velocidad y tal como se discuti anteriormente, se envan paquetes de 58 bytes de datos, que es el mximo permitido. Posteriormente reprograma el nmero de serie que tambin se le suministra por lnea de comandos mediante el mismo procedimiento de borradoprogramacin reemplazando as la cadena DAQ-0000 original, y reinicia el microcontrolador en modo de funcionamiento normal enviando el comando BOOT_CMD_RESET. Para reprogramar variables se necesita tambin la clave de cifrado, puesto que el bootloader espera el segmento de programa que se desea reescribir codicado con XTEA. Para ello, la clave XTEA est denida como constante en el programa lsymash. Finalmente, hay que aclarar que este programa est indicado nicamente para uso interno durante el proceso de programacin y que no es apto para la actualizacin del rmware por parte de un usuario. bb = tp 64 (6.3)
Herramienta resettool
La herramienta resttool enva el la cadena ASCII rstCmd al dispositivo a travs del endpoint 2 del HASP cuando est funcionando en modo normal para reiniciarlo en modo DFU. Esto resulta til para iniciar el proceso de actualizacin o para corregir un posible error al escribir el nmero de serie al llamar a lsymash.
126
CAPTULO 7
PRUEBAS
Con el n de vericar el correcto funcionamiento del sistema desarrolado, se realizan una serie de pruebas empleando la placa prototipo destinadas a probar la funcionalidad de cada una de las partes de que se compone. Estas pruebas se pueden clasicar en cuatro subapartados: Instalacin del dispositivo Prueba de sensores Prueba de HASP Prueba de actualizacin de rmware. Se han realizado pruebas en las siguientes mquinas: PC Porttil Ahtec Sense con procesador Intel Core 2 Duo a 2.4 GHz y 2 Gb de memoria RAM y Windows XP x64. PC Sobremesa clnico con procesador Intel Pentium 4 a 2 GHz, 1 Gb de memoria RAM y Windows XP Professional. PC Porttil LG S1 Pro Express Dual con procesador Intel Core 2 Duo T7600 a 2 GHz, 3 Gb de memoria RAM y Windows 7 beta. Apple MacBook Pro con procesador Intel Core 2 Duo a 2.66 GHz, 4 Gb de memoria RAM y Mac OS X Leopard. El dispositivo se detecta correctamente, se puede ver el estado de los sensores con la herramienta de calibracin de joystick de un juego. Pero el soporte HASP no est implementado para Mac OS X. PC Sobremesa Packard Bell Dot con procesador Intel Atom a 1.6 GHz, 1 Gb de RAM y Ubuntu Linux.
128
7.1. INSTALACIN DEL DISPOSITIVO
El comando lsusb muestra el dispositivo, con la herramienta jscal se puede ver el estado de los sensores, pero al igual que en Mac OS X no hay soporte HASP. Sistema PlayStation 3 El dispositivo es detectado y congurado. Se pueden controlar los mens con los sensores analgicos asignados al eje X y eje Y. El soporte HASP tampoco est implementado para este sistema. En los sistemas Windows se han ejecutado las cuatro pruebas con xito. En el resto de sistemas se han ejecutado la prueba de deteccin y la de lectura de sensores con las herramientas presentes para el sistema en cuestin.
7.1.
INSTALACIN DEL DISPOSITIVO
El objetivo de esta prueba es comprobar que distintas mquinas con distintos sistemas operativos detectan y conguran el dispositivo correctamente. Esto implica que el proceso de enumeracin se realice con xito y que la comunicacin entre dispositivo y host funcione adecuadamente. Al tratarse de un perifrico que pertenece a la clase HID, se espera que en la mayora de sistemas operativos se detecte y congure automticamente sin necesidad de instalar ningn software.
7.2.
PRUEBA DE SENSORES
A la placa prototipo se le han conectado diez pulsadores y diez potencimetros para poder comprobar su funcionamiento. Con la ayuda del panel de control de Windows, se utiliza la herramienta de calibracin de joysticks para ver el estado de cada sensor.
7.3.
PRUEBA HASP
Utilizando la librera libhw se implementa una aplicacin de prueba botonera que pone en funcionamiento el sistema e imprime por consola el nombre de cada mensaje que recibe a travs de la funcin de callback.
7.4.
ACTUALIZACIN DE FIRMWARE
Con la herramienta fwcrypt se cifra el archivo .HEX, resultado de la compilacin del rmware y con la herramienta lsymash se carga en el dispositivo. Tras la actualizacin correcta se verica que funciona correctamente. Se prueba la herramienta resettool para reinciar el dispositivo en modo DFU.
CAPTULO 7. PRUEBAS
129
Figura 7.1: Prueba de sensores
Figura 7.2: Prueba de sistema HASP
130
7.4. ACTUALIZACIN DE FIRMWARE
Figura 7.3: Prueba de actualizacin de mware con lsymash
CAPTULO 8
PRESUPUESTO
Para estimar el coste total del proyecto se han tenido en cuenta los gastos derivados tanto del software y hardware utilizado en su desarrollo, como de los materiales para la construccin del prototipo y el coste de los recursos humanos.
8.1.
COSTE DE LOS RECURSOS SOFTWARE
Durante el desarrollo del proyecto se han utilizado diversas herramientas software. Para el diseo del esquemtico y la placa de circuito impreso se ha utilizado el software Eagle, que en su versin de estudiante es gratuita. Aunque impone ciertas limitaciones que se nombraron en el captulo 3, estas no son relevantes para llevar a cabo el desarrollo con xito. Para la programacin del microcontrolador se ha utilizado CCS PCWH que requiere una licencia comercial, MPLAB IDE con MPASM que se distribuye de manera gratuita, y el compilador C18 que dispone tambin de una versin gratis para estudiantes. Para la programacin de la librera y herramientas en el PC se ha utilizado Visual C++ Express, se puede descargar sin ningn coste del sitio web de Microsoft, a pesar de tener ciertas limitaciones, estas no obstaculizan en absoluto el desarrollo del proyecto. El Windows Driver Development Kit es el kit de desarrollo de drivers para los sistemas operativos Windows de Microsoft y al igual que los programas anteriores es gratuito, pero en este caso sin limitaciones. Para el desarrollo de los descriptores HID se ha empleado el programa HID Descriptor Tool de USB-IF. Es una herramienta gratuita. Finalmente el sistema operativo utilizado es Windows XP x64 cuyo uso tambin requiere una licencia. Todos los precios incluyen el IVA. El resumen de costes derivados del software se muestra en la tabla 8.1.
132
8.2. COSTE DE LOS RECURSOS HARDWARE
Concepto Microchip MPLAB IDE Microchip MPASM Microchip C18 CCS PIC C PCWH USB-IF HID Descriptor Tool Eagle Microsoft Windows DDK Microsoft Visual C++ Express Microsoft Windows XP x64 Edition Total
Precio 0e 0e 0e 348.8 e 0e 0e 0e 0e 77.12 e 425.92 e
Cuadro 8.1: Costes de software
8.2.
COSTE DE LOS RECURSOS HARDWARE
En primer lugar se contabilizarn los recursos hardware necesarios para el desarrollo del software y los planos y esquemticos de la PCB, y en segundo lugar el material empleado para la construccin del prototipo.
Concepto PC Portatil 2.4 GHz 2Gb RAM Programador/Depurador MPLAB ICD 2 Total Cuadro 8.2: Costes de hardware I
Precio 760 e 325 e 1085 e
CAPTULO 8. PRESUPUESTO
133
Concepto Soldador de 40 W Rollo de estao de 0.5 mm Placa fotosensible positiva de 50 x 50 mm Taladro multifuncin tipo Dremel Multmetro digital Set de productos qumicos para insolado Insoladora casera de LEDs UV Pack de 10 hojas de transparentes A4 Array de resistencias 10 K (9 elementos) Resistencia 1K (pack de 10 unidades) Cristal de cuarzo de 4 MHz Microcontrolador PIC18F2550 SPDIP Tira de pines (40 pines) Zcalo DIP de 28 pines Conector USB hembra tipo B Condensador cermico 100 nF Condensador cermico 200 nF Condensador cermico 27 pF Conector de apriete (bloque de 10) Conector de apriete (bloque de 3) LED rojo de 1.5 mm Total
Cantidad 1 1 1 1 1 1 1 1 2 1 1 1 1 1 1 1 1 2 2 2 1
Precio unitario 26 e 8.95 e 16.90 e 69.95 e 15.52 e 15 e 35 e 9.67 e 0.19 e 0.99 e 0.96 e 8.71 e 0.48 e 0.17 e 0.40 e 0.13 e 0.13 e 0.08 e 0.63 e 0.30 e 0.08 e
Precio total 26 e 8.95 e 16.90 e 69.95 e 15.52 e 15 e 35 e 9.67 e 0.38 e 0.99 e 0.96 e 8.71 e 0.48 e 0.17 e 0.40 e 0.13 e 0.13 e 0.16 e 1.26 e 0.60 e 0.08 e 211.44 e
Cuadro 8.3: Costes de hardware II
8.3.
COSTE DE RECURSOS HUMANOS
Teniendo en cuenta el tiempo dedicado a cada tarea y la asignacin de las mismas, los costes asociados a los recursos humanos se muestran en la tabla 8.4. En esta estimacin no se han tenido en cuenta los nes de semana, se ha asumido una jornada laboral de 8 horas, y no se ha incluido la redaccin de la memoria.
Concepto Ingeniero Tcnico Total
Horas 912 72
Salario/hora 11.26 e 8e
Coste 10269.12 e 576 e 10845.12 e
Cuadro 8.4: Costes de recursos humanos
134
8.4. COSTE TOTAL
8.4.
COSTE TOTAL
La tabla 8.5 resume el coste total del proyecto. Concepto Recursos software Recursos hardware I Recursos hardware II Recursos humanos Total Coste 425.92 e 1085 e 211.44 e 10845.12 e 12567.48 e
Cuadro 8.5: Costes totales Hay que recordar que este es el coste total del desarrollo y fabricacin del prototipo, para su produccin en serie seran necesarios unos gastos iniciales derivados de la fabricacin de los PCBs y el coste unitario sera mucho menor.
CAPTULO 9
CONCLUSIONES Y TRABAJO FUTURO
9.1.
CONCLUSIONES
A la nalizacin del desarrollo, y tras comprobar los resultados se pueden concluir que se han cumplido los objetivos propuestos al inicio. El resultado obtenido ha sido un perifrico microcontrolado que muestrea pulsadores y potencimetros y enva esta informacin mediante USB. Es apto para su montaje dentro de paneles y mandos de control de maquinaria real para su uso con simuladores y otro software interactivo. El perifrico no requiere ninguna fuente de alimentacin externa, ni la instalacin de drivers para un sistema operativo especco, lo que lo hace multiplataforma. Adems de la lectura de sensores, el perifrico implementa un algoritmo de desafo-respuesta que permite detectar la presencia continuada del dispositivo con el n de servir como llave HASP para evitar la distribucin y uso ilegtimo de copias de un software junto con el que se distribuye. Se ha desarrollado una librera que oculta los detalles del hardware y mantiene informado al software protegido del estado de la proteccin, noticndole inmediatamente de eventos que afectan a la misma como la desconexin del dispositivo, o un error en el dilogo que mantiene con el host. El dispositivo es reprogramable in situ implementando los mecanismos necesarios para actualizar el cdigo que ejecuta el microcontrolador en el lugar donde habitualmente se utiliza sin tener que ser desmontado por un tcnico y sin romper la cadena de seguridad. Se han desarrollado tambin herramientas que permiten el cifrado del programa rmware y la mencionada reprogramacin. Este desarrollo ha sido posible gracias a la eleccin de los componentes adecuados que han permitido la fabricacin manual de una placa de las dimensiones requeridas, como el microcontrolador PIC18F2550 que incorpora en su encapsulado prcticamente la totalidad del hardware necesario para cumplir los objetivos del proyecto (mdulo USB, conversor A/D, resistencias de pull-up internas), minimizando as la circuitera externa necesaria, lo que impacta directamente en el tamao y el coste. La eleccin del bus USB como medio de interconexin ha resultado muy ventajosa puesto que suministra la alimentacin necesaria y ofrece una comunicacin robusta, rpida y exible entre host y
136
9.2. TRABAJO FUTURO
dispositivos. Se puede concluir tambin que si bien es cierto que USB aade un factor importante de complejidad respecto a predecesores como el RS-232, tambin lo s como se ha podido comprobar, que los fabricantes centran sus esfuerzos en proporcionar herramientas y hardware que aceleran y facilitan en gran medida el desarrollo de perifricos basados en este estndar. Esto repercute en un uso muy extendido del mismo, donde los usuarios ganan en sencillez gracias a caractersticas como Plug & Play y la existencia de distintas clases de dispositivos, y los desarrolladores ganan en tiempo invertido, permitindose obviar en gran medida estas complejidades y centrarse en su diseo. Por otro lado el coste de fabricacin por unidad justica el desarrollo del proyecto en lugar de implementar una solucin basada en una tarjeta de sensorizacin y una llave HASP.
9.2.
TRABAJO FUTURO
Se han cumplido los objetivos del proyecto, pero se observa que an hay ciertos aspectos susceptibles de mejora, que se proponen como trabajo futuro: Estudiar y mejorar las vulnerabilidades del algoritmo de validacin por desaforespuesta desarrollado y valorar su reemplazo por otro existente, o adpotar XTEA al igual que el bootloader. Mejorar la librera realizando la deteccin del dispositivo guiada por eventos, en lugar de enumerando peridicamente cuando no est conectado. Mejorar el diseo de la librera mediante el uso de plantillas. Disear un armazn para la distribucin de actualizaciones de rmware. Se propone el uso de un chero ZIP que proporciona un contenedor seguro con comprobacin de cdigo CRC, con la extensin cambiada y que contenga la imagen binaria cifrada y un archivo XML con informacin sobre las mejoras incluidas, el cdigo de versin y los PID de dispositivos compatibles. Disear una herramienta de actualizacin de rmware para el usuario. Se propone la implementacin como un plug-in para el navegador al estilo Windows Update, de forma que visitando una pgina web se detecten los dispositivos compatibles conectados, la versin de rmware de cada uno y mediante una consulta a un servidor determinar si existe una versin nueva, permitiendo su descarga y reprogramacin automticas. Disear una extensin como una placa hija que se conecte en el zcalo del microcontrolador reemplazando a este, y que contenga un sistema compuesto por un transceptor inalmbrico, un controlador de carga de batera, un microcontrolador y
CAPTULO 9. CONCLUSIONES Y TRABAJO FUTURO
137
un conector para una batera con el objetivo de permitir la comunicacin tanto sin cables como por USB, ofreciendo la posibilidad tambin de cargar la batera cuando est conectado.
138
9.2. TRABAJO FUTURO
APNDICE A
PLANOS Y FOTOLITOS
140
APNDICE A. PLANOS Y FOTOLITOS
141
A.1.
ESQUEMTICO DEL CIRCUITO
142
A.2. LISTADO DE COMPONENTES
A.2.
LISTADO DE COMPONENTES
Concepto Array de resistencias 10 K (9 elementos) Resistencia 1K (pack de 10 unidades) Cristal de cuarzo de 4 MHz Microcontrolador PIC18F2550 SPDIP Tira de pines (40 pines) Zcalo DIP de 28 pines Conector USB hembra tipo B Condensador cermico 100 nF Condensador cermico 200 nF Condensador cermico 27 pF Conector de apriete (bloque de 10) Conector de apriete (bloque de 3) LED rojo de 1.5 mm Cantidad 2 1 1 1 1 1 1 1 1 2 2 2 1
Cuadro A.1: Listado de componentes
143
A.3.
LAYOUT DEL PCB
Figura A.1: Layout: Capa Top y Componentes en rojo, Capa Bottom en verde
144
A.4. FOTOLITOS DEL PCB
A.4.
FOTOLITOS DEL PCB
Figura A.2: Fotolito: Cara Top
Figura A.3: Fotolito: Cara Botom
145
Figura A.4: Fotolito: Capa de componentes
146
A.4. FOTOLITOS DEL PCB
APNDICE B
ESPECIFICACIONES
148
B.1. ESPECIFICACIONES DEL DISPOSITIVO
B.1.
ESPECIFICACIONES DEL DISPOSITIVO
Dimensiones (mm) Tensin de alimentacin (V) Intensidad mxima (mA) Frecuencia del microprocesador (MHz) N. de pines Conexin Norma USB Clase de dispositivo Versin de clase Temperatura de funcionamiento (o C) Resolucin de muestreo (bits) Periodo de muestreo (ms) N. de entradas analgicas N. de entradas digitales Sistema HASP
58 x 38 x 18 5.0 100 48.0 26 USB hembra tipo B 2.0 HID 1.11 -40 - 85 10 10 10 10 Desafo-Respuesta
Cuadro B.1: Especicaciones del dispositivo
B.2.
PINOUT
Pin D 0-9 AD 0-9 VDD GND USB
Funcin Entradas digitales Entradas digitales/analgicas 5 V (100 mA) Tierra Conexin USB
Cuadro B.2: Especicaciones del dispositivo
APNDICE B. ESPECIFICACIONES
149
B.3.
IMGENES
Figura B.1: Fotografa del dispositivo
150
B.3. IMGENES
APNDICE C
LISTADOS DE CDIGO FUENTE
152
C.1. FIRMWARE DEL MICROCONTROLADOR
C.1. C.1.1.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
FIRMWARE DEL MICROCONTROLADOR lsred_main.c
# i n c l u d e <18 F2550 . h>
# b u i l d ( r e s e t =0 x800 , i n t e r r u p t =0 x808 ) / / B o o t l o a d e r remapped v e c t o r s # d e v i c e ADC=10 # o r g 0x89E , 0 x138F DEFAULT / / / / FULL SPEED # f u s e s HSPLL ,NOWDT, PROTECT , NOLVP,NODEBUG, USBDIV , PLL1 , CPUDIV1 , VREGEN,NOMCLR, CPB # u s e d e l a y ( c l o c k =4 8000 000 ) # d e f i n e USB_USE_FULL_SPEED TRUE / / LINE ADDED! ! / / SLOW SPEED # f u s e s HSPLL ,NOWDT, PROTECT , NOLVP,NODEBUG, USBDIV , PLL1 , CPUDIV3 , VREGEN, NOMCLR, CPB # u s e d e l a y ( c l o c k =2 4000 000 ) # d e f i n e USB_USE_FULL_SPEED FALSE
// // //
// / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / // / / CCS L i b r a r y dynamic d e f i n e s . F o r dynamic c o n f i g u r a t i o n o f t h e CCS L i b r a r y / / f o r y o u r a p p l i c a t i o n s e v e r a l d e f i n e s n e e d t o be made . See t h e comments / / a t u s b . h f o r more i n f o r m a t i o n // // / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / #DEFINE USB_HID_DEVICE TRUE / / T e l l s t h e CCS PIC USB f i r m w a r e / / t o i n c l u d e HID h a n d l i n g c o d e . / / t u r n on EP1 f o r IN i n t e r r u p t t r a n s f e r s . ( IN = PIC > PC ) # d e f i n e USB_EP1_TX_ENABLE USB_ENABLE_INTERRUPT # d e f i n e USB_EP1_TX_SIZE 23 / / max p a c k e t s i z e o f t h i s e n d p o i n t # d e f i n e USB_EP2_TX_ENABLE # d e f i n e USB_EP2_TX_SIZE 8 # d e f i n e USB_EP2_RX_ENABLE # d e f i n e USB_EP2_RX_SIZE 9 USB_ENABLE_INTERRUPT / / t u r n on EP2 f o r OUT b u l k / i n t e r r u p t t r a n s f e r s
USB_ENABLE_INTERRUPT
/ / t u r n on EP2 f o r IN b u l k / i n t e r r u p t t r a n s f e r s
/ / D e f i n e t h e p i n mapping // Digital # d e f i n e D0 # d e f i n e D1 # d e f i n e D2 # d e f i n e D3 # d e f i n e D4 # d e f i n e D5 # d e f i n e D6 # d e f i n e D7 # d e f i n e D8 # d e f i n e D9 / / Analog # d e f i n e AN0 # d e f i n e AN1 # d e f i n e AN2 # d e f i n e AN3 # d e f i n e AN4 # d e f i n e AN5 # d e f i n e AN6 # d e f i n e AN7 # d e f i n e AN8 # d e f i n e AN9
i n p u t ( PIN_E3 ) i n p u t ( PIN_A4 ) i n p u t ( PIN_C0 ) i n p u t ( PIN_C1 ) i n p u t ( PIN_C2 ) i n p u t ( PIN_C6 ) i n p u t ( PIN_C7 ) i n p u t ( PIN_B5 ) i n p u t ( PIN_B6 ) i n p u t ( PIN_B7 )
0 1 2 3 4 8 9 10 11 12
// / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / // / / I n c l u d e t h e CCS USB L i b r a r i e s . See t h e comments a t t h e t o p o f t h e s e / / f i l e s f o r more i n f o r m a t i o n // // / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / # i n c l u d e # i n c l u d e < l s r e d _ d e s c . h> # i n c l u d e <usb . c> / / # i n c l u d e <STRING . H> # i n c l u d e "LSYMCSVP . h " # d e f i n e UMBRAL_AD 700 / / M i c r o c h i p PIC18F25550 h a r d w a r e l a y e r f o r u s b . c / / USB C o n f i g u r a t i o n and D e v i c e d e s c r i p t o r s f o r t h i s UBS d e v i c e / / h a n d l e s u s b s e t u p t o k e n s and g e t d e s c r i p t o r r e p o r t s / / I m p l e m e n t a t i o n o f LSyM C h a l l e n g i n g S o f t w a r e V a l i d a t i o n P r o t o c o l / / L e v e l o f a n a l o g r e a d s from which t h e c o r r e s p o n d i n g d i g i t a l p i n may be s e t t o 1
APNDICE C. LISTADOS DE CDIGO FUENTE
153
79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162
# d e f i n e DELAY_AD_US 400
/ / A/D C o n v e r s o r d e l a y r e q u i r e d t i m e
/ / Data b u f f e r s s t a t i c int8 out_data [23]; static int8 data_buffer [9]; s t a t i c i n t 1 6 sample ;
/ / Buffer for c o n t r o l l e r data / / B u f f e r f o r HASP / / B uf fer f o r c u r r e n t sample
int i ; c o n s t c h a r r s t M s g [ ] = " rstCmd " ; c o n s t i n t 8 s e n s o r _ l u t [ ] = {AN0 , AN1 , AN2 , AN3 , AN4 , AN5 , AN6 , AN7 , AN8 , AN9 } ; / Checks t h e " u m b r a l " v a l u e from a A/D c o n v e r s i o n f o r a g i v e n s a m p l e and c h a n n e l and s e t s t h e c o r r e s p o n d i n g d i g i t a l p i n s t a t u s / v o i d EvaluarAD ( u n s i g n e d c h a r c a n a l , i n t 1 6 m u e s t r a ) { unsigned char condicion ; c o n d i c i o n = ( m u e s t r a <= UMBRAL_AD) ; switch ( canal ) { c a s e AN0 : out_data [21] break ; c a s e AN1 : out_data [21] break ; c a s e AN2 : out_data [21] break ; c a s e AN3 : out_data [21] break ; c a s e AN4 : out_data [21] break ; c a s e AN5 : out_data [21] break ; c a s e AN6 : out_data [22] break ; c a s e AN7 : out_data [22] break ; c a s e AN8 : out_data [22] break ; c a s e AN9 : out_data [22] break ; } } / Performs the a c t u a l reading of t r a n s d u c e r s / void sensorTask ( void ) { int8 i , j ; / / Clear the output buffer f o r ( i = 0 ; i < 2 3 ; i ++) o u t _ d a t a [ i ] = 0 x0 ; f o r ( i =0 , j = 0 ; i < 1 0 ; i ++) { set_adc_channel ( sensor_lut [ i ]) ; r e a d _ a d c (ADC_START_ONLY) ; d e l a y _ u s (DELAY_AD_US) ; s a m p l e = r e a d _ a d c (ADC_READ_ONLY) ; o u t _ d a t a [ j ] = s a m p l e & 0 x00FF ; o u t _ d a t a [ j ++] = ( s a m p l e & 0 x300 ) >> 8 ; EvaluarAD ( AN0 , s a m p l e ) ; } out_data [20] out_data [20] out_data [20] out_data [20] out_data [20] out_data [20] |= |= |= |= |= |= ( ~ D0&0x1 ) ; ( ~ D1&0x1 ) << ( ~ D2&0x1 ) << ( ~ D3&0x1 ) << ( ~ D4&0x1 ) << ( ~ D5&0x1 ) <<
| = c o n d i c i o n << 2 ;
| = c o n d i c i o n << 3 ;
| = c o n d i c i o n << 4 ;
| = c o n d i c i o n << 5 ;
| = c o n d i c i o n << 6 ;
| = c o n d i c i o n << 7 ;
|= condicion ;
| = c o n d i c i o n << 1 ;
| = c o n d i c i o n << 2 ;
| = c o n d i c i o n << 3 ;
1; 2; 3; 4; 5;
154
163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222
out_data [20] |= out_data [20] |= out_data [21] |= out_data [21] |=
( ~ D6&0x1 ) << 6 ; ( ~ D7&0x1 ) << 7 ; ( ~ D8&0x1 ) ; ( ~ D9&0x1 ) << 1 ;
u s b _ p u t _ p a c k e t ( 1 , o u t _ d a t a , 2 3 , USB_DTS_TOGGLE ) ; } / P e r f o r m s t h e i n i t i a l p o r t and AD c o n v e r t e r c o n f i g u r a t i o n o f t h e PIC18F2550 / void s e n s o r I n i t ( void ) { SET_TRIS_A ( 0 b10111111 ) ; SET_TRIS_B ( 0 b11111111 ) ; SET_TRIS_C ( 0 b11000111 ) ; PORT_B_PULLUPS (TRUE) ; s e t u p _ a d c _ p o r t s (ALL_ANALOG) ; s e t u p _ a d c (ADC_CLOCK_INTERNAL) ; set_adc_channel (0) ; } / P e r f o r m s t h e HASP t a s k / v o i d HASPTask ( v o i d ) { usb_get_packet (2 , data_buffer , 9) ; / / Get t h e d a t a from t h e PIC s d u a l p o r t ram f o r ( i = 0 ; i < 6 ; i ++) i f ( rstMsg [ i ] != d a t a _ b u f f e r [ i ] ) goto hasp ; #asm g o t o 0 x0016 ; Bootloader entry point # endasm hasp : s i g n ( ( ptrWord ) d a t a _ b u f f e r ) ; / / Sign the s t r i n g u s b _ p u t _ p a c k e t ( 2 , d a t a _ b u f f e r , 8 , USB_DTS_TOGGLE ) ; / / Send b a c k t h e s i g n e d s t r i n g } / Firmware e n t r y p o i n t / v o i d main ( v o i d ) { // s p r i n t f ( r e s e t M s g " cmdRst " ) ; / / Configure pins / / I n i t USB l i b r a r y / / I n i t HASP a l g o r i t h m
sensorInit () ; usb_init_cs () ; hasp_init () ;
w h i l e (TRUE) { / / Loop f o r e v e r usb_task () ; / / Do t h e USB t a s k i f ( usb_enumerated ( ) ) { sensorTask ( ) ; / / Perform the s enso r t a s k i f ( u s b _ k b h i t ( 2 ) ) { / / I f t h e r e i s any c h a l l e n g i n g s t r i n g a w a i t i n g f o r s i g n i n g HASPTask ( ) ; / / we p r o c e s s and s e n d i t b a c k } } delay_ms ( 4 ) ; / / A l i t t l e d e l a y t o a r c h i e v e 10ms } }
...
C.1.2.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
lsred_desc.h
#IFNDEF __USB_DESCRIPTORS__ #DEFINE __USB_DESCRIPTORS__ # i n c l u d e // // // // // // // // // //////////////////////////////////////////////////////////////// / / HID R e p o r t . T e l l s HID d r i v e r how t o h a n d l e and d e a l w i t h / r e c e i v e d d a t a . HID R e p o r t s c a n be e x t r e m e l y complex , / s e e HID s p e c i f c a t i o n f o r h e l p on w r i t i n g y o u r own . / / Gamepad : 10 a x i s 20 b u t t o n s / Vendors p e c i f i c HID D e v i c e : LSyM HASP key ////////////////////////////////////////////////////////////////
c o n s t c h a r USB_CLASS_SPECIFIC_DESC [ ] = { 0 x05 , 0 x01 , / / USAGE_PAGE ( G e n e r i c D e s k t o p ) / / 0 , 1
155
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101
0 x09 , 0 x05 , / / USAGE ( Game Pad ) / / 2 , 3 0 xa1 , 0 x01 , / / COLLECTION ( A p p l i c a t i o n ) / / 4 , 5 0 xa1 , 0 x00 , // COLLECTION ( P h y s i c a l ) / / 6 , 7 0 x09 , 0 x30 , // USAGE (X) / / 8 , 9 0 x09 , 0 x31 , // USAGE (Y) / / 1 0 , 1 1 0 x09 , 0 x32 , // USAGE ( Z ) / / 1 2 , 1 3 0 x09 , 0 x33 , // USAGE ( Rx ) / / 1 4 , 1 5 0 x09 , 0 x34 , // USAGE ( Ry ) / / 1 6 , 1 7 0 x09 , 0 x35 , // USAGE ( Rz ) / / 1 8 , 1 9 0 x09 , 0 x38 , // USAGE ( Wheel ) / / 2 0 , 2 1 0 x09 , 0 x36 , // USAGE ( S l i d e r ) / / 2 2 , 2 3 0 x15 , 0 x00 , // LOGICAL_MINIMUM ( 0 ) / / 2 4 , 2 5 0 x26 , 0 x f f , 0 x03 , // LOGICAL_MAXIMUM ( 1 0 2 3 ) / / 2 6 , 2 7 , 2 8 0 x75 , 0 x10 , // REPORT_SIZE ( 1 6 ) / / 2 9 , 3 0 0 x95 , 0 x08 , // REPORT_COUNT ( 8 ) / / 3 1 , 3 2 0 x81 , 0 x02 , // INPUT ( Data , Var , Abs ) / / 3 3 , 3 4 0 x05 , 0 x02 , // USAGE_PAGE ( S i m u l a t i o n C o n t r o l s ) / / 3 5 , 3 6 0 x09 , 0 xbb , // USAGE ( T h r o t t l e ) / / 3 7 , 3 8 0 x09 , 0 xc5 , // USAGE ( B r a k e ) / / 3 9 , 4 0 0 x15 , 0 x00 , // LOGICAL_MINIMUM ( 0 ) / / 4 1 , 4 2 0 x26 , 0 x f f , 0 x03 , // LOGICAL_MAXIMUM ( 1 0 2 3 ) / / 4 3 , 4 4 , 4 5 0 x75 , 0 x10 , // REPORT_SIZE ( 1 6 ) / / 4 6 , 4 7 0 x95 , 0 x02 , // REPORT_COUNT ( 2 ) / / 4 8 , 4 9 0 x81 , 0 x02 , // INPUT ( Data , Var , Abs ) / / 5 0 , 5 1 0 x05 , 0 x09 , // USAGE_PAGE ( B u t t o n ) / / 5 2 , 5 3 0 x19 , 0 x01 , // USAGE_MINIMUM ( B u t t o n 1 ) / / 5 4 , 5 5 0 x29 , 0 x14 , // USAGE_MAXIMUM ( B u t t o n 2 0 ) / / 5 6 , 5 7 0 x15 , 0 x00 , // LOGICAL_MINIMUM ( 0 ) / / 5 8 , 5 9 0 x25 , 0 x01 , // LOGICAL_MAXIMUM ( 1 ) / / 6 0 , 6 1 0 x75 , 0 x01 , // REPORT_SIZE ( 1 ) / / 6 2 , 6 3 0 x95 , 0 x14 , // REPORT_COUNT ( 2 0 ) / / 6 4 , 6 5 0 x81 , 0 x02 , // INPUT ( Data , Var , Abs ) / / 6 6 , 6 7 0 x95 , 0 x04 , // REPORT_COUNT ( 4 ) / / 6 8 , 6 9 0 x81 , 0 x03 , // INPUT ( Cnst , Var , Abs ) / / 7 0 , 7 1 0 xc0 , // END_COLLECTION / / 72 0 xc0 , / / END_COLLECTION / / 73 / / HID r e p o r t d e s c r i p t o r f o r LSYM HASP d e v i c e 0 x06 , 0 x00 , 0 x f f , / / USAGE_PAGE ( Vendor D e f i n e d Page 1 ) / / 7 4 , 7 5 , 7 6 0 x09 , 0 x01 , / / USAGE ( Vendor Usage 1 ) / / 7 7 , 7 8 0 xa1 , 0 x01 , / / COLLECTION ( A p p l i c a t i o n ) / / 7 9 , 8 0 0 x19 , 0 x01 , // USAGE_MINIMUM ( Vendor Usage 1 ) / / 8 1 , 8 2 0 x29 , 0 x01 , // USAGE_MAXIMUM ( Vendor Usage 1 ) / / 8 3 , 8 4 0 x15 , 0 x00 , // LOGICAL_MINIMUM ( 0 ) / / 8 5 , 8 6 0 x26 , 0 x f f , 0 x00 , // LOGICAL_MAXIMUM ( 2 5 5 ) / / 8 7 , 8 8 , 8 9 0 x75 , 0 x08 , // REPORT_SIZE ( 8 ) / / 9 0 , 9 1 0 x95 , 0 x08 , // REPORT_COUNT ( 8 ) / / 9 2 , 9 3 0 x81 , 0 x02 , // INPUT ( Data , Var , Abs ) / / 9 4 , 9 5 0 x19 , 0 x01 , // USAGE_MINIMUM ( Vendor Usage 1 ) / / 9 6 , 9 7 0 x29 , 0 x01 , // USAGE_MAXIMUM ( Vendor Usage 1 ) / / 9 8 . 9 9 0 x15 , 0 x00 , // LOGICAL_MINIMUM ( 0 ) / / 1 0 0 , 1 0 1 0 x26 , 0 x f f , 0 x00 , // LOGICAL_MAXIMUM ( 2 5 5 ) / / 1 0 2 , 1 0 3 , 1 0 4 0 x75 , 0 x08 , // REPORT_SIZE ( 8 ) / / 1 0 5 , 1 0 6 0 x95 , 0 x09 , // REPORT_COUNT ( 9 ) / / 1 0 7 , 1 0 8 0 x91 , 0 x02 , // OUTPUT ( Data , Var , Abs ) / / 1 0 9 , 1 1 0 0 xc0 / / END_COLLECTION / / 111 } ; / / T o t a l : 112 / / i f a c l a s s h a s an e x t r a d e s c r i p t o r n o t p a r t o f t h e c o n f i g d e s c r i p t o r , / / t h i s l o o k u p t a b l e d e f i n e s where t o l o o k f o r i t i n t h e c o n s t / / USB_CLASS_SPECIFIC_DESC [ ] a r r a y . / / f i r s t e l e m e n t i s t h e c o n f i g number ( i f y o u r d e v i c e h a s more t h a n one c o n f i g ) / / s e c o n d e l e m e n t i s which i n t e r f a c e number / / s e t e l e m e n t t o 0xFFFF i f t h i s c o n f i g / i n t e r f a c e combo d o e s n t e x i s t c o n s t i n t 1 6 USB_CLASS_SPECIFIC_DESC_LOOKUP [USB_NUM_CONFIGURATIONS ] [ 2 ] = { / / config 1 // interface 0 0, // interface 1 74 }; / / i f a c l a s s h a s an e x t r a d e s c r i p t o r n o t p a r t o f t h e c o n f i g d e s c r i p t o r , / / t h i s lookup t a b l e d e f i n e s the s i z e of t h a t d e s c r i p t o r . / / f i r s t e l e m e n t i s t h e c o n f i g number ( i f y o u r d e v i c e h a s more t h a n one c o n f i g ) / / s e c o n d e l e m e n t i s which i n t e r f a c e number / / s e t e l e m e n t t o 0xFFFF i f t h i s c o n f i g / i n t e r f a c e combo d o e s n t e x i s t c o n s t i n t 1 6 USB_CLASS_SPECIFIC_DESC_LOOKUP_SIZE [USB_NUM_CONFIGURATIONS ] [ 2 ] = { / / config 1 // interface 0 74 , // interface 1 38
156
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184
// };
s i z e o f ( USB_CLASS_SPECIFIC_DESC )
// // // // // // //
/// / / / / / ///
///////////////////////////////////////////////////////////// s t a r t config descriptor r i g h t now we o n l y s u p p o r t one c o n f i g u r a t i o n d e s c r i p t o r . t h e c o n f i g , i n t e r f a c e , c l a s s , and e n d p o i n t g o e s i n t o t h i s a r r a y . ///////////////////////////////////////////////////////////// 66 / / c o n f i g + i n t e r f a c e + c l a s s + e n d p o i n t
#DEFINE USB_TOTAL_CONFIG_LEN
c o n s t c h a r USB_CONFIG_DESC [ ] = { / / IN ORDER TO COMPLY WITH WINDOWS HOSTS , THE ORDER OF THIS ARRAY MUST BE : // config ( s ) // interface (s) // c l a s s ( es ) // endpoint ( s ) / / c o n f i g _ d e s c r i p t o r for config index 1 USB_DESC_CONFIG_LEN , / / l e n g t h o f d e s c r i p t o r s i z e ==1 USB_DESC_CONFIG_TYPE , / / c o n s t a n t CONFIGURATION ( CONFIGURATION 0 x02 ) ==2 USB_TOTAL_CONFIG_LEN , 0 , / / s i z e o f a l l d a t a r e t u r n e d f o r t h i s c o n f i g ==3 ,4 2 , / / number o f i n t e r f a c e s t h i s d e v i c e s u p p o r t s ==5 0 x01 , / / i d e n t i f i e r f o r t h i s c o n f i g u r a t i o n . ( I F we had more t h a n one c o n f i g u r a t i o n s ) ==6 0 x00 , / / i n d e x o f s t r i n g d e s c r i p t o r f o r t h i s c o n f i g u r a t i o n ==7 0xC0 , / / b i t 6=1 i f s e l f powered , b i t 5=1 i f s u p p o r t s r e m o t e wakeup ( we don t ) , b i t s 04 u n u s e d and b i t 7 =1 ==8 0 x32 , / / maximum b u s power r e q u i r e d ( maximum m i l l i a m p e r e s / 2 ) ( 0 x32 = 100mA) // interface descriptor 1 USB_DESC_INTERFACE_LEN , / / l e n g t h o f d e s c r i p t o r =10 USB_DESC_INTERFACE_TYPE , / / c o n s t a n t INTERFACE ( INTERFACE 0 x04 ) =11 0 x00 , / / number d e f i n i n g t h i s i n t e r f a c e ( I F we had more t h a n one i n t e r f a c e ) 0 x00 , / / a l t e r n a t e s e t t i n g ==13 1 , / / number o f e n d p o i n s , e x c e p t 0 . ==14 0 x03 , / / c l a s s code , 03 = HID ==15 0 x00 , / / s u b c l a s s c o d e / / b o o t ==16 0 x00 , / / p r o t o c o l c o d e ==17 0 x02 , / / i n d e x o f s t r i n g d e s c r i p t o r f o r i n t e r f a c e ==18 / / c l a s s d e s c r i p t o r 1 ( HID ) USB_DESC_CLASS_LEN , / / l e n g t h o f d e s c r i p t o r ==19 USB_DESC_CLASS_TYPE , / / d s c r i p t o r t y p e ( 0 x21 == HID ) ==20 0 x10 , 0 x01 , / / h i d c l a s s r e l e a s e number ( 1 . 0 ) ==21 ,22 0 x00 , / / l o c a l i z e d c o u n t r y c o d e ( 0 = none ) ==23 0 x01 , / / number o f h i d c l a s s d e s c r p t o r s t h a t f o l l o w ( 1 ) ==24 0 x22 , / / r e p o r t d e s c r i p t o r t y p e ( 0 x22 == HID ) ==25 USB_CLASS_SPECIFIC_DESC_LOOKUP_SIZE [ 0 ] [ 0 ] , 0 x00 , / / l e n g t h o f r e p o r t d e s c r i p t o r
==12
==26 ,27
/ / endpoint descriptor USB_DESC_ENDPOINT_LEN , / / l e n g t h o f d e s c r i p t o r ==28 USB_DESC_ENDPOINT_TYPE , / / c o n s t a n t ENDPOINT ( ENDPOINT 0 x05 ) ==29 0 x81 , / / e n d p o i n t number and d i r e c t i o n ( 0 x81 = EP1 IN ) ==30 USB_ENDPOINT_TYPE_INTERRUPT , / / t r a n s f e r t y p e s u p p o r t e d ( 0 x03 i s i n t e r r u p t ) ==31 USB_EP1_TX_SIZE , 0 x00 , / / maximum p a c k e t s i z e s u p p o r t e d ==32 ,33 10 , / / p o l l i n g i n t e r v a l , i n ms . ( c a n t be s m a l l e r t h a n 10 f o r s l o w s p e e d d e v i c e s ) ==34 / / i n t e r f a c e d e s c r i p t o r 2 ( HASP ) USB_DESC_INTERFACE_LEN , / / l e n g t h o f d e s c r i p t o r =34 USB_DESC_INTERFACE_TYPE , / / c o n s t a n t INTERFACE ( INTERFACE 0 x04 ) =35 0 x01 , / / number d e f i n i n g t h i s i n t e r f a c e ( I F we had more t h a n one i n t e r f a c e ) ==36 0 x00 , / / a l t e r n a t e s e t t i n g ==37 2 , / / number o f e n d p o i n t s f o r t h i s i n t e r f a c e //38 0 x03 , / / c l a s s code , 03 = HID ==39 0 x00 , / / s u b c l a s s c o d e / / b o o t ==40 0 x00 , / / p r o t o c o l c o d e ( k e y b o a r d ) ==41 0 x03 , / / i n d e x o f s t r i n g d e s c r i p t o r f o r i n t e r f a c e ==42 / / c l a s s d e s c r i p t o r 2 ( HID ) USB_DESC_CLASS_LEN , / / l e n g t h o f d e s c r i p t o r ==43 USB_DESC_CLASS_TYPE , / / d s c r i p t o r t y p e ( 0 x21 == HID ) ==44 0 x10 , 0 x01 , / / h i d c l a s s r e l e a s e number ( 1 . 0 ) ==45 ,46 0 x00 , / / l o c a l i z e d c o u n t r y c o d e ( 0 = none ) ==47 0 x01 , / / number o f h i d c l a s s d e s c r p t o r s t h a t f o l l o w ( 1 ) ==48 0 x22 , / / r e p o r t d e s c r i p t o r t y p e ( 0 x22 == HID ) ==49 USB_CLASS_SPECIFIC_DESC_LOOKUP_SIZE [ 0 ] [ 1 ] , 0 x00 , / / l e n g t h o f r e p o r t d e s c r i p t o r ==50 ,51 / / e n d p o i n t d e s c r i p t o r 2 IN USB_DESC_ENDPOINT_LEN , / / l e n g t h o f d e s c r i p t o r ==52 USB_DESC_ENDPOINT_TYPE , / / c o n s t a n t ENDPOINT ( ENDPOINT 0 x05 ) ==53 0 x82 , / / e n d p o i n t number and d i r e c t i o n ( 0 x82 = EP2 IN ) ==54 USB_ENDPOINT_TYPE_INTERRUPT , / / t r a n s f e r t y p e s u p p o r t e d ( 0 x03 i s i n t e r r u p t ) ==55 USB_EP2_TX_SIZE , 0 x00 , / / maximum p a c k e t s i z e s u p p o r t e d ==56 ,57
157
185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268
10 , / / p o l l i n g i n t e r v a l , i n ms . ( c a n t be s m a l l e r t h a n 10 f o r s l o w s p e e d d e v i c e s ) / / e n d p o i n t d e s c r i p t o r 2 OUT USB_DESC_ENDPOINT_LEN , / / l e n g t h o f d e s c r i p t o r ==52 USB_DESC_ENDPOINT_TYPE , / / c o n s t a n t ENDPOINT ( ENDPOINT 0 x05 ) ==53 0 x02 , / / e n d p o i n t number and d i r e c t i o n ( 0 x02 = EP2 OUT) ==54 USB_ENDPOINT_TYPE_INTERRUPT , / / t r a n s f e r t y p e s u p p o r t e d ( 0 x03 i s i n t e r r u p t ) USB_EP2_RX_SIZE , 0 x00 , / / maximum p a c k e t s i z e s u p p o r t e d ==56 ,57 10 / / p o l l i n g i n t e r v a l , i n ms . ( c a n t be s m a l l e r t h a n 10 f o r s l o w s p e e d d e v i c e s ) };
==58
==55 ==58
/ / BEGIN CONFIG DESCRIPTOR LOOKUP TABLES / / s i n c e we c a n t make p o i n t e r s t o c o n s t a n t s i n c e r t a i n p i c 1 6 s , t h i s i s an o f f s e t t a b l e t o f i n d / / a s p e c i f i c d e s c r i p t o r i n t h e above t a b l e . / / NOTE : DO TO A LIMITATION OF THE CCS CODE, ALL HID INTERFACES MUST START AT 0 AND BE SEQUENTIAL // FOR EXAMPLE, I F YOU HAVE 2 HID INTERFACES THEY MUST BE INTERFACE 0 AND INTERFACE 1 # d e f i n e USB_NUM_HID_INTERFACES 2 / / t h e maximum number o f i n t e r f a c e s s e e n on any c o n f i g / / f o r example , i f c o n f i g 1 h a s 1 i n t e r f a c e and c o n f i g 2 h a s 2 i n t e r f a c e s you must d e f i n e t h i s a s 2 # d e f i n e USB_MAX_NUM_INTERFACES 2 / / d e f i n e how many i n t e r f a c e s t h e r e a r e p e r c o n f i g . [0] i s the f i r s t config , etc . c o n s t c h a r USB_NUM_INTERFACES [USB_NUM_CONFIGURATIONS ] = { 2 } ; / / d e f i n e where t o f i n d c l a s s d e s c r i p t o r s / / f i r s t d i m e n s i o n i s t h e c o n f i g number / / s e c o n d d i m e n s i o n s p e c i f i e s which i n t e r f a c e / / l a s t d i m e n s i o n s p e c i f i e s which c l a s s i n t h i s i n t e r f a c e t o g e t , b u t most w i l l o n l y h a v e 1 c l a s s p e r i n t e r f a c e / / i f a c l a s s d e s c r i p t o r i s n o t v a l i d , s e t t h e v a l u e t o 0xFFFF c o n s t i n t 1 6 USB_CLASS_DESCRIPTORS [USB_NUM_CONFIGURATIONS ] [ 2 ] [ 1 ] = { / / config 1 // interface 0 // class 1 18 , // interface 1 // class 1 43 };
# i f ( s i z e o f ( USB_CONFIG_DESC ) ! = USB_TOTAL_CONFIG_LEN ) # e r r o r USB_TOTAL_CONFIG_LEN n o t d e f i n e d c o r r e c t l y # endif
// / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / // / // / s t a r t device d e s c r i p t o r s // / // / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / #ORG 0 x2700 c o n s t c h a r USB_DEVICE_DESC [ ] = { / / s t a r t s o f w i t h d e v i c e c o n f i g u r a t i o n . o n l y one p o s s i b l e USB_DESC_DEVICE_LEN , / / t h e l e n g t h o f t h i s r e p o r t ==1 0 x01 , / / t h e c o n s t a n t DEVICE ( DEVICE 0 x01 ) ==2 0 x00 , 0 x02 , / / u s b v e r s i o n i n bcd ( 2 . 0 ) ==3 ,4 0 x00 , / / c l a s s c o d e ==5 0 x00 , / / s u b c l a s s c o d e ==6 0 x00 , / / p r o t o c o l c o d e ==7 USB_MAX_EP0_PACKET_LENGTH , / / max p a c k e t s i z e f o r e n d p o i n t 0 . (SLOW SPEED SPECIFIES 8 ) ==8 0xD8 , 0 x04 , / / v e n d o r i d ( 0 x04D8 i s M i c r o c h i p ) 0 x02 , 0 xF0 , / / p r o d u c t i d ==11 ,12 / / don t u s e f f f f s a y s usbbye x a m p l e guy . o o p s 0 x00 , 0 x02 , / / d e v i c e r e l e a s e number ==13 ,14 0 x01 , / / i n d e x o f s t r i n g d e s c r i p t i o n o f m a n u f a c t u r e r . t h e r e f o r e we p o i n t t o s t r i n g _ 1 a r r a y ( s e e below ) 0 x02 , / / i n d e x o f s t r i n g d e s c r i p t o r o f t h e p r o d u c t ==16 0 x04 , / / i n d e x o f s t r i n g d e s c r i p t o r o f s e r i a l number ==17 USB_NUM_CONFIGURATIONS / / number o f p o s s i b l e c o n f i g u r a t i o n s ==18 }; # i f ( s i z e o f ( USB_DEVICE_DESC ) ! = USB_DESC_DEVICE_LEN ) # e r r o r USB_DESC_DEVICE_LEN n o t d e f i n e d c o r r e c t l y # endif
==15
// // // // // //
/// / / / / ///
///////////////////////////////////////////////////////////// start string descriptors S t r i n g 0 i s a s p e c i a l l a n g u a g e s t r i n g , and must be d e f i n e d . /////////////////////////////////////////////////////////////
People i n U. S .A. can l e a v e t h i s a l o n e .
158
C.2. LIBRERA LIBHW
269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337
/ / the o f f s e t of the s t a r t i n g l o c a t i o n of each s t r i n g . string 1 , etc . c o n s t c h a r USB_STRING_DESC_OFFSET [ ] = { 0 , 4 , 1 4 , 4 4 , 7 8 } ;
o f f s e t [0 ] i s the s t a r t of s t r i n g 0 , o f f s e t [1 ] i s the s t a r t of
/ / number o f s t r i n g s you have , i n c l u d i n g s t r i n g 0 . # d e f i n e USB_STRING_DESC_COUNT s i z e o f ( USB_STRING_DESC_OFFSET ) #ORG 0x7CA2 , 0x7D2F c h a r c o n s t USB_STRING_DESC [ ] = { // string 0 4 , / / length of s t r i n g index USB_DESC_STRING_TYPE , / / d e s c r i p t o r t y p e 0 x03 ( STRING ) 0 x09 , 0 x04 , / / M i c r o s o f t D e f i n e d f o r US E n g l i s h // string 1 10 , / / l e n g t h of s t r i n g index USB_DESC_STRING_TYPE , / / d e s c r i p t o r t y p e 0 x03 ( STRING ) L , 0 , S ,0 , y ,0 , M , 0 // string 2 30 , / / l e n g t h of s t r i n g index USB_DESC_STRING_TYPE , / / d e s c r i p t o r t y p e 0 x03 ( STRING ) L , 0 , S ,0 , y ,0 , M , 0 , ,0 , D , 0 , A , 0 , Q , 0 , ,0 , B , 0 , o ,0 , a ,0 , r ,0 , d ,0 // string 3 34 , USB_DESC_STRING_TYPE , L , 0 , S ,0 , y ,0 , M , 0 , ,0 , H , 0 , A , 0 , S ,0 , P ,0 , ,0 , D , 0 , e ,0 , v ,0 , i ,0 , c ,0 , e ,0 // string 4 18 , USB_DESC_STRING_TYPE , D , 0 , A , 0 , Q , 0 , , 0 , 0 ,0 , 0 ,0 , 0 ,0 , 0 ,0 }; # o r g 0 x1390 , 0x1AFF DEFAULT
C.2.
LIBRERA LIBHW
Debido a la gran cantidad de cdigo existente entre librera y herramientas complementarias se muestra slo el cdigo fuente de los archivos de cabecera que denen cada capa. El cdigo fuente completo de todo el proyecto se encuentra en soporte digital en el
159
CD adjunto.
C.2.1.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 // // // // //
libhw.h
/////////////////////////////////// / / \ f i l e libhw . h / / \ b r i e f Main h e a d e r f i l e d e f i n i n g t h e l i b h w namespace , a l l i t s c l a s s e s and d a t a t y p e s and i n c l u d i n g t h e c l a s s d e f i n i t i o n headers / / / \ a u t h o r M i g u e l Angel E x p o s i t o S a n c h e z (LSYM) < miexsan@alumni . uv . es > // / // / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / # i f n d e f libhwH # d e f i n e libhwH / / # i n c l u d e <windows . h> # include # include # include # include # include " Protocol . h" " Driver . h" "LSYMCSVP . h " "LSYMHASPD2 . h " "LSYMHASP . h "
/ C O N S T A N T S / / Some c o n s t a n t s / # d e f i n e LSYM_VENDOR_ID 0x04D8 / / / < Vendor ID we u s e from M i c r o c h i p T e c h n o l o g y , I n c . namespace libhw { / / F o r w a r d d e c l a r a t i o n s t o s p e e dup c o m p i l e t i m e t y p e d e f v o i d LIBHWCALLBACK; / / / < The r e t u r n t y p e f o r u s e r c a l l b a c k f u n c t i o n s class Driver ; / / / < The d r i v e r l a y e r i n t e r f a c e class Protocol ; / / / < The p r o t o c o l l a y e r i n t e r f a c e c l a s s LSYMHASP ; / / / < The HASP l a y e r i m p l e m e n t a t i o n c l a s s LSYMHASPD2 ; / / / < The LSyM HASP D r i v e r f o r model 2 b o a r d s c l a s s c l a s s LSYMCSVP ; / / / < The LSyM C h a l l e n g i n g S o f t w a r e V a l i d a t i o n P r o t o c o l c l a s s class libhwException ; / / / < E x c e p t i o n s t h a t c a n be t h r o w n by l i b h w }; # endif
C.2.2.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 // // // // // // // // / / / / / / / /
Driver.h
////////////////////////////////// \ f i l e Driver . h \ b r i e f D e f i n i t i o n o f t h e d r i v e r i n t e r f a c e t h a t must be i m p l e m e n t e d i n a l l d r i v e r s f o r LSyM p r o d u c t s \ a u t h o r M i g u e l Angel E x p o s i t o S a n c h e z (LSYM) < miexsan@alumni . uv . es > //////////////////////////////////////
# i f n d e f DriverH # d e f i n e DriverH / / # i n c l u d e " libhw . h" namespace libhw { / \ class Driver \ s e c t i o n d e v e l o p e r s Use I n o r d e r t o make a d r i v e r you must i m p l e m e n t a l l m e t h o d s i n t h i s i n t e r f a c e . / class Driver { f r i e n d c l a s s LSYMHASP ; public :
160
C.2. LIBRERA LIBHW
29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
D r i v e r ( ) : s t a t e (UNENUM) {} ~ D r i v e r ( ) {} / D r i v e r s i n t e r n a l s t a t e m a c h i n e / enum D r i v e r S t a t e {UNENUM, ENUMERATING, OK, DRVERROR };
/ / /< Class constructor / / /< Class d e s t r u c t o r
// // // //
/< /< /< /<
The d e v i c e i s n o t e n u m e r a t e d The d e v i c e i s b e i n g e n u m e r a t e d D e v i c e e n u m e r a t e d and r u n n i n g Driver error
s t a t i c const unsigned char productIDL ; / / / < P r o d u c t ID s LSB s t a r t i n g v a l u e s t a t i c c o n s t unsigned char productIDH ; / / / < P r o d u c t D s MSB s t a r t i n g v a l u e protected : s t a t i c c o n s t i n t oLen ; / / / < Output b u f f e r l e n g t h in bytes s t a t i c c o n s t i n t iLen ; / / /< Input buffer length in bytes DriverState state ; / / /< Current driver s s t a t e char SN [ 2 0 ] ; / / / < D e v i c e s e r i a l number wchar_t ProductString [50]; / / / < D e v i c e p r o d u c t name s t r i n g unsigned short i n t productID ; / / / < D e v i c e p r o d u c t ID v i r t u a l void enumerate ( ) = 0; / / / < To g e t an a b s t r a c t c l a s s ( t r i e s t o e n u m e r a t e t h e d e v i c e ) v i r t u a l bool send ( unsigned char data , unsigned i n t len ) { r e t u r n f a l s e ; } / / / < Writes a data packet to the device v i r t u a l bool r e c e i v e ( unsigned char data , u n s i g n e d i n t l e n = 0 ) { r e t u r n f a l s e ; } / / / < G e t s a d a t a p a c k e t from t h e d e v i c e v i r t u a l v o i d r e s e t ( ) {} / / /< Resets the driver / Gets the c u r r e n t d r i v e r s t a t e @ r e t u r n The c u r r e n t D r i v e r S t a t e / inline DriverState getState () { return state ; } }; } # endif
C.2.3.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 // // // // // // // // / / / / / / / /
Protocol.h
////////////////////////////////// \ f i l e Protocol . h \ b r i e f D e f i n i t i o n o f t h e p r o t o c o l i n t e r f a c e t h a t must be i m p l e m e n t e d i n a l l p r o t o c o l s f o r LSyM HASP d e v i c e s \ a u t h o r M i g u e l Angel E x p o s i t o S a n c h e z (LSYM) < miexsan@alumni . uv . es > //////////////////////////////////////
# i f n d e f ProtocolH # define ProtocolH / / # i n c l u d e " libhw . h" namespace libhw { / \ class Protocol \ s e c t i o n d e v e l o p e r s Use I n o r d e r t o make a p r o t o c o l you must i m p l e m e n t a l l m e t h o d s i n t h i s i n t e r f a c e . / class Protocol { f r i e n d c l a s s LSYMHASP ; public : / Class constructor A l l o c a t e s memory f o r i n p u t and o u t p u t b u f f e r s / P r o t o c o l ( ) : s t a t e ( STOP ) { / A l l o c a t e t h e i n p u t and o u t p u t b u f f e r s / input = ( u n s i g n e d c h a r ) m a l l o c ( i L e n ) ; o u t p u t = ( u n s i g n e d c h a r ) m a l l o c ( oLen ) ; / / I f i n p u t == NULL | | o u t p u t == NULL > E x c e p t i o n ? } / Class d e s t r u c t o r F r e e s t h e memory u s e d by t h e i n p u t / o u t p u t b u f f e r s /
161
43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90
~Protocol () { / F r e e t h e i n p u t and o u t p u t b u f f e r s / free ( input ) ; free ( output ) ; } / P r o t o c o l i n t e r n a l s t a t e m a c h i n e / enum P r o t o c o l S t a t e {STOP , / / / < The p r o t o c o l i s s t o p p e d INITIALIZING , / / / < The p r o t o c o l i s i n i t i a l i z i n g OK, / / / < The p r o t o c o l i s w o r k i n g OK INIT_ERROR , / / / < T h e r e was an i n i t i a l i z a t i o n e r r o r PROT_ERROR / / / < T h e r e was a p r o t o c o l e r r o r }; s t a t i c c o n s t unsigned i n t productIDMask ; / / / < P r o d u c t ID f l a g s m a t c h i n g t h i s p r o t o c o l / Gets the c u r r e n t p r o t o c o l s t a t e @ r e t u r n The p r o t o c o l s t a t e / i n l i n e P r o t o c o l S t a t e g e t S t a t e ( ) { r e t u r n s t a t e ; } / / / < Gets the c u r r e n t p r o t o c o l s t a t e / G e t s a p o i n t e r t o t h e o u t p u t b u f f e r o f t h i s p r o t o c o l and r e t u r n i t s l e n g t h @param [ o u t ] ob P o i n t e r t o t h e o u t p u t b u f f e r @return t he s i z e in b y t e s of t he b u f f e r / i n l i n e u n s i g n e d i n t g e t O u t p u t B u f f e r ( u n s i g n e d c h a r &ob ) { ob = o u t p u t ; r e t u r n oLen ; } / / / < Gets a p o i n t e r to the output buffer / G e t s a p o i n t e r t o t h e i n p u t b u f f e r o f t h i s p r o t o c o l and r e t u r n i t s l e n g t h @param [ o u t ] i b P o i n t e r t o t h e i n p u t b u f f e r @return t he s i z e in b y t e s of t he b u f f e r / i n l i n e u n s i g n e d i n t g e t I n p u t B u f f e r ( u n s i g n e d c h a r &i b ) { i b = i n p u t ; r e t u r n i L e n ; } protected : ProtocolState state ; / / /< Current protocol s t a t e v i r t u a l v o i d i n i t ( ) {} / / /< I n i t i a l i z e the protocol v i r t u a l v o i d p r e S t e p ( ) {} / / / < Steps the p r o t o c o l ( p r e v i o u s to d a ta exchange ) v i r t u a l v o i d p o s t S t e p ( ) {} / / / < Steps the p r o t o c o l ( f o l l o w i n g d a ta exchange ) v i r t u a l void r e s e t ( ) = 0; / / / < To g e t an a b s t r a c t c l a s s ( r e s e t s t h e p r o t o c o l ) unsigned char input ; / / / P r o t o c o l ) unsigned char output ; / / / < O u t p u t b u f f e r ( P r o t o c o l => D e v i c e ) s t a t i c c o n s t i n t oLen = 9 ; / / / < Defined output length s t a t i c c o n s t i n t iLen = 8; / / / < Defined input length }; } # endif
C.2.4.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 // // // // // // // // / / / / / / / /
LSYMHASP.h
////////////////////////////////// \ f i l e LSYMHASP . h \ b r i e f LSYMHASP C l a s s i m p l e m e n t s a h a r d w a r e v a l i d a t i o n s e c u r i t y t h r e a d w i t h a c a l l b a c k i n t e r f a c e \ a u t h o r M i g u e l Angel E x p o s i t o S a n c h e z (LSYM) < miexsan@alumni . uv . es > //////////////////////////////////////
# i f n d e f LSYMHASPH # d e f i n e LSYMHASPH / / # i n c l u d e " libhw . h" # include " libhwException . h" / / D e f i n i t i o n o f m e s s a g e s t h a t c a n be s e n t t o t h e t h r e a d # d e f i n e WM_STOP WM_APP + 0 x100 / / / < Stop the t h r e a d # d e f i n e WM_RESET WM_APP + 0 x101 / / / < Reset the protocol namespace libhw { / \ c l a s s LSYMHASP \ s e c t i o n HASPuse Use
162
C.2. LIBRERA LIBHW
29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
To u s e t h i s c l a s s you must i n s t a n t i a t e i t by p a s s i n g t o t h e c o n s t r u c t o r a p o i n t e r t o t h e d r i v e r t o u s e , a p o i n t e r t o t h e p r o t o c o l t o u s e and a p o i n t e r t o a u s e r d e f i n e d c a l l b a c k f u n c t i o n . / c l a s s LSYMHASP { public : / HASP I n t e r n a l s a t e m a c h i n e / enum HASPState {STAT_DISCONNECTED , / / / < Device not connected STAT_DETECTED , / / / < Device d e t e c t e d but not checked STAT_INIT , / / /< Library i n i t i a l i z a t i o n STAT_RUNNING , / / / < Library running STAT_ERROR , / / /< Library error STAT_STOP / / / < Library stopped }; / HASP C a l l b a c k m e s s a g e s / enum HASPMessage {HWERROR, / / / < Hardware e r r o r PERROR , / / /< Protocol error DISCONNECTED , / / / < The HASP d e v i c e i s n o t c o n n e c t e d ONLINE , / / / < The HASP d e v i c e h a s b e e n c o n n e c t e d and c h e c k e d INIT , / / / < The HASP l i b r a r y h a s b e e n i n i t i a l i z e d INIT_ERROR , / / / < E r r o r w h i l e i n i t i a l i z i n g HASP l i b r a r y STOP } ; / / / < The HASP l i b r a r y h a s b e e n s t o p p e d / HASP E x c e p t i o n c o d e s / enum HASPException {EX_THREADSTARTED, / / / < S t a r t e r r o r : The t h r e a d i s a l r e a d y s t a r t e d EX_THREADSTOPPED , / / / < S t o p e r r o r : The t h r e a d i s a l r e a d y s t o p p e d EX_CANTSTOP , / / / < S t o p e r r o r : The t h r e a d c a n t be s t o p p e d EX_CANTSTART / / / < S t a r t e r r o r : The t h r e a d c a n t be s t a r t e d }; t y p e d e f v o i d ( HWEVTCALLBACK) ( HASPMessage ) ; / / / < U s e r c a l l b a c k f u n c t i o n p r o t o t y p e LSYMHASP( D r i v e r , P r o t o c o l , HWEVTCALLBACK) ; / / /< Class constructor ~LSYMHASP ( ) ; / / /< Class d e s t r u c t o r void cleanup ( ) ; / / / < F r e e s t h e d r i v e r and p r o t o c o l memory void s t a r t ( ) ; / / / < S t a r t s t h e HASP s e r v i c e void stop ( ) ; / / / < S t o p s t h e HASP s e r v i c e i n l i n e b o o l v a l i d H W P r e s e n t ( ) { r e t u r n s t a t e == STAT_RUNNING ; } / / / < R e t u r n s i f t h e r e i s a v a l i d HASP d e v i c e a t t a c h e d (NOT RECOMMENDED! ! , u s e t h e c a l l b a c k i n s t e a d ) / G e t s t h e d e v i c e s s e r i a l number from i t s d e v i c e d e s c r i p t o r ( you must c h e c k f i r s t t h e s t a t e OK) Note t h a t you l l g e t a wide c h a r s t r i n g ( u n i c o d e ) @ r e t u r n The p r o d u c t s e r i a l number s t r i n g / i n l i n e c h a r g e t S e r i a l S t r i n g ( ) { r e t u r n d r i v e r >SN ; } / Gets the ProductID of the c u r r e n t device ( you must c h e c k f i r s t t h e s t a t e OK) @ r e t u r n The p r o d u c t ID / i n l i n e u n s i g n e d s h o r t i n t g e t P I D ( ) { r e t u r n d r i v e r >p r o d u c t I D ; } private : s t a t i c u n s i g n e d i n t _ _ s t d c a l l H A S P S t a t i c T h r e a d ( v o i d ) ; / / / < S t a t i c a l l y d e f i n e d t h r e a d f o r t h e HASP service v o i d HASPThread ( ) ; / / / < R e a l HASP s e r v i c e t h r e a d HANDLE m_hHASPThread ; / / / < Handle t o working t h r e a d unsigned m_idHASPThread ; / / / < Working t h r e a d s ID HWND hWnd ; / / / < U s e r window r e c e i v i n g WM_DEVICECHANGE m e s s a g e s HASPState state ; / / / < HASP c u r r e n t s t a t e Driver driver ; / / / < Driver to use with the hardware Protocol protocol ; / / /< Validation protocol unsigned char p_input ; / / / P r o t o c o l ) unsigned char p_output ; / / / D e v i c e ) v o i d ( HASPCallback ) ( HASPMessage ) ; / / / < P o i n t e r t o t h e u s e r d e f i n e d c a l l b a c k }; } # endif
BIBLIOGRAFA
[AGM08]
Rafael Achaerandio Garca and Fernando Maldonado. I estudio anual de idc para la bsa sobre la piratera en espaa. In IDC, editor, I Estudio Anual de IDC para la BSA sobre la piratera en Espaa. BSA, 2008. 1.1 Inc Aladdin Knowledge productos aladdin. Systems. Catlogo on-line de
[AKS]
http://www.aladdin.com/hasp/ protection-keys-benefits-models.aspx. 2.4, 6.2
[Axe97]
Jan Axelson. The microcontroller idea book. In Lakeview Research, editor, The microcontroller idea book, Madison, WI, USA, 1997. Lakeview Research. 2.3 Jan Axelson. Usb complete, third edition. In Lakeview Research, editor, USB Complete, Third edition, Madison, WI, USA, 2005. Lakeview Research. (document), 2.2.1, 5.1, 6.4.1
[Axe05]
[CSFBAOSS01] Carlos Cerrada Somolinos, Vicente Feliu Batlle, Antonio Adn Oliver, and Jos Andrs Somolinos Snchez. Fundamentos de estructura y tecnologa de computadores. In Editorial Universitaria Ramn Areces, editor, Fundamentos de estructura y tecnologa de computadores. Editorial Universitaria Ramn Areces, 2001. (document), 2.2, 2.1 [Gra05] Joe Grand. Can you really trust hardware? - exploring security problems in hardware devices, 2005. http://grandideastudio.com/ wp-content/uploads/trust_slides.pdf. 2.4 Steve J. Baker. Librera portable para juegos plib. http://plib. sourceforge.net/. 6.1.3
[JB]
164
Bibliografa
[MHH+ 08]
J.D. Meier, Alex Homer, David Hill, Jason Taylor, Bansode Prashant, Lonnie Wall, Rob jr Boucher, and Akshay Bogawat. Patterns & practices application architecture guide 2.0, 2008. 6.4.1 Parallax propeller. propeller/. 2.3 Parallax.
http://www.parallax.com/
[Par]
[Per05]
Juan Jos Perez. Material docente de la asignatura sistemas basados en microprocesador. In Universidad de Valencia, editor, Material docente de la asignatura Sistemas Basados en Microprocesador, 2005. 2.3 ST. Nota de prensa de st microelectronics. http://www.st.com/ stonline/press/news/year2005/p1416h.htm. 2.3 Peter Stephenson. Artculo sobre el aladdin hasp srm, 2 2009. http://www.scmagazineuk.com/aladdin-hasp-srm/ review/2909/. 2.4 Microchip Technology. Datasheet del pic18f2455/2550/4455/4550. In Datasheet del PIC18F2455/2550/4455/4550, 2007. 5.1, 5.4 USB-IF. Programa de cumplimiento de usb-if. http://www.usb.
org/developers/compliance/. 2.2.1
[ST]
[Ste09]
[Tec07]
[UIa]
[UIb] [UI01]
USB-IF. Sitio web del usb-if. http://www.usb.org. 2.2.1 USB-IF. Especicacin de la norma hid 1.11 para dispositivos de interfaz humana, 2001. http://www.usb.org/developers/ devclass_docs/HID1_11.pdf. 6.1.3

PFC

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PFC

Hochgeladen von

Copyright:

Verfügbare Formate

Departament dInformtica

c Universitat de Valncia - Todos los derechos reservados

CAPTULO 2. Estado del arte

CAPTULO 3. Metodologa y materiales

CAPTULO 4. Denicin de requisitos y anlisis del sistema

CAPTULO 5. Diseo e implementacin del hardware

CAPTULO 6. Diseo e implementacin del software

106 106 112 113 121

CAPTULO 9. Conclusiones y trabajo futuro

9.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

APNDICE A. Planos y fotolitos

APNDICE C. Listados de cdigo fuente

C.2.4. LSYMHASP.h . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

57 85 86 86 87 88 88 89 89 93 93 93 93 94 94 94 94 103 105 109 115 116 119 119 121

8.1. Costes de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 8.2. Costes de hardware I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

67 68 69 69 70 71 76 77 79 80 82 83 84 84 90 91 92 95 98 99 100 101 103 104 107 114

6.21. 6.22. 6.23. 6.24. 6.25. 6.26. 6.27.

116 117 117 118 119 120 122

B.1. Fotografa del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . 149

ESTADO DEL ARTE

ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS

2.2. ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS

CAPTULO 2. ESTADO DEL ARTE

Interfaz Serie RS-232

Electronic Industries Alliance

2.2. ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS

USB Implementers Forum

CAPTULO 2. ESTADO DEL ARTE

2.2. ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS

CAPTULO 2. ESTADO DEL ARTE

Figura 2.5: Tipos A y B del conector USB

2.2. ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS

CAPTULO 2. ESTADO DEL ARTE

Figura 2.7: Conectores Firewire

2.2. ESTNDARES DE INTERCONEXIN ENTRE UN COMPUTADOR Y SUS PERIFRICOS

Puerto paralelo Centronics

CAPTULO 2. ESTADO DEL ARTE

CAPTULO 2. ESTADO DEL ARTE

2.4. DISPOSITIVOS HASP

CAPTULO 2. ESTADO DEL ARTE

DISPOSITIVOS DE ADQUISICIN DE DATOS (DAQ)

2.5. DISPOSITIVOS DE ADQUISICIN DE DATOS (DAQ)

Figura 2.9: Ejemplo de seal digital ideal

CAPTULO 2. ESTADO DEL ARTE

Conversor Analogico-Digital (ADC)

Dispositivos de adquisicin de datos integrados

2.6. ARQUITECTURA DE UN SIMULADOR

CAPTULO 2. ESTADO DEL ARTE

Figura 2.11: Arquitectura de un sistema de simulacin

2.6. ARQUITECTURA DE UN SIMULADOR

3.2. PLANIFICACIN DE RECURSOS MATERIALES Y HUMANOS

PLANIFICACIN DE RECURSOS MATERIALES Y HUMANOS

CAPTULO 3. METODOLOGA Y MATERIALES

CCS PICC PCWH

USB-IF descriptor tool

CAPTULO 3. METODOLOGA Y MATERIALES

Microsoft Windows Server 2003 SP1 DDK

Visual C++ Express

Windows XP x64 edition

El hardware utilizado para la realizacin del proyecto es el siguiente:

Planicacin y recursos humanos

CAPTULO 3. METODOLOGA Y MATERIALES

Figura 3.1: Diagrama de Gantt