Can Con 18f4580

TRABAJO FINAL DE CARRERA
TTULO DEL TFC : Diseno y construccion de bus de datos y sensores para las I practicas de NACC TITULACION: Ingeniera Tecnica Telecomunicaciones, especialidad Sistemas de Telecomunicacion / Ingeniera Tecnica Aeronautica, especialidad Aeronavegacion AUTORES: Christian Miranda Estepa , Jonathan Ronquillo Guerrero DIRECTOR: Dagoberto Salazar FECHA: 15 de enero de 2008
Ttulo : Diseno y construccion de bus de datos y sensores para las practicas de NACC Autores: Christian Miranda Estepa , Jonathan Ronquillo Guerrero Director: Dagoberto Salazar Fecha: 15 de enero de 2008
Resumen Este trabajo nal de carrera se puede dividir en dos partes. En la primera parte crearemos un nodo (o interface) de comunicaciones que sea capaz de recibir datos mediante diferentes protocolos como SPI, I2C, RS232 y transmitirlo todo a un bus principal (CAN Bus). De esta forma, se podran comunicar diferentes dispositivos sin preocuparnos del protocolo nativo que utilicen. El control de este nodo de comunicaciones se realiza con un microcontrolador PIC18F4580, ya que este se adapta perfectamente a nuestros objetivos. Para implementar la parte software hemos utilizado el compilador CCS y las libreras que se han desarrollado para CAN. Una vez terminada la primera parte, relacionada mas con el area de las comunicaciones, nuestro trabajo se centra en una segunda partei que esta mas relacianda con la instru mentacion para navegacion. En esta parte se desarrolla una placa de adquisicion de datos que incluye unos sensores que proporcionan informacion de inclinacion, aceleracion y velocidad angular. La idea general es conectar nuestra placa de sensores con otros dispositivos (elabora dos, por ejemplo, por companeros en otros TFC) utilizando los nodos de comunicaciones en CANBus, y as poder utilizar multiples dispositivos en las practicas de la asignatura Navegacion Aerea, Cartografa y Cosmografa (NACC).
Title : Design and construction of a data bus and sensors for the NACC practices Authors: Christian Miranda Estepa , Jonathan Ronquillo Guerrero Director: Dagoberto Salazar Date: January 15, 2008
Overview This nal Project can be divided into two parts. In the rst one we will create a communications node (or interface) able to receive data through different protocols like SPI, I2C, RS232 and able to transmit all the information to a main bus (CAN bus). This way, different Devices will be able to communicate without worrying about the protocol being used. The control of this communication node is carried out by a PIC18f4580 microcontroller because it suits perfectly to our objectives. In order to implement the software part, we have used the CCS compiler and its libraries, developed for CAN. Once the rst part (the communications one) is nished, our work gets focused on the second part (the one related with navigation instrumentation). An acquisition data plate is developed including sensors which give information of slope, acceleration and angular velocity. The general idea is to connect our plate of sensors with other devices (for instance, devices built by other realized by TFC students) using the communication nodes in CANBus, and then we will be able to use multiple devices in laboratory work of the subject Navegacion Aerea, Cartograa y Cosmograa (NACC).
En el plano emocional este trabajo va dedicado a nuestros padres por su paciencia y comprension. En el plano tecnico queremos agradecer, sobre todo, a nuestro tutor Dagoberto Salazar por su seguimiento en el trabajo y sus consejos, y a Oscar Casas por su ayuda con la placa de pruebas de CANBus y el compilador CCS.
NDICE GENERAL I
INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAPTULO 1. Conceptos Teoricos . . . . . . . . . . . . . . . . . . . . . I
1.1. Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1. PIC (Peripheral Interface Controller) . . . . . . . . . . . . . . . . . 1.1.2. CAN (Controller Area Network) . . . . . . . . . . . . . . . . . . . . 1.1.3. RS232 (Recommended Standard 232) . . . . . . . . . . . . . . . . 1.1.4. I2C (Inter-Integrated Circuit) . . . . . . . . . . . . . . . . . . . . . . 1.1.5. SPI (Serial Peripheral Interface) . . . . . . . . . . . . . . . . . . . . 1.2. Placa de adquisicion de datos . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. PIC18F2580 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. MEMS (Micro Electro-Mechanical Systems) . . . . . . . . . . . . . 1.2.3. Sistema Inercial . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3
3 3 7 13 15 18 20 20 22 34
CAPTULO 2. Metodologa I
. . . . . . . . . . . . . . . . . . . . . . . . . . 37 37 41 43 51 66 67 71
2.1. Protocolo CAN utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Placa de Adquisicion de Datos . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CAPTULO 3. Experimentos I
. . . . . . . . . . . . . . . . . . . . . . . . . 79 79 80 80 86 88 90 90
3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Nodo de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. RS232-CAN-RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. I2C-CAN-RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3. SPI-CAN-RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Placa de adquisicion de datos . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Recepcion de datos de un solo ADIS16100 . . . . . . . . . . . . . .
3.3.2. Recepcion de datos de la Placa de Adquisicion de Datos por bus CAN 94
3.4. Experimento nal: Placa Adquisicion de Datos, PC y GPS con otro PC monitorizando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
CAPTULO 4. Conclusiones y Recomendaciones . . . . . . . . . . . 113 I SIGLAS Y ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . 117 BIBLIOGRAFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 I APENDICE A. Codigo implementado
. . . . . . . . . . . . . . . . . . . 121
A.1. Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 A.1.1. tfc.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 A.1.2. funciones.c A.1.3. funciones.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 . . . . . . . . . . . . . . . . . . . . . . . . 136
A.2. Placa de Adquisicion de Datos
A.2.1. adquisicion datos.c . . . . . . . . . . . . . . . . . . . . . . . . . . 136 A.2.2. funciones adis.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 A.2.3. funciones adis.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 A.3. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 A.3.1. experimentos spi.c A.3.3. experimentos i2c.c . . . . . . . . . . . . . . . . . . . . . . . . . . 147 . . . . . . . . . . . . . . . . . . . . . . . . . . 152 A.3.2. experimentos spi modo2.c . . . . . . . . . . . . . . . . . . . . . . 150
A.4. experimentos i2c modo2.c . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 A.5. experimento solo 1 adis.c . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
APENDICE B. Diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . 161

B.1. tfc.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 B.2. adquisicion datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
APENDICE C. Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

C.1. Nodo de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 C.2. Placa de adquisicion de datos . . . . . . . . . . . . . . . . . . . . . . . . . 170
APENDICE D. Problemas en Datasheet del ADIS16100
. . . . . . . 173
APENDICE E. Lista de componentes y presupuesto del proyecto. 175 APENDICE F. Estudio previo. Ejercicios de familiarizacion con el protocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . 179
F.1. Utilizando el software de desarrollo (IDE) Familiarizacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 F.2. Primeros pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 F.3. PIC18F4580 como transmisor y MCP25050 para outputs . . . . . . . . . . 181 F.4. MCP25050 para inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 F.5. MCP250XX para entradas analogicas . . . . . . . . . . . . . . . . . . . . . 187
NDICE DE FIGURAS I
1.1 Componentes que conguran un microcontrolador . . . . . . . 1.2 Mercado mundial de los PICs . . . . . . . . . . . . . . . . . . 1.3 Diagrama de pines del PIC 18F4580 . . . . . . . . . . . . . . . 1.4 Ejemplo de envo de paquete en CAN . . . . . . . . . . . . . . 1.5 Velocidad del bus CAN en funcion de la longitud . . . . . . . . . 1.6 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Modelo Niveles de tension utilizados en CAN . . . . . . . . . . 1.8 Formato estandar y extendido de las tramas CAN. . . . . . . . 1.9 Campos de las tramas CAN . . . . . . . . . . . . . . . . . . . 1.10Ejemplo de arbitracion en CAN . . . . . . . . . . . . . . . . . . 1.11Conectores DB-25 y DB-9 en RS232. . . . . . . . . . . . . . . 1.12Conguracion 7N1 del RS232. . . . . . . . . . . . . . . . . . . 1.13Esquema de conexion del bus I2C. . . . . . . . . . . . . . . . . 1.14Condicion de inicio del I2C. . . . . . . . . . . . . . . . . . . . . 1.15Condicion de parada del I2C. . . . . . . . . . . . . . . . . . . . 1.16Ejemplo de comunicacion I2C. . . . . . . . . . . . . . . . . . . 1.17Conexion del CS de SPI a los diferentes dispositivos. . . . . . . 1.18Desplazamiento de bits en Esclavo SPI. . . . . . . . . . . . . . 1.19Ejemplo de comunicacion SPI. . . . . . . . . . . . . . . . . . . 1.20Diagrama de pines del PIC 18F2580 . . . . . . . . . . . . . . . 1.21Diagrama de bloques del ADIS16100. . . . . . . . . . . . . . . 1.22La senal del ADIS16100 incrementa con el angulo de giro. . . . 1.23Diagrama de secuencia de conguracion/lectura en ADIS16100. 1.24Diagrama de secuencia SPI en ADIS16100. . . . . . . . . . . . 1.25Diagrama de bloques del ADIS16201. . . . . . . . . . . . . . . 1.26Disposicion de los pines del ADIS16201. . . . . . . . . . . . . 1.27Posibles orientaciones del ADIS16201. . . . . . . . . . . . . . 1.28Escritura-Lectura del ADIS16201. . . . . . . . . . . . . . . . . 1.29Registros DIN/DOUT del ADIS16201. . . . . . . . . . . . . . . 1.30Los tres ejes de movimiento de una aeronave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 6 8 9 9 10 11 11 12 15 15 16 17 17 18 19 20 20 21 23 23 26 27 30 31 31 32 32 34 37 39 43 44 44 45 45 46 47 48 48 49 49
2.1 Campo ID dividido en 3 sub-campos. . . . . . . . . . . . . . . . . 2.2 Tipos de mensaje en el protocolo CAN. . . . . . . . . . . . . . . . 2.3 Diagrama esquematico. Nodo de Comunicaciones. . . . . . . . . . 2.4 Polarizacion del conector de alimentacion. . . . . . . . . . . . . . . 2.5 Bloque de alimentacion del Nodo de Comunicaciones. . . . . . . . 2.6 Bloque del clock del Nodo de Comunicaciones. . . . . . . . . . . . 2.7 Conector RJ12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Bloque de programacion del Nodo de Comunicaciones. . . . . . . . 2.9 Bloque de comunicaciones del Nodo de Comunicaciones. . . . . . 2.10Conguracion MAX232. . . . . . . . . . . . . . . . . . . . . . . . 2.11Pines del PCA82C251. . . . . . . . . . . . . . . . . . . . . . . . . 2.12Interruptores activacion/desactivacion de las resistencias PULL-UP. 2.13Terminales de conexiones externas del Nodo de Comunicaciones. .
2.14Cable NULL-MODEM - Cable directo. . . . . . . . . . . . . . . . . . . . . . . 2.15PCB del Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . 2.16Programador ICD utilizado a la hora de programar. . . . . . . . . . . . . . . . 2.17Esquema ujo de datos en INT CANRX0. . . . . . . . . . . . . . . . . . . . . 2.18Esquema ujo de datos en INT SSP. . . . . . . . . . . . . . . . . . . . . . . . 2.19Esquema ujo de datos en INT RDA. . . . . . . . . . . . . . . . . . . . . . . 2.20Jerarqua de los cheros utilizados en Nodo de Comunicaciones. . . . . . . . . 2.21Diagrama de ujo del modulo Conguracion Nodo de Comunicaciones. . . . . 2.22Diagrama de ujo del modulo Interrupcion Interruptores. . . . . . . . . . . . . 2.23Diagrama de ujo del modulo Interrupcion CAN. . . . . . . . . . . . . . . . . 2.24Distribucion de los dos bytes con informacion del ID. . . . . . . . . . . . . . . 2.25Diagrama de ujo del modulo Procesado de Datos CAN. . . . . . . . . . . . . 2.26Diagrama de ujo del modulo Interrupcion I2C y SPI. . . . . . . . . . . . . . . 2.27Diagrama de ujo del modulo Interrupcion RS232. . . . . . . . . . . . . . . . 2.28Diagrama esquematico. Placa de Adquisicion de Datos. . . . . . . . . . . . . . 2.29M1117t alimentacion ADIS16201 a 3,3 V y condensadores de 10 F. . . . . . . 2.30Bloque de programacion. Resistencias de 1 k. . . . . . . . . . . . . . . . . . 2.31Diagrama esquematico de la tarjeta y sus conexiones al conector estandar dual row de 2mm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.32Esquema de la disposicion de los sensores en la placa. . . . . . . . . . . . . . 2.33Ejemplo de envo de 16 bits por SPI. . . . . . . . . . . . . . . . . . . . . . . . 2.34Jerarqua de los cheros utilizados en la Placa de Adquisicion de Datos. . . . . 2.35Diagrama de ujo del modulo Conguracion Placa Adquisicion de Datos. . . . 2.36Diagrama de ujo del modulo Interrupcion RDA en ADIS16201. . . . . . . . . 2.37Protocolo NMEA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.38Diagrama de ujo del modulo Pedido y Envio de Datos en ADIS16201. . . . . 3.1 Conguracion HyperTerminal. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Interruptor RS232 en ON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Esquema montaje experimentos RS232-CAN-RS232. . . . . . . . . . . . . . . 3.4 Montaje experimentos RS232-CAN-RS232. . . . . . . . . . . . . . . . . . . . 3.5 Resultado de las pruebas 1 a la 13. . . . . . . . . . . . . . . . . . . . . . . . 3.6 Esquema: Ejemplo de la distribucion de IDs entre 3 PCs. . . . . . . . . . . . . 3.7 Interruptor I2C en ON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Esquema montaje experimentos I2C-CAN-RS232. . . . . . . . . . . . . . . . 3.9 Interruptor SPI en ON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10Esquema montaje experimentos SPI-CAN-RS232. . . . . . . . . . . . . . . . 3.11Resultados de temperatura en Offset Binary del primer ADIS16100. . . . . . . 3.12Resultados de temperatura en Complemento a 2 del primer ADIS16100. . . . . 3.13Resultados de velocidad angular en Offset Binary del primer ADIS16100. . . . 3.14Resultados de velocidad angular en Complemento a 2 del primer ADIS16100. . 3.15Resultados de temperatura en Offset Binary del segundo ADIS16100. . . . . . 3.16Resultados de temperatura en Complemento a 2 del segundo ADIS16100. . . . 3.17Resultados de velocidad angular en Offset Binary del segundo ADIS16100. . . 3.18Resultados de velocidad angular en Complemento a 2 del segundo ADIS16100. 3.19Esquema del experimento Recepcion de datos de la Placa de Adquisicion. . . 3.20Resultados a los 8 pedidos posibles desde el PC. . . . . . . . . . . . . . . . . 3.21GPS utilizado en el experimento. . . . . . . . . . . . . . . . . . . . . . . . . .
50 52 53 54 55 55 56 59 60 61 62 63 65 66 67 68 69 70 71 72 74 75 76 77 78 81 82 83 84 85 86 87 88 89 90 92 93 94 95 96 97 98 99 100 101 102
3.22Esquema de conexion de los pines UserTerminal. . . . . . . . . . . . . . 3.23Montaje del experimento nal. . . . . . . . . . . . . . . . . . . . . . . . 3.24Resultado al conectar el GPS. . . . . . . . . . . . . . . . . . . . . . . . 3.25Resultado al conectar el GPS y la placa de adquisicion de datos. . . . . . 3.26Resultado al conectar el GPS, la placa de adquisicion de datos y otro PC. B.1 Simbolos utilizados en el diagrama de ujo. . . . . . . . . . . . . . . . B.2 Diagrama de ujo del modulo Conguracion Nodo de Comunicaciones. B.3 Diagrama de ujo del modulo Interrupcion Interruptores. . . . . . . . . B.4 Diagrama de ujo del modulo Interrupcion CAN. . . . . . . . . . . . . B.5 Diagrama de ujo del modulo Procesado Datos CAN. . . . . . . . . . B.6 Diagrama de ujo del modulo Interrupcion I2C y SPI. . . . . . . . . . . B.7 Diagrama de ujo del modulo Interrupcion RS232. . . . . . . . . . . . B.8 Diagrama de ujo del modulo Conguracion Placa Adquisicion de Datos. B.9 Diagrama de ujo del modulo Interrupcion RDA en ADIS16201. . . . . . B.10Diagrama de ujo del modulo Pedido y envio de datos en ADIS16201. . C.1 C.2 C.3 C.4 C.5 C.6 C.7 Capa top del Layout del nodo de comunicacion. . . . . . . . . . . . . Capa bottom del Layout del nodo de comunicacion. . . . . . . . . . . Layout con las capas top y bottom del nodo de comunicacion. . . . . Capa top del Layout de la placa de adquisicion de datos. . . . . . . . Capa bottom del Layout de la placa de adquisicion de datos. . . . . . Layout con las capas top y bottom de la placa de adquisicion de datos. Layout placa acopladora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
106 108 109 110 111 161 161 162 162 163 164 164 165 165 166 167 168 169 170 171 172 172
D.1 Tabla con los diferentes modos de trabajo de SPI en el PIC18F2580. . . . . . . 174 F.1 F.2 F.3 F.4 F.5 F.6 F.7 F.8 F.9 Asociacion LEDs con los puertos RB del PIC Ejercicio 2. . . . . . . . . . . . . . . . . . . Registro del MCP25050. . . . . . . . . . . . Codigo a anadir en la librera ccscana.c. . . Resultado del ejercicio anterior . . . . . . . . Registros del MCP25050. . . . . . . . . . . LEDs del nodo C. . . . . . . . . . . . . . . . Codigo del ejercicio hecho por nosotros. . . . Codigo del ejercicio del potenciometro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 182 182 183 184 185 187 188 189
NDICE DE TABLAS I
1.1 Conguracion de condensadores segun el reloj . . . . . . . . . . . . . . . 1.2 Puertos y pines utilizados en el PIC18F4580 . . . . . . . . . . . . . . . . 1.3 Senales mas comunes en RS232 y sus respectivos pines en los conectores. 1.4 Puertos y pines utilizados en el PIC18F2580 . . . . . . . . . . . . . . . . 1.5 Especicaciones mas importantes del ADIS16100. . . . . . . . . . . . . . 1.6 Descripcion de los pines del ADIS16100. . . . . . . . . . . . . . . . . . . 1.7 Tabla de pruebas del ADIS16100. . . . . . . . . . . . . . . . . . . . . . . 1.8 Descripcion de la asignacion de bits en el registro DIN. . . . . . . . . . . . 1.9 Descripcion de la asignacion de bits en el registro DOUT. . . . . . . . . . . 1.10Ejemplos de datos de salida del ADIS16100. . . . . . . . . . . . . . . . . 1.11Especicaciones mas importantes del ADIS16201. . . . . . . . . . . . . . 1.12Descripcion de los pines del ADIS16201. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 14 21 24 25 25 27 28 29 33 33
2.1 Identicadores asociados a los mensajes utilizados en la Placa de Adquisicion de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Tabla de aceptacion de mensajes de la Placa de Adquisicion de Datos. . . . . 2.3 Caractersticas si la tabla de aceptacion esta en el Nodo de Comunicaciones. . 2.4 Caractersticas si la tabla de aceptacion esta en el Dispositivo. . . . . . . . . . 2.5 Otros Transceivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Conguracion interruptores de seleccion de protocolos. . . . . . . . . . . . . .
41 42 42 42 49 50
E.1 Lista de precios componentes nodo. . . . . . . . . . . . . . . . . . . . . . . . 176 E.2 Lista de precios componentes placa de adquisicion. . . . . . . . . . . . . . . . 177
INTRODUCCION
En la asignatura Navegacion Aerea, Cartografa y Cosmografa (NACC) se pretende incluir practicas en la que los alumnos puedan ver el funcionamiento de un sistema de navegacion. La nalidad de un sistema de navegacion es poder determinar la ruta seguida por el vehculo y en consecuencia, guiarlo de manera adecuada. Este sistema de navegacion estara formado por dos elementos, el GPS (Global Positio ning System) y el INS (Inertial Navigation System). La combinacion de estos dos disposi tivos se denomina INS/GPS. En estas practicas se pretende monitorizar todos los datos recibidos por estos dos sensores y transmitirlos a una estacion central, como por ejemplo un PC. De esta forma, y procesando los datos de forma correcta, se podra obtener la in formacion necesaria para determinar la ruta seguida y proporcionar la actitud del vehculo. El objetivo de este trabajo nal de carrera es doble: En una primera parte se disena un nodo de comunicaciones capaz de hacer de interfaz entre dispositivos que hablan en RS232, SPI o I2C, y un bus general de comunicaciones llamado Bus CAN. En la segunda parte se disena una placa electronica en la que se integran dos inclinometros/acelerome tros, y dos giroscopos. La primera parte del trabajo la dividimos en tres subpartes (una subparte por cada protocolo a utilizar) en la que realizamos diferentes experimentos. Para hacer estos experimentos implementamos dos nodos de comunicaciones de prueba en dos protoboards (prototipos). Al tener los dos prototipos pudimos probar la comunicacion RS232-CANRS232, SPI-CAN-SPI y I2C-CAN-I2C. Lo que se pretenda en cada subparte era obtener una comunicacion entre los nodos de comunicacion. Una vez comprobado el correcto funcionamiento de los prototipos se elaboraron los dispositivos denitivos. La nalidad de la segunda parte es la de recoger informacion sobre inclinacion, acelera cion y velocidad angular de los sensores para enviarla posteriormente al nodo de comuni caciones mediante RS232, y despues enviarla al bus general por CAN. De esta forma se podra emular un INS (solo faltara el procesado nal que se realizara en otro modulo). La prueba nal consiste en unir, a traves del bus CAN controlado por los nodos de comu nicacion, nuestra placa de adquisicion de datos, un GPS y dos PC. En uno de estos PC se monitorizaran todos los datos. La distribucion de esta memoria es la siguiente: Un primer captulo donde se explican los conceptos teoricos mas importantes para poder entender el trabajo, y que servira de introduccion a los siguientes captulos.
En el segundo captulo se presenta la metodologa utilizada para poder desarrollar

este proyecto: Que hemos hecho y como lo hemos hecho.
El tercer captulo consiste en presentar las diferentes pruebas realizadas en las dos
placas electronicas para comprobar su correcto funcionamiento.
Para nalizar encontraremos un apartado con las conclusiones obtenidas de los

experimentos realizados.
Diseno y construccion de bus de datos y sensores para las practicas de NACC
En los anexos se encontrara el material de soporte adicional.
Conceptos Teoricos
CAPTULO 1. CONCEPTOS TEORICOS I

El objetivo de este captulo es ofrecer una introduccion a los aspectos teoricos mas rele vantes a lo largo de esta memoria. Creemos que son utiles y necesarios para un correcto seguimiento del trabajo, y as no llevar al lector la confusion o la duda. En primer lugar, en la seccion 1.1., se describen los conceptos teoricos de la primera parte del proyecto (nodo de comunicaciones). Hemos considerado importante destacar tanto el funcionamiento del corazon de la placa (el PIC18F4580) como los protocolos a utilizar. En la seccion 1.2. se describen los conceptos teoricos de la placa de adquisicion de datos disenada. En primer lugar se explican los MEMS y el PIC utilizado y seguidamente se describe el concepto de Sistema Inercial.
1.1. Nodo de Comunicaciones

1.1.1. PIC (Peripheral Interface Controller)
Los PIC son una familia de microcontroladores (C) fabricados por Microchip Tecnhno logy Inc. Para el control de todos los procesos en nuestra placa electronica escogimos este tipo de C debido a su bajo precio, sencillo manejo y programacion, y a la cantidad de documentacion y usuarios que hay detras de ellos. Aunque no son los C que mas prestaciones ofrecen, sus caractersticas se ajustan perfectamente a nuestro proyecto. Existe una gran cantidad de modelos de PIC con caractersticas y prestaciones diferentes. Esto hace que el desarrollador pueda escoger el modelo que mas se ajuste a sus necesidades. Para que el PIC pueda realizar sus funciones lo primero que se ha de hacer es programarlo, es decir, hemos de escribir un programa que contenga los procesos que el PIC deba ejecutar. Este programa se puede escribir en varios lenguajes de programacion, pero los mas utilizados son el Assembler (ensamblador) y el C. Aun faltara un ultimo paso para que el PIC pueda entender lo que hemos escrito. Este ultimo paso es traducir este progra ma a lenguaje maquina (1s y 0s). Gracias a los compiladores este proceso es bastante directo. En este trabajo nal de carrera hemos programado en C y el compilador utilizado es el proporcionado por la empresa CCS (Custom Computer Services, Inc.). Como todo C, un PIC se puede dividir en diferentes bloques (Ver la gura 1.1);
Reloj: Todos los PIC disponen de un circuito oscilador que genera una onda cuadrada de alta frecuencia que se utiliza para sincronizar todas las operaciones del sistema. El PIC tiene un oscilador interno incorporado, y en funcion de la velocidad de trabajo con la que queramos trabajar utilizaremos este oscilador (velocidades mas bajas) o un oscilador externo (velocidades altas) como por ejemplo cristal de cuarzo, resonador ceramico1 o una red R-C. Aumentar la frecuencia del reloj im1
Cristal de cuarzo de baja frecuencia (800kHz).
Figura 1.1: Componentes que conguran un microcontrolador plica disminuir el tiempo de ejecucion de las instrucciones, pero lleva aparejado un incremento de la temperatura.
I/O (In/Out): La mayora de los pines que posee un PIC son de I/O y se destinan a
proporcionar el soporte a las senales de entrada, salida y de control.
CPU: Es el elemento que interpreta las instrucciones y procesa los datos en los
programas del PIC.
Memoria de datos: Los datos que manejan los programas varan continuamente, y
esto exige que la memoria que los contiene debe ser de escritura y de lectura, por lo que la memoria RAM (Random Access Memory) es la mas adecuada, aunque sea volatil. Tambien se dispone de una memoria de lectura y escritura no volatil, del tipo EEPROM (Electrically-Erasable Programmable Read-Only Memory). De esta forma, un corte en el suministro de la alimentacion no ocasiona la perdida de la informa cion, que esta disponible al reiniciarse el programa. Memoria de programas: El PIC esta disenado para que en su memoria de pro grama se almacenen todas las instrucciones del programa de control. Como este siempre es el mismo, debe estar grabado de forma permanente. Existen varios tipos de memoria adecuados para soportar estas funciones, de las cuales en los PIC se utilizan la ROM (Read-Only Memory), OTP (One-Time Programmable) y Flash. Perifericos: Se llama perifericos a todas aquellas unidades a traves de las cuales el PIC se comunica con el mundo exterior. En los PIC podemos encontrar ADC (Analog to Digital Converter), comparadores, temporizadores, y perifericos destinados a las comunicaciones como los siguientes; EUSART (Enhanced Universal Synchronous Asynchronous Receiver Transmitter): Interfaz entrada salida serie. Con este modulo podemos transformar los datos en serie a paralelo y al reves. De esta forma se pueden adaptar los datos con los que trabaja el PIC (en paralelo) con los que le pueden llegar a traves de este puerto (serie). Es el utilizado por el protocolo RS232. USB (Universal Serial Bus): Permite operar con el protocolo USB.
Conceptos Teoricos
MSSP (Master Synchronous Serial Port): Es una interfaz serie integrada en el PIC disenada para comunicarse con otros perifericos o C. Permite operar con los protocolos I2C y SPI. CAN (Controller Area Network): Permite operar con el protocolo CAN. PSP (Parallel Slave Port): Interfaz para conectar dos C mediante niveles TTL (Transistor-Transistor Logic). CCP/ECCP (Enhanced Capture/Compare/PWM): Modulo que se puede utilizar como comparador, como capturador o como PWM (Pulse-Width Modulation). Para nalizar creemos importante destacar que los proyectos en los que se suelen trabajar con PICs pueden ser muy variados, por ejemplo la automocion, la industria, informatica, comunicaciones, etc (Ver la gura 1.2).
Figura 1.2: Mercado mundial de los PICs
1.1.1.1. PIC18F4580 Una vez vistas las caractersticas generales de los PIC, nos hace falta conocer las es pecicaciones del PIC a utilizar en nuestro diseno. El PIC elegido para este trabajo es el PIC18F4580 ya que puede soportar los 3 modulos necesarios (EUSART, MSSP y CAN) para trabajar con los 4 protocolos (RS232, SPI, I2C y CAN). Este PIC tiene 40 pines que se distribuyen como se muestra en la gura 1.3. Las caractersticas mas importantes son las siguientes: Reloj: Ofrece varias opciones de conguracion de la frecuencia de oscilacion, permitiendo al usuario escoger segun se adapte a sus necesidades: Utilizando un cristal o un resonador ceramico y conectandolos a los pines OSC1 y OSC2 del PIC. Para la eleccion de la frecuencia de oscilacion, el fabricante nos ofrece unas tablas2 (Ver la tabla 1.1);
2
XT corresponde a Crystal/Resonator, HS a High-Speed Crystal/Resonator y LP a Low-Power Crystal.
Figura 1.3: Diagrama de pines del PIC 18F4580 Resonadores Ceramicos Modo XT HS Frecuencia 455kHz 2MHz 4MHz 8MHz 16MHz OSC1 56pF 47pF 33pF 27pF 22pF OSC2 56pF 47pF 33pF 27pF 22pF Modo LP XT HS Osciladores de cristal Frecuencia 32kHz 200kHz 1MHz 4MHz 4MHz 8MHz 20MHz OSC1 33pF 15pF 33pF 27pF 27pF 22pF 15pF OSC2 33pF 15pF 33pF 27pF 27pF 22pF 15pF
Tabla 1.1: Conguracion de condensadores segun el reloj
Los condensadores elegidos van del pin OSC1 o OSC2 a 0V (GND). En el diseno de nuestra placa hemos escogido como frecuencia de oscilacion 20 MHz. Utilizando relojes externos, ofreciendo la opcion de utilizar dos pines del PIC (OSC1 y OSC2) o solo un pin (OSC1). Utilizando un oscilador externo RC con la misma opcion de conguracion de pi nes que en el caso anterior. Un oscilador RC esta formado por un condensador no polarizado y una resistencia. Este tipo de oscilador proporciona una esta bilidad mediocre en la frecuencia generada y podra ser utilizado para aquellos proyectos que no requieran precision. Utilizando un oscilador interno. Este metodo se suele utilizar en los casos que se quieran aprovechar los pines OSC1 y OSC2 como I/O. Utilizando un multiplicador de frecuencia PLL (Phase Lock Loop). Gracias al PLL y utilizando el oscilador interno, el usuario puede disponer de una selec cion de frecuencias entre 31kHz y 32MHz.
I/O: En este PIC hay 5 puertos diferentes (A, B, C, D y E). Cada puerto tiene tres
registros para sus operaciones que son el TRIS (registro de direccion de datos), el PORT (el que lee el nivel de tension que hay en el pin) y el LAT (utilizado en operaciones lectura-modicacion-escritura del valor que el pin I/O esta leyendo). En la tabla 1.2 se muestran por cada puerto los pines que se han utilizado.
Conceptos Teoricos
Pin 4, 5 y 6 13 y 14 37, 38 y 39 35 y 36 38, 39 y 40 18 25 y 26 23 23 y 24
Funcionalidad Puerto A LEDs Reloj Puerto B Interruptores CAN Para programar el PIC Puerto C Reloj I2C y SPI Datos RS232 Datos I2C Datos SPI Puerto D No utilizado Puerto E Para programar el PIC y para RESET
Tabla 1.2: Puertos y pines utilizados en el PIC18F4580
Memoria de datos: Tiene 1536 bytes de memoria RAM y 256 bytes de EEPROM. Memoria de programa: Tiene 32 kbytes de memoria Flash.
Perifericos: En el PIC18F4580 podemos encontrar 11 ADC de 10 bits, dos modulos CCP/ECCP, MSSP para I2C y SPI, EUSART, dos comparadores, 4 temporizadores (uno de 8 bits y tres de 16 bits) y un modulo CAN.
1.1.2. CAN (Controller Area Network)

El bus CAN es un bus de datos de comunicacion serie, empleado para su aplicacion en sistemas distribuidos en tiempo real. Originalmente el bus CAN fue desarrollado para aplicaciones en la industria automotriz, pero debido a sus caractersticas, robustez y excelente relacion calidad/precio, CAN fue adoptado para aplicaciones industriales y de control. El protocolo de comunicacion CAN fue especicado originalmente por la compana alemana Robert Bosch para aplicaciones crticas en tiempo real. Los motivos principales que nos han llevado a la eleccion de este protocolo son las siguientes:
Tratamiento de errores muy ecaz. Es un protocolo muy robusto frente a los proble mas de ruido, ya que fue disenado para entornos industriales.
Es un sistema que se ha ido adaptando a otros campos, lo que ha hecho que su
uso se haya extendido. Por ello, su coste es bajo frente al coste de otros posibles sistemas. Posibilidad de implementacion con dispositivos relativamente simples y baratos como por ejemplo los PICs que usamos.
Facilidad de desarrollo y gran cantidad de fabricantes en el mercado de dispositivos

CAN.
Su sistema de prioridades no destructivo, que permite que en caso de que se

transmitan dos mensajes simultaneamente, el de mayor prioridad no se destruya y llegue a su destino sin ningun tipo de retardo anadido. Su sistema de identicacion de mensajes, que consiste en que los nodos no tienen realmente una direccion, sino que se programan con un sistema de ltros para que acepten un determinado tipo de mensajes (Ver la gura 1.4), es decir, es un sistema basado en tipos de mensajes, no en direcciones, lo que hace que se puedan anadir nuevos nodos sin tener que recongurar el resto de los nodos.
Figura 1.4: Ejemplo de envo de paquete en CAN Su comportamiento en tiempo real: El metodo empleado por el protocolo CAN asocia cada mensaje a ser enviado con una prioridad determinada, y usa un mecanismo especial de arbitraje para asegurar que el mensaje de mayor prioridad sea el mensaje transmitido. La prioridad de un mensaje es un numero unico y puede ser usado como el identicador del mensaje. Es por eso que a la prioridad se le denomina tambien identicador del mensaje. En cuanto a inconvenientes:
Protocolo complejo. Velocidad limitada por la longitud de la red (Ver la gura 1.5), aunque en este trabajo
no inuye demasiado como para tenerlo en cuenta. Segun el estandar, la velocidad maxima que puede alcanzar el bus CAN es de 1Mbps y esta se puede alcanzar hasta con una longitud de red de 40 metros. En el marco de nuestro proyecto esto no nos afecta.
Conceptos Teoricos
Figura 1.5: Velocidad del bus CAN en funcion de la longitud Para el desarrollo de nuestra red CAN nos vamos a basar en el estandar ISO 11898 (Organizacion Internacional para la Estandarizacion), en aspectos concretos del protocolo de nodos, etc. CAN como son los niveles del bus, implementacion Dado que el protocolo CAN solo dene dos niveles del Modelo OSI (Ver la gura 1.6), es necesario que se dena tambien un nivel alto de aplicacion, del que hablaremos en el apartado 2.1..
Figura 1.6: Modelo OSI
1.1.2.1. Capa Fsica Se denen los parametros a nivel fsico (niveles de senal, corriente, sincronizacion, etc.). CAN no tiene declarada una especicacion como tal, pero los estandares ISO 11898 establecen las caractersticas que deben de cumplir las aplicaciones para la transferencia en alta y baja velocidad. La informacion circula por dos cables trenzados que unen todas las unidades de control que forman el sistema. Esta informacion se trasmite por diferencia de tension entre los dos cables, de forma que un valor alto de tension representa un 1 y un valor bajo de tension representa un 0. La combinacion adecuada de unos y ceros conforman el mensaje a trasmitir. En un cable los valores de tension oscilan entre 0 V y 2.25 V, por lo que se denomina cable L (Low), y el otro cable, llamado cable H (High) tiene niveles de tension entre 2.75
10
V y 5 V (Ver la gura 1.7). En caso de que se interrumpa la lnea H o que se derive a masa, el sistema trabajara con la senal de Low con respecto a masa. En el caso de que se interrumpa la lnea L, ocurrira lo contrario. Esta situacion permite que el sistema siga trabajando con uno de los cables cortados o comunicados a masa, quedando fuera de servicio solamente cuando ambos cables se cortan.
Figura 1.7: Modelo Niveles de tension utilizados en CAN El valor dominante en el bus CAN se produce cuando tenemos el bit 0 mientras que el valor recesivo se produce con el bit a 1. Es importante tener en cuenta que el trenzado entre ambas lneas sirve para anular los campos magneticos, por lo que no se debe modicar en ningun caso ni el paso ni la longitud de dichos cables.
1.1.2.2. Capa de enlace de datos (LLC y MAC) La MAC (Media Access Control) es la responsable de: Tipo de trama que se enva: Para la transmision y control de mensajes CAN se denen cuatro tipos de tramas: De datos, remota (transmitido por una unidad de bus que requiere la transmision de una trama de datos con el mismo identicador), de error (transmitido por cualquier unidad que detecta un error en el bus), y de sobrecarga (usado para dar un retraso extra entre las tramas de datos y remotas). Tanto las tramas de datos y las tramas remotas tienen dos formatos. Un formato es el llamado Estandar y el otro es el Extendido, y se diferencian en el numero de bits que tiene el identicador (la estandar tiene 11 bits y la extendida tiene 29 bits) (Ver la gura 1.8). Las tramas de datos y las remotas se separan de tramas precedentes mediante espacios entre tramas (interframe space). Dentro de las tramas de datos y remotas podemos encontrarnos con diferentes campos (Ver la gura 1.9): Inicio de trama: consiste en un bit a 0.
Conceptos Teoricos
11
Figura 1.8: Formato estandar y extendido de las tramas CAN. Campo de arbitracion: campo donde se introduce el identicador. Campo de control: campo donde se indica la longitud de los datos. Campo de datos: campo donde se introducen los datos (como maximo 8 bytes). Campo CRC: campo de comprobacion de errores. Campo ACK: Consta de dos bits en recesivos. Fin de trama: consiste en 7 bits recesivos.
Figura 1.9: Campos de las tramas CAN La unica diferencia entre la trama de datos y la trama remota es que esta ultima no contiene el campo de datos. Arbitracion: Cuando el bus esta idle (libre), cualquier unidad puede transmitir un mensaje. Si dos o mas dispositivos quieren transmitir mensajes al mismo tiempo, el
12
conicto de quien accedera al bus sera resuelto por el arbitro utilizando el identi cador. Este mecanismo garantiza que no se pierde informacion ni tampoco tiempo. En el caso de una trama de datos y una remota con el mismo identicador, la trama de datos prevalece sobre la trama remota. Durante la arbitracion cada transmisor compara el nivel del bit transmitido con el que monitoriza el bus: Si esos niveles son iguales continua enviando, si son diferentes y lo que hemos enviado es un bit recesivo 1 y monitorizamos un bit dominante 0, la unidad habra perdido la arbitracion y debera dejar de transmitir (Ver la gura 1.10).
Figura 1.10: Ejemplo de arbitracion en CAN
ACK: Un receptor que recibe un mensaje correctamente se lo notica al transmisor

poniendo el bit del campo ACK a 0 (dominante), de forma que el transmisor que esta todava trasmitiendo reconoce que al menos alguien ha recibido un mensaje escrito correctamente. De no ser as, el transmisor interpreta que su mensaje pre senta un error. Detectar errores: En cuanto a la deteccion y manejo de errores, un controlador CAN cuenta con la capacidad de detectar y manejar los errores que surjan en una red. Todo error detectado por un nodo se notica inmediatamente al resto de los nodos. Denir el metodo de acceso: El metodo de acceso al medio utilizado es el de Acceso Multiple por Deteccion de Portadora, con Deteccion de Colisiones y Arbitra je por Prioridad de Mensaje (CSMA/CD+AMP, Carrier Sense Multiple Access with Collision Detection and Arbitration Message Priority). De acuerdo con este metodo, los nodos en la red que necesitan transmitir infor deben esperar a que el bus este libre (deteccion de portadora). Cuando se macion cumple esta condicion, dichos nodos transmiten un bit de inicio (acceso multiple). Cada nodo lee el bus bit a bit durante la transmision de la trama y comparan el valor transmitido con el valor recibido; mientras los valores sean identicos, el nodo continua con la transmision; si se detecta una diferencia en los valores de los bits, se lleva a cabo el mecanismo de arbitraje.
La LLC (Logical Link Control) es la capa que esta relacionada con;
Filtrado de mensajes: Como hemos comentado anteriormente, los dispositivos no

tienen realmente una direccion, sino que se programan con un sistema de ltros para que acepten un determinado tipo de mensajes
Conceptos Teoricos
13
Proceso de solucion de errores (reenvo): El protocolo CAN tiene cinco metodos de repaso de errores, tres en el nivel de mensaje y dos en el nivel del bit. Si un mensaje tiene alguno de estos errores, no se aceptara y se generara una trama de error para que el resto de los nodos no hagan caso del mensaje defectuoso, y para que el nodo que transmite vuelva a enviar el mensaje.
1.1.2.3. Capa de supervisor Un sistema de bus serie presenta el problema de que un nodo defectuoso puede bloquear el funcionamiento del sistema completo. Cada nodo activo transmite una bandera de error cuando detecta algun tipo de error y puede ocasionar que un nodo defectuoso pueda acaparar el medio fsico. Para eliminar este riesgo el protocolo CAN dene un mecanismo autonomo para detectar y desconectar un nodo defectuoso del bus. Dicho mecanismo se conoce como aislamiento de fallos o Fault Connement.
1.1.2.4. Capa de aplicacion Existen diferentes estandares que denen la capa de aplicacion; algunos son muy espe ccos y estan relacionados con sus campos de aplicacion. Entre las capas de aplicacion mas utilizadas cabe mencionar CAL, CANopen, DeviceNet, SDS (Smart Distributed System), OSEK y CANKingdom. En nuestro trabajo crearemos nuestra propia capa de aplicacion (Ver apartado 2.1.).
1.1.3. RS232 (Recommended Standard 232)

Ante la gran variedad de equipos, sistemas y protocolos que existen surgio la necesidad de un acuerdo que permitiera a los equipos de varios fabricantes comunicarse entre si. La EIA (Electronics Industry Association) elaboro la norma RS-232, la cual dene la interfaz mecanica, los pines, las senales y los protocolos que debe cumplir la comunicacion serial. El RS232 es un protocolo de comunicacion serie orientado a caracteres, es decir, un protocolo donde toda la informacion es enviada por un solo canal bit a bit (un canal para y otro para recibirla), y donde lo que se envan son caracteres. Por enviar informacion ejemplo, si queremos enviar el numero 123, primero tendremos que enviar el caracter 1, seguidamente el 2 y para nalizar el 3, y no el byte que represente el numero 123. Este protocolo esta disenado para distancias cortas, de unos 15 metros mas o menos, y se puede trabajar de forma asncrona o sncrona y con tipos de canal simplex, halfduplex y fullduplex3 .
Una canal simplex consiste en una comunicacion unidireccional, deshabilitando la respuesta del recep tor. Un canal halfduplex permite la comunicacion en ambos sentidos pero no simultaneamente, mientras
3
14
Una conexion RS232 esta denida por un cable desde un dispositivo al otro. Hay 25 co nexiones en la especicacion completa pero en la mayora de los casos se utilizan menos de la mitad. Los conectores mas utilizados son los DB9 y los DB25 (Ver la gura 1.11). En la tabla 1.3 se puede observar las senales mas comunes en RS232 segun los pines del conector asignados:
GND: Valor a 0V. TD: Lnea de datos del transmisor al receptor. RD: Lnea de datos del receptor al transmisor.
DTR: Lnea por donde el receptor informa al transmisor que esta vivo y bien. DSR: Lnea por donde el transmisor informa al receptor que esta vivo y bien.
RTS: Lnea en la que el transmisor indica que quiere enviar algo al receptor.
CTS: Lnea en la que se informa que el receptor esta preparado para recibir datos.
DCD: Lnea por la que el receptor informa al transmisor que tiene una portadora
entrante.
RI: Lnea en la que se indica que se ha detectado una portadora.

Senal GND Transmision de datos (TD) Recepcion de datos (RD) Terminal de datos preparado (DTR) Datos preparados (DSR) Peticion de envo (RTS) Limpieza de envo (CTS) Portadora de datos detectada (DCD) Indicador de tono (RI) DB-25 7 2 3 20 6 4 5 8 22 DB-9 5 3 2 4 6 7 8 1 9
Tabla 1.3: Senales mas comunes en RS232 y sus respectivos pines en los conectores. La conexion mas sencilla se puede realizar con 3 cables (TD, RD, y GND). En nuestro trabajo utilizaremos esta conguracion de 3 cables. Los parametros a congurar en una comunicacion RS232 son los siguientes:
Protocolo serie (numero de bits - paridad - bits de parada): La paridad se utiliza

para poder comprobar la calidad de los datos recibidos. Los bits de datos pueden estar entre los 5 bits y los 8, y los bits de parada consisten en uno o dos bits puestos a 1. En la gura 1.12 se muestra una conguracion 7N1.
que un canal fullduplex permite una comunicacion bidireccional simultanea.
Conceptos Teoricos
15
Figura 1.11: Conectores DB-25 y DB-9 en RS232. En nuestro trabajo utilizaremos la conguracion 8N1 (8 bits de datos sin paridad y con un bit de parada).
Velocidad del puerto: RS232 puede transmitir los datos a unas velocidades determinadas (normalmente entre 4800 y 115200 bps).
Protocolo de control de ujo: El control de ujo puede ser mediante hardware gracias al llamado handshaking entre las lneas RTS y CTS, o por software mediante 4 el XON/XOFF . En nuestro proyecto no utilizaremos control de ujo.
Figura 1.12: Conguracion 7N1 del RS232.
1.1.4. I2C (Inter-Integrated Circuit)

I2C es un bus bidireccional de dos hilos desarrollado por Philips. Su nalidad principal es la de poder facilitar las comunicaciones entre dispositivos pequenos, como por ejemplo entre PICs y memorias EEPROM.
1.1.4.1. Descripcion del bus Sus caractersticas mas relevantes se pueden resumir en los siguientes puntos:
En el XON/XOFF, cuando el receptor quiere que el transmisor pare su envo de datos enva XOFF, mientras que cuando el receptor quiere que el transmisor enve mas datos, enva XON.
4
16
Esta formado fsicamente por dos hilos, el SDA (Serial Data) y el SCL (Serial Clo ck). Estos dos hilos son los que forman en su totalidad el bus y en ellos se conectan todos los dispositivos como se puede observar en la gura 1.13. Por lo tanto, es un protocolo Halfduplex.
Figura 1.13: Esquema de conexion del bus I2C. Todos los dispositivos tienen una direccion propia, que hay que indicar al inicio de la conexion para poder establecerla. Por lo tanto, a diferencia del bus CAN, es un sistema basado en direcciones y no en tipos de mensajes. En funcion de si se envan o se reciben datos, se deben considerar los dispositivos como Maestros (Master) o esclavos (Slaves). El primer dispositivo que encuentre libre el bus, y por lo tanto inicie la comunicacion y controle el reloj, sera el Master, mientras que los demas seran Slaves.
Es un bus serial, de 8 bits, bidireccional y a diferencia del RS232 no es orientado a

caracteres.
Debido a que es un bus Multimaster5 , puede darse el caso en el que varios dispositivos necesiten acceder al medio al mismo tiempo. Para controlar estas situaciones existe un sistema de arbitraje. Este sistema determina, mediante el SCL y el nivel logico del mismo hilo, que dispositivo tendra prioridad sobre el otro. El numero de dispositivos que pueden conectarse al bus esta limitado, de forma que este no supere los 400 pF de capacitancia. Puede trabajar a 100 kbps (modo estandar), 400 kbps (modo rapido) o 3,4 Mbps (modo de alta velocidad). En nuestro software utilizaremos el modo rapido. Tanto el SDA como el SCL estan conectados a unas resistencias de carga llamadas resistencias pull-up. Estas resistencias polarizan las lneas, de forma que cuando el bus esta libre (idle), se encuentre a nivel alto (1 logico) y este estable.
1.1.4.2. Funcionamiento del bus Los pasos a seguir en una comunicacion master-slave desde que se quiere enviar datos hasta que se reciben los datos es la siguiente:
5
Mas de un master puede controlar el bus al mismo tiempo sin corrupcion de los mensajes.
Conceptos Teoricos
17
1. Si un dispositivo necesita establecer comunicacion con otro, debera comprobar que el bus esta libre. 2. Se enva la condicion de INICIO (Ver la gura 1.14) para ocupar el bus. Entonces el resto de dispositivos escuchan el SDA, por el cual se enva la direccion de 7 bits del dispositivo receptor. De esta forma se establece el enlace entre Maestro y Esclavo.
Figura 1.14: Condicion de inicio del I2C. 3. Al mismo tiempo en el SCL se transmite la senal del reloj que sincronizara el tiempo de envo de los bytes por el SDA de los dispositivos, de forma que se puedan leer correctamente los datos del SDA cuando el SCL cambia del nivel bajo al nivel alto (lectura en el anco de subida). 4. Una vez enviados los 7 bits de la direccion se enva un octavo bit que indicara si estamos en modo escritura o lectura en el dispositivo receptor. Este bit es el denominado bit R/W. 5. El master espera un ACK6 por parte del esclavo. 6. Seguidamente en funcion de si estamos en modo lectura o escritura, el master o el esclavo enviaran paquetes de 8 bits. Despues de cada paquete se enviara un ACK para conrmar la correcta transferencia de datos. 7. Una vez enviados todos los datos se establece la condicion de parada, que vol vera al bus el estado libre (Ver la gura 1.15).
Figura 1.15: Condicion de parada del I2C. En la gura 1.16 se presenta un ejemplo de como se realiza la comunicacion con el protocolo I2C.
6
Mensaje que se enva para conrmar que un mensaje o un conjunto de mensajes han llegado
18
Figura 1.16: Ejemplo de comunicacion I2C.
1.1.5. SPI (Serial Peripheral Interface)

El SPI es un bus fullduplex, sncrono y serial desarrollado por Motorola. Tambien puede encontrarse con el nombre de Microwire, propiedad de National SemiConductors. Al ser un bus serial su numero de hilos es reducido en comparacion a los buses paralelos. Si bien estos ultimos son mas rapidos, la eciencia y simplicidad que un bus serial puede ofrecer hace que esta diferencia de velocidad sea menos importante.
1.1.5.1. Descripcion del bus SPI es un bus que establece la comunicacion entre master y esclavo mediante 4 tipos de hilos que contiene senales diferentes:
MISO, Master In/Slave Out. Esta lnea es una de las dos lneas unidireccionales.
A traves de esta lnea se realiza la transmision de datos de forma unidireccional desde la salida del Esclavo a la entrada del Maestro. Cuando el dispositivo no ha sido seleccionado para la comunicacion, esta lnea es puesta en un estado de alta impedancia para evitar interferencias.
MOSI, Master Out/Slave In. Esta lnea es la segunda de las dos lneas unidirec
cionales. A traves de esta lnea se realiza la transmision de datos de forma unidi reccional desde la salida del master a la entrada del esclavo. El dispositivo master pone los datos sobre la lnea MOSI medio ciclo antes del nal del anco de alta impedancia para evitar interferencias. SCLK, Es el reloj del bus con el que los dispositivos sincronizaran el ujo de datos a traves de las lneas. Se pueden congurar 2 parametros que denen 4 modos de sincronizacion. Estos parametros son: CPOL (Clock polarity): Determina si el estado IDLE de la lnea SCLK es en nivel bajo (CPOL = 0) o en nivel alto (CPOL = 1). No tiene efecto signicativo en el formato de transferencia.
Conceptos Teoricos
19
CPHA (Clock Phase): Determina en cual anco del reloj los datos son ledos o escritos. Si CPHA = 0 los datos sobre la lnea MOSI son puestos en el primer anco de reloj y los datos sobre la lnea MISO son ledos en el segundo anco de reloj. Cuando CPHA = 1 sucede lo contrario, la transferencia de datos sucede en el segundo anco de reloj. Por lo tanto, segun como se combinen estos dos parametros, tendremos 4 modos diferentes de trabajo. Es muy importante que todos los dispositivos dentro del bus trabajen con el mismo modo.
CS o SS, Chip select o Slave Select. Los dispositivos en SPI no se seleccionan por
software utilizando direcciones, como ocurre en I2C. En este protocolo es necesario utilizar una lnea mas llamada Chip Select, (CS) o Select Slave (SS). De forma que si estamos utilizando 3 dispositivos, el bus estara compuesto por 2 hilos de transmision de datos, 1 de reloj y 3 de CS como se puede observar en la gura 1.17. Si solo se utiliza un Master y un Esclavo como en el caso de nuestro nodo de comunicaciones, las lneas CS no seran necesarias.
Figura 1.17: Conexion del CS de SPI a los diferentes dispositivos.
1.1.5.2. Funcionamiento del bus Cuando se la establece comunicacion, el bus solo puede ser ocupado por un Master y un Esclavo. Cualquier dispositivo que no haya sido seleccionado debera deshabilitarse por medio del chip select para evitar interferencia. La seleccion de los dispositivos es muy sencilla: El master pone a nivel logico bajo 0 el chip select del dispositivo en cuestion. El resto pasan a modo de alta impedancia para no interferir la comunicacion. A partir de este momento se inicia la comunicacion entre los de inicio de I2C. dispositivos. Es algo parecido a la condicion
20
Una vez seleccionados los dispositivos, los datos pueden ser transferidos hasta una ve locidad maxima de varios MHz (Mbps). En los PICs que vamos a utilizar, la velocidad maxima es de 5 Mbps (con un clock de 20 MHz), aunque nosotros utilizaremos una velocidad de 1,25 Mbps. Durante la transferencia SPI, los datos son transmitidos y recibidos simultaneamente por cada una de las lneas MISO y MOSI. Esto ocurre porque los datos entrantes en el Esclavo avanzan en un registro interno de forma que cuando se recibe el byte entero, los datos salen por la lnea SDO (Ver la gura 1.18). La lnea SDO en el esclavo corresponde a la lnea MISO comentada anteriormente, mientras que la SDI en el esclavo corresponde a la lnea MOSI.
Figura 1.18: Desplazamiento de bits en Esclavo SPI. En la gura 1.19 se puede ver el formato de transferencia del bus SPI.
Figura 1.19: Ejemplo de comunicacion SPI.
1.2. Placa de adquisicion de datos

1.2.1. PIC18F2580
El PIC elegido para la placa de adquisicion de datos es el PIC18F2580. Este PIC tambien puede soportar los 2 modulos necesarios (EUSART, MSSP) para trabajar con los 2 proto-
Conceptos Teoricos
21
colos a utilizar (RS232, SPI). La diferencia con el PIC18F4580 es que tiene menos puertos I/O y menos memoria RAM y Flash. Como no se utilizaran todos los puertos I/O, el codigo no necesita de grandes memorias RAM y Flash, y ademas el tamano del PIC18F2580 es mas pequeno, por lo que se adapta perfectamente al diseno de la placa de adquisicion de datos.
Figura 1.20: Diagrama de pines del PIC 18F2580 Las caractersticas mas importantes son las siguientes:
Reloj: Como en el caso del PIC18F4580, hemos seleccionado un oscilador externo

de 20 MHz mediante un cristal de cuarzo.
I/O: En este PIC hay 4 puertos diferentes (A, B, C y E). En la tabla 1.4 se muestran
por cada puerto los pines que se han utilizado. Pin 3 9 y 10 26, 27 y 28 18 25 y 26 23 y 24 1 Funcionalidad Puerto A LED Reloj Puerto B Para programar el PIC Puerto C Reloj SPI Datos RS232 Datos SPI Puerto E Para programar el PIC y para RESET
Tabla 1.4: Puertos y pines utilizados en el PIC18F2580
Memoria de datos: Tiene 768 bytes de memoria RAM y 256 bytes de EEPROM.
22
Memoria de programa: Tiene 16 kbytes de memoria Flash.

Perifericos: En el PIC18F2580 podemos encontrar 11 ADC de 10 bits, dos modulos CCP/ECCP, MSSP para I2C y SPI, EUSART, dos comparadores, 4 temporizadores (uno de 8 bits y tres de 16 bits) y un modulo CAN.
1.2.2. MEMS (Micro Electro-Mechanical Systems)

Las siglas de MEMS provienen de las palabras en ingles Micro Electro-Mechanical Sys tems que hacen referencia al tipo de tecnologa electromecanica micrometrica que se utilizan en algunos circuitos integrados (IC). En estos se integran, encima de un sustrato, sensores, actuadores y elementos electronicos de medidas que van desde los micrometros a los milmetros. Los MEMS han conseguido eliminar la diferencia entre los complejos dispositivos meca nicos y los circuitos electronicos, juntandolos en un mismo sustrato de forma que, lo que a macroescala es grande y costoso, a la escala de los MEMS es mas practico y barato. Gracias a su tamano y su precio, los campos tecnologicos en los que los MEMS se utilizan son muy variados: Automocion: Acelerometros en vehculos para hacer saltar el airbag. Sensores de presion para activar los sistemas de suspension. Giroscopos MEMS para detectar giros como en el sistema de control de esta bilidad dinamico.
Medicina y biotecnologa:
Sensores de presion para medir la presion sangunea. Circuitos integrados que ayudan a mejorar las prestaciones microscopicas, qumica y agentes biologicos. microchips para detectar la contaminacion Comunicaciones e informatica: Impresoras de inyeccion de tinta, las cuales usan un piezoelectrico o burbuja de inyeccion para depositar la tinta en el papel. Desarrollo de material electronico compatible a altas frecuencias haciendo que el tamano total del circuito, consumo y coste nal se reduzca, al mismo tiempo que la eciencia para investigaciones de microondas aumenta. Tecnologa optica de conmutacion, utilizada para comunicacion de datos. El unico problema que acarrean estos sistemas micro electromecanicos es la fabricacion, puesto que es necesario modicar la tecnologa de fabricacion convencional para conse guir reducir algunos efectos que a escala macroscopica son despreciables. Algunos de estos efectos son termicos y electrostaticos.
Conceptos Teoricos
23
En este TFC trabajaremos con unos circuitos integrados MEMS, el ADIS 16100 y el 16201 fabricados con tecnologa MST.
1.2.2.1. ADIS16100 El ADIS 16100, esta formado como se puede ver en la gura 1.21, por un giroscopo que 7 puede llegar a detectar un giro de guinada del MEMS en el rango de 300o /s, por un termometro, un convertidor ADC y un modulo de SPI que sera con el que se realice la lectura a traves del puerto de salida DOUT.
Figura 1.21: Diagrama de bloques del ADIS16100. Los datos de salida del SPI (en el puerto DOUT) van en funcion de la tasa de giro sobre el eje z (Ver la gura 1.22)8 . Como hemos comentado anteriormente, los valores maximos o o que podra detectar seran de -300 /s si gira en sentido antihorario o +300 /s si gira en sentido horario.
Figura 1.22: La senal del ADIS16100 incrementa con el angulo de giro. En el ADIS16100 se incluye un convertidor ADC interno. Este convertidor realiza la con version de analogico a digital de la temperatura y de la tasa de giro. Ademas, tiene unas
Giro sobre el eje z LSB (Least Signicant Bit) es el bit que tiene menos peso dentro de un numero. Es decir, es el bit que proporciona el cambio mas pequeno en cualquier valor si es cambiado.
8 7
24
entradas analogicas, AIN1 y AIN2, que nos permiten digitalizar cualquier otro tipo de in formacion analogica que se conecte. En el datasheet del ADIS16100 se pueden observar todas las caractersticas, bloques de diagramas, especicaciones y las tpicas respuestas de actuacion. Para nuestro TFC necesitaremos tener en cuenta y conocer primordialmente las caractersticas mas esen o ciales mostradas en la tabla 1.5 (Especicaciones a Ta = 25 C, Vcc = 5 V, tasa de giro = 0o /s y Cout = 0 F). Parametro Alimentacion Sensibilidad Resolucion AD Input Tiempo de conversion Null (Initial) Lectura termometro Rango del termometro Condicion Para Ta = -40 C a 85 C @25o C 16 ciclos de reloj a 20 MHz Nominal 0o /sec output es 2048 LSB Ta = 298o K
o o
Min 3,68
Typ 5 4,1 12
Max 4,52 800 +37
Units V LSB/o /s bits ns o /sec LSB o C
-42 2048 -40 a 85
Tabla 1.5: Especicaciones mas importantes del ADIS16100. Un punto a tener muy en cuenta es nuestra carga electrostatica. El cuerpo humano puede acumular cargas superiores a los 4000 V y descargarlas sin darnos cuenta sobre el dis positivo. Por esta razon es muy importante tocar con las manos a tierra durante un par de segundos para descargarnos y as no cortocircuitar ningun componente. El ADIS16100 tiene 16 pines con los que podemos congurarlo y obtener los datos nece sarios. En la tabla 1.6 se muestra la disposicion de los pines y su funcionamiento. Como caractersticas de funcionamiento principales podemos destacar las siguientes: Los giroscopos utilizan unos resonadores electroestaticos que se alimentan a 14 16 V para trabajar correctamente. La alimentacion de los componente se hace a 5 V y es por ello que dentro del chip encontramos un elevador de tension para alimentar los resonadores. Una vez obtenidos los datos analogicos de temperatura o de tasa de giro, estos son muestreados en el AD para despues transmitirlos por SPI. Para ello la senal se ltra pasando por dos etapas. La primera de estas etapas se encuentra justo despues de la salida del giroscopo, donde hay un polo que ltra las frecuencias altas. De esta forma evitamos los cambios bruscos justo antes de la amplicacion nal. En la segunda etapa se calibra, a traves del condensador Cout, la respuesta frecuencial del sistema cuyo ltro paso bajo esta pre-congurado a 40 Hz. Para reducir el ancho de banda, y por consecuente la respuesta frecuencial, se ha de congurar un ltro paso bajo con la ayuda de una resistencia interna, ROUT, y de un condensador externo en el puerto, COUT, como se puede ver en la gura 1.21.
El rango de medidas del ADIS16100 es congurable. Podemos incrementar el mar gen dinamico unicamente anadiendo una resistencia externa entre los pines RATE
Conceptos Teoricos
25
Pin 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Abreviatura DIN SCLK DOUT NC RATE FILT
Descripcion Data In del SPI. Se lee en los ancos de bajada del SCLK, para escribir en registros de control. Clock para comunicaciones y conversiones Salida del SPI. Cambia cada anco de bajada del SCLK Nada Salida de datos analogicos que representa la tasa de giro del ADIS Regulador de respuesta frecuencial y ancho de banda conectando un condensador Alimentacion, puede ser a +3 V o +5 V Entrada analogica 1 Entrada analogica 2 Alimentacion tierra Vref a 2.5 V Boton test 2 Boton test 1 Alimentacion Nada Chip Select del SPI
Vdrive
AIN1 AIN2 COM
Vre f
ST2 ST1
Vcc
NC
CS
Tabla 1.6: Descripcion de los pines del ADIS16100.
y FILT. Esta resistencia cambia la impedancia del chip ya que al conectarla en esos puertos lo que estamos haciendo es conectarla en paralelo con la resistencia inter na ROUT de 180 K. Por ejemplo si conectasemos una resistencia de 330 K en los pines RATE y FILT se obtendra un incremento de rango de un 50 %. El valor mnimo que se permite conectar es de 45 K. Las fuentes de alimentacion pueden variar el comportamiento de precision y estabilidad del sensor. Por ello el ADIS16100 lleva unos condensadores desacopladores de 0,2 F en el Vcc , por lo que en el diseno nal no necesitaremos ningun tipo de impedancia de decoupling.
Existen unos botones el ST1 y ST2 en los pines 13 y 12 que nos ayudan a probar
el correcto funcionamiento del sensor. Esto es muy importante, ya que en muchos momentos del diseno de la placa, es util conocer en cual estado esta nuestro sensor. Las pruebas consisten en excitar los sensores electromecanicos y obtener unos valores en el DOUT, la salida del SPI (Ver la tabla 1.7). Pruebas Pulsando ST1 Pulsando ST2 Pulsando ST1 y ST2 Resultado en el DOUT -221 LSB 221 LSB NULL
Tabla 1.7: Tabla de pruebas del ADIS16100.
26
En cuanto a la comunicacion entre el ADIS16100 y un dispositivo de control (en nuestro caso un PIC), como ya se ha dicho unas lineas mas arriba se utiliza el protocolo SPI. Esta comunicacion cumple las mismas especicaciones que hay en el captulo 1.1.5., y 9 concretamente se trata del modo 2 o modo C (CPHA = 0 y CPOL = 1) . Por ello, para iniciar la transferencia de datos el CS ha de estar a nivel logico 0, el SCLK tendra como libre el nivel alto y los cambios de datos en los buffers se realizaran en los ancos de bajada. El ADIS16100 por su parte incorpora unas funciones, READ y WRITE, que facilitan la comunicacion con el resto de dispositivos. Mas adelante, en el captulo 2.3.2., se explica como se ha de congurar por software el PIC para realizar adecuadamente la comunicacion con este dispositivo. Las comunicaciones entre el PIC y el ADIS, que se encuentra permanentemente a la escucha del registro de entrada de datos (DIN), se realizan a traves de comandos de 16 bits. Una vez el dispositivo ha sido seleccionado a traves del CS, se inicia la comunicacion y cuando se han recibido los 16 bits, el chip lee los datos y los procesa. En funcion del codigo recibido, realizara unas operaciones u otras, que comentaremos a continuacion.
Figura 1.23: Diagrama de secuencia de conguracion/lectura en ADIS16100. En funcion del codigo recibido en el DIN, el ADIS simplemente contestara con un paquete de datos (datos que corresponden a una conguracion previa) o sera recongurado, para que en la siguiente iteracion responda datos de la nueva conguracion. Como nota muy importante, a la hora de esperar las respuestas del ADIS hay que de cir que solo responde cuando se le enva un comando, sea de lectura o conguracion, y siempre que es recongurado, contestara con la nueva conguracion un comando des pues y no en el mismo comando en el que esta siendo congurado. Con esto vemos que sera necesario un segundo comando para realizar una lectura de la nueva conguracion despues de haber enviado un comando de conguracion (ver gura 1.23). Como se puede ver en la tabla 1.8, se tratara de un comando de conguracion o de simple lectura de datos en funcion del bit 15 (WRITE) del DIN. Si lo ponemos en 0, el comando sera de lectura y el ADIS respondera un paquete de 16 bits. En cambio, si el bit 15 o WRITE es 1, accederemos al registro de control del ADIS16100 y podremos congurar su modo de trabajo. Su conguracion estara determinada por el resto de bits que hemos enviado en ese mismo comando (ver gura 1.24, DIN). Los datos de salida siempre siguen el mismo patron. Los dos primeros bits siempre es El fabricante proporciona un manual donde se indica cual modo SPI es necesario para la comunicacion con los dispositivos de control (Modo 2 o Modo C). En la practica este modo que proporciona el fabricante es incorrecto, y para comunicar el ADIS16100 con un PIC como el utilizado en este TFC es necesario utilizar el modo 1 o modo B (CPHA = 0 y CPOL = 0)
9
Conceptos Teoricos
27
Bit No 15
Abreviatura WRITE
Funcionalidad 1: Vuelca el contenido de DIN al registro de control, y se recongura el modo de trabajo del chip. 0: No se producen cambios en el registro de control y el ADIS16100 responde con la conguracion que dispone. Estado bajo, 0 para funcionamiento normal. Dont care, no intervienen. Modo de trabajo: 00: Salida giroscopo 01: Salida temperatura 10: Entrada analogica 1 11: Entrada analogica 1 Estado alto,1 para funcionamiento normal. Dont care, no intervienen. Estado bajo, 0 para funcionamiento normal. Formato de los datos de salida: 0: complemento a dos 1: Offset binario Dont care, no intervienen.
14 13, 12 11, 10
0 D/C ADD1 ADD0
9, 8 7, 6 5 4
1 D/C 0 CODE
3 al 0
D/C
Tabla 1.8: Descripcion de la asignacion de bits en el registro DIN.
Figura 1.24: Diagrama de secuencia SPI en ADIS16100. taran a 0, seguidamente se enviaran el ADD1 y el ADD0, y para nalizar, los datos (Ver tabla 1.9). Siguiendo la tabla 1.8 vemos que una serie de bits siempre tendran valores constantes independientemente de la conguracion que se precise: Los bits 14 y 5 deberan estar siempre a nivel bajo, 0 para una funcionalidad correcta del chip. Los bits 9 y 8 deberan estar siempre a nivel alto 1. Los bits 13-12, 7-6 y del 3 al 0 no tendran importancia en ningun momento y se podran establecer como 1 o 0; por ello a lo largo de este documento estos bits se mostraran sin valor y seran representados por una x. (Dont care bits, DC).
En cambio, habra otros bits que seran los que varen, y que estableceran el tipo de salida y el formato de los datos:
28
Bit No 15, 14 13, 12
Abreviatura 0 ADD1 ADD0
Funcionalidad Siempre a 0. Modo de trabajo: 00: Salida giroscopo 01: Salida temperatura 10: Entrada analogica 1 11: Entrada analogica 1 Datos.
11-0
D11-D0
Tabla 1.9: Descripcion de la asignacion de bits en el registro DOUT.
Los bits 11 y 10, ADD1 y ADD0 determinan el modo de trabajo del chip. El bit 4 CODE determina el formato de salida de los datos.
A continuacion se expone un ejemplo de conguracion y comunicacion. Para este caso el objetivo es obtener datos de temperatura en offset y giroscopo en complemento a dos. Para ello seguiremos los siguientes pasos: Primero ir a la tabla 1.8 y escoger una combinacion de bits con la cual el ADIS16100 quede congurado como datos de temperatura en formato offset. Para ello tendre mos que tener una combinacion en la cual: El bit 15 ha de ser 1 (escritura). El bit 14 ha de ser 0. Los bits 13 y 12 pueden ser tanto 0 como 1, X. Los bits 11 y 10 establecen el modo de trabajo Temperatura: ADD1= 0, ADD0=1. Los bits 9 y 8 han de ser 1. Los bits 7 y 6 han de ser X. El bit 5 ha de ser 0. El bit 4 establece el formato de datos, CODE = 1. Los bits 3-0 han de valer X. Por lo que en denitiva tendremos: 10xx0111xx01xxxx.
Enviamos un paquete con la secuencia de bits anterior. Debido al funcionamiento del ADIS16100, los datos que recibamos en esa misma
iteracion no corresponderan a lo que acabamos de congurar. Por ello, tendremos que volver a enviar otro paquete de forma que recibamos los datos de temperatura en offset. Los bits que enviaremos en esta iteracion, al tratarse de una lectura del chip, pueden ser los mismos que los de conguracion, solo que esta vez el bit 15, WRITE, ha de ser 0 para no entrar en el registro de control.
Conceptos Teoricos
29
Una vez realizada la lectura de temperatura, procedemos a la lectura del giroscopo en formato complemento a dos. Para llevar a cabo satisfactoriamente esta operacion debemos volver a congurar el ADIS igual que lo hemos hecho para la temperatura, solo que esta vez la secuencia de bits sera: 10xx0011xx00xxxx, cambiando el modo de trabajo y el formato de los datos de salida a giroscopo en complemento a dos10 . Al igual que para leer la temperatura despues de la conguracion, para leer los datos de la nueva conguracion volvemos a enviar un paquete de datos cambiando el bit 15 a 0, obteniendo la siguiente cadena de bits: 00xx0011xx00xxxx. Una vez realizada la lectura, si queremos obtener otro tipo de informacion debe mos realizar los mismos pasos. Cambiaremos la conguracion (con WRITE = 1) y seguidamente realizaremos la lectura deseada (con WRITE = 0).
Para facilitar la comprension del funcionamiento de los registros DOUT, mostraremos la tabla 1.10 con ejemplos de posibles datos proporcionados por los sensores.
o
/s
Codigo
Patron Binario
Velocidad Angular en Complemento a Dos 0,2439 1 0000000000000001 0 0 0000000000000000 -0,2439 -1 0000111111111111 Velocidad Angular en Offset Binary 0,2439 2049 0000100000000001 0 2048 0000100000000000 -0,2439 2047 0000011111111111 Temperatura en Complemento a Dos 25,1453 1 0001000000000001 25 0 0001000000000000 24,8547 -1 0001111111111111 Temperatura en Offset Binary 25,1453 2049 0001100000000001 25 2048 0001100000000000 24,8547 2047 0001011111111111 Tabla 1.10: Ejemplos de datos de salida del ADIS16100.
1.2.2.2. ADIS16201 El ADIS 16201 es un MEMS que nos proporciona medidas de aceleraciones, inclinaciones y temperatura de manera simultanea, a traves de unas lneas SPI. Ademas, nos permite calibrar de forma rapida y barata los sensores digitales que incorpora.
En esta iteracion, los datos recibidos del chip seran los referentes a la conguracion previa, que en este caso es la temperatura en formato offset.
10
30
Este chip incorpora una diferencia en tecnologa respecto el anterior, el ADIS16100, ya que tiene una serie de caractersticas que ayudan a realizar de forma mas facil el trabajo sin necesidad de incluir hardware. Algunas de las caractersticas que lo hacen diferente son: Una funcion de alarma congurable.
Un ADC de 12 bits. Un DAC de 12 bits. Puertos I/O congurables.

Posibilidad de controlar la alimentacion y el modo Sleep a traves del SPI.
El esquema de bloques del ADIS16201 se puede ver en la gura 1.25.
Figura 1.25: Diagrama de bloques del ADIS16201. Al igual que el ADIS16100, en el datasheet podemos encontrar todas las caractersticas del MEMS, pero para nuestro TFC nos interesan las de la tabla 1.11 (Especicaciones a Ta = -40o C a 125o C, Vdd = 3,3 V y tilt = 0). El ADIS16201 tiene 16 pines con los que podremos congurarlo y obtener los datos ne cesarios. En la tabla 1.12 se muestra la disposicion de los pines y su funcionamiento. A la hora de situar el MEMS en la placa nal, se ha de tener en cuenta su posicion para poder realizar las lecturas de inclinaciones y aceleraciones de forma correcta. Teniendo en cuenta que la gravedad es negativa y queremos que este en el eje y, la posicion en la que se debe colocar el MEMS debe ser la que esta mas a la izquierda en la gura 1.27 . El funcionamiento del ADIS16201 es similar al del ADIS16100. Por medio de los puertos DIN y DOUT se hacen las transmisiones de datos, con la diferencia que en el ADIS16201
Conceptos Teoricos
31
Figura 1.26: Disposicion de los pines del ADIS16201.
Figura 1.27: Posibles orientaciones del ADIS16201.
32
cada registro de cola del SPI DOUT tiene una direccion (un address) y un formato asig nado que conlleva a una funcion especca. Para mostrar datos de salida, se requiere previamente una lectura de un comando a traves del registro DIN. Por lo tanto, para obtener la informacion deseada se necesitan 2 ciclos de 16 bits. En el primer ciclo se transmite la direccion del registro, el address, para localizar el tipo de datos que nos piden. En el segundo estan los datos de lectura (Ver la gura 1.28). De este modo, en vez de ir congurando que tipo de lecturas queremos (como en el caso del ADIS16100), en el ADIS16201 cuando enviemos un address este nos respondera en la siguiente iteracion con un tipo de dato especco.
Figura 1.28: Escritura-Lectura del ADIS16201.
El registro DIN esta compuesto por 16 bits, de los que 6 son para la lectura del comando (del A0 al A5), otro nos indica si estamos accediendo o no al registro de control (W/R) y los ultimos 8 bits no importa que valor tengan (Ver gura 1.29).
Figura 1.29: Registros DIN/DOUT del ADIS16201. El registro DOUT tiene 16 bits (Ver gura 1.29): El ND (new data ready) se pone a 1 cuando algun registro ha sido actualizado, el EA (indicador de alarma) y los bits de datos (del D0 al D13). En los bits de datos se ha de destacar que para informacion de aceleracion se utilizaran los 14 bits en complemento a 2, en cambio, para el resto de informacion se utilizan 12 bits despreciando los bits D12 y D13. puede ver detalladamente cada uno de los registros de lectura de comandos.
Conceptos Teoricos
33
Parametro Rango de entrada Sensibilidad Offset
Condicion Inclinometro
Min
Typ
Max
Units
o
70 70 y T=25 C
o o
a 25o C Acelerometro o Sensibilidad a 25 C 2,140 2,162 Offset a 25o C y 0 g 8151 8192 Respuesta frecuencial del acelerometro BW del sensor 2250 Frecuencia de resonancia 5,5 Termometro Salida a 25o C 1278 Factor de escala -2,13 ADC Resolucion 12 Ganancia de error 2 DAC Resolucion 12 Ganancia de error 0,5 Conversiones Mnimo tiempo de conversion 244 Maximo tiempo de conversion 484
9,9 2037
10 2048
10,1 2059 2,184 8233
LSB/o LSB LSB/mg LSB Hz kHz LSB LSB/o C bits LSB bits
% s
ms
Tabla 1.11: Especicaciones mas importantes del ADIS16201.
Pin 1 2 3 4 5,6 7,11 8, 10 9 12 13 14 15 16
Abreviatura SCLK DOUT DIN
Descripcion Clock para comunicaciones y conversiones Salida del SPI. Cambia cada anco de bajada del SCLK Data In del SPI. Se lee en los ancos de SUBIDA del SCLK, para escribir en registros de control. Chip Select. Activo en nivel logico bajo 0. Pines I/O. No conectado Conexiones a tierra. Reset, activo a nivel bajo Salida de voltaje analogico auxiliar para el DAC. Alimentacion a +3.3 V Entrada de voltaje analogico auxiliar para el ADC Salida de voltaje de referencia preciso. Comun del circuito.
CS
DIO0,DIO1 NC AUX COM
RST
AUX DAC VDD AUX ADC
Vre f
COM
Tabla 1.12: Descripcion de los pines del ADIS16201.
34
1.2.3. Sistema Inercial

Los Sistemas de Navegacion Inercial consisten en una plataforma estabilizada con girosco pos, tambien llamada Unidad de medidas inerciales (IMU, en ingles). Esta plataforma sirve de marco de referencia que, combinada con una serie de algoritmos y mecanismos de control, nos permiten la establecer un sistema de guiado inercial. Esta plataforma obtiene medidas de la aceleracion del vehculo en los tres ejes del espacio mediante tres acelerometros embarcados sobre la plataforma inercial. Por otro lado, la tasa de giro en los 3 ejes (Ver la gura 1.30) las obtiene de 3 giroscopos.
Figura 1.30: Los tres ejes de movimiento de una aeronave. A partir de estas medidas, el sistema puede calcular por un lado la velocidad del vehculo mediante una integracion (Ecuacion 1.1), la posicion del vehculo con una doble integra cion (Ecuacion 1.2), y a partir de all la velocidad angular, la actitud y orientacion del mismo.
v= r=
adt adt 2
(1.1) (1.2)
ZZ
Debido a que la plataforma giro estabilizada no es perfecta, en los calculos se van introduciendo errores acumulativos que deben ser corregidos mediante fuentes externas (como por ejemplo, el GPS) al cabo de un cierto tiempo de vuelo (que es variable segun la cali dad del INS utilizado). A pesar de la existencia de estos errores acumulativos, los INS son muy utilizados y necesarios en la navegacion. En nuestro TFC desarrollamos un sistema de adquisicion de datos que nos permite pro porcionar a un procesador central la informacion necesaria que los chips ADIS16100 (giroscopio eje Z) y el ADIS16201 (acelerometro e inclinometro) nos proporcionan para calcular las aceleraciones, velocidades y posicion del vehculo en el que estemos embar cados. Es importante hacer notar, no obstante, que el sistema desarrollado aqu es del tipo strap down INS, donde la plataforma que contiene los giroscopos y acelerometros no esta giroestabilizada, sino ja a la estructura del vehculo.
Conceptos Teoricos
35
Si bien esto reduce la precision del dispositivo, los resultados son lo sucientemente bue nos como para alcanzar el objetivo que se busca con este TFC (apoyar las practicas de NACC), mientras se gana en sencillez de construccion y operacion.
36
Metodologa
37
CAPTULO 2. METODOLOGA I I
En este captulo de metodologa trataremos de mostrar que y como desarrollamos nuestro TFC, as como los problemas e inconvenientes que encontramos durante su elaboracion, para as ayudar tambien a futuros proyectistas.
2.1. Protocolo CAN utilizado

Para que nuestro bus CAN realice una comunicacion completa y correcta, debemos im plementar el nivel de aplicacion, tambien llamado Protocolo de Alto Nivel. Es en este nivel de aplicacion donde se ha de decidir el tipo de mensajes que habra y sus identicadores. La distribucion del tipo de mensajes y de sus identicadores es muy importante en el bus CAN. Como ya se ha comentado, el bus CAN es un sistema basado en tipos de mensajes y no en direcciones. Por lo tanto, la eciencia y funcionalidad del bus vendran determinados por esta distribucion. En nuestro sistema utilizaremos paquetes CAN en formato estandar. Eso signica que el campo ID sera de 11 bits. Sera en este campo en el que el protocolo se jara a la hora de arbitrar el acceso al medio. Es por eso que hemos de tener cuenta la urgencia de los mensajes a la hora de asociar IDs a los paquetes. Los 11 bits los hemos dividido en 3 campos (Ver la gura 2.1):
Tipo de mensaje: ID[10:9] Prioridad de mensaje: ID[8:7] ID del mensaje: ID[6:0]
Figura 2.1: Campo ID dividido en 3 sub-campos. El tipo de mensajes lo dividimos en otros 4 niveles (de mayor a menor prioridad):
Comandos: ID10=0 y ID9=0 Eventos: ID10=0 y ID9=1 Respuestas: ID10=1 y ID9=0 Datos: ID10=1 y ID9=1
38
Los comandos seran utilizados cuando se quiera obligar a los dispositivos a realizar algun cometido. Se les da la prioridad maxima para evitar que estos comandos queden rezagados por otros tipos de mensaje. En segundo lugar vendran los eventos. Los eventos son generados por los dispositivos en respuesta a algun acontecimiento fuera de lo normal. Es por eso que se le da una de las prioridades mas altas. Las respuestas son mensajes de datos solicitados por otros dispositivos. Para diferenciar lo de los mensajes de datos no solicitados, se les ha dado una prioridad mas alta que a estos ultimos. En el ultimo nivel pondremos los mensajes de datos. Esto no signica que los datos no sean importantes, pero los otros 3 tipos de mensajes tienen aun mas prioridad. Ademas, debido al alto porcentaje de mensajes con datos que habra respecto a los otros tipos, si le dieramos una prioridad mas alta podramos crear el efecto starvation, es decir, hacer esperar a un mensaje de comandos (que tendra una prioridad mas baja) porque se estan enviando mensajes de datos (con la prioridad mas alta). Dentro de cada tipo de mensaje tambien vamos a diferenciar las prioridades. Para ello utilizaremos el campo de Prioridad de mensaje, que utiliza otros dos bits:
Crtica: ID8=0 y ID7=0 Alta: ID8=0 y ID7=1 Media: ID8=1 y ID7=0 Baja: ID8=1 y ID7=1
Con estas sub-prioridades conseguiremos darle mas uidez a nuestro bus. Por ejemplo, a los datos del dispositivo que sea mas propenso a enviar datos le damos una prioridad mas baja que a los del dispositivo que enve los datos con menos asiduidad. De esta manera conseguiremos no crear el efecto starvation explicado anteriormente. Los 7 bits restantes podran diferenciar los diferentes mensajes que esten en el mismo grupo. Por lo tanto, con este diseno tendremos 4 bits que agruparan los mensajes en 16 grupos 4 ). Dentro de estos 16 grupos tendremos 128 niveles de prioridad diferentes posibles (2 (27 ). (Ver la gura 2.2). Una vez tenemos las prioridades denidas, se ha de decidir que tipo de mensajes salien tes y entrantes van a tener los dispositivos. En nuestro caso, la placa de adquisicion de datos tendra los siguientes paquetes; Como paquetes entrantes podemos tener: Comandos en los que se pide informacion de aceleracion en el eje x (CMND.ACCX).
Metodologa
39
Figura 2.2: Tipos de mensaje en el protocolo CAN. Comandos en los que se pide informacion de aceleracion en el eje y (CMND.ACCY). Comandos en los que se pide informacion de aceleracion en el eje z (CMND.ACCZ). Comandos en los que se pide informacion de inclinacion en el eje x (CMND.INCLX). Comandos en los que se pide informacion de inclinacion en el eje y (CMND.INCLY). Comandos en los que se pide informacion de inclinacion en el eje z (CMND.INCLZ). Comandos en los que se pide informacion de velocidad angular en el eje y (cabeceo) (CMND.WY). Comandos en los que se pide informacion de velocidad angular en el eje z (guinada) (CMND.WZ). Comandos en los que se pide informacion de temperatura interna del ADIS16100 numero 1 (CMND.T1). Comandos en los que se pide informacion de temperatura interna del ADIS16100 numero 2 (CMND.T2). Comandos en los que se pide informacion de temperatura interna del ADIS16201 numero 1 (CMND.T3). Comandos en los que se pide informacion de temperatura interna del ADIS16201 numero 2 (CMND.T4).
Como paquetes salientes tendremos: Respuesta de aceleracion en el eje x (DATA.ACCX).
40
Respuesta de aceleracion en el eje y (DATA.ACCY). Respuesta de aceleracion en el eje z (DATA.ACCZ). Respuesta de inclinacion en el eje x (DATA.INCLX). Respuesta de inclinacion en el eje y (DATA.INCLY). Respuesta de inclinacion en el eje z (DATA.INCLZ).
Respuesta de temperatura interna del ADIS16100 numero 1 (DATA.T1). Respuesta de temperatura interna del ADIS16100 numero 2 (DATA.T2). Respuesta de temperatura interna del ADIS16201 numero 1 (DATA.T3). Respuesta de temperatura interna del ADIS16201 numero 2 (DATA.T4). Respuesta de velocidad angular en el eje y (DATA.WY). Respuesta de velocidad angular en el eje z (DATA.WZ) .
En la tabla 2.1 se muestran los identicadores asociados a cada mensaje. Una vez asociado el ID a cada paquete ya se puede crear la tabla de aceptacion (o ltro) en el nodo de comunicaciones. Esta tabla es necesaria para poder obviar los paquetes que no interesan al dispositivo. En el sistema disenado, esta tabla estara denida por los ID de los paquetes entrantes al dispositivo y por el ID de reset de comunicaciones (ID=0). Por lo tanto, la tabla de aceptacion quedara como la tabla 2.2. A la hora de programar la tabla de aceptacion de mensajes surgio la duda si hacerla en el nodo de comunicaciones o en el propio dispositivo. Cada una de las opciones tena sus caractersticas (Ver las tablas 2.3 y 2.4). Los puntos claves son los de la independencia entre nodo y dispositivo y el no tener que anadir un PIC al dispositivo. Este ultimo hecho es el que nos ha hecho decidir por programar la tabla de aceptacion en el nodo de comunicaciones. Es por eso que nos gustara recalcar, que al ser el Nodo de Comunicaciones dependiente con el dispositivo, siempre que se quiera cambiar de dispositivo se tendra que reprogramar esta tabla de aceptacion de mensajes. Viendo la distribucion de los mensajes se puede llegar a la conclusion que no hace falta hacer tantas sub-divisiones de prioridades. Esto es cierto si solo se tiene en cuenta un dispositivo, pero una de las nalidades de este trabajo es poderlo unir junto con otros dispositivos, como puede ser un GPS, que anadiran bastantes mas tipos de mensajes. Pensando a futuro, al sistema se le podra unir otros dispositivos, como por ejemplo una caja negra que fuera registrando los datos, unos servos para tener la posibilidad de dirigir un vehculo, etc. Es por este motivo que se ha decidido implementar un protocolo CAN con estas sub-divisiones en el campo ID para tener un mayor rango de prioridades, y de esta forma dar mas uidez al bus.
Metodologa
41
Tipo de mensaje Comando Comando Comando Comando Comando Comando Comando Comando Comando Comando Comando Comando Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta Respuesta
Prioridad Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Media Media Media Media Media Media Media Media Media Media Media Media
ID 00010000000 00010000001 00010000010 00010000011 00010000100 00010000101 00010000110 00010000111 00010001000 00010001001 00010001010 00010001011 10100000000 10100000001 10100000010 10100000011 10100000100 10100000101 10100000110 10100000111 10100001000 10100001001 10100001010 10100001011
Nombre del paquete CMND.ACCX CMND.ACCY CMND.ACCZ CMND.INCLX CMND.INCLY CMND.INCLZ CMND.WY CMND.WZ CMND.T1 CMND.T2 CMND.T3 CMND.T4 DATA.ACCX DATA.ACCY DATA.ACCZ DATA.INCLX DATA.INCLY DATA.INCLZ DATA.WY DATA.WZ DATA.T1 DATA.T2 DATA.T3 DATA.T4
Paquetes Entrantes
Paquetes Salientes
Tabla 2.1: Identicadores asociados a los mensajes utilizados en la Placa de Adquisicion de Datos.
2.2. Nodo de Comunicaciones

La nalidad del Nodo de Comunicaciones es la de poder recibir informacion de dispositivos que hablen en RS232, SPI o I2C, para despues enviar esa misma informacion al Bus CAN. En los siguientes apartados se puede ver como se ha disenado tanto el hardware como el software para poder cumplir con estos requisitos.
42
ID a aceptar en la Placa de Adquisicion de Datos 00000000000 00010000100 00010001001 00010000000 00010000101 00010001010 00010000001 00010000110 00010001011 00010000010 00010000111 00010000011 00010001000
Tabla 2.2: Tabla de aceptacion de mensajes de la Placa de Adquisicion de Datos.
En Nodo de Comunicacion Nodo y dispositivo seran dependientes. Reprogramar el PIC si se pretende cambiar el nodo de comunicacion. No sera necesario un PIC complementario. Tabla 2.3: Caractersticas si la tabla de aceptacion esta en el Nodo de Comunicaciones.
En Dispositivo Nodo y dispositivo seran independientes. No sera necesario reprogramar el PIC. Se necesitara un PIC extra. Tabla 2.4: Caractersticas si la tabla de aceptacion esta en el Dispositivo.
Metodologa
43
2.2.1. Hardware
2.2.1.1. Esquema electronico El nodo de comunicaciones consta fsicamente con el hardware necesario (Ver la gura 2.3) para poder establecer comunicacion en todos y cada uno de los protocolos descritos en el capitulo 1.1.
Figura 2.3: Diagrama esquematico. Nodo de Comunicaciones. A parte del microcontrolador PIC18F4580, escogido porque tiene los 3 modulos necesarios (EUSART, MSSP, CAN) para implementar los 4 protocolos (SERIE, I2C, SPI, CAN), han sido necesarios un conjunto de bloques a n de conseguir un funcionamiento optimo del dispositivo. Estos bloques se pueden diferenciar por su funcion: Bloque de alimentacion: Este bloque consta de un regulador de tension LM7805 de la casa TSC y un condensador electroltico de 47 F (Ver la gura 2.5).
44
Este condensador nos permite alimentar los componentes de nuestro circuito a dis tancias relativamente grandes de la fuente de alimentacion. Basicamente su funcion es eliminar el rizado de la senal de tension que hay en la entrada del regulador para que la senal de salida no tenga grandes variaciones de tension debido a irregularidades, cuando llegue al componente. El valor de este condensador variara en funcion de la distancia entre los dispositi vos y la fuente de alimentacion, o del ltro de alimentacion, pudiendo llegar a ser superuo. La alimentacion de entrada del regulador puede variar entre un mnimo de 7.5 V y un maximo de 20 V a la entrada, consiguiendo 5 V de salida. Es muy importante el valor mnimo de 7.5 V, ya que el regulador tiene una cada de tension (Voltaje Drop) de 2 V y el mnimo para trabajar con el nodo son 5 V. La conexion a la red electrica se hace por medio de un transformador de 220 V a 9 V (Este transformador puede ser de 9 V o 12 V) o a traves de unas bateras de 12 V conectadas directamente al nodo. En ambos casos hay que tener muy en cuenta la polaridad con la que se conecta la alimentacion a la placa, puesto que podemos llegar a quemar el regulador 7805 de este bloque. Siempre tendremos la tierra (GND) por la parte de fuera del conector y 9 V o 12 V por la parte de dentro (Ver gura 2.4)
Figura 2.4: Polarizacion del conector de alimentacion.
Figura 2.5: Bloque de alimentacion del Nodo de Comunicaciones.
Bloque del clock: A la hora de elegir una frecuencia de trabajo nos ayudamos
del datasheet del PIC18F4580, donde podemos encontrar un captulo dedicado a conguraciones de osciladores (Ver apartado 1.1.1.1.). En nuestro caso nos decidimos por utilizar un oscilador externo XT (cristal de cuar zo) ya que son bastante estables, faciles de encontrar en el mercado y su precio no es excesivo. La frecuencia del oscilador escogido es de 20MHz, que es el maximo que admite el PIC en el modo de alta velocidad, HS (High Speed). (Ver tabla 1.1). Ademas del cristal de cuarzo son necesarios unos condensadores y una resistencia para incrementar la estabilidad del oscilador (Ver la gura 2.6 ). Los valores de la tabla 1.1 son orientativos. Si se utilizan unos condensadores de mayor capacidad
Metodologa
45
ganaremos estabilidad, pero se incrementara el tiempo de inicio del reloj. En nuestro nodo de comunicaciones hemos utilizados los valores indicados en la tabla.
Figura 2.6: Bloque del clock del Nodo de Comunicaciones. Bloque de programacion: Para programar el PIC se ha utilizado una unidad de programacion y debug llamada ICD (Ver apartado 2.2.2.1.) de la casa CCS. Para conectar este dispositivo es necesario un conector RJ12 (Ver la gura 2.7).
Figura 2.7: Conector RJ12. Establecida la conexion entre las puertas digitales RB7, RB6, RB5 del PIC y el conector RJ12, tal y como se indica en el esquema de la gura 2.8, disenamos un boton de Reset para reiniciar el nodo en caso de cualquier problema. Esto es posible conectando un pulsador al pin MCLR. Ademas, en esta gura se pueden observar una serie de resistencias. Estas resistencias son muy necesarias ya que evitan que al desconectar el ICD (desconec tar una impedancia del circuito), las entradas digitales lean informacion incorrecta variando entre el 0 y el 1 logicos, provocando que las interrupciones que corresponden a las puertas digitales RB sean invocadas y creando a su vez un mal funcionamiento del software. Estas resistencias deben de ser del orden de 1 k - 10 k. Las resistencias conectadas a RB5 y RB6 son diferentes a la conectada en RB7 ya que en estos pines (RB5 y RB6) tambien se conectan unos interruptores para seleccionar el protocolo a utilizar. Estos interruptores para seleccionar el protocolo tienen asociadas unas resistencias que se encuentran conectadas en paralelo con las resistencias de los pines RB5 y RB6 (ver mas abajo en gura 2.9). Estas ultimas hacen variar el nivel de tension a la entrada de los pines RB5 y RB6 de forma incorrecta. Debido a esto es necesario que el valor de las resistencias de RB6 y RB5 sea mayor que en las resistencias de los interruptores. De esta forma podemos asegurar una lectura correcta de los niveles de tension en las entradas del PIC.
46
Figura 2.8: Bloque de programacion del Nodo de Comunicaciones. Bloque de comunicaciones y seleccion de protocolo: El bloque de comunicaciones esta integrado por los transceivers de RS232 y CAN, los buses de CAN, RS232, SPI e I2C, y los puertos para que el usuario conecte el nodo al dispositivo (Ver la gura 2.9). Los transceivers utilizados son los siguientes: El MAX232, utilizado para los comunicaciones RS232, es un chip dual formado por unos drivers (transmisores), unos receivers (receptores) y un generador de voltaje capacitivo para subir de los 0 V - 5 V que transmite el PIC a los 12 V del estandar EIA-2321 . En total el MAX232 dispone de 4 conversores de niveles TTL/CMOS al bus estandar RS232 y viceversa. De estos 4 conversores solo utilizaremos 2, uno CMOSRS232 y otro RS232CMOS. Cada receiver convierte las entradas EIA-232 a niveles de 5 V TTL/CMOS, y cada driver convierte las entradas TTL/CMOS a niveles EIA-232. De forma resumida el MAX232 es un chip que adapta senales electricas (capa fsica en los niveles OSI). Su tpica conguracion (extrada del datasheet) es la que utilizaremos en el nodo de comunicaciones y es la mostrada en la gura 2.10. En nuestro caso solo utilizaremos un unico canal de comunicacion, por lo que no utilizaremos los pines T1OUT, T1IN, R1IN y R1OUT correspondientes a 2 conversores. Los pines R2OUT y T2IN, que corresponden a los niveles CMOS de uno de los conversores, iran conectados a los pines del PIC RX/DT (pin 26) y TX/CK (pin 25) respectivamente. Las salidas del MAX232 en EIA-232 a 12 V se conectaran a traves de un conector DB9 hembra2 al cable NULL MODEM que ira al dispositivo nal. El funcionamiento del cable NULL MODEM se explica mas adelante.
EIA Electronic Industries Alliance. Al Estandar RS-232 tambien se le puede llamar EIA-232 ya que RS232 fue una propuesta de esta asociacion de empresas. 2 Es un conector hembra y no macho porque con este ultimo se produce un efecto espejo en las cone xiones (Ver gura 1.11).
1
Metodologa
47
Figura 2.9: Bloque de comunicaciones del Nodo de Comunicaciones. El PCA82C251 es una interfaz entre el controlador del protocolo CAN que se encuentra en el PIC, y el Bus CAN fsico. Este chip esta formado por un receiver y un driver que nos convertira las senales que entren por el CANH y CANL a CMOS para tener una lectura correcta de los datos en el PIC (adapta niveles). Su conguracion de pines se muestra en la gura 2.11. A parte del PCA82C251 existen otras alternativas en el mercado. En nuestro caso hemos utilizado este chip porque se ajusta a nuestros criterios de diseno, pero en funcion de estos tambien podemos encontrar otros transceivers (ver tabla 2.5). En cuanto a SPI e I2C, estos protocolos no necesitan ninguna adaptacion en sus niveles de senal como lo requeran CAN y RS232, de forma que podemos conectar los dispositivos directamente al PIC. El unico concepto que hay que tener claro es que para el correcto funcionamiento de I2C son necesarias 2 resistencias de carga (denidas en el captulo 1.1.4.1.) mientras que para SPI estas resistencias provocan un mal funcionamiento del bus. Debido a que ambos protocolos comparten pines en el PIC, se han disenado unos interruptores que nos permitiran usar las resistencias PULL-UP cuando estemos trabajando en I2C, y desactivarlas cuando estemos trabajando con SPI. Esta sistema, desarrollado por nosotros, se puede ver en la gura 2.12. La conexion a otros dispositivos desde el nodo de comunicaciones se reali-
48
Figura 2.10: Conguracion MAX232. Smbolo TXD GND Pin 1 2 3 4 5 6 7 8 Descripcion Transmision de los datos recibidos Tierra Alimentacion Salida de los datos recibidos Salida de tension de referencia Nivel bajo CAN IN/OUT Nivel alto CAN IN/OUT Entrada resistencia Slope Figura 2.11: Pines del PCA82C251. zara mediante un User Terminal para los protocolos SPI, I2C y CAN, y mediante un cable NULL MODEM conectado al DB9 del nodo para el RS232 (Ver la gura 2.13). A continuacion describimos como conectar dos nodos de comunicacion o un nodo y un dispositivo: En el bus CAN la conexion consiste en unir los dos terminales de CANH y de CANL entre s (CANH-CANH, CANL-CANL y GND-GND)3 . Por otro lado, para el protocolo I2C la conexion sera SDA-SDA, SCLK-SCLK y GND-GND. Por su parte, para el SPI la conexion sera SDO-SDI, SDI-SDO, SCLK-SCLK y GND-GND 4 . La conexion serial por RS232, a traves del conector DB9 hembra, se rea lizara con un cable NULL MODEM. Otra opcion podra haber sido utilizar un cable serial directo, pero por criterios de diseno se opto por un NULL MODEM. En las comunicaciones serial, sea cual sea el tipo de cable utilizado, el pin de
3 Cuando se quiera conectar mas de dos Nodos de Comunicaciones entre si, seran necesarias dos re sistencias de 120 colocadas en paralelo (entre CANH y CANL), una en cada extremo del bus. La nalidad de estas resistencias es evitar que los datos transmitidos sean devueltos en forma de eco de los extremos de los cables y que se falsiquen los datos. 4 Es muy importante conectar las tierras entre los dispositivos para evitar problemas de masa otante en la alimentacion
VCC
RXD
VREF
CANL CANH
RS
Metodologa
49
Transceivers Fabricante Philips Modelo PCA1 PCA2 TJA1054 MAX3058 MAX3050 MAX3054 SN65LBC031 SN65HVD251 SN65HVD232 No Nodos 110 15 32 32 32 32 120 120 Velocidad 1mega 125k 125k 1mega 2mega 250k 500k 1mega 1mega tolerancia NO SI SI Low EMC NO NO SI NO NO NO 3.3v
Maxim
Ti
Tabla 2.5: Otros Transceivers.
Figura 2.12: Interruptores activacion/desactivacion de las resistencias PULL-UP.
Figura 2.13: Terminales de conexiones externas del Nodo de Comunicaciones.
50
Transmision (TX) del dispositivo 1 debe ir conectado al de recepcion (RX) del dispositivo 2. La diferencia entre utilizar o no un cable NULL MODEM es el lugar donde el pin TX se conecta a RX. En un cable NULL MODEM este cruce se hace en el cable, mientras que en un cable serial directo el cruce se hace en el dispositivo (Ver la gura 2.14).
Figura 2.14: Cable NULL-MODEM - Cable directo. Finalizando este bloque de comunicaciones, se han conectado 3 interruptores a las puertas digitales del PIC (RB4, RB5 y RB6) para seleccionar por software el protocolo del dispositivo con el que estamos trabajando. Estos interruptores se pueden ver en la gura 2.3 con el nombre de: INT RS232, INT I2C, INT SPI. En la tabla 2.6 se pueden ver las diferentes conguraciones.
``` ` ```
Interruptor
``` ``` ` `
Protocolo
INT RS232 1 0 0
INT I2C 0 1 0
INT SPI 0 0 1
RS232 I2C SPI
Tabla 2.6: Conguracion interruptores de seleccion de protocolos. Si dos interruptores se ponen en ON, se seleccionara el protocolo perteneciente al primer interruptor modicado. Para evitar problemas, es recomenda ble solo tener un interruptor activado a la vez. Para poder reconocer visualmente en que protocolo estamos trabajando, hemos implementado 3 LEDs de colores diferentes. Por cada una de las 3 con guraciones se encendera un LED diferente. Como se ha explicado en el bloque de programacion, las resistencias de los interruptores que son conectadas en paralelo con los pines RB5 y RB6 han de ser de menor valor para no dar lecturas de tension incorrectas, mientras que la resistencia del interruptor RS232 (RB4) no necesita valores concretos ya que en este pin el ICD no esta conectado y no se producen efectos de impedancias en paralelo.
Metodologa
51
2.2.1.2. PCB Una vez desarrollados y probados los bloques que forman el nodo de comunicaciones, y despues de haber experimentado con el dispositivo sobre un protoboard, pudimos decir que habamos llegado a una conguracion estable. Con este diseno nal se ha elaborado un circuito integrado que nos permite trabajar de forma continua y estable en un unico modelo de circuito. Para realizar el circuito integrado denitivo nos ayudamos del software que utilizan los servicios tecnicos de la EPSC. El software utilizado es el P-CAD 2002. De esta forma evitamos incompatibilidades en los formatos de cheros, ya que ellos nos realizan las placas con las pistas del circuito. Utilizamos este programa con la nalidad de realizar el PCB. El PCB es un medio para sostener mecanicamente y conectar electricamente componentes electronicos, a traves de rutas o pistas de material conductor, grabados desde hojas de cobre laminadas sobre un sustrato no conductor. Como se puede ver en la gura 2.15, se utilizo tanto la capa TOP, donde tenemos la 5 mayora de conexiones, como la capa BOTTOM , que es donde tenemos GND y algunas conexiones que no era posible enrutar por la capa TOP. Para enrutar a traves de las dos capas se han utilizado VIAS, que son agujeros metalizados que atraviesan la placa de una supercie a otra, creando un puente entre ellas. Debido a que gran parte de los componentes utilizados en el circuito no existan en las libreras del programa, como por ejemplo el conector del ICD, utilizamos otro software (el Patern Editor, que esta incluido en el paquete de P-CAD2002) para crear los patrones de los componentes que no tenamos, creando as una librera especial para nuestro nodo de comunicaciones. Estos componentes estan adjuntados en el archivo del PCB que se encuentra en el CD-ROM de software.
2.2.2. Software
En este apartado se explica todo lo relacionado con el desarrollo del software del nodo de comunicaciones. Primero se hara una pequena introduccion al entorno de programacion utilizado. Segui damente, y ayudandonos con un diagrama de ujo, se explicara paso a paso el codigo implementado en los PIC.
2.2.2.1. Entorno de programacion Como se comentaba en el captulo 1.1.1., para que el PIC pueda realizar sus funciones primero se ha de programar. Para programar el PIC se necesitan una serie pasos y elementos:
5
En el anexo C se pueden ver por separado cada una de las capas de todos los circuitos de este trabajo
52
Figura 2.15: PCB del Nodo de Comunicaciones Utilizar un editor de textos para poder escribir el codigo. El lenguaje de programa cion que se suele utilizar en la mayora de los casos es el C o el Ensamblador. En nuestro TFC hemos utilizado C ya que disponamos de libreras que nos facilitaban el trabajo, y ademas por su facilidad a la hora de utilizarlo. Compilador que traduzca el chero escrito en C a codigo maquina. En nuestro caso hemos utilizado el compilador PCW de la casa CCS Inc. Este compilador traduce el codigo C del archivo fuente (.c) a lenguaje maquina para el PIC, generando as un archivo en formato hexadecimal (.HEX). Este compilador se integra en un entorno de desarrollo integrado (IDE) que nos permite desarrollar todos y cada uno de estos pasos, desde la edicion hasta la compilacion pasando por la depuracion de errores. El ultimo paso es el de la programacion. Una forma de programar el PIC es con un programador externo. Este no sera un metodo muy ecaz ya que cada vez que quisieramos programarlo, tendramos que quitar el PIC de nuestro circuito para ponerlo en el programador externo. Para remediar esto utilizamos una unidad de programacion y debug, que tambien nos proporciona CCS Inc., llamada ICD (Ver la gura 2.16). Esta unidad ICD va conectada al ordenador mediante un cable USB y al PIC me diante un conector RJ11. Este conector RJ11 es el que esta conectado a los pines
Metodologa
53
del PIC necesarios para poder programarlo.
Figura 2.16: Programador ICD utilizado a la hora de programar.
2.2.2.2. Codigo implementado Antes de ponerse a implementar el codigo, se ha de estar seguro de lo que se quiere hacer y como se va a hacer. Para ello, resaltaremos los puntos mas importantes a consi derar, se decidira la distribucion del codigo en los diferentes cheros posibles, y nalmente unos diagramas de ujo que nos serviran para representar visualmente la se se crearan cuencia de datos y procesos a lo largo del programa. Una vez se tenga todo esto claro, se puede pasar a implementar el codigo. A la hora de implementar nuestro codigo, tuvimos que tener en cuenta dos factores muy importantes: Los tipos de dispositivos a los que nos ibamos a conectar y la forma de optimizar los recursos del PIC. Cuando hablamos del tipo de dispositivos con los que nos vamos a comunicar, nos referi mos a la forma como estos dispositivos enviaran su informacion. Nosotros hemos diferenciado tres tipos de dispositivos: Dispositivo tipo 1: Dispositivo que va enviando informacion continuamente o cada x tiempo, sin que ningun otro dispositivo se lo haya pedido explcitamente. Dispositivo tipo 2: Dispositivos que envian informacion solo cuando reciben ordenes, es decir, cuando reciben paquetes CAN del tipo Comandos.
Dispositivo tipo 3: Dispositivos que funcionan de la dos formas explicadas anteriormente.
Debido a estos tres diferentes tipos de dispositivos, se han implementado dos funciones especiales (estas funciones se encuentran en el archivo funciones.c);
54
id entrante id salida: Esta funcion solo se utiliza cuando estamos comunicando nos con un dispositivo del tipo 2 o 3. En estos casos, el dispositivo no va a enviar informacion sobre el ID del mensaje que se transmitira por CAN, y es por eso que necesitamos esta funcion para asociarle un ID. Es en este punto donde el pro gramador ha de indicar la relacion entre el ID del mensaje entrante (paquete tipo Comando), y el ID del mensaje saliente (paquete tipo Respuesta). mensaje a responder: Gracias a esta funcion sabremos si un paquete necesita una respuesta o no jandonos en su ID.
La forma de optimizar los recursos del PIC fue una decision bastante sencilla: Funciona miento en base a interrupciones. Todas las acciones a realizar estaran en las funciones de las interrupciones. La idea basica de las interrupciones es la de quitar carga de trabajo al procesador para que pueda realizar otros procesos. Si no se implementaran estas interrupciones se tendra que estar preguntando en todo momento al procesador por algun dato en concreto. De esta manera se deja libre al procesador, y solo cuando se produce la circunstancia por la que ha sido programada la interrupcion se toma el control de este. Las cuatro interrupciones utilizadas son las siguientes: INT RB: Esta interrupcion se utiliza para el manejo de los interruptores. Su funcion es la de congurar las variables internas que utilizamos para seleccionar el proto colo para enviar o recibir datos. Esta interrupcion salta cuando en cualquiera de los pines RB4, RB5, RB6 y RB7 hay un cambio de nivel. INT CANRX0: La funcion de esta interrupcion es detectar paquetes CAN dentro del bus, y pasar la informacion necesaria al dispositivo al que este conectado mediante el protocolo seleccionado (Ver la gura 2.17). Se activa siempre que se recibe un paquete CAN.
Figura 2.17: Esquema ujo de datos en INT CANRX0. Debido a la continua llegada de paquetes CAN, en esta interrupcion solamen tese recibe el paquete. El posterior procesado de la informacion se activa mediante un boleano en la rutina main del programa. De esta forma se podran recibir todos los paquetes CAN. INT SSP: La funcion de esta interrupcion es detectar senal por el pin 23 en el PIC18F4580 o el 15 en el PIC18F2580 (recepcion I2C y SPI), e ir guardando esa informacion en un vector de 8 posiciones (8 bytes es el maximo que se puede anadir
Metodologa
55
en un paquete CAN) hasta que se llene este vector o hasta que llegue una condicion de nal de transmision (Ver la gura 2.18). En estos casos, se enviara el paquete CAN con el ID recibido y con el paquete de informacion.
Figura 2.18: Esquema ujo de datos en INT SSP. INT RDA: La funcion de esta interrupcion es detectar senal por el pin 26 en el PIC18F4580 o el 18 en el PIC18F2580 (recepcion de datos RS232)(Ver la gura 2.19). Al igual que con la interrupcion INT SSP, los datos se van guardando en un vector de 8 posiciones hasta que llegue una condicion de nal de comunicacion o el paquete se llene.
Figura 2.19: Esquema ujo de datos en INT RDA.
Otro punto a tener en cuenta antes de ponerse a programar es tener clara la distribucion del codigo. Nunca se ha de programar todo el codigo de golpe y en un solo chero, sino que se ha de hacer con una cierta jerarqua (Ver la gura 2.20). tfc.c: Es donde se encuentran las interrupciones y la funcion main del programa. Por lo tanto, es donde se realiza practicamente la mayoria de las acciones. En tfc.c es donde se conguran los 4 protocolos a utilizar, donde se declaran las variables globales, etc. Mas adelante se explica detalladamente el codigo de este chero.
funciones.c: En este chero es donde se encuentran las funciones con las que el
usuario podra modicar el funcionamiento del Nodo de Comunicaciones. Como ya se comento en el apartado 2.1., el Nodo de Comunicaciones es depen diente del dispositivo, y por lo tanto tendremos que adaptar el codigo segun este ultimo. En resumen, cuando se quiera cambiar de dispositivo, este sera el unico chero que se tendra que modicar (junto con su librera funciones.h). Las funciones son la siguientes:
56
Figura 2.20: Jerarqua de los cheros utilizados en Nodo de Comunicaciones. seleccion mensaje(id): Con esta funcion podremos saber si un paquete es para este nodo o no. id entrante id salida(id): Con esta funcion sabremos cual es el id de salida dependiendo del id de entrada. Por lo tanto, solo utilizaremos esta funcion en dispositivos del tipo 2 o 3. mensaje a responder(id): Con esta funcion sabremos si el paquete recibido necesita respuesta o no. imprimir id(): Con esta funcion se habilitara o deshabilitara el envo de los ID por el protocolo seleccionado. condicionnal(): En esta funcion se indica cual es la condicion de nal de transmision del dispositivo al que se conecta el Nodo de Comunicaciones. id valido(): En esta funcion se indica si el ID que enva el dispositivo es un ID valido para utilizarlo en el bus CAN o no. set id valido(): En esta funcion se indica el ID valido en el caso que el resul tado de la funcion id valido() sea negativo. condicion nal can(id): Con esta funcion sabremos cual es la condicion de nal de los datos que nos llegan por CAN, gracias al ID con los que llegan los paquetes. Esta funcion es necesaria porque cada dispositivo puede tener unas condiciones de nal de datos diferentes, y por lo tanto el nodo receptor ha de saber cual es esa condicion de nal de datos en cada caso.
funciones.h: En esta librera se declaran las funciones de funciones.c. can-18f4580.c: En can-18f4580.c es donde encontraremos las funciones rela cionadas con el bus CAN. Estas funciones son las que se utilizaran a lo largo del codigo de tfc.c.
can-18f4580.h: En esta librera se declaran las estructuras, variables y funciones

utilizadas en can-18f4580.c.
Metodologa
57
18f4580.h: En esta librera se denen todas las constantes associadas al PIC18F4580.

Para el correcto seguimiento del codigo implementado en el nodo de comunicaciones hemos considerado oportuno realizar un diagrama de ujo (Ver Anexo B). El diagrama de ujo lo hemos utilizado para representar visualmente la secuencia de datos y procesos a lo largo de nuestro programa. Es un proceso que se ha de hacer siempre antes de ponerse a programar el codigo para facilitar la comunicacion entre los diferentes programadores y la comprension de problemas largos y complicados. Una vez que se dibuja el diagrama de ujo, llega a ser facil escribir el programa en cualquier idioma de alto nivel. Por ultimo, el diagrama de ujo tambien nos ayudara a explicar el programa a otras perso nas. Vamos a dividir este diagrama de ujo en varios modulos para explicar el codigo imple mentado (Para ver el codigo ir a Anexo A): Modulo Conguracion Nodo de Comunicaciones: El primer paso a realizar es el de la inicializacion del PIC. Es aqu donde conguramos todos los parametros necesarios para el correcto funcionamiento del PIC. En este punto se utilizan directivas, que son comandos especcos precedidos por un # y que permiten que el compilador acepte o ignore los datos siguientes. Primero anadimos las libreras del PIC (18F4580.h), la librera del CAN (can-18F4580.c) y la librera funciones.c. En la primera librera encontramos todas las deniciones de constantes utilizadas dentro del PIC. En la librera del CAN estan las funciones basicas del protocolo (recibir paquete, enviar paquete, etc). Seguidamente, y ayudados con la directiva #fuses, declaramos las opciones a activarse en el PIC cuando se programe. En nuestro caso hemos activado HS (High Speed Osc), NOWDT (No Watch Dog Timer), NOLVP (No Low Voltage Program ming, B3 o B5 usado para I/O) y NOPROTECT (Codigo no protegido por lecturas). El reloj lo conguramos con la directiva #use delay(clock = frecuencia). En nuestro caso lo conguramos con una frecuencia de oscilacion de 20 MHz. De esta forma indicamos al compilador la frecuencia del procesador, en ciclos por segundo, a la vez que habilitamos el uso de las funciones delay ms() y delay us(). Es en este punto donde se han de declarar unas variables globales que se utilizaran a lo largo del programa. Un ejemplo de estas variables son los contadores, variables booleanas para indicar con cual protocolo estamos trabajando o con que tipo de dispositivo nos comunicamos, los pines de los LEDs, etc. El siguiente paso a realizar es el del Reset de las comunicaciones. Este paso esta pensado para que cuando un nodo de comunicaciones se resetee, enve un mensaje advirtiendo a todos los nodos que los proximos datos que transmita seran datos de inicio y no la continuacion de datos de la transmision anterior. Para conseguir esta nalidad nos ayudamos de la funcion can putd() (explicada mas adelante en este mismo captulo) con la que enviaremos un paquete con el caracter \r y con el ID 00000000000.
58
Este caracter estara asociado al ID=0 en la funcion condicion nal can(id), y por lo tanto, todos los nodos al recibir este paquete inicializaran todas sus variables para poder iniciar una nueva recepcion de datos. Gracias a esta funcion, cada dispositivo puede enviar su propia condicion de nal de datos y de esta forma no forzarle a anadir una variable a cada cadena de datos. Este reset se adapta perfectamente a nuestro sistema placa de adquisicion-CANPC (o dos PC). Pero si de cara a un futuro se quisiera ampliar el numero de dis positivos, este sistema de reset se tendra que mejorar. Sera necesario disenar un metodo para que la condicion de reset se enviara solo al dispositivo con el que esta ba hablando anteriormente y no a todos los demas. De esta forma no se interferira con otra posibles comunicaciones dentro del bus CAN. A continuacion, se pretende inicializar los protocolos RS232, CAN y I2C. En este punto no se inicializa el protocolo SPI ya que el I2C utiliza los mismos pines, y por lo tanto al congurar uno se descongura el otro protocolo. Haciendo pruebas nos dimos cuenta que era la inicializacion del SPI la que descon guraba la del I2C (y no al reves). Es por ese motivo que el protocolo SPI solo se inicializa en el momento que se activa su interruptor. Para poder congurar RS232, es importante tener en cuenta que antes de denir el puerto serie se ha tenido que denir el reloj utilizado. Con la directiva #use RS232(BAUD=baudios, XMIT=pin, RCV=pin) se le dice al compilador la velocidad en baudios y los pines utilizados para la I/O serie. Ademas, tambien se habilitaran las funciones getc(), putc() y printf(). En nuestro caso pondremos un BAUD de 4800 y la conguracion sera la 8N1 (que es la Default Conguration). Para congurar el protocolo I2C nos ayudamos de la directiva #use i2c(master/Slave, SDA=pin, SCL=pin). Esta directiva permanece efectiva para las funciones i2c start, i2c stop, i2c read, i2c write e i2c poll hasta que se encuentre otra directiva #use i2c. En nuestro programa, en la primera opcion de esta directiva hemos puesto Master. Esto nos permitira utilizar el dispositivo como transmisor de datos y poder iniciar la comunicacion. Cuando queramos que el dispositivo se comporte como receptor de datos, tendremos que utilizar esta directiva como Slave (mas adelante ocurre este caso). Con esta conguracion, la velocidad del protocolo es de 400 kbps. En la inicializacion del bus CAN utilizamos la funcion can init(), denida en la librera CAN antes mencionada. Esta funcion inicializa el modulo CAN a 125 kbaudios y se limpian todos los ltros y mascaras para que todos los mensajes puedan ser recibidos con cualquier identicador. Seguidamente se activan las interrupciones. Una interrupcion puede estar imple mentada, pero si no se habilita nunca llegara a saltar. Utilizamos las funciones enable interrupts(level) para habilitar la interrupcion del nivel dado en level. El level GLOBAL permite todas las interrupciones que esten habilitadas de forma individual. Para poder adaptar el Nodo de comunicaciones a los requerimientos del dispositi vo, se llaman a las funciones condicionnal() e id valido. En la primera funcion se indicara cual es la condicion de nal de datos del dispositivo, y por lo tanto nos de vuelve un valor que se guardara en una variable global. En la segunda funcion se
Metodologa
59
indicara mediante un booleano si el ID que enva el dispositivo es valido o no. En este caso, tambien guardaremos el booleano en una variable global. Una vez realizados estos pasos, se entra en un punto de espera. Se saldra de este punto cuando salte alguna interrupcion o cuando se habilite la opcion de enviar los datos recibidos por CAN. Una vez nalizadas las interrupciones o el envio de estos datos recibidos por CAN, se volvera al estado de espera. Hemos anadido una condicion de Reset (Reset de alimentacion y no reset de comunicaciones). Con este reset volvemos al inicio del diagrama de ujo. En la gura 2.21 se puede ver el diagrama de ujo de este modulo.
Figura 2.21: Diagrama de ujo del modulo Conguracion Nodo de Comunicaciones. Modulo Interrupcion Interruptores: En un primer paso miramos el nivel que tie nen los tres pines digitales (RB4, RB5 y RB6). Dentro de la interrupcion tenemos 3 ltros que detectan cual de los tres pines es el que ha cambiado su valor. Dependiendo de cual haya sido, modicaremos las variables correspondientes. Para poder crear un reconocimiento visual, hemos instalado 3 LEDs que se encen deran segun el protocolo que este escogido (LED roja para RS232, LED amarillo naranja para I2C y LED rojo para SPI). En cada uno de los 3 ltros activaremos el LED correspondiente. Una vez hemos modicado las variables y hemos encendido el LED correspondiente, realizamos el reset de comunicaciones. Siempre que se entre en esta interrup cion es porque se ha cambiado el protocolo; por lo tanto, seguro que se iniciara una
60
comunicacion nueva. Es por este motivo que se ha anadido este reset de comunicaciones. Como ya se comento anteriormente, el protocolo SPI se inicializa en este punto. Por ello, cuando se accione el interruptor de SPI se inicializara el protocolo mediante la funcion setup spi(), en la que indicaremos el modo de trabajo (master o slave), la forma de enviar los datos (SPI L TO H o SPI H TO L) y la frecuencia a la que se enviaran los datos (DEFAULT, SPI CLK DIV 16 o SPI CLK DIV 4). Inicialmente conguraremos al dispositivo como SLAVE. De esta forma, cuando queramos transmitir por SPI tendremos que volver a utilizar esta funcion con gurandolo como MASTER. Las otras dos variables dependeran del dispositivo con el que se tenga que comunicar (el unico requisito es que tanto en el Slave como en el Master han de estar conguradas de la misma forma). La velocidad que hemos congurado es la correspondiente a SPI CLK DIV 16 (1,25 Mbps). En la gura 2.22 se puede ver el diagrama de ujo de este modulo.
Figura 2.22: Diagrama de ujo del modulo Interrupcion Interruptores. Modulo Interrupcion CAN: En esta interrupcion solo recibiremos el paquete CAN, y el procesado de los datos se realizara en la funcion main() del programa. El procesado de los datos se podra hacer en la propia interrupcion pero como la llegada de paquetes al Nodo puede ser bastante rapida, hemos preferido liberar
Metodologa
61
de carga de trabajo a la interrupcion. De esta forma, si mientras se procesan los datos llega otro paquete, este podra ser atendido por la interrupcion. Con la funcion can getd() se obtiene el ID, la informacion y el numero de bytes que se han enviado. En la gura 2.23 se puede ver el diagrama de ujo de este modulo.
Figura 2.23: Diagrama de ujo del modulo Interrupcion CAN. Modulo Procesado de Datos CAN: Una vez obtenidos los datos del paquete CAN en la interrupcion CAN, lo primero que se debe hacer es saber si este paquete es para nosotros o no. Cada nodo tendra que ltrar los paquetes que le lleguen segun el dispositivo al que este conectado. Por lo tanto, se crea una dependencia entre nodo de comunicaciones y dispositivo. Si el nodo se quisiera unir a otro dispositivo, se tendra que programar con los ltros correspondientes a ese dispositivo. El ltro esta implementado mediante la funcion seleccio1n mensaje(ID). Es en esta funcion donde se guardan los identicadores a aceptar en un vector (cuando se quiera modicar la tabla de aceptacion de mensajes se modicara este vector). Si el ID esta dentro del vector, devuelve un TRUE y si no ha sido encontrado devuelve un FALSE. Dependiendo de este resultado se seguiran procesando los datos (si es TRUE) o se nalizara este modulo (FALSE). Una vez se sepa que el paquete es para nostros, pasamos a calcular 3 parame tros bastante importantes. El primer parametro lo obtendremos de la funcion con dicion nal can(id), y con ella podremos saber la condicion nal de los datos en funcion del ID recibido. El segundo parametro lo obtendremos de la funcion mensaje a responder(), con la que podremos saber si el paquete recibido es del tipo Comando o del tipo Datos. Si el paquete es del tipo Comando, se conguran las variables adecuadas para que los datos provenientes del dispositivo se cojan como datos y no como IDs. El tercer parametro lo obtendremos de la funcion imprimir id(), con la que sabremos si se ha de enviar el ID recibido en el paquete CAN o no. Una vez recibida la informacion de estas 3 funciones, se ha de enviar el ID y los datos por el protocolo seleccionado. Este envo de datos vendra determinado por el resultado de las 4 funciones anteriores. Por ejemplo, si imprimir id() devuelve un FALSE, no se imprimira el ID.
62
En la recepcion del ID lo primero que se hace es separarlo en dos bytes. Esto es necesario porque este identicador es de 11 bits y por lo tanto lo tendremos que guardar en 2 bytes. La forma de hacerlo es la siguiente; se crea una mascara para coger los tres ulti mos bits y estos formaran el segundo byte. El primer byte correspondera a los 8 bits siguientes (desplazamos el ID 3 posiciones hacia la derecha y lo igualamos al segundo byte). Por ejemplo, supongamos que nos llega un paquete con ID=1364 (10101010100), un byte cogera el valor de los tres ultimos bits (100 = 6) y el otro byte cogera el valor de los primeros 8 bits (10101010 = 170) (Ver la gura 2.24).
Figura 2.24: Distribucion de los dos bytes con informacion del ID. Si se quisieran enviar los dos bytes de ID, el primer paso es mirar si el ID recibido es el de la condicion de reset de comunicaciones (ID=0). Si estamos en ese caso, no nos interesa enviar los ID (solo se enviara la condicion de nal de comunicacion que es el \r). Si no estamos en ese caso, se envan los dos bytes con el ID por el protocolo seleccionado (el envo de datos en cada protocolo se explica en las interrupciones dedicadas a cada uno de ellos). Una vez se han enviado los ID, se han de enviar los datos (incluida la condicion de nal de datos). Nos ayudamos del valor numero de bytes recibido en la fun cion can getd() para enviar todos los datos. Se volveran a inicializar las variables necesarias cuando se reciba la condicion de nal de datos. Sabremos cual es esta condicion porque en la funcion main() se llamo a la funcion condicion nal can(id) y se guardo en una variable global. Las formas de enviar los datos son diferentes segun con el protocolo con el que estamos trabajando: En RS232 para enviar los datos es suciente con la funcion printf(). En I2C lo primero es enviar la condicion de start, lo que se logra con la funcion i2c start(). Seguidamente se ha de enviar la direccion del dispositivo con el que se quiere comunicar con la funcion i2c write(direccion). Se ha de tener en cuenta que la direccion de transmision del nodo de comu nicaciones y la de recepcion del dispositivo han de ser la misma. Despues de haber enviado la direccion del dispositivo, se pueden enviar todos los datos que se quiera tambien con la funcion i2c write(datos). Para nalizar es nece sario la condicion de stop, que se genera con la funcion i2c stop(). En SPI el proceso es algo diferente a los dos casos anteriores. Primero hemos de explicar que a diferencia del I2C, cuando transmitimos en SPI salta la interrupcion INT SSP. Por lo tanto, antes de enviar los datos hemos de deshabilitar dicha interrupcion disable interrupt(INT SSP). Esto implica que no se podra tener con la funcion
Metodologa
63
una comunicacion full-duplex, pero para el funcionamiento de nuestro nodo de comunicaciones (en el que solo se enva o solo se recibe en SPI en un instante dado), esto no es uno es una restriccion importante. Una vez deshabilitada la interrupcion, hemos de congurar el PIC para que trabaje en modo Master con la funcion setup spi(). Es en este punto cuando ya se puedeN enviar los datos con la funcion spi write(dato). Una vez nalizada la transmision de datos volvemos a congurar el PIC en modo Esclavo. Un ultimo paso es limpiar la interrupcion (creada al transmitir los datos) con la funcion clear interrupt(INT SSP), y volverla a habilitar con enable interrupts(INT SSP). En la gura 2.25 se puede ver el diagrama de ujo de este modulo.
Figura 2.25: Diagrama de ujo del modulo Procesado de Datos CAN. Modulo Interrupcion I2C y SPI: La primera accion a realizar es la del ltro seleccionador de protocolo. Nos tenemos que jar en las variables indicadoras de
64
protocolos para determinar donde tenemos que entrar. Al ser una interrupcion compartida para I2C y SPI se ha de hacer esta especie de ltro al principio. En los dos protocolos lo primero que hacemos es mirar con que tipo de dispositivo estamos comunicandonos. Si la variable transmitir sin preguntar esta a TRUE, el dispositivo es del tipo 1, mientras que si la variable esta a FALSE, el dispositivo es tratados como tipo 1 o 2 segun el caso). del tipo 2 (los dispositivos del tipo 3, seran Si estamos en el caso del dispositivo del tipo 1, los dos primeros bytes de informa cion se cogeran como informacion de ID. Como el ID a enviar por el paquete es de 11 bits, hemos de volver a juntar los dos bytes con informacion del ID. Para conseguirlo, al primer byte lo multiplicamos por 8 para anadirle 0s logicos al nal. Al segundo byte se le aplica una mascara que nos permite jarnos solo en los 3 ultimos bits. Para obtener el ID de 11 bits sumamos los dos bytes. Por ejemplo, si el primer byte recibido es el 10101010, al multiplicarlo por 8 obten dremos 10101010000. Si el segundo byte recibido es el 00000100, al sumarselo al otro resultado obtendremos el ID = 10101010100 = 1364. Si a la hora de recibir el primer o el segundo byte se recibe una condicion de nal de transmision6 , se reconguraran las variables para que en la siguiente entrada se vuelva a coger la informacion como si fuera el primer byte que le llega. Es a partir del tercer byte que la informacion se tratara como si fueran datos. Es importante mencionar que, aun siendo el dispositivo del tipo 1, si el ID que enva es invalido no tendremos que coger los primeros bytes como si fueran ID sino como si fueran datos (de ah la importancia de la funcion id valido(). Es por este motivo que cuando se observa el valor de la variable transmitir sin preguntar, tambien nos tengamos que jar en el de la variable idvalido. El ID lo podremos obtener con la funcion set id valido()). En dispositivos del tipo 2, todos los bytes recibidos son tratados como si fueran Datos y el ID se obtendra de la funcion id entrante id salida(). Una vez tenemos el ID, se reciben los bytes con informacion de datos. Si el byte recibido es una condicion de nal de comunicacion, se enva un paquete CAN con los datos almacenados hasta el momento en el vector de 8 posiciones. Si el byte recibido no es una condicion de nal de datos, este byte es almacenado en el vector de 8 posiciones. En el momento que el vector este completo, se enva el paquete CAN inmediata mente. Para enviar un paquete al bus CAN se utiliza la funcion can putd(ID, Datos, Numero de bytes, Prioridad, Extended, RTR). En el campo ID anadiremos el ID de 11 bits obtenido directamente de los dos primeros bytes recibidos o el ID obtenido de la funciones id entrante id salida() o set id valido(). En el campo Datos se anade el paquete de 8 posiciones y sabre mos el numero de bytes de informacion que habra en ese paquete gracias al campo Numero de bytes. En el campo prioridad se indica el orden de salida en caso de haber mas de un paquete en los registros del CAN (como hay 4 registros en CAN, en el campo prioridad habra valores hasta el 3). En nuestro caso hemos puesto la
Esta condicion de nal de datos la tendremos guardada en una variable global que habra sido modi cada por la funcion condicionnal() en la funcion main() del programa.
6
Metodologa
65
maximo prioridad que es la 3. En el campo Extended se indica si se va a utilizar el formato estandar o el extendido. Como nuestros ID son de 11 bits en este campo ponemos TRUE para indicar que estamos con el formato estandar. Por ultimo, en el campo RTR se indica si el paquete es una trama de datos o una trama remota. En nuestro caso anadiremos un FALSE para indicar que se tratan de tramas de datos. La unica diferencia entre el modo I2C y el modo SPI es la forma de recibir los datos. En I2C en primer lugar hemos de declarar la directiva #use I2C en la que se indi cara el modo esclavo (Slave) y la direccion propia del dispositivo (que sera la misma con la que enve los datos el nodo de comunicaciones) para poder recibir correcta mente la informacion. Con la funcion i2c poll() podremos detectar cuando un byte ha llegado en el buffer de transmision. Seguidamente con la funcion i2c read() ob tenemos el valor recibido. Al nal de la interrupcion hemos de volver a declarar la directiva #use I2C en modo Master para poder enviar datos si fuera el caso. En SPI, como desde el principio el protocolo se declara en modo esclavo, no hemos de volverlo a declarar. La funcion utilizada para detectar la recepcion del byte es spi data is in(). Seguidamente con la funcion spi read() se podra obtener el valor. En la gura 2.26 se puede ver el diagrama de ujo de este modulo.
Figura 2.26: Diagrama de ujo del modulo Interrupcion I2C y SPI. Modulo Interrupcion RS232: El proceso seguido en esta interrupcion es exacta mente el mismo que en la interrupcion I2C y SPI, con la unica diferencia que a la getc(). hora de obtener los datos se realiza con la funcion
66
En la gura 2.27 se puede ver el diagrama de ujo de este modulo.
Figura 2.27: Diagrama de ujo del modulo Interrupcion RS232.
2.3. Placa de Adquisicion de Datos

La nalidad de la Placa de Adquisicion de Datos es la de poder integrar 2 ADIS16100 y 2 ADIS16201 para que proporcionen informacion sobre velocidad angular en el eje z y el eje y, as como aceleracion e inclinacion en los 3 ejes. Para llegar a este cometido se utiliza el PIC18F2580 comentado en captulos anteriores. Este PIC extra se necesita para poder controlar los 4 sensores y, una vez recibidos los datos, poder enviar el comando NMEA 7 correspondiente. Utilizaremos el protocolo SPI para comunicarnos con los sensores ADIS y el protocolo RS232 para comunicarnos con el Nodo de Comunicaciones. En los siguientes apartados se describe detalladamente como ha sido el diseno tanto del software como del hardware.
El protocolo NMEA es una especicacion combinada electrica y de datos entre aparatos electronicos marinos, y tambien mas generalmente, para receptores GPS.
7
Metodologa
67
2.3.1. Hardware
2.3.1.1. Esquema electronico Como se puede apreciar en la gura 2.28, esta placa esta formada por unos sensores de la compana Analog Devices ADIS16100 y ADIS16201, y todo el hardware necesario para procesar y transmitir los datos adquiridos.
Figura 2.28: Diagrama esquematico. Placa de Adquisicion de Datos. En esta placa nos ayudaremos con un PIC, en concreto con el PIC18F2580 (ver 1.2.1.), y con un conjunto de bloques para llevar a cabo todas las operaciones necesarias. En oca siones los bloques seran similares a los del nodo de comunicaciones por lo que se haran referencias a guras y tablas anteriores. Algunas explicaciones teoricas seran omitidas puesto que ya han sido descritas en el seccion de hardware del nodo (2.2.1.). A continuacion se presentan cada uno de estos bloques segun su funcion: Bloque de alimentacion 5 V y 3,3 V: En esta placa, el bloque de alimentacion esta dividido en dos secciones.
68
La primera seccion, al igual que en el nodo de comunicaciones, esta compuesta por un condensador electroltico de 47 F y un regulador LM7805, que se encargara de alimentar todo el dispositivo a 5 V incluyendo los sensores, excepto los ADIS16201 que se alimentan a 3,3 V. Como fuente de alimentacion a la entrada del regulador de tension utilizaremos unas bateras de 12 V o 9 V, o bien un transformador de 220 V a 9 V como hacamos en el nodo de comunicaciones. Al igual que para el nodo de comunicaciones, tendremos que ir con mucho cuidado con la polarizacion de alimentacion, puesto que si se conecta al contrario de la gura 2.4, la placa no funcionara y podemos quemar los componentes. La segunda seccion del bloque de alimentacion esta compuesta por otro regulador de tension, concretamente el M1117t-3,3/NOPB, que a partir de los 5 V de entrada procedentes del anterior regulador obtiene los 3,3 V necesarios para alimentar los ADIS16201. A diferencia del bloque anterior en este regulador no es necesario un condensador a la entrada del mismo para eliminar el rizado de la senal de tension, ya que el condensador utilizado a la entrada del LM7805 se encarga de hacerla estable. No obstante, si sera necesario un condensador de 10 F (como mnimo) conectado al Vout del M1117t-3,3 para no llevar a inestabilidad el regulador (ver gura 2.29).
Figura 2.29: M1117t alimentacion ADIS16201 a 3,3 V y condensadores de 10 F.
Bloque del clock: Debido a que el PIC18F4580 (nodo de comunicaciones) y el

PIC18F2580 (placa de adquisicion de datos) son de la misma familia, las conguraciones del clock para ambos PICs son exactamente iguales. As pues trabajaremos con un oscilador de 20 MHz XT (cristal de cuarzo) y los condensadores de 15 pF necesarios para que la estabilidad a esta frecuencia sea la adecuada (Ver gura 2.6 del capitulo 2.2.1.). Bloque de programacion: Al igual que el bloque del clock, el diseno del bloque de programacion en esta placa es practicamente el mismo que el utilizado para el nodo de comunicaciones. Utilizamos un RJ12 conectado a los pines del PIC RB7, RB6, RB5 y MCLR, tambien a 5 V y a GND. La unica diferencia con respecto al nodo, es que el valor de las resistencias conec tadas entre los pines RB7-GND, RB6-GND y RB5-GND es de 1 k y no de 3,3 k como algunos casos en el nodo, ya que en este diseno no hay problemas de impedancias generados por las resistencias de los interruptores que tenemos en la otra placa para seleccionar el protocolo (En la gura 2.30 se puede ver la conguracion).
Bloque de comunicaciones: A n de comunicarse con otros dispositivos (en nuestro caso el nodo de comunicaciones) y transmitir las cadenas NMEA que contienen la informacion, esta placa se ayuda del protocolo RS232.
Metodologa
69
Figura 2.30: Bloque de programacion. Resistencias de 1 k. Por ello, el diseno del hardware necesario sera el mismo que el utilizado en las comunicaciones RS232 del nodo de comunicaciones, con la unica diferencia del conector DB9, que en lugar de ser un DB9 hembra en la placa de adquisicion de datos sera un DB9 macho.
Bloque sensores: Este bloque esta formado por el ADIS16100, el ADIS16201,

unos conectores dual row de 2mm y unas pequenas placas secundarias que utili zaremos para acoplar los sensores a la placa principal sin danar los chips. En el captulo de teora 1.2.2. se explica el funcionamiento y caractersticas de los sensores. Dicho captulo es muy importante a la hora de orientar y colocar los sen sores, puesto que en funcion de los datos que queramos obtener tendremos que congurarlos en el espacio de una forma u otra (En la seccion 2.3.1.2. se explica cual sera la disposicion de estos sensores). La forma de comunicar este bloque con el PIC es muy sencilla. Esto es as ya que utilizamos unos conectores estandares dual row de 2 mm, iguales a los que llevan incorporadas las evaluation boards, que son las tarjetas donde se encuentran los sensores. Siguiendo la gura 2.31, vemos que de lo unico que tendramos que preocuparnos sera de llevar cada pin (SCLK, CS, DOUT, DIN, etc.) que se encuentra en esta tarjeta a su pin correspondiente en la placa. Para facilitar las cosas se ha creado un cable que al conectarlo por cada extremo une directamente cada pin de la placa con el pin correspondiente en la tarjeta donde se encuentran los sensores. Como peculiaridad de este bloque hay que comentar que debido al tamano y con guracion de los sensores, ha sido necesario crear una segunda placa y colocarla en paralelo a la placa principal.
2.3.1.2. PCB El PCB desarrollado para la placa de adquisicion de datos ha sido realizado en las mismas condiciones que el PCB del nodo de comunicaciones. El programa utilizado ha sido P-CAD 2002 y se han usado tando la capa TOP como la BOTTOM.
70
Figura 2.31: Diagrama esquematico de la tarjeta y sus conexiones al conector estandar dual row de 2mm. Posiblemente una de las diferencias mas notorias de las placas es su tamano, concentra cion y compresion de los componentes, y es que a diferencia del nodo de comunicaciones, a la hora de disenar el PCB de la placa de adquisicion de datos uno de los criterios se guidos fue el de elaborar una placa con el menor tamano posible8 , ya que se trata de un dispositivo que debera ir integrado en un vehculo. A la hora de abrir el archivo PCB veremos tres placas diferentes. La mas pequena, que llamamos acopladora, la placa inercial que contiene todos los bloques excepto el de los sensores, y la placa que contiene los sensores.
Placa acopladora: Esta placa nos ayuda a unir los sensores con el dispositivo. Para
ello, se unira la placa acopladora al sensor mediante unos tornillos que pasan por los agujeros de la parte superior de la placa, y esta a su vez se unira a la placa de los sensores (donde estan los agujeros rectangulares) soldandola con estano. Placa inercial: Esta placa contiene toda la electronica necesaria para procesar y comunicar, va puerto serial, los datos que se capturan en la placa de los sensores. Placa de los sensores: Esta placa contiene los sensores y esta en paralelo a la placa anterior. Se conecta mediante unos pines que estan soldados en ambas pla cas de forma que quedan jas y solidarias entre ellas. Ademas estos pines, a nivel de comunicaciones, son utilizados para comunicar los sensores con el PIC. Debido a que los sensores ADIS16100 solo capturan datos sobre un eje y los ADIS16201 en dos, la conguracion y orientacion de los sensores debe corresponder al de la gura 2.32, donde:
Aun as, una de las propuestas de mejoras en este proyecto es utilizar componentes SMD para conse guir reducir el tamano y peso lo maximo posible
8
Metodologa
71
El sensor 1 corresponde a un ADIS16100 en el que se realizan lecturas de cabeceo, giroscopo en eje Z. El sensor 2 corresponde a un ADIS16100 en el que se realizan lecturas de guinada, giroscopo en eje Y. El sensor 3 corresponde a un ADIS16201 en el que se realizan lecturas de aceleracion en el eje X y el eje Z. El sensor 4 corresponde a un ADIS16201 en el que se realizan lecturas de aceleracion en el eje Y y el eje Z.
Figura 2.32: Esquema de la disposicion de los sensores en la placa.
2.3.2. Software
En este apartado se explica todo lo relacionado con el desarrollo del software de la Placa de Adquisicion de Datos. El entorno de programacion utilizado es exactamente el mismo al que se utilizo para desarrollar el software del Nodo de Comunicaciones. Es por ese motivo que se pasa a explicar directamente el Software disenado.
2.3.2.1. Codigo implementado Como se hizo con el diseno del software del Nodo de Comunicaciones, antes de ponerse a escribir el codigo han de quedar claras las principales caractersticas que ha de tener dicho codigo. Hemos considerado que las caractersticas mas relevantes pueden ser las siguientes:
72
Comunicacion Full-duplex en SPI entre el PIC y los ADIS. Se ha de enviar informacion a los ADIS en grupos de 16 bits. Recepcion de datos mediante una interrupcion. El primer y segundo punto nos los marcan las especicaciones de los sensores ADIS. Para utilizar una comunicacion Full-duplex hemos utilizado una funcion que hasta ahora no se haba visto, spi xfer(). Mas adelante se habla con mas detalle de esta funcion. El hecho de enviar 16 bits en un solo ciclo nos acarreo bastantes problemas. En principio, con la funcion spi xfer() se pueden enviar datos de 16 bits. Esto es cierto pero con un pequeno matiz: No es lo mismo utilizar la funcion spi xfer() cuando el protocolo se ha implementado por hardware que cuando se ha implementado por software. La diferencia esta en que en el primer caso se envan los 16 bits, pero despues del octavo clock de reloj la lnea CLK se mantiene en estado alto un cierto tiempo con lo que se perda la comunicacion con el ADIS. Cuando el protocolo se implementa por software, se envan los 16 bits seguidos. No nos pudimos dar cuenta de este hecho hasta que nalmente pudimos examinar el proceso de comunicacion utilizando un osciloscopio. En la gura 2.33 se puede ver la diferencia entre estos dos casos.
Figura 2.33: Ejemplo de envo de 16 bits por SPI. La interrupcion a utilizar para recibir los datos del Nodo de Comunicaciones es la INT RDA, ya que se utilizara el puerto serie para esta comunicacion. En esta interrupcion se cogeran el ID y el comando que se habra enviado por el bus CAN. Una vez recibidos se activara una variable global para habilitar el envo del comando al ADIS correspondiente. Una vez tenemos estos puntos claros, hemos de especicar la jerarqua de cheros que utilizaremos. Tales cheros son los siguientes: adquisicion datos.c: Es donde se encuentra el codigo que se encarga de la inte rrupcion para recibir los datos del Nodo de Comunicaciones, pedir los datos al ADIS, procesarlos y nalmente devolverselos al nodo. Por lo tanto, es donde se encuentra main() del programa. la funcion
Metodologa
73
funciones adis.c: En este chero podemos encontrar las funciones necesarias

para poderse comunicar con los sensores ADIS e interpretar correctamente la infor macion que proporcionan. Las funciones dentro de este chero son las siguientes: seleccion cs(CS, id): Devuelve el pin del CS a utilizar en funcion del ID recibido. grados minuto(comando, recepcion): Procesa los datos recibidos de los sensores ADIS y devuelve la velocidad angular en o /m. Primero se anade la calibracion que se ha calculado en el experimento 3.3.2., y seguidamente se calcula el valor binario de los datos (correspondientes a los ultimos 12 bits de la respuesta de los ADIS) y se multiplica por el valor de la resolucion (0,2439o /s en el caso de velocidad angular). temperatura(comando, recepcion): Procesa los datos recibidos de los sensores ADIS y devuelve la temperatura en o C. Primero hemos de calcular el valor binario de los datos (correspondientes a los ultimos 12 bits de la respuesta de los ADIS) y se multiplica por el valor de la resolucion (0,1453o C en el caso de temperatura). Sumandole 25o C a este resultado, obtendremos el valor de la temperatura interna del ADIS. checksum(checksum1, checksum2): Devuelve el checksum 9 del valor recibido de los ADIS. aceleracion(recepcion, recepcion2, id): Procesa los datos recibidos de los sensores ADIS y devuelve la aceleracion. inclinacion(recepcion, recepcion2, id): Procesa los datos recibidos de los sen sores ADIS y devuelve la inclinacion. temperatura 2(recepcion): Procesa los datos recibidos de los sensores ADIS y devuelve la temperatura. A diferencia de temperatura(comando, recepcion), temperatura 2(recepcion) es para los ADIS201.
funciones adis.h: En esta librera se declaran las funciones de funciones adis.c. 18F2580.h: En esta librera se denen todas las constantes asociadas al PIC18F2580.
En la gura 2.34 se puede ver la dependencia entre cada uno de los cheros. Para poder seguir con mayor facilidad el codigo implementado, se pueden ver el diagramas de ujo del codigo en el Anexo B. Para explicar el codigo, hemos dividido el diagrama de ujo en varios modulos; Modulo Conguracion Placa de Adquisicion de Datos: Es aqu donde se con guran todos los parametros necesarios para el correcto funcionamiento del PIC. Primero se declara la libreria del propio PIC (18F2580.h) para tener todas las de niciones de constantes utilizadas en el codigo, y seguidamente la librera funcio nes adis.c para tener acceso a las funciones denidas por nosotros.
Una suma de vericacion o checksum es una forma de control de redundancia, una medida muy simple para proteger la integridad de los datos, vericando que no hayan sido corrompidos.
9
74
Figura 2.34: Jerarqua de los cheros utilizados en la Placa de Adquisicion de Datos. Seguidamente se declararan las mismas directivas #fuses que se declararon en el software del Nodo de Comunicaciones. Estas son HS, NOWDT, NOLVP y NOPROTECT. El reloj se congura a 20 MHz con la directiva #use delay(clock=frecuencia). Una vez congurados los parametros del PIC18F2580, hemos declarado las varia bles globales a utilizar a lo largo del codigo. En el siguiente paso se inicializan los protocolos RS232 y SPI. Para inicializar el puerto serie se ha utilizado la misma directiva que se utilizo para el Nodo de Comunicaciones. Sin embargo, hemos utilizado una directiva diferente para el protocolo SPI. Como se ha comentado anteriormente, para poder enviar los 16 bits de datos teniamos que implementar el protocolo por software. Esto nos ha obligado a utilizar la directiva #use spi(). A esta directiva se le pueden pasar diferentes parametros, utilizando nosotros los siguientes: MASTER:Para trabajar como Master en la comunicacion. MSB FIRST: Para enviar el bit MSB primero y el LSB ultimo. DI=PIN C4: Declara el PIN C4 como DI. DO=PIN C5: Declara el PIN C5 como DO. CLK=PIN C3: Declara el PIN C3 como CLK. MODE=1: Declara el Modo de SPI. BITS=16: Para enviar 16 bits en el mismo ciclo de reloj. STREAM=adis: Para ponerle un nombre a esta conguracion. Otro gran problema que tuvimos a la hora de implementar el codigo era la decision del modo de trabajo de SPI. En el datasheet del ADIS16100 hacen referencia a la conguracion donde CPOL=1 y CPHA=0. Con esta conguracion, el modo de trabajo es el 2 (Mode=2) pero no obtenamos datos validos de los ADIS.
Metodologa
75
Despues de muchos dias de pruebas infructuosas, se decidio probar con los modos 0, 1 y 3. Fue una gran sorpresa cuando conrmamos que con el modo 1 los ADIS respondian correctamente a todos los comandos. Lo anterior signica que la conguracion correcta es CPOL=0 y CPHA=0. Por lo tanto, de cara a futuros proyectistas, se ha de tener en cuenta este hecho y no tomar como correcto el dato que proporciona el datasheet de Analog Devices. De hecho, no es el unico error encontrado en el datasheet10 . En el Anexo D se muestran todos los errores en dicho datasheet. El modo de trabajo de SPI para los ADIS201 no lo sabemos, ya que no se ha podido experimentar con ellos al quemarse los dos sensores durante las pruebas. Para nalizar, activamos las interrupciones a utilizar y ponemos los 4 CSs de los 4 sensores ADIS en estado IDLE. Despues de realizar todos estos pasos, el codigo entra en un proceso de espera. Esta espera solo se vera interrumpida por la interrupcion RDA o por la habilitacion de la variable para poder enviar los comandos al ADIS y procesar los datos. Una vez nalizados estos dos procesos, se volvera al punto de espera. En la gura 2.35 se observa el diagrama de ujo de este modulo.
Figura 2.35: Diagrama de ujo del modulo Conguracion Placa Adquisicion de Datos. Modulo Interrupcion RDA en ADIS16201: En esta interrupcion se cogeran el ID y el comando enviados por el Nodo de Comunicaciones. Una vez recibido el caracter (char), miramos si ya tenemos el ID o no. Si no lo tenemos, lo cogemos como primer o segundo byte de ID (segun el valor de las variables globales). Si ya tenamos el ID, dicho caracter sera guardado como primer o segundo byte del comando a enviar al ADIS. Una vez ya se tengo el ID y el
10
Ya comprobamos que el datasheet que tenamos fuera la ultima revision
76
comando, se activa una variable para que en la funcion main() se enve el comando, se reciban los datos, se procesen y se enven al Nodo de Comunicaciones. En la gura 2.36 se observa el diagrama de ujo de este modulo.
Figura 2.36: Diagrama de ujo del modulo Interrupcion RDA en ADIS16201. Modulo Pedido y Envio de Datos ADIS: Para poder enviar los comandos, he mos de saber a cual ADIS se han de enviar. Gracias a la funcion seleccion cs(CS, id) podremos asignar el CS al pin correspondiente para comunicarse con el ADIS solicitado. Cuando ya se sabe el CS a utilizar, se puede enviar el comando y recibir los datos. Este proceso, como ya se explico en la seccion 1.2.2.1., se realiza mediante dos ciclos de 16 bits. Es por eso que se utiliza dos veces la funcion spi xfer(). Esta funcion hace lo mismo que el spi read() o spi write() con la diferencia que necesita de la directiva #use spi() para congurarse. De esta forma podremos enviar los 16 bits dentro del mismo ciclo. Tal y como estan situados los ADIS16201, la medida de la aceleracion e inclinacion en el eje z se puede obtener a partir de ambos ADIS16201. Es por este motivo que cuando se recibe el ID 130 o 133 (Ver tabla 2.1) se ha de realizar dos veces el doble ciclo de 16 bits y guardar ambas respuestas. Despues de recibir los datos de los sensores ADIS, hemos de procesar los datos diferenciandolos si son datos de velocidad angular (ID=134 y ID=135), tempera tura de los sensores ADIS16100 (ID=136 y ID=137), aceleracion (ID=128, ID=129 y ID=130), incliniacion (ID=131, ID=132 y ID=133) o temperatura de los sensores ADIS16201 (ID=138 y ID=139). Esta seleccion la realizamos mediante 5 IFs y se en cada uno dependiendo del ID (Ver tabla 2.1). entrara
Metodologa
77
En cada IF se llamara a la funcion correspondiente para procesar los datos, se 11 calculara el checksum de estos datos, y se enviaran por el puerto serie. A la hora de enviar los datos por el puerto serie, se sigue el protocolo NMEA. Este protocolo sigue la estructura de la gura 2.37.
Figura 2.37: Protocolo NMEA. En nuestro caso el ADDRESS sera: INROT: Para informacion de velocidad angular de los ADIS16100. PADIS: Para informacion de temperatura de los ADIS16100 y ADIS16201. PADISACC: Para informacion de aceleracion sobre los ejes del ADIS16201. PADISINC: Para informacion de inclinacion sobre los ejes del ADIS16201. En el campo VALUE se anadiran los 4 caracteres con informacion de los sensores ADIS. Entre el VALUE y el CHECKSUM hemos anadido una caracter para indicar si los datos obtenidos son validos o no. Si el resultado de esta variable es una A, el resultado sera valido. Sin embargo, si es una V el resultado no sera valido. En la gura 2.38 se observa el diagrama de ujo de este modulo.
Actualmente esta funcion solo devuelve dos 0 con lo que se deja para un futuro el calculo real del checksum.
11
78
Figura 2.38: Diagrama de ujo del modulo Pedido y Envio de Datos en ADIS16201.
Experimentos
79
CAPTULO 3. EXPERIMENTOS I
3.1. Introduccion
En este captulo se explican todos los experimentos realizados para poder certicar y validar los requisitos propuestos al principio de esta memoria. Se comprueba tanto el funcionamiento del protocolo en s, como el ujo de datos entre un dispositivo y otro. En el primer apartado se describen los experimentos utilizados para comprobar cada uno de los protocolos implementados en el Nodo de Comunicaciones. Se analiza la interope rabilidad entre los protocolos con los que se uniran al dispositivo (RS232, I2C y SPI) y el CAN. En las pruebas de I2C y SPI hemos utilizado RS232 para poder visualizar la recepcion de datos. Es por ese motivo que los experimentos los hemos llamado I2C-CAN-RS232 (y no I2C-CAN-I2C) y SPI-CAN-RS232 (y no SPI-CAN-SPI). A pesar de esto, demostrando el correcto funcionamiento de esas pruebas, tambien se demuestra el correcto funciona miento de una comunicacion I2C-CAN-I2C y SPI-CAN-SPI. A diferencia del protocolo RS232, con I2C y SPI no tenemos ningun dispositivo que hable directamente en estos protocolos, por lo que se necesita de unos codigos extra. En estos codigos se pretende emular a dispositivos del tipo 1, 2 y 3. Hemos decidido no explicar paso a paso el codigo utilizado ya que no incumbe al Nodo de Comunicaciones, pero s se pueden ver en el Anexo A. Para cada Nodo de Comunicaciones hemos de congurar el chero funciones.c. En los experimentos de la parte del Nodo de Comunicaciones esta conguracion sera la misma y no en cada para todos los Nodos. Es por eso que los vamos a detallar a continuacion experimento. Funcion imprimir id(): En nuestro experimento no sera necesario visualizar los IDs por lo que el return de esta funcion sera FALSE. Si se quieren visualizar por pantalla a traves de HyperTerminal los IDs, simplemente tendremos que cambiar el return a TRUE. Funcion condicionnal(): Conguraremos el return de la funcion a 13 que es un \r en el codigo ASCII. Es este caracter y no otro ya que el caracter 13 del codigo ASCII corresponde a pulsar el intro en el PC, por lo que cuando pulsemos ENTER el nodo interpretara esta accion como nal de condicion. Funcion id valido(): Los IDs que enviaremos han sido previamente calculados de forma que sean validos para el protocolo CAN. Por lo tanto, esta funcion ha de retornar un TRUE. Funcion set id vallido(): No hace falta congurar esta funcion, puesto que nunca la utilizaremos. Funcion condicion nal can(): Esta funcion siempre retornara el valor 13 (\r).
80
Las funciones seleccion mensaje(), id entrada id salida() y mensaje a responder() se comentaran en cada experimento. Tanto para familiarizarnos como para comprobar el correcto funcionamiento del bus CAN en general, nos hemos ayudado de los ejercicios proporcionados junto con el kit de desa rrollo CAN que tienen en el departamento de electronica de la EPSC. Estos ejercicios realizados no los hemos incluido en este captulo ya que no son experi mentos propios del Nodo de Comunicaciones sino del protocolo en general en una placa de pruebas. Es por este motivo que hemos decidido incluir los ejercicios realizados en esta placa de pruebas en el Anexo F. En el segundo apartado se describen los experimentos realizados sobre los MEMS ADIS. Primero se comprobara la correcta recepcion de datos de un solo ADIS16100 y seguidamente la operabilidad entre los dos diferentes ADIS16100. No se ha podido trabajar con los dos ADIS16201 de que disponamos debido a diversos problemas que se tuvo con ellos. Uno de ellos se quemo al tocar accidentalmente el cable la regleta de los 9V (cuando su alimentacion es de 3,3V) y el segundo de alimentacion ADIS16201 tenia continuidad entre la alimentacion y el GND. Aun as, se ha disenado tanto el software como el hardware necesario para que en un futuro se puedan anadir esos dos sensores ADIS16201. Un ultimo experimento consiste en la union del Nodo de Comunicaciones, la Placa de Adquisicion de Datos, un GPS y un PC para poder monitorizar toda la informacion a traves de otro PC. De esta forma se comprobara el funcionamiento global del sistema utilizando diferentes dispostivios a la vez. Es importante destacar que tanto los experimentos del Nodo de Comunicaciones como los de la Placa de Adquisicion de Datos se han realizado sobre las protoboards en las que se montaron todos los elementos. Una vez comprobado que se obtenan resultados positivos de los experimentos, se paso a disenar el circuito impreso con P-CAD 2002 para su posterior fabricacion. Volvimos a realizar los experimentos hechos anteriormente en las protoboards para corroborar el funcionamiento del circuito impreso.
3.2. Nodo de comunicaciones

3.2.1. RS232-CAN-RS232
El montaje realizado en este experimento es el siguiente:
1. Conectar el PC1 por el puerto serie al conector DB9 del Nodo de Comunicaciones. Esta conexion se realizara mediante un cable NULL MODEM (Ver gura 3.3). 2. Conectar el bus CAN de los dos Nodos de Comunicaciones mediante dos cables (CANH y CANL).
Experimentos
81
3. Conectar los GND de los dos Nodos de Comunicaciones. 4. Conectar el PC2 mediante un cable NULL MODEM al otro Nodo de Comunicacio nes. Este PC sera el que lea la informacion enviada por el PC1. 5. Tanto para escribir como para recibir la informacion nos ayudaremos de la aplicacion HyperTerminal de Windows. Por lo tanto, el siguiente paso es abrir este programa y congurarlo tal y como se presenta en la gura 3.1. Se ha de congurar en el puerto donde se conecte el cable NULL MODEM, que en nuestro caso es el COM1.
Figura 3.1: Conguracion HyperTerminal. 6. Conectar los dos Nodos de Comunicaciones a la alimentacion. 7. Poner el interruptor correspondiente a RS232 en ON, y los otros dos interruptores en OFF (Ver gura 3.2).). 8. Finalmente, para los experimentos en los que se utilizen tres nodos y tres PCs, la conexion CAN se tendra que hacer conectando los tres nodos a un bus general(CANH y CANL) con dos resistencias de 120 en paralelo en cada extremo (como se comento en el apartado 2.2.1.).
El montaje nal se puede observar en las guras 3.3 y 3.4. Antes de realizar los experimentos hemos de congurar las funciones seleccion mensaje, id entrante id salida y mensaje a responder. De esta manera podremos trabajar con dispositivos del tipo 1, 2 y 3.
82
Figura 3.2: Interruptor RS232 en ON. En la funcion seleccion mensaje anadiremos los IDs 778, 779 y 1931. Al mensaje con ID = 778 = 1100001010 lo trataremos como paquete del tipo Datos mientras que al mensaje con ID = 779 = 1100001011 lo trataremos como paquete del tipo Comando. El paquete con el ID = 1931 sera el paquete respuesta al Comando. En estos experimentos tambien utilizaremos el ID = 796 = 1100011100 para comprobar que nuestros ltros no lo aceptan y por lo tanto comprobar que funcionan correctamente. En la funcion id entrante id salida indicamos la relacion entre ID de entrada y de salida. En nuestro caso, para obtener la ID de salida sumaremos 1152 a la ID de entrada (por eso hemos de aceptar los paquetes con ID = 1931). En la funcion mensaje a responder anadiremos el ID = 779. En resumen:
IDs a aceptar: 778, 779 y 1931 ID salida = ID entrada + 1152 ID de paquete tipo Comando: 779
Una vez tenemos programadas las funciones, el PC1 debera empezar transmitiendo los dos bytes de informacion del ID. Por ejemplo, si queremos enviar el ID = 778 tendremos que escribir como primer caracter la letra a = 97 = 1100001 (recordar que RS232 es orientado a caracteres), y como segundo caracter la letra b = 98 = 1100010 (para el ID = 779 los caracteres a enviar seran la letra a y la c). A partir de este punto todos los caracteres que se enven han de ser procesados como datos y no como ID. Para comprobar el correcto funcionamiento del puerto serie realizamos las siguientes pruebas:
Prueba 1: El PC1 enva ab12345678ab12345678\r y el PC2 tendra que recibir 12345678ab12345678\r. Esta prueba nos sirve para ver si se transmite y recibe
correctamente tanto el ID como los datos.
Experimentos
83
Figura 3.3: Esquema montaje experimentos RS232-CAN-RS232.
Prueba 2: El PC1 enva cd12345678ab12345678\r y el PC2 tendra que recibir .

En esta prueba, al igual que la anterior, se pretende comprobar que el ID y los datos se envan correctamente. Pero en este caso al enviar otro ID, no tendra que salir nada por el Hyperterminal del PC2.
Prueba 3: El PC1 enva ab1234567812\rab1234567812\r y el PC2 tendra que recibir 1234567812\r1234567812\r. Esta prueba nos sirve para ver si despues de de nal de datos (\r) enviada en medio de los datos, la comunicacion una condicion
se inicia correctamente.
Prueba 4: El PC1 enva ab1234567812\rcd1234567812\r y el PC2 tendra que recibir 1234567812\r. Al igual que en la prueba anterior, en esta se pretende ver si despues de un \r enviado en medio de los datos, la comunicacion se inicia co rrectamente aunque se enve un ID erroneo.
Prueba 5: El PC1 enva ab\rab1234567812\r y el PC2 tendra que recibir \r1234567812\r. Esta prueba nos sirve para ver si despues de una condicion de
nal de datos enviada justo despues del segundo byte con informacion de ID, la comunicacion se inicia correctamente.
Prueba 6: El PC1 enva ab\rcd1234567812\r y el PC2 tendra que recibir \r. Al igual que en la prueba anterior, en esta se pretende ver si despues de un \r
enviada justo despues del segundo byte con informacion de ID, la comunicacion se inicia correctamente aunque se enve un ID erroneo.
Prueba 7: El PC1 enva a\rab1234567812\r y el PC2 tendra que recibir
84
Figura 3.4: Montaje experimentos RS232-CAN-RS232. 1234567812\r. Esta prueba nos sirve para ver si despues de una condicion de nal de datos enviada despues del primer byte con informacion de ID, la comunicacion se inicia correctamente.
Prueba 8: El PC1 enva a\rcd1234567812\r y el PC2 tendra que recibir . En esta

prueba, al igual que en la anterior, se pretende ver si despues de una condicion de nal de datos enviada despues del primer byte con informacion de ID, la comunica cion se inicia correctamente aunque se enve un ID erroneo.
Prueba 9: El PC1 enva \rab1234567812\r y el PC2 tendra que recibir 1234567812\r. Esta prueba nos sirve para ver si despues de una condicion de
nal de datos enviada justo al inicio de la comunicacion, la comunicacion se inicia correctamente.
Prueba 10: El PC1 enva \rcd1234567812\r y el PC2 tendra que recibir . En esta
prueba, al igual que en la anterior, se pretende ver si despues de una condicion de nal de datos enviada justo al inicio de la comunicacion, la comunicacion se inicia correctamente aunque se enve un ID erroneo.
Prueba 11: El PC1 enva ab123456781234\r\rab123456\r y el PC2 tendra que recibir 123456781234\r123456. Esta prueba nos sirve para ver si enviar dos con diciones de nal de comunicacion seguidas afecta a la siguiente comunicacion. Prueba 12: Una ultima prueba es la de la comunicacion en ambos sentidos. En este caso, los dos PC solo estaran para recibir los datos. La transmision de datos se hara a traves de los PICs. Se programaran para que justo despues de un reseteo se enve 123456781234567812345678.
Experimentos
85
Prueba 13: Esta prueba es exactamente igual que la anterior con la diferencia de
que los dos PC haran de receptores y transmisores. En cada uno escribiremos ab123456781234567812345678\r. Los resultados de las 13 pruebas son los mostrados en la gura 3.5.
Figura 3.5: Resultado de las pruebas 1 a la 13. Despues de estas pruebas, corroboramos el correcto funcionamiento de la recepcion del ID y de los datos y su posterior envo. Pero solo se han hecho las pruebas para los envos de paquetes del tipo Datos. Seguidamente pasamos a realizar las pruebas para comprobar el funcionamiento de la co municacion en el caso de enviar paquetes del tipo Comando (no se volvera a comprobar el correcto funcionamiento de la recepcion de IDs). Prueba 14: El PC1 enva ac1234\r. Al ser un comando, el PC2 recibira 1234\r y tendra que contestar. En el PC2 escribiremos ab1234\r. El PC1 recibira ab1234\r. Esta prueba nos sirve para ver si despues de enviar un Comando, los dos primeros bytes que enva el dispositivo los lee como datos o como ID. Si funciona correc tamente, ha de coger los dos primeros bytes como datos y el ID obtenerlo de la funcion id entrante id salida.
86
Prueba 15: Una ultima prueba es realizar la comunicacion entre tres PCs en el que cada uno enviara datos con un ID diferente y aceptara paquetes de uno de los otros dos PC. Por ejemplo, el PC1 enva datos con el ID = 778 y acepta el ID = 779, el PC2 enva con ID = 800 y acepta el ID = 778, y el PC3 enva con ID = 779 y acepta el ID = 800 (Ver gura 3.6). En esta prueba solo nos interesa saber si el bus CAN funciona correctamente con mas de un Nodo, y por lo tanto no es de importancia si se envian paquetes del tipo Datos o Comandos. Para facilitar la prueba se decidio enviar todos los paquetes como si fueran del tipo Datos. Por lo tanto, en la funcion mensaje a responder no pondremos ningun ID.
Figura 3.6: Esquema: Ejemplo de la distribucion de IDs entre 3 PCs.
Despues de realizar las 15 pruebas, hemos podido certicar el correcto funcionamiento de la interaccion entre los protocolos RS232 y CAN en los Nodos de Comunicaciones.
3.2.2. I2C-CAN-RS232
En este montaje se corroborara el correcto funcionamiento entre el protocolo I2C y CAN. Para ello son necesarios tres nodos de comunicaciones1 y un PC. El montaje es el siguiente:
Conectar los pines del UserTerminal del nodo 1 al nodo 2. Conectaremos el SDA
1
Un nodo estara congurado de forma que simule un dispositivo I2C y no como nodo de comunicaciones.
Experimentos
87
del nodo 1 al SDA del nodo 2, el SCLK del nodo 1 al SCLK del nodo 2, y el GND del nodo 1 al GND del nodo 2.
Conectar el bus CAN entre los nodos 2 y 3 mediante los pines CANH y CANL del
UserTerminal.
Conectar los GND de los nodos 2 y 3. Al nodo 3 conectaremos en el puerto serie un cable NULL MODEM. Al otro extremo
del cable NULL MODEM conectaremos el PC. Este PC leera la informacion que le llegue y la mostrara por el HyperTerminal.
Congurar el Hyperterminal como se muestra en la gura 3.1.

Como el nodo 2 sera el que reciba o enve datos por I2C, hemos de poner en ON el interruptor de I2C y a OFF el de RS232 y SPI2 (Ver gura 3.7). En el nodo 3 solo hemos de activar el interruptor correspondiente a RS232. En el primer nodo no hara falta el interruptor porque ya estara programado como si fuera un dispositivo I2C.
Figura 3.7: Interruptor I2C en ON. Activar los interruptores de las resistencias de PULL-UP en el nodo 1 o 2.
Programar el nodo 1 con los cheros experimentos i2c.c y experimentos i2c modo2.c
(Ver Anexo A). Con estos codigos conguraremos el nodo como dispositivo del tipo 1 o 2.
El montaje nal del experimento se puede observar en la gura 3.8. Las pruebas a seguir en este experimento son las mismas que las utilizadas en el experi mento RS232-CAN-RS232. La unica diferencia sera que el nodo transmisor en este caso
Recordar que la inicializacion del protocolo SPI descongura la del I2C. Por este motivo se recomienda hacer un reset y despues poner en ON el interruptor de I2C.
2
88
Figura 3.8: Esquema montaje experimentos I2C-CAN-RS232. enviara los datos justo despues de conectarlo a la alimentacion ya que estara implemen tado en el codigo (debido a que nosotros a traves del ordenador no podemos escribir en I2C). Se han de volver a congurar las funciones seleccion mensaje, id entrante id salida y mensaje a responder con los ID ha utilizar de la misma forma que se hizo en el experimento anterior. Con el codigo experimentos i2c.c simulamos un dispositivo del tipo 1. De esta forma, enviaremos un numero de bytes con un ID correspondiente a un paquete del tipo Datos (o sea, que no necesite respuesta). Con este codigo podremos hacer las pruebas 1-13. Con el codigo experimentos i2c modo2.c simulamos un dispositivo del tipo 2 o 3. De esta forma, desde el PC podremos enviar un Comando para que el dispositivo nos conteste. Con este codigo podremos hacer la prueba 14. La prueba 15 no se realiza en este caso debido a la imposibilidad de poder escribir datos en I2C en cualquier momento. Despues de realizar las 14 pruebas, hemos podido certicar el correcto funcionamiento de la interaccion entre los protocolos I2C y CAN en los Nodos de Comunicacion.
3.2.3. SPI-CAN-RS232
En este montaje se corroborara el correcto funcionamiento entre el protocolo SPI y CAN. Para ello son necesarios tres nodos de comunicaciones y un PC. Al igual que en el experimento anterior, uno de los nodos lo programaremos adecuadamente para que pueda simular un dispositivo del tipo 1 o 2. El montaje es el siguiente:
Conectar los pines del UserTerminal del nodo 1 al nodo 2. Conectaremos el SDO
del nodo 1 al SDI del nodo 2, el SDI del nodo 1 al SDO del nodo 2, el SCLK del nodo 1 al SCLK del nodo 2, y el GND del nodo 1 al GND del nodo 2.
Conectar el bus CAN entre los nodos 2 y 3 mediante los pines CANH y CANL del
UserTerminal.
Experimentos
89
Conectar los GND de los nodos 2 y 3. Al nodo 3 conectaremos en el puerto serie un cable NULL MODEM. Al otro extremo
del cable NULL MODEM conectaremos el PC. Este PC leera la informacion que le llegue y la mostrara por HyperTerminal.
Congurar el Hyperterminal como se muestra en la gura 3.1.

Como el nodo 2 sera el que reciba o enve datos por SPI, hemos de poner en ON el interruptor de SPI y a OFF el de RS232 y I2C (Ver gura 3.9). En el nodo 3 solo hemos de activar el interruptor correspondiente a RS232. En el primer nodo no hara falta el interruptor porque ya estara programado como si fuera un dispositivo SPI.
Figura 3.9: Interruptor SPI en ON.
Programar el nodo 1 con los cheros experimentos spi.c y experimentos spi modo2.c
(Ver Anexo A). Con estos codigos conguraremos el nodo como dispositivo del tipo 1 o 2. El montaje nal del experimento se puede observar en la gura 3.10. Las pruebas a seguir en este experimento son las mismas que las utilizadas en el experimento RS232-CAN-RS232. Al igual que en el experimento anterior, la unica diferencia sera que el nodo transmisor enviara los datos justo despues de conectarlo a la alimenta cion ya que estara implementado en el codigo (debido a que nosotros a traves del ordenador no podemos escribir en SPI). Se ha de volver a congurar las funciones seleccion mensaje, id entrante id salida y mensaje a responder con los ID a utilizar de la misma forma que se hizo en el experimento RS232-CAN-RS232. Con el codigo experimentos spi.c simulamos un dispositivo del tipo 1. De esta forma, enviaremos un numero de bytes con un ID correspondiente a un paquete del tipo Datos (o sea, que no necesite respuesta).
90
Figura 3.10: Esquema montaje experimentos SPI-CAN-RS232. Con este codigo podremos hacer las pruebas de 1-13. Con el codigo experimentos spi modo2.c simulamos un dispositivo del tipo 2 o 3. De esta forma, desde el PC podremos enviar un Comando para que el dispositivo nos conteste. Con este codigo podremos hacer la prueba 14. La prueba 15 no se realiza en este caso debido a la imposibilidad de poder escribir datos en SPI en cualquier momento. Despues de realizar las 14 pruebas, hemos podido certicar el correcto funcionamiento de la interaccion entre los protocolos SPI y CAN en los Nodos de Comunicacion.
3.3. Placa de adquisicion de datos

3.3.1. Recepcion de datos de un solo ADIS16100
Con este experimento se pretende recibir correctamente los datos del ADIS16100. Este paso es necesario hacerlo antes de realizar el experimento en el que comunicaremos un PC mediante CAN a la Placa de Adquisicion de Datos con los dos ADIS16100. El codigo utilizado en este experimento no sera el codigo denitivo en la Placa de Ad de Datos pero se puede ver en el Anexo A con el nombre de experimenquisicion to solo 1 adis.c. Para ello conguraremos el sensor de las 4 formas diferentes (Temperatura en Offset Bi nary y Complemento a 2 y velocidad angular tambien en esos dos formatos) y despues de cada conguracion se enviaran 700 pedidos de lectura. Todas estas lecturas se guardan en memoria para despues imprimirlas por pantalla. Tanto con los comandos de conguracion como en los de lectura, primero hemos de habi litar el CS. Una vez habilitado el CS podemos enviar el comando con la funcion spi xfer(). Es en este punto donde se encuentra la diferencia entre comando de conguracion y comando de lectura. En nuestro experimento hemos utilizado los siguientes comandos3 :
3
Ver tabla 1.8 para recordar que signicaba cada bit en el registro DIN del ADIS16100
Experimentos
91
33552: Este numero corresponde a los bytes 1000001100010000. Con lo que con
guraremos el sensor para que proporcione datos de velocidad angular en formato Offset Binary.
guraremos el sensor para que proporcione datos de velocidad angular en formato Complemento a 2.
guraremos el sensor para que proporcione datos de temperatura en formato Offset Binary.
guraremos el sensor para que proporcione datos de temperatura en formato Complemento a 2.
784: Este numero corresponde a los bytes 1100010000. Con lo que podremos
obtener datos del sensor sin recongurarlo.
Como se comento en los captulos 2.3.2. y 1.2.2.1., el ADIS funciona con ciclos de 16 bits. Para poder enviar 16 bits seguidos, implementamos el protocolo SPI por software utilizando la directiva #use spi(master, MSB FIRST, DI=PIN C4, DO=PIN C5, CLK=PIN C3, MODE=1, BITS=16, STREAM=adis). Con esta directiva podremos trabajar como Master, enviar el MSB primero, congurar los pines de los dos cables de datos y el del reloj, y sobretodo determinar el Modo de funcionamiento que en nuestro caso es el Modo 14 . Los resultados esperados deberan ser los siguientes (Ver tabla 1.9 para recordar que signicaba cada bit en el registro DOUT del ADIS16100):
Para datos de velocidad angular en Offset Binary: Suponiendo que tenemos los
sensores sin movimiento, el resultado obtenido debera estar entorno al 0000100000000000.
Para datos de velocidad angular en Complemento a 2: Suponiendo que tenemos

los sensores sin movimiento, el resultado obtenido debera estar entorno al 0000000000000000.
Para datos de temperatura en Offset Binary: Suponiendo que la temperatura interna de los sensores es de 25o C, el resultado obtenido debera estar entorno al 0001100000000000.
Para datos de temperatura en Complemento a 2: Suponiendo que la temperatura

interna de los sensores es de 25o C, el resultado obtenido debera estar entorno al 0001000000000000.
El montaje realizado en este experimento es el siguiente:

4
Ver Anexo D para ver porque es el Modo 1
92
Conectar los pines de los conectores J1 y J2 (Ver gura 2.31) de la placa de eva luacion de los ADIS16100 a los conectores dual row. Se supone que los sensores ADIS ya estaran situados en la Placa de Adquisicion de Datos, y por lo tanto este paso nos lo podramos saltar. Conectar el cable Null Modem de la placa de Adquisicion de datos al PC.
Congurar el Hyperterminal del PC como se muestra en la gura 3.1. Congurar el Hyperterminal para que capture los datos en un chero .txt5 .
Conectar la alimentacion a la placa.
Programar el PIC18F2580 con el chero experimento solo 1 adis.c. Esperar a recibir 4 veces los 700 datos solicitados al ADIS16100. Congurar el Hyperterminal para que pare de capturar los datos6 .
Una vez realizados estos pasos, podremos ver el chero .txt para comparar los resultados obtenidos con los teoricos. Haciendo estas comparaciones podremos ver si el sensor esta bien calibrado. En el caso de las medidas de temperatura no podemos saber si el sensor esta bien calibrado o no (porque no tenemos ninguna referencia para compararlo). Aun as, los resul tados han sido satisfactorios porque estan alrededor de un valor razonable (22o C). Los resultados se pueden observar en las guras 3.11 y 3.12.
Figura 3.11: Resultados de temperatura en Offset Binary del primer ADIS16100.

5 6
Ir al menu Transferir > Capturar Texto > Iniciar Ir al menu Transferir > Capturar Texto > Parar
Experimentos
93
Figura 3.12: Resultados de temperatura en Complemento a 2 del primer ADIS16100. En el caso de las medidas de velocidad angular s que tenemos una referencia7 . Los resultados se pueden observar en las guras 3.13 y 3.14. Como se puede observar, tenemos un Offset8 en las medidas entorno a los 47 LSB. A una resolucion de 0,2439o /s/LSB a este offset le corresponde un error de alrededor de o 11,46 /s. Para evitar este error, en la funcion grados minuto(comando, recepcion) del chero ad quisicion datos.c (que sera el chero nal que se programara en la placa) se le restara este error a las medidas efectuadas. Tanto en los resultados de temperatura como de velocidad angular se puede observar que tenemos una deriva. Esta deriva nos proporcionara un error maximo de no mas de 5,5o /s o 9 o 6 C. Desgraciadamente este error no se puede corregir . Estos son los resultados de calibracion del primer ADIS16100, pero aun queda por calibrar el segundo ADIS16100. El proceso es el mismo y los resultados obtenidos se pueden observar en las guras 3.15, 3.16, 3.17 y 3.18. El offset obtenido en los datos de velocidad angular de este ADIS16100, tambien se tendra en cuenta en la funcion grados minuto(comando, recepcion) del chero adquisicion datos.c. Podemos observar que el error maximo que pueden tener los dos ADIS16100 es practi camente identico. En lo unico que varan es en el offset de los datos de velocidad angular. Al ser mas grande en el primer ADIS16100, la compensacion que tendremos que anadir en la funcion grados minuto(comando, recepcion) sera tambien mas grande.
7 8
Como el sensor no se mueve, la velocidad angular ha de ser 0. Diferencia entre valor teorico y valor real 9 Aunque se podra compensar parcialmente tomando varias medidas
94
Figura 3.13: Resultados de velocidad angular en Offset Binary del primer ADIS16100. Es importante destacar que el offset entre ADIS es diferente, pero en todo caso para el mismo ADIS el offset para los datos en formato Offset Binary y Complemento a dos debera ser igual. En nuestro caso eso se cumple; en el primer ADIS16100 tenemos offset de 47,1 LSB y 47,08 LSB mientras que para el segundo ADIS16100 tenemos offsets de -11,46 LSB y -11,14 LSB. Con estas pruebas hemos podido corroborar la correcta recepcion de datos y ademas hemos podido calibrar los sensores.
3.3.2. Recepcion de datos de la Placa de Adquisicion de Datos por bus CAN

En este experimento se pretende corroborar el correcto funcionamiento de la comuni cacion entre un PC y la placa de Adquisicion de Datos mediante el bus CAN. En este caso, la placa de Adquisicion de Datos tendra incorporado los dos ADIS16100 y los dos ADIS16201. Al utilizar un PC como transmisor de comandos y receptor de datos, tuvimos una serie de problemas. Los IDs asociados para la placa de adqusicion de datos no los podemos dividir en dos bytes (Ver gura 2.24). Estos dos bytes resultaran ser dos caracteres no imprimibles, y por lo tanto no se podran enviar por Hyperterminal. Para evitar esto, hemos disenado dos funciones llamadas confgi interfaz() y interfaz(). Estas dos funciones estan declaradas en funciones.c. En la funcion confgi interfaz() se habilitara o deshabilitara la utilizacion de la funcion interfaz(). Esta ultima funcion devolvera el ID y los datos necesarios para poder enviar un paquete
Experimentos
95
Figura 3.14: Resultados de velocidad angular en Complemento a 2 del primer ADIS16100. CAN a la Placa de Adquisicion de Datos dependiendo del numero que escribamos por el Hyperterminal. Se enva un 1: La funcion devolvera el ID = 136 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (183 y 208) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 47056, con el que podremos obtener informacion de temperatura interna en Offset Binary (Recordar tabla 1.8). Con el ID = 136 indicamos que la informacion la queremos del primer ADIS16100 (Recordar tabla 2.1). Se enva un 2: La funcion devolvera el ID = 136 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (135 y 0) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 34560, con el que podremos obtener informacion de temperatura interna en Complemento a 2 (Recordar tabla 1.8). Con el ID = 136 indicamos que la informacion la queremos del primer ADIS16100 (Recordar tabla 2.1). Se enva un 3: La funcion devolvera el ID = 137 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (183 y 208) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 47056, con el que podremos obtener informacion de temperatura interna en Offset Binary (Recordar tabla 1.8). Con el ID = 137 indicamos que la informacion la queremos del segundo ADIS16100 (Recordar tabla 2.1).
96
Figura 3.15: Resultados de temperatura en Offset Binary del segundo ADIS16100. Se enva un 4: La funcion devolvera el ID = 137 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (135 y 0) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 34560, con el que podremos obtener informacion de temperatura interna en Complemento a 2 (Recordar tabla 1.8). Con el ID = 137 indicamos que la informacion la queremos del segundo ADIS16100 (Recordar tabla 2.1). Se enva un 5: La funcion devolvera el ID = 134 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (131 y 16) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 33552, con el que podremos obtener informacion de velocidad angular en Offset Binary (Recordar tabla 1.8). Con el ID = 134 indicamos que la informacion la queremos del primer ADIS16201 (Recordar tabla 2.1). Se enva un 6: La funcion devolvera el ID = 134 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (131 y 0) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 33536, con el que podremos obtener informacion de velocidad angular en Complemento a 2 (Recordar tabla 1.8). Con el ID = 134 indicamos que la informacion la queremos del primer ADIS16201 (Recordar tabla 2.1). Se enva un 7: La funcion devolvera el ID = 135 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (131 y 16) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 33552, con el que podremos obtener informacion de velocidad angular en Offset Binary (Recordar
Experimentos
97
Figura 3.16: Resultados de temperatura en Complemento a 2 del segundo ADIS16100. tabla 1.8). Con el ID = 135 indicamos que la informacion la queremos del segundo ADIS16201 (Recordar tabla 2.1). Se enva un 8: La funcion devolvera el ID = 135 y 3 bytes de informacion. Dos bytes con informacion del comando a enviar a los ADIS (131 y 0) y una condicion de nal de datos (13). Con los dos bytes con informacion de comando obtendran el valor 33536, con el que podremos obtener informacion de velocidad angular en Complemento a 2 (Recordar tabla 1.8). Con el ID = 135 indicamos que la informacion la queremos del segundo ADIS16201 (Recordar tabla 2.1).
Estas modicaciones de codigo en funciones.c se han hecho para facilitar el envo y la visualizacion de los Datos. Pero una vez se haya realizado el experimento se pueden eliminar estas partes de codigo y no afectara en nada al funcionamiento global. Antes de programar los codigos en los PICs hemos de recongurar la funcion funciones.c para cada Nodo de Comunicaciones, ya que cada dispositivo tiene un funcionamiento diferente. Estas conguraciones son las siguientes:
Para el Nodo conectado al PC:

Funcion seleccion mensaje(): Este PC aceptara IDs de la placa de adquisi cion de datos(1280-1291) y del reset de comunicaciones (0). Funcion id entrada id salida(): No es necesario congurar esta funcion porque no vamos a responder a ningun mensaje en nuestro experimento. Funcion mensaje a responder(): Debido a que en el caso de nuestro expe rimento los paquetes que vamos a recibir no tendran respuesta, el vector de que estar vaco (encontrado=false;). IDs tendra
98
Figura 3.17: Resultados de velocidad angular en Offset Binary del segundo ADIS16100. Funcion imprimir id(): En nuestro experimento no sera necesario visualizar los IDs, por lo que el return de esta funcion sera FALSE. Si se quieren visua lizar por pantalla a traves de HyperTerminal los IDs, simplemente tendremos que cambiar el return a TRUE. Funcion condicionnal(): Conguraremos el return de la funcion a 13 que es un \r en el codigo ASCII. Es este caracter y no otro ya que el caracter 13 del codigo ASCII corresponde a pulsar el intro en el PC1, por lo que cuando pulsemos ENTER el nodo interpretara esta accion como nal de condicion. Funcion id valido(): Los IDs que enviamos por el PC1 al nodo han sido pre viamente calculados de forma que sean validos para el protocolo CAN, propor cionandole al paquete en cuestion prioridad media y tipo de mensaje evento. Por lo tanto, esta funcion ha de retornar un TRUE. Funcion set id valido(): No hace falta congurar esta funcion, puesto que nunca la utilizaremos. Funcion cong interfaz(): Al igual que en el experimento 3.3.2., para facilitar la transmision de datos de la placa de adquisicion de datos al PC1 utilizaremos esa misma interfaz. De modo que para habilitarla tendremos que congurar el return de esta funcion a TRUE (solo en este nodo). Funcion condicion nal can(): En esta funcion se ha de asociar los IDs 0, 134, 135, 136 y 137 a \r como condicion nal, y los IDs 1286, 1287, 1288 y 1289 a \n como condicion nal. Para el Nodo conectado a la Placa de Adquisicion de Datos: Funcion seleccion mensaje(): Para la seleccion de mensajes en la placa de adquisicion de datos, y por lo tanto para la conguracion del vector de IDs a aceptar, seguiremos la tabla 2.2.
Experimentos
99
Figura 3.18: Resultados de velocidad angular en Complemento a 2 del segundo ADIS16100. Funcion id entrada id salida(): Este dispositivo responde a paquetes entran tes. Debido a que en la informacion que envan los chips ADIS16100 y ADIS16201 no se encuentran los IDs de los mensajes que se enviaran, se los hemos de agregar nosotros. Observando la tabla2.1 determinamos la re lacion ID de entrada-salida. En nuestro caso esta relacion sera: id entrada + 1152LSB. Funcion mensaje a responder(): Se han de incluir los mismos IDs que en la funcion seleccion mensaje(), menos el ID = 0 ya que no queremos responder al Reset de las comunicaciones. Funcion imprimir id(): Debido a que los IDs son necesarios en la placa de adquisicion de datos para saber que sensor tiene que capturar los datos, debemos enviar (imprimir) el ID al dispositivo. Conguraremos el return a TRUE. Funcion condicionnal(): Conguraremos el return de la funcion a 10 que es un \n en el codigo ASCII. Esto es debido a que en el protocolo standard NMEA, utilizado en la placa de adquisicion de datos, cuando se naliza una transmision de datos el ultimo caracter es \n (ver gura 2.37). Funcion id valido(): Este dispositivo no enva IDs con el formato adecuado para CAN (por prioridades, tipos de paquetes, etc), por lo tanto el return de esta funcion tendra que ser congurado a False ya que no es valido. Funcion set id valido(): Esta funcion no la tendremos que congurar, puesto que previamente en la funcion id entrada id salida() hemos calculando el ID de salida en funcion del ID de entrada. Funcion cong interfaz(): En este nodo no es necesario utilizar la interfaz para enviar y recibir datos de la placa de adquisicion de datos por lo que debemos congurar el return a False.
100
Funcion condicion nal can(): En esta funcion se han de asociar los IDs 0, 134, 135, 136 y 137 a \r como condicion nal, y los IDs 1286, 1287, 1288 y 1289 a \n como condicion nal. El montaje realizado en este experimento es el siguiente:
Conectar el puerto serie del PC al conector DB9 de un Nodo de Comunicaciones

mediante un cable Null Modem.
Conectar el bus CAN de los dos Nodos de Comunicaciones mediante dos cables
(CANH y CANL).
Conectar el GND de los dos Nodos. Conectar mediante un cable Null Modem el otro Nodo de Comunicaciones con la
Placa de Adquisicion de Datos.
Congurar el Hyperterminal del PC como se muestra en la gura 3.1.

Conectar la alimentacion a los dos Nodos de Comunicaciones y a la Placa de Ad quisicion de Datos.
Programar el chero tfc.c en los Nodos de Comunicaciones (modiciar en cada caso

el archivo funciones.c como se ha comentado anteriormente). Programar el chero adquisicion datos.c en la Placa de Adquisicion de datos.
Conectar los interruptores correspondientes al protocolo RS232 en los dos Nodos.

El montaje nal del experimento se puede observar en la gura 3.19.
Figura 3.19: Esquema del experimento Recepcion de datos de la Placa de Adquisicion. Una vez realizados estos pasos, estamos preparados para enviar comandos a la Placa de Adquisicion de Datos. La prueba que se ha realizado es bastante sencilla. Escribiremos 3 veces seguidas en el Hyperterminal los numeros del 1 al 8. De esta forma pediremos 3 veces datos de temperatura y velocidad angular en los dos formatos y a los dos ADIS. Los resultados obtenidos tendran que ser los siguientes:
Experimentos
101
Cuando escribimos un 1: Se pide informacion de temperatura y deberamos recibir $PADIS,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 2: Se pide informacion de temperatura y deberamos recibir $PADIS,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 3: Se pide informacion de temperatura y deberamos recibir $PADIS,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 4: Se pide informacion de temperatura y deberamos recibir $PADIS,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 5: Se pide informacion de velocidad angular y deberamos recibir $INROT,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 6: Se pide informacion de velocidad angular y deberamos recibir $INROT,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 7: Se pide informacion de velocidad angular y deberamos recibir $INROT,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS. Cuando escribimos un 8: Se pide informacion de velocidad angular y deberamos recibir $INROT,valor obtenido,A*00\r\n, donde valor obtenido es el valor que devuelven los ADIS.
Ayudandonos de los resultados obtenidos en el experimento anterior, podremos compro bar si el valor obtenido esta dentro de lo previsible, o sea, que este dentro del rango de datos posibles. Despues de realizar el experimento el resultado fue el de la gura 3.20.
Figura 3.20: Resultados a los 8 pedidos posibles desde el PC.
102
Se puede observar que los resultados son los esperados, y que ademas los valores obte nidos estan dentro de lo previsible. De esta forma, se certica el correcto funcionamiento de la comunicacion Placa de Adquisicion - CAN - PC. Como ultimo experimento, juntaremos los dos grandes bloques que hemos probado hasta ahora (comunicacion PC-CAN-PC y Placa Adquisicion de Datos-CAN-PC) junto con un GPS que nos ha proporcionado el Prof. Dagoberto Salazar.
3.4. Experimento nal: Placa Adquisicion de Datos, PC y GPS con otro PC monitorizando
Es el momento de realizar el experimento nal donde se probara el correcto funcionamiento del sistema de comunicaciones que se ha desarrollado a lo largo del TFC. Explicaremos cuales dispositivos se han utilizado, como se han realizado las conexiones y las congu raciones dispositivo-nodo, y como se llevara a cabo la puesta en marcha. A la hora de realizar el experimento se han utilizado un total de 4 dispositivos y 4 nodos. Entre los dispositivos contamos con: Dos PCs. Uno de ellos monitorizara los datos recibidos de un GPS y enviara co mandos a la Placa de Adquisicion para despues monitorizar los datos. El otro PC se comunicara con el primero, enviando y recibiendo paquetes de datos. Una Placa de Adquisicion de Datos inerciales. Un GPS (Ver gura 3.21), que enva periodicamente con una cierta frecuencia unas cadenas NMEA. Estas contienen informacion de posicionamiento captadas de los satelites NAVSTAR del sistema GPS.
Figura 3.21: GPS utilizado en el experimento.
Primero. Debido a que cada uno de los dispositivos se comporta de manera diferente (ver tipos de dispositivos en 2.2.2.2.) los nodos de comunicacion deben ser re-congurados de acuerdo con la forma de trabajo de cada uno de los dispositivos.
Experimentos
103
Para realizar estas re-conguraciones del nodo, simplemente tendremos que editar el archivo funciones.c como se explica a continuacion para cada uno de los dispositivos y, exclusivamente para este experimento, editar la velocidad de transferencia del protocolo RS232 del archivo tfc.c para el nodo del dispositivo PC1.
Los PCs se comportan como un dispositivo del tipo 3. Por ello cuando vayamos a
editar el archivo funciones.c realizaremos los siguientes cambios: PC1: Monitorizar GPS + peticiones datos inerciales + comunicacion PC2 Funcion seleccion mensaje(): Este PC aceptara IDs del GPS (1792), del PC2 (779), de la placa de adquisicion de datos(1280-1291) y del reset de comunicaciones (0). Funcion id entrada id salida(): No es necesario congurar esta funcion porque no vamos a responder a ningun mensaje en nuestro experimento. Funcion mensaje a responder(): Debido a que en el caso de nuestro expe rimento los paquetes que vamos a recibir no tendran respuesta, el vector de IDs tendra que estar vaco (encontrado = false;). Funcion imprimir id(): En nuestro experimento no sera necesario visualizar los IDs, por lo que el return de esta funcion sera FALSE. Si se quieren visua lizar por pantalla a traves de HyperTerminal los IDs, simplemente tendremos que cambiar el return a TRUE. Funcion condicionnal(): Conguraremos el return de la funcion a 13, que es un \r en el codigo ASCII. Es este caracter y no otro ya que el caracter 13 del codigo ASCII corresponde a pulsar el intro en el PC1, por lo que cuando pulsemos ENTER el nodo interpretara esta accion como nal de condicion. Funcion id valido(): Los IDs que enviamos por el PC1 al nodo han sido pre viamente calculados de forma que sean validos para el protocolo CAN. Propor cionandole al paquete en cuestion prioridad media y tipo de mensaje evento. Por lo tanto, esta funcion ha de retornar un TRUE. Funcion set id vallido(): No hace falta congurar esta funcion, puesto que nunca la utilizaremos. Funcion cong interfaz(): Al igual que en el experimento 3.3.2., para facilitar la transmision, recepcion y visualizacion de datos de la placa de adquisicion de datos en el PC1 utilizaremos esa misma interfaz. De modo que para habili tarla tendremos que congurar el return de esta funcion a TRUE (solo en este nodo). Funcion condicion nal can(): En esta funcion se han de asociar los IDs 0, 134, 135, 136, 137, 778 y 779 a \r como condicion nal, y los IDs 1286, 1287, 1288, 1289 y 1792 a \n como condicion nal. Exclusivamente para este experimento, y con la nalidad de que se pueden visua lizar por HyperTerminal todos los datos recibidos por CAN a traves del nodo del PC1 (que es el unico que monitoriza GPS + inerciales), se modicara la tasa de bits por segundo del protocolo RS232, ascendiendola a 57600 bps. PC2: Comunicacion con PC1.
104
Funcion seleccion mensaje(): Este PC aceptara IDs del PC1 (778) y del reset de comunicaciones (0). Funcion id entrada id salida(): No es necesario congurar esta funcion porque no vamos a responder a ningun mensaje en nuestro experimento. Funcion mensaje a responder(): Debido a que en el caso de nuestro expe rimento los paquetes que vamos a recibir no tendran respuesta, el vector de IDs tendra que estar vaco (encontrado = false;). Funcion imprimir id(): En nuestro experimento no sera necesario visualizar los IDs, por lo que el return de esta funcion sera FALSE. Si se quieren visua lizar los IDs por pantalla a traves del HyperTerminal, simplemente tendremos que cambiar el return a TRUE. Funcion condicionnal(): Conguraremos el return de la funcion a 13, que es un \r en el codigo ASCII. Es este caracter y no otro ya que el caracter 13 del codigo ASCII corresponde a pulsar el intro en el PC1, por lo que cuando pulsemos ENTER el nodo interpretara esta accion como nal de condicion. Funcion id valido(): Los IDs que enviamos por el PC1 al nodo han sido pre viamente calculados de forma que sean validos para el protocolo CAN, propor cionandole al paquete en cuestion prioridad media y tipo de mensaje evento. Por lo tanto, esta funcion ha de retornar un TRUE. Funcion set id vallido(): No hace falta congurar esta funcion, puesto que nunca la utilizaremos. Funcion cong interfaz(): En este nodo no es necesario utilizar la interfaz para enviar y recibir datos de la placa de adquisicion de datos por lo que debemos congurar el return a False. Funcion condicion nal can(): En esta funcion se ha de asociar los IDs 0, 134, 135, 136, 137, 778 y 779 a \r como condicion nal, y los IDs 1286, 1287, 1288, 1289 y 1792 a \n como condicion nal.
El GPS se comporta como un dispositivo del tipo 1. Por ello, cuando vayamos a
editar el archivo funciones.c realizaremos los siguientes cambios: Funcion seleccion mensaje(): El GPS no tiene porque recibir paquetes, por lo que el vector de IDs (ltro) ha de estar vaco. Funcion id entrada id salida(): El GPS no recibe datos, ni IDs de entrada, por lo que no necesita calcular las IDs de salida. Esta funcion no sera necesaria y no tendremos que congurarla para el caso del GPS. Funcion mensaje a responder(): El GPS no responde mensajes ya que nin guno de ellos es aceptado en la funcion seleccion mensaje(). Simplemente va enviando paquetes cada cierto periodo. De forma que en esta funcion no hay que congurar nada. Funcion imprimir id(): Al igual que en la funcion anterior, no tenemos que congurar nada porque no recibimos mensajes de los que tengamos que imprimir las IDs. Funcion condicionnal(): Conguraremos el return de la funcion a 10, que es un \n en el codigo ASCII. Esto es debido a que en el protocolo standard
Experimentos
105
NMEA, utilizado por el GPS, cuando se naliza una transmision de datos el ultimo caracter es \n (ver gura 2.37). Funcion id valido(): El GPS no enva IDs con el formato adecuado para CAN (por prioridades, tipos de paquetes, etc), por lo tanto el return de esta funcion tendra que ser congurado a FALSE. Funcion set id vallido(): Como la funcion anterior ha sido congurada a FAL SE, no hay identicadores para los paquetes CAN. Por ello, en esta funcion congurar como ID CAN del GPS el valor 1792. Este lo que haremos sera identicador proporciona a los paquetes del GPS dentro del protocolo CAN, prioridad media y tipo de mensaje de datos. Funcion cong interfaz(): En este nodo no es necesario utilizar la interfaz para enviar y recibir datos de la placa de adquisicion de datos por lo que debemos congurar el return a FALSE. Funcion condicion nal can(): En esta funcion se han de asociar los IDs 0, 134, 135, 136, 137, 778 y 779 a \r como condicion nal, y los IDs 1286, 1287, 1288, 1289 y 1792 a \n como condicion nal. La placa de adquisicion de datos se comporta como un dispositivo del tipo 2. Por ello, cuando vayamos a editar el archivo funciones.c realizaremos los siguientes cambios: Funcion seleccion mensaje(): Para la seleccion de mensajes en la placa de adquisicion de datos, y por lo tanto conguracion del vector de IDs a aceptar, seguiremos la tabla 2.2. Funcion id entrada id salida(): Este dispositivo responde a paquetes entran tes. Debido a que en la informacion que envan los chips ADIS16100 y ADIS16201 no se encuentran las IDs de los mensajes que se enviaran, se los hemos de agregar nosotros. Observando la tabla2.1 determinamos la relacion ID de entrada-salida. En nuestro caso esta relacion sera: id entrada + 1152LSB. Funcion mensaje a responder(): Se han de incluir los mismos IDs que en la funcion seleccion mensaje() menos el ID = 0, ya que no queremos responder al reset de las comunicaciones. Funcion imprimir id(): Debido a que los IDs son necesarios en la placa de adquisicion de datos para saber cual sensor tiene que capturar los datos, debemos enviar (imprimir) el ID del dispositivo. Por ello, conguraremos el return a TRUE. Funcion condicionnal(): Conguraremos el return de la funcion a 10, que es un \n en el codigo ASCII. Esto es debido a que en el protocolo estandar NMEA (utilizado en la placa de adquisicion de datos) cuando se naliza una transmision de datos el ultimo caracter es \n (ver gura 2.37). Funcion id valido(): Este dispositivo no enva IDs con el formato adecuado para CAN (por prioridades, tipos de paquetes, etc), por lo tanto el return de esta funcion tendra que ser congurado a FALSE. Funcion set id valido(): Esta funcion no la tendremos que congurar, puesto que previamente en la funcion id entrada id salida() hemos calculando el ID del ID de entrada. de salida en funcion
106
Funcion cong interfaz(): En este nodo no es necesario utilizar la interfaz para enviar y recibir datos de la placa de adquisicion de datos, por lo que debemos congurar el return a False. Funcion condicion nal can(): En esta funcion se han de asociar los IDs 0, 134, 135, 136, 137, 778 y 779 a \r como condicion nal, y los IDs 1286, 1287, nal. 1288, 1289 y 1792 a \n como condicion
Segundo. Una vez programados y re-congurados los nodos de comunicacion, tendre mos que conectarlos entre ellos a traves del bus CAN. Al igual que en los experimentos del nodo de comunicaciones (3.2.2.), debemos conectar los pines del UserTerminal de cada nodo con los pines correspondientes del UserTerminal de los otros nodos: CANH del nodo 1 al CANH del nodo 2, CANL del nodo 1 al CANL del nodo 2 y GND del nodo 1 al GND del nodo 2 (Ver gura 3.22). Es muy importante no olvidar las dos resistencias de 120 en los extremos del bus entre las lineas diferenciales CANH y CANL, para evitar que los datos sean devueltos en forma de eco de los extremos del bus y se falsiquen.
Figura 3.22: Esquema de conexion de los pines UserTerminal. Tercero. Despues de realizar la union entre los nodos, se puede decir que tenemos listo el bus de comunicaciones entre nodos, por lo que seguidamente tendremos que conectar cada dispositivo con su nodo correspondiente (previamente congurado) y establecer as el enrutamiento de comunicaciones completo para nuestro experimento.
Experimentos
107
Caso de los PCs. Ambos utilizan el mismo sistema de conexion, ya que los dos se comunican con el nodo a traves del protocolo RS232. Por ello, en los dos nodos de estos dispositivos (PC1 y PC2), tendremos que indicar al codigo que el protocolo utilizado en las comunicaciones con el dispositivo es RS232, y no I2C o SPI. Esta indicacion la podemos hacer mediante los interruptores de seleccion de protocolo que disponen los nodos. Lo unico que tendremos que hacer es poner el interruptor RS232 en ON y los interruptores I2C y SPI en OFF (Ver gura 3.2). Una vez activado el interruptor correspondiente conectaremos el dispositivo al nodo mediante un cable NULL MODEM. La forma de hacerlo es muy sencilla: Simplemente conectaremos un extremo del cable al puerto serie de los PCs, y en el otro extremo el conector DB9 del bloque de comunicaciones del nodo. La conexion nodo-GPS, al igual que el caso anterior, tampoco es ningun problema, ya que el kit del GPS incluye sus propios cables de comunicacion. As pues, con el cable que tenemos del kit conectaremos el puerto 1 del GPS (conector RJ45) con el puerto serie (conector DB9) del nodo de comunicacion. Es muy importante conectarlo al puerto 1 y no al 2 por que a diferencia del puerto 1, el puerto 2 no utiliza el protocolo NMEA sino un protocolo exclusivo del fabricante para su software, llamado UBX, que tambien esta disponible en el kit. Los interruptores se tendran que congurar como en la gura 3.2, ya que el protocolo utilizado en este caso es, como en el anterior, RS232. La placa de adquisicion de datos utiliza un cable NULL MODEM para la comuni cacion RS232, de la misma forma que en los PCs. Por ello, los pasos a seguir para la conexion nodo-dispositivo sera exactamente igual que en el primer punto (caso de los PCs). Conectaremos el DB9 de la placa de adquisicion de datos a un extremo del cable NULL MODEM, y el otro extremo va al nodo de comunicaciones. Colocaremos en ON el interruptor correspondiente a RS232, y en OFF los correspondientes a I2C y SPI.
Cuarto. Terminadas de enrutar todas las conexiones dispositivo-nodo y nodo-nodo, el sistema de comunicacion ya esta preparado (Ver gura 3.23). Seguidamente lo que haremos sera volver conectar a la red electrica los nodos de comu10 nicacion y encenderemos los dispositivos . Si fuese necesario, podemos hacer un reset de un nodo dado pulsando el correspondiente boton Reset. Una vez todos los dispositivos estan preparados, es el momento de realizar las pruebas nales y comprobar el funcionamiento del sistema. Pero antes, como ya sabemos, tanto para escribir como para recibir la informacion del PC1 y del PC2 nos ayudaremos del HyperTerminal de Windows. Por lo tanto, el siguiente paso antes de realizar las pruebas es abrir este programa y congurarlo tal y como se presenta en la gura 3.1. Pero hay que tener muy presente la diferencia en las velocidades: En el HyperTerminal del PC1 los bits por segundo en lugar
10
En el caso de los PCs, conectar HyperTerminal.
108
Figura 3.23: Montaje del experimento nal. de ser 4800 baudios han de ser 57600 baudios, tal y como se comento en la conguracion del archivo tfc.c de este dispositivo (PC1). Quinto. La puesta a punto de los dispositivos, nodos, conexiones y conguraciones esta terminada, por lo que siguiendo una serie de pasos que comentaremos a continuacion testearemos la integridad del sistema. La prueba que realizaremos, funcionalmente, trata de seguir minuciosamente los experimentos de los dispositivos comentados en los captulos anteriores, incluyendo exclusiva mente para esta prueba un nuevo dispositivo, el GPS, que simplemente tendra que ser monitorizado por un PC (PC1). La particularidad de este experimento es que esta vez los dispositivos ya probados individualmente ahora tendran que poder trabajar en paralelo entre ellos (integracion de dispositivos). Como ya se ha indicado a lo largo de esta seccion, disponemos de un PC (PC1), con el que nos ayudaremos a la hora de monitorizar gran parte del traco del sistema y comunicarnos con diferentes dispositivos. Es a partir de este PC1 con el que iniciaremos el experimento y no desde otro dispositivo, debido a que es el unico dispositivo del sistema que acepta los paquetes de informacion que el GPS transmite periodicamente. Por ello nada mas conectar el GPS y el HyperTerminal deberamos poder visualizar por pantalla algo similar a la gura 3.24. Una vez comprobamos que la recepcion de datos del GPS es correcta, pasaremos a comprobar la comunicacion entre el PC1 y la placa de adquisicion de datos mientras recibimos paquetes de informacion del GPS simultaneamente. La forma de comunicarnos con la placa de adquisicion de datos es la misma que en el experimento de la seccion 3.3.2., ya que utilizamos la misma interfaz que nos facilita realizar peticiones y lecturas de los sensores para recibir la informacion. El resultado de esta prueba es la visualizacion por el HyperTerminal del PC1 datos iner-
Experimentos
109
Figura 3.24: Resultado al conectar el GPS. ciales procedentes de la placa de adquisicion de datos y datos procedentes del GPS. Al realizar movimientos de la placa de adquisicion de datos, la informacion procedente de los giroscopos sigue siendo coherente y corresponde a valores similares a los obtenidos en las pruebas individuales del dispositivo (Ver gura 3.25). Hasta ahora hemos comprobado el sistema con dispositivos del tipo 1 (GPS) y del tipo 2 (placa de adquisicion de datos). Para comprobar el funcionamiento del sistema con dispositivos del tipo 3 nos ayudaremos del PC2. Este tipo de dispositivos, como se dene en la seccion 2.2.2.2., puede tanto responder ordenes como enviar paquetes por CAN cuando se requiera. Por ello, en este ultimo caso, cuando transmitamos por el PC2 previamente debemos escribir por el Hyperterminal el identicador del paquete que PC1 tiene programado como paquete a aceptar en su vector de IDs. Esta ID es 779, que corresponde en codigo ASCII a los caracteres a y c. En el caso de la comunicacion recproca, el identicador del paquete CAN que tendremos que escribir en el HyperTerminal del PC1 es 778, que corresponde a los caracteres del codigo ASCII a y b. El contenido de datos en estas transmisiones seran cadenas de caracteres que nosotros mismo escribiremos en el HyperTerminal, de la misma manera que hacamos en el experimento de la seccion 3.2.1. (Ver gura 3.26). Con esta prueba, que se puede ver en el video prueba nal incluido en el CD-ROM del TFC, se da por nalizado el captulo experimentos y podemos decir que todos los objetivos marcados previamente al desarrollar del TFC se han visto cumplidos y superados con creces. Podemos realizar esta armacion ya que:
110
Figura 3.25: Resultado al conectar el GPS y la placa de adquisicion de datos.
Se ha conseguido integrar en un mismo sistema de comunicaciones dispositivos

que siguen protocolos de comunicacion diferentes. Esta diferencia no es solo a nivel de la capa de enlace (nivel 2 del modelo OSI) sino tambien a nivel de la capa fsica (nivel 1 del modelo OSI). Se ha conseguido disenar una serie de dispositivos portatiles, ligeros y faciles de acoplar en vehculos. Los errores obtenidos en el experimento de la placa de adquisicion de datos (ver 3.3.1.) son consistentes y conocidos. Por lo tanto, se han podido calibrar los dispositivos.
Durante el desarrollo de los experimentos, los dispositivos han trabajado el 100 %

del tiempo y no hemos sufridos cadas de comunicacion en ningun momento, con lo que podemos decir que la abilidad del sistema es alta, y los dispositivos tienen una buena continuidad de trabajo.
Experimentos
111
Figura 3.26: Resultado al conectar el GPS, la placa de adquisicion de datos y otro PC.
112
Conclusiones y Recomendaciones
113
CAPTULO 4. CONCLUSIONES Y I RECOMENDACIONES

Los objetivos de nuestro proyecto eran multiples: Disenar y construir un nodo de comunicaciones capaz de comunicarse con diferen tes dispositivos utilizando los protocolos RS232, I2C y SPI. La informacion recibida para poderla enviar por un bus general, el bus de estos dispositivos se adaptara CAN. De esta forma se podran unir muchos tipos de dispositivos al bus CAN sin importar el protocolo que utilizan. Disenar y contruir un dispositivo que proporcionara informacion de velocidad an gular en los ejes de cabeceo y guinada, y aceleracion e inclinacion en los 3 ejes del vehculo, siendo capaz de ir embarcado en el mismo. El profesor de la asig natura Navegacion Aerea, Cartografa y Cosmografa (NACC) nos proporciono 4 sensores (2 ADIS16100 y 2 ADIS16201) para poder alcanzar este objetivo.
Corroborar el funcionamiento del bus CAN utilizando los dispositivos antes mencio nados junto con uno o varios PCs mas. Una funcionalidad directa que se le va a dar a estos nodos de comunicaciones es la de utilizarlos en proyectos de las practicas de NACC. Estos proyectos consisten en la utili zacion de un carrito donde habra incorporado un GPS, una placa proporcionando datos sobre velocidad angular, inclinacion y acceleracion, un procesador central y unos servomotores, entre otros. De esta forma se podran observar los datos de posicion del vehculo y guiarlo si hiciera falta. Los nodos de comunicaciones proporcionados realizaran la funcion de unir todos estos dispositivos al bus CAN, controlando el envo y recepcion de datos en cada uno de ellos. La Placa de Adquisicion de Datos sera el dispositivo que proporcionara los datos de velocidad angular, aceleracion y inclinacion del carrito. A lo largo del TFC hemos ido siguiendo diferentes etapas. La primera etapa consistio en el estudio de todos los protocolos y del posible hardware a utilizar en cada una de las partes de nuestro proyecto. Esta etapa resulto ser mucho mas larga de lo esperado, ya que tuvimos que aprender el funcionamiento de 4 protocolos que no habamos visto a lo largo de nuestros estudios. Una vez tuvimos claro los conceptos teoricos a utilizar, la siguiente etapa fue el desarrollo hardware en protoboards. Este es un paso obligatorio en todos los proyectos en los que se disena un dispositivo, ya que se tiene que comprobar el correcto funcionamiento de cada uno de los modulos de hardware. Se han realizado experimentos para cada uno de los protocolos trabajando individual mente, y experimentos para el correcto funcionamiento del envo y recepcion de datos de los sensores. Los resultados de estos experimentos han sido tal y como se esperaban. Ademas, los resultados del experimento en la Placa de Adqusicion de Datos nos han servido para conrmar que los sensores cometen un error en las lecturas que realizan, y que
114
por tanto necesitan ser calibrados previamente. Despues de realizar un calculo estadsti co, se han estimado los parametros de calibracion necesarios para cada sensor, y se han anadido al software implementado. Cuando se ha comprobado que el software y el hardware funcionaban correctamente, pu dimos pasar a disenar los PCB de las placas para corroborar el correcto funcionamiento tanto del software como del hardware sobre los dispositivos nales. El diseno de los PCB se tuvo que ajustar a unos criterios establecidos por los servicios encargados de realizar la placa. Decidimos utilizar componentes en su formato estandar, y no en formato SMD, ya que para la nalidad de estas placas el primer formato era adecuado, y ademas practica mente todos los componentes seleccionados cumplen con la normativa RoHs (Restriccion de ciertas Sustancias Peligrosas en aparatos electricos y electronicos), respetando as al medioambiente. Aun as, de cara a futuras versiones del nodo de comunicaciones se recomienda la posibi lidad de utilizar componentes en formato SMD para reducir considerablemente el tamano y peso de las placas. Desgraciadamente, el funcionamiento de los sensores ADIS16201 no se ha podido comprobar debido a diferentes problemas comentados en el capitulo de experimentos. A pesar de este contratiempo, se diseno el software y el hardware necesario para poderlos utilizar en un futuro. Recomendamos que en el futuro se adquieran otros sensores de este tipo para as corroborar el diseno del hardware y el software asociado. Despues de comprobar el resultado de todos los experimentos, podemos decir que hemos cumplido con los objetivos planteados al principio. Aun as, quisimos ver la exibilidad del comportamiento del sistema anadiendole otro dispositivo, un receptor GPS. Este GPS nos lo ha proporcionado el profesor de NACC, y con el hemos podido ver que nuestro diseno del nodo de comunicacion no es individualizado, o sea, pensado solo para los PCs y la Placa de Adquisicion de Datos, sino que se pueden ir agregando dispositivos que utilicen los protocolos SPI, I2C y/o RS232. No obstante, creemos que se podran mejorar algunas partes de nuestro diseno. Un as pecto lo hemos comentado anteriormente: Si se pretende incluir estos dispositivos en algun vehculo, como por ejemplo un pequeno UAV (Unmanned Aerial Vehicle), tendremos que reducir al maximo el tamano de las placas ya que lo importante en estos vehculos es la denominada carga de pago o payload. Una forma rapida y eciente sera utilizar componentes en formato SMD. Tambien se podran obviar partes de la placa como por ejemplo los interruptores, leds y sus correspondientes resistencias y el bloque de progra macion. Pero como la aplicacion mas directa sera el desarrollo de las practicas de NACC, decidimos poner estos componentes para que los usuarios (principalmente estudiantes) pudieran tener una mejor vision de lo que estan utilizando, pudieran reconocer los diferen tes bloques y componentes, y fueran capaces de programar el nodo y placa de adquisicion de datos in situ. Otro aspecto a mejorar podra ser el funcionamiento del Reset. Nosotros lo hemos di senado para que resetee todos los nodos que esten conectados al bus CAN. Un reset mas eciente tendra que reiniciar unicamente el dispositivo con el que se estaba comuni cando. Para ello se tendra que dotar de una cierta inteligencia al nodo de comunicaciones,
115
y esta opcion no entraba en los planes iniciales de nuestro proyecto. Es por ese motivo que, de cara a futuras versiones de nuestro nodo de comunicaciones, se podra tener en cuenta este aspecto. Para ir nalizando, hay que remarcar que este TFC en ocasiones se ha ido escribiendo con una doble nalidad. En un primer plano, y con un sentido mas inmediato, describir todo el desarrollo llevado a cabo durante el trabajo del da a da en el TFC; y en un segundo plano, y con un objetivo mas tutorial, crear un guion que ayude a los alumnos de aeronautica en la realizacion de las practicas de NACC. Ademas, debido a este segundo plano, este TFC pudiera servir como base de desarrollo y gua para otros proyectos dentro de las areas de la aeronautica y las telecomunicaciones. Animamos a futuros proyectistas a que se involucren en proyectos de este tipo, ya que este es uno de los sectores con mas potencial, y posiblemente el que mas se desarrolle durante los proximos anos en Cataluna.
116
117
SIGLAS Y ABREVIATURAS
ACK: Acknowledgement ADC: Analog to Digital Converter CAL: CAN Application Layer CAN: Controller Area Network CCP/ECCP: Enhanced Capture/Compare/PWM CCS: Custom Computer Services inc. CMOS: Complementary Metal-Oxide Semiconductor CPHA: Clock Phase CPOL: Clock Polarity CRC: Codigos de Redundancia Cclica CS: Chip Select CSMA/CD+AMP: Carrier Sense Multiple Access with Collision Detection and Arbitration Message Priority CTS: Clear To Send DAC: Digital to Analog Converter DCD: Carrier Detect DIN: Data In del SPI DOUT: Data Out del SPI DSR: Data Set Ready DTR: Data Terminal Ready EEPROM: Electrically-Erasable Programmable Read-Only Memory EIA: Electronics Industry Association EUSART: Enhanced Universal Synchronous Asynchronous Receiver Transmitter GND: Ground GPS: Global Positioning System HS: High Speed I2C: Inter-Integrated Circuit IC: Integrated Circuits ICD: In-Circuit-Debugger ID: Identier IDE: Entorno de Desarrollo Integrado IMU: Unidad de Medidas Inerciales INS: Inertial Navigation System ISO: Organizacion Internacional para la Estandarizacion LLC: Logical Link Control MAC: Media Access Control MEMS: Micro Electro-Mechanical Systems MISO: Master In/Slave Out MOSI: Master Out/Slave In MSSP: Master Synchronous Serial Port MCLR: Master Clear NOLVP: No Low Voltage Programming NOWDT: No Match Dog Timer OSC: Oscilador OSEK: Offene Systeme und deren Schnittstellen fur die Elektronik in Kraftfahrzeugen
118
(.Open Systems and their interfaces for the Electronics in Motor vehicles) OTP: One-Time Programmable PCB: Printed Circuit Board PIC: Peripheral Interface Controller PLL: Phase Lock Loop PSP: Parallel Slave Port PWM: Pulse-Width Modulation RAM: Random Access Memory RD: Received Data RI: Ring Indicator ROM: Read-Only Memory RS232: Recommended Standard 232 RTS: Request To Send RX: Recepcion SCL: Serial Clock SCLK: Serial Clock SDA: Serial Data SDI: Serial Data In SDO: Serial Data Out SDS: Smart Distributed System SPI: Serial Peripheral Interface SS: Slave Select TD: Transmitted Data TTL: Transistor-Transistor Logic TX: Transmission USB: Universal Serial Bus XT: Cristal
BIBLIOGRAFA I
119
BIBLIOGRAFA I
Libros
[1] Gardner, N. PICmicro MCU C - An introduction to programming The Microchip PIC in CCS C.. Bluebird Electronics. 2002.
Paginas Webs
www.microchip.com www.ccsinfo.com www.ondaradio.es www.asciitable.com www.can-cia.org/can www.todopic.com.ar www.wikipedia.org miarroba.com/foros/ver.php?id=6510 www.camiresearch.com/Data Com Basics/RS232 standard.html www.i2c-bus.org www.analog.com/en/cat/0,2878,764,00.html
Datasheets
PIC184580 y PIC18F2580: datasheetPIC18F4580.pdf ADIS16100: ADIS16100.pdf ADIS16201: ADIS16201.pdf TS7805T: 7805T.pdf PCA82C251: PCA82C251 3.pdf MAX232: max232.pdf
Especicaciones de Protocolos
CAN: can2spec.pdf RS232: rs-232.pdf I2C: 39340011.pdf SPI: S12SPIV3.pdf
120
Otros documentos
Manual CCS: CCSmanual.pdf. Version 4. August 2006. Tutorial Microprocesadores PIC: Apunte de Microprocesadores PIC.pdf (autor:
Javier Rambaldo).
Proyecto en el que se utiliza CAN: portland-lv2-avionics-design.pdf (autores:

Michael Kennan y Matt McFadden).
Ejercicios para placa desarrollo CAN: Development Kit for the CANBus Exercise Book.pdf. September 2006. CCS Inc.
Tutorial P-CAD 2002: pcb.pdf.
Codigo implementado
121
APENDICE A.
CODIGO IMPLEMENTADO
A.1. Nodo de Comunicaciones

A.1.1. tfc.c
122
Codigo implementado
123
124
Codigo implementado
125
126
Codigo implementado
127
128
Codigo implementado
129
130
Codigo implementado
131
132
A.1.2. funciones.c
Codigo implementado
133
134
Codigo implementado
135
A.1.3. funciones.h
136
A.2. Placa de Adquisicion de Datos

A.2.1. adquisicion datos.c
Codigo implementado
137
138
Codigo implementado
139
140
Codigo implementado
141
142
A.2.2. funciones adis.c
Codigo implementado
143
144
Codigo implementado
145
146
A.2.3. funciones adis.h
Codigo implementado
147
A.3. Experimentos
A.3.1. experimentos spi.c
148
Codigo implementado
149
150
A.3.2. experimentos spi modo2.c
Codigo implementado
151
152
A.3.3. experimentos i2c.c
Codigo implementado
153
154
Codigo implementado
155
A.4. experimentos i2c modo2.c
156
Codigo implementado
157
A.5. experimento solo 1 adis.c
158
Codigo implementado
159
160
Diagramas de ujo
161
APENDICE B.
DIAGRAMAS DE FLUJO
Antes de mostrar los diagramas de ujo de los codigos tfc.c y adquisicion datos, vamos a indiciar el signicado de cada uno de los smbolos utilizados:
Figura B.1: Simbolos utilizados en el diagrama de ujo.
B.1. tfc.c
Figura B.2: Diagrama de ujo del modulo Conguracion Nodo de Comunicaciones.
162
Figura B.3: Diagrama de ujo del modulo Interrupcion Interruptores.
Figura B.4: Diagrama de ujo del modulo Interrupcion CAN.
Diagramas de ujo
163
Figura B.5: Diagrama de ujo del modulo Procesado Datos CAN.
164
Figura B.6: Diagrama de ujo del modulo Interrupcion I2C y SPI.
Figura B.7: Diagrama de ujo del modulo Interrupcion RS232.
Diagramas de ujo
165
B.2. adquisicion datos
Figura B.8: Diagrama de ujo del modulo Conguracion Placa Adquisicion de Datos.
Figura B.9: Diagrama de ujo del modulo Interrupcion RDA en ADIS16201.
166
Figura B.10: Diagrama de ujo del modulo Pedido y envio de datos en ADIS16201.
Layout
167
APENDICE C.
C.1. Nodo de comunicaciones
LAYOUT
Figura C.1: Capa top del Layout del nodo de comunicacion.
168
Figura C.2: Capa bottom del Layout del nodo de comunicacion.
Layout
169
Figura C.3: Layout con las capas top y bottom del nodo de comunicacion.
170
C.2. Placa de adquisicion de datos
Figura C.4: Capa top del Layout de la placa de adquisicion de datos.
Layout
171
Figura C.5: Capa bottom del Layout de la placa de adquisicion de datos.
172
Figura C.6: Layout con las capas top y bottom de la placa de adquisicion de datos.
Figura C.7: Layout placa acopladora.
Problemas en Datasheet del ADIS16100
173
APENDICE D.
PROBLEMAS EN DATASHEET DEL ADIS16100
A lo largo del proyecto tubimos varios problemas relacionados con el datasheet del ADIS16100 que nos supuso bastante retraso. Queremos exponer estos problemas en este Anexo para evitarle a futuros proyectistas estos problemas. Todos los errores encontrados estan en la revision B del datasheet. Tambien queramos comentar que estos errores no son suposiciones nuestras sino que despues de comunicarselos al ingeniero responsable (Mark Looney, Mark.Looney@analog.com) del ADIS16100 en Analog Devices, nos dio la razon. Los errores son los siguientes; En la gura 22 (pagina 12 de 16) se indica la conguracion del Modo de trabajo de SPI como Clock Polarity = 1 y Clock Phase = 0. Esta conguracion corresponde al Mode=2 en la directiva #use spi(). Despues de muchas pruebas y ver que siempre daban resultados negativos, decidimos cambiar de modo de trabajo. La sorpresa fue al ver que con otro modo la comunicacion con el sensor funcionaba correctamente. Despues de visualizar la nueva comunicacion por un osciloscopio y ver el datasheet del PIC18F2580 nos dimos cuenta que el correcto modo de trabajo era con Clock Polarity = 0 and Clock Phase = 0. Esto signica que el estado IDLE del reloj ha de ser 0 y la transmision ha de ser en el primer anco del reloj (en este caso en el anco de bajada). Este es el caso del Mode = 1 en la directiva #use spi(). En el datasheet del PIC18F2580 coincide con los parametros CKP=0 y CKE=1. Como se puede ver en la gura D.1, la unica diferencia entre los dos modos es el estado IDLE del reloj. En la Tabla 6 (pagina 13 de 16) se indica que el Bit Pattern para una velocidad angular de -0.2439 y -0.4878 es 1111111111111111 y 1111111111111110. Pero el correcto Bit Pattern es 0000111111111111 y 0000111111111110 porque los bits numero 15, 14, 13 y 12 son 0 obligatoriamente. Solo los 12 ultimos bits se conguran en Complemento a Dos. En la Tabla 7 (pagina 13 de 16) se indica que el Bit Pattern para una velocidad angular de -0.2439 y -0.4878 es 0000111111111111 y 0000111111111110. Pero el correcto Bit Pattern es 0000011111111111 y 0000011111111110 porque en esta tabla, el formato de los datos de salido es en Ofset Binary. En la Tabla 8 (pagina 13 de 16) se indica que el Code para una temperatura de 85o C en Complemento a Dos es 585. Este Code corresponde a una temperatura de 115o C y esta no esta dentro del rango del propio ADIS16100. El correcto Code o para una temperatura de 85 C es 413 (Bit Pattern: 0001000110011101). No se haba tenido en cuenta que para el Code = 0 la temperatura es de 25o C y no 0o C. En la Tabla 9 (pagina 13 de 16) se indica que el Code para una temperatura de 85o C en Complemento a Dos es 2633. Este Code corresponde a una temperatura
174
Figura D.1: Tabla con los diferentes modos de trabajo de SPI en el PIC18F2580. de 115o C y esta no esta dentro del rango del propio ADIS16100. El correcto Code para una temperatura de 85o C es 2461 (Bit Pattern: 0001100110011101). No se haba tenido en cuenta que para el Code = 2048 la temperatura es de 25o C y no 0o C. Otro error en esta tabla es que el Bit Pattern para una temperatura de (25-0.1453)o C y (25-0.2906) es 0001111111111111 y 0001111111111110. El correcto Bit pattern sera 0001011111111111 y 000101111111110.
Lista de componentes y presupuesto del proyecto.
175
APENDICE E. LISTA DE COMPONENTES Y PRESUPUESTO DEL PROYECTO.

En el proximo anexo se realiza una estimacion del valor de cada uno de los dispositivos disenados, y se indican detalladamente caractersticas como lugar de compra, referencia en el lugar de compra, fabricante y precio de cada uno de los componentes para facilitar la fabricacion de mas unidades. A continuacion se detallan los componentes del Nodo de comunicaciones en la tabla E.1 y los componentes de la placa de adquisicion de datos en la tabla E.2.
Componente
Fabricante TSC Ariston Ariston Ariston Ariston Ariston
Referencia
Lugar de compra
Cod. articulo WR7805 JR47U25 DS15P A271 XB2000 DS15P PR253H3 TF2266 P42A PR2547k PR251k
e/unidad
0.1930 0.0281 0.0169 1,130 0.550 0.0169 0.0201 0.4990 0.2780 0.0201 0.0201 4.72 0.4999 0.0280 0.0248 0.5400 0.3000 0.0201 0.2560 0.0201 0.3240 0.2790 0.0201 3.0400 14,6e
Bloque de Alimentacion 1 x Regulador 1 x Condensador 1 x Condensadores 1 x Conec alimentacion 1 x Reloj de cuarzo 2 x Condensadores 1 x Resistencia 1 x Conector RJ12 1 x Pulsador 1 x Resistencia 3 x Resistencia 1 x PIC18F4580 1 x Transceiver RS232 5 x Condensador 1 x Condensador 1 x Conector 1 x Transceiver CAN 1 x Resistencia 2 x Interruptores 2 x Resistencia 3 x Interruptores 3 x LEDs 6 x Resistencia 1 x UserTerminal TOTAL 7805 TO-220 Onda radio Electroltico 47F Onda radio Ceramico 15pF Onda radio Jack rosca 2,1mm Onda Radio Bloque del Clock XB 2000 Onda radio Ceramico 15pF Onda radio 330 Onda radio Bloque de Programacion
AMP RJ12 Onda radio Ariston Pulsador amarillo Onda radio Ariston 47K Onda radio Ariston 1K Onda radio Bloque de comunicacion y seleccion de protocolos Microchip Texas Inst Ariston Ariston Ariston Philips Ariston Maruwa Ariston Ariston Ariston Ariston Phoenix 18F4580I/P MAX232 Ceramicos 100nF Electroltico 4,7F DB9 hembra PCA82C251 10 Dip negros 4,7k DIP azules Rojo/Amarillo/Verde 3,3K MPT 05/12-254 Microchip Onda radio Onda radio Onda radio Onda radio Ebay Onda Radio Onda Radio Onda Radio Onda Radio Onda Radio Onda Radio Onda Radio
MAX232 CCS100K63 JR4U763 CO2309H PR2510H DIP9301 PR254k7 DIP501 WO1003RB/AB/VB PR253k3 1725753
176
Tabla E.1: Lista de precios componentes nodo.
Componente Placa Inercial
Fabricante
Referencia
Lugar de compra
Cod. articulo
e/unidad
Bloque de Alimentacion
Lista de componentes y presupuesto del proyecto.
1 x Regulador 1 x Condensador 1 x Condensadores 1 x Conec alimentacion 1 x Reloj de cuarzo 2 x Condensadores 1 x Resistencia 1 x Conector RJ12 1 x Pulsador 1 x Resistencia 3 x Resistencia 1 x PIC18F2580 1 x Transceiver RS232 5 x Condensador 1 x Condensador 1 x Conector 1 x LEDs 1 x Resistencia 1 x Conector Poste Placa Sensores 1 x Regulador 2 x Condensadores 1 x Conector Poste 1 x Conector Poste 2 x Sensores Mems 2 x Sensores Mems TOTAL
TSC Ariston Ariston Ariston Ariston Ariston
7805 TO-220 Onda radio Electroltico 47F Onda radio Ceramico 15pF Onda radio Jack rosca 2,1mm Onda Radio Bloque del Clock XB 2000 Onda radio Ceramico 15pF Onda radio 330 Onda radio Bloque de Programacion RJ12 Onda radio Pulsador negro Onda radio 47K Onda radio 1K Onda radio Bloque de comunicacion 18F2580-I/SP MAX232 Ceramicos 100nF Electroltico 4,7F DB9 hembra Rojo/Amarillo/Verde 3,3K Macho 2,54 Dual LM1117 Tantalio 10F Macho 2,54 Dual Hembra 2 Dual ADIS16100/PCB ADIS16201/PCB Microchip Onda radio Onda radio Onda radio Onda radio Onda Radio Onda Radio Onda radio Amidata Onda radio Onda radio Onda radio Farnell Farnel
WR7805 JR47U25 DS15P A271 XB2000 DS15P PR253H3 TF2266 P42N PR2547k PR251k
0.1930 0.0281 0.0169 1,130 0.550 0.0169 0.0201 0.4990 0.2780 0.0201 0.0201 4.33 0.4999 0.0280 0.0248 0.5400 0.2790 0.0201 0.3370 1.28 0.3370 2,1100 74.35 67,09 295,46e
AMP Ariston Ariston Ariston Microchip Texas Inst Ariston Ariston Ariston Ariston Ariston Ariston National Ariston Ariston Ariston Analog Analog
MAX232 CCS100K63 JR4U763 CO2309H WO1003RB/AB/VB PR253k3 CO3080 535-8663 CO3080 CO30972 1465267 1274171
177
Tabla E.2: Lista de precios componentes placa de adquisicion.
178
Estudio previo. Ejercicios de familiarizacion con el protocolo CAN
179
APENDICE F. ESTUDIO PREVIO. EJERCICIOS DE FAMILIARIZACION CON EL PROTOCOLO CAN

Con este informe vamos a explicar nuestras experiencias con el kit de desarrollo BusCan. Para conocer el protocolo hemos realizado una gua resumen de las especicaciones y caractersticas de este. Ademas hemos seguido unos ejercicios para familiarizarnos con el IDE (Integrated Development Enviroment, software de desarrollo). Empezaremos por los ejercicios mas basicos del kit y conforme vayamos avanzando nos iremos desviando hacia el bus.
F.1. Utilizando el software de desarrollo (IDE) Familiarizacion.

Antes de nada hemos de establecer ciertos parametros de conguracion:
Seleccionar el compilador para nuestro PIC. En estos ejercicios utilizaremos el

PIC16F876A o el PIC18f4580. El primero de los PICs nos obliga a seleccionar el compilador en modo PCM 14 bit. En el segundo hay que seleccionar el compilador en modo PCH 16 bit. En la pestana compile, donde se selecciona el compilador para nuestro PIC, hay que asegurarse de tener programado el chip (Program chip), con el boton Lookup Part. Testeamos el COMM, el ICD y la Tarjeta.
Una vez conrmamos que todo es correcto podemos empezar con los ejercicios. El
ejercicio 2 nos muestra como las variables de memoria son utilizadas en el compi lador y como poder seguirlas con el C/ASM List y el Symbol Map.
F.2. Primeros pasos

Generamos un codigo simple, con el que encenderemos un LED. El proposito de este ejercicio es aprender a programar correctamente el chip. Los pasos a seguir son:
1. Especicacion de la librera del chip, en nuestro caso la librera del Pic 18f4580. 2. Realizamos el codigo. Una vez terminado lo compilamos con el icono Compile. 3. Seguidamente tenemos dos opciones: A. Si queremos cargar el programa a la placa tendremos que clickar en Program Chip.
180
B. Si queremos Debugar el programa clickaremos en Debug / Enable Debugger. Nos apareceran diferentes opciones ( Reset, Single Step, Go, Step Over). Con la opcion Reset nos aseguramos que la tarjeta esta preparada, con Single Step podremos ir observando la evolucion del programa paso a paso ( entra en las funciones), con Go ejecutamos el programa y con Step Over lo que se consigue es ejecutar una linea de codigo C.
El codigo del primer ejercicio es:
Las primeras 4 lneas denen el hardware utilizado. En este caso un clock de 20MHz, un PIC18F4580 y el ICD Debugger. Los fuses signican lo siguiente:
HS: High Speed Osc (mayor que 4MHz). NOLVP: No low voltage programming, B3 (PIC16) or B5(PIC18) used for I/O. NOWDT: No Watch Dog Timer.
181
Despues asociamos 3 variables ( LED VERDE, LED AMARILLO, LED ROJO) a sus respectivos pines(Ver gura F.1).
Figura F.1: Asociacion LEDs con los puertos RB del PIC
Para nalizar, en el main realizamos un bucle innito indicando el tiempo de apagado y de encendido de los LEDs.(En el CD-ROM TFC, se encuentra el video de este ejercicio, con el nombre de video 1).
F.3. PIC18F4580 como transmisor y MCP25050 para outputs

En este ejercicio ejecutaremos el programa correspondiente al codigo F.2: Las primeras 4 lneas son parecidas a las del ejercicio anterior. En este caso hemos anadi do el fuse NOPROTECT ( Code not protected from reading) y la librera para trabajar con CAN llamada can-18xxx8.c. Como el programa esta disenado para enviar datos al Nodo D, denimos el identicador de este nodo. En nuestro caso el identicador sera el 0x400. La funcion write 7 segment enviara los datos necesarios para que en el 7-segmentos se muestren los dgitos correspondientes. El comando principal de esta funcion es el can putd que es con el que se construyen paquetes CAN y se ponen en los buffers de transmision. A este comando se le pasan 6 variables que en este caso son las siguientes:
WRITE REGISTER D ID Identicador buffer Datos 3 Numero de bytes de datos 1 Prioridad
182
Figura F.2: Ejercicio 2.
TRUE Flag indicando si es Extended Frame FALSE Flag indicando si es Data Frame (FALSE) o Request Frame (TRUE).
Para saber el identicador a utilizar tenemos que ir a la Tabla 4.2 del datasheet del MCP25050. En nuestro caso queremos que sea Write Register y por lo tanto el identicador tendra que tal y como se puede ver en la gura F.3.
Figura F.3: Registro del MCP25050.
Es por eso que utilizamos el identicador 0x400 (que en binario acaba en tres 0s). Para esta opcion, en la tabla nos muestra que tiene 3 bytes de datos ( addr, mask y value). Es por eso que dentro de la funcion write 7 segment creamos un buffer de 3 bytes. En la se le indica el registro donde se guardara la informacion (0x1E), en el primera posicion
183
segundo bytes se le indica la mascara (0x7F) y en el tercero se le pone los datos, El re gistro 0x1E es el llamado Output Latch Register, la mascara 0x7F (01111111) indica que bits seran en los que nos jemos (en este ejemplo no nos jaremos en el ultimo bit que es el del punto en el 7-segmentos). El valor se selecciona de un vector llamado lcd seg en el que se indican en cada posicion el numero a mostrar (los bits que estaran a 1 o a 0). Con el comando can init() inicializamos el modulo CAN a 125kbaudios y se limpian todos los ltros y mascaras para que todos los mensajes puedan ser recibidos con cualquier identicador. Seguidamente utilizamos el comando can putd, En este caso se le ha pasado los siguien tes parametros:
0x100 Identicador 0 Datos 0 Numero de bytes de datos 1 Prioridad TRUE Flag indicando si es Extended Frame FALSE Flag indicando si es Data Frame (FALSE) o Request Frame (TRUE).
Este primer mensaje vaco es necesario para que el MCP25050 pase del estado Power Up al estado Normal. Seguidamente nos encontramos con un bucle innito en el que pasamos la variable i para que por el 7-segmentos vaya visualizandose el contador. Una vez escrito este programa pasamos a Compilar y a Cargarlo al nodo A. El programa debe mostrar un contador del 0 al 9 en el 7-segmentos. A partir de ahora creamos una librera llamado ccscana.c En esta anadiremos todas las deniciones de hardware, #denes y funciones. A continuacion queremos anadir al programa el codigo necesario para poder encender los leds del nodo C. Nuestra nalidad es que el led verde se encienda cuando el contador sea mas pequeno que 1, el led amarillo cuando el contador sea mas pequeno que 4 y el rojo cuando sea mas pequeno que 7. Para poder realizar esto, anadiremos el codigo de la gura F.4 en la librera ccscana.c.
Figura F.4: Codigo a anadir en la librera ccscana.c.
La funcion write c led persigue la misma nalidad que la del 7-segmentos, o sea, enviar un paquete al nodo C con cierta informacion. En este caso el registro sera el mismo (0x1E), con la mascara seleccionamos solo un bit que correspondra al led deseado (0x02<led) y en los datos enviaremos un 0 o un 1 dependiendo si queremos apagar o encender el led.
184
Para nalizar anadimos el codigo siguiente;
El resultado se puede ver en la gura F.5 o tambien en Video 2del CD-ROM.
Figura F.5: Resultado del ejercicio anterior
F.4. MCP25050 para inputs

La nalidad de este ejercicio es encender los leds del Nodo C dependiendo de los botones que se hayan apretado. La MCP25050 usada en el nodo C ha sido programada para enviar un frame cuando cualquier de los botones ha sido pulsado (GP4-GP6). El programa tendra que leer estos mensajes y encender los leds correspondientes.
185
Para empezar anadiremos el ID de los botones en la librera ccscana.c: #dene NODE C PUSHBUTTON ID 0x303 En este caso hemos puesto el ID como 0x303. Con este ID estaremos en la opcion (0x303 01100000001):
Figura F.6: Registros del MCP25050.
El codigo que compilaremos y cargaremos en el nodo A es el siguiente:
Con este codigo lo primero que realizamos es recibir los paquetes enviados por MCP2050 cuando se ha pulsado algun boton. Primero utilizamos la funcion can kbhit(). Esta funcion retorna un TRUE si hay algun valor en los buffers de recepcion. Despues utilizamos la funcion can getd. Con esta funcion podemos coger un paquete del bus y nos devuelve:
ID del transmisor del paquete En nuestro caso sera la de los PUSHBUTTON.
Datos Longitud de los datos

Estructura con algun tipo de informacion predeterminada.
186
Una vez tenemos los ID de los paquetes que circulan por el bus, nos jamos que sea realmente el que nos interesa (0X303). Y una vez tenemos nuestro paquete miramos en el campo datos que boton ha sido pulsado. Seguidamente queremos que al igual que los leds del nodo C, los leds del nodo B tam bien se enciendan al pulsar cualquir boton del nodo C. El codigo es el siguiente;
En el se puede ver las especicaciones del hardware utilizado ( PIC16F76A a 2,5MHz.) Se incluye la librera MCP251x.c que es el controlador que utiliza la PIC16F76A. Seguidamente hacemos referencia a los pines donde estan conectados los LEDs y el ID del nodo C (que es el que realiza los paquetes) (Ver gura F.7). El ID del nodo C es 0x300 (en decimal 01100000000) y por lo tanto tambien sera un Write Register (con su direccion, mascara y datos). En el main hacemos el mismo proceso que el del codigo cargado en el Nodo A; en este caso miramos que el paquete recibido sea el del nodo C y que el registro donde la in-
187
Figura F.7: LEDs del nodo C. formacion se guarde sea el 0X1e (Output Latch Register). Una vez tenemos el paquete miramos que boton era el que se haba pulsado y encendemos el led correspondiente. (Resultado en el video 3 del CD-ROM)
Para nalizar hemos querido probar un programa made in casero. Su funcion es la de incrementar, decrementar o poner a 0 el contador del 7-segmentos con los botones. El programa utilizado es el de la gura F.8: (Resultado en el video 4 del CD-ROM)
F.5. MCP250XX para entradas analogicas

El MCP25050 puede estar congurado con hasta 4 entradas analogicas. El A/D es de 10 bits. El siguiente programa enviara request frames pidiendo los resultados del A/d cada 100ms y luego se esperara a este frame con la informacion. Este no es un buen esquema para una aplicacion real ya que si el MCP25050 no respon de, el programa se quedara colgado. Introduciendo el siguiente programa, conseguiremos que modicando el potenciometro del nodo C, en el 7-segmentos del nodo C vaya variando el numero mostrado;
La diferencia de este codigo con los demas es la introduccion del request frame (jarse can putd que es TRUE). en el ultimo campo de la funcion Otra diferencia es la variable que le introducimos al 7-segmentos que en este caso de pende del buffer[2] (o sea, de la posicion del potenciometro). El resultado se encuentra en el video 5 del CD-ROM
188
Figura F.8: Codigo del ejercicio hecho por nosotros.
189
Figura F.9: Codigo del ejercicio del potenciometro.

Can Con 18f4580

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Can Con 18f4580

Cargado por

Copyright:

Formatos disponibles

TRABAJO FINAL DE CARRERA

2.3.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.2. Recepcion de datos de la Placa de Adquisicion de Datos por bus CAN 94

A.2. Placa de Adquisicion de Datos

APENDICE B. Diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . 161

APENDICE C. Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

APENDICE D. Problemas en Datasheet del ADIS16100

50 52 53 54 55 55 56 59 60 61 62 63 65 66 67 68 69 70 71 72 74 75 76 77 78 81 82 83 84 85 86 87 88 89 90 92 93 94 95 96 97 98 99 100 101 102

En el segundo captulo se presenta la metodologa utilizada para poder desarrollar

Para nalizar encontraremos un apartado con las conclusiones obtenidas de los

Diseno y construccion de bus de datos y sensores para las practicas de NACC

En los anexos se encontrara el material de soporte adicional.

CAPTULO 1. CONCEPTOS TEORICOS I

1.1. Nodo de Comunicaciones

Cristal de cuarzo de baja frecuencia (800kHz).

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Figura 1.2: Mercado mundial de los PICs

XT corresponde a Crystal/Resonator, HS a High-Speed Crystal/Resonator y LP a Low-Power Crystal.

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Tabla 1.1: Conguracion de condensadores segun el reloj

Pin 4, 5 y 6 13 y 14 37, 38 y 39 35 y 36 38, 39 y 40 18 25 y 26 23 23 y 24

Tabla 1.2: Puertos y pines utilizados en el PIC18F4580

1.1.2. CAN (Controller Area Network)

Es un sistema que se ha ido adaptando a otros campos, lo que ha hecho que su

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Facilidad de desarrollo y gran cantidad de fabricantes en el mercado de dispositivos

Su sistema de prioridades no destructivo, que permite que en caso de que se

Figura 1.6: Modelo OSI

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Figura 1.10: Ejemplo de arbitracion en CAN

ACK: Un receptor que recibe un mensaje correctamente se lo notica al transmisor

La LLC (Logical Link Control) es la capa que esta relacionada con;

Filtrado de mensajes: Como hemos comentado anteriormente, los dispositivos no

1.1.3. RS232 (Recommended Standard 232)

Diseno y construccion de bus de datos y sensores para las practicas de NACC

RI: Lnea en la que se indica que se ha detectado una portadora.

Protocolo serie (numero de bits - paridad - bits de parada): La paridad se utiliza

Figura 1.12: Conguracion 7N1 del RS232.

1.1.4. I2C (Inter-Integrated Circuit)

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Es un bus serial, de 8 bits, bidireccional y a diferencia del RS232 no es orientado a

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Figura 1.16: Ejemplo de comunicacion I2C.

1.1.5. SPI (Serial Peripheral Interface)

Figura 1.17: Conexion del CS de SPI a los diferentes dispositivos.

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Figura 1.19: Ejemplo de comunicacion SPI.

1.2. Placa de adquisicion de datos

Reloj: Como en el caso del PIC18F4580, hemos seleccionado un oscilador externo

Tabla 1.4: Puertos y pines utilizados en el PIC18F2580

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Memoria de programa: Tiene 16 kbytes de memoria Flash.

1.2.2. MEMS (Micro Electro-Mechanical Systems)

Diseno y construccion de bus de datos y sensores para las practicas de NACC

Max 4,52 800 +37

Units V LSB/o /s bits ns o /sec LSB o C

-42 2048 -40 a 85

Abreviatura DIN SCLK DOUT NC RATE FILT

Tabla 1.6: Descripcion de los pines del ADIS16100.

Tabla 1.7: Tabla de pruebas del ADIS16100.

Diseno y construccion de bus de datos y sensores para las practicas de NACC

0 D/C ADD1 ADD0

Tabla 1.8: Descripcion de la asignacion de bits en el registro DIN.