d usb hasp hid - muralmural.uv.es/miexsan/pfc/pfc.pdf · bios consejos han jugado un gran papel y a...

Departament d’Informàtica

PROYECTO FINAL DE CARRERA

DISEÑO E IMPLEMENTACIÓN DE UNA

TARJETA DE SENSORIZACIÓN USBCON HASP BASADA EN HID

Presentado por:D. Miguel Ángel Expósito Sánchez

Burjassot, Septiembre de 2009

Proyecto dirigido por: Rafael Javier Martínez Durá

c©Universitat de València - 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.

AgradecimientosA mi tutor, Rafael Martinez, que me ha brindado la oportunidad de realizar este

proyecto.A todos los compañeros del grupo LSyM, en especial a Marta cuya experiencia y sa-

bios consejos han jugado un gran papel y a Alejandro, que sabe dar un toque profesionala todo aquello en lo que se involucra.

A José Pino, quien siempre ha estado dispuesto a prestarme su ayuda desinteresada.A mis compañer@s de clase, por todos estos años de amistad y buenos recuerdos.

Que no acaben aquí.A mis amigos Rubén y Andrés por su ayuda y paciencia, y porque siempre serán unos

«corrutos».A Saúl, que nunca duda en compartir conmigo su conocimiento tanto tecnológico

como culinario.A Pako y Adrián, que siempre están ahí para lo bueno y para lo malo, y saben reirse

de la vida en los momentos en que más lo necesito.A Esther. Gracias por ser una persona con la que siempre puedo hablar.A mi tío Miguel y mi tía Jaci. Os estaré eternamente agradecido.A Enrique, Paqui y Gema. Me habeis enseñado cómo se escribe «familia».

ÍNDICE

CAPÍTULO 1. Introducción 131.1. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

CAPÍTULO 2. Estado del arte 172.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2. Estándares de interconexión entre un computador y sus periféricos . . . . 17

2.2.1. Interfaces Serie . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2. Interfaces Paralelas . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.3. Interfaces Inalámbricas . . . . . . . . . . . . . . . . . . . . . . . 26

2.3. Microcontroladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4. Dispositivos HASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5. Dispositivos de Adquisición de Datos (DAQ) . . . . . . . . . . . . . . . 31

2.5.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.5.2. Conversor Analogico-Digital (ADC) . . . . . . . . . . . . . . . . 332.5.3. Dispositivos de adquisición de datos integrados . . . . . . . . . . 332.5.4. Dispositivos de juegos . . . . . . . . . . . . . . . . . . . . . . . 34

2.6. Arquitectura de un simulador . . . . . . . . . . . . . . . . . . . . . . . . 34

CAPÍTULO 3. Metodología y materiales 373.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2. Planificación de recursos materiales y humanos . . . . . . . . . . . . . . 383.3. Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.1. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.3. Planificación y recursos humanos . . . . . . . . . . . . . . . . . 42

4 ÍNDICE

CAPÍTULO 4. Definición de requisitos y análisis del sistema 454.1. Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1. Requisitos del hardware . . . . . . . . . . . . . . . . . . . . . . 454.1.2. Requisitos del software . . . . . . . . . . . . . . . . . . . . . . . 464.1.3. Requisitos comunes . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2. Análisis de alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.1. Conexión del periférico con el computador . . . . . . . . . . . . 474.2.2. Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.3. Lenguaje de programación . . . . . . . . . . . . . . . . . . . . . 49

4.3. Selección de alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 51

CAPÍTULO 5. Diseño e implementación del hardware 555.1. Diagrama de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2. Conectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.1. Conexión USB . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.2. Conexión los sensores . . . . . . . . . . . . . . . . . . . . . . . 565.2.3. Otros conectores . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3. Asignación de pines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4. Alimentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5. Oscilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.6. Comunicación USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.7. Conexión de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.7.1. Sensores digitales . . . . . . . . . . . . . . . . . . . . . . . . . . 645.7.2. Sensores analógicos . . . . . . . . . . . . . . . . . . . . . . . . 67

5.8. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.9. Diseño del esquemático . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.10. Implementación del hardware . . . . . . . . . . . . . . . . . . . . . . . . 71

CAPÍTULO 6. Diseño e implementación del software 756.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.1.1. Endpoints y pipes . . . . . . . . . . . . . . . . . . . . . . . . . . 756.1.2. Descriptores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.1.3. La clase HID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.2. Algoritmo HASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.3. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.3.1. Configuración del microcontrolador . . . . . . . . . . . . . . . . 836.3.2. Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.3.3. Comunicación USB . . . . . . . . . . . . . . . . . . . . . . . . 906.3.4. Adquisición y formateado de datos . . . . . . . . . . . . . . . . . 976.3.5. Implementación del algoritmo HASP . . . . . . . . . . . . . . . 1056.3.6. Programa principal . . . . . . . . . . . . . . . . . . . . . . . . . 105

ÍNDICE 5

6.3.7. Generación del ejecutable . . . . . . . . . . . . . . . . . . . . . 1066.3.8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.4. Software para el PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126.4.1. Librería HASP . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136.4.2. Herramientas complementarias . . . . . . . . . . . . . . . . . . . 121

CAPÍTULO 7. Pruebas 1277.1. Instalación del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . 1287.2. Prueba de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287.3. Prueba HASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287.4. Actualización de firmware . . . . . . . . . . . . . . . . . . . . . . . . . 128

CAPÍTULO 8. Presupuesto 1318.1. Coste de los recursos software . . . . . . . . . . . . . . . . . . . . . . . 1318.2. Coste de los recursos hardware . . . . . . . . . . . . . . . . . . . . . . . 1328.3. Coste de recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . 1338.4. Coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

CAPÍTULO 9. Conclusiones y trabajo futuro 1359.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

APÉNDICE A. Planos y fotolitos 139A.1. Esquemático del circuito . . . . . . . . . . . . . . . . . . . . . . . . . . 141A.2. Listado de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 142A.3. Layout del PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143A.4. Fotolitos del PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

APÉNDICE B. Especificaciones 147B.1. Especificaciones del dispositivo . . . . . . . . . . . . . . . . . . . . . . 148B.2. Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148B.3. Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

APÉNDICE C. Listados de código fuente 151C.1. Firmware del microcontrolador . . . . . . . . . . . . . . . . . . . . . . . 152

C.1.1. lsred_main.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152C.1.2. lsred_desc.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

C.2. Librería libhw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158C.2.1. libhw.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159C.2.2. Driver.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159C.2.3. Protocol.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

6 ÍNDICE

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

ÍNDICE DE TABLAS

5.1. Numeración y función de cada pin [Axe05] . . . . . . . . . . . . . . . . 57

6.1. Tabla de registros de configuración. . . . . . . . . . . . . . . . . . . . . 856.2. Configuración del registro CONFIG1L. . . . . . . . . . . . . . . . . . . 866.3. Configuración del registro CONFIG1H. . . . . . . . . . . . . . . . . . . 866.4. Configuración del registro CONFIG2L. . . . . . . . . . . . . . . . . . . 876.5. Configuración del registro CONFIG3H. . . . . . . . . . . . . . . . . . . 886.6. Configuración del registro CONFIG5L. . . . . . . . . . . . . . . . . . . 886.7. Configuración del registro CONFIG5H. . . . . . . . . . . . . . . . . . . 896.8. Configuración del micro. . . . . . . . . . . . . . . . . . . . . . . . . . . 896.9. Descriptor de dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . 936.10. Descriptor de configuración . . . . . . . . . . . . . . . . . . . . . . . . . 936.13. Descriptor HID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.11. Descriptor de interfaz 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.12. Descriptor de interfaz 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.14. Descriptor de endpoint 1 (IN) . . . . . . . . . . . . . . . . . . . . . . . . 946.15. Descriptor de endpoint 2 (IN) . . . . . . . . . . . . . . . . . . . . . . . . 946.16. Descriptor de endpoint 2 (OUT) . . . . . . . . . . . . . . . . . . . . . . 946.17. Número y tipo de entradas . . . . . . . . . . . . . . . . . . . . . . . . . 1036.18. Interfaz de la librería HASP para PIC18. . . . . . . . . . . . . . . . . . . 1056.19. Comandos aceptados por el bootloader. . . . . . . . . . . . . . . . . . . 1096.20. Interfaz de la capa «Driver» . . . . . . . . . . . . . . . . . . . . . . . . . 1156.21. Interfaz de la capa «Protocol» . . . . . . . . . . . . . . . . . . . . . . . 1166.22. Interfaz de la capa «LSYMHASP» . . . . . . . . . . . . . . . . . . . . . 1196.23. Mensajes de notificación . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.24. Códigos de excepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

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

8 ÍNDICE DE TABLAS

8.3. Costes de hardware II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338.4. Costes de recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . 1338.5. Costes totales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

A.1. Listado de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 142

B.1. Especificaciones del dispositivo . . . . . . . . . . . . . . . . . . . . . . 148B.2. Especificaciones del dispositivo . . . . . . . . . . . . . . . . . . . . . . 148

ÍNDICE DE FIGURAS

1.1. Evolución sobre el software ilegal en España de 2003 a 2007 . . . . . . . 15

2.1. Interfaz de E/S para un dispositivo generíco [CSFBAOSS01] . . . . . . . 182.2. Cronograma de una transmisión RS-232 a 1600 baudios sin bit de paridad 202.3. A la izquierda conector DB-25, a la derecha conector DB-9 . . . . . . . . 202.4. Diagrama del conector USB 3.0 . . . . . . . . . . . . . . . . . . . . . . 222.5. Tipos A y B del conector USB . . . . . . . . . . . . . . . . . . . . . . . 232.6. Topología de USB 2.0 y predecesores . . . . . . . . . . . . . . . . . . . 232.7. Conectores Firewire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.8. Utilización de microcontroladores por cada sector . . . . . . . . . . . . . 282.9. Ejemplo de señal digital ideal . . . . . . . . . . . . . . . . . . . . . . . . 322.10. Ejemplo de señal analógica . . . . . . . . . . . . . . . . . . . . . . . . . 332.11. Arquitectura de un sistema de simulación . . . . . . . . . . . . . . . . . 35

3.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1. El encapsulado SPDIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1. Diagrama de bloques del sistema . . . . . . . . . . . . . . . . . . . . . . 555.2. Tipos de conectores USB principales, de izquierda a derecha: Micro USB

macho, Mini USB tipo B macho, Tipo B macho, Tipo A macho. . . . . . 565.3. Conector USB tipo B macho y hembra. . . . . . . . . . . . . . . . . . . 575.4. Extremos del cable de conexión USB de tipo A-B. . . . . . . . . . . . . . 575.5. Conector USB tipo B para montaje en placa. . . . . . . . . . . . . . . . . 575.6. Diagrama de pines del PIC18F2550 en su encapsulado SPDIP . . . . . . 585.7. Esquema de circuito de alimentación para un PIC18F2550 alimentado por

USB usando su transceptor incorporado. . . . . . . . . . . . . . . . . . . 595.8. Esquema de la circuitería de selección de reloj del PIC18F2550 relativa

al módulo USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.9. Esquema de conexión de un cristal de cuarzo al PIC18F2550. . . . . . . . 61

10 ÍNDICE DE FIGURAS

5.10. Tabla de capacidades recomendadas por el fabricante para los condensa-dores C1 y C2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.11. Circuito para la detección de un dispositivo de alta velocidad. . . . . . . . 625.12. Circuito para la detección de un dispositivo de baja velocidad. . . . . . . 635.13. Fragmento del esquema de la circuitería de control del USB relativo a las

resistencias de pull-up internas. . . . . . . . . . . . . . . . . . . . . . . . 635.14. Esquema simplificado de la circuitería de control de un pin de E/S. . . . . 655.15. Esquema de conexión de un pulsador a una entrada digital. . . . . . . . . 665.16. Rango de niveles de tensión y su correspondencia con los niveles lógicos

en TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.17. Esquema de conexión de cada entrada digital, X1-1 y X1-2 simbolizan

pines del conector de apriete, X2-1 y X2-2 simbolizan los extremos delos cables conectados a estos. . . . . . . . . . . . . . . . . . . . . . . . . 67

5.18. Conexionado interno de los pines de entrada analógicos al conversor A/Ddel PIC18F2550. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.19. Esquema de conexión de un potenciómetro a un conversor A/D. . . . . . 695.20. Esquema de conexión separado. . . . . . . . . . . . . . . . . . . . . . . 695.21. Esquema de conexión final. . . . . . . . . . . . . . . . . . . . . . . . . . 705.22. Esquema de conexionado interno típico de una placa de prototipos Proto-

Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1. Tuberías lógicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.2. Jerarquía de descriptores USB. . . . . . . . . . . . . . . . . . . . . . . . 776.3. Papel de los descriptores de informe en la jerarquía de descriptores USB. 796.4. Report de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.5. Intercambio de información HASP. . . . . . . . . . . . . . . . . . . . . . 826.6. Cadena de desafío . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.7. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.8. Imagen de la salida por consola de la aplicación de prueba ’swval’. . . . . 846.9. Diagrama de flujo principal. . . . . . . . . . . . . . . . . . . . . . . . . 906.10. Endpoints utilizados, dirección y propósito. . . . . . . . . . . . . . . . . 916.11. Jerarquía de descriptores para el dispositivo . . . . . . . . . . . . . . . . 926.12. Captura de HID descriptor tool . . . . . . . . . . . . . . . . . . . . . . . 956.13. Registro de configuración A/D ADCON1 . . . . . . . . . . . . . . . . . 986.14. Proceso de toma de una muestra con tiempo de adquisición de 4 TAD . . 996.15. Registro de configuración A/D ADCON2 . . . . . . . . . . . . . . . . . 1006.16. Registro de configuración A/D ADCON0 . . . . . . . . . . . . . . . . . 1016.17. Funcionamiento de las entradas digitales simuladas. . . . . . . . . . . . . 1036.18. Rebote producido al presionar un pulsador. . . . . . . . . . . . . . . . . 1046.19. Mapa de memoria de un dispositivo con bootloader . . . . . . . . . . . . 1076.20. Pila de capas de la librería libhw . . . . . . . . . . . . . . . . . . . . . . 114

ÍNDICE DE FIGURAS 11

6.21. Superclase Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166.22. Máquina de estados de la capa «Driver» . . . . . . . . . . . . . . . . . . 1176.23. Superclase «Protocol» . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.24. Máquina de estados de «Protocol» . . . . . . . . . . . . . . . . . . . . . 1186.25. Clase «LSYMHASP» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.26. Máquina de estados de «LSYMHASP» . . . . . . . . . . . . . . . . . . 1206.27. Diagrama de secuencia de un ciclo del protocolo HASP. . . . . . . . . . . 122

7.1. Prueba de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.2. Prueba de sistema HASP . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.3. Prueba de actualización de fimware con lsymflash . . . . . . . . . . . . . 130

A.1. Layout: Capa Top y Componentes en rojo, Capa Bottom en verde . . . . 143A.2. Fotolito: Cara Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144A.3. Fotolito: Cara Botom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144A.4. Fotolito: Capa de componentes . . . . . . . . . . . . . . . . . . . . . . . 145

B.1. Fotografía del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . 149

12 ÍNDICE DE FIGURAS

CAPÍTULO 1

INTRODUCCIÓN

1.1. MOTIVACIONES

En una sociedad como la actual, en la que el público demanda aplicaciones con cadavez mayor nivel de interactividad los desarrolladores buscan nuevas formas de interactuarcon los usuarios eliminando las barreras de los periféricos de entrada clásicos como elteclado y el ratón mediante el diseño de periféricos específicos para la tarea que se realiza.

El campo de la simulación por computador ha experimentado un auge en los últimosaños debido en gran medida al rápido avance del hardware y de la tecnología en general.Las nuevas técnicas de visualización, computacionalmente inviables en el pasado y elabaratamiento del hardware tanto para visualización, contando las nuevas GPUs con unnumero mayor de transistores y más potencia de cálculo que el procesador central o CPU,como para la captura de la entrada del usuario, siendo barata y eficaz la utilización deperiféricos tales como trackers, proyectores de vídeo o sistemas de visión esteroscópicaque aumentan considerablemente la inmersión del usuario dentro del entorno simulado.Todo esto hace posible que más personas puedan beneficiarse de la tecnología, que estásiendo ampliamente implantada, entre otros campos, en el formativo para entrenamientosin riesgos ni altos costes asociados de futuros profesionales, como es el caso por ejemplodel manejo de maquinaria de obra civil.

El desarrollo de un simulador suele estar enfocado a un campo muy concreto y a larealización repetitiva de un conjunto de tareas y maniobras específico (ya sea conducirun camión o manejar una grúa). Uno de los principales objetivos durante el desarrolloconsiste en lograr la mayor inmersión posible del usuario en el entorno simulado, lo queen la mayoría de casos descarta al tradicional teclado y ratón como principal método deentrada, lo que podría provocar que la aplicación perdiese gran parte de su función didac-tica. Este aspecto puede ser mejorado si la entrada del usuario proviene de un dispositivolo más parecido posible al utilizado en la vida real.

Por lo tanto resulta interesante desde el punto de vista de la simulación, que exista unacorrespondencia entre el tipo concreto de simulador y el tipo de periféricos de entrada/sa-lida para la interacción con el usuario que se utilizan.

14 1.1. MOTIVACIONES

Sin embargo los dispositivos de control usados en la vida real distan mucho de serperiféricos aptos para un ordenador personal, y varían mucho en forma y tecnología deunos a otros, teniendo cada uno sus propias interfaces eléctricas y lógicas. De esta manerase plantea el problema consistente en capturar la entrada de uno de estos dipositivos paraentregársela al simulador, para que este a su vez pueda actualizar en consecuencia elestado de la simulación y producir resultados en su visualización gráfica o de retorno alpropio periférico en forma de señales luminosas, o de variaciones en sus indicadores oactuadores.

No obstante, todos los dispositivos de control reales suelen tener características co-munes, siendo la principal el hecho de que están formados por transductores y sensoreseléctricos tales como pulsadores o potenciómetros, cuyos niveles de tensión se puedenmedir para obtener una entrada adecuada. De manera que estos dispositivos pueden seradaptados para ser convertidos en periféricos aptos para formar parte de un simulador.

Por otra parte, el uso indebido de la tecnología acarrea consecuencias que impactannegativamente en la evolución y el desarrollo la industria ya que no solo disminuye losingresos, sino que también redunda en menos I+D y disminuye las inversiones en desarro-llo de marketing. En los últimos años, el uso de software ilegal en España no ha hecho másque aumentar en relación a Europa Occidental [AGM08] como se desprende de la figura1.1, ocupando el decimo segundo puesto del ranking mundial de pérdidas producidas porpiratería. Las copias ilegales tanto de software como de cualquier material amparado porderechos de autor está castigada con diversas penas por la ley y las fuerzas de seguridaden gran número paises, lo cual no consigue sino mitigar este impacto sin llegar a obtenerunos resultados aceptables. Con el fín de reducir al mínimo estas actividades delictivas,desde hace más de dos décadas se vienen desarrollando y utilizando tecnologías, unasveces basadas total o parcialmente en teoremas que llevan existiendo más de cincuentaaños como es el caso de la criptografía, y otras totalmente nuevas, la implementación yasea por software (números de serie, activación telemática ...) o por hardware (dispositivosde bloqueo) siempre está destinada únicamente a limitar en la medida de lo posible lareproducción o difusión no autorizadas de dichos materiales.

Resulta por tanto de gran utilidad en la intersección de ambos campos combinar enun mismo dispositivo la capacidad de proporcionar al simulador la entrada del usuario(pulsación de botones, movimientos, ...) de manera adaptada a éste, y la de protección delsoftware contra la reproducción ilegal, aprovechando el hecho de que el dispositivo seránecesario para controlar la simulación, y se distribuye al menos uno con cada copia delsoftware.

El presente proyecto surge de la necesidad de incorporar un componente en el interiorde una botonera real de control de una grúa torre, que le permita conectarse a un PC para lautilización del simulador de entrenamiento en el manejo de este tipo de grúa, y aprovecharel desarrollo del hardware para aplicar una protección anticopia algo más robusta que losmétodos tradicionales por software.

Para terminar es preciso señalar que el diseño será totalmente reutilizable para cual-

CAPÍTULO 1. INTRODUCCIÓN 15

Figura 1.1: Evolución sobre el software ilegal en España de 2003 a 2007

quier otro simulador o aplicación relacionada.

1.2. OBJETIVOS

El objetivo principal del presente proyecto es:

Diseñar y construir un dispositivo hardware periférico intermediario entre los trans-ductores de los mandos de control de una maquinaria real y un computador que ademásofrezca un sistema de validación de software, obteniendo así un dispositivo híbrido queproporcione ambas funcionalidades. El desarrollo de una librería software y herramien-tas adicionales necesarias que permitan al computador acceder a las funciones propor-cionadas por dicho dispositivo periférico.

Las principales características que debe tener el dispositivo son:

• El dispositivo estará físicamente conectado al computador mediante el bus USB 1 ya los transductores, con el fin de aislar el tipo concreto de dispositivo de control delcomputador en el que se utilice.

• No requerirá alimentación externa.

• Tomará muestras sobre el estado de los sensores y comunicará las lecturas de ma-nera adecuada al computador.

• El dispositivo validará el software de forma segura, robusta, y no penalizará a aque-llos usuarios que posean una copia legítima del software.

1La elección del bus USB como interfaz con el computador será justificada en las posteriores secciones.

16 1.2. OBJETIVOS

• Tiene que ofrecer dificultades contra la ingeniería inversa de dicha protección.

A continuación se enumeran las características que debe cumplir la librería software:

• La librería se encargará de la monitorización contínua del estado de conexión deldispositivo.

• Será la responsable de asegurarse de que el dispositivo es autentico mediante elintercambio de mensajes.

• Notificará al software protegido de eventos producidos en relación a los apartadosanteriores para que éste pueda actuar en consecuencia.

• Será transparente para el programador.

• Ocupará los mínimos recursos tanto espaciales como temporales en el computadorcomo sea posible.

• Tendrá un diseño modular y estará construida sobre un lenguaje de programaciónde alto nivel y de uso común.

CAPÍTULO 2

ESTADO DEL ARTE

2.1. INTRODUCCIÓN

En la presente sección se realiza un estudio de la tecnología actual y alternativas exis-tentes para abordar los problemas anteriormente presentados.

El objetivo de dicho estudio es recabar y evaluar las distintas alternativas disponiblespara determinar las más adecuadas para el presente proyecto.

2.2. ESTÁNDARES DE INTERCONEXIÓN ENTRE UN COMPU-TADOR Y SUS PERIFÉRICOS

Todo computador cuenta con un subsistema de Entrada/Salida encargado de la comu-nicación con el mundo exterior. Se compone de un conjunto de módulos que comunican laCPU con dispositivos externos definiendo un interfaz, y contienen lógica necesaria paraliberar a la misma de tareas necesarias para esta comunicación como pueden ser el controlde flujo o la conversión serie a paralelo. A diferencia de lo que ocurre con los accesos amemoria en los que la CPU gobierna totalmente el proceso, dado que genera todas lasseñales de control implicadas, en transferencias de E/S la responsabilidad es tanto de laCPU como del propio periférico, puesto que éste es en definitva un elemento que fun-ciona de forma independiente [CSFBAOSS01]. En definitiva, estos módulos controlan yse comunican con periféricos externos de forma paralela a la CPU, al mismo tiempo queaislan a la misma del tipo de periférico y de sus características (velocidad de transmisión,ancho de palabra ...). Se construyen en torno a un estándar para permitir la interconexiónde diversos periféricos de fabricantes distintos.

Los módulos de E/S pueden conectarse directamente al bus del procesador, o a un busdedicado de E/S como se muestra en la figura 2.1). En el caso más común:

• El registro de estado contiene información que permite a la CPU conocer el estadoactual del periférico.

• En el registro de datos se cargan los últimos datos recibidos desde el periférico, o

18 2.2. ESTÁNDARES DE INTERCONEXIÓN ENTRE UN COMPUTADOR Y SUS PERIFÉRICOS

Figura 2.1: Interfaz de E/S para un dispositivo generíco [CSFBAOSS01]

que se desean transmitir (a menudo se emplean colas FIFO para interrumpir menosa la CPU).

• El controlador de interfaz contiene la lógica que controla el periférico según suestándar, además de recibir órdenes desde la CPU y notificarle eventos mediantelíneas de interrupción (no se han representado en la ilustración).

• El módulo de E/S puede así ser capaz de copiar los datos a un destino específico sinintervención de la CPU mediante transferencias DMA1, bien leer o escribir datosde forma activa, o hacerlo como resultado de una interrupción.

A continuación se describen los estándares e interfaces más importantes para la inter-conexión de periféricos con un computador, clasificándolos en tres categorías:

• Serie: Los datos son transmitidos mediante el uso de una sola línea eléctrica.

• Paralela: Los datos son transmitidos mediante el uso de varias líneas eléctricas quetransportan datos de forma simultánea.

• Inalámbrica: No se emplean líneas para la transmisión entre el periférico y el inter-faz, sino que se utiliza algún enlace basado en radio o haz de luz, sin embargo sí seemplean entre el interfaz y la CPU.

1Direct Memory Access o Acceso Directo a Memoria, es como se llama al controlador que permite latransferencia de bloques de información entre dos módulos conectados al bus sin intervención activa de laCPU.

CAPÍTULO 2. ESTADO DEL ARTE 19

2.2.1. Interfaces SerieLas interfaces serie son las más utilizadas debido a su gran flexibilidad y al reducido

número de hilos necesario en comparación con las interfaces paralelas.En este tipo de interfaz los bits viajan uno a uno a través de una línea, y se codifica

cada estado de un bit (cero o uno) con un nivel de tensión. Por lo tanto se necesita algúnmecanismo de control para asegurar que el destinatario de la transmisión captura estosbits en el momento preciso. Es aquí donde se hace la distinción entre interfaces seriesíncronas y asíncronas.

En las interfaces síncronas, las líneas de datos van acompañadas de algún tipo de señalde control, ya sea una señal de reloj, o señales de solicitud y reconocimiento. En el primercaso, el emisor genera una señal de reloj de forma que el bit presente en la línea deja de serválido con el inicio de un nuevo ciclo, momento en el que se coloca el siguiente bit en lalínea, se puede elegir tanto en el flanco ascendente como en el descendente. En el segundocaso, se utilizan dos líneas, una de petición desde el emisor hasta el receptor, y otra dereconocimiento desde el receptor al emisor. El emisor activa la señal de petición al ponerun nuevo bit en la línea, y lo mantendrá hasta que el receptor confirme que lo ha recibidoactivando la línea de reconocimiento, momento en el que se repite el ciclo. Presentan laventaja de que el receptor funcionará a la frecuencia determinada por estas señales decontrol, de esta forma el emisor y el receptor determinan la velocidad de transferencia.

En las interfaces asíncronas, tanto emisor como receptor deben estar sincronizados,puesto que sólo se usan líneas de datos. El emisor envía los bits a una frecuencia deter-minada y el receptor debe capturarlos en los instantes de tiempo precisos, por lo tantoel desvío entre los relojes de emisor y receptor debe ser mínimo. Por otra parte es ne-cesario enviar información de sincronización, en unos casos marcando el inicio de unatransferencia para que el receptor sepa cuando debe empezar a capturar, o en otros utili-zando codificaciones como Manchester, que no utiliza niveles de tensión para señalizar elestado de un bit, sino transiciones entre estos.

Las interfaces serie asíncronas suelen implementar control de errores mediante un bitde paridad. La velocidad de transferencia se mide en baudios, que en este caso coincidecon bits por segundo.

Interfaz Serie RS-232Se trata de la norma definida 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 unmodem, pero puede ser otro dispositivo). La transmisión puede ser asíncrona o síncrona,utilizándose niveles de tensión de -3 a -15 V para el nivel bajo lógico y de +3 a +15 V parael nivel alto. Está diseñado para distancias cortas (hasta 15 metros), y para velocidades detransmisión de no más de 20 kilobytes/segundo.

Para la comunicación asíncrona se genera un bit de inicio de la transmisión (nivel ba-

2Electronic Industries Alliance


Figura 2.2: Cronograma de una transmisión 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 final de la transmisión (nivel alto), así como un bit de paridad opcional(véase fig 2.2). Cuando la línea está inactiva permanece a nivel alto. Permite la comunica-ción simplex, half duplex o full duplex, con líneas dedicadas para el control de flujo. Estoes útil en el caso de que el receptor procese los datos a una velocidad menor de la que losreciba, ya que puede señalizar al emisor para que detenga temporalmente la transmisión.

La conexión se realiza mediante un conector de tipo DB-25, pero es más común en-contrar conectores de tipo DB-9 (fig 2.3), más baratos y pequeños.

El módulo de E/S encargado de la comunicación serie se llama UART (Transceptorasíncrono universal), o USART (Transceptor síncrono y asíncrono universal). La granmayoría de los PCs incorporan al menos uno, pero debido a la pérdida de popularidad deeste tipo de enlace en los últimos años, cada vez es más dificil encontrarlo, sobretodo enequipos portátiles.

USBUSB es en la actualidad el interfaz de facto para la conexión de periféricos a un

computador. El estándar USB fue libreado en 1996 por Compaq, NEC, Northern Tele-com, IBM, DEC, Intel y Microsoft, consorcio conocido como el USB-IF3 que respalda

3USB Implementers Forum


su estandarización. La principal razón que propició su desarrollo fue que los puertos RS-232 y Centronics tradicionales se estaban empezando a convertir en un cuello de botella amedida que la tecnología avanzaba, además de otras razones como la necesidad de incre-mentar el número de puertos disponibles o el no tener que adquirir tarjetas especiales, queconsumían recursos limitados del PC (rangos de memoria y líneas de interrupción que seconfiguraban manualmente).

Proporciona una gran flexibilidad en cuanto a que admite la conexión de una enormediversidad de periféricos, así como otras características como la capacidad de multiplicarel número de puertos disponibles mediante el uso de concentradores USB, la conexión yconfiguración en caliente (sin apagar la máquina) de hasta 127 dispositivos en el mismobus, o el hecho de que proporciona alimentación a los periféricos de forma que si suconsumo se encuentra dentro de unos límites no es necesaria una fuente de alimentaciónexterna.

La especificación inicial (USB 1.0) soporta únicamente la velocidad de 1.5 Mbps paradispositivos lentos como teclados o joysticks. Estos dispositivos son llamados de bajavelocidad.

En 1998 se publicó una revisión: USB 1.1, en la que se añadió un nuevo tipo detransferencia para facilitar el desarrollo de periféricos de interfaz humana como ratoneso teclados y el incremento de la velocidad de transferencia hasta 12 Mbps definiendola clase de dispositivos de velocidad completa, utilizado para dispositivos más rápidoscomo las unidades de almacenamiento.

Posteriormente, en el año 2000 se liberó la especificación USB 2.0, con el anexoal USB-IF de las compañias Lucent, Philips y HP. Su principal mejora respecto a supredecesor fue un gran incremento en la velocidad de transferencia, llegando hasta los480 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 soportarloporque han de permitir la convivencia de tráficos de tres velocidades distintas, lo que loshace más complejos. Para garantizar la compatibilidad, un concentrador 2.0 al que se leconecta un dispositivo más lento adapta la velocidad de forma adecuada. Los fabricantesoptan por seguir fabricando dispositivos que cumplen la norma USB 1.1 si no necesitangrandes tasas de transferencia para mantener la compatibilidad con equipos viejos.

En 2001 el USB-IF, de la necesidad de comunicar distintos periféricos entre sí sin lanecesidad de un computador equipado con un host USB, publicó la especificación USBOTG (On The Go), que define una norma según la cual los periféricos pueden imple-mentar una funcionalidad de host reducida para la comunicación directa punto a punto dedispositivos tales como cámaras fotográficas e impresoras.

El 17 de Noviembre de 2008, se anunció que la versión 1.0 de la especificación deUSB 3.0 estaba completa. El nuevo estándar, también conocido como SuperSpeed USB,proporciona un nuevo modo de transferencia de 4.8 Gbps, pudiedonse obtener 3.2 Gb-ps reales tras la carga que supone el protocolo. En modo SuperSpeed, la comunicaciónes full-dúplex puesto que existen dos pares de líneas diferenciales nuevos para la comu-


Figura 2.4: Diagrama del conector USB 3.0

nicación en ambos sentidos. El host no interroga constantemente al dispositivo, lo queredunda en una gestión mucho más eficiente de la energía. USB 3.0 proporciona hasta900 mA de corriente, suponiendo un incremento del 80 % respecto a su predecesor. Semantiene la retrocompatibilidad con USB 2.0 y anteriores pero el conector cambia lige-ramente para acomodar las nuevas líneas, aunque los conectores tradicionales de tipo Apodrán conectarse a receptáculos 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 estén disponi-bles a partir de 2010.

Los componentes de USB son tres:

• Host: Es el módulo de E/S encargado de controlar todo el bus, asignar direccio-nes, gestionar la potencia y la alimentación, controlar errores y comunicarse con elcomputador. Los ordenadores personales pueden estar equipados con más de uno.

• Concentrador: Permite conectar varios dispositivos USB a un solo puerto gestionan-do todos los aspectos relacionados con su enumeración y funcionamiento. Puedeservir como fuente de alimentación adicional.

• Dispositivo: Es el periférico propiamente dicho, actua como extremo en la comuni-cación

El estándar USB define desde las especificaciones lógicas hasta las mecánicas paraconseguir la mayor compatiblidad entre dispositivos fabricados por distintas compañías.

Utiliza una topología basada en estrella (fig 2.6). Cada dispositivo se conecta a unpuerto del concentrador raíz, o a otro concentrador lo que permite acoplarlos en cascadapara multiplicar el número de puertos disponibles y conectar hasta un total de 127 dispo-sitivos. La conexión es muy rápida y sencilla y no es necesario reiniciar el sistema ya que


Figura 2.5: Tipos A y B del conector USB

Figura 2.6: Topología de USB 2.0 y predecesores

el concentrador raíz es notificado de la conexión y desconexión de nuevos dispositivos yéste es configurado y puesto en marcha de inmediato.

Presenta gran inmunidad al ruido debido a que para la transmisión de datos se empleaun par de cables trenzados con señal diferencial y apantallados, que proporcionan unacomunicación half-duplex (o de un solo sentido simultáneamente). La longitud máximadel cable es de alrededor de 5 metros [Axe05]. También se incluyen dos líneas que pro-porcionan 5V de alimentación (hasta 500 mA) y tierra, que en muchos casos es suficientepara alimentar el periférico.

Los datos se transmiten en código NRZI (No retorno a cero invertido), que incluyeinformación de sincronización.

Los dispositivos USB contienen en su memoria información sobre sus características,entre las principales y comunes a todos:

• Norma USB soportada (1.0, 1.1 o 2.0)


• Ancho de banda requerido

• Potencia consumida

• Datos del fabricante y número de serie

Esta información se organiza en descriptores, que forman un código binario.Cuando el dispositivo se conecta, el hub más cercano detecta una variación de tensión

entre sus líneas de datos. En este momento el periférico pasa por un proceso llamadoenumeración en el que el host lo reconoce, le asigna una dirección (única en el bus), unancho de banda máximo y notifica al sistema operativo de su presencia, el cual intentarácargar un controlador compatible. Durante este proceso, el host interroga al dispositivoobteniendo sus descriptores que le proporcionan la información necesaria para llevar acabo esta tarea.

Para iniciar la comunicación el host envía un comando acompañado de la direccióndel 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 notificación al host de la cone-xión de un nuevo dispositivo, o la asignación de una dirección de bus.

• Interrupción: Son utilizadas por los dispositivos que requieren la atención eventualdel host, fundamentalmente dispositivos de interfaz humana como joysticks, ratoneso teclados.

• Masiva o Bulk: Se usan para transmitir grandes bloques de datos de forma eficienteque usan todo el ancho de banda disponible. Su uso está centrado en dispositivos dealmacenamiento, impresoras, etc.

• Isócrona: Estas transferencias garantizan una latencia máxima pero no que los datossean correctos, tienen un ancho de banda mínimo garantizado. Se utiliza cuando serequiere una tasa de transferencia constante y resulta aceptable perder datos. Casosde uso frecuente son dispositivos de audio y vídeo.

Es preciso señalar que las velocidades máximas de USB no son reales puesto que enla realidad el intercambio de transferencias de control y para otros propósitos consumenuna parte.

Los dispositivos USB que llevan el logotipo oficial del USB-IF han superado un pro-ceso de validación del dispositivo. Para obtener esta validación se han de realizar una seriede pruebas, estas dependen del tipo de dispositivo y de su velocidad. Finalmente hay queenviar al USB-IF un formulario con la información sobre el dispositivo y el resultado delos tests [UIa].


Figura 2.7: Conectores Firewire

IEEE-1394 o FireWireEl IEEE-1394, también conocido como Firewire es el estándar de comunicaciones de

alta velocidad desarrollado por Apple y Sony a mediados de los 90. Es un estándar parala conexión a dispositivos que requieren gran ancho de banda y que ha sido rápidamenteadoptado. Sus principales características son:

• Alcanza una velocidad sostenida de 400 Mbps.

• Permite la conexión de un máximo de 63 dispositivos, que pueden comunicarseentre sí.

• Acepta longitudes de cable de hasta 4.25 m.

• Puede garantizar una distribución de los datos en perfecta sincronía.

• Permite la desconexión y conexión durante el uso sin tener que reiniciar el sistema(plug & play).

• Se alimenta por el propio bus, proporcionando hasta 25 V, suficiente para muchosdiscos duros de alto rendimiento y baterías de carga rápida.

Todo lo anterior lo hace idóneo para aplicaciones multimendia como la edición de vídeodigital en la que se requiere una alta tasa de transferencia y se precisa una latencia mínima.

En la actualidad, tanto PCs como Macintosh están equipados con puertos FireWire,y existe en el mercado una amplia gama de dispositivos desde reproductores de vídeo,sistemas de entretenimiento doméstico, dispositivos de grabación de audio profesionalhasta unidades de almacenamiento masivo.

Dada su superioridad en cuanto a ancho de banda respecto a USB, es un estándar atener en cuenta para el tipo de aplicaciones anteriormente mencionadas, pero presenta ladesventaja de ser más caro de implementar.

2.2.2. Interfaces ParalelasLas interfaces paralelas se caracterizan por transmitir varios datos por líneas indepen-

dientes de forma simultanea, lo que permite aumentar el ancho de banda. El tradicional


puerto paralelo, basado en conector DB-25 está también desapareciendo progresivamen-te debido a sus prestaciones, lo que lleva a que los fabricantes opten por interfaces másmodernos para la conexión de sus dispositivos.

Puerto paralelo CentronicsFue diseñado por la compañia Centronics Data Computer Corporation para sus pri-

meras impresoras matriciales empleando un conector de 36 pines que rápidamente pasó aconocerse como conector Centronics.

Posteriormente, cuando IBM implementó el interfaz paralelo en el IBM PC, emplea-ron el conector DB-25 en el lado del PC, dejando el conector original de 36 pines en ellado de la impresora.

Consta de 8 líneas de datos, y otras 10 de control, utiliza niveles de tensión TTL ysoporta velocidades de hasta 100 Kbytes/s.

Es muy susceptible al ruido electromagnético debido a que las líneas no están balan-ceadas y la norma no define ningún tipo de blindaje.

Más tarde fue reemplazado por el estándar IEEE-1284, que especifica los modos adi-cionales EPP4, ECP5, el modo 4 bits y el modo 8 bits. Estos nuevos modos permiten lacomunicación bidireccional y el control de errores incrementando las tasas de transferen-cia debido a que los protocolos son implementados por hardware.

En el caso de los PC, la BIOS permite seleccionar el modo de operación del puertoparalelo.

2.2.3. Interfaces InalámbricasBluetooth

Bluetooth es un conjunto de especificaciones definidas por el Bluetooth Special Inter-est Group para el intercambio de datos sin cables a través de cortas distancias. Trabaja enla banda ISM de 2.4 GHz. Puede conectar varios dispositivos en redes de área personal(PAN) gestionando la sincronización.

Para la transmisión utiliza una tecnología llamada «frequency hopping spread spec-trum», o espectro expandido por salto de frecuencias que cambia la frecuencia de trans-misión de acuerdo a un patrón basado en 79 frecuencias distintas en su modo básico. Estesistema permite alcanzar una tasa de transferencia de datos de 1 Mbit/s.

Bluetooth proporciona una forma de conectarse e intercambiar información entre dis-positivos como teléfonos móviles, ordenadores, impresoras, sistemas GPS, cámaras digi-tales y consolas de videojuegos entre otros. Esto se consigue mediante el uso de perfilesque agrupan las características comunes a una clase de dispositivos (audio, teclados, al-macenamiento, ...).

4Enhanced Parallel Port, o Puerto Paralelo Mejorado5Extended Capabilities Port, o Puerto con capacidades extendidas


Existen tres clases de dispositivos según la potencia consumida y su alcance, variandoentre 1 y 100 metros.

La versión 2.0+EDR6 alcanza los 3 Mbits/s.La especificación Bluetooth está basada en un protocolo formado por capas:

• LMP (Link Management Protocol) Utilizado para controlar el enlace de radioentre dos dispositivos. Se implementa en el controlador.

• L2CAP (Logical Link Control & Adaptation Protocol) Se utiliza para multiple-xar múltiples conexiones lógicas entre dos dispositivos usando diferentes protoco-los de más alto nivel. Proporciona segmentación y reensamblado de los paquetestransmitidos.

• SDP (Service Discovery Protocol) Permite a los dispositivos descubrir qué servi-cios soportan los otros, y qué parámetros se utilizan para conectarse a ellos. Cadaservicio se identifica con un UUID7.

• HCI (Host/Controller Interface) Estandariza la comunicación entre la pila de ca-pas del protocolo Bluetooth y el controlador (el circuito integrado Bluetooth). Estaestandarización permite reemplazar el circuito integrado con cambios mínimos.

Según los protocolos utilizados se necesitan capas adicionales.Cada dispositivo Bluetooth puede comunicarse con hasta siete dispositivos en un gru-

po de usuarios inalámbrico ad-hoc de hasta 8 dispositivos, conocido como piconet.

2.3. MICROCONTROLADORES

Se entiende como controlador un sistema especializado y encargado de controlar unproceso o un conjunto de procesos altamente relacionados entre sí. Este tipo de dispositi-vos ha evolucionado desde su construcción exclusivamente con lógica discreta hace tresdécadas, a su implementación mediante el uso de un microprocesador rodeado de todasu circuitería de soporte (memoria, lógica de selección, de interrupciones, E/S ...) en unatarjeta de circuito impreso, y finalmente a la miniaturización de todos estos componentesen un solo chip, denominado microcontrolador.

Las razones principales para el uso de un microcontrolador en lugar de una máquinade propósito general son [Per05]:

• Gestión eficiente de procesos

• Aumento de la fiabilidad

• Reducción del tamaño, consumo y coste6Enhanced Data Rate, o Tasa de datos mejorada7Universally Unique Identifier o Identificador universalmente único

28 2.3. MICROCONTROLADORES

• Mayor flexibilidad

Por tanto un microcontrolador es un circuito integrado que contiene los elementos deun computador minimalista para gobernar o controlar parte de un sistema mayor en elque, gracias a su reducido tamaño, suele estar incorporado. Al estar dotados de un altogrado de especialización, contienen periféricos de aplicación específica.

Según [Axe97] se pueden encontrar microcontroladores en todo tipo de cosas en laactualidad. Cualquier dispositivo que mida, almacene, controle, calcule, o visualice infor-mación es un candidato para ser gobernado por un microcontrolador. El uso más extendidode estos lo encontramos (como puede verse en la figura 2.8) en el sector de la informá-tica, donde pueden encontrarse en periféricos tales como teclados o impresoras. Son unproducto de la rápida evolución de la tecnología.

Figura 2.8: Utilización de microcontroladores por cada sector

Puesto que los microcontroladores, como ya se ha explicado son sistemas especializa-dos para una aplicación concreta, y no máquinas de propósito general como podría serloun PC, existe en el mercado una inmensa cantidad modelos, que ofrecen muy diversascombinaciones de características. Mientras que unos presentan cantidades de memoriaRAM mayores, otros disponen de características DSP8, e incluso recientemente han apa-recido microcontroladores con características tan exóticas como la integración en el mis-mo chip de lógica programable [ST], o microcontroladores compuestos por varias CPUsindependientes [Par]. De esta manera es responsabilidad del ingeniero realizar la eleccióncorrecta atendiendo a los requisitos de la tarea para la que se va a emplear con el fin deminimizar los costes de hardware y software, aspecto de vital importancia si se opta porla producción masiva del producto final.

Los principales factores a tener en cuenta en la elección de un microcontrolador son:

• Velocidad8Digital Signal Processing o Procesado Digital de Señal es una arquitectura SIMD que permite la apli-

cación de operaciones sobre conjuntos de datos de forma eficiente.


Es necesario asegurarse de que el sistema va a ser capaz de ejecutar su tarea enel tiempo requerido.

• Número y tipo de líneas de Entrada y Salida

Estas deben ofrecer un interfaz adecuado para los sensores o el resto de com-ponentes del sistema para minimizar la circuitería externa necesaria.

• Herramientas de desarrollo disponibles

Es imprescindible poder contar con el software (compilador, depurador, docu-mentación), y el hardware (programador/ICD 9).

En su memoria ROM sólamente reside un programa encargado del control de unaaplicación determinada (tareas típicas de estos son la adquisición de datos desde sensores,la comunicación de información o el control de otros dispositivos externos). Al ser unprograma de aplicación específica, que reside en una memoria de estado sólido, y quegestiona el hardware a bajo nivel, podemos catalogarlo como firmware. Estos programasse ejecutan en bucle infinito, ya que corren sobre la máquina desnuda y no existe unsistema operativo subyacente al que devolver el control tras la finalización del mismo.

El firmware debe ser cargado en la memoria no volátil del microcontrolador, a esteproceso se conoce como programación. Los microcontroladores suelen ser programadoscon la ayuda de un dispositivo programador específico proporcionado por el fabricante,aunque hoy en día casi todos ofrecen la característica de reprogramabilidad ICSP10.

Una vez programado, el microcontrolador queda listo para ejecutar el código firmwareresidente en su memoria.

Debido a la gran variedad existente en el mercado, que ofrece innumerables familiasde microcontroladores se pueden hacer muchas clasificaciones, siendo uno de los factoresmás significativos para ello la cantidad y tipo de periféricos integrados, que comúnmentesuelen ser:

• CPU

• Memoria ROM (EEPROM/PROM/FLASH) para almacenamiento del programa ydatos constantes.

• Memoria RAM para almacenamiento de variables.

• Dispositivos de comunicación y control

– USART, I2C, SPI, Paralelo, USB, Ethernet9In Circuit Debugging, o Depuración en Circuito es un método que permite depurar la aplicación firm-

ware sin tener que extraer el microcontrolador de su ubicación en la placa de circuito impreso del sistemamicrocontrolado.

10In-Circuit Serial Programming, o programación serie en el circuito se entiende como la capacidad de serreprogramados en la propia placa de circuito impreso en la que estan instalados sin necesidad de extraerlos.

30 2.4. DISPOSITIVOS HASP

– Comparadores de tensión analógicos

– Controladores

– Puertos de E/S digitales

– Conversores A/D y D/A

– Moduladores de señal por anchura de pulsos (PWM)

• Multiplicadores de frecuencia de reloj (PLL), divisores de frecuencia y osciladoresincorporados

• Watchdog 11

• Circuitería adicional de soporte a todo lo anterior (lógica de selección, arbitrado debuses, circuitos de protección ...)

Otro factor relevante para establecer una clasificación es el ancho de palabra de laCPU, siendo los más comunes de 4 y 8 bits por ser económicos y suficientes para muchasaplicaciones.

Los principales fabricantes de microcontorladores son Microchip, Freescale, Intel,Texas Instruments, Philips, Renesas, Cypress Semiconductor y National Semiconductorentre otros, pero es la gama de microcontroladores PIC del fabricante Microchip la quegoza de mayor popularidad entre profesionales y aficionados. Este éxito se debe en granparte a su precio, su disponibilidad y sus herramientas de desarrollo.

2.4. DISPOSITIVOS HASP

El término HASP viene de las siglas inglesas Hardware Against Software Piracy, ohardware contra la piratería del software. Reciben este nombre los dispositivos destina-dos a limitar el uso de un determinado software a su legítimo propietario y evitar así ladistribución ilegal que se produce rápidamente por Internet, y en menor medida por otrosmedios.

Esta tecnología, debido al incremento de coste que supone se suele implementar enpaquetes de software muy costosos y software de mercado vertical, como CAD o ediciónde audio profesional, donde las pérdidas económicas derivadas del uso ilegal pueden sersignificativas.

Un dipositivo HASP debe estar conectado físicamente a la máquina que ejecuta elsoftware durante todo el periodo de uso del mismo.

La protección más débil consiste en que el software compruebe si el dispositivo estápresente, lo que suele implementarse como una función que devuelve simplemente «true»o «false». El ataque a esta protección consiste en desensamblar y trazar el programa pa-ra aislar la instrucción de salto condicional que hace que el software funcione o no. La

11Sistema basado en un temporizador que evita que el dispositivo quede atrapado en un bucle infinito, obloqueado por otra causa.


instrucción se reemplaza con otra que siempre salta a la misma dirección incondicional-mente, lo que da lugar a un ejecutable parcheado.

Un sistema más seguro y más utilizado consiste en el intercambio contínuo de mensa-jes cifrados entre el host y el dispositivo. De esta manera el dispositivo debe ejecutar unalgoritmo capaz de mantener este diálogo, lo que requiere de información secreta codifi-cada únicamente en los dispositivos HASP originales.

Los dispositivos HASP modernos incorporan como ya se ha comentado encriptación,y técnicas de fabricación destinadas a evitar la ingeniería inversa. Típicamente incluyenmemoria no volátil donde almacenan información sobre la licencia y un microprocesadorque ejecuta partes del software en el propio dispositivo, convirtiendose así en criptopro-cesadores seguros.

Sin embargo los investigadores de seguridad advierten que los dispositivos aún nosolucionan el problema del «trusted client», de forma que si se le da a un usuario unmensaje cifrado, el algoritmo y la clave, el sistema es potencialmente inseguro, inclusocon el algoritmo y la clave codificados en el hardware [Gra05].

Por otro lado, si esto sucede los dispositivos HASP pueden ser clonados, producién-dose versiones no autorizadas del mismo, o creando drivers emuladores que simulan laconexión y el comportamiento del dispositivo.

Los dispositivos HASP con reloj contienen un reloj de tiempo real independiente aldel sistema operativo para los fabricantes que requieren manejar períodos de uso acotadoscomo el alquiler.

La empresa líder en tecnologías hardware de seguridad es Aladdin, que cuenta conun catálogo de llaves HASP USB que implementan encriptación AES de 128 bits, y uncompleto sistema de certificados, firmas digitales y validación telemática tanto para va-lidación 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 ADQUISICIÓN DE DATOS (DAQ)

Los sistemas de adquisición de datos se utilizan para medir y registrar señales quepueden ser obtenidas de dos maneras:

• Las que se originan a partir de la medición directa de magnitudes eléctricas, com-ponentes contínuas, frecuencias y resistencias.

• Las que se originan a partir de transductores, como galgas extensiométricas o ter-mopares.

Las operaciones esenciales de un sistema de adquisición de datos incluyen la ma-nipulación de señales analógicas, medición, conversión y manejo de datos digitales, yprogramación y control interno. Un sistema de adquisición de datos digital se componede los siguientes elementos:

32 2.5. DISPOSITIVOS DE ADQUISICIÓN DE DATOS (DAQ)

Figura 2.9: Ejemplo de señal digital ideal

2.5.1. Componentes• Transductor: Transforma parámetros físicos en señales eléctricas, reconocibles por

el sistema de adquisición.

• Acondicionamiento de señal: Es un subsistema que contiene la circuitería que dasoporte al transductor. Por lo general esta circuitería puede proporcionar la ener-gía de excitación, circuito de equilibrio y elementos de calibración específicos deltransductor. También amplifica, modifica o filtra ciertas partes de la señal de salidaproporcionada por el transductor a unos niveles aceptables por las siguientes fases.

• Multiplexor: Acepta varias entradas analógicas y las conecta secuencialmente a uninstrumento de medición.

• Conversor analógico-digital (ADC o Analog to Digital Converter). Convierte el vol-taje analógico a su equivalente digital. Es el único elemento totalmente indispensa-ble de un sistema de adquisición de datos, y podría constituir uno por sí mismo.

• Unidad de proceso de datos: Colecciona, monitoriza y almacena los datos tomados.

Hay muy diversos tipos de dispositivos de Adquisición de Datos que se pueden clasi-ficar atendiendo principalmente al tipo de señales que adquieren:

DigitalLas señales digitales, en contraste con las señales analógicas, no varían en forma con-

tinua, sino que cambian en pasos o en incrementos discretos. La mayoría de las señalesdigitales utilizan códigos binarios o de dos estados.

En el marco de este proyecto, las señales digitales se asocian a los pulsadores, ya queestos tienen dos estados (pulsado/no pulsado) al igual que la señal.

AnalógicaLas señales analógicas varían de forma contínua. Los transductores analógicos suelen

generar una señal eléctrica analógica de valor (voltaje) proporcional a la magnitud medida


Figura 2.10: Ejemplo de señal analógica

(presión, temperatura, ángulo de giro...). Un ejemplo de transductor es una célula fotovol-taica, que genera a su salida una corriente proporcional a la intensidad de luz incidente enella, o el potenciómetro que produce como salida un cambio en la resistencia, relacionadacon la posición angular del eje.

En nuestro caso las señales analógicas se asocian con las palancas y joysticks, ya queen última instancia están construidos con potenciómetros, que son transductores analógi-cos, y tienen un recorrido contínuo y suave.

Las señales analógicas plantean además el problema de su conversión. Al necesitartransmitirse a un sistema inherentemente digital como lo es un computador, tienen quepasar por una fase de conversión previa, llamada muestreo.

El dispositivo encargado de realizar esta conversión se denomina conversor A/D (Analó-gico a Digital).

2.5.2. Conversor Analogico-Digital (ADC)El conversor analógico-digital es como ya se ha dicho el elemento más importante

de un sistema de adquísición de datos. Existen varios tipos de conversor, según la cir-cuitería empleada para realizar la conversión, pero todos tienen en común los siguientesparámetros que pueden evaluarse como factores de calidad:

• Tiempo de conversión: Se conoce como tiempo de conversión al tiempo que trans-curre desde que comienza una conversión hasta que esta finaliza y se obtiene el datocorrespondiente a la salida.

• Cuantificación: Es la división del recorrido de la señal en un rango de valores dis-cretos. Este parámetro es importante ya que determina el nivel de detalle.

2.5.3. Dispositivos de adquisición de datos integradosLos dispositivos de adquisición de datos integrados contienen toda la circuitería ne-

cesaria en una carcasa, y se comunican mediante algún 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 acce-so a la información a través de un interfaz de programación (API).

• Tienen un consumo elevado y requieren una fuente de alimentación externa.

• La precisión con que se realizan las medidas suele ser excesiva para el propósito deeste proyecto.

2.5.4. Dispositivos de juegosLos dispositivos de juego como joysticks o gamepads son un buen ejemplo de cómo

se traducen las pulsaciones y movimientos del usuario en un flujo de datos comprensiblepor una aplicación, por lo que les prestamos especial atención.

Al estar destinados a un público general, son dispositivos de sobremesa que propor-cionan en la actualidad conectividad y compatibilidad mediante el uso del bus USB omediante tecnologías inalámbricas como Bluetooth.

2.6. ARQUITECTURA DE UN SIMULADOR

Un simulador está formado principalmente por tres módulos interconectados entre síy cada uno con una misión específica como puede verse en la figura 2.11.

El Subsistema de simulación dinámica es el encargado de simular algorítmicamenteel comportamiento físico de los elementos que intervienen en la simulación, incluyendolas leyes de la física y cómo estas les afectan. Recibe la entrada del usuario, de esta formael estado de la simulación puede verse afectado por la acción del mismo.

El Subsistema visual tiene como única tarea representar la información de la simula-ción de manera visual, es decir: genera todos los gráficos visibles por el usuario. Recibela información del estado actual del subsistema de simulación dinámica para generar ima-genes actualizadas.

El Puesto de control permite al operador realizar operaciones como iniciar o parar lasimulación, y otras tareas como la recolección de estadísticas sobre la sesión y el progresodel alumno.


Figura 2.11: Arquitectura de un sistema de simulación

36 2.6. ARQUITECTURA DE UN SIMULADOR

CAPÍTULO 3

METODOLOGÍA Y MATERIALES

3.1. METODOLOGÍA

En la actualidad, el desarrollo de casi todos los proyectos se apoya en una metodo-logía de trabajo, por lo general depurada desde la experiencia adquirida con anterioresproyectos.

La metodología del diseño siempre suele ser dependiente de la naturaleza del pro-yecto así como de los requisitos impuestos y las preferencias del personal a cargo de suejecución.

Esta trata de cuantificar y planificar los aspectos más fundamentales del proyecto co-mo los recursos necesarios (materiales y de personal), y el coste temporal y económicoderivado del mismo.

El desarrollo del presente proyecto se ha dividido en ocho fases que se enumeran acontinuacíón:

• Revisión bibliográfica. Para comenzar, se realiza una recopilación de informaciónacerca de las plataformas sobre las que se va a trabajar, así como memorias detrabajos similares a este.

• Especificación de requisitos. En esta fase se definirán los requisitos que debe cum-plir el producto final, definiendo parámetros como el rendimiento y consumo eléc-trico requeridos, o tamaño. También se analiza el alcance del proyecto y las distintasalternativas disponibles.

• Definición de la arquitectura del sistema. Aquí se realizará una selección de loscomponentes más apropiados de forma que se cumplan los requisitos. También seestudiarán alternativas para otros aspectos como la conexión con el computador, laarquitectura del software, o el diseño del sistema HASP.

• Diseño e implementación del hardware y software. En este apartado se lleva a cabo,una vez definidas las especificaciones, la arquitectura y los componentes, el desa-rrollo de los esquemas de la circuitería y la construcción de un prototipo inicial en

38 3.2. PLANIFICACIÓN DE RECURSOS MATERIALES Y HUMANOS

una placa proto-board, ya que los simuladores de depuración de los microcontrola-dores presentan limitaciones que pueden limitar el correcto testeo del dispositivo,como las fluctuaciones en las entradas, o la comunicación USB con el computador.También se desarrolla todo el software que corre tanto en el microcontrolador comoen el PC.

• Pruebas y depuración. En esta fase se prueba el prototipo inicial para comprobarque cumple las especificaciones y que por lo tanto es seguro pasar a la siguientefase del diseño sin que ello repercuta en pérdidas económicas.

• Diseño del prototipo final. Con la arquitectura hardware y software validada, seprocede al diseño de una placa de circuito impreso, o PCB usando un programade CAD, que genera ficheros de fabricación de PCBs estándar. A continuación sefabrica una placa de forma manual mediante el insolado, se programa el microcon-trolador y se monta junto con el resto de los componentes.

• Pruebas finales. Una vez fabricado el prototipo se realizan una serie de pruebas paracomprobar su correcto funcionamiento antes de pasar a la fase final.

• Redacción. Finalmente se realiza la redacción de la presente memoria del proyectoque incluye el procedimiento seguido y los resultados obtenidos.

3.2. PLANIFICACIÓN DE RECURSOS MATERIALES Y HUMA-NOS

En esta planificación se tienen en cuenta los recursos necesarios para el desarrollo delproyecto y la fabricación del prototipo. Los costes asociados se mostrarán en el capítulo«Presupuesto».

3.3. MATERIAL

3.3.1. SoftwareDurante el desarrollo de este proyecto se han utilizado Microchip MPLAB, CCS PICC

PCWH, Microchip C18, Microchip MPASM, USB-IF Descriptor Tool, Eagle, MicrosoftWindows DDK, Visual C++ Express y el sistema operativo Windows XP x64 Edition,que se pasan a describir a continuación:

Microchip MPLABSe trata del entorno de desarrollo integrado de Microchip para toda su familia de

microcontroladores. Integra un conjunto de herramientas para el trabajo con estos dispo-sitivos, entre las más destacadas:

• Editor de texto. Permite la edición del código fuente y colorea la sintaxis.

CAPÍTULO 3. METODOLOGÍA Y MATERIALES 39

• Simulador. Visualiza en pantalla el estado de la máquina: registros, memoria (RAM/ ROM / EEPROM / ...), periféricos... También muestra la dirección de la instrucciónen ejecución y su traducción en lenguaje de alto nivel asociada. Permite generarestímulos en sus pines de entrada y visualiza las salidas.

• Programador. Con la ayuda de un dispositivo programador compatible, carga elfirmware compilado en la memoria ROM del microcontrolador y verifica los datosescritos. También escribe la palabra de configuración, establece algunas informa-ciones del usuario y permite borrar el chip.

• Depurador ICD. Mediante un dispositivo depurador compatible, carga en el mi-crocontrolador un subprograma que se comunica con el PC para monitorizar en elpropio chip el estado de la ejecución.

• Configurador de dispositivo. Posibilita la edición de la configuración del dispositivoy la visualiza en una forma legible por humanos.

• Integrado con compiladores como C18, CCS PICC, o HI-TECH, y con ensambla-dores como MPASM.

Microchip MPASMEnsamblador para la familia de microcontroladores PIC, se suministra con archivos

de cabecera que definen constantes simbólicas que contienen definiciones específicas paracada tipo de microcontrolador. Está integrado en MPLAB y es gratuito.

Microchip C18C18 es el compilador de lenguaje C de Microchip para la familia de microcontrolado-

res PIC18. El lenguaje compilado sigue la especificación C, pero no cumple el estándarANSI/ISO debido a algunas restricciones dependientes de la plataforma, y a la inclusiónde algunas palabras clave cualificadoras, como la palabra rom, que colocada delante deltipo de dato en una declaración de variable especifica que se trata de una constante al-macenada en memoria ROM. Incluye multitud de librerías para el manejo de alto nivelde los recursos del chip, y proporciona construcciones del lenguaje orientadas a tareasespecíficas de bajo nivel como la atención de interrupciones o la inclusión de fragmentosescritos en código ensamblador.

Se integra completamente con con el entorno de desarrollo integrado MPLAB y cuentacon una versión de estudiante gratuita con la única limitación de dejar de hacer optimiza-ciones sobre el código generado tras un periodo de tiempo desde su instalación.

CCS PICC PCWHEl compilador CCS PICC es una potente herramienta para el desarrollo de firmware

escrito en C para microcontroladores PIC.

40 3.3. MATERIAL

Como ventajas frente al compilador C18 de Microchip, la edición PCWH de PICCsoporta las familias de microcontroladores PIC10, PIC12, PIC16,y PIC18. Y la edicióncompleta (PCWHD) soporta además de los anteriores, la familia de microcontroladoresde 16 bits PIC24, y la familia con DSP integrado dsPIC.

PICC genera código más pequeño que C18 puesto que tiene 307 funciones prepro-gramadas en patrones de código parametrizables y accesibles al usuario como llamadas afunciones C, en lugar de estar programadas en código C en librerías separadas que han deser también compiladas.

Es posible localizar variables y fragmentos de código en posiciones específicas dememoria, entre las herramientas de depuración incluye una variante de la llamadas a lafunción printf y scanf de la librería estandar de C para la depuración por el puerto RS-232.Otra de sus principales características es que mediante la definición de la frecuencia deloscilador, y de la configuración, PICC parametriza automáticamente todas las caracterís-ticas 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 referenciapara diseños 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 toolSe trata de una herramienta diseñada por el USB Implementers Forum, de uso gratuito

y disponible para su descarga en su página web que asiste al diseño de descriptores paradispositivos USB de tipo HID1.

Presenta un editor de descriptores que muestra al usuario una lista de todas las posiblesopciones en cada momento. Una vez completo permite la validación del mismo simulandoel comportamiento de la parte software del sistema operativo encargada de ello.

Finalmente convierte el descriptor en lenguaje simbólico a código binario y puedeexportarlo en varios formatos, principalmente un formato interno para poder cargarlo enla misma herramienta y proseguir el trabajo más adelante, o como archivo de cabecera deC .h, donde define un vector de elementos de 8 bits inicializado a sus correspondientesvalores.

EagleEagle es un popular paquete de CAD para el diseño de PCBs. Se compone de tres pro-

gramas: El «Schematic Editor» que sirve para diseñar el esquemático teórico del circuitoy validarlo en base a unas reglas de conectividad eléctrica. El «Layout Editor» genera elfotolito de la placa partiendo del esquema teórico y permite su edición. El «Autorouter»utiliza algoritmos de rutado para dibujar las pistas que conectan los componentes de la

1Human Interface Device, o Dispositivo de Interfaz humana que será explicado en posteriores secciones.


placa, soporta hasta 16 capas de señales y da al usuario a elegir ciertos parámetros basa-dos en costes que influyen en la estrategia de rutado. Finalmente, el «CAM Processor»genera los archivos para su fabricación, ya sea obteniendo un fotolito para insolado, omediante ficheros Gerber estándares para la fabricación en instalaciones equipadas conmaquinaria de control numérico.

Microsoft Windows Server 2003 SP1 DDKMicrosoft Windows Driver Development Kit es un conjunto de herramientas para el

desarrollo de drivers bajo los sistemas operativos Windows. Se compone de librerías, do-cumentación, ejemplos y herramientas para la compilación y prueba de drivers específicospara que un dispositivo hardware en desarrollo funcione bajo Windows Server 2003, Win-dows XP y Windows 2000 tanto en sus ediciones de 32 bits como de 64 bits. Está biensoportado y hay una comunidad de desarrolladores on-line a la que se puede acudir enbusca de ayuda.

Visual C++ ExpressForma parte del entorno de desarrollo Visual Studio 2005 de Microsoft. Compila pro-

gramas escritos en lenguaje ISO C++ a código máquina para producir archivos ejecuta-bles, o a código CLR2, realizando optimizaciones para incrementar la velocidad de eje-cución debido a que hace uso de las instrucciones SIMD del procesador como las SSE2.Cuenta con gran número de librerías como las MFC que simplifica el desarrollo de apli-caciones con interfaz de usuario. La versión express es de uso gratuito, pero carece dealgunas herramientas como el generador de instaladores que empaqueta las aplicacionesdesarrolladas para su distribución.

Windows XP x64 editionLa edición de 64 bits del popular sistema operativo de Microsoft explota las capacida-

des de las CPUs modernas que cuentan con esta arquitectura (AMD64, EM64T), mientraspermite la ejecución de programas escritos para las ediciones de 32 bits mediante el sub-sistema WoW64 (Windows on Windows) que emula el entorno de ejecución de un sistemade 32 bits utilizando unas librerías de traducción que convierten las llamadas a funcionesdel sistema operativo. Sin embargo, requiere drivers diseñados específicamente para estaarquitectura.

3.3.2. HardwareEl hardware utilizado para la realización del proyecto es el siguiente:

2Common Language Runtime es un código desarrollado por Microsoft, que es interpretado por la má-quina virtual .NET runtime framework

42 3.3. MATERIAL

DiseñoPC portátil 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/re-grabadora de DVD y 3 puertos USB 2.0.

Fabricación y montajeProgramador/Depurador Microchip ICD2 para la programación del microcontrolador.

Se empleará un soldador de 40W para el montaje de las placas, un multímetro digitalcon display LCD para su comprobación, y una placa proto-board para realizar el primermontaje.

3.3.3. Planificación y recursos humanosEn cuanto a la distribución de recursos humanos, todas las tareas han sido realizadas

por el proyectista, sin embargo se supone que se dividen las tareas entre un ingeniero alque se le aplica un salario estimado de 11.26 e/hora y un técnico a quien se le aplicaun salario de 8 e/hora. Las tareas del primero son el diseño y programación, y las delsegundo el montaje y fabricación de placas.

En el diagrama de Gantt se puede observar que las tareas de diseño e implementaciónde firmware y software se realizan en paralelo puesto que ambos están íntimamente li-gados. Ambas tareas comienzan una vez construido el prototipo en la placa proto-boardporque es necesario durante la depuración.


Figura 3.1: Diagrama de Gantt

44 3.3. MATERIAL

CAPÍTULO 4

DEFINICIÓN DE REQUISITOS Y ANÁLISISDEL SISTEMA

En este capítulo se van a definir los requisitos que debe cumplir el producto final, parapoder evaluar las alternativas disponibles y elegir las que más se acomoden a ellos, encuanto a hardware (microcontrolador y resto de componentes), como a software (lenguajey herramientas utilizadas).

4.1. ESPECIFICACIÓN DE REQUISITOS

En el primer capítulo se hizo una breve explicación de los requisitos del proyecto.Ahora es el momento de exponerlos todos, definiendolos con más detalle.

4.1.1. Requisitos del hardware• El dispositivo estará conectado físicamente al computador y a los transductores del

dispositivo de control real (botonera).

• El dispositivo será de fácil conexión y desconexión y será compatible con la mayorvariedad de computadores posible.

• Debe tener un tamaño óptimo para su montaje dentro del espacio libre disponibleen una botonera.

El mínimo espacio disponible que se ha observado dentro de las botoneras deuso más común es de 38 x 58 mm, medida que se tendrá en cuenta en el diseño dela PCB

• No requerirá alimentación externa, y tendrá un bajo consumo.

Esto será un factor a tener en cuenta al seleccionar el interfaz de conexión conel computador.

• Debe permitir obtener el estado de 10 sensores digitales, y de 10 sensores que pue-den ser bien digitales o bien analógicos.

46 4.1. ESPECIFICACIÓN DE REQUISITOS

• Tomará muestras sobre el estado de los sensores y comunicará las lecturas de ma-nera adecuada al computador

Lo cual implica seleccionar un microcontrolador equipado con conversoresA/D y que sea suficientemente rápido para ejecutar estas tareas.

• No requerirá la instalación de drivers y será completamente Plug & Play 1.

• El dispositivo validará el software de forma segura, robusta, y no penalizará a aque-llos usuarios que posean una copia legítima del software

Deberá comunicarse con el computador y establecer un diálogo contínuo paraverificar que el dispositivo es válido.

• Tiene que ofrecer dificultades contra la ingeniería inversa de dicha protección.

• El diseño debe ser apto para su fabricación en serie.

4.1.2. Requisitos del software• El firmware contenido en el microcontrolador será actualizable por el usuario final

sin requerir ninguna intervención técnica que implique abrir o desmontar el aparato.

De esta forma se reserva la posibilidad de realizar un mantenimiento del firm-ware post-venta, liberando actualizaciones en caso de que se detecte algún error ose mejore alguna característica.

• La librería del lado del computador se encargará de la monitorización contínua delestado de conexión del dispositivo.

• Será la responsable de asegurarse de que el dispositivo es autentico mediante elintercambio de mensajes.

• Notificará al software protegido de eventos producidos en relación a los apartadosanteriores para que éste pueda actuar en consecuencia.

• Será transparente para el programador.

• Ocupará los mínimos recursos tanto espaciales como temporales en el computadorcomo sea posible.

• Tendrá un diseño modular y estará construida sobre un lenguaje de programaciónde alto nivel y de uso común.

1Conectar y utilizar. Se llama así a los periféricos que no requieren ninguna configuración ni reinicio dela máquina para su puesta en funcionamiento

CAPÍTULO 4. DEFINICIÓN DE REQUISITOS Y ANÁLISIS DEL SISTEMA 47

4.1.3. Requisitos comunes• La arquitectura general debe permitir ampliaciones futuras del sistema como la adi-

ción de más sensores, o la comunicación inalámbrica 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 com-patibilidad con otros.

4.2. ANÁLISIS DE ALTERNATIVAS

Partiendo de los requisitos descritos anteriormente, en esta sección se van a exponerdistintas alternativas y se tomarán las decisiones de diseño necesarias justificándolas encada caso.

4.2.1. Conexión del periférico con el computadorEste debe ser el primer aspecto a considerar, ya que influirá decisivamente en la elec-

ción de los componentes. Debido a las limitaciones de tamaño máximo del PCB, y decoste es deseable que el microcontrolador sea el único circuito integrado. Por lo tantodependiendo del interfaz de comunicación elegido, habrá que seleccionar un microcon-trolador que incorpore un transceptor compatible con el estándar, lo cual a su vez influiráen el resto de componentes.

De los interfaces expuestos en el capítulo 2, que son los más extendidos en el campode la informática, se descartan inmediatamente los interfaces paralelos puesto que nose desean cables complejos, y la aplicación no requiere gran ancho de banda. Siendo elperiodo típico de muestreo de 10 ms.

Otro factor que los descartan es su poca presencia en los equipos informáticos deescritorio de hoy en día.

En cuanto a los interfaces serie, se descarta trivialmente el RS-232 por la misma razónde haber quedado obsoleto, y porque no proporciona alimentación.

Respecto a los inalámbricos, por el momento quedan también descartados ya que re-quieren baterías, que a su vez requieren circuitos de monitorización de carga lo que enca-recerá el precio unitario, no obstante se podrán implementar en un futuro.

Finalmente la decisión se encuentra entre el bus USB y el bus Firewire, por lo quehabrá que hacer una comparación técnica de los factores clave de ambos para poder tomarla decisión.

Como se ha expuesto anteriormente, tanto USB como FireWire permiten la conexiónde diversos dispositivos al computador, pero la velocidad de FireWire es muy superior ala de USB, ambos proporcionan alimentación y están estandarizados y extendidos.

48 4.2. ANÁLISIS DE ALTERNATIVAS

4.2.2. MicrocontroladorEl microcontrolador, como elemento principal del diseño debe satisfacer la mayor par-

te de los requisitos definidos al principio del capítulo, y atendiendo a los criterios funda-mentales de selección de un microcontrolador descritos en el capítulo 2 y a los requisitosdel proyecto, para tomar la decisión se tendrán en cuenta los siguientes parámetros:

• Velocidad de cálculo

La CPU debe ejecutar instrucciones a una velocidad suficiente como para rea-lizar las operaciones de E/S y los cálculos necesarios en un intervalo de tiempomáximo. En la actualidad casi todos los microcontroladores tienen una frecuenciade reloj variable que se puede ajustar según los requisitos para llegar a un compro-miso entre potencia de cómputo y consumo eléctrico.

• Módulos integrados

El proyecto requiere la elección de un microcontrolador que tenga incorporadosmódulos que le permitan realizar ciertas tareas como conversión Analógico-Digitaly comunicación USB. El uso de un microcontrolador con módulos incorporadosestá destinado a reducir el número de componentes en placa, y por tanto el coste,el tiempo de desarrollo, el consumo total, y el espacio en placa. Por otra parte, enmuchos casos el microcontrolador contiene módulos que no se utilizan porque noson necesarios, pero que no suponen un gran coste adicional, y debido a sus otrascaracterísitcas son firmes candidatos a ser seleccionados entre toda la gama delfabricante.

• Factor de forma y encapsulado

Resulta muy importante que el encapsulado del chip sea adecuado para la fabri-cación de un prototipo, esto es, que tenga un tamaño y una configuración de pinesapta para su soldadura manual en una placa de circuito impreso, o su inserción enuna placa proto-board. Los fabricantes suelen ofrecer distintos encapsulados parael mismo dispositivo, con lo que es posible utilizar uno para la fase de construccióndel prototipo, y otro diferente para el producto final.

• Herramientas de desarrollo y documentación disponibles

El hecho de que se trate de una plataforma popular implica en muchos casosque el fabricante proporciona gran cantidad de documentación, que existen buenasherramientas de desarrollo, y sobretodo, que hay muchos proyectos ya desarrolla-dos y ejemplos disponibles, lo cual es de gran ayuda. Ademas si se cuenta conexperiencia previa en el desarrollo con esa plataforma se reduce considerablementeel tiempo de desarrollo.

• Pines de E/S


El microcontrolador deberá contar con suficientes pines de entrada y salida paraesta aplicación, lo que debe evaluarse teniendo en cuenta la arquitectura del sistemaque se haya diseñado para poder cuantificar esta necesidad.

• Consumo

El consumo debe ser apropiado para que pueda funcionar exclusivamente conla corriente suministrada por el bus USB. Muchos microcontroladores están pre-parados para funcionar con poca corriente o con baterías, y disponen de modosespeciales de bajo consumo.

• Memoria

Habrá que estimar la cantidad de memoria necesaria para acometer las tareas delas que se compone el funcionamiento del sistema (muestreo, algoritmo anticopia,comunicación USB) para poder determinar la cantidad de memoria tanto volátilcomo no volátil que se necesita.

• Arquitectura

En muchos casos, los microcontroladores de 8 bits son suficientes, pero hay queevaluar la potencia de cálculo necesaria para seleccionar la arquitectura de menorcoste que se adapte a los requisitos del proyecto.

4.2.3. Lenguaje de programaciónEs importante seleccionar los lenguajes de programación más adecuados de entre la

gran diversidad existente. El lenguaje, unido a las herramientas de desarrollo van a influirmucho en el tiempo de desarrollo del software.

Lenguaje de programación para el microcontroladorDe entre los lenguajes más usados destacan Basic, C y ensamblador.Basic

Originalmente fue desarrollado como una herramienta fácil de usar para principiantes,con lo que presenta una sintaxis muy sencilla, y cercana unos pocos aspectos al lenguajenatural o pseudocódigo, por ello es el preferido de aficionados que no tienen gran expe-riencia en programación. Por esta misma razón se encuentran en la red gran cantidad derecursos relacionados con el lenguaje.

CC ha demostrado a lo largo de tres décadas su flexibilidad, puesto que con él se hanprogramado compiladores, juegos, sistemas operativos, drivers y un inmenso etcétera.C está razonablemente cerca del lenguaje máquina, permitiendo trabajar con punteros ydirecciones de memoria mientras mantiene su característica de lenguaje de alto nivel.

50 4.2. ANÁLISIS DE ALTERNATIVAS

EnsambladorEs el lenguaje de más bajo nivel, y por tanto más cercano a la máquina, esto lo hace to-talmente dependiente de la misma. Ofrece la posibilidad de escribir código muy eficiente,para lo cual hay que conocer muy bien la máquina en la que se ejecuta. Sin embargo esmuy poco portable y difícil de mantener. Su uso está extendido en el ámbito de los micro-controladores bien porque el fabricante no proporcione herramientas de más alto nivel, obien porque se pretenda optimizar el rendimiento y el consumo.

Lenguaje de programación para el PCDe entre los lenguajes más utilizados actualmente para la programación bajo Win-

dows se pueden citar:JavaJava es un lenguaje de programación orientada a objetos muy popular. Se trata de unlenguaje interpretado que requiere de la máquina virtual de Java. Se utiliza en multitudde aplicaciones desde juegos hasta aplicaciones web empresariales. Es muy escalable, yutiliza una sintaxis similar en varios aspectos a la de C++. Su rendimiento está ligado ala eficiencia del compilador y de la máquina virtual que lo ejecuta. Sus limitaciones encuanto acceso a bajo nivel al sistema también las determina la máquina virtual. Sin em-bargo se pueden crear bindings para exponer funciones nativas de la plataforma de formaque queden accesibles desde la máquina virtual.Visual C++Se trata de un entorno de desarrollo integrado para lenguajes C y C++. Se usa específica-mente para el desarrollo y depuración de aplicaciones escritas para las API’s de MicrosoftWindows, DirectX y .NET.

Utiliza las Microsoft Foundation Classes de forma extensiva para el desarrollar apli-caciones basadas en entorno gráfico.

El entorno de desarrollo cuenta con herramientas como IntelliSense, que muestra demanera visual las construcciones del lenguaje, depuración remota, editar y continuar oresaltado de la sintaxis.

Cuando se compila para .NET se pueden introducir algunos elementos ajenos a C++para hacer uso extensivo de sus características como el recolector de basura.

Visual BasicEs un lenguaje de programación basado en objetos (no orientado a objetos) propietario deMicrosoft, cuya primera versión se presentó en 1991. Se trata de un dialecto del lenguajeBASIC con extras añadidos. Al igual que Java es un lenguaje interpretado que requierede una DLL que contiene la máquina virtual para su ejecución. Sin embargo ofrece laposibilidad de compilar directamente a código nativo. Existen muchas bibliotecas quefacilitan el acceso a muchas funciones del sistema operativo y a la integración con otrasaplicaciones. Debido a su similitud con el lenguaje BASIC posee una curva de apredizajemuy rápida. Sin embargo, presenta inconvenientes como que al ser propietario complica


su portabilidad, no permite secciones de código escrito en ensamblador, permite el usode variables sin declarar, no incluye operadores de desplazamiento de bits, y no tieneinstrucciones de preprocesamiento por citar los principales.Visual C#Se trata de un lenguaje de programación desarrollado y estandarizado por Microsoft, cuyasintaxis básica 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 característicaspropias del paradigma de programación orientada a objetos: encapsulación, herencia ypolimorfismo. Otra de sus principales características es la gestión automática de memoria,dado que al formar parte de la plataforma .NET tiene a su disposición el recolector debasura de este, y la posibilidad de acceder a código nativo escrito de forma no orientadaa objetos.

4.3. SELECCIÓN DE ALTERNATIVAS

Una vez mostradas las alternativas disponibles para el desarrollo de este proyecto sepasa a la toma de decisiones sobre la más apropiada en cada caso.

Es necesario definir en primer lugar el estándar de comunicación utilizado para laconexión de el dispositivo desarrollado con el computador, para lo cual debe tomarse unadecisión entre utilizar Firewire, o USB.

Precisamente debido a la mayor velocidad de FireWire (de 200 a 800 Mbps) respectoa USB es más caro de implementar y por ello su uso está restringido a aplicaciones quedemandan esos anchos de banda como la edición digital de audio y vídeo o el almacena-miento masivo, sin embargo USB ofrece en su versión más lenta una velocidad más quesuficiente para la aplicación desarrollada (1.5 Mbps), y un coste mucho menor, además deque hay una gran oferta de microcontroladores con transceptor USB incorporado de muybajo coste.

Por otro lado, USB ofrece una filosofía de interconexión Plug & Play, de manera quese pueden conectar hasta 127 dispositivos sin necesidad de reiniciar la máquina, y en mu-chos casos, instalar drivers. Muchos dispositivos que no son computadores de propósitogeneral incluyen puertos USB, como consolas de videojuegos, autorradios, etc. Y ofrecencompatibilidad plug & play con ciertas clases de periféricos USB: (unidades de almace-namiento, joysticks y otros dispositivos de entrada . . . ). Hace un uso del ancho de bandaóptimo ya que dispone de varios tipos de transferencias, y también optimiza el consumoeléctrico, pudiendo poner en modo de bajo consumo a un dispositivo USB que no se estáutilizando. Finalmente, aunque USB presente una complejidad añadida al uso de otrosinterfaces más simples como el RS-232, existe una gran cantidad de herramientas quefacilitan el desarrollo de periféricos que utilizan este estándar, y tanto su especificacióncomo otra documentación está disponible en la red de manera gratuita, lo que facilita engran medida el diseño.

2European Computer Manufacturers Association

52 4.3. SELECCIÓN DE ALTERNATIVAS

Todo ello hace que USB sea la opción elegida.En cuanto a la selección del microcontrolador, se opta por un modelo de la amplia

gama de microcontroladores del fabricante Microchip. Las razones fundamentales paraelegir a este fabricante son la experiencia previa con productos del mismo, que tiene encatálogo una gran variedad de modelos, divididos en tres gamas, que se adaptan a grannúmero de aplicaciones, y que ya se cuenta con experiencia previa en el uso de estosmicrocontroladores.

Todos están construidos en torno a una arquitectura común, lo que permite que unavez se ha desarrollado para una, migrar a otra sea extremadamente fácil.

Una vez decidido el fabricante, se debe buscar un microcontrolador que cumpla lassiguientes características:

• Su arquitectura debe ser de 8 bits puesto que no se requiere gran potencia de cálculoy ya se cuenta con experiencia previa en esta familia.

• Debe disponer de un módulo USB que requiera poca o ninguna circuitería externaadicional.

• Su memoria de programa debe ser reprogramable, y además tiene que poder serreprogramada por firmware sin necesidad de un programador externo para permitirsu actualización mediante USB.

• Tiene que estar disponible en encapsulado SPDIP3 (fig. 4.1), puesto que es el másadecuado para la fabricación de prototipos.

• Debe disponer de conversores A/D para muestrear los transductores analógicos (po-tenciómetros).

• Debe disponer de puertos de entrada digitales para muestrear los transductores di-gitales.

• No debe consumir más de 100 mA

• Debe tener disponibilidad suficiente para la adquisición de lotes de cientos de uni-dades, y mantener su disponibilidad durante el tiempo suficiente para que no seanecesario migrar a otro debido al cese de su fabricación con el tiempo.

Tras realizar varias búsquedas paramétricas en el catálogo on-line de Microchip, se haseleccionado el modelo PIC18F2550.

En el momento de la redacción de esta memoria, el fabricante dispone 250 microcon-troladores de 8 bits, teniendo 49 de ellos transceptor USB 2.0 integrado. Se proporcionatambién de manera gratuita el entorno de desarrollo MPLAB IDE, de gran cantidad dedocumentación y de soporte técnico 24/7.

3Skinny Plastic Dual In-Line, es un tipo de encapsulado para su montaje a través de agujeros


Figura 4.1: El encapsulado SPDIP

Este modelo es un microcontrolador de 8 bits con 32 Kbytes de memoria ROM de tipoFlash, y 2 Kbytes de memoria de tipo SRAM. La CPU soporta frecuencias de reloj de has-ta 48 MHz, ofreciendo una velocidad de 12 MIPS. Incluye una memoria EEPROM de 256bits accesible por firmware para el almacenamiento no volátil de parámetros necesariosen tiempo de ejecución.

Dispone también de un conversor A/D de 10 bits conectado a un multiplexor analógicode 10 canales. lo que satisface los requisitos.

Tiene también incorporado un transceptor USB 2.0 de velocidad completa (hasta 12Mbps), que soporta todos los tipos de transfrencias, además cuenta con suficientes pinesde entrada/salida digitales, y con resistencias de pull-up internas cuya utilidad se compro-bará más adelante.

El etiquetado de esta familia de microcontroladores se compone de la familia, seguidadel voltaje de operación, el tipo de memoria, y finalmente el modelo concreto. De estamanera, el PIC18F2550 es de la familia PIC18, funciona a 5 V (puesto que no incorporauna L, que significaría Low Voltaje (3.3 V)), utiliza memoria Flash (denotado por la F, yel modelo es el 2550. Las memoria flash es más rápida que la EEPROM y tiene un tiempode vida máximo de 10.000 a 100.000 ciclos de borrado-reprogramación según el tipo dememoria. La memoria Flash debe ser borrada antes de ser reprogramada, y se borra anivel de bloques.

En lo referente al lenguaje de programación, para el microcontrolador se ha seleccio-nado C, puesto que es eficiente, se cuenta con buenos conocimientos sobre su sintaxis,permite el acceso a bajo nivel a la máquina, y secciones escritas en código ensambla-dor. En definitiva permite un mayor control de todos los aspectos del funcionamiento delmicrocontrolador. Además para la plataforma PIC18 existe gran cantidad de software ylibrerías disponible on-line.

En cuanto al lenguaje de programación para el PC, descartamos Java porque uno delos objetivos es que sea lo más eficiente posible, y ocupe los mínimos recursos del mismode manera que no ralentice el funcionamiento del simulador o de la aplicación que usa eldispositivo, por otra parte Java no permite el acceso directo a USB, siendo necesaria unalibrería nativa de bindings.

El resto de opciones podrían ser válidas, pero se opta por C++ por permitir un accesodirecto a la API de USB proporcionada por el sistema operativo, orientado a objetos,

54 4.3. SELECCIÓN DE ALTERNATIVAS

eficiente, y uno de los lenguajes de uso común más extendidos, redundando en una mayorfacilidad para la ampliación y mantenimiento del código.

Para la programación del microcontrolador se utiliza el compilador CCS por generarun código más pequeño que C18, y permitir el diseño más rápido del firmware. Perotambién se utilizará el compilador C18 y el ensamblador MPASM como se explicará másadelante.

El tipo de dispositivo será USB 2.0 de velocidad completa (12 Mbps). Esta configura-ción permitirá añadir más funciones en el futuro que requieran más ancho de banda.

CAPÍTULO 5

DISEÑO E IMPLEMENTACIÓN DELHARDWARE

En este punto ya se tiene suficiente información para abordar el diseño del periférico.En primer lugar se va a diseñar el esquema de la circuitería del periférico, que des-

glosaremos en: conectores, asignación de pines, alimentación, oscilador, comunicaciónUSB, y conexión de sensores.

5.1. DIAGRAMA DE BLOQUES

De acuerdo con las especificaciones y los componentes seleccionados, se elabora eldiagrama de boques representado en la figura 5.1.

Figura 5.1: Diagrama de bloques del sistema

Como se puede apreciar, el único componente del sistema es el microcontroladorPIC18F2550, que satisface todas las exigencias del proyecto. Al disponer de un conversorA/D de 10 canales integrado, permite la conexión de las líneas que transportan las señalesa medir (debidamente acondicionadas) directamente a los pines del integrado sin requerirun conversor externo. Por otra parte, el transceptor USB integrado es toda la electrónicaque necesita para la conexión al bus USB [Tec07].

56 5.2. CONECTORES

Sin embargo como veremos en las siguientes secciones, serán necesarios unos po-cos componentes discretos externos como condensadores y resistencias, y un cristal decuarzo.

5.2. CONECTORES

El primer requisito del hardware es que el dispositivo estará conectado físicamenteal computador y a los transductores de la botonera. Por lo tanto se van a seleccionar losconectores apropiados para este propósito.

5.2.1. Conexión USBExisten fundamentalmente cuatro tipos de conectores USB, mostrados en la figura

5.2.La norma USB 1.0 y 2.0 sólo define los conectores tipo A y tipo B (tanto macho

como hembra), pero algunos fabricantes han desarrollado conectores más pequeños, másaptos para dispositivos portátiles, como el mini y el micro USB, que estan disponiblesal público. Otros fabricantes utilizan conectores propietarios, que están basados en otroconector mecánico pero mantienen las señales de USB.

Figura 5.2: Tipos de conectores USB principales, de izquierda a derecha: Micro USBmacho, Mini USB tipo B macho, Tipo B macho, Tipo A macho.

Para este proyecto se ha determinado que el conector más adecuado es el tipo B hem-bra (fig. 5.5), por tres razones: tiene gran disponibilidad, el conector no es de montajesuperficial lo que facilitará su soldadura manual, y la existencia de cables de conexióntipo A-B macho para su conexión con el computador (vease figura 5.4), ya que tanto lospuertos presentes en los computadores como en los concentradores USB son de tipo Ahembra.

5.2.2. Conexión los sensoresEn cuanto a la conexión con los sensores, para proporcionar una buena conexión, faci-

litar el montaje y reducir el coste se opta por conectores de apriete, de paso 2.54 mm queestán disponibles en bloques de tres y diez elementos y tienen un tamaño adecuado para

CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL HARDWARE 57

Pin Color Función1 Rojo VCC (4.4 - 5.25 V)2 Blanco D- (Datos)3 Verde D+ (Datos)4 Negro GND (Tierra)

Cuadro 5.1: Numeración y función de cada pin [Axe05]

Figura 5.3: Conector USB tipo B macho y hembra.

su montaje en la placa. Los sensores se conectarán empleando cables desde el conectorde apriete hasta los pulsadores o potenciómetros del dispositivo sensorizado.

5.2.3. Otros conectoresFinalmente, para permitir la instalación y retirada del microcontrolador sin usar sol-

daduras se coloca un zócalo de 28 pines.

Figura 5.4: Extremos del cable deconexión USB de tipo A-B.

Figura 5.5: Conector USB tipo Bpara montaje en placa.

58 5.3. ASIGNACIÓN DE PINES

5.3. ASIGNACIÓN DE PINES

La asignación de pines suele ser uno de los primeros pasos al diseñar un sistemamicrocontrolado 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 figura 5.6, muchos de los pines están multiplexados de manera quesólo pueden ser utilizados para una función en un momento determinado. Por tanto es enesta etapa cuando hay que definir cual o cuales de las funciones que ofrece dada pin seránla utilizadas y por tanto qué se debe conectar a cada uno de ellos.

Es preciso señalar que la utilización de un módulo interno del micro, como el trans-ceptor USB exige el uso de un conjunto de pines que al estar asignados a ese módulo, nopodrán ser utilizados para ninguna otra de las funciones con las que está multiplexado (ano ser claro, que se deje de utilizar ese módulo y que la arquitectura lo permita).

En las siguientes subsecciones se justificará la asignación realizada a cada uno de lospines.

5.4. ALIMENTACIÓN

Atendiendo a los requisitos, el periférico no necesitará alimentación externa, es porello que hemos escogido una interfaz de conexión que proporciona alimentación suficien-te.

La alimentación suministrada por el bus es muy estable, pero contiene ruido de altafrecuencia, por ello se coloca un condensador cerámico entre alimentación y tierra, conuna capacidad de 100 nF. Este es un condensador de desacoplo, que cumple una doblefunción: por un lado bloquea las fluctuaciones de alta frecuencia de la línea de alimen-tación para mejorar la estabilidad, por otro lado cuando el integrado produce un pico deconsumo, el condensador absorbe este pico evitando la caída de tensión en la línea, suinstalación es frecuente entre los pines de alimentación de los circuitos integrados.


Siguiendo las indicaciones de las hojas de especificaciones para el 18F2550, se imple-menta el esquema mostrado en la figura 5.7, que incorpora un condensador (200 nF) entreel pin VUSB y tierra. Esto se debe a que el estándar USB define 3.3 V para las líneas dedatos, pero el micro está funcionando a 5 V, que es la tensión que proporcionan las líneasde alimentación del bus. Por eso existe un regulador de tensión interno que adapta la ten-sión de 5 V a 3.3 V [Tec07]. El pin VUSB tiene la tensión de salida del regulador, usadopara alimentar el transceptor USB interno. Esta tensión puede ser necesaria si se utilizanresistencias de pull-up externas en las líneas de datos, lo cual se explicará en la sección«Comunicación USB». Si no se necesita, se debe conectar a través de un condensador atierra para evitar que «flote» al dejarlo al aire e introduzca ruido en la circuitería USBinterna.

Figura 5.7: Esquema de circuito de alimentación para un PIC18F2550 alimentado porUSB usando su transceptor incorporado.

Para finalizar hay que observar que el bus comienza suministrando 100 mA hasta queel host obtiene los descriptores que le informan de la corriente que debe suministrar, yque la corriente típica máxima del PIC18F2550 es de 5 mA. Por lo tanto el consumo delchip en modo de funcionamiento normal trabajando a una tensión de 5 V es, según la leyde ohm (ecuación 5.1), de 25 mW.

P = V · I (5.1)

Los pines implicados aquí son: VSS (8, 19), VDD (20), VUSB (14).

5.5. OSCILADOR

Como cualquier circuito síncrono, el micro necesita de una fuente de oscilación queutilizar como señal de reloj. El PIC18F2550 tiene un oscilador interno que puede alimen-tar la CPU y los módulos internos, pero debido a los requisitos de frecuencia y estabilidad

60 5.5. OSCILADOR

del módulo USB se necesita utilizar el oscilador basado en cristal de cuarzo externo queutiliza los pines OSC1 y OSC2 genera una señal de reloj estable, apta para el móduloUSB.

El PIC18F4550 puede operar en varios modos de oscilación, entre los que cabe desta-car:

• 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 módulo PLL para multiplicar la frecuen-cia.

• HSPLL: Ídem que el anterior pero con cristal externo de alta velocidad.

• EC: Con señal de reloj externa alimentada por un pin.

• INTHS: CPU y periféricos con el oscilador interno pero usando un cristal de altavelocidad para el módulo USB.

Los cristales de cuarzo se basan en las propiedades piezoeléctricas de este materialpara la generación estable de señales oscilantes, por ello son muy usados como parte decircuitos osciladores.

En cuanto a la frecuencia, hay que tener en cuenta que el módulo USB necesita una en-trada de 6 MHz para su funcionamiento como dispositivo de baja velocidad, o de 48 MHzpara su funcionamiento como dispositivo de velocidad completa. La figura 5.8 muestrala circuitería de selección de reloj del micro, de ella se pueden extraer todas las posiblesconfiguraciones para conseguir la frecuencia adecuada en la entrada del módulo USB(marcada como «USB Peripheral»).

Puesto que se desea configurar un dispositivo de velocidad completa, la frecuenciaque se necesita obtener a la entrada del módulo USB es de 48 MHz, para ello se hadeterminado que se puede utilizar un cristal de 4 MHz con la configuración que sigue elcamino maracado en rojo en la figura 5.9 (de izquierda a derecha). El uso de un cristal deesta frecuencia se debe a que se trata de componentes caros, cuyo precio es generalmentedirectamente proporcional a la frecuencia que desarrollan, siendo 4 MHz la configuraciónmínima para el funcionamiento del sistema.

Como se puede ver, la señal pasa por un multiplexor que no divide la frecuencia, paraentrar después a un circuito PLL 1 que eleva la frecuencia de 4 MHz a 96 MHz. Finalmentepasa por un divisor de frecuencia que la escala hasta obtener los 48 MHz deseados, quepasan por un multiplexor final hacia la entrada del módulo USB.

En cuanto a la frecuencia de la CPU, se toma la señal a 96 MHz a la salida del PLL, yse divide independientemente por dos (multiplexor marcado con CPUDIV), esto pasa por

1Phase-Locked Loop, o lazo de seguimiento de fase es un sistema realimentado que multiplica la fre-cuencia de una señal de entrada


Figura 5.8: Esquema de la circuitería de selección de reloj del PIC18F2550 relativa almódulo USB.

otros dos multiplexores y finalmente va a la entrada de reloj de la CPU, que consecuen-temente también trabajará a 48 MHz, la velocidad máxima que proporciona 12 MIPS.Recordemos que al ser un dispositivo que no funciona con baterías y que se alimenta através del puerto USB el consumo no es una prioridad, y esta frecuencia proporciona unabuena velocidad de cómputo para implementar las caracterísitcas del proyecto, y permitirotras en un futuro.

Esta configuración será tenida en cuenta en la posterior fase de desarrollo del firmwa-re.

En lo respectivo al oscilador de cuarzo, siguiendo las hojas de especificaciones laconexión debe realizarse de la forma indicada en la figura 5.10.

Figura 5.9: Esquema de cone-xión de un cristal de cuarzo alPIC18F2550.

Figura 5.10: Tabla de capacidades recomen-dadas por el fabricante para los condensa-dores C1 y C2.

62 5.6. COMUNICACIÓN USB

Figura 5.11: Circuito para la detección de un dispositivo de alta velocidad.

Según la tabla mostrada en la figura 5.10 los valores recomendados por el fabricantepara los condensadores C1 y C2 son 27 pF.

Finalmente, el oscilador tendrá un encapsulado de tipo HC49 de forma que su montajesea fácil.

Los pines implicados en esta sección son OSC1 (9) y OSC2 (10).

5.6. COMUNICACIÓN USB

Antes de continuar es necesario explicar cómo funciona el proceso de detección de undispositivo al bus.

Puesto que los dispositivos utilizan para el intercambio de datos con el host, transfe-rencias de control que en última instancia son un tipo de transferencia USB que puederealizarse a tres velocidades distintas, ya desde el principio se debe conocer la velocidaddel dispositivo para poder llevar a cabo este proceso correctamente.

El host o hub tiene conectadas a sus líneas de datos D+ y D-, sendas resistencias depull-down de 15 KΩ

La norma dice que un dispositivo de velocidad completa debe llevar la línea D+ anivel alto mediante la conexión de una resistencia de pull-up de 1.5 KΩ (ver figura 5.11).Mientras que un dispositivo de baja velocidad llevará la línea D- a nivel alto de la mis-ma manera (ver figura 5.12). En cuanto a los dispositivos USB 2.0 de alta velocidad, seidentifican como de velocidad completa, y una vez que el host obtiene sus descriptores secambia la velocidad, y se desconecta la resistencia de pull-up para balancear la línea.

El PIC18F2550 tiene estas resistencias integradas en el chip y son controlables por


Figura 5.12: Circuito para la detección de un dispositivo de baja velocidad.

firmware, lo que junto con el regulador de tensión de 3.3 V, y el transceptor USB integradoreduce la circuitería externa necesaria para la operación del bus USB a cero, conectándoselas líneas de datos D+ y D- provenientes del conector directamente a los pines D+ y D-del chip.

También se permite el uso de un transceptor USB externo, de un regulador de tensiónexterno o de ambos, pero se ha escogido este micro especialmente por contar con todaesta circuitería integrada. En la figura 5.13 se pueden apreciar las resistencias de pull-up,el transceptor USB y el regulador de tensión.

Figura 5.13: Fragmento del esquema de la circuitería de control del USB relativo a lasresistencias de pull-up internas.

Los pines involucrados en esta sección son D+ (16) y D- (15).

64 5.7. CONEXIÓN DE SENSORES

5.7. CONEXIÓN DE SENSORES

Los sensores que se pretenden conectar a este sistema son, como ya se ha explicadopulsadores y potenciómetros presentes en varios tipos de dispositivos de control de ma-quinaria real. Recordemos que el objetivo es muestrear el estado de 10 sensores digitales(pulsadores) y otros 10 que pueden ser digitales o analógicos (potenciómetros).

5.7.1. Sensores digitalesEl micro dispone de pines de E/S digital de propósito general que pueden ser utiliza-

dos para este cometido, de manera que se conecte un pulsador a cada pin. Los pines seorganizan en puertos nombrados con letras de la A a la E, se utiliza la nomeclatura Rxypara referirse al pin noy del puerto x, (por ejemplo RA3 es el pin no 3 del puerto A). En laversión de 28 pines que estamos utilizando no están disponibles todos los puertos ni todoslos pines en cada puerto. Hay que destacar que cada puerto presenta características espe-ciales como buffers de entrada schmitt-trigger, o drivers CMOS pero todos los que quedanlibres tras las asignaciones realizadas anteriormente tienen en común que aceptan nivelesTTL. Cada pin puede configurarse individualmente como de entrada o de salida mediantela escritura de un registro que comunica con un latch, que a su vez controla un buffertriestado, de manera que cuando se configura como entrada el pin está en estado de altaimpedancia y cuando se configura como salida está conectado con el bit correspondientede su registro de control, véase figura 5.14.

Uno de los esquemas de conexión más típicos para cuando se dispone de una entradaindependiente por pulsador, el cual se ha implementado, es el que se muestra en la figura5.15, en el que se conecta el pin a VDD a través de una resistencia de pull-up para limitarel consumo. El pin también se conecta a tierra a través del pulsador tal y como se muestraen la figura 5.15, de forma que cuando se pulsa produce una caída de tensión que llevaal pin a nivel bajo. De esta manera (asumimos que usamos pulsadores en cuyo estado dereposo están abiertos) si no se está pulsando se podrá leer un 1 lógico en esa entrada, y sise está pulsando se leerá un 0 lógico.

El valor de esta resistencia no es crítico, pero hay que asegurarse de que cuando elpulsador esté en reposo la corriente que entre por el pin sea superior al umbral inferiordel nivel alto TTL, y que cuando se pulsa el nivel de tensión cae por debajo del umbralsuperior del nivel bajo TTL, evitando los niveles indefinidos. Tal y como se muestra enla figura 5.16 los niveles lógicos TTL son de 0 a 0.8 V para el nivel bajo y de 2 V a 5 Vpara el nivel alto, quedando la franja entre ambas en un nivel indeterminado que hay queevitar. Valores típicos de estas resistencias están en torno a los 10 KΩ - 100 KΩ.

Afortunadamente, el PIC18F2550 dispone de resistencias de pull-up internas en todoslos pines de entrada del puerto B (8 en total) activables por firmware y que reducen lacircuitería externa. Gracias a esto no será necesario colocar una resistencia externa encada pin de entrada del puerto B (RBx).

Los pulsadores son parte de las botoneras de control, por lo tanto no forman parte del


Figura 5.14: Esquema simplificado de la circuitería de control de un pin de E/S.


Figura 5.15: Esquema de conexión de un pulsador a una entrada digital.

Figura 5.16: Rango de niveles de tensión y su correspondencia con los niveles lógicos enTTL.

circuito y se encontrarán fuera de la placa de circuito impreso. Por esta razón hay queponer las resistencias de pull-up en la placa y conectar el punto donde debe ir el pulsadoral pin correspondiente del conector de apriete. De esta forma cuando se monte dentro dela botonera, sólo habrá que conectar un extremo de los pulsadores a tierra, y el otro a losconectores de apriete (fig 5.17).

Los pines de entrada digitales que quedan libres tras las asignaciones anteriores sonlos siguientes (ver figura 5.6): RA(0-5), RC(0,1,2,6,7), RB(0-7), RE3, que suman un totalde 20.

Si se descartan los que están multiplexados con una entrada analógica puesto que senecesitan todas las entradas analógicas (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 réplicadel circuito descrito en la figura 5.17.


Figura 5.17: Esquema de conexión de cada entrada digital, X1-1 y X1-2 simbolizan pinesdel conector de apriete, X2-1 y X2-2 simbolizan los extremos de los cables conectados aestos.

5.7.2. Sensores analógicosComo consta en los requisitos, se deben poder muestrear sensores que pueden ser bien

analógicos o bien digitales.Los potenciómetros son utilizados en dispositivos de interfaz humana porque son una

forma económica de determinar la posición angular de un útil de control tal como unapalanca, o un pedal. Los dispositivos de juego como joysticks, joypads o volantes incor-poran estos componentes, y también los dispositivos de control de maquinaria real, por loque el sistema deberá ser capaz de determinar la posición de potenciómetros conectadosa él.

Desde el punto de vista electrónico, un potenciómetro es una resistencia a la que se lepuede variar su valor mediante el giro de un eje o un elemento deslizante. Se componende un material resistivo como el grafito y de un contacto que se desplaza a lo largo de él.Típicamente 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 quesu tensión varía, generalmente de forma lineal, con el ángulo de giro. De esta maneramidiendo la tensión de este terminal se puede determinar la posición angular del eje.

Para poder medir esta tensión se ha escogido un micro con conversor A/D de 10 bitsde precisión. La figura 5.18 muestra cómo la entrada analógica del conversor A/D estáconectada a un multiplexor analógico controlable por firmware que permite seleccionaruno de los diez pines (canales) de entrada analógicos ANx. Nótese que los pines marcadoscon el superíndice (1) sólo están disponibles en la versión de 40 pines, y hay que recor-dar de la figura 5.6 que los pines ANx que pueden funcionar como entradas analógicasestán multiplexados con Rxy, que son pines de E/S digitales. Esto implica que se debeseleccionar una funcionalidad u otra para cada uno de los pines.


Figura 5.18: Conexionado interno de los pines de entrada analógicos al conversor A/Ddel PIC18F2550.

Como se desprende también de la figura, el voltaje de referencia tanto positivo comonegativo del conversor es seleccionable entre VCC y el pin AN3 o entre tierra y el pinAN2 respectivamente.

Para el conexionado de un potenciómetro con uno de los canales analógicos del PIC18F2550se puede usar como voltaje de referencia positivo el suministrado por el bus USB (5 V), ytierra como voltaje de referencia negativo, de esta manera se optimiza el uso de los pinesdisponibles.

En estas condiciones se debe aplicar una diferencia de potencial de 5 V en los pinesdel potenciómetro para escalar la señal de salida del mismo al rango entero del conversorA/D para obtener así la mayor precisión.

De esta manera cuando el potenciómetro esté en su mínima posición angular la tensiónde salida será cercana a 0 V, y el valor digital capturado por el conversor será cercano almínimo: 0000000000. Igualmente, cuando el potenciómetro esté en su máxima posiciónangular, la tensión de salida será cercana a los 5 V, capturandose un valor cercano a1111111111. Cualquier posición intermedia será linealmente dependiente del ángulo degiro (asumiendo que se utilice un potenciómetro lineal).

Con todo ello en mente se construye el circuito mostrado en la figura 5.19.


Figura 5.19: Esquema de conexiónde un potenciómetro a un conversorA/D.

Figura 5.20: Esquema de conexión separa-do.

Al igual que ocurría con los pulsadores, los potenciómetros forman parte de las boto-neras y se dejan todas las líneas necesarias para el cableado externo de los mismos en losconectores como muestra la figura 5.20.

No obstante, puede darse la situación de que se desee instalar este sistema de adqui-sición de datos en una botonera que no disponga de potenciómetros, o que disponga demenos de diez, y sin embargo hayan más de diez pulsadores que sensorizar. Para estos ca-sos se podrá conectar un pulsador a una de las entradas analógicas, para lo cual como yase explicó anteriormente se requiere una resistencia de pull-up por cada uno. Es por elloque las entradas analógicas tendrán una resistencia de pull-up desconectable mediante unjumper, quedando el circuito final como indica la figura 5.21.

En este caso, cuando se sustituya el potenciómetro por un pulsador el conversor cap-turará un nivel de tensión cercano a 5 V con el pulsador en posición de reposo, y cercanoa 0 V cuando esté pulsado. En suma, cada uno de los diez canales analógicos tendrá unaseñal digital virtual asociada, cuyo valor dependerá del nivel de tensión capturado en esecanal, esta estrategia será explicada con más detalle en las siguientes secciones.

Los pines afectados en esta sección son los restantes: AN(0-4) y AN(8-12), un totalde 10. Cada uno de ellos se conectará con su correspondiente pulsador o potenciómetromediante una réplica del circuito descrito en la figura 5.21.

5.8. RESUMEN

En resumen, la asignación final de pines del micro queda como sigue:

70 5.9. DISEÑO DEL ESQUEMÁTICO

Figura 5.21: Esquema de conexión final.

Pin Id Función Pin Id Función1 RE3 Entrada digital 0 15 D- Datos USB2 AN0 Entrada analógica 0 16 D+ Datos USB3 AN1 Entrada analógica 1 17 RC6 Entrada digital 54 AN2 Entrada analógica 2 18 RC7 Entrada digital 65 AN3 Entrada analógica 3 19 VSS Tierra6 RA4 Entrada digital 1 20 VDD Alimentación7 AN4 Entrada analógica 4 21 AN12 Entrada analógica 98 VSS Tierra 22 AN10 Entrada analógica 79 OSC1 Cristal de cuarzo 23 AN8 Entrada analógica 510 OSC2 Cristal de cuarzo 24 AN9 Entrada analógica 611 RC0 Entrada digital 2 25 AN11 Entrada analógica 812 RC1 Entrada digital 3 26 RB5 Entrada digital 713 RC2 Entrada digital 4 27 RB6 Entrada digital 814 VUSB Regulador USB (a tierra) 28 RB7 Entrada digital 9

5.9. DISEÑO DEL ESQUEMÁTICO

Con todo lo descrito anteriormente y la ayuda del paquete de software Eagle se creauna versión inical del esquemático para poder proceder a su montaje en una placa depruebas.


Figura 5.22: Esquema de conexionado interno típico de una placa de prototipos Proto-Board

5.10. IMPLEMENTACIÓN DEL HARDWARE

Como se comentó en el capítulo de «Metodología y materiales» en primer lugar seutilizará una placa de prototipos proto-board para comprobar que todo el sistema funcionacorrectamente. Las placas proto-board son placas de reutilizables usadas para construirprototipos de circuitos impresos sin necesidad de soldaduras. Se componen de un panelde plástico con una rejilla donde se insertan los componentes. Presentan un esquema deconexionado interno horizontal y vertical como se muestra en la figura 5.22.

Para el conexionado entre pistas se emplea hilo telefónico que permite una inserciónlimpia. Se utiliza un conector USB tipo B hembra y se sueldan hilos telefónicos a suscuatro pines, que son insertados en la placa.

Para probar la sensoriazción digital se inserta un pulsador para montaje en placa yse cablea con el microcontrolador. En cuanto a la analógica se hace lo mismo con unpotenciómetro.

Una vez montado el esquema se realizan comprobaciones eléctricas sobre la placa.Finalmente se carga en el micro un firmware de demostración suministrado con el com-pilador CCS y se conecta por USB a un PC para comprobar que la comunicación escorrecta.

Tras haber verificado el diseño en la placa de pruebas se procede a la fabricación deuna placa prototipo. Partiendo del esquema inicial se realizan modificaciones, poniendoespecial énfasis en optimizar el tamaño de la placa para cumplir los requisitos.

El diseño mostrado en el apéndice (fig. A.1) es el fruto refinado de la experimentacióncon la placa de prototipos, en la que se ha observado que se puede optimizar el tamaño dela placa si se colocan conectores de apriete a ambos lados y cada uno conecta las señalespresentes a ese lado del chip. Otra de las optimizaciones ha consistido en utilizar redes deresistencias para la implementación de los pull-up puesto que son componentes relativa-mente compactos. Los conectores y redes de resistencias que figuran en el esquemáticose han seleccionado teniendo en cuenta su disponibilidad por parte del fabricante, estojustifica el uso de redes de 9 resistencias y de bloques de conectores de 10 y 3 unidades.

72 5.10. IMPLEMENTACIÓN DEL HARDWARE

Con el esquema terminado se procede al diseño de la PCB. Las dimensiones son 58 x38 mm, se emplean dos caras (máximo permitido por la versión de estudiante de Eagle)con un grosor de pista de 0.6 mm y 0.3 mm. Debido al proceso de fabricación, un grosormenor podría dar lugar a pistas cortadas.

Con el «Layout Editor» se colocan los componentes y se rutan las pistas de formamanual. Durante el diseño de la PCB se presta especial atención a cumplir los siguientesobjetivos:

• Las pistas deben tener la menor longitud posible, especialmente las del oscilador ylas de datos USB.

• Prescindir de vías 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 sujeción de la placa mediante tornillos.

Como resultado de este trabajo, se decide que las redes de resistencias se coloquendebajo del microcontrolador, elevando éste mediante el uso de dos tiras de pines y unzócalo de 28 pines.

Puesto que la configuración analógico o digital de cada uno de los sensores de tipoAD será fijada en fábrica no se instalan jumpers, sino que se puentean o no empleandolos pines sobrantes de los otros componentes.

El software genera el fotolito de la cara Top (superior), Bottom (inferior), y Compo-nentes (que contiene la serigrafía de los mismos, pero que no se va a utilizar inicialmente)(figuras A.2, A.3, y A.4), así como los ficheros Gerber que contienen la información ne-cesaria para su fabricación industrial.

La placa de prototipo se fabrica de forma manual empleando una placa fotosensible ysiguiendo el siguiente procedimiento:

1. Se imprimen los fotolitos en láminas de acetato con una impresora de inyección detinta especial.

2. Se grapan las dos caras teniendo cuidado con que coincidan perfectamente los agu-jeros de ambas.

3. En una habitación con baja iluminación se separa el adhesivo protector de la placafotosensible y se coloca entre los acetatos.

4. Se exponen ambas caras por un periodo aproximado de 5 minutos a la luz de unainsoladora.


5. Se sumerge la placa en una solución de sosa cáustica que elimina los restos de capafotosensible en las zonas donde ha incidido la luz.

6. A continuación se elimina el material conductor de las zonas en las que no ha incidi-do la luz mediante un proceso llamado atacado que consiste en sumergir la placa enuna solución de agua oxigenada, ácido clorhídrico, agua y peróxido de hidrógeno apartes iguales.

7. Para terminar el proceso de insolado se frota con algodón y acetona para eliminarlos restos de la capa protectora que quedan sobre las pistas.

8. Finalmente se procede al mecanizado de la placa mediante una sierra y un taladropara realizar los orificios por los que pasarán los pines de los componentes, y los desujeción de la placa.

Una vez se ha terminado la fabricación se procede al montaje de los componentes.Para ello se aplica flux de soldadura sobre los pines y se calientan aportando estaño parasu fijación. Hay que prestar especial atención a los pines que actuan como vías, puestoque han de ser soldados por ambas caras.

Finalmente se realizan las comprobaciones eléctricas correspondientes mediante unpolímetro.

74 5.10. IMPLEMENTACIÓN DEL HARDWARE

CAPÍTULO 6

DISEÑO E IMPLEMENTACIÓN DELSOFTWARE

En este capítulo se desarrollarán los aspectos relativos al diseño e implementación delas partes software del proyecto.

6.1. INTRODUCCIÓN

Antes de entrar en el desarrollo propiamente dicho, es necesario explicar algunos delos fundamentos en los que se basa USB, ya que es necesario conocer ciertos detalles so-bre la comunicación y el proceso de enumerado. Posteriormente se describirá el algoritmoutilizado para el sistema HASP, y después se pasarán a explicar los detalles de la imple-mentación del firmware desarrollado para el microcontrolador, y software desarrolladopara el PC.

6.1.1. Endpoints y pipes

El flujo de datos que se produce entre el host y un dispositivo USB se organiza deforma lógica en pipes o tuberías. Una tubería es un canal lógico de datos entre ambos.Estas se conectan entre un endpoint o punto final del dispositivo y la capa de software quecontrola el hardware USB en el host. Los endpoints vienen configurados de fábrica, estánnumerados de forma única por cada dispositivo y se agrupan en conjuntos que se llamaninterfaces, de manera que el control de un periférico USB puede llevarse a cabo mediantela comunicación a través de varios endpoints.

76 6.1. INTRODUCCIÓN

Figura 6.1: Tuberías lógicas

Físicamente, 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 través del par de señales diferenciales D+/D- quepasan por el cable. A nivel lógico el software USB configura y administra los dispositivosmediante la tubería por defecto de control. Esta tubería utiliza el endpoint 0, que debeestar soportado por todos los dispositivos USB para su funcionamiento.

Durante el proceso de enumeración que tiene lugar inmediatamente después de conec-tar el periférico, el host obtiene a través de la tubería por defecto de control la informacióndel dispositivo y el resto de puntos finales disponibles en él. Finalmente le asigna una di-rección única en el bus.

En el nivel más alto, el software o driver que hace uso del dispositivo USB se comunicacon él a través de las tuberías conectadas a puntos finales. Como ejemplo se puede definirun dispositivo de almacenamiento en el que se dedique un endpoint para el envío decomandos de lectura y escritura, y otro para la transferencia de datos.

6.1.2. DescriptoresComo se comentó en el estado del arte, los descriptores contienen toda la información

que el host necesita para identificar al dispositivo y sus características, y así ser capaz debuscar y cargar el driver adecuado para su puesta en funcionamiento.

Los descriptores se organizan en una jerarquía que contiene los siguientes elementos:

• Descriptor de dispositivo: Indica la versión de USB con la que es compatible eldispositivo, el código del fabricante (asignado por el USB-IF), y el código del pro-ducto. También el número de descriptores de configuración presentes.

• Descriptor de configuración: Una configuración es un modo de operación del dis-positivo (por ejemplo una cámara podría operar como webcam o como cámara defotos). El host debe seleccionar una configuración y sólo puede haber una activa.Este descriptor especifica la potencia requerida, y el número de interfaces asociadoscon esa configuración. En la práctica son raros los dispositivos que ofrezcan más deuna configuración.

CAPÍTULO 6. DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE 77

• Descriptor de interfaz: Estos descriptores contienen el número de puntos finalesasociado con el interfaz, y la clase de dispositivo a la que pertenece (almacenamien-to masivo, HID, impresión, ...).

• Descriptor de endpoint: Especifica el número de endpoint, el tipo de transferenciasque se realizarán a través de él (interrupción, masiva, isócrona, ...), su longitud y sudirección desde el punto de vista del host: (IN=Del dispositivo al host, OUT=Delhost al dispositivo). El punto final 0 es necesario y predefinido, por tanto no necesitadescriptor.

• Descriptor de cadena: Contiene una cadena de texto que puede ser referenciadapor los descriptores anteriores, ejemplos comunes de cadenas son el nombre delfabricante o el número de serie.

Figura 6.2: Jerarquía de descriptores USB.

6.1.3. La clase HIDLa norma USB define más de diez clases de dispositivos. Estas clases agrupan un

conjunto de características que son comunes a cierto tipo de dispositivos USB y tienenrequisitos de transporte de datos similares. Cuando un dispositivo pertenece a una deestas clases no necesita drivers específicos puesto que sus capacidades y característicasestán definidas en un descriptor de clase. El sistema operativo puede utilizar driversgenéricos para una clase, lo que libera al fabricante de la obligación de crear y mantenerdrivers específicos para diversas plataformas. Las clases de dispositivo se especializan ensubclases que indican un tipo de dispositivo más concreto. En el descriptor de interfaz ode dispositivo figura el código de la clase a la que pertenece el dispositivo. Hay más de10 clases definidas en el estándar, siendo las pricipales:

• Audio

• Comunicaciones


• HID

• Impresora

• Almacenamiento masivo

• Concentrador

• Definido por el fabricante

La clase HID engloba fundamentalmente, a dispositivos que son utilizados por huma-nos para controlar el funcionamiento de computadores. Ejemplos típicos de dispositivosde la clase HID incluyen teclados, ratones y controles de juegos, pero también disposi-tivos que no requieren de interacción humana pero que proporcionan los datos de formasimilar a dispositivos HID, como lectores de códigos de barras [UI01]. Esto lo hace idealpara satisfacer los requisitos del proyecto por lo que será la clase de dispositivo usada.

Los report descriptors (descriptores de informe) son descriptores específicos de laclase HID que describen el protocolo usado y definen elementos que describen la posiciónde un botón o estado, esta información se usa para:

• Determinar a dónde enviar la entrada –por ejemplo, enviarla a la API de ratón ojoystick–

• Permitir al software asignar funcionalidad a la entrada –por ejemplo, usar la entradade un ratón para mover el cursor por la pantalla–

Cuando se conecta un dispositivo HID, su descriptor de informe se pasa al driver HID,que lo decodifica y se especializa para manejar el dispositivo, dirigiendo los flujos de E/Sa donde corresponda (API de teclado, ratón, ...).

Los componentes principales de un descriptor de clase HID son:

• Usage: Los usages, o usos son información que el fabricante proporciona sobre quése está midiendo exactamente (el giro de un volante, la presión de un pedal, el ejede un joystick, ...), y por lo tanto qué se debe hacer con los datos. Los usages seorganizan en páginas de uso (usage pages) que definen conjuntos globales (contro-les de simulación, periférico de juegos...), y los identificadores de uso (usage IDs)definen controles específicos como freno, gatillo, o botón izquierdo del ratón.

• Report: Los reports, o informes indican el formato en el que se transmiten los datos(por ejemplo: 3 campos de 8 bits que codifican enteros sin signo de 0 a 1023).

• Collection: Los collection o colecciones identifican la relación entre dos o máselementos de datos (por ejemplo: x e y son un punto en 2 dimensiones).


Figura 6.3: Papel de los descriptores de informe en la jerarquía de descriptores USB.

Una vez definido el descriptor de informe, el dispositivo debe generar contínuamenteinformes sobre el estado de los sensores en un intervalo de tiempo definido en el descriptordel endpoint (1 ms como mínimo en USB 1.x), y enviarlos mediante una transferencia deinterrupción.

Los datos deben ser formateados de manera que coincidan con lo establecido en eldescriptor de informe y enviados secuencialmente.

El diseño de descriptores de informe puede llegar a ser muy complejo, por ello parailustrar esta idea se propone el siguiente ejemplo: en la figura 6.4 se muestra el informede un joystick de dos ejes y tres botones. En el descriptor se ha definido que la posiciónde los ejes se representa con 12 bits de precisión, y que los dos bits más significativosde la lectura del eje X se encuentran en el bit 1 y 0 del byte 2, el resto en el byte 1. Conel eje Y sucede de manera similar. En cuanto a los pulsadores su estado se codifica contres bits situados a continuación de la lectura del eje Y (1 significa pulsado, 0 significano pulsado), y se rellena el último bit del byte 3 con un valor constante por defecto (0).Observese que la representación de valores numéricos se realiza en formato little endian.


Figura 6.4: Report de ejemplo

Un descriptor de informe HID que cumple estas especificaciones sería el siguiente:

USAGE_PAGE (Generic Desktop) Pag. de uso: Perif. genérico de escritorioUSAGE (Joystick) Tipo concreto: JoystickCOLLECTION (Application) Col.: Application (Datos reconocibles)COLLECTION (Physical) Col.:Physical (Coordenadas puntuales)LOGICAL_MINIMUM (0) Valor mínimo: 0LOGICAL_MAXIMUM (4096) Valor máximo: 4096USAGE (X) Uso: Eje XUSAGE (Y) Uso: Eje YREPORT_SIZE (12) Tamaño del informe: 12 bitsREPORT_COUNT (2) Número de informes: 2INPUT (Data,Var,Abs) Datos hacia el host (variables)END_COLLECTION Fín de la colección PhysicalUSAGE_PAGE (Button) Pag. de uso: BotónUSAGE_MINIMUM (Button 1) Elemento mínimo: 1 (1er botón)USAGE_MAXIMUM (Button 3) Elemento máximo: 3 (3er botón)LOGICAL_MINIMUM (0) Valor mínimo: 0LOGICAL_MAXIMUM (1) Valor máximo: 1REPORT_SIZE (1) Tamaño del informe: 1 bitREPORT_COUNT (3) Número de informes: 3INPUT (Data,Var,Abs) Datos hacia el host (variables)REPORT_COUNT (1) Tamaño del informe: 1 bitINPUT (Cnst,Var,Abs) Datos hacia el host (constantes)END_COLLECTION Fín de la colección Application

El dispositivo del ejemplo deberá cada 10 ms (definido en el descriptor de clase HID,que no se muestra) leer el estado de los dos ejes y los tres botones, alinearlos de la formaque aparece en la ilustración mediante desplazamientos y operaciones lógicas, y enviarlomediante una transferencia de tipo interrupción.

Del descriptor hay que destacar que el orden de los datos coincide con el orden enque aparecen sus descripciones, y que el uso de la colección «Application» hace que elsistema operativo reconozca los ejes y botones como tales y así se los muestre a las aplica-ciones que mediante la API correspondiente solicitan el acceso a joysticks. Para aclarar elconcepto de «Application» se concretará la idea para el sistema operativo Windows XP:


Con este descriptor, Windows lo reconoce como un joystick estándar, e incluso aparecelistado en la ventana «Dispositivos de juego» del panel de control, permitiendo incluso sucalibrado. También puede ser usado en cualquier juego de PC para Windows sin ningunamodificación ni drivers o software adicional, solo hay que indicar que se quiere usar esedispositivo como entrada en el apartado de configuración del juego.

Las librerías de E/S del usuario como plib [JB], o Microsoft DirectInput serán total-mente compatibles con él, lo que pone de manifiesto la importancia de diseñar correcta-mente el descriptor HID.

6.2. ALGORITMO HASP

Tal y como se explicó en los primeros capítulos, el dispositivo debe comportarse comouna llave HASP de forma que su conexión física con el computador sea un requisitoindispensable para el funcionamiento de un determinado software protegido en el PC.

El computador mantiene un diálogo contínuo con el dispositivo durante el cual inter-cambian información. Si el diálogo se interrumpiese o los datos intercambiados no fueranlos esperados, el software usuario del sistema HASP en el PC es notificado de ello paraque actúe en consecuencia (por ejemplo mostrando un aviso al usuario, o bloqueándoseen modo de demostración con funcionalidad o tiempo de uso reducido).

Una posible implementación, válida y ligera consiste en la autenticación por desafío-respuesta, representada en la figura 6.5, y cuyo funcionamiento es el siguiente:

Tanto el host como el dispositivo HASP pueden ejecutar un algoritmo f que ha sidoimplementado en ambos. Este algoritmo toma como entrada una cadena de bits, y con laayuda de una clave secreta que ambos conocen produce una cadena de bits de salida. Eldiálogo consiste en lo siguiente:

1. El host genera un mensaje aleatorio x.

2. El host envía este mensaje al dispositivo.

3. Tanto el dispositivo como el host calculan la respuesta con la ayuda de la clavecompartida c: y = f(x,c)

4. El dispositivo envía su respuesta de vuelta al host.

5. El host compara la respuesta recibida con su propia respuesta. En función de lacoincidencia o no de ambas determinará que el dispositivo es falso o no.

6. Se repite todo el proceso tras un intervalo de tiempo.

La información intercambiada no contiene ningún mensaje relevante, residiendo todala importancia de éste en la respuesta generada, que tratará de asegurar que al otro ladodel bus se está ejecutando el mismo algoritmo, con la misma clave. Estos dos factores sonfundamentales para el funcionamiento del sistema.

82 6.2. ALGORITMO HASP

Figura 6.5: Intercambio de información HASP.

Los dispositivos HASP más modernos utilizan algoritmos de cifrado simétrico com-plejos como el AES [AKS], un algoritmo de 128 bits extremadamente robusto, perocomputacional y espacialmente costoso, especialmente para dispositivos empotrados.

Dados los requisitos, con el fin de proponer un algoritmo desconocido para un po-tencial hacker, se ha optado por el diseño de un pequeño algoritmo de validación pordesafío/respuesta basado en CRC, rápido y que requiere de la intervención de una clavesecreta conocida por ambas partes. Esta clave puede actuar como código de licencia delsoftware protegido, de manera que cada producto de software distinto utilice el mismoalgoritmo pero con claves diferentes.

La cadena generada por el host (cadena de desafío), es una palabra de 72 bits rellenadacon datos aleatorios que contiene una subcadena denominada palabra de información.Esta subcadena tiene un tamaño de 8 bits, y puede comenzar en cualquier posición (offset)de la cadena de desafío desde la 1 hasta la 16.

Como se ha explicado antes, tanto host (computador) como dispositivo disponen deuna clave secreta. Esta clave consiste en un vector de 11 palabras de 16 bits. La palabrade información contiene dos campos (enteros sin signo): el offset donde comenzará lapalabra de información en la próxima cadena que envíe el host y un índice. El primercampo ocupa 4 bits, lo que permite un desplazamiento de 16 posiciones y el índice ocupa3 bits, lo que le otorga un rango de 0 a 7. Las posiciones que ocupan en la palabra deinformación se muestran en la figura 6.6.

Cuando el dispositivo recibe la cadena de desafío, ya conoce del ciclo anterior el offsetdonde comienza la palabra de información de esta cadena recien recibida, la decodifica yobtiene el índice y el siguiente offset. Este último lo guarda para el siguiente ciclo.

A continuación se concatenan las subcadenas que quedan a la izquerda y a la derechade la cadena de desafío obteniéndose una nueva cadena, c’ de 64 bits. En el siguiente pasose toma el índice decodificado de la palabra de información y se calcula la función XORde cada byte de c’ con los elementos del vector de clave comenzando desde el índice.


Figura 6.6: Cadena de desafío

Finalmente se calcula el CRC acumulando el código CRC calculado en el ciclo ante-rior y se obtiene la cadena de respuesta de 64 bits.

Obsérvese que, la respuesta en cada ciclo depende de datos calculados en el cicloanterior (offset de la palabra de información y CRC), esto hace que para una cadena dedesafío concreta no exista una respuesta concreta sino que ha de considerarse todo eldiálogo anterior, lo cual supone una dificultad añadida 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 lacadena de desafío, 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 podríaenviar al dispositivo sólo cadenas de desafío con el primer bit a 1 de forma que las cadenasde respuesta no tengan dependencias con las anteriores.

Para probar la idea se ha implementado una aplicación llamada ’swval’ que simula elcomportamiento de ambas partes y muestra en pantalla la cadena generada, y las cade-nas calculadas tanto por el host como por el dispositivo HASP. Su salida por consola semuestra en la figura 6.8.

Los cálculos se han realizado en aritmética de 8 bits de forma que portarlo a la arqui-tectura PIC18 sea inmediato.

6.3. FIRMWARE

6.3.1. Configuración del microcontroladorLa arquitectura PIC18 dispone de un conjunto de registros de configuración que esta-

blecen algunos ajustes globales del microcontrolador, los más relevantes son los siguien-tes:

84 6.3. FIRMWARE

Figura 6.7: Procedimiento

Figura 6.8: Imagen de la salida por consola de la aplicación de prueba ’swval’.


• Fuente de oscilación

• Temporizador de arranque

• Detector de caída de tensión alimentación

• Detector de fallo del reloj

• Uso del regulador de tensión interno para USB

• Perro guardián

• Reset al desbordarse la pila

• Protección contra lectura de áreas de código.

Ocupan desde la dirección (hexadecimal) 300000 hasta la 3FFFFF. Esta configuraciónse almacena en memoria flash. La figura 6.1 muestra la lista de registros de configuración.

Cuadro 6.1: Tabla de registros de configuración.

A continuación se explica la configuración aplicada a los registros relevantes.

OsciladorDurante la etapa de diseño del hardware se decidió que se necesita una fuente de

oscilación de 4 MHz mediante la conexión de un cristal de cuarzo externo como osciladorprimario en modo HSPLL (ya que se utiliza el módulo PLL), y que esto debía generar los48 MHz necesarios para la operación del módulo USB, como aparece en la figura 5.5.

La ruta seguida por las señales de reloj hasta llegar a la CPU, el módulo USB y elresto de módulos se controla mediante los registros CONFIG1H y CONFIG1L.

86 6.3. FIRMWARE

Cuadro 6.2: Configuración del registro CONFIG1L.

Cuadro 6.3: Configuración del registro CONFIG1H.


Módulo USB y otras configuraciones

Para la operación del módulo USB utilizando el regulador de tensión interno es nece-sario activar el bit VREGEN del registro CONFIG2L


Este registro también establece la configuración de otras características, como el tem-porizador de arranque, que mantiene al micro en estado de reset durante un periodo paradar tiempo al cristal de cuarzo a que se estabilice, o el detector de caida de tensión enla alimentación, que reinicia el micro si la tensión alimentación desciende por debajo decierto voltaje. Ambas características están activadas.

Puesto que el pin RE3, que se corresponde con la entrada digital 0 del diseño estámultiplexado con MCLR# (una señal de reset externa), hay que indicar en el registro deconfiguración CONFIG3H que la función de ese pin es la de entrada digital de propó-sito general RE3. También resulta útil configurar que los pines 4 a 0 del puerto B esténconfigurados como entradas analógicas ya desde el momento del arranque.

88 6.3. FIRMWARE


Protección del código

La arquitectura ofrece la posibilidad de proteger diversos segmentos de código contrala lectura mediante un programador. Si se intenta leer un área protegida la lectura serealiza, pero todos los datos leidos son «0». Aquí resulta de gran importancia protegertodo el código almacenado en la memoria ROM para evitar la fabricación no autorizadade réplicas, o el desensamblado del mismo.




ResumenFinalmente la configuración de estos registros queda como indica la tabla 6.8.

Registro ValorCONFIG1L 0010 0000CONFIG1H 0000 1110CONFIG2L 0011 1110CONFIG3H 0000 0100CONFIG5L 0000 0000CONFIG5H 0000 0000

Cuadro 6.8: Configuración del micro.

El resto de registros toman sus valores predeterminados. Estos valores se programanen el momento de cargar el firmware en la memoria Flash del micro. El compilador CCSpermite definirlos mediante la siguiente directiva:

1 #fuses HSPLL,NOWDT,PROTECT,NOLVP,NODEBUG,USBDIV,PLL1,

2 CPUDIV1,VREGEN,NOMCLR,CPB

6.3.2. ProgramaEl firmware realiza las siguientes tareas:

• Comunicación USB

• Adquisición de datos

• Formateo y comunicación de datos

• Recepción y envío de las cadenas HASP

El bucle principal cumple el diagrama de flujo de la figura 6.9.

90 6.3. FIRMWARE

Figura 6.9: Diagrama de flujo principal.

6.3.3. Comunicación USBEl compilador CCS y sus librerías se encargan de los detalles a bajo nivel del hardware

del módulo USB, y gestiona el proceso de enumeración y las transferencias. Para ello hayque incluir los archivos:

• pic18_usb.h: Implementa una capa que controla el hardware USB.

• usb.c: Gestiona el protocolo USB, el proceso de enumeración y los descriptores.

Mediante la siguiente directiva se indica que el periférico es de velocidad completa:

1 #define USB_USE_FULL_SPEED TRUE

También hay que indicar que el dispositivo pertenecerá a la clase HID para que se genereel código necesario para manejar el protocolo.

1 #define USB_HID_DEVICE TRUE

EndpointsA continuación hay que decidir cuantos endpoints se necesitan, la orientación de los

flujos de datos, y su propósito.Para determinarlo hay que analizar las comunicaciones que se producen entre el host y

el dispositivo recordando que por una parte se comunica la información sobre los sensores,y por otra hay un flujo bidireccional para el intercambio de cadenas de desafío/respuesta.Por lo tanto se propone el uso de dos endpoints, uno de tipo IN y otro de tipo IN OUT.


Figura 6.10: Endpoints utilizados, dirección y propósito.

Ahora hay que decidir el tamaño de cada endpoint. Analicemos en primer lugar eltamaño que ocupa un informe sobre el estado de los sensores. Hay que tener en cuenta quela unidad mínima de transmisión es el byte, por lo que hay que redondear estos tamañosa múltiplos 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 (conversión 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 dela conversión A/D.

En total se necesitan 23 bytes para la transmisión del estado de los sensores, por loque el endpoint dedicado para ello tendrá ese tamaño.

En cuanto al tamaño del endpoint para el sistema HASP según la definición del al-goritmo se usan 9 bytes del host al dispositivo (OUT), y 8 bytes del dispositivo al host(IN).

Después se activan los endpoints que se van a utilizar (además del endpoint 0 que esimprescindible), y el tamaño de cada uno.

1 #define USB_EP1_TX_ENABLE USB_ENABLE_INTERRUPT

2 #define USB_EP1_TX_SIZE 23

3

4 #define USB_EP2_TX_ENABLE USB_ENABLE_INTERRUPT

5 #define USB_EP2_TX_SIZE 8

6

7 #define USB_EP2_RX_ENABLE USB_ENABLE_INTERRUPT

8 #define USB_EP2_RX_SIZE 9

92 6.3. FIRMWARE

Estas sentencias activan los registros de control del módulo USB que habilitan losendpoints 0 (siempre activo), 1 y 2.

DescriptoresAntes de proceder al diseño de los descriptores recordemos que el propósito es que

el host vea las dos funcionalidades del dispositivo, tanto el sistema HASP como el desensorización. Para ello se propone el uso de dos interfaces, de manera que la jerarquíade descriptores quedaría como muestra la figura 6.11.

Figura 6.11: Jerarquía de descriptores para el dispositivo

El archivo lsred_desc.h contiene los descriptores del dispositivo, definidos como vec-tores de tipo char constante. El compilador CCS proporciona facilidades para la progra-mación de descriptores, como constantes con significado simbólico. Se puede extraer elfichero de cabecera de descriptores de cualquier ejemplo USB suministrado con el compi-lador y personalizarlo para la aplicación que se quiera desarrollar. El archivo lsred_desc.hes una modificación del ejemplo «ex_usb_kmouse» que implementa un dispositivo com-binado de teclado y ratón. Con esto en mente se diseñan los siguientes descriptores:

El código del fabricante (Vendor ID o VID) es asignado por el USB-IF, pero Microchipcede su VID para el desarrollo de dispositivos USB utilizando sus microcontroladores. Elcódigo del producto servirá para identificar al dispositivo cuando se conecte, se puede usaruna codificación definida por el diseñador de acuerdo a las características del dispositivo.En este caso la F simboliza que lleva HASP integrado, y el 2 indica que es la segundaversión del producto, la primera fue una implementación de prueba. En cuanto al númerode serie al igual que ocurre con el nombre del fabricante o el vendedor, se puede utilizaruna cadena ASCII. Luego esta cadena puede ser recuperada por el software para permitiral fabricante llevar un control sobre su producción, lo que también resulta interesante. Para


Versión USB 2.0Codigo del fabricante Microchip (04D8)Código de producto F002Versión del producto 0002Cadena del fabricante «LSyM»Cadena del producto «LSyM DAQ Board»

Cadena del número de serie «DAQ-0000»N. de configuraciones 1

Cuadro 6.9: Descriptor de dispositivo

Número de interfaces soportados 2Identificador de esta configuración 1

Opciones de energía Alimentado por el busPotencia requerida 100 mA

Cuadro 6.10: Descriptor de configuración

este tipo de dispositivos se ha fijado un número de serie del tipo DAQ-xxxx donde la partederecha del guión es un número que se incrementa en cada dispositivo fabricado. Másadelante se verá cómo se ha conseguido modificar el número de serie una vez programadoel microcontrolador sin tener que modificar la cadena constante del fichero lsred_desc.hy volver a compilar el firmware.

Como se puede observar, se solicitan 100 mA que es más de lo que necesita el mi-crocontrolador, pero se ha elegido este ajuste para contar con suficiente corriente paraalimentar posibles futuras ampliaciones del dispositivo.

En la siguiente tabla se muestra el descriptor HID utilizado, es el mismo para el inter-faz de los sensores que para el HASP, lo único que cambia es el descriptor de informe.

Versión de HID 1.1Código de idioma No definido

Tipo de descriptor de informe HID

Cuadro 6.13: Descriptor HID

Numero de interfaz 0Código de clase HID (0x03)

Nombre de este interfaz «LSyM DAQ Board»

Cuadro 6.11: Descriptor de interfaz 1

94 6.3. FIRMWARE

Numero de interfaz 1Código de clase HID (0x03)

Nombre de este interfaz «LSyM HASP Device»

Cuadro 6.12: Descriptor de interfaz 2

Código de endpoint 1Dirección IN

Tamaño máximo del paquete 23 bytesIntervalo de lectura 10 ms

Cuadro 6.14: Descriptor de endpoint 1 (IN)

Código de endpoint 2Dirección IN


Cuadro 6.15: Descriptor de endpoint 2 (IN)

Código de endpoint 2Dirección OUT


Cuadro 6.16: Descriptor de endpoint 2 (OUT)

Con el fin de agilizar el diseño de descriptores de informe, el USB-IF proporcionala herramienta «Hid Descriptor Tool», que permite la edición de descriptores de maneravisual.


Figura 6.12: Captura de HID descriptor tool

Con ella se ha generado el siguiente descriptor de informe para la sensorización:

USAGE_PAGE (Generic Desktop) Pag. de uso: Periférico de escritorioUSAGE (Game Pad) Uso concreto: GamepadCOLLECTION (Application)COLLECTION (Physical)USAGE (X) Eje XUSAGE (Y) Eje YUSAGE (Z) Eje ZUSAGE (Rx) Rotación XUSAGE (Ry) Rotación YUSAGE (Rz) Rotación ZUSAGE (Wheel) VolanteUSAGE (Slider) DeslizadorLOGICAL_MINIMUM (0) Mínimo lógico: 0LOGICAL_MAXIMUM (1023) Máximo lógico: 1023REPORT_SIZE (16) Tamaño de informe: 16 bitsREPORT_COUNT (8) N. de informes: 8INPUT (Data,Var,Abs) Datos hacia el host (variables)USAGE_PAGE (Simulation Controls) Pag. de uso: Controles de simulaciónUSAGE (Throttle) Acelerador

96 6.3. FIRMWARE

USAGE (Brake) FrenoLOGICAL_MINIMUM (0) Mínimo lógico: 0LOGICAL_MAXIMUM (1023) Máximo lógico: 1023REPORT_SIZE (16) Tamaño del informe: 16 bitsREPORT_COUNT (2) N. de informes: 2INPUT (Data,Var,Abs) Datos hacia el host (variables)USAGE_PAGE (Button) BotónUSAGE_MINIMUM (Button 1) Primer botón: 1USAGE_MAXIMUM (Button 20) Último botón: 20LOGICAL_MINIMUM (0) Mínimo lógico: 0LOGICAL_MAXIMUM (1) Máximo lógico: 1REPORT_SIZE (1) Tamaño del informe: 1 bitREPORT_COUNT (20) N. de informes: 20INPUT (Data,Var,Abs) Datos hacia el host (variables)REPORT_COUNT (4) N. de informes 4INPUT (Cnst,Var,Abs) Datos hacia el host (constantes)END_COLLECTIONEND_COLLECTION

Hay tres aspectos importantes a aclarar sobre el descriptor: En primer lugar el dis-positivo se identifica como un gamepad puesto que es un periférico muy parecido y estoasegurará la compatibilidad con librerías de entrada. Otro aspecto importante es que losvalores máximo y mínimo van de 0 a 1023 coincidiendo con los 11 bits de precisión delconversor A/D del PIC, esto permite a las librerías de entrada escalar el valor a otros ran-gos. Sin embargo el tamaño del informe es de 16 bits para simplificar el formateado delos datos de salida como se indicó antes. Finalmente a cada entrada analógica hay quedarle un uso concreto aunque luego no se corresponda con el real también para asegurarla compatibilidad.

Usando la misma herramienta, se ha generado el siguiente descriptor de informe parael sistema HASP:

USAGE_PAGE (Vendor Defined Page 1) Pag uso: definido por el fabricanteUSAGE (Vendor Usage 1) Uso definido por el vendedorCOLLECTION (Application)USAGE_MINIMUM (Vendor Usage 1) Valor mín definido por el fabricanteUSAGE_MAXIMUM (Vendor Usage 1) Valor máx definido por el fabricanteLOGICAL_MINIMUM (0) Mínimo lógico: 0LOGICAL_MAXIMUM (255) Máximo lógico: 255REPORT_SIZE (8) Tamaño del informe: 8 bitsREPORT_COUNT (8) Número de informes: 8INPUT (Data,Var,Abs) Datos hacia el host (variables)USAGE_MINIMUM (Vendor Usage 1) Valor min definido por el fabricanteUSAGE_MAXIMUM (Vendor Usage 1) Valor max definido por el fabricanteLOGICAL_MINIMUM (0) Mínimo lógico: 0LOGICAL_MAXIMUM (255) Máximo lógico: 255REPORT_SIZE (8) Tamaño del informe: 8 bitsREPORT_COUNT (9) Número de informes: 9OUTPUT (Data,Var,Abs) Datos desde el hostEND_COLLECTION


De este descriptor hay que destacar que se le debe otorgar un valor mínimo y máximo acada elemento de informe, que el tamaño de los informes por el número de estos coincidecon las especificaciones del algoritmo HASP (9 bytes de salida y 8 bytes de entrada) y queel uso de este interfaz está definido por el fabricante, con lo que no lo identificará comoun gamepad y no enviará sus datos a la API de E/S, siendo responsabilidad del softwarecomunicarse con él a bajo nivel.

6.3.4. Adquisición y formateado de datosUna de las tareas fundamentales del micro es la adquisición del estado de los sensores.

En esta subsección se explica el diseño y la implementación de esta tarea.

Configuración del conversor A/DEl microcontrolador PIC18F2550 dispone, como ya se ha comentado de un conversor

A/D de 10 bits y 10 canales multiplexados. Este módulo permite la conversión de un nivelde tensión analógico a su correspondiente valor digital de 10 bits, que aporta un rangodigital de 0 a 1023.

El voltaje de referencia analógico (Vref+ y Vref-) es seleccionable por software, entreVDD y VSS o el voltaje presente en los pines RA3 y RA2 respectivamente. Este rango devoltajes también llamado Vref afecta directamente a la resolución del conversor según laecuación 6.1.

Res =V ref +−V ref−

1024=V ref

1024(6.1)

La mínima diferencia entre Vref+ y Vref- es de 2 V.

Recordemos que se pretende utilizar VDD como Vref+ y GND como Vref- para opti-mizar el uso de los pines.

Los pines del chip que vayan a ser usados como entradas analógicas deben configu-rarse como pines de entrada mediante la escritura en los registros TRIS (de tristate, otriestado) que controlan la dirección de las señales tal y como se mostró en la figura 5.14.

Para configurar estos parámetros se escribe en el registro de control ADCON1 (fig.6.13), donde se seleccionan las referencias de tensión y se escoge un patrón de entradasde tipo analógico o digital (nótese que no se permite cualquier combinación). En este casoseleccionamos las 10 entradas analógicas disponibles como tales (las entradas marcadascon (2) no están disponibles en la versión del micro de 28 pines que se está utilizando).

98 6.3. FIRMWARE

Figura 6.13: Registro de configuración A/D ADCON1

El proceso de conversión se compone de dos tiempos: el tiempo de adquisición y eltiempo de conversión. Durante el primer tiempo el condensador interno del conversorA/D se carga hasta el nivel de la línea analógica seleccionada, una vez cargado durante eltiempo de conversión se desconecta de la línea analógica y se transforma este nivel en unvalor digital mediante aproximaciones sucesivas.

El tiempo de adquisición se puede programar de manera que el módulo espere eltiempo necesario antes de realizar la conversión, o se puede hacer de forma manual pro-gramando un bucle de espera activa. El TAD es el tiempo de conversión por bit y se definecomo el tiempo necesario para determinar el valor de un solo bit del resultado de la con-versión. Esta unidad de tiempo debe tener un valor de entre 1.4 µs y 25 µs si se utilizauna fuente fuente de reloj externa, o de 1 µs si se utiliza el oscilador RC interno.

El tiempo de adquisición se puede configurar entre 2 y 20 TAD (el valor recomen-


Figura 6.14: Proceso de toma de una muestra con tiempo de adquisición de 4 TAD

dado es de 2.45 µs), mientras que para realizar la conversión se necesitan 11 TAD. Laconversión se inicia escribiendo el valor 1 en el bit GO/DONE# del registro ADCON0.

El resultado de la conversión se escribe en los registros ADCONH:ADCONL. El valorde 11 bits puede ser justificado en el registro compuesto de 16 bits a la izquierda o a laderecha según la configuración establecida en el registro ADCON0, los bits no usadosson rellenados con ceros y se genera una interrupción. El condensador queda conectado ala línea analógica para una nueva conversión.

Se utiliza el oscilador RC interno (1 MHz), y un valor de tiempo de conversión auto-mático de 2 TAD.

Finalmente, con el registro ADCON0 se puede controlar el multiplexor para seleccio-nar la entrada analógica deseada.

100 6.3. FIRMWARE




Estos registros son escritos por el compilador CCS mediante llamadas a funciones dealto nivel, pero es imprescindible conocer su funcionamiento para entender las limitacio-nes del hardware.

Implementación de la adquisición de datosEl archivo lsred_main.c contiene el programa principal y otras subrutinas de apoyo.Para la inicialización del hardware se define una función «sensorInit()» que hace lo

siguiente:

• Configura la función y dirección de cada pin mediante los registros TRIS.

• Activa los pull-up del puerto B.

• Selecciona todos los pines ANx como entradas analógicas.

• Establece el oscilador RC interno del conversor A/D.

102 6.3. FIRMWARE

• Selecciona al entrada analógica AN0.

El código correspondiente es:

1 SET_TRIS_A(0b10111111);

2 SET_TRIS_B(0b11111111);

3 SET_TRIS_C(0b11000111);

4 PORT_B_PULLUPS(TRUE);

5 setup_adc_ports(ALL_ANALOG);

6 setup_adc(ADC_CLOCK_INTERNAL);

7 set_adc_channel(0);

Esta función se llama una vez desde el programa principal y deja el hardware listopara realizar las conversiones.

Para la generación del informe HID se define un vector de tipo char global con elnombre «out_data» de 23 elementos. El vector es rellenado por la función «sensorTask()»,cuyo funcionamiento es el siguiente:

• Inicializa a 0 todo el vector.

• Selecciona el primer canal analógico.

• Toma una muestra del canal.

• Copia los 8 bits más bajos de la conversión en el primer byte del vector.

• Copia los 2 bits restantes de la conversión en los dos bits menos significativos delsiguiente byte del vector.

• Repite el proceso con las 9 entradas analógicas restantes incrementando el índicedel vector «out_data».

El código que realiza esta tarea es:

1 for(i=0;i<23;i++) out_data[i] = 0x0;

2

3 ...

4

5 set_adc_channel(channel);

6 read_adc(ADC_START_ONLY);

7 sample = read_adc(ADC_READ_ONLY);

8 out_data[i] = sample & 0x00FF;

9 out_data[i+1] = (sample & 0x300) >> 8;

10 EvaluarAD(channel, sample);

11

12 ...


Como puede observarse, por cada canal convertido se realiza una llamada a la función«EvaluarAD()». Antes de explicar su propósito recordemos el número total de entradasfísicas del chip:

Tipo de entrada Número ID asignadoEntradas digitales 10 D0..9

Entradas analógicas 10 AD0..9

Cuadro 6.17: Número y tipo de entradas

Sin embargo, en el descriptor se notifica al host de que el número de entradas digitalesno es 10 sino 20. Durante el diseño del hardware se decidió que cada entrada analógicatendría asociada una entrada digital «simulada», cuyo valor lógico dependería del valorde la última muestra tomada en su entrada analógica correspondiente. Esto permite conec-tar pulsadores a entradas analógicas cerrando el jumper adecuado. Las entradas digitalesreales (que disponen de un pin digital asignado en el chip) se numeran de D0 a D9, y lassimuladas de D10 a D19.

Figura 6.17: Funcionamiento de las entradas digitales simuladas.

Como se muestra en la figura 6.17, cuando se toma una muestra del canal asociadoa la entrada ADx, se evalúa si el valor está por encima o por debajo de cierto umbral«UMBRAL_AD», definido como constante en el programa, si es mayor que el valor de laentrada simulada Dy es 0 (no pulsado) donde y = x+10, si es menor o igual es 1 (pulsado).La función «Evaluar_AD» toma como parámetros la muestra obtenida y el canal x, evalúala ecuación 6.2 y escribe el resultado en el bit correspondiente del vector «out_data» deinforme. El umbral se ha fijado en 700 por observar durante las fases de depuración quees un valor adecuado.

Dy =

1 si ADx ≤ UMBRAL_AD0 si ADx > UMBRAL_AD

y = x+ 10 (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 según la clase HID, 0 significa no pulsado y 1 significapulsado. Sin embargo debido al esquema de conexión mediante pull-up los valores queobtenemos son los complementarios.

1 out_data[20] |= (~D0&0x1);

2 out_data[20] |= (~D1&0x1)<< 1;

3 out_data[20] |= (~D2&0x1)<< 2;

4 out_data[20] |= (~D3&0x1)<< 3;

5 out_data[20] |= (~D4&0x1)<< 4;

6 out_data[20] |= (~D5&0x1)<< 5;

7 out_data[20] |= (~D6&0x1)<< 6;

8 out_data[20] |= (~D7&0x1)<< 7;

9

10 out_data[21] |= (~D8&0x1);

11 out_data[21] |= (~D9&0x1)<< 1;

Una de las dificultades más comunes al muestrear el estado de pulsadores a gran ve-locidad suele ser el problema de los rebotes. Los rebotes son fluctuaciones de una señalconectada a un pulsador o switch que se producen al accionarlo, esto ocasiona que la tran-sición de la señal no sea limpia debido a las imperfecciones del mecanismo y dando lugara la presencia de niveles lógicos aleatorios durante un corto intervalo de tiempo.

Figura 6.18: Rebote producido al presionar un pulsador.

Existen varias soluciones a este problema, desde la instalación de comparadores detipo Schmitt Trigger hasta la reducción de la frecuencia de muestreo. En este caso comolos informes se generan cada 10ms esto no supone un problema puesto que el intervalode tiempo es suficientemente grande como para que la señal se estabilice.

Finalmente se envía el informe por el endpoint 1.

1 usb_put_packet(1,out_data,23,USB_DTS_TOGGLE);


Función Propósitohasp_init() Inicializa la librería.

sign() Recibe una cadena de desafío y devuelve la respuesta.

Cuadro 6.18: Interfaz de la librería HASP para PIC18.

6.3.5. Implementación del algoritmo HASPPara el manejo del sistema HASP se ha implementado una librería que prácticamente

contiene el código realizado en la aplicación de prueba «swval». El interfaz de la mismaes:

La función «HASPTask()» lee la cadena de desafío que ha llegado por el endpoint 2,llama a sign() para obtener la respuesta, y envía esta última de nuevo por el endpoint 2.

1 usb_get_packet(2, data_buffer, 9);

2 sign((ptrWord)data_buffer);

3 usb_put_packet(2, data_buffer, 8, USB_DTS_TOGGLE);

6.3.6. Programa principalEl programa principal sigue básicamente el diagrama de flujo representado en la fi-

gura 6.9. En primer lugar inicializa el hardware del conversor A/D y los puertos de E/S,la librería USB y la librería HASP. Después entra en bucle infinito en el que atiende elprotocolo USB, y periódicamente llama a sensorTask. Si se reciben datos de HASP por elendpoint 2 se llama a «HASPTask()». Finalmente se incluye un retardo de 4 ms para espe-rar antes de generar el siguiente informe. El tiempo invertido en realizar las conversionesañadido al tiempo de espera da un valor cercano a 10 ms.

1 sensorInit();

2 usb_init_cs();

3 hasp_init();

4

5 while (TRUE)

6 usb_task();

7 if (usb_enumerated())

8 sensorTask();

9 if (usb_kbhit(2))

10 HASPTask();

11

12

13 delay_ms(4);

14

106 6.3. FIRMWARE

6.3.7. Generación del ejecutableEl compilador genera un ejecutable en formato HEX (INHX32) que contiene una ima-

gen de la memoria FLASH y los registros de configuración mapeados a partir de la direc-ción 300000. Para programarlo en el chip se debe colocar en el módulo de programacióny pulsar el botón «program» del MPLAB. Mediante el programador USB se programa lamemoria en cuestión de segundos y el micro queda listo para funcionar.

6.3.8. BootloaderPara cumplir todos los requisitos del proyecto se debe dotar al sistema de un mecanis-

mo para la actualización del firmware que ejecuta, y de otros parámetros variables comoel número de serie o la clave HASP. Todo ello debe poder realizarse mediante el enlaceUSB del micro sin necesidad de extraerlo del circuito impreso y colocarlo en un módulode programación.

Las actualizaciones de firmware serán de gran utilidad para los usuarios en caso deque después de la entrega del producto se detecte algún bug o se realice alguna mejora,permitiendo a este instalar la última versión sin requerir una intervención técnica. Por otraparte, el poder reprogramar algunos parámetros como el número de serie y la clave HASPson útiles para los desarrolladores o durante el proceso de fabricación.

Para cubrir estas necesidades se utilizan Bootloaders o cargadores de arranque. LosBootloaders son piezas de software que suelen residir en las primeras posiciones de me-moria y por lo general no se pueden actualizar. Su propósito es reprogramar el área dememoria del firmware de aplicación con datos nuevos recibidos a través de algún puer-to (RS-232, USB, I2C ...). En la actualidad cientos de dispositivos emplean bootloaders,desde reproductores de MP3 hasta consolas de videojuegos.

El diseño de bootloaders tiene sentido ya que no se puede reprogramar una zona decódigo que está siendo ejecutada puesto que puede producir resultados impredecibles alsustituir instrucciones y direcciones de salto por otras nuevas.

Firmware de aplicaciónEl firmware de aplicación es el programa que ejecuta el sistema normalmente cuando

no está actualizándose, en este caso se trata del programa descrito en la sección anterior.Para acomodar un firmware de aplicación a la presencia de un bootloader se deben realizaralgunos cambios en el mismo, siendo el principal la relocalización del código para dejarlibre el rango de memoria reservado para el bootloader.

Modos de operaciónCuando 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


actualización (entrando así en modo de actualización, o DFU1), o debe ceder el control alfirmware de aplicación mediante un salto a su punto de entrada (modo de funcionamientonormal). Esta decisión se puede tomar de varias maneras en función del dispositivo delque se trate:

• Mediante la pulsación de una combinación de teclas.

Esto sólo es viable en dispositivos con teclas, y se ha de escoger una combina-ción o tiempos de pulsación que sea prácticamente imposible que se den durante elfuncionamiento normal (p. ej: pulsar el botón POWER y Menú durante 20 segun-dos). También se puede poner una tecla especial para ello.

• Por software mediante el envío de un comando.

Es un método más fiable puesto que no requiere intervención del usuario. Siel dispositivo está conectado de alguna manera mediante un enlace de datos se lepuede enviar un comando especial que lo ponga en modo de actualización.

Figura 6.19: Mapa de memoria de un dispositivo con bootloader

Cuando se está en modo de actualización se ejecuta un subprograma que recibe datospor el puerto y los escribe en direcciones de la memoria flash suministradas por el mismopuerto. También suelen permitir el envío de comandos para otras funciones, como lecturade la flash, o reinicio en modo de aplicación.

Bootloader diolanDurante la revisión bibliográfica se encontró un bootloader de código abierto para

PIC18, liberado bajo licencia GNU GPL por diolan.com, una empresa de sistemas empo-trados que lo usa en sus productos. El bootloader está programado usando el compilador

1Device Firmware Update

108 6.3. FIRMWARE

C18 y el ensamblador MPASM, razón por la que se emplean también estas herramientaspara su compilación. Sus características son:

• Tamaño reducido: 2 Kb

• Comunicación por USB. Periférico de clase HID (no requiere drivers)

• Encriptación de datos usando el algoritmo XTEA

• Paso de modo aplicación a DFU por software o mediante pulsador

Estas características lo hacen perfecto para el propósito de este proyecto.

Una de las características fundamentales aquí es la comunicación de datos encripta-dos. Esta característica hace que proporcione al usuario una imagen del firmware cifrada,que pasa por el bus USB cifrada, y se descifra dentro del microcontrolador, que a su veztiene establecidos los bits de protección de código en sus registros de configuración. Elalgoritmo XTEA está especialmente indicado para dispositivos empotrados por requerirmuy poca memoria RAM y tener un coste computacional escaso.

Un sistema es tan débil como su punto más débil, por lo que entregar una imagen delfirmware sin cifrar a un usuario para actualizar sus dispositivos podría dar lugar al desen-samblado del código y obtención de claves privadas y fabricación de réplicas rompiendoasí la cadena de seguridad.

Por otra parte el uso de la clase HID mantiene el dispositivo «driverless», y debe sureducido tamaño a que muchas partes de la gestión del bus USB han sido reescritas enensamblador, y otras innecesarias han sido eliminadas.

Implementación

En el momento de realizar la implementación el fabricante no proporciona ningúntipo de documentación, ni software adicional para controlarlo desde el PC. Se permitíaúnicamente la descarga del código fuente del bootloader para PIC18F4455.

Por lo tanto ha sido necesario realizar un estudio del código para determinar su fun-cionamiento y poder desarrollar las herramientas necesarias para su manejo por USB.

El bootloader presenta un interfaz basado en comandos:


Comando UtilidadBOOT_CMD_READ_CODE Lee un segmento de código de la Flash

BOOT_CMD_WRITE_CODE Escribe un segmento de código a la FlashBOOT_CMD_ERASE_CODE Borra un segmento de código de la FlashBOOT_CMD_GET_FW_VER Devuelve la versión del bootloader

BOOT_CMD_RESET Reinicia el microBOOT_CMD_READ_ID Lee el ID del micro

BOOT_CMD_WRITE_ID Escribe el ID del microBOOT_CMD_UNKNOWN Usado para control de errores

Cuadro 6.19: Comandos aceptados por el bootloader.

Para la comunicación con el host se utiliza el endpoint 1, con un tamaño de paquetede 64 bytes. El primer byte codifica el comando a ejecutar, el segundo byte es un identi-ficador de comando que debe suministrar el software y que sirve para enlazar comandosy respuestas. El resto de los bytes depende del comando específico. A continuación seexplican los cuatro comandos que se han utilizado:

BOOT_CMD_READ_CODEEste comando toma los siguientes argumentos:

Byte Contenido3 Parte baja de la dirección4 Parte alta de la dirección5 Reservado6 Tamaño a leer en bytes (múltiplo de 8)

Al enviar este comando, el bootloader lee el área de código solicitada, la cifra con elalgoritmo XTEA y la devuelve mediante una transferencia. Hay que tener en cuenta quelos argumentos que toma este comando dejan un total de 58 bytes libres en el paquete, loque limita el valor máximo del campo que indica el tamaño a leer.

BOOT_CMD_WRITE_CODEEste comando toma los siguientes argumentos:

Byte Contenido3 Parte baja de la dirección4 Parte alta de la dirección5 Reservado6 Tamaño a escribir en bytes (múltiplo de 8)

110 6.3. FIRMWARE

Cuando el bootloader recibe este comando, descifra el paquete de datos que lo acom-paña y lo escribe en la dirección solicitada. Tiene la misma limitación de tamaño que elanterior.

BOOT_CMD_ERASE_CODEEste comando toma los siguientes argumentos:

Byte Contenido3 Parte baja de la dirección (debe ser múltiplo de 64)4 Parte alta de la dirección5 Reservado6 Tamaño a borrar en bloques de 64 bytes

El comando borra la memoria flash. Puesto que la flash se borra por bloques de 64bytes el tamaño debe estar especificado en bloques de este tamaño, y la dirección debe serun múltiplo. Es necesario recordar que la tecnología Flash impone que antes de reescribirun área de memoria primero hay que borrarla.

BOOT_CMD_RESETEl comando no toma ningún argumento, su función es reiniciar el micro en modo de

funcionamiento normal.

Procedimiento de arranqueEl bootloader puede tomar la decisión sobre si arrancar en modo DFU o normal de

acuerdo al estado de un jumper externo, o también 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 dirección 0 de la memoriaEEPROM está presente el valor 5A. Si es así arrancará en modo DFU, el host lo detectarácomo dispositivo HID genérico y quedará listo para la recepción de comandos. En casocontrario salta a la dirección 0x800, que coincide con el punto de entrada del firmware deaplicación.

El modo de funcionamiento basado en la EEPROM mark tiene la ventaja de que sila actualización queda incompleta, debido a un fallo eléctrico, la desconexión accidentaldel dispositivo o cualquier otra eventualidad al conectarlo de nuevo volverá a arrancar enmodo DFU en lugar de ejecutar la imagen corrupta del firmware y permitirá intentarlo denuevo tantas veces como sea necesario.

Vendor ID y Product IDEl vendor ID y product ID por defecto son 0x1234 y 0x8765. Estos han sido cambia-

dos a 0x04D8 (Microchip), y 0x0000 para su posterior detección en el PC.


Punto de entradaSe necesita algún mecanismo para que el dispositivo pase de modo de funcionamiento

normal a modo DFU para actualizar su firmware. Para ello el bootloader tiene un punto deentrada en la dirección 0x0016. Si el firmware de aplicación realiza un salto a esta direc-ción se escribe el valor 5A en la EEPROM y después se ejecuta la instrucción RESET quereinicia el micro por software, en estas condiciones como se ha descrito antes arrancaráen modo DFU quedando listo para la actualización.

Algoritmo XTEAEl algoritmo XTEA deriva del TEA (Tiny Encryption Algorithm). Es un algoritmo de

cifrado por bloques notable por su simplicidad de descripción e implementación. No estásujeto a ninguna patente. XTEA opera sobre bloques de 64 bits, usa una clave simétricade 128 bits y una constante numérica «delta». Contiene una estrcutrua de Feistel2 quese ejecuta un número determinado de iteraciones, cuantas más iteraciones, mayor es elnivel de seguridad recomendándose 64 como compromiso entre seguridad y velocidad.Se clasifica dentro de los block-cipher.

En la implementación del algoritmo se usan 64 iteraciones, la constante «delta» tieneun valor predefinido y la clave XTEA se ha determinado de forma que su obtención porfuerza bruta no sea trivial. Estos parámetros se programan como constantes en el archivoxtea.asm que contiene el algoritmo de cifrado y descifrado escrito en ensamblador. Laclave XTEA se escribe como una cadena ASCII de 16 caracteres.

Modificaciones hechas al firmware de aplicaciónPara acomodar el bootloader junto con el resto del código y permitir la convivencia

entre ambos se han tenido que realizar ciertas modificaciones al firmware de aplicaciónque se describen a continuación:

• Relocalización del código

El código generado originalmente estaba diseñado para su ejecución directa,con lo que comenzaba en la dirección 0x0000 (vector de reset). Puesto que esasdirecciones están ocupadas ahora por el bootloader hay que relocalizar el códigopara que empiece en la dirección 0x0800 que es donde se salta para iniciar el fun-cionamiento normal.

• Relocalización de vectores de interrupción

Los vectores de interrupción de la arquitectura PIC18 se encuentran en 0x0008para interrupciones de alta prioridad y 0x0018 para interrupciones de baja prioridad.Estos vectores hay que relocalizarlos a 0x0808 y 0x0818 respectivamente.

2Método de cifrado por bloques con una estructura particular

112 6.4. SOFTWARE PARA EL PC

• Relocalización de constantes reprogramables

Las constantes que se quiere poder reprogramar externamente mediante el bootloa-der como el número de serie y la clave HASP tienen que estar situadas en posicionesde memoria múltiplo de 64 bytes para permitir el borrado y posterior reprogramado.

• Definición de un comando DFU

El dispositivo debe, mediante los interfaces USB definidos originalmente, po-der recibir algún comando que provoque el salto al punto de entrada del bootloaderpara su reinicio en modo de actualización de firmware.

Para solucionar los dos primeros puntos se escribe la siguiente directiva:

1 #build(reset=0x800,interrupt=0x808) // Solo alta prio.

En cuanto a la relocalización de constantes reprogramables, se utiliza la dirección0x7D00 para la cadena ASCII del número de serie y 0x7D80 para la clave HASP, teniendoespecial cuidado de que el borrado de 64 bytes a partir de cada una de estas direccionesno borre nada más que las constantes afectadas. Para ello se ha utilizado la directiva #orgdel compilador que coloca el código que va a continuación en la dirección especificada.

Para el reinicio en modo DFU se aprovecha el interfaz del dispositivo HASP, de ma-nera que si los 6 primeros bytes de la cadena de desafío corresponden con la secuenciaASCII «rstCmd» se salta al punto de entrada del bootloader, quedando la función «HAS-PTask()» como sigue:

1 void HASPTask(void)

2 usb_get_packet(2, data_buffer, 9);

3 for(i=0; i<6; i++)

4 if(rstMsg[i] != data_buffer[i])

5 goto hasp;

6 #asm

7 goto 0x0016 ; Bootloader entry point

8 #endasm

9 hasp:

10 // Sign the string

11 sign((ptrWord)data_buffer);

12 // Send back the signed string

13 usb_put_packet(2, data_buffer, 8, USB_DTS_TOGGLE);

14

6.4. SOFTWARE PARA EL PC

En esta sección se describe el desarrollo del software que corre en el PC.


6.4.1. Librería HASPDurante el desarrollo del firmware ya se aclaró que la funcionalidad de sensorización

no necesita de ninguna librería especial, puesto que el uso del item «Application» deldescriptor HID, y su identificación como gamepad lo hacen compatible con cualquierlibrería de entrada estándar. Sin embargo, la función HASP, al ser un interfaz de usodefinido por el fabricante requiere de una comunicación especializada.

Se pretende implementar una librería que se haga cargo de los detalles del hardware yque proporcione al software que la incorpore un interfaz de alto nivel para la utilizacióndel sistema HASP. Todo el código fuente ha sido comentado debidamente para generar sudocumentación con la herramienta «doxygen» y se proporciona el código de una aplica-ción «pruebalib» en el CD adjunto que muestra su funcionamiento.

La función del sistema HASP es, en última instancia, proporcionar al software unasola información: ¿la copia que se está ejecutando es legal?, y con esta idea en mente seprocede al desarrollo de un interfaz que permita al software conocer esta información demanera clara y precisa.

En primer lugar, hay que tener en cuenta varios factores para el diseño:

• Se pueden producir diversos eventos en relación con el hardware: desconexión,error de comunicaciones ...

• Los eventos suceden de forma asíncrona con el funcionamiento del software

• El protocolo de desafío/respuesta debe obedecer a cierta temporización

• Deben poder utilizarse otros protocolos de validación de software en caso de que seimplementen en un futuro

• La arquitectura debe ser lo suficientemente general como para permitir la comuni-cación HASP mediante otros tipos de bus distintos de USB para facilitar el diseñode futuros periféricos.

• No debe suponer una carga importante para la CPU

• No debe consumir grandes recursos

Para abordar este diseño se opta por una arquitectura basada en capas.La arquitectura basada en capas se enfoca en la distribución de roles y responsabilida-

des de forma jerárquica proveyendo una forma muy efectiva de separación de responsa-bilidades. El rol indica el modo y tipo de interacción con otras capas, y la responsabilidadindica la funcionalidad que está siendo desarrollada [MHH+08].

Esta arquitectura resulta muy beneficiosa, puesto que proporciona:

• Abstracción. La arquitectura basada en capas abstrae la vista del modelo como untodo mientras que provee suficiente detalle para entender las relaciones entre capas.


Figura 6.20: Pila de capas de la librería libhw

• Encapsulamiento. El diseño no hace asunciones sobre tipos de datos, métodos,propiedades o implementación.

• Funcionalidad claramente definida. El diseño claramente define la separaciónentre la funcionalidad de cada capa. Los datos fluyen hacia y desde las capas encualquier sentido.

• Rendimiento. Distribuir las capas entre múltiples sistemas puede incrementar laescalabilidad, tolerancia a fallos y el rendimiento.

• Alta cohesión. Cada capa tiene una funcionalidad directamente relacionada con lasu tarea.

• Reutilizable. Las capas inferiores no tienen ninguna dependencia con las capassuperiores, permitiendo ser reutilizables en otros escenarios.

• Desacople. La comunicación entre dos capas está basada en la abstracción lo queprovee un desacople entre ellas.

El nombre de la librería es «libhw», ya que ofrece un interfaz con el hardware diseña-do. La figura 6.20 muestra la pila de capas desarrollada, y la figura 6.4.1 el diagrama declases. El funcionamiento de cada parte explica a continuación:

DriverEsta es la capa encargada de realizar la comunicación con el dispositivo. La tabla 6.20

muestra el interfaz presentado por la capa «Driver».


enumerate() Detecta si el dispositivo está presentesend() Envía un paquete de datos al dispositivo

receive() Recibe un paquete de datos desde el dispositivoreset() Reinicia la comunicación

getState() Obtiene el estado interno

Cuadro 6.20: Interfaz de la capa «Driver»

Su funcionamiento está gobernado por la máquina de estados de la figura 6.22 quepermite el control de las operaciones sobre el hardware en función de la presencia delmismo y el estado de las comunicaciones.

El estado UNENUM indica que el dispositivo no se ha detectado, bien porque aún nose ha llevado a cabo la detección mediante la llamada a «enumerate()», o bien porque estadetección 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 produceun error de comunicaciones pasando al estado DRVERROR, o se desconecta el dispositivopasándose de nuevo al estado UNENUM.

La clase «Driver» es una superclase abstracta y define el interfaz que debe propor-cionar cualquier driver especializado para manejar un tipo de dispositivo concreto. Lasclases derivadas tienen la responsabilidad de manejar las transiciones entre estados de


Figura 6.21: Superclase Driver

forma correcta y de implementar la comunicación real con el hardware.

ProtocolLa capa «Protocol» implementa un protocolo de validación de software basado en

intercambio de mensajes.El interfaz ofrecido para su comunicación con las capas adyacentes es el siguiente:El protocolo define un buffer de salida para el envío de mensajes y otro de entrada

para la recepción. La entidad que utilice el protocolo deberá llamar a «preStep()» paraque la implementación prepare la cadena a enviar y la coloque en el buffer de salida,después enviará el mensaje al dispositivo HASP, y recibirá la respuesta produciéndose así

init() Inicializa el protocologetOutputBuffer() Obtiene un puntero al buffer de salidagetInputBuffer() Obtiene un puntero al buffer de entrada

preStep() Ejecuta acciones previas al intercambio de datospostStep() Ejecuta acciones posteriores al intercambio de datos

reset() Reinicia el protocologetState() Obtiene el estado interno

Cuadro 6.21: Interfaz de la capa «Protocol»


Figura 6.22: Máquina de estados de la capa «Driver»

Figura 6.23: Superclase «Protocol»


Figura 6.24: Máquina de estados de «Protocol»

el intercambio de datos. Finalmente colocará el mensaje recibido en el buffer de entraday llamará a postStep() para que se compruebe que es correcto.

Su funcionamiento, al igual que ocurre con la capa anterior obedece a la máquina deestados mostrada en la figura 6.26. El protocolo se inicia en el estado STOP, cuando sellama a «init()» pasa por el estado INITIALIZING, y si la operación tiene éxito llegaráal estado OK. Cuando se ejecuta la operación «postStep()», si las comprobaciones delprotocolo fallan se pasará al estado PROT_ERROR del que se podrá salir llamando a«reset()», volvíendose de nuevo al estado OK.

LSYMHASPLSYMHASP es la capa superior, que implementa la API para el uso del sistema. Es la

parte más compleja, puesto que tiene la mayor responsabilidad. Utiliza la capa Driver paracomunicarse con el hardware, y gestiona el paso de información entre éste y el protocoloimplementando un servicio de notificación de eventos mediante la API.

El interfaz que ofrece es el siguiente:El método de notificación de eventos es mediante una función de callback. Esta fun-

ción es llamada por la librería recibiendo como argumento un mensaje codificado comoentero. Los mensajes cubren las situaciones del sistema HASP que son de interés para elsoftware que lo implementa:

La implementación más típica consiste en asumir que el software debe estar desblo-


Figura 6.25: Clase «LSYMHASP»

start() Inicializa el sistema HASPstop() Detiene el sistema HASP

validHWPresent() Devuelve si hay un hardware HASP válido conectadogetSerialString() Obtiene la cadena del número de serie del dispositivo conectado

getPID() Obtiene el PID del hilo

Cuadro 6.22: Interfaz de la capa «LSYMHASP»

HWERROR Error de hardwarePERROR Error de protocolo

DISCONNECTED No hay dispositivo conectadoONLINE Dispositivo conectado y funcionando

INIT Inicializando sistemaINIT_ERROR Error de inicialización

STOP Sistema detenido

Cuadro 6.23: Mensajes de notificación


Figura 6.26: Máquina de estados de «LSYMHASP»

queado una vez se ha recibido el mensaje «ONLINE», y que debe estar bloqueado alrecibir cualquier otro mensaje.

El funcionamiento del sistema HASP discurre de forma paralela al del software quelo 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 implementación del hilo contiene el códigoque realiza la comunicación con las capas subyacentes y provoca las notificaciones. Estoimplica que la función de callback es llamada por el propio hilo, con lo que el programadordebe tener la precaución de utilizar los mecanismos de sincronización pertinentes si elcódigo contenido en el callback accede a estructuras de datos compartidas con el propiosoftware. El hilo ejecuta un ciclo de validación (preStep - intercambio de datos - postStep)cada aproximadamente 1 segundo, con lo que pasa la mayor parte del tiempo suspendidosuponiendo una carga muy pequeña para la CPU. Por ello, también hay que tener encuenta que el tiempo de ejecución del código contenido en la función de callback no tengauna duración excesiva para no alargar el tiempo del ciclo ni correr el riesgo de bloquearseindefinidamente ya que esto último detendría el proceso de validación sin notificaciónalguna. El hilo además comprueba en todo momento la presencia del dispositivo, si nose detecta en cada ciclo se reenumera en su busca, notificando en todo momento de loseventos producidos y actualizando el estado de la máquina de estados interna.

La clase LSYMHASP puede lanzar excepciones como resultado de las llamadas a losmétodos «start()» o «stop()». La clase «libhwException» que implementa la excepción


EX_THREADSTARTED El hilo ya ha sido iniciadoEX_STOPPED El hilo ya ha sido detenido

EX_CANTSTOP No se puede detener el hiloEX_CANTSTART No se puede iniciar el hilo

Cuadro 6.24: Códigos de excepción

contiene el código del error y una cadena de caracteres opcional con el significado.Los posbiles errores son:El diagrama de secuencia de la figura 6.27 muestra un ciclo de validación.

LSYMHASPD2La clase LSYMHASPD2 es una implementación de driver para las placas modelo 2

(recordemos que el código de producto era 2 puesto que el primer modelo fue una imple-mentación de prueba). Deriva de la clase abstracta «Driver» e implementa los métodos deesta.

La comunicación a bajo nivel con el dispositivo se ha basado en los ejemplos de JanAxelson [Axe05] para detectar y comunicarse con dispositivos HID en sistemas Windowsempleando el «Windows DDK». La implementación permite obtener el Vendor ID (VID)y el Product ID (PID) de cada uno de los dispositivos HID conectados actualmente alsistema y abrir un manejador al que se desee para poder leer y escribir como si se tratase deun fichero. Las lecturas y escrituras son bloqueantes pero se programa un tiempo de esperamáximo de 6 segundos de manera que un fallo en la comunicación o en el dispositivo noinhabiliten el sistema HASP.

LSYMCSVPLSYMCSVP es la implementación del protocolo de validación por desafío-respuesta

propuesto al principio de esta sección. Su nombre son las siglas de «Challenging Softwa-re Validation Protocol». Su código es el de la parte host de la implementación de prueba«swval» con los cámbios mínimos para encapsularlo en una especialización de «Proto-col».

6.4.2. Herramientas complementariasPara la gestión del código del dispositivo mediante el bootloader se necesita desarro-

llar herramientas adicionales, que se explican a continuación.

Herramienta fwcryptLa herramienta fwcrypt lee una imagen del firmware en formato HEX (INH32) y

genera una imagen encriptada en un fichero de salida. Este fichero es apto para cargarseen el micro mediante el bootloader.


Figura 6.27: Diagrama de secuencia de un ciclo del protocolo HASP.


El formato HEX de Intel es un fichero de texto que contiene la imagen de un programamediante la descripción de las direcciones de memoria y los datos que las ocupan. Existenformatos de 6, 16, y 32 bits pero el que genera el compilador es este último. Cada líneade un fichero .HEX se compone de seis partes:

• Código de inicio: Es el caracter ASCII dos puntos (:)

• Número de bytes: Dos dígitos hexadecimales que codifican el número de bytespresentes en el campo de datos

• Dirección: Cuatro dígitos hexadecimales que especifican la dirección de comienzode la secuencia de datos contenida en el campo de datos. Está limitada a 64 Kb yrepresentada en formato big endian

• Tipo de registro: Dos dígitos hexadecimales codificando el tipo de datos en elcampo de datos. Los dos tipos de registros que se han usado son:

– 00 Registro de datos. El registro de datos contiene datos válidos.

– 01 Registro de final de fichero. Debe ser el último.

• Campo de datos: Secuencia de n bytes de datos (2n dígitos hexadecimales)

• Checksum: Suma de comprobación. Se obtiene sumando los bytes de todos loscampos, excepto el código de inicio y el checksum y obteniendo el complementoa 2 del byte menos significativo del resultado. Si los datos son correctos, al sumarlos bytes de todos los campos excepto el código de inicio dará un valor cuyo bytemenos significativo es 0

El programa recibe en la línea de comandos el nombre del fichero a cifrar, lo abre ydecodifica el fichero .HEX línea a línea ignorando aquellos que estén presentes en unadirección superior a 0x300000 (registros de configuración) y comprobando el checksum.Los datos se van colocando en un array que simboliza la memoria del microcontrolador.Después se recorre este array cifrando en bloques de 64 bits con el algoritmo XTEA yla clave XTEA pasada también en la línea de comandos. Finalmente se vuelca este arraydirectamente a un fichero de salida.

La implementación de los algoritmos de cifrado y descifrado se muestran a continua-ción:

Cifrado:

1 sum, i : Entero sin signo

2 x1: Entero de 32 bits (primera mitad del bloque)

3 x2: Entero de 32 bits (segunda mitad del bloque)

4 XTEA_ITER: N. de iteraciones (64)

5 DELTA: Constante numérica (0x9E3779B9)

6


7 sum=0;

8 for( i=0; i<XTEA_ITER; i++ )

9

10 x1 += (((x2<<4) ^ (x2>>5)) + x2) ^

11 (sum + key[sum&0x03]);

12 sum+= DELTA;

13 x2 += (((x1<<4) ^ (x1>>5)) + x1) ^

14 (sum + $KEY[(sum>>11)&0x03]);

15

Descifrado:

1 sum, i : Entero sin signo

2 x1: Entero de 32 bits (primera mitad del bloque)

3 x2: Entero de 32 bits (segunda mitad del bloque)

4 XTEA_ITER: N. de iteraciones (64)

5 DELTA: Constante numérica (0x9E3779B9)

6

7 sum = DELTA* XTEA_ITER;

8 for( i=0; i<XTEA_ITER; i++ )

9

10 x2 -= (((x1<<4) ^ (x1>>5)) + x1) ^

11 (sum + key[(sum>>11)&0x03]);

12 sum-= DELTA;

13 x1 -= (((x2<<4) ^ (x2>>5)) + x2) ^

14 (sum + key[sum&0x03]);

15

Herramienta lsymflashLa herramienta lsymflash busca el dispositivo en modo DFU (buscando dispositi-

vos HID con Vendor ID 0x04D8 y Product ID 0x0000), toma un archivo de imagen defirmware cifrada a través de la línea de comandos y la envía mediante sucesivos coman-dos BOOT_CMD_WRITE_CODE al bootloader, quien la descifra y escribe en memoriaFlash. Es necesario recordar que la memoria Flash debe ser borrada antes de ser progra-mada por lo que antes de enviar los datos se calcula la cantidad de bloques de 64 bytesa borrar mediante la ecuación 6.3 donde bb es el número de bloques a borrar y tp es eltamaño del programa en bytes (tamaño del fichero de entrada). Después se envía un co-mando BOOT_CMD_ERASE_CODE por cada 255 bloques (tamaño máximo borrableen una sola transacción debido a que éste se codifica con un solo byte). Una vez comien-za el envío de los datos del programa cifrados, las direcciones de destino se generan apartir del punto de entrada del firmware de aplicación (0x800). Para obtener la máxima


velocidad y tal como se discutió anteriormente, se envían paquetes de 58 bytes de datos,que es el máximo permitido. Posteriormente reprograma el número de serie que tambiénse le suministra por línea de comandos mediante el mismo procedimiento de borrado-programación reemplazando así la cadena «DAQ-0000» original, y reinicia el microcon-trolador en modo de funcionamiento normal enviando el comando BOOT_CMD_RESET.Para reprogramar variables se necesita también la clave de cifrado, puesto que el bootloa-der espera el segmento de programa que se desea reescribir codificado con XTEA. Paraello, la clave XTEA está definida como constante en el programa lsymflash. Finalmente,hay que aclarar que este programa está indicado únicamente para uso interno durante elproceso de programación y que no es apto para la actualización del firmware por parte deun usuario.

bb = d tp64e (6.3)

Herramienta resettoolLa herramienta resttool envía el la cadena ASCII «rstCmd» al dispositivo a través del

endpoint 2 del HASP cuando está funcionando en modo normal para reiniciarlo en modoDFU. Esto resulta útil para iniciar el proceso de actualización o para corregir un posibleerror al escribir el número de serie al llamar a lsymflash.

CAPÍTULO 7

PRUEBAS

Con el fin de verificar el correcto funcionamiento del sistema desarrolado, se realizanuna serie de pruebas empleando la placa prototipo destinadas a probar la funcionalidadde cada una de las partes de que se compone. Estas pruebas se pueden clasificar en cuatrosubapartados:

• Instalación del dispositivo

• Prueba de sensores

• Prueba de HASP

• Prueba de actualización de firmware.

Se han realizado pruebas en las siguientes máquinas:

• PC Portátil Ahtec Sense con procesador Intel Core 2 Duo a 2.4 GHz y 2 Gb dememoria RAM y Windows XP x64.

• PC Sobremesa clónico con procesador Intel Pentium 4 a 2 GHz, 1 Gb de memoriaRAM y Windows XP Professional.

• PC Portátil LG S1 Pro Express Dual con procesador Intel Core 2 Duo T7600 a 2GHz, 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 memoriaRAM y Mac OS X Leopard.

El dispositivo se detecta correctamente, se puede ver el estado de los sensorescon la herramienta de calibración de joystick de un juego. Pero el soporte HASP noestá implementado para Mac OS X.

• PC Sobremesa Packard Bell Dot con procesador Intel Atom a 1.6 GHz, 1 Gb deRAM y Ubuntu Linux.

128 7.1. INSTALACIÓN DEL DISPOSITIVO

El comando «lsusb» muestra el dispositivo, con la herramienta jscal se puedever 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 configurado. Se pueden controlar los menús conlos sensores analógicos 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 restode sistemas se han ejecutado la prueba de detección y la de lectura de sensores con lasherramientas presentes para el sistema en cuestión.

7.1. INSTALACIÓN DEL DISPOSITIVO

El objetivo de esta prueba es comprobar que distintas máquinas con distintos sistemasoperativos detectan y configuran el dispositivo correctamente. Esto implica que el pro-ceso de enumeración se realice con éxito y que la comunicación entre dispositivo y hostfuncione adecuadamente.

Al tratarse de un periférico que pertenece a la clase HID, se espera que en la mayoríade sistemas operativos se detecte y configure automáticamente sin necesidad de instalarningún software.

7.2. PRUEBA DE SENSORES

A la placa prototipo se le han conectado diez pulsadores y diez potenciómetros parapoder comprobar su funcionamiento. Con la ayuda del panel de control de Windows, seutiliza la herramienta de calibración de joysticks para ver el estado de cada sensor.

7.3. PRUEBA HASP

Utilizando la librería «libhw» se implementa una aplicación de prueba «botonera» quepone en funcionamiento el sistema e imprime por consola el nombre de cada mensaje querecibe a través de la función de callback.

7.4. ACTUALIZACIÓN DE FIRMWARE

Con la herramienta «fwcrypt» se cifra el archivo .HEX, resultado de la compilacióndel firmware y con la herramienta «lsymflash» se carga en el dispositivo. Tras la actuali-zación correcta se verifica que funciona correctamente.

Se prueba la herramienta «resettool» para reinciar el dispositivo en modo DFU.

CAPÍTULO 7. PRUEBAS 129

Figura 7.1: Prueba de sensores

Figura 7.2: Prueba de sistema HASP

130 7.4. ACTUALIZACIÓN DE FIRMWARE

Figura 7.3: Prueba de actualización de fimware con lsymflash

CAPÍTULO 8

PRESUPUESTO

Para estimar el coste total del proyecto se han tenido en cuenta los gastos derivadostanto del software y hardware utilizado en su desarrollo, como de los materiales para laconstrucción 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 diseño del esquemático y la placa de circuito impreso se ha utilizado el softwa-re Eagle, que en su versión de estudiante es gratuita. Aunque impone ciertas limitacionesque se nombraron en el capítulo 3, estas no son relevantes para llevar a cabo el desarrollocon éxito.

Para la programación del microcontrolador se ha utilizado CCS PCWH que requiereuna licencia comercial, MPLAB IDE con MPASM que se distribuye de manera gratuita,y el compilador C18 que dispone también de una versión gratis para estudiantes.

Para la programación de la librería y herramientas en el PC se ha utilizado Visual C++Express, se puede descargar sin ningún coste del sitio web de Microsoft, a pesar de tenerciertas limitaciones, estas no obstaculizan en absoluto el desarrollo del proyecto.

El Windows Driver Development Kit es el kit de desarrollo de drivers para los sistemasoperativos Windows de Microsoft y al igual que los programas anteriores es gratuito, peroen este caso sin limitaciones.

Para el desarrollo de los descriptores HID se ha empleado el programa HID DescriptorTool de USB-IF. Es una herramienta gratuita.

Finalmente el sistema operativo utilizado es Windows XP x64 cuyo uso también re-quiere 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 PrecioMicrochip MPLAB IDE 0 eMicrochip MPASM 0 eMicrochip C18 0 eCCS PIC C PCWH 348.8 eUSB-IF HID Descriptor Tool 0 eEagle 0 eMicrosoft Windows DDK 0 eMicrosoft Visual C++ Express 0 eMicrosoft Windows XP x64 Edition 77.12 eTotal 425.92 e

Cuadro 8.1: Costes de software

8.2. COSTE DE LOS RECURSOS HARDWARE

En primer lugar se contabilizarán los recursos hardware necesarios para el desarro-llo del software y los planos y esquemáticos de la PCB, y en segundo lugar el materialempleado para la construcción del prototipo.

Concepto PrecioPC Portatil 2.4 GHz 2Gb RAM 760 eProgramador/Depurador MPLAB ICD 2 325 eTotal 1085 e

Cuadro 8.2: Costes de hardware I

CAPÍTULO 8. PRESUPUESTO 133

Concepto Cantidad Precio unitario Precio totalSoldador de 40 W 1 26 e 26 eRollo de estaño de 0.5 mm 1 8.95 e 8.95 ePlaca fotosensible positiva de 50 x 50 mm 1 16.90 e 16.90 eTaladro multifunción tipo Dremel 1 69.95 e 69.95 eMultímetro digital 1 15.52 e 15.52 eSet de productos químicos para insolado 1 15 e 15 eInsoladora casera de LEDs UV 1 35 e 35 ePack de 10 hojas de transparentes A4 1 9.67 e 9.67 eArray de resistencias 10 KΩ (9 elementos) 2 0.19 e 0.38 eResistencia 1KΩ (pack de 10 unidades) 1 0.99 e 0.99 eCristal de cuarzo de 4 MHz 1 0.96 e 0.96 eMicrocontrolador PIC18F2550 SPDIP 1 8.71 e 8.71 eTira de pines (40 pines) 1 0.48 e 0.48 eZócalo DIP de 28 pines 1 0.17 e 0.17 eConector USB hembra tipo B 1 0.40 e 0.40 eCondensador cerámico 100 nF 1 0.13 e 0.13 eCondensador cerámico 200 nF 1 0.13 e 0.13 eCondensador cerámico 27 pF 2 0.08 e 0.16 eConector de apriete (bloque de 10) 2 0.63 e 1.26 eConector de apriete (bloque de 3) 2 0.30 e 0.60 eLED rojo de 1.5 mm 1 0.08 e 0.08 eTotal 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 asignación de las mismas, loscostes asociados a los recursos humanos se muestran en la tabla 8.4. En esta estimaciónno se han tenido en cuenta los fines de semana, se ha asumido una jornada laboral de 8horas, y no se ha incluido la redacción de la memoria.

Concepto Horas Salario/hora CosteIngeniero 912 11.26 e 10269.12 eTécnico 72 8 e 576 eTotal 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 CosteRecursos software 425.92 eRecursos hardware I 1085 eRecursos hardware II 211.44 eRecursos humanos 10845.12 eTotal 12567.48 e

Cuadro 8.5: Costes totales

Hay que recordar que este es el coste total del desarrollo y fabricación del prototi-po, para su producción en serie serían necesarios unos gastos iniciales derivados de lafabricación de los PCBs y el coste unitario sería mucho menor.

CAPÍTULO 9

CONCLUSIONES Y TRABAJO FUTURO

9.1. CONCLUSIONES

A la finalización del desarrollo, y tras comprobar los resultados se pueden concluirque se han cumplido los objetivos propuestos al inicio.

El resultado obtenido ha sido un periférico microcontrolado que muestrea pulsadoresy potenciómetros y envía esta información mediante USB. Es apto para su montaje dentrode paneles y mandos de control de maquinaria real para su uso con simuladores y otrosoftware interactivo. El periférico no requiere ninguna fuente de alimentación externa,ni la instalación de drivers para un sistema operativo específico, lo que lo hace multi-plataforma. Además de la lectura de sensores, el periférico implementa un algoritmo dedesafío-respuesta que permite detectar la presencia continuada del dispositivo con el finde servir como llave HASP para evitar la distribución y uso ilegítimo de copias de un soft-ware junto con el que se distribuye. Se ha desarrollado una librería que oculta los detallesdel hardware y mantiene informado al software protegido del estado de la protección, no-tificándole inmediatamente de eventos que afectan a la misma como la desconexión deldispositivo, o un error en el diálogo que mantiene con el host.

El dispositivo es reprogramable «in situ» implementando los mecanismos necesariospara actualizar el código que ejecuta el microcontrolador en el lugar donde habitualmentese utiliza sin tener que ser desmontado por un técnico y sin romper la cadena de seguridad.Se han desarrollado también herramientas que permiten el cifrado del programa firmwarey la mencionada reprogramación.

Este desarrollo ha sido posible gracias a la elección de los componentes adecuadosque han permitido la fabricación manual de una placa de las dimensiones requeridas, co-mo el microcontrolador PIC18F2550 que incorpora en su encapsulado prácticamente latotalidad del hardware necesario para cumplir los objetivos del proyecto (módulo USB,conversor A/D, resistencias de pull-up internas), minimizando así la circuitería externanecesaria, lo que impacta directamente en el tamaño y el coste. La elección del bus USBcomo medio de interconexión ha resultado muy ventajosa puesto que suministra la ali-mentación necesaria y ofrece una comunicación robusta, rápida y flexible entre host y

136 9.2. TRABAJO FUTURO

dispositivos.Se puede concluir también que si bien es cierto que USB añade un factor importante

de complejidad respecto a predecesores como el RS-232, también lo és como se ha po-dido comprobar, que los fabricantes centran sus esfuerzos en proporcionar herramientasy hardware que aceleran y facilitan en gran medida el desarrollo de periféricos basadosen este estándar. Esto repercute en un uso muy extendido del mismo, donde los usuariosganan en sencillez gracias a características como Plug & Play y la existencia de distin-tas clases de dispositivos, y los desarrolladores ganan en tiempo invertido, permitiéndoseobviar en gran medida estas complejidades y centrarse en su diseño.

Por otro lado el coste de fabricación por unidad justifica el desarrollo del proyectoen lugar de implementar una solución basada en una tarjeta de sensorización y una llaveHASP.

9.2. TRABAJO FUTURO

Se han cumplido los objetivos del proyecto, pero se observa que aún hay ciertos as-pectos susceptibles de mejora, que se proponen como trabajo futuro:

• Estudiar y mejorar las vulnerabilidades del algoritmo de validación por desafío-respuesta desarrollado y valorar su reemplazo por otro existente, o adpotar XTEAal igual que el bootloader.

• Mejorar la librería realizando la detección del dispositivo guiada por eventos, enlugar de enumerando periódicamente cuando no está conectado.

• Mejorar el diseño de la librería mediante el uso de plantillas.

• Diseñar un armazón para la distribución de actualizaciones de firmware. Se proponeel uso de un fichero ZIP que proporciona un contenedor seguro con comprobaciónde código CRC, con la extensión cambiada y que contenga la imagen binaria cifraday un archivo XML con información sobre las mejoras incluidas, el código de versióny los PID de dispositivos compatibles.

• Diseñar una herramienta de actualización de firmware para el usuario. Se proponela implementación como un plug-in para el navegador al estilo «Windows Update»,de forma que visitando una página web se detecten los dispositivos compatibles co-nectados, la versión de firmware de cada uno y mediante una consulta a un servidordeterminar si existe una versión nueva, permitiendo su descarga y reprogramaciónautomáticas.

• Diseñar una extensión como una placa hija que se conecte en el zócalo del mi-crocontrolador reemplazando a este, y que contenga un sistema compuesto por untransceptor inalámbrico, un controlador de carga de batería, un microcontrolador y

CAPÍTULO 9. CONCLUSIONES Y TRABAJO FUTURO 137

un conector para una batería con el objetivo de permitir la comunicación tanto sincables como por USB, ofreciendo la posibilidad también de cargar la batería cuandoesté conectado.

138 9.2. TRABAJO FUTURO

APÉNDICE A

PLANOS Y FOTOLITOS

APÉNDICE A. PLANOS Y FOTOLITOS 141

A.1. ESQUEMÁTICO DEL CIRCUITO

142 A.2. LISTADO DE COMPONENTES

A.2. LISTADO DE COMPONENTES

Concepto CantidadArray de resistencias 10 KΩ (9 elementos) 2Resistencia 1KΩ (pack de 10 unidades) 1Cristal de cuarzo de 4 MHz 1Microcontrolador PIC18F2550 SPDIP 1Tira de pines (40 pines) 1Zócalo DIP de 28 pines 1Conector USB hembra tipo B 1Condensador cerámico 100 nF 1Condensador cerámico 200 nF 1Condensador cerámico 27 pF 2Conector de apriete (bloque de 10) 2Conector de apriete (bloque de 3) 2LED rojo de 1.5 mm 1

Cuadro A.1: Listado de componentes


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


Figura A.4: Fotolito: Capa de componentes

146 A.4. FOTOLITOS DEL PCB

APÉNDICE B

ESPECIFICACIONES

148 B.1. ESPECIFICACIONES DEL DISPOSITIVO

B.1. ESPECIFICACIONES DEL DISPOSITIVO

Dimensiones (mm) 58 x 38 x 18Tensión de alimentación (V) 5.0

Intensidad máxima (mA) 100Frecuencia del microprocesador (MHz) 48.0

N. de pines 26Conexión USB hembra tipo B

Norma USB 2.0Clase de dispositivo HID

Versión de clase 1.11Temperatura de funcionamiento (oC) -40 - 85

Resolución de muestreo (bits) 10Periodo de muestreo (ms) 10N. de entradas analógicas 10

N. de entradas digitales 10Sistema HASP Desafío-Respuesta

Cuadro B.1: Especificaciones del dispositivo

B.2. PINOUT

Pin FunciónD 0-9 Entradas digitales

AD 0-9 Entradas digitales/analógicasVDD 5 V (100 mA)GND TierraUSB Conexión USB

Cuadro B.2: Especificaciones del dispositivo

APÉNDICE B. ESPECIFICACIONES 149

B.3. IMÁGENES

Figura B.1: Fotografía del dispositivo

150 B.3. IMÁGENES

APÉNDICE C

LISTADOS DE CÓDIGO FUENTE

152 C.1. FIRMWARE DEL MICROCONTROLADOR

C.1. FIRMWARE DEL MICROCONTROLADOR

C.1.1. lsred_main.c1 # i n c l u d e <18F2550 . h>234 # b u i l d ( r e s e t =0x800 , 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 s5 # d e v i c e ADC=106 # org 0x89E , 0x138F DEFAULT78 / / / / FULL SPEED9 # f u s e s HSPLL ,NOWDT, PROTECT, NOLVP,NODEBUG, USBDIV , PLL1 , CPUDIV1 ,VREGEN,NOMCLR, CPB

10 # use d e l a y ( c l o c k =48000000)11 # d e f i n e USB_USE_FULL_SPEED TRUE / / LINE ADDED! !1213 / / SLOW SPEED14 / / # f u s e s HSPLL ,NOWDT, PROTECT, NOLVP,NODEBUG, USBDIV , PLL1 , CPUDIV3 ,VREGEN, NOMCLR, CPB15 / / # use d e l a y ( c l o c k =24000000)16 / / # d e f i n e USB_USE_FULL_SPEED FALSE1718 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /19 / /20 / / CCS L i b r a r y dynamic d e f i n e s . For 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 y21 / / f o r your 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 need t o be made . See t h e comments22 / / a t usb . h f o r more i n f o r m a t i o n23 / /24 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /25 #DEFINE USB_HID_DEVICE TRUE / / T e l l s t h e CCS PIC USB f i r m w a r e26 / / t o i n c l u d e HID h a n d l i n g code .2728 / / 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 )29 # d e f i n e USB_EP1_TX_ENABLE USB_ENABLE_INTERRUPT30 # 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 t3132 # d e f i n e USB_EP2_TX_ENABLE USB_ENABLE_INTERRUPT / / t u r n on EP2 f o r OUT bu lk / i n t e r r u p t t r a n s f e r s33 # d e f i n e USB_EP2_TX_SIZE 83435 # d e f i n e USB_EP2_RX_ENABLE USB_ENABLE_INTERRUPT / / t u r n on EP2 f o r IN bu lk / i n t e r r u p t t r a n s f e r s36 # d e f i n e USB_EP2_RX_SIZE 9373839 / / D e f i ne t h e p i n mapping4041 / / D i g i t a l42 # d e f i n e D0 i n p u t ( PIN_E3 )43 # d e f i n e D1 i n p u t ( PIN_A4 )44 # d e f i n e D2 i n p u t ( PIN_C0 )45 # d e f i n e D3 i n p u t ( PIN_C1 )46 # d e f i n e D4 i n p u t ( PIN_C2 )47 # d e f i n e D5 i n p u t ( PIN_C6 )48 # d e f i n e D6 i n p u t ( PIN_C7 )49 # d e f i n e D7 i n p u t ( PIN_B5 )50 # d e f i n e D8 i n p u t ( PIN_B6 )51 # d e f i n e D9 i n p u t ( PIN_B7 )5253 / / Analog54 # d e f i n e AN0 055 # d e f i n e AN1 156 # d e f i n e AN2 257 # d e f i n e AN3 358 # d e f i n e AN4 459 # d e f i n e AN5 860 # d e f i n e AN6 961 # d e f i n e AN7 1062 # d e f i n e AN8 1163 # d e f i n e AN9 126465 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /66 / /67 / / 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 e68 / / f i l e s f o r more i n f o r m a t i o n69 / /70 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /7172 # i n c l u d e < p i c 1 8 _ u s b . h> / / Mic roch ip PIC18F25550 hardware l a y e r f o r usb . c73 # i n c l u d e < l s r e d _ d e s c . h> / / USB C o n f i g u r a t i o n and Device d e s c r i p t o r s f o r t h i s UBS d e v i c e74 # i n c l u d e <usb . c> / / h a n d l e s usb 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 s75 / / # i n c l u d e <STRING . H>76 # i n c l u d e "LSYMCSVP. h " / / 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 l7778 # d e f i n e UMBRAL_AD 700 / / Leve 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

APÉNDICE C. LISTADOS DE CÓDIGO FUENTE 153

79 # d e f i n e DELAY_AD_US 400 / / A/D Conve r so r d e l a y r e q u i r e d t ime8081 / / Data b u f f e r s82 s t a t i c i n t 8 o u t _ d a t a [ 2 3 ] ; / / B u f f e r f o r c o n t r o l l e r d a t a83 s t a t i c i n t 8 d a t a _ b u f f e r [ 9 ] ; / / B u f f e r f o r HASP8485 s t a t i c i n t 1 6 sample ; / / B u f f e r f o r c u r r e n t sample8687 i n t i ;88 c o n s t c h a r r s tMsg [ ] = " rstCmd " ;8990 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 ;9192 /∗93 ∗ Checks t h e " umbra 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 sample and c h a n n e l94 ∗ 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 s95 ∗ /96 vo id 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 )97 98 u n s i g n e d c h a r c o n d i c i o n ;99

100 c o n d i c i o n = ( m u e s t r a <= UMBRAL_AD) ;101102 s w i t c h ( c a n a l )103 104 c a s e AN0:105 o u t _ d a t a [ 2 1 ] | = c o n d i c i o n << 2 ;106 b r e a k ;107 c a s e AN1:108 o u t _ d a t a [ 2 1 ] | = c o n d i c i o n << 3 ;109 b r e a k ;110 c a s e AN2:111 o u t _ d a t a [ 2 1 ] | = c o n d i c i o n << 4 ;112 b r e a k ;113 c a s e AN3:114 o u t _ d a t a [ 2 1 ] | = c o n d i c i o n << 5 ;115 b r e a k ;116 c a s e AN4:117 o u t _ d a t a [ 2 1 ] | = c o n d i c i o n << 6 ;118 b r e a k ;119 c a s e AN5:120 o u t _ d a t a [ 2 1 ] | = c o n d i c i o n << 7 ;121 b r e a k ;122 c a s e AN6:123 o u t _ d a t a [ 2 2 ] | = c o n d i c i o n ;124 b r e a k ;125 c a s e AN7:126 o u t _ d a t a [ 2 2 ] | = c o n d i c i o n << 1 ;127 b r e a k ;128 c a s e AN8:129 o u t _ d a t a [ 2 2 ] | = c o n d i c i o n << 2 ;130 b r e a k ;131 c a s e AN9:132 o u t _ d a t a [ 2 2 ] | = c o n d i c i o n << 3 ;133 b r e a k ;134 135 136137 /∗138 ∗ P e r f o r m s t h e a c t u a l r e a d i n g of t r a n s d u c e r s139 ∗ /140 vo id s e n s o r T a s k ( vo id ) 141 i n t 8 i , j ;142143 / / C l e a r t h e o u t p u t b u f f e r144 f o r ( i =0 ; i <23; i ++) o u t _ d a t a [ i ] = 0x0 ;145146 f o r ( i =0 , j =0 ; i <10; i ++)147 148 s e t _ a d c _ c h a n n e l ( s e n s o r _ l u t [ i ] ) ;149 r e a d _ a d c (ADC_START_ONLY) ;150 d e l a y _ u s (DELAY_AD_US) ;151 sample = r e a d _ a d c (ADC_READ_ONLY) ;152 o u t _ d a t a [ j ] = sample & 0x00FF ;153 o u t _ d a t a [ j ++] = ( sample & 0 x300 ) >> 8 ;154 EvaluarAD (AN0, sample ) ;155 156157 o u t _ d a t a [ 2 0 ] | = (~D0&0x1 ) ;158 o u t _ d a t a [ 2 0 ] | = (~D1&0x1 ) << 1 ;159 o u t _ d a t a [ 2 0 ] | = (~D2&0x1 ) << 2 ;160 o u t _ d a t a [ 2 0 ] | = (~D3&0x1 ) << 3 ;161 o u t _ d a t a [ 2 0 ] | = (~D4&0x1 ) << 4 ;162 o u t _ d a t a [ 2 0 ] | = (~D5&0x1 ) << 5 ;


163 o u t _ d a t a [ 2 0 ] | = (~D6&0x1 ) << 6 ;164 o u t _ d a t a [ 2 0 ] | = (~D7&0x1 ) << 7 ;165166 o u t _ d a t a [ 2 1 ] | = (~D8&0x1 ) ;167 o u t _ d a t a [ 2 1 ] | = (~D9&0x1 ) << 1 ;168169 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) ;170 171172 /∗173 ∗ 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 PIC18F2550174 ∗ /175 vo id s e n s o r I n i t ( vo id ) 176 SET_TRIS_A (0 b10111111 ) ;177 SET_TRIS_B (0 b11111111 ) ;178 SET_TRIS_C (0 b11000111 ) ;179 PORT_B_PULLUPS(TRUE) ;180 s e t u p _ a d c _ p o r t s (ALL_ANALOG) ;181 s e t u p _ a d c (ADC_CLOCK_INTERNAL) ;182 s e t _ a d c _ c h a n n e l ( 0 ) ;183 184185 /∗186 ∗ P e r f o r m s t h e HASP t a s k187 ∗ /188 vo id HASPTask ( vo id ) 189 u s b _ g e t _ p a c k e t ( 2 , d a t a _ b u f f e r , 9 ) ; / / Get t h e d a t a from t h e PIC ’ s dua l−p o r t ram190 f o r ( i =0 ; i <6 ; i ++)191 i f ( r s tMsg [ i ] != d a t a _ b u f f e r [ i ] )192 go to hasp ;193 #asm194 go to 0 x0016 ; B o o t l o a d e r e n t r y p o i n t195 # endasm196 hasp :197 s i g n ( ( ptrWord ) d a t a _ b u f f e r ) ; / / S ign t h e s t r i n g198 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 back t h e s i g n e d s t r i n g199 200201 /∗202 ∗ Firmware e n t r y p o i n t203 ∗ /204 vo id main ( vo id ) 205206 / / s p r i n t f ( r e s e t M s g " cmdRst " ) ;207208 s e n s o r I n i t ( ) ; / / C o n f i g u r e p i n s209 u s b _ i n i t _ c s ( ) ; / / I n i t USB l i b r a r y210 h a s p _ i n i t ( ) ; / / I n i t HASP a l g o r i t h m211212 w h i l e (TRUE) / / Loop f o r e v e r213 u s b _ t a s k ( ) ; / / Do t h e USB t a s k214 i f ( u sb_enumera t ed ( ) ) 215 s e n s o r T a s k ( ) ; / / Pe r fo rm t h e s e n s o r t a s k216 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 . . .217 HASPTask ( ) ; / / we p r o c e s s and send i t back218 219 220 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 10ms221 222

C.1.2. lsred_desc.h1 #IFNDEF __USB_DESCRIPTORS__2 #DEFINE __USB_DESCRIPTORS__34 # i n c l u d e <usb . h>56 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /7 / / /8 / / / HID R epo 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 th9 / / / r e c e i v e d d a t a . HID R e p o r t s can be e x t r e m e l y complex ,

10 / / / 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 your own .11 / / /12 / / / Gamepad : 10 a x i s − 20 b u t t o n s13 / / / Vendor−s p e c i f i c HID Device : LSyM HASP key14 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /1516 c o n s t c h a r USB_CLASS_SPECIFIC_DESC [ ] = 17 0x05 , 0x01 , / / USAGE_PAGE ( G e n e r i c Desktop ) / / 0 ,1


18 0x09 , 0x05 , / / USAGE ( Game Pad ) / / 2 ,319 0xa1 , 0x01 , / / COLLECTION ( A p p l i c a t i o n ) / / 4 ,520 0xa1 , 0x00 , / / COLLECTION ( P h y s i c a l ) / / 6 ,721 0x09 , 0x30 , / / USAGE (X) / / 8 ,922 0x09 , 0x31 , / / USAGE (Y) / / 10 ,1123 0x09 , 0x32 , / / USAGE ( Z ) / / 12 ,1324 0x09 , 0x33 , / / USAGE ( Rx ) / / 14 ,1525 0x09 , 0x34 , / / USAGE ( Ry ) / / 16 ,1726 0x09 , 0x35 , / / USAGE ( Rz ) / / 18 ,1927 0x09 , 0x38 , / / USAGE ( Wheel ) / / 20 ,2128 0x09 , 0x36 , / / USAGE ( S l i d e r ) / / 22 ,2329 0x15 , 0x00 , / / LOGICAL_MINIMUM ( 0 ) / / 24 ,2530 0x26 , 0 x f f , 0x03 , / / LOGICAL_MAXIMUM ( 1 0 2 3 ) / / 26 ,27 ,2831 0x75 , 0x10 , / / REPORT_SIZE ( 1 6 ) / / 29 ,3032 0x95 , 0x08 , / / REPORT_COUNT ( 8 ) / / 31 ,3233 0x81 , 0x02 , / / INPUT ( Data , Var , Abs ) / / 33 ,3434 0x05 , 0x02 , / / USAGE_PAGE ( S i m u l a t i o n C o n t r o l s ) / / 35 ,3635 0x09 , 0xbb , / / USAGE ( T h r o t t l e ) / / 37 ,3836 0x09 , 0xc5 , / / USAGE ( Brake ) / / 39 ,4037 0x15 , 0x00 , / / LOGICAL_MINIMUM ( 0 ) / / 41 ,4238 0x26 , 0 x f f , 0x03 , / / LOGICAL_MAXIMUM ( 1 0 2 3 ) / / 43 ,44 ,4539 0x75 , 0x10 , / / REPORT_SIZE ( 1 6 ) / / 46 ,4740 0x95 , 0x02 , / / REPORT_COUNT ( 2 ) / / 48 ,4941 0x81 , 0x02 , / / INPUT ( Data , Var , Abs ) / / 50 ,5142 0x05 , 0x09 , / / USAGE_PAGE ( B u t to n ) / / 52 ,5343 0x19 , 0x01 , / / USAGE_MINIMUM ( B ut to n 1 ) / / 54 ,5544 0x29 , 0x14 , / / USAGE_MAXIMUM ( B ut to n 20) / / 56 ,5745 0x15 , 0x00 , / / LOGICAL_MINIMUM ( 0 ) / / 58 ,5946 0x25 , 0x01 , / / LOGICAL_MAXIMUM ( 1 ) / / 60 ,6147 0x75 , 0x01 , / / REPORT_SIZE ( 1 ) / / 62 ,6348 0x95 , 0x14 , / / REPORT_COUNT ( 2 0 ) / / 64 ,6549 0x81 , 0x02 , / / INPUT ( Data , Var , Abs ) / / 66 ,6750 0x95 , 0x04 , / / REPORT_COUNT ( 4 ) / / 68 ,6951 0x81 , 0x03 , / / INPUT ( Cnst , Var , Abs ) / / 70 ,7152 0xc0 , / / END_COLLECTION / / 7253 0xc0 , / / END_COLLECTION / / 7354 / / 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 e55 0x06 , 0x00 , 0 x f f , / / USAGE_PAGE ( Vendor Def ined Page 1 ) / / 74 ,75 ,7656 0x09 , 0x01 , / / USAGE ( Vendor Usage 1 ) / / 77 ,7857 0xa1 , 0x01 , / / COLLECTION ( A p p l i c a t i o n ) / / 79 ,8058 0x19 , 0x01 , / / USAGE_MINIMUM ( Vendor Usage 1 ) / / 81 ,8259 0x29 , 0x01 , / / USAGE_MAXIMUM ( Vendor Usage 1 ) / / 83 ,8460 0x15 , 0x00 , / / LOGICAL_MINIMUM ( 0 ) / / 85 ,8661 0x26 , 0 x f f , 0x00 , / / LOGICAL_MAXIMUM ( 2 5 5 ) / / 87 ,88 ,8962 0x75 , 0x08 , / / REPORT_SIZE ( 8 ) / / 90 ,9163 0x95 , 0x08 , / / REPORT_COUNT ( 8 ) / / 92 ,9364 0x81 , 0x02 , / / INPUT ( Data , Var , Abs ) / / 94 ,9565 0x19 , 0x01 , / / USAGE_MINIMUM ( Vendor Usage 1 ) / / 96 ,9766 0x29 , 0x01 , / / USAGE_MAXIMUM ( Vendor Usage 1 ) / / 98 .9967 0x15 , 0x00 , / / LOGICAL_MINIMUM ( 0 ) / / 100 ,10168 0x26 , 0 x f f , 0x00 , / / LOGICAL_MAXIMUM ( 2 5 5 ) / / 102 ,103 ,10469 0x75 , 0x08 , / / REPORT_SIZE ( 8 ) / / 105 ,10670 0x95 , 0x09 , / / REPORT_COUNT ( 9 ) / / 107 ,10871 0x91 , 0x02 , / / OUTPUT ( Data , Var , Abs ) / / 109 ,11072 0 xc0 / / END_COLLECTION / / 11173 ; / / T o t a l : 1127475 / / i f a c l a s s has 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 ,76 / / t h i s lookup t a b l e d e f i n e s where t o look f o r i t i n t h e c o n s t77 / / USB_CLASS_SPECIFIC_DESC [ ] a r r a y .78 / / 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 your d e v i c e has more t h a n one c o n f i g )79 / / second e l e m e n t i s which i n t e r f a c e number80 / / 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 doesn ’ t e x i s t81 c o n s t i n t 1 6 USB_CLASS_SPECIFIC_DESC_LOOKUP [USB_NUM_CONFIGURATIONS ] [ 2 ] =82 83 / / c o n f i g 184 / / i n t e r f a c e 085 0 ,86 / / i n t e r f a c e 187 7488 ;8990 / / i f a c l a s s has 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 ,91 / / t h i s lookup t a b l e d e f i n e s t h e s i z e o f t h a t d e s c r i p t o r .92 / / 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 your d e v i c e has more t h a n one c o n f i g )93 / / second e l e m e n t i s which i n t e r f a c e number94 / / 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 doesn ’ t e x i s t95 c o n s t i n t 1 6 USB_CLASS_SPECIFIC_DESC_LOOKUP_SIZE [USB_NUM_CONFIGURATIONS ] [ 2 ] =96 97 / / c o n f i g 198 / / i n t e r f a c e 099 74 ,

100 / / i n t e r f a c e 1101 38


102 / / s i z e o f ( USB_CLASS_SPECIFIC_DESC )103 ;104105106107 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /108 / / /109 / / / s t a r t c o n f i g d e s c r i p t o r110 / / / r i g h t now we on ly 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 .111 / / / 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 goes i n t o t h i s a r r a y .112 / / /113 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /114115 #DEFINE USB_TOTAL_CONFIG_LEN 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 t116117 c o n s t c h a r USB_CONFIG_DESC [ ] = 118 / / IN ORDER TO COMPLY WITH WINDOWS HOSTS , THE ORDER OF THIS ARRAY MUST BE :119 / / c o n f i g ( s )120 / / i n t e r f a c e ( s )121 / / c l a s s ( e s )122 / / e n d p o i n t ( s )123124 / / c o n f i g _ d e s c r i p t o r f o r c o n f i g i n d e x 1125 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 ==1126 USB_DESC_CONFIG_TYPE , / / c o n s t a n t CONFIGURATION (CONFIGURATION 0x02 ) ==2127 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 ,4128 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 ==5129 0x01 , / / 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 . ( IF we had more t h a n one c o n f i g u r a t i o n s ) ==6130 0x00 , / / 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 ==7131 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 remote wakeup ( we don ’ t ) , b i t s 0−4 unused and b i t 7 =1

==8132 0x32 , / / maximum bus 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)133134 / / i n t e r f a c e d e s c r i p t o r 1135 USB_DESC_INTERFACE_LEN , / / l e n g t h o f d e s c r i p t o r =10136 USB_DESC_INTERFACE_TYPE , / / c o n s t a n t INTERFACE ( INTERFACE 0x04 ) =11137 0x00 , / / number d e f i n i n g t h i s i n t e r f a c e ( IF we had more t h a n one i n t e r f a c e ) ==12138 0x00 , / / a l t e r n a t e s e t t i n g ==13139 1 , / / number o f endpo ins , e x c e p t 0 . ==14140 0x03 , / / c l a s s code , 03 = HID ==15141 0x00 , / / s u b c l a s s code / / boo t ==16142 0x00 , / / p r o t o c o l code ==17143 0x02 , / / 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 ==18144145 / / c l a s s d e s c r i p t o r 1 ( HID )146 USB_DESC_CLASS_LEN , / / l e n g t h o f d e s c r i p t o r ==19147 USB_DESC_CLASS_TYPE , / / d s c r i p t o r t y p e (0 x21 == HID ) ==20148 0x10 , 0 x01 , / / h i d c l a s s r e l e a s e number ( 1 . 0 ) ==21 ,22149 0x00 , / / l o c a l i z e d c o u n t r y code (0 = none ) ==23150 0x01 , / / 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 ) ==24151 0x22 , / / r e p o r t d e s c r i p t o r t y p e (0 x22 == HID ) ==25152 USB_CLASS_SPECIFIC_DESC_LOOKUP_SIZE [ 0 ] [ 0 ] , 0x00 , / / l e n g t h o f r e p o r t d e s c r i p t o r ==26 ,27153154 / / e n d p o i n t d e s c r i p t o r155 USB_DESC_ENDPOINT_LEN , / / l e n g t h o f d e s c r i p t o r ==28156 USB_DESC_ENDPOINT_TYPE , / / c o n s t a n t ENDPOINT (ENDPOINT 0x05 ) ==29157 0x81 , / / e n d p o i n t number and d i r e c t i o n (0 x81 = EP1 IN ) ==30158 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 ) ==31159 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 ,33160 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 low speed d e v i c e s ) ==34161 / / i n t e r f a c e d e s c r i p t o r 2 (HASP)162 USB_DESC_INTERFACE_LEN , / / l e n g t h o f d e s c r i p t o r =34163 USB_DESC_INTERFACE_TYPE , / / c o n s t a n t INTERFACE ( INTERFACE 0x04 ) =35164 0x01 , / / number d e f i n i n g t h i s i n t e r f a c e ( IF we had more t h a n one i n t e r f a c e ) ==36165 0x00 , / / a l t e r n a t e s e t t i n g ==37166 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 / / 3 8167 0x03 , / / c l a s s code , 03 = HID ==39168 0x00 , / / s u b c l a s s code / / boo t ==40169 0x00 , / / p r o t o c o l code ( keyboard ) ==41170 0x03 , / / 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 ==42171 / / c l a s s d e s c r i p t o r 2 ( HID )172 USB_DESC_CLASS_LEN , / / l e n g t h o f d e s c r i p t o r ==43173 USB_DESC_CLASS_TYPE , / / d s c r i p t o r t y p e (0 x21 == HID ) ==44174 0x10 , 0 x01 , / / h i d c l a s s r e l e a s e number ( 1 . 0 ) ==45 ,46175 0x00 , / / l o c a l i z e d c o u n t r y code (0 = none ) ==47176 0x01 , / / 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 ) ==48177 0x22 , / / r e p o r t d e s c r i p t o r t y p e (0 x22 == HID ) ==49178 USB_CLASS_SPECIFIC_DESC_LOOKUP_SIZE [ 0 ] [ 1 ] , 0x00 , / / 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 ,51179 / / e n d p o i n t d e s c r i p t o r 2 IN180 USB_DESC_ENDPOINT_LEN , / / l e n g t h o f d e s c r i p t o r ==52181 USB_DESC_ENDPOINT_TYPE , / / c o n s t a n t ENDPOINT (ENDPOINT 0x05 ) ==53182 0x82 , / / e n d p o i n t number and d i r e c t i o n (0 x82 = EP2 IN ) ==54183 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 ) ==55184 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


185 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 low speed d e v i c e s ) ==58186 / / e n d p o i n t d e s c r i p t o r 2 OUT187 USB_DESC_ENDPOINT_LEN , / / l e n g t h o f d e s c r i p t o r ==52188 USB_DESC_ENDPOINT_TYPE , / / c o n s t a n t ENDPOINT (ENDPOINT 0x05 ) ==53189 0x02 , / / e n d p o i n t number and d i r e c t i o n (0 x02 = EP2 OUT) ==54190 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 ) ==55191 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 ,57192 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 low speed d e v i c e s ) ==58193 ;194195196 / /∗∗∗∗∗∗ BEGIN CONFIG DESCRIPTOR LOOKUP TABLES ∗∗∗∗∗∗∗∗197 / / s i n c e we can ’ 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 c16s , t h i s i s an o f f s e t t a b l e t o f i n d198 / / 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 .199200 / / NOTE: DO TO A LIMITATION OF THE CCS CODE, ALL HID INTERFACES MUST START AT 0 AND BE SEQUENTIAL201 / / FOR EXAMPLE, IF YOU HAVE 2 HID INTERFACES THEY MUST BE INTERFACE 0 AND INTERFACE 1202 # d e f i n e USB_NUM_HID_INTERFACES 2203204 / / t h e maximum number o f i n t e r f a c e s seen on any c o n f i g205 / / f o r example , i f c o n f i g 1 has 1 i n t e r f a c e and c o n f i g 2 has 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 2206 # d e f i n e USB_MAX_NUM_INTERFACES 2207208 / / 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 t h e f i r s t c o n f i g , e t c .209 c o n s t c h a r USB_NUM_INTERFACES[USB_NUM_CONFIGURATIONS] = 2 ;210211 / / 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 s212 / / f i r s t d imens ion i s t h e c o n f i g number213 / / second d imens ion s p e c i f i e s which i n t e r f a c e214 / / l a s t d imens ion 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 ge t , b u t most w i l l on ly have 1 c l a s s p e r i n t e r f a c e215 / / 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 0xFFFF216 c o n s t i n t 1 6 USB_CLASS_DESCRIPTORS [USB_NUM_CONFIGURATIONS ] [ 2 ] [ 1 ] =217 218 / / c o n f i g 1219 / / i n t e r f a c e 0220 / / c l a s s 1221 18 ,222 / / i n t e r f a c e 1223 / / c l a s s 1224 43225 ;226227228 # i f ( s i z e o f (USB_CONFIG_DESC) != USB_TOTAL_CONFIG_LEN)229 # 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 y230 # e n d i f231232233 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /234 / / /235 / / / s t a r t d e v i c e d e s c r i p t o r s236 / / /237 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /238 / / #ORG 0 x2700239 c o n s t c h a r USB_DEVICE_DESC [ ] = 240241 / / s t a r t s o f w i th d e v i c e c o n f i g u r a t i o n . on ly one p o s s i b l e242 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 ==1243 0x01 , / / t h e c o n s t a n t DEVICE (DEVICE 0x01 ) ==2244 0x00 , 0 x02 , / / usb v e r s i o n i n bcd ( 2 . 0 ) ==3 ,4245 0x00 , / / c l a s s code ==5246 0x00 , / / s u b c l a s s code ==6247 0x00 , / / p r o t o c o l code ==7248 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) ==8249 0xD8 , 0 x04 , / / vendor i d (0 x04D8 i s Mic roch ip )250 0x02 , 0 xF0 , / / p r o d u c t i d ==11 ,12 / / don ’ t use f f f f s a y s usb−by−example guy . oops251 0x00 , 0 x02 , / / d e v i c e r e l e a s e number ==13 ,14252 0x01 , / / 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 ) ==15253 0x02 , / / 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 ==16254 0x04 , / / 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 ==17255 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 ==18256 ;257258 # i f ( s i z e o f (USB_DEVICE_DESC) != USB_DESC_DEVICE_LEN)259 # 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 y260 # e n d i f261262263 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /264 / / /265 / / / s t a r t s t r i n g d e s c r i p t o r s266 / / / 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 . Peo p l e i n U. S .A. can l e a v e t h i s a l o n e .267 / / /268 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

158 C.2. LIBRERÍA LIBHW

269270 / / t h e o f f s e t o f t h e s t a r t i n g l o c a t i o n o f each s t r i n g . o f f s e t [ 0 ] i s t h e s t a r t o f s t r i n g 0 , o f f s e t [ 1 ] i s t h e s t a r t o f

s t r i n g 1 , e t c .271 c o n s t c h a r USB_STRING_DESC_OFFSET [ ] = 0 , 4 , 1 4 , 4 4 , 7 8 ;272273 / / 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 .274 # d e f i n e USB_STRING_DESC_COUNT s i z e o f ( USB_STRING_DESC_OFFSET )275276 #ORG 0x7CA2 , 0x7D2F277 c h a r c o n s t USB_STRING_DESC [ ] = 278 / / s t r i n g 0279 4 , / / l e n g t h o f s t r i n g i n d e x280 USB_DESC_STRING_TYPE , / / d e s c r i p t o r t y p e 0x03 ( STRING )281 0x09 , 0 x04 , / / M i c r o s o f t Def ined f o r US−E n g l i s h282 / / s t r i n g 1283 10 , / / l e n g t h o f s t r i n g i n d e x284 USB_DESC_STRING_TYPE , / / d e s c r i p t o r t y p e 0x03 ( STRING )285 ’L ’ , 0 ,286 ’S ’ , 0 ,287 ’ y ’ , 0 ,288 ’M’ ,0289 / / s t r i n g 2290 30 , / / l e n g t h o f s t r i n g i n d e x291 USB_DESC_STRING_TYPE , / / d e s c r i p t o r t y p e 0x03 ( STRING )292 ’L ’ , 0 ,293 ’S ’ , 0 ,294 ’ y ’ , 0 ,295 ’M’ , 0 ,296 ’ ’ , 0 ,297 ’D’ , 0 ,298 ’A’ , 0 ,299 ’Q’ , 0 ,300 ’ ’ , 0 ,301 ’B ’ , 0 ,302 ’ o ’ , 0 ,303 ’ a ’ , 0 ,304 ’ r ’ , 0 ,305 ’ d ’ ,0306 / / s t r i n g 3307 34 ,308 USB_DESC_STRING_TYPE ,309 ’L ’ , 0 ,310 ’S ’ , 0 ,311 ’ y ’ , 0 ,312 ’M’ , 0 ,313 ’ ’ , 0 ,314 ’H’ , 0 ,315 ’A’ , 0 ,316 ’S ’ , 0 ,317 ’P ’ , 0 ,318 ’ ’ , 0 ,319 ’D’ , 0 ,320 ’ e ’ , 0 ,321 ’ v ’ , 0 ,322 ’ i ’ , 0 ,323 ’ c ’ , 0 ,324 ’ e ’ ,0325 / / s t r i n g 4326 18 ,327 USB_DESC_STRING_TYPE ,328 ’D’ , 0 ,329 ’A’ , 0 ,330 ’Q’ , 0 ,331 ’−’ , 0 ,332 ’ 0 ’ , 0 ,333 ’ 0 ’ , 0 ,334 ’ 0 ’ , 0 ,335 ’ 0 ’ ,0336 ;337 # org 0x1390 , 0x1AFF DEFAULT

C.2. LIBRERÍA LIBHW

Debido a la gran cantidad de código existente entre librería y herramientas comple-mentarias se muestra sólo el código fuente de los archivos de cabecera que definen cadacapa. El código fuente completo de todo el proyecto se encuentra en soporte digital en el


CD adjunto.

C.2.1. libhw.h1 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /2 / / /3 / / / \ f i l e l i bhw . h4 / / /5 / / / \ 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 ibhw 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 h e a d e r s6 / / / \ a u t h o r Miguel Angel E x p o s i t o Sanchez (LSYM) <miexsan@alumni . uv . es >7 / / /8 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /9

10 # i f n d e f libhwH11 # d e f i n e libhwH1213 / /−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−14 # i n c l u d e <windows . h>1516 # i n c l u d e " P r o t o c o l . h "17 # i n c l u d e " D r i v e r . h "18 # i n c l u d e "LSYMCSVP. h "19 # i n c l u d e "LSYMHASPD2 . h "20 # i n c l u d e "LSYMHASP. h "2122 /∗∗∗∗∗∗∗∗ C O N S T A N T S ∗∗∗∗∗∗∗∗∗ /23 /∗24 ∗ Some c o n s t a n t s25 ∗ /26 # d e f i n e LSYM_VENDOR_ID 0x04D8 / / / < Vendor ID we use from Mic roch ip Technology , I n c .2728 namespace l ibhw29 3031 / / Forward d e c l a r a t i o n s t o speed−up compi l e t ime32 t y p e d e f vo id 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 s33 c l a s s D r i v e r ; / / / < The d r i v e r l a y e r i n t e r f a c e34 c l a s s P r o t o c o l ; / / / < The p r o t o c o l l a y e r i n t e r f a c e35 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 n36 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 s37 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 s38 c l a s s l i b h w E x c e p t i o n ; / / / < E x c e p t i o n s t h a t can be thrown by l ibhw39 ;4041 # e n d i f

C.2.2. Driver.h1 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /2 / / /3 / / / \ f i l e D r i v e r . h4 / / /5 / / / \ 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 implemented i n a l l d r i v e r s f o r LSyM p r o d u c t s6 / / / \ a u t h o r Miguel Angel E x p o s i t o Sanchez (LSYM) <miexsan@alumni . uv . es >7 / / /8 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /9

10 # i f n d e f DriverH11 # d e f i n e DriverH1213 / /−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−1415 # i n c l u d e " l ibhw . h "1617 namespace l ibhw18 1920 /∗∗21 ∗ \ c l a s s D r i v e r22 ∗ \ s e c t i o n d e v e l o p e r s Use23 ∗ In o r d e r t o make a d r i v e r you must implement a l l methods i n t h i s i n t e r f a c e .24 ∗ /25 c l a s s D r i v e r26 27 f r i e n d c l a s s LSYMHASP;28 p u b l i c :


29 D r i v e r ( ) : s t a t e (UNENUM) / / / < C l a s s c o n s t r u c t o r30 ~ D r i v e r ( ) / / / < C l a s s d e s t r u c t o r31 /∗∗32 ∗ D r i v e r ’ s i n t e r n a l s t a t e−machine33 ∗ /34 enum D r i v e r S t a t e UNENUM, / / / < The d e v i c e i s n o t enumera t ed35 ENUMERATING, / / / < The d e v i c e i s b e i n g enumera t ed36 OK, / / / < Device enumera t ed and r u n n i n g37 DRVERROR / / / < D r i v e r e r r o r38 ;3940 s t a t i c c o n s t u n s i g n e d c h a r produc t IDL ; / / / < P r o d u c t ID ’ s LSB s t a r t i n g v a l u e41 s t a t i c c o n s t u n s i g n e d c h a r product IDH ; / / / < P r o d u c t ÍD ’ s MSB s t a r t i n g v a l u e42 p r o t e c t e d :43 s t a t i c c o n s t i n t oLen ; / / / < Outpu t b u f f e r l e n g t h i n b y t e s44 s t a t i c c o n s t i n t iLen ; / / / < I n p u t b u f f e r l e n g t h i n b y t e s45 D r i v e r S t a t e s t a t e ; / / / < C u r r e n t d r i v e r ’ s s t a t e46 c h a r SN [ 2 0 ] ; / / / < Device s e r i a l number47 wcha r_ t P r o d u c t S t r i n g [ 5 0 ] ; / / / < Device p r o d u c t name s t r i n g48 u n s i g n e d s h o r t i n t p r o d u c t I D ; / / / < Device p r o d u c t ID49 v i r t u a l vo id enumera t e ( ) = 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 enumera t e t h e d e v i c e )50 v i r t u a l boo l send ( u n s i g n e d c h a r∗ da ta ,51 u n s i g n e d i n t l e n ) r e t u r n f a l s e ; / / / < W r i t e s a d a t a p a c k e t t o t h e d e v i c e52 v i r t u a l boo l r e c e i v e ( u n s i g n e d c h a r∗ da ta ,53 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 ; / / / < Gets a d a t a p a c k e t from t h e d e v i c e54 v i r t u a l vo id r e s e t ( ) / / / < R e s e t s t h e d r i v e r55 /∗∗56 ∗ Gets t h e c u r r e n t d r i v e r s t a t e57 ∗ @return The c u r r e n t D r i v e r S t a t e58 ∗ /59 i n l i n e D r i v e r S t a t e g e t S t a t e ( ) r e t u r n s t a t e ; 60 ;61 6263 # e n d i f

C.2.3. Protocol.h1 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /2 / / /3 / / / \ f i l e P r o t o c o l . h4 / / /5 / / / \ 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 implemented 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 s6 / / / \ a u t h o r Miguel Angel E x p o s i t o Sanchez (LSYM) <miexsan@alumni . uv . es >7 / / /8 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /9

10 # i f n d e f P r o t o c o l H11 # d e f i n e P r o t o c o l H1213 / /−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−14 # i n c l u d e " l ibhw . h "1516 namespace l ibhw17 18 /∗∗19 ∗ \ c l a s s P r o t o c o l20 ∗ \ s e c t i o n d e v e l o p e r s Use21 ∗ In o r d e r t o make a p r o t o c o l you must implement a l l methods i n t h i s i n t e r f a c e .22 ∗ /23 c l a s s P r o t o c o l24 25 f r i e n d c l a s s LSYMHASP;26 p u b l i c :27 /∗∗28 ∗ C l a s s c o n s t r u c t o r29 ∗ 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 s30 ∗ /31 P r o t o c o l ( ) : s t a t e (STOP)32 33 /∗ 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 ∗ /34 i n p u t = ( u n s i g n e d c h a r ∗) m a l lo c ( iLen ) ;35 o u t p u t = ( u n s i g n e d c h a r ∗) m a l lo c ( oLen ) ;36 / / I f i n p u t == NULL | | o u t p u t == NULL −−> E x c e p t i o n ?37 3839 /∗∗40 ∗ C l a s s d e s t r u c t o r41 ∗ F r e e s t h e memory used by t h e i n p u t / o u t p u t b u f f e r s42 ∗ /


43 ~ P r o t o c o l ( )44 45 /∗ Free t h e i n p u t and o u t p u t b u f f e r s ∗ /46 f r e e ( i n p u t ) ;47 f r e e ( o u t p u t ) ;48 4950 /∗∗51 ∗ P r o t o c o l i n t e r n a l s t a t e−machine52 ∗ /53 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 d54 INITIALIZING , / / / < The p r o t o c o l i s i n i t i a l i z i n g55 OK, / / / < The p r o t o c o l i s working OK56 INIT_ERROR , / / / < There was an i n i t i a l i z a t i o n e r r o r57 PROT_ERROR / / / < There was a p r o t o c o l e r r o r58 ;59 s t a t i c c o n s t u n s i g n e d i n t productIDMask ; / / / < P r o d u c t ID f l a g s match ing t h i s p r o t o c o l60 /∗∗61 ∗ Gets t h e c u r r e n t p r o t o c o l s t a t e62 ∗ @return The p r o t o c o l s t a t e63 ∗ /64 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 t h e c u r r e n t p r o t o c o l s t a t e65 /∗∗66 ∗ Gets 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 h67 ∗ @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 r68 ∗ @return t h e s i z e i n b y t e s o f t h e b u f f e r69 ∗ /70 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 t o

t h e o u t p u t b u f f e r71 /∗∗72 ∗ Gets 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 h73 ∗ @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 r74 ∗ @return t h e s i z e i n b y t e s o f t h e b u f f e r75 ∗ /76 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 iLen ; 77 p r o t e c t e d :78 P r o t o c o l S t a t e s t a t e ; / / / < C u r r e n t p r o t o c o l s t a t e79 v i r t u a l vo id i n i t ( ) / / / < I n i t i a l i z e t h e p r o t o c o l80 v i r t u a l vo id p r e S t e p ( ) / / / < S t e p s t h e p r o t o c o l ( p r e v i o u s t o d a t a exchange )81 v i r t u a l vo id p o s t S t e p ( ) / / / < S t e p s t h e p r o t o c o l ( f o l l o w i n g d a t a exchange )82 v i r t u a l vo id 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 )83 u n s i g n e d c h a r ∗ i n p u t ; / / / < I n p u t b u f f e r ( D r i v e r => P r o t o c o l )84 u n s i g n e d c h a r ∗ o u t p u t ; / / / < Outpu t b u f f e r ( P r o t o c o l => Device )85 s t a t i c c o n s t i n t oLen = 9 ; / / / < Def ined o u t p u t l e n g t h86 s t a t i c c o n s t i n t iLen = 8 ; / / / < Def ined i n p u t l e n g t h87 ;88 8990 # e n d i f

C.2.4. LSYMHASP.h12 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /3 / / /4 / / / \ f i l e LSYMHASP. h5 / / /6 / / / \ b r i e f LSYMHASP C l a s s imp lemen t s a ha rdware v a l i d a t i o n s e c u r i t y t h r e a d wi th a c a l l b a c k i n t e r f a c e7 / / / \ a u t h o r Miguel Angel E x p o s i t o Sanchez (LSYM) <miexsan@alumni . uv . es >8 / / /9 / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

101112 # i f n d e f LSYMHASPH13 # d e f i n e LSYMHASPH1415 / /−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−1617 # i n c l u d e " l ibhw . h "18 # i n c l u d e " l i b h w E x c e p t i o n . h "1920 / / D e f i n i t i o n o f messages t h a t can be s e n t t o t h e t h r e a d21 # d e f i n e WM_STOP WM_APP + 0 x100 / / / < Stop t h e t h r e a d22 # d e f i n e WM_RESET WM_APP + 0 x101 / / / < R e s e t t h e p r o t o c o l2324 namespace l ibhw25 26 /∗∗27 ∗ \ c l a s s LSYMHASP28 ∗ \ s e c t i o n HASPuse Use


29 ∗ To use 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 use30 ∗ , a p o i n t e r t o t h e p r o t o c o l t o use and a p o i n t e r t o a use r−d e f i n e d c a l l b a c k f u n c t i o n .31 ∗ /32 c l a s s LSYMHASP33 34 p u b l i c :35 /∗∗36 ∗ HASP I n t e r n a l s a t e−machine37 ∗ /38 enum HASPState STAT_DISCONNECTED , / / / < Device n o t c o n n e c t e d39 STAT_DETECTED , / / / < Device d e t e c t e d b u t n o t checked40 STAT_INIT , / / / < L i b r a r y i n i t i a l i z a t i o n41 STAT_RUNNING, / / / < L i b r a r y r u n n i n g42 STAT_ERROR, / / / < L i b r a r y e r r o r43 STAT_STOP / / / < L i b r a r y s t o p p e d44 ;45 /∗∗46 ∗ HASP C a l l b a c k messages47 ∗ /48 enum HASPMessage HWERROR, / / / < Hardware e r r o r49 PERROR, / / / < P r o t o c o l e r r o r50 DISCONNECTED, / / / < The HASP d e v i c e i s n o t c o n n e c t e d51 ONLINE , / / / < The HASP d e v i c e has been c o n n e c t e d and checked52 INIT , / / / < The HASP l i b r a r y has been i n i t i a l i z e d53 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 y54 STOP ; / / / < The HASP l i b r a r y has been s t o p p e d55 /∗∗56 ∗ HASP E x c e p t i o n codes57 ∗ /58 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 d59 EX_THREADSTOPPED, / / / < Stop 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 d60 EX_CANTSTOP, / / / < Stop e r r o r : The t h r e a d can ’ t be s t o p p e d61 EX_CANTSTART / / / < S t a r t e r r o r : The t h r e a d can ’ t be s t a r t e d62 ;63 t y p e d e f vo id (∗HWEVTCALLBACK) ( HASPMessage ) ; / / / < User c a l l b a c k f u n c t i o n p r o t o t y p e64 LSYMHASP( D r i v e r ∗ , P r o t o c o l ∗ , HWEVTCALLBACK) ; / / / < C l a s s c o n s t r u c t o r65 ~LSYMHASP( ) ; / / / < C l a s s d e s t r u c t o r66 vo id c l e a n u p ( ) ; / / / < F r e e s t h e d r i v e r and p r o t o c o l memory67 vo id s t a r t ( ) ; / / / < S t a r t s t h e HASP s e r v i c e68 vo id s t o p ( ) ; / / / < S t o p s t h e HASP s e r v i c e69 i n l i n e boo l va l idHWPresen 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! ! , use t h e c a l l b a c k i n s t e a d )70 /∗∗71 ∗ Gets 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 r72 ∗ ( you must check f i r s t t h e s t a t e OK)73 ∗ 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 )74 ∗ @return The p r o d u c t s e r i a l number s t r i n g75 ∗ /76 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 ; 77 /∗∗78 ∗ Gets t h e Produc t ID of t h e c u r r e n t d e v i c e79 ∗ ( you must check f i r s t t h e s t a t e OK)80 ∗ @return The p r o d u c t ID81 ∗ /82 i n l i n e u n s i g n e d s h o r t i n t ge tPID ( ) r e t u r n d r i v e r−>p r o d u c t I D ; 83 p r i v a t e :84 s t a t i c u n s i g n e d i n t _ _ s t d c a l l HASPSta t icThread ( vo id ∗) ; / / / < 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

s e r v i c e85 vo id HASPThread ( ) ; / / / < Rea l HASP s e r v i c e t h r e a d86 HANDLE m_hHASPThread ; / / / < Handle t o working t h r e a d87 u n s i g n e d m_idHASPThread ; / / / < Working t h r e a d ’ s ID88 HWND hWnd ; / / / < User window r e c e i v i n g WM_DEVICECHANGE messages89 HASPState s t a t e ; / / / < HASP c u r r e n t s t a t e90 D r i v e r∗ d r i v e r ; / / / < D r i v e r t o use wi th t h e ha rdware91 P r o t o c o l∗ p r o t o c o l ; / / / < V a l i d a t i o n p r o t o c o l92 u n s i g n e d c h a r ∗ p _ i n p u t ; / / / < P r o t o c o l i n p u t b u f f e r ( D r i v e r −> P r o t o c o l )93 u n s i g n e d c h a r ∗ p _ o u t p u t ; / / / < P r o t o c o l o u t p u t b u f f e r ( P r o t o c o l −> Device )94 vo id (∗HASPCallback ) ( HASPMessage ) ; / / / < P o i n t e r t o t h e use r−d e f i n e d c a l l b a c k95 ;96 9798 # e n d i f

BIBLIOGRAFÍA

[AGM08] Rafael Achaerandio García and Fernando Maldonado. I estudio anualde idc para la bsa sobre la piratería en españa. In IDC, editor, I EstudioAnual de IDC para la BSA sobre la piratería en España. BSA, 2008.1.1

[AKS] Inc Aladdin Knowledge Systems. Catálogo on-line deproductos aladdin. 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. Lake-view Research. 2.3

[Axe05] Jan Axelson. Usb complete, third edition. In Lakeview Research, edi-tor, USB Complete, Third edition, Madison, WI, USA, 2005. LakeviewResearch. (document), 2.2.1, 5.1, 6.4.1

[CSFBAOSS01] Carlos Cerrada Somolinos, Vicente Feliu Batlle, Antonio Adán Oliver,and José Andrés Somolinos Sánchez. Fundamentos de estructura y tec-nología de computadores. In Editorial Universitaria Ramón Areces, edi-tor, Fundamentos de estructura y tecnología de computadores. EditorialUniversitaria Ramón Areces, 2001. (document), 2.2, 2.1

[Gra05] Joe Grand. Can you really trust hardware? - exploring security pro-blems in hardware devices, 2005. http://grandideastudio.com/wp-content/uploads/trust_slides.pdf. 2.4

[JB] Steve J. Baker. Librería portable para juegos plib. http://plib.

sourceforge.net/. 6.1.3

http://www.aladdin.com/hasp/protection-keys-benefits-models.aspx

http://www.aladdin.com/hasp/protection-keys-benefits-models.aspx

http://grandideastudio.com/wp-content/uploads/trust_slides.pdf

http://grandideastudio.com/wp-content/uploads/trust_slides.pdf

http://plib.sourceforge.net/

http://plib.sourceforge.net/

164 Bibliografía

[MHH+08] J.D. Meier, Alex Homer, David Hill, Jason Taylor, Bansode Prashant,Lonnie Wall, Rob jr Boucher, and Akshay Bogawat. Patterns & practi-ces application architecture guide 2.0, 2008. 6.4.1

[Par] Parallax. Parallax propeller. http://www.parallax.com/

propeller/. 2.3

[Per05] Juan José Perez. Material docente de la asignatura sistemas basados enmicroprocesador. In Universidad de Valencia, editor, Material docentede la asignatura Sistemas Basados en Microprocesador, 2005. 2.3

[ST] ST. Nota de prensa de st microelectronics. http://www.st.com/

stonline/press/news/year2005/p1416h.htm. 2.3

[Ste09] Peter Stephenson. Artículo sobre el aladdin hasp srm, 22009. http://www.scmagazineuk.com/aladdin-hasp-srm/

review/2909/. 2.4

[Tec07] Microchip Technology. Datasheet del pic18f2455/2550/4455/4550. InDatasheet del PIC18F2455/2550/4455/4550, 2007. 5.1, 5.4

[UIa] USB-IF. Programa de cumplimiento de usb-if. http://www.usb.

org/developers/compliance/. 2.2.1

[UIb] USB-IF. Sitio web del usb-if. http://www.usb.org. 2.2.1

[UI01] USB-IF. Especificación de la norma hid 1.11 para dispositivosde interfaz humana, 2001. http://www.usb.org/developers/

devclass_docs/HID1_11.pdf. 6.1.3

http://www.parallax.com/propeller/

http://www.parallax.com/propeller/

http://www.st.com/stonline/press/news/year2005/p1416h.htm

http://www.st.com/stonline/press/news/year2005/p1416h.htm

http://www.scmagazineuk.com/aladdin-hasp-srm/review/2909/

http://www.scmagazineuk.com/aladdin-hasp-srm/review/2909/

http://www.usb.org/developers/compliance/

http://www.usb.org/developers/compliance/

http://www.usb.org

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

d usb hasp hid - muralmural.uv.es/miexsan/pfc/pfc.pdf · bios consejos han jugado un gran papel y a...

Documents