can con 18f4580

TRABAJO FINAL DE CARRERA

TITULO DEL TFC : Dise no y construcci on de bus de datos y sensores para laspr acticas de NACC

TITULACION: Ingenierıa T ecnica Telecomunicaciones, especialidad Sistemas deTelecomunicaci on / Ingenierıa T ecnica Aeron autica, especialidad Aeronavegaci on

AUTORES: Christian Miranda Estepa , Jonathan Ronquillo Guerrer o

DIRECTOR: Dagoberto Salazar

FECHA: 15 de enero de 2008

Tıtulo : 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 final de carrera se puede dividir en dos partes. En la primera parte creare-mos un nodo (o interface) de comunicaciones que sea capaz de recibir datos mediantediferentes protocolos como SPI, I2C, RS232 y transmitirlo todo a un bus principal (CANBus). De esta forma, se podran comunicar diferentes dispositivos sin preocuparnos delprotocolo nativo que utilicen. El control de este nodo de comunicaciones se realiza con unmicrocontrolador PIC18F4580, ya que este se adapta perfectamente a nuestros objetivos.Para implementar la parte software hemos utilizado el compilador CCS y las librerıas quese 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 datosque incluye unos sensores que proporcionan informacion de inclinacion, aceleracion y ve-locidad 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 comunicacionesen CANBus, y ası poder utilizar multiples dispositivos en las practicas de la asignatura“Navegacion Aerea, Cartografıa y Cosmografıa” (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 final Project can be divided into two parts. In the first one we will create a commu-nications 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, differentDevices will be able to communicate without worrying about the protocol being used. Thecontrol of this communication node is carried out by a PIC18f4580 microcontroller becauseit suits perfectly to our objectives. In order to implement the software part, we have usedthe CCS compiler and its libraries, developed for CAN.

Once the first part (the communications one) is finished, our work gets focused on thesecond part (the one related with navigation instrumentation). An acquisition data plateis developed including sensors which give information of slope, acceleration and angularvelocity.

The general idea is to connect our plate of sensors with other devices (for instance, devicesbuilt by other realized by TFC students) using the communication nodes in CANBus, andthen we will be able to use multiple devices in laboratory work of the subject “NavegacionAerea, Cartografia y Cosmografia” (NACC).

En el plano emocional este trabajo va dedicado a nuestros padres por su paciencia ycomprension.

En el plano tecnico queremos agradecer, sobre todo, a nuestro tutor Dagoberto Salazarpor 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.

INDICE GENERAL

INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

CAPITULO 1.Conceptos Te oricos . . . . . . . . . . . . . . . . . . . . . 3

1.1. Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1. PIC (Peripheral Interface Controller) . . . . . . . . . . . . . . . . . 3

1.1.2. CAN (Controller Area Network) . . . . . . . . . . . . . . . . . . . . 7

1.1.3. RS232 (Recommended Standard 232) . . . . . . . . . . . . . . . . 13

1.1.4. I2C (Inter-Integrated Circuit) . . . . . . . . . . . . . . . . . . . . . . 15

1.1.5. SPI (Serial Peripheral Interface) . . . . . . . . . . . . . . . . . . . . 18

1.2. Placa de adquisici on de datos . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2.1. PIC18F2580 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2.2. MEMS (Micro Electro-Mechanical Systems) . . . . . . . . . . . . . 22

1.2.3. Sistema Inercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

CAPITULO 2.Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.1. Protocolo CAN utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2. Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.3. Placa de Adquisici on de Datos . . . . . . . . . . . . . . . . . . . . . . . . 66

2.3.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

2.3.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

CAPITULO 3.Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.2. Nodo de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.2.1. RS232-CAN-RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.2.2. I2C-CAN-RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.2.3. SPI-CAN-RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.3. Placa de adquisici on de datos . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.3.1. Recepcion de datos de un solo ADIS16100 . . . . . . . . . . . . . . 90

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

3.4. Experimento final: Placa Adquisici on de Datos, PC y GPS con otro PCmonitorizando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

CAPITULO 4.Conclusiones y Recomendaciones . . . . . . . . . . . 113

SIGLAS Y ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . 117

BIBLIOGRAF IA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

APENDICE A. Codigo implementado . . . . . . . . . . . . . . . . . . . 121

A.1. Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A.1.1. tfc.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A.1.2. funciones.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.1.3. funciones.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

A.2. Placa de Adquisici on de Datos . . . . . . . . . . . . . . . . . . . . . . . . 136

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 . . . . . . . . . . . . . . . . . . . . . . . . . . 147

A.3.2. experimentos spi modo2.c . . . . . . . . . . . . . . . . . . . . . . 150

A.3.3. experimentos i2c.c . . . . . . . . . . . . . . . . . . . . . . . . . . 152

A.4. experimentos i2c modo2.c . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

A.5. experimento solo 1 adis.c . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

APENDICE B. Diagramas de flujo . . . . . . . . . . . . . . . . . . . . . . 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 adquisici on de datos . . . . . . . . . . . . . . . . . . . . . . . . . 170

APENDICE D. Problemas en Datasheet del ADIS16100 . . . . . . . 173

APENDICE E. Lista de componentes y presupuesto del proyecto. 1 75

APENDICE F. Estudio previo. Ejercicios de familiarizaci on con elprotocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . 179

F.1. Utilizando el software de desarrollo (IDE)Familiarizaci on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 anal ogicas . . . . . . . . . . . . . . . . . . . . . 187

INDICE DE FIGURAS

1.1 Componentes que configuran un microcontrolador . . . . . . . . . . . . . . . 41.2 Mercado mundial de los PIC’s . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Diagrama de pines del PIC 18F4580 . . . . . . . . . . . . . . . . . . . . . . . 61.4 Ejemplo de envıo de paquete en CAN . . . . . . . . . . . . . . . . . . . . . . 81.5 Velocidad del bus CAN en funcion de la longitud . . . . . . . . . . . . . . . . . 91.6 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.7 Modelo Niveles de tension utilizados en CAN . . . . . . . . . . . . . . . . . . 101.8 Formato estandar y extendido de las tramas CAN. . . . . . . . . . . . . . . . 111.9 Campos de las tramas CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.10Ejemplo de arbitracion en CAN . . . . . . . . . . . . . . . . . . . . . . . . . . 121.11Conectores DB-25 y DB-9 en RS232. . . . . . . . . . . . . . . . . . . . . . . 151.12Configuracion 7N1 del RS232. . . . . . . . . . . . . . . . . . . . . . . . . . . 151.13Esquema de conexion del bus I2C. . . . . . . . . . . . . . . . . . . . . . . . . 161.14Condicion de inicio del I2C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.15Condicion de parada del I2C. . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.16Ejemplo de comunicacion I2C. . . . . . . . . . . . . . . . . . . . . . . . . . . 181.17Conexion del CS de SPI a los diferentes dispositivos. . . . . . . . . . . . . . . 191.18Desplazamiento de bits en Esclavo SPI. . . . . . . . . . . . . . . . . . . . . . 201.19Ejemplo de comunicacion SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . 201.20Diagrama de pines del PIC 18F2580 . . . . . . . . . . . . . . . . . . . . . . . 211.21Diagrama de bloques del ADIS16100. . . . . . . . . . . . . . . . . . . . . . . 231.22La senal del ADIS16100 incrementa con el angulo de giro. . . . . . . . . . . . 231.23Diagrama de secuencia de configuracion/lectura en ADIS16100. . . . . . . . . 261.24Diagrama de secuencia SPI en ADIS16100. . . . . . . . . . . . . . . . . . . . 271.25Diagrama de bloques del ADIS16201. . . . . . . . . . . . . . . . . . . . . . . 301.26Disposicion de los pines del ADIS16201. . . . . . . . . . . . . . . . . . . . . 311.27Posibles orientaciones del ADIS16201. . . . . . . . . . . . . . . . . . . . . . 311.28Escritura-Lectura del ADIS16201. . . . . . . . . . . . . . . . . . . . . . . . . 321.29Registros DIN/DOUT del ADIS16201. . . . . . . . . . . . . . . . . . . . . . . 321.30Los tres ejes de movimiento de una aeronave. . . . . . . . . . . . . . . . . . . 34

2.1 Campo ID dividido en 3 sub-campos. . . . . . . . . . . . . . . . . . . . . . . 372.2 Tipos de mensaje en el protocolo CAN. . . . . . . . . . . . . . . . . . . . . . 392.3 Diagrama esquematico. Nodo de Comunicaciones. . . . . . . . . . . . . . . . 432.4 Polarizacion del conector de alimentacion. . . . . . . . . . . . . . . . . . . . . 442.5 Bloque de alimentacion del Nodo de Comunicaciones. . . . . . . . . . . . . . 442.6 Bloque del clock del Nodo de Comunicaciones. . . . . . . . . . . . . . . . . . 452.7 Conector RJ12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.8 Bloque de programacion del Nodo de Comunicaciones. . . . . . . . . . . . . . 462.9 Bloque de comunicaciones del Nodo de Comunicaciones. . . . . . . . . . . . 472.10Configuracion MAX232. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.11Pines del PCA82C251. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.12Interruptores activacion/desactivacion de las resistencias PULL-UP. . . . . . . 492.13Terminales de conexiones externas del Nodo de Comunicaciones. . . . . . . . 49

2.14Cable NULL-MODEM - Cable directo. . . . . . . . . . . . . . . . . . . . . . . 502.15PCB del Nodo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . 522.16Programador ICD utilizado a la hora de programar. . . . . . . . . . . . . . . . 532.17Esquema flujo de datos en INT CANRX0. . . . . . . . . . . . . . . . . . . . . 542.18Esquema flujo de datos en INT SSP. . . . . . . . . . . . . . . . . . . . . . . . 552.19Esquema flujo de datos en INT RDA. . . . . . . . . . . . . . . . . . . . . . . 552.20Jerarquıa de los ficheros utilizados en Nodo de Comunicaciones. . . . . . . . . 562.21Diagrama de flujo del modulo ’Configuracion Nodo de Comunicaciones’. . . . . 592.22Diagrama de flujo del modulo ’Interrupcion Interruptores’. . . . . . . . . . . . . 602.23Diagrama de flujo del modulo ’Interrupcion CAN’. . . . . . . . . . . . . . . . . 612.24Distribucion de los dos bytes con informacion del ID. . . . . . . . . . . . . . . 622.25Diagrama de flujo del modulo ’Procesado de Datos CAN’. . . . . . . . . . . . . 632.26Diagrama de flujo del modulo ’Interrupcion I2C y SPI’. . . . . . . . . . . . . . . 652.27Diagrama de flujo del modulo ’Interrupcion RS232’. . . . . . . . . . . . . . . . 662.28Diagrama esquematico. Placa de Adquisicion de Datos. . . . . . . . . . . . . . 672.29M1117t alimentacion ADIS16201 a 3,3 V y condensadores de 10 µF. . . . . . . 682.30Bloque de programacion. Resistencias de 1 kΩ. . . . . . . . . . . . . . . . . . 692.31Diagrama esquematico de la tarjeta y sus conexiones al conector estandar dual

row de 2mm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.32Esquema de la disposicion de los sensores en la placa. . . . . . . . . . . . . . 712.33Ejemplo de envıo de 16 bits por SPI. . . . . . . . . . . . . . . . . . . . . . . . 722.34Jerarquıa de los ficheros utilizados en la Placa de Adquisicion de Datos. . . . . 742.35Diagrama de flujo del modulo ’Configuracion Placa Adquisicion de Datos’. . . . 752.36Diagrama de flujo del modulo ’Interrupcion RDA en ADIS16201’. . . . . . . . . 762.37Protocolo NMEA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.38Diagrama de flujo del modulo ’Pedido y Envio de Datos en ADIS16201’. . . . . 78

3.1 Configuracion HyperTerminal. . . . . . . . . . . . . . . . . . . . . . . . . . . 813.2 Interruptor RS232 en ON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3 Esquema montaje experimentos RS232-CAN-RS232. . . . . . . . . . . . . . . 833.4 Montaje experimentos RS232-CAN-RS232. . . . . . . . . . . . . . . . . . . . 843.5 Resultado de las pruebas 1 a la 13. . . . . . . . . . . . . . . . . . . . . . . . 853.6 Esquema: Ejemplo de la distribucion de ID’s entre 3 PC’s. . . . . . . . . . . . . 863.7 Interruptor I2C en ON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.8 Esquema montaje experimentos I2C-CAN-RS232. . . . . . . . . . . . . . . . 883.9 Interruptor SPI en ON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.10Esquema montaje experimentos SPI-CAN-RS232. . . . . . . . . . . . . . . . 903.11Resultados de temperatura en Offset Binary del primer ADIS16100. . . . . . . 923.12Resultados de temperatura en Complemento a 2 del primer ADIS16100. . . . . 933.13Resultados de velocidad angular en Offset Binary del primer ADIS16100. . . . 943.14Resultados de velocidad angular en Complemento a 2 del primer ADIS16100. . 953.15Resultados de temperatura en Offset Binary del segundo ADIS16100. . . . . . 963.16Resultados de temperatura en Complemento a 2 del segundo ADIS16100. . . . 973.17Resultados de velocidad angular en Offset Binary del segundo ADIS16100. . . 983.18Resultados de velocidad angular en Complemento a 2 del segundo ADIS16100. 993.19Esquema del experimento ’Recepcion de datos de la Placa de Adquisicion’. . . 1003.20Resultados a los 8 pedidos posibles desde el PC. . . . . . . . . . . . . . . . . 1013.21GPS utilizado en el experimento. . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.22Esquema de conexion de los pines UserTerminal. . . . . . . . . . . . . . . . . 1063.23Montaje del experimento final. . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.24Resultado al conectar el GPS. . . . . . . . . . . . . . . . . . . . . . . . . . . 1093.25Resultado al conectar el GPS y la placa de adquisicion de datos. . . . . . . . . 1103.26Resultado al conectar el GPS, la placa de adquisicion de datos y otro PC. . . . 111

B.1 Simbolos utilizados en el diagrama de flujo. . . . . . . . . . . . . . . . . . . . 161B.2 Diagrama de flujo del modulo ’Configuracion Nodo de Comunicaciones’. . . . . 161B.3 Diagrama de flujo del modulo ’Interrupcion Interruptores’. . . . . . . . . . . . . 162B.4 Diagrama de flujo del modulo ’Interrupcion CAN’. . . . . . . . . . . . . . . . . 162B.5 Diagrama de flujo del modulo ’Procesado Datos CAN’. . . . . . . . . . . . . . 163B.6 Diagrama de flujo del modulo ’Interrupcion I2C y SPI’. . . . . . . . . . . . . . . 164B.7 Diagrama de flujo del modulo ’Interrupcion RS232’. . . . . . . . . . . . . . . . 164B.8 Diagrama de flujo del modulo Configuracion Placa Adquisicion de Datos. . . . . 165B.9 Diagrama de flujo del modulo Interrupcion RDA en ADIS16201. . . . . . . . . . 165B.10Diagrama de flujo del modulo Pedido y envio de datos en ADIS16201. . . . . . 166

C.1 Capa top del Layout del nodo de comunicacion. . . . . . . . . . . . . . . . . . 167C.2 Capa bottom del Layout del nodo de comunicacion. . . . . . . . . . . . . . . . 168C.3 Layout con las capas top y bottom del nodo de comunicacion. . . . . . . . . . 169C.4 Capa top del Layout de la placa de adquisicion de datos. . . . . . . . . . . . . 170C.5 Capa bottom del Layout de la placa de adquisicion de datos. . . . . . . . . . . 171C.6 Layout con las capas top y bottom de la placa de adquisicion de datos. . . . . . 172C.7 Layout placa acopladora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

D.1 Tabla con los diferentes modos de trabajo de SPI en el PIC18F2580. . . . . . . 174

F.1 Asociacion LED’s con los puertos RB del PIC . . . . . . . . . . . . . . . . . . 181F.2 Ejercicio 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182F.3 Registro del MCP25050. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182F.4 Codigo a anadir en la librerıa ’ccscana.c’. . . . . . . . . . . . . . . . . . . . . 183F.5 Resultado del ejercicio anterior . . . . . . . . . . . . . . . . . . . . . . . . . . 184F.6 Registros del MCP25050. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185F.7 LED’s del nodo C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187F.8 Codigo del ejercicio hecho por nosotros. . . . . . . . . . . . . . . . . . . . . . 188F.9 Codigo del ejercicio del potenciometro. . . . . . . . . . . . . . . . . . . . . . 189

INDICE DE TABLAS

1.1 Configuracion de condensadores segun el reloj . . . . . . . . . . . . . . . . . 61.2 Puertos y pines utilizados en el PIC18F4580 . . . . . . . . . . . . . . . . . . 71.3 Senales mas comunes en RS232 y sus respectivos pines en los conectores. . . 141.4 Puertos y pines utilizados en el PIC18F2580 . . . . . . . . . . . . . . . . . . 211.5 Especificaciones mas importantes del ADIS16100. . . . . . . . . . . . . . . . 241.6 Descripcion de los pines del ADIS16100. . . . . . . . . . . . . . . . . . . . . 251.7 Tabla de pruebas del ADIS16100. . . . . . . . . . . . . . . . . . . . . . . . . 251.8 Descripcion de la asignacion de bits en el registro DIN. . . . . . . . . . . . . . 271.9 Descripcion de la asignacion de bits en el registro DOUT. . . . . . . . . . . . . 281.10Ejemplos de datos de salida del ADIS16100. . . . . . . . . . . . . . . . . . . 291.11Especificaciones mas importantes del ADIS16201. . . . . . . . . . . . . . . . 331.12Descripcion de los pines del ADIS16201. . . . . . . . . . . . . . . . . . . . . 33

2.1 Identificadores asociados a los mensajes utilizados en la Placa de Adquisicionde Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.2 Tabla de aceptacion de mensajes de la Placa de Adquisicion de Datos. . . . . 422.3 Caracterısticas si la tabla de aceptacion esta en el Nodo de Comunicaciones. . 422.4 Caracterısticas si la tabla de aceptacion esta en el Dispositivo. . . . . . . . . . 422.5 Otros Transceivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.6 Configuracion interruptores de seleccion de protocolos. . . . . . . . . . . . . . 50

E.1 Lista de precios componentes nodo. . . . . . . . . . . . . . . . . . . . . . . . 176E.2 Lista de precios componentes placa de adquisicion. . . . . . . . . . . . . . . . 177

1

INTRODUCCION

En la asignatura “Navegacion Aerea, Cartografıa y Cosmografıa” (NACC) se pretendeincluir practicas en la que los alumnos puedan ver el funcionamiento de un sistema denavegacion. La finalidad de un sistema de navegacion es poder determinar la ruta seguidapor el vehıculo y en consecuencia, guiarlo de manera adecuada.

Este sistema de navegacion estarıa 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 datosrecibidos por estos dos sensores y transmitirlos a una estacion central, como por ejemploun 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 vehıculo.

El objetivo de este trabajo final de carrera es doble: En una primera parte se disena unnodo de comunicaciones capaz de hacer de interfaz entre dispositivos que hablan enRS232, SPI o I2C, y un bus general de comunicaciones llamado Bus CAN. En la segundaparte 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 pro-tocolo a utilizar) en la que realizamos diferentes experimentos. Para hacer estos expe-rimentos implementamos dos nodos de comunicaciones de prueba en dos protoboards(prototipos). Al tener los dos prototipos pudimos probar la comunicacion RS232-CAN-RS232, SPI-CAN-SPI y I2C-CAN-I2C. Lo que se pretendıa en cada subparte era obteneruna comunicacion entre los nodos de comunicacion. Una vez comprobado el correctofuncionamiento de los prototipos se elaboraron los dispositivos definitivos.

La finalidad 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 sepodra emular un INS (solo faltarıa el procesado final que se realizara en otro modulo).

La prueba final 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 PCse monitorizaran todos los datos.

La distribucion de esta memoria es la siguiente:

• Un primer capıtulo donde se explican los conceptos teoricos mas importantes parapoder entender el trabajo, y que servira de introduccion a los siguientes capıtulos.

• En el segundo capıtulo se presenta la metodologıa utilizada para poder desarrollareste proyecto: Que hemos hecho y como lo hemos hecho.

• El tercer capıtulo consiste en presentar las diferentes pruebas realizadas en las dosplacas electronicas para comprobar su correcto funcionamiento.

• Para finalizar encontraremos un apartado con las conclusiones obtenidas de losexperimentos realizados.

2 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 3

CAPITULO 1. CONCEPTOS TEORICOS

El objetivo de este capıtulo 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 correctoseguimiento 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 partedel proyecto (nodo de comunicaciones). Hemos considerado importante destacar tanto elfuncionamiento 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 datosdisenada. En primer lugar se explican los MEMS y el PIC utilizado y seguidamente sedescribe 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 escogimoseste tipo de µC debido a su bajo precio, sencillo manejo y programacion, y a la cantidadde documentacion y usuarios que hay detras de ellos. Aunque no son los µC que masprestaciones ofrecen, sus caracterısticas se ajustan perfectamente a nuestro proyecto.

Existe una gran cantidad de modelos de PIC con caracterısticas y prestaciones diferentes.Esto hace que el desarrollador pueda escoger el modelo que mas se ajuste a sus necesi-dades.

Para que el PIC pueda realizar sus funciones lo primero que se ha de hacer es programar-lo, es decir, hemos de escribir un programa que contenga los procesos que el PIC debaejecutar. Este programa se puede escribir en varios lenguajes de programacion, pero losmas utilizados son el ’Assembler’ (ensamblador) y el C. Aun faltarıa un ultimo paso paraque el PIC pueda entender lo que hemos escrito. Este ultimo paso es traducir este progra-ma a lenguaje maquina (1’s y 0’s). Gracias a los compiladores este proceso es bastantedirecto. En este trabajo final de carrera hemos programado en C y el compilador utilizadoes el proporcionado por la empresa CCS (Custom Computer Services, Inc.).

Como todo µC, un PIC se puede dividir en diferentes bloques (Ver la figura 1.1);

• Reloj : Todos los PIC disponen de un circuito oscilador que genera una onda cua-drada de alta frecuencia que se utiliza para sincronizar todas las operaciones delsistema. El PIC tiene un oscilador interno incorporado, y en funcion de la velocidadde trabajo con la que queramos trabajar utilizaremos este oscilador (velocidadesmas bajas) o un oscilador externo (velocidades altas) como por ejemplo cristal decuarzo, resonador ceramico1 o una red R-C. Aumentar la frecuencia del reloj im-

1Cristal de cuarzo de baja frecuencia (800kHz).


Figura 1.1: Componentes que configuran un microcontrolador

plica disminuir el tiempo de ejecucion de las instrucciones, pero lleva aparejado unincremento de la temperatura.

• I/O (In/Out) : La mayorıa de los pines que posee un PIC son de I/O y se destinan aproporcionar el soporte a las senales de entrada, salida y de control.

• CPU: Es el elemento que interpreta las instrucciones y procesa los datos en losprogramas del PIC.

• Memoria de datos : Los datos que manejan los programas varıan continuamente, yesto exige que la memoria que los contiene debe ser de escritura y de lectura, porlo que la memoria RAM (Random Access Memory) es la mas adecuada, aunquesea volatil.

Tambien se dispone de una memoria de lectura y escritura no volatil, del tipoEEPROM (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 estesiempre es el mismo, debe estar grabado de forma permanente.

Existen varios tipos de memoria adecuados para soportar estas funciones, de lascuales en los PIC se utilizan la ROM (Read-Only Memory), OTP (One-Time Pro-grammable) y Flash.

• Perif ericos : Se llama perifericos a todas aquellas unidades a traves de las cuales elPIC se comunica con el mundo exterior. En los PIC podemos encontrar ADC (Analogto Digital Converter), comparadores, temporizadores, y perifericos destinados a lascomunicaciones como los siguientes;

– EUSART (Enhanced Universal Synchronous Asynchronous Receiver Trans-mitter): Interfaz entrada salida serie. Con este modulo podemos transformarlos datos en serie a paralelo y al reves. De esta forma se pueden adaptar losdatos con los que trabaja el PIC (en paralelo) con los que le pueden llegar atraves de este puerto (serie). Es el utilizado por el protocolo RS232.

– USB (Universal Serial Bus): Permite operar con el protocolo USB.


– MSSP (Master Synchronous Serial Port): Es una interfaz serie integrada enel PIC disenada para comunicarse con otros perifericos o µC. Permite operarcon 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 utili-zar como comparador, como capturador o como PWM (Pulse-Width Modula-tion).

Para finalizar creemos importante destacar que los proyectos en los que se suelen trabajarcon PIC’s pueden ser muy variados, por ejemplo la automocion, la industria, informatica,comunicaciones, etc (Ver la figura 1.2).

Figura 1.2: Mercado mundial de los PIC’s

1.1.1.1. PIC18F4580

Una vez vistas las caracterısticas generales de los PIC, nos hace falta conocer las es-pecificaciones del PIC a utilizar en nuestro diseno. El PIC elegido para este trabajo es elPIC18F4580 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 quese distribuyen como se muestra en la figura 1.3.

Las caracterısticas mas importantes son las siguientes:

• Reloj : Ofrece varias opciones de configuracion de la frecuencia de oscilacion, per-mitiendo al usuario escoger segun se adapte a sus necesidades:

– Utilizando un cristal o un resonador ceramico y conectandolos a los pinesOSC1 y OSC2 del PIC. Para la eleccion de la frecuencia de oscilacion, elfabricante nos ofrece unas tablas2 (Ver la tabla 1.1);

2XT 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 Cer amicos Osciladores de cristal

Modo Frecuencia OSC1 OSC2 Modo Frecuencia OSC1 OSC2

XT455kHz 56pF 56pF

LP32kHz 33pF 33pF

2MHz 47pF 47pF 200kHz 15pF 15pF4MHz 33pF 33pF

XT1MHz 33pF 33pF

HS8MHz 27pF 27pF 4MHz 27pF 27pF

16MHz 22pF 22pFHS

4MHz 27pF 27pF8MHz 22pF 22pF

20MHz 15pF 15pF

Tabla 1.1: Configuracion de condensadores segun el reloj

Los condensadores elegidos van del pin OSC1 o OSC2 a 0V (GND). En eldiseno de nuestra placa hemos escogido como frecuencia de oscilacion 20MHz.

– 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 configuracion de pi-nes que en el caso anterior. Un oscilador RC esta formado por un condensadorno polarizado y una resistencia. Este tipo de oscilador proporciona una esta-bilidad mediocre en la frecuencia generada y podra ser utilizado para aquellosproyectos que no requieran precision.

– Utilizando un oscilador interno. Este metodo se suele utilizar en los casos quese quieran aprovechar los pines OSC1 y OSC2 como I/O.

– Utilizando un multiplicador de frecuencia PLL (Phase Lock Loop). Gracias alPLL 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 tresregistros 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 enoperaciones lectura-modificacion-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.


Pin Funcionalidad

Puerto A4, 5 y 6 LED’s13 y 14 Reloj

Puerto B37, 38 y 39 Interruptores

35 y 36 CAN38, 39 y 40 Para programar el PIC

Puerto C18 Reloj I2C y SPI

25 y 26 Datos RS23223 Datos I2C

23 y 24 Datos SPIPuerto D

No utilizadoPuerto E

1 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.

• Perif ericos : En el PIC18F4580 podemos encontrar 11 ADC de 10 bits, dos modulosCCP/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 aplicacionen sistemas distribuidos en tiempo real. Originalmente el bus CAN fue desarrollado pa-ra aplicaciones en la industria automotriz, pero debido a sus caracterısticas, robustez yexcelente relacion calidad/precio, CAN fue adoptado para aplicaciones industriales y decontrol.

El protocolo de comunicacion CAN fue especificado originalmente por la companıa ale-mana Robert Bosch para aplicaciones crıticas en tiempo real.

Los motivos principales que nos han llevado a la eleccion de este protocolo son las si-guientes:

• Tratamiento de errores muy eficaz. 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 posiblessistemas.

• Posibilidad de implementacion con dispositivos relativamente simples y baratos co-mo por ejemplo los PICs que usamos.

• Facilidad de desarrollo y gran cantidad de fabricantes en el mercado de dispositivosCAN.

• Su sistema de prioridades “no destructivo”, que permite que en caso de que setransmitan dos mensajes simultaneamente, el de mayor prioridad no se destruya yllegue a su destino sin ningun tipo de retardo anadido.

• Su sistema de identificacion de mensajes, que consiste en que los nodos no tienenrealmente una direccion, sino que se programan con un sistema de filtros para queacepten un determinado tipo de mensajes (Ver la figura 1.4), es decir, es un siste-ma basado en tipos de mensajes, no en direcciones , lo que hace que se puedananadir nuevos nodos sin tener que reconfigurar el resto de los nodos.

Figura 1.4: Ejemplo de envıo de paquete en CAN

• Su comportamiento en tiempo real: El metodo empleado por el protocolo CAN aso-cia cada mensaje a ser enviado con una prioridad determinada, y usa un meca-nismo especial de arbitraje para asegurar que el mensaje de mayor prioridad seael mensaje transmitido. La prioridad de un mensaje es un numero unico y puedeser usado como el identificador del mensaje. Es por eso que a la prioridad se ledenomina tambien identificador del mensaje.

En cuanto a inconvenientes:

• Protocolo complejo.

• Velocidad limitada por la longitud de la red (Ver la figura 1.5), aunque en este trabajono influye demasiado como para tenerlo en cuenta. Segun el estandar, la velocidadmaxima que puede alcanzar el bus CAN es de 1Mbps y esta se puede alcanzarhasta con una longitud de red de 40 metros. En el marco de nuestro proyecto estono nos afecta.


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 protocoloCAN como son los niveles del bus, implementacion de nodos, etc.

Dado que el protocolo CAN solo define dos niveles del Modelo OSI (Ver la figura 1.6),es necesario que se defina tambien un nivel alto de aplicacion, del que hablaremos en elapartado 2.1..

Figura 1.6: Modelo OSI

1.1.2.1. Capa Fısica

Se definen los parametros a nivel fısico (niveles de senal, corriente, sincronizacion, etc.).CAN no tiene declarada una especificacion como tal, pero los estandares ISO 11898establecen las caracterısticas que deben de cumplir las aplicaciones para la transferenciaen alta y baja velocidad.

La informacion circula por dos cables trenzados que unen todas las unidades de controlque forman el sistema. Esta informacion se trasmite por diferencia de tension entre los doscables, de forma que un valor alto de tension representa un 1 y un valor bajo de tensionrepresenta un 0. La combinacion adecuada de unos y ceros conforman el mensaje atrasmitir.

En un cable los valores de tension oscilan entre 0 V y 2.25 V, por lo que se denominacable L (Low), y el otro cable, llamado cable H (High) tiene niveles de tension entre 2.75


V y 5 V (Ver la figura 1.7).

En caso de que se interrumpa la lınea H o que se derive a masa, el sistema trabajara con lasenal de Low con respecto a masa. En el caso de que se interrumpa la lınea L, ocurrira locontrario. Esta situacion permite que el sistema siga trabajando con uno de los cablescortados o comunicados a masa, quedando fuera de servicio solamente cuando amboscables 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 elvalor recesivo se produce con el bit a ’1’.

Es importante tener en cuenta que el trenzado entre ambas lıneas sirve para anular loscampos magneticos, por lo que no se debe modificar en ningun caso ni el paso ni lalongitud 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 envıa : Para la transmision y control de mensajes CAN sedefinen cuatro tipos de tramas:

– De datos,

– remota (transmitido por una unidad de bus que requiere la transmision de unatrama de datos con el mismo identificador),

– 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 yremotas).

Tanto las tramas de datos y las tramas remotas tienen dos formatos. Un formato esel llamado Estandar y el otro es el Extendido, y se diferencian en el numero de bitsque tiene el identificador (la estandar tiene 11 bits y la extendida tiene 29 bits) (Verla figura 1.8). Las tramas de datos y las remotas se separan de tramas precedentesmediante espacios entre tramas (interframe space).

Dentro de las tramas de datos y remotas podemos encontrarnos con diferentescampos (Ver la figura 1.9):

– Inicio de trama: consiste en un bit a ’0’.


Figura 1.8: Formato estandar y extendido de las tramas CAN.

– Campo de arbitracion: campo donde se introduce el identificador.

– Campo de control: campo donde se indica la longitud de los datos.

– Campo de datos: campo donde se introducen los datos (como maximo 8 by-tes).

– 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 nocontiene el campo de datos.

• Arbitraci on : Cuando el bus esta idle (libre), cualquier unidad puede transmitir unmensaje. Si dos o mas dispositivos quieren transmitir mensajes al mismo tiempo, el


conflicto de quien accedera al bus sera resuelto por el “arbitro” utilizando el identifi-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 identificador, la tramade datos prevalece sobre la trama remota.

Durante la arbitracion cada transmisor compara el nivel del bit transmitido con el quemonitoriza el bus: Si esos niveles son iguales continua enviando, si son diferentes ylo que hemos enviado es un bit recesivo ’1’ y monitorizamos un bit dominante ’0’, launidad habra perdido la arbitracion y debera dejar de transmitir (Ver la figura 1.10).

Figura 1.10: Ejemplo de arbitracion en CAN

• ACK : Un receptor que recibe un mensaje correctamente se lo notifica al transmisorponiendo el bit del campo ACK a ’0’ (dominante), de forma que el transmisor queesta todavıa trasmitiendo reconoce que al menos alguien ha recibido un mensajeescrito 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 controladorCAN cuenta con la capacidad de detectar y manejar los errores que surjan en unared. Todo error detectado por un nodo se notifica inmediatamente al resto de losnodos.

• Definir el m etodo de acceso : El metodo de acceso al medio utilizado es el deAcceso Multiple por Deteccion de Portadora, con Deteccion de Colisiones y Arbitra-je por Prioridad de Mensaje (CSMA/CD+AMP, Carrier Sense Multiple Access withCollision Detection and Arbitration Message Priority).

De acuerdo con este metodo, los nodos en la red que necesitan transmitir infor-macion deben esperar a que el bus este libre (deteccion de portadora). Cuando secumple 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 elvalor transmitido con el valor recibido; mientras los valores sean identicos, el nodocontinua 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 notienen realmente una direccion, sino que se programan con un sistema de filtrospara que acepten un determinado tipo de mensajes


• Proceso de soluci on de errores (reenvıo) : El protocolo CAN tiene cinco metodosde repaso de errores, tres en el nivel de mensaje y dos en el nivel del bit. Si unmensaje tiene alguno de estos errores, no se aceptara y se generara una trama deerror para que el resto de los nodos no hagan caso del mensaje defectuoso, y paraque 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 bloquearel funcionamiento del sistema completo. Cada nodo activo transmite una bandera de errorcuando detecta algun tipo de error y puede ocasionar que un nodo defectuoso puedaacaparar el medio fısico.

Para eliminar este riesgo el protocolo CAN define un mecanismo autonomo para detectary desconectar un nodo defectuoso del bus. Dicho mecanismo se conoce como aislamientode fallos o ’Fault Confinement’.

1.1.2.4. Capa de aplicacion

Existen diferentes estandares que definen la capa de aplicacion; algunos son muy espe-cıficos 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 necesidadde un acuerdo que permitiera a los equipos de varios fabricantes comunicarse entre si. LaEIA (Electronics Industry Association) elaboro la norma RS-232, la cual define la interfazmecanica, 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, unprotocolo donde toda la informacion es enviada por un solo canal bit a bit (un canal paraenviar informacion y otro para recibirla), y donde lo que se envıan son caracteres. Porejemplo, si queremos enviar el numero 123, primero tendremos que enviar el caracter 1,seguidamente el 2 y para finalizar 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, yse puede trabajar de forma asıncrona o sıncrona y con tipos de canal simplex, halfduplexy fullduplex3.

3Una 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


Una conexion RS232 esta definida por un cable desde un dispositivo al otro. Hay 25 co-nexiones en la especificacion completa pero en la mayorıa de los casos se utilizan menosde la mitad. Los conectores mas utilizados son los DB9 y los DB25 (Ver la figura 1.11).

En la tabla 1.3 se puede observar las senales mas comunes en RS232 segun los pinesdel conector asignados:

• GND: Valor a 0V.

• TD: Lınea de datos del transmisor al receptor.

• RD: Lınea de datos del receptor al transmisor.

• DTR: Lınea por donde el receptor informa al transmisor que esta vivo y bien.

• DSR: Lınea por donde el transmisor informa al receptor que esta vivo y bien.

• RTS: Lınea en la que el transmisor indica que quiere enviar algo al receptor.

• CTS: Lınea en la que se informa que el receptor esta preparado para recibir datos.

• DCD: Lınea por la que el receptor informa al transmisor que tiene una portadoraentrante.

• RI: Lınea en la que se indica que se ha detectado una portadora.

Senal DB-25 DB-9

GND 7 5Transmision de datos (TD) 2 3Recepcion de datos (RD) 3 2

Terminal de datos preparado (DTR) 20 4Datos preparados (DSR) 6 6Peticion de envıo (RTS) 4 7Limpieza de envıo (CTS) 5 8

Portadora de datos detectada (DCD) 8 1Indicador de tono (RI) 22 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 nuestrotrabajo utilizaremos esta configuracion de 3 cables.

Los parametros a configurar en una comunicacion RS232 son los siguientes:

• Protocolo serie (numero de bits - paridad - bits de parada ): La paridad se utilizapara poder comprobar la calidad de los datos recibidos. Los bits de datos puedenestar entre los 5 bits y los 8, y los bits de parada consisten en uno o dos bits puestosa ’1’. En la figura 1.12 se muestra una configuracion 7N1.

que un canal fullduplex permite una comunicacion bidireccional simultanea.


Figura 1.11: Conectores DB-25 y DB-9 en RS232.

En nuestro trabajo utilizaremos la configuracion 8N1 (8 bits de datos sin paridad ycon un bit de parada).

• Velocidad del puerto : RS232 puede transmitir los datos a unas velocidades deter-minadas (normalmente entre 4800 y 115200 bps).

• Protocolo de control de flujo : El control de flujo puede ser mediante hardware gra-cias al llamado ’handshaking’ entre las lıneas RTS y CTS, o por software medianteel XON/XOFF4. En nuestro proyecto no utilizaremos control de flujo.

Figura 1.12: Configuracion 7N1 del RS232.

1.1.4. I2C (Inter-Integrated Circuit)

I2C es un bus bidireccional de dos hilos desarrollado por Philips. Su finalidad principal esla de poder facilitar las comunicaciones entre dispositivos pequenos, como por ejemploentre PICs y memorias EEPROM.

1.1.4.1. Descripcion del bus

Sus caracterısticas mas relevantes se pueden resumir en los siguientes puntos:

4En el XON/XOFF, cuando el receptor quiere que el transmisor pare su envıo de datos envıa XOFF,mientras que cuando el receptor quiere que el transmisor envıe mas datos, envıa XON.


• Esta formado fısicamente 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 conectantodos los dispositivos como se puede observar en la figura 1.13. Por lo tanto, es unprotocolo Halfduplex.

Figura 1.13: Esquema de conexion del bus I2C.

• Todos los dispositivos tienen una direccion propia, que hay que indicar al inicio dela conexion para poder establecerla. Por lo tanto, a diferencia del bus CAN, es unsistema basado en direcciones y no en tipos de mensajes .

• En funcion de si se envıan o se reciben datos, se deben considerar los dispositivoscomo Maestros (Master) o esclavos (Slaves).

El primer dispositivo que encuentre libre el bus, y por lo tanto inicie la comunicaciony 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 acaracteres.

• Debido a que es un bus Multimaster5, puede darse el caso en el que varios disposi-tivos necesiten acceder al medio al mismo tiempo. Para controlar estas situacionesexiste un sistema de arbitraje . Este sistema determina, mediante el SCL y el nivellogico del mismo hilo, que dispositivo tendra prioridad sobre el otro.

• El numero de dispositivos que pueden conectarse al bus esta limitado, de forma queeste 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 llamadasresistencias pull-up . Estas resistencias polarizan las lıneas, de forma que cuandoel 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 datoshasta que se reciben los datos es la siguiente:

5Mas de un master puede controlar el bus al mismo tiempo sin corrupcion de los mensajes.


1. Si un dispositivo necesita establecer comunicacion con otro, debera comprobar queel bus esta libre.

2. Se envıa la condicion de INICIO (Ver la figura 1.14) para ocupar el bus. Entonces elresto de dispositivos escuchan el SDA, por el cual se envıa la direccion de 7 bits deldispositivo 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 tiempode envıo de los bytes por el SDA de los dispositivos, de forma que se puedan leercorrectamente los datos del SDA cuando el SCL cambia del nivel bajo al nivel alto(lectura en el flanco de subida).

4. Una vez enviados los 7 bits de la direccion se envıa un octavo bit que indicara siestamos en modo escritura o lectura en el dispositivo receptor. Este bit es el deno-minado 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 elesclavo enviaran paquetes de 8 bits. Despues de cada paquete se enviara un ACKpara confirmar 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 figura 1.15).

Figura 1.15: Condicion de parada del I2C.

En la figura 1.16 se presenta un ejemplo de como se realiza la comunicacion con elprotocolo I2C.

6Mensaje que se envıa para confirmar que un mensaje o un conjunto de mensajes han llegado


Figura 1.16: Ejemplo de comunicacion I2C.

1.1.5. SPI (Serial Peripheral Interface)

El SPI es un bus fullduplex, sıncrono y serial desarrollado por Motorola. Tambien puedeencontrarse 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 eficiencia y simplicidad que un bus serial puedeofrecer 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 dehilos que contiene senales diferentes:

• MISO, Master In/Slave Out. Esta lınea es una de las dos lıneas unidireccionales.A traves de esta lınea se realiza la transmision de datos de forma unidireccionaldesde la salida del Esclavo a la entrada del Maestro. Cuando el dispositivo no hasido seleccionado para la comunicacion, esta lınea es puesta en un estado de altaimpedancia para evitar interferencias.

• MOSI, Master Out/Slave In. Esta lınea es la segunda de las dos lıneas unidirec-cionales. A traves de esta lınea se realiza la transmision de datos de forma unidi-reccional desde la salida del master a la entrada del esclavo. El dispositivo masterpone los datos sobre la lınea MOSI medio ciclo antes del final del flanco de altaimpedancia para evitar interferencias.

• SCLK , Es el reloj del bus con el que los dispositivos sincronizaran el flujo de datosa traves de las lıneas.

Se pueden configurar 2 parametros que definen 4 modos de sincronizacion. Estosparametros son:

– CPOL (Clock polarity): Determina si el estado IDLE de la lınea SCLK es ennivel bajo (CPOL = 0) o en nivel alto (CPOL = 1). No tiene efecto significativoen el formato de transferencia.


– CPHA (Clock Phase): Determina en cual flanco del reloj los datos son leıdoso escritos. Si CPHA = 0 los datos sobre la lınea MOSI son puestos en elprimer flanco de reloj y los datos sobre la lınea MISO son leıdos en el segundoflanco de reloj. Cuando CPHA = 1 sucede lo contrario, la transferencia de datossucede en el segundo flanco de reloj.

Por lo tanto, segun como se combinen estos dos parametros, tendremos 4 modosdiferentes de trabajo.

Es muy importante que todos los dispositivos dentro del bus trabajen con el mismomodo.

• CS o SS, Chip select o Slave Select. Los dispositivos en SPI no se seleccionan porsoftware utilizando direcciones, como ocurre en I2C. En este protocolo es necesarioutilizar una lınea mas llamada Chip Select, (CS) o Select Slave (SS). De formaque si estamos utilizando 3 dispositivos, el bus estara compuesto por 2 hilos detransmision de datos, 1 de reloj y 3 de CS como se puede observar en la figura1.17.

Si solo se utiliza un Master y un Esclavo como en el caso de nuestro nodo decomunicaciones, las lıneas 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 unEsclavo. Cualquier dispositivo que no haya sido seleccionado debera deshabilitarse pormedio del chip select para evitar interferencia.

La seleccion de los dispositivos es muy sencilla: El master pone a nivel logico bajo ’0’ elchip select del dispositivo en cuestion. El resto pasan a modo de alta impedancia para nointerferir la comunicacion. A partir de este momento se inicia la comunicacion entre losdispositivos. Es algo parecido a la condicion de inicio de I2C.


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 velocidadmaxima es de 5 Mbps (con un clock de 20 MHz), aunque nosotros utilizaremos una velo-cidad de 1,25 Mbps.

Durante la transferencia SPI, los datos son transmitidos y recibidos simultaneamente porcada una de las lıneas MISO y MOSI. Esto ocurre porque los datos entrantes en el Esclavoavanzan en un registro interno de forma que cuando se recibe el byte entero, los datossalen por la lınea SDO (Ver la figura 1.18). La lınea SDO en el esclavo corresponde a lalınea MISO comentada anteriormente, mientras que la SDI en el esclavo corresponde a lalınea MOSI.

Figura 1.18: Desplazamiento de bits en Esclavo SPI.

En la figura 1.19 se puede ver el formato de transferencia del bus SPI.

Figura 1.19: Ejemplo de comunicacion SPI.

1.2. Placa de adquisici on de datos

1.2.1. PIC18F2580

El PIC elegido para la placa de adquisicion de datos es el PIC18F2580. Este PIC tambienpuede soportar los 2 modulos necesarios (EUSART, MSSP) para trabajar con los 2 proto-


colos a utilizar (RS232, SPI). La diferencia con el PIC18F4580 es que tiene menos puertosI/O y menos memoria RAM y Flash.

Como no se utilizaran todos los puertos I/O, el codigo no necesita de grandes memoriasRAM y Flash, y ademas el tamano del PIC18F2580 es mas pequeno, por lo que se adaptaperfectamente al diseno de la placa de adquisicion de datos.

Figura 1.20: Diagrama de pines del PIC 18F2580

Las caracterısticas mas importantes son las siguientes:

• Reloj : Como en el caso del PIC18F4580, hemos seleccionado un oscilador externode 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 muestranpor cada puerto los pines que se han utilizado.

Pin Funcionalidad

Puerto A3 LED

9 y 10 RelojPuerto B

26, 27 y 28 Para programar el PICPuerto C

18 Reloj SPI25 y 26 Datos RS23223 y 24 Datos SPI

Puerto E1 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.


• Memoria de programa : Tiene 16 kbytes de memoria Flash.

• Perif ericos : En el PIC18F2580 podemos encontrar 11 ADC de 10 bits, dos modulosCCP/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 tecnologıa electromecanica micrometrica que seutilizan en algunos circuitos integrados (IC). En estos se integran, encima de un sustrato,sensores, actuadores y elementos electronicos de medidas que van desde los microme-tros a los milımetros.

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 quea 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 utilizanson muy variados:

• Automocion:

– Acelerometros en vehıculos 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 biotecnologıa:

– Sensores de presion para medir la presion sanguınea.

– Circuitos integrados que ayudan a mejorar las prestaciones microscopicas,microchips para detectar la contaminacion quımica y agentes biologicos.

• Comunicaciones e informatica:

– Impresoras de inyeccion de tinta, las cuales usan un piezoelectrico o burbujade inyeccion para depositar la tinta en el papel.

– Desarrollo de material electronico compatible a altas frecuencias haciendo queel tamano total del circuito, consumo y coste final se reduzca, al mismo tiempoque la eficiencia para investigaciones de microondas aumenta.

– Tecnologıa optica de conmutacion, utilizada para comunicacion de datos.

El unico problema que acarrean estos sistemas micro electromecanicos es la fabricacion,puesto que es necesario modificar la tecnologıa de fabricacion convencional para conse-guir reducir algunos efectos que a escala macroscopica son despreciables. Algunos deestos efectos son termicos y electrostaticos.


En este TFC trabajaremos con unos circuitos integrados MEMS, el ADIS 16100 y el 16201fabricados con tecnologıa MST.

1.2.2.1. ADIS16100

El ADIS 16100, esta formado como se puede ver en la figura 1.21, por un giroscopo quepuede llegar a detectar un giro de guinada7 del MEMS en el rango de ±300o/s, por untermometro, un convertidor ADC y un modulo de SPI que sera con el que se realice lalectura 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 sobreel eje z (Ver la figura 1.22)8. Como hemos comentado anteriormente, los valores maximosque podra detectar seran de -300o/s si gira en sentido antihorario o +300o/s si gira ensentido 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

7Giro sobre el eje z8LSB (Least Significant 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.


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 caracterısticas, bloquesde diagramas, especificaciones y las tıpicas respuestas de actuacion. Para nuestro TFCnecesitaremos tener en cuenta y conocer primordialmente las caracterısticas mas esen-ciales mostradas en la tabla 1.5 (Especificaciones a Ta = 25oC, Vcc = 5 V, tasa de giro =0o/s y Cout = 0 µF).

Parametro Condici on Min Typ Max Units

Alimentacion Para Ta = -40oC a 85oC 5 VSensibilidad @25oC 3,68 4,1 4,52 LSB/o/s

Resolucion AD Input 12 bitsTiempo de conversion 16 ciclos de reloj a 20 MHz 800 ns

Null (Initial) Nominal 0o/sec output es 2048 LSB -42 +37 o/secLectura termometro Ta = 298oK 2048 LSB

Rango del termometro -40 a 85 oC

Tabla 1.5: Especificaciones mas importantes del ADIS16100.

Un punto a tener muy en cuenta es nuestra carga electrostatica. El cuerpo humano puedeacumular 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 desegundos para descargarnos y ası no cortocircuitar ningun componente.

El ADIS16100 tiene 16 pines con los que podemos configurarlo y obtener los datos nece-sarios. En la tabla 1.6 se muestra la disposicion de los pines y su funcionamiento.

Como caracterısticas 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 Vy es por ello que dentro del chip encontramos un elevador de tension para alimentarlos resonadores.

• Una vez obtenidos los datos analogicos de temperatura o de tasa de giro, estos sonmuestreados en el AD para despues transmitirlos por SPI. Para ello la senal se filtrapasando por dos etapas.

La primera de estas etapas se encuentra justo despues de la salida del girosco-po, donde hay un polo que filtra las frecuencias altas. De esta forma evitamos loscambios bruscos justo antes de la amplificacion final.

En la segunda etapa se calibra, a traves del condensador Cout, la respuesta fre-cuencial del sistema cuyo filtro paso bajo esta pre-configurado a 40 Hz. Para reducirel ancho de banda, y por consecuente la respuesta frecuencial, se ha de configurarun filtro paso bajo con la ayuda de una resistencia interna, ROUT, y de un conden-sador externo en el puerto, COUT, como se puede ver en la figura 1.21.

• El rango de medidas del ADIS16100 es configurable. Podemos incrementar el mar-gen dinamico unicamente anadiendo una resistencia externa entre los pines RATE


Pin Abreviatura Descripci on

1 DINData In del SPI. Se lee en los flancos de bajada del SCLK,

para escribir en registros de control.2 SCLK Clock para comunicaciones y conversiones3 DOUT Salida del SPI. Cambia cada flanco de bajada del SCLK4 NC Nada

5 RATESalida de datos analogicos que representa la tasa

de giro del ADIS

6 FILTRegulador de respuesta frecuencial y ancho de banda

conectando un condensador7 Vdrive Alimentacion, puede ser a +3 V o +5 V8 AIN1 Entrada analogica 19 AIN2 Entrada analogica 2

10 COM Alimentacion tierra11 Vre f Vref a 2.5 V12 ST2 Boton test 213 ST1 Boton test 114 Vcc Alimentacion15 NC Nada16 CS Chip Select del SPI

Tabla 1.6: Descripcion de los pines del ADIS16100.

y FILT. Esta resistencia cambia la impedancia del chip ya que al conectarla en esospuertos 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Ω enlos pines RATE y FILT se obtendrıa un incremento de rango de un 50%. El valormınimo que se permite conectar es de 45 KΩ.

• Las fuentes de alimentacion pueden variar el comportamiento de precision y estabi-lidad del sensor. Por ello el ADIS16100 lleva unos condensadores desacopladoresde 0,2 µF en el Vcc, por lo que en el diseno final no necesitaremos ningun tipo deimpedancia de decoupling.

• Existen unos botones el ST1 y ST2 en los pines 13 y 12 que nos ayudan a probarel correcto funcionamiento del sensor. Esto es muy importante, ya que en muchosmomentos del diseno de la placa, es util conocer en cual estado esta nuestro sensor.Las pruebas consisten en excitar los sensores electromecanicos y obtener unosvalores en el DOUT, la salida del SPI (Ver la tabla 1.7).

Pruebas Resultado en el DOUT

Pulsando ST1 -221 LSBPulsando ST2 221 LSB

Pulsando ST1 y ST2 NULL

Tabla 1.7: Tabla de pruebas del ADIS16100.


En cuanto a la comunicacion entre el ADIS16100 y un dispositivo de control (en nuestrocaso un PIC), como ya se ha dicho unas lineas mas arriba se utiliza el protocolo SPI.

Esta comunicacion cumple las mismas especificaciones que hay en el capıtulo 1.1.5., yconcretamente se trata del modo 2 o modo C (CPHA = 0 y CPOL = 1)9.

Por ello, para iniciar la transferencia de datos el CS ha de estar a nivel logico ’0’, el SCLKtendra como libre el nivel alto y los cambios de datos en los buffers se realizaran enlos flancos de bajada. El ADIS16100 por su parte incorpora unas funciones, READ yWRITE, que facilitan la comunicacion con el resto de dispositivos. Mas adelante, en elcapıtulo 2.3.2., se explica como se ha de configurar por software el PIC para realizaradecuadamente la comunicacion con este dispositivo.

Las comunicaciones entre el PIC y el ADIS, que se encuentra permanentemente a laescucha del registro de entrada de datos (DIN), se realizan a traves de comandos de 16bits. Una vez el dispositivo ha sido seleccionado a traves del CS, se inicia la comunicaciony cuando se han recibido los 16 bits, el chip lee los datos y los procesa. En funcion delcodigo recibido, realizara unas operaciones u otras, que comentaremos a continuacion.

Figura 1.23: Diagrama de secuencia de configuracion/lectura en ADIS16100.

En funcion del codigo recibido en el DIN, el ADIS simplemente contestara con un paquetede datos (datos que corresponden a una configuracion previa) o sera reconfigurado, paraque en la siguiente iteracion responda datos de la nueva configuracion.

Como nota muy importante, a la hora de esperar las respuestas del ADIS hay que de-cir que solo responde cuando se le envıa un comando, sea de lectura o configuracion, ysiempre que es reconfigurado, contestara con la nueva configuracion un comando des-pues y no en el mismo comando en el que esta siendo configurado. Con esto vemos quesera necesario un segundo comando para realizar una lectura de la nueva configuraciondespues de haber enviado un comando de configuracion (ver figura 1.23).

Como se puede ver en la tabla 1.8, se tratara de un comando de configuracion o desimple 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, siel bit 15 o WRITE es ’1’, accederemos al registro de control del ADIS16100 y podremosconfigurar su modo de trabajo. Su configuracion estara determinada por el resto de bitsque hemos enviado en ese mismo comando (ver figura 1.24, DIN).

Los datos de salida siempre siguen el mismo patron. Los dos primeros bits siempre es-

9El fabricante proporciona un manual donde se indica cual modo SPI es necesario para la comunicacioncon los dispositivos de control (Modo 2 o Modo C). En la practica este modo que proporciona el fabricantees incorrecto , y para comunicar el ADIS16100 con un PIC como el utilizado en este TFC es necesarioutilizar el modo 1 o modo B (CPHA = 0 y CPOL = 0)


Bit N o Abreviatura Funcionalidad

15 WRITE’1’: Vuelca el contenido de DIN al registro de control,

y se reconfigura el modo de trabajo del chip.’0’: No se producen cambios en el registro de control

y el ADIS16100 responde con la configuracion que dispone.14 0 Estado bajo, ’0’ para funcionamiento normal.

13, 12 D/C Don’t care, no intervienen.

11, 10 ADD1 ADD0Modo de trabajo:

00: Salida giroscopo01: Salida temperatura10: Entrada analogica 111: Entrada analogica 1

9, 8 1 Estado alto,’1’ para funcionamiento normal.7, 6 D/C Don’t care, no intervienen.5 0 Estado bajo, ’0’ para funcionamiento normal.4 CODE Formato de los datos de salida:

’0’: complemento a dos’1’: Offset binario

3 al 0 D/C Don’t care, no intervienen.

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 finalizar, los datos (Vertabla 1.9).

Siguiendo la tabla 1.8 vemos que una serie de bits siempre tendran valores constantesindependientemente de la configuracion que se precise:

• Los bits 14 y 5 deberan estar siempre a nivel bajo, ’0’ para una funcionalidad co-rrecta 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 sepodran establecer como ’1’ o ’0’; por ello a lo largo de este documento estos bits semostraran sin valor y seran representados por una ’x’. (Don’t care bits, DC).

En cambio, habra otros bits que seran los que varıen, y que estableceran el tipo de saliday el formato de los datos:


Bit N o Abreviatura Funcionalidad

15, 14 0 Siempre a ’0’.

13, 12 ADD1 ADD0Modo de trabajo:

00: Salida giroscopo01: Salida temperatura10: Entrada analogica 111: Entrada analogica 1

11-0 D11-D0 Datos.

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 configuracion y comunicacion. Para este casoel 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 ADIS16100quede configurado 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 definitiva tendremos: ’10xx0111xx01xxxx’.

• Enviamos un paquete con la secuencia de bits anterior.

• Debido al funcionamiento del ADIS16100, los datos que recibamos en esa mismaiteracion no corresponderan a lo que acabamos de configurar. Por ello, tendremosque volver a enviar otro paquete de forma que recibamos los datos de temperaturaen offset.

Los bits que enviaremos en esta iteracion, al tratarse de una lectura del chip, puedenser los mismos que los de configuracion, solo que esta vez el bit 15, WRITE, ha deser ’0’ para no entrar en el registro de control.


• Una vez realizada la lectura de temperatura, procedemos a la lectura del giroscopoen formato complemento a dos. Para llevar a cabo satisfactoriamente esta operaciondebemos volver a configurar el ADIS igual que lo hemos hecho para la temperatura,solo que esta vez la secuencia de bits sera: ’10xx0011xx00xxxx’, cambiando elmodo de trabajo y el formato de los datos de salida a giroscopo en complemento ados10.

• Al igual que para leer la temperatura despues de la configuracion, para leer losdatos de la nueva configuracion volvemos a enviar un paquete de datos cambiandoel 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 configuracion (con WRITE = ’1’) yseguidamente realizaremos la lectura deseada (con WRITE = ’0’).

Para facilitar la comprension del funcionamiento de los registros DOUT, mostraremos latabla 1.10 con ejemplos de posibles datos proporcionados por los sensores.

o /s Codigo Patr on Binario

Velocidad Angular en Complemento a Dos0,2439 1 0000000000000001

0 0 0000000000000000-0,2439 -1 0000111111111111

Velocidad Angular en Offset Binary0,2439 2049 0000100000000001

0 2048 0000100000000000-0,2439 2047 0000011111111111

Temperatura en Complemento a Dos25,1453 1 0001000000000001

25 0 000100000000000024,8547 -1 0001111111111111

Temperatura en Offset Binary25,1453 2049 0001100000000001

25 2048 000110000000000024,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, inclinacionesy temperatura de manera simultanea, a traves de unas lıneas SPI. Ademas, nos permitecalibrar de forma rapida y barata los sensores digitales que incorpora.

10En esta iteracion, los datos recibidos del chip seran los referentes a la configuracion previa, que en estecaso es la temperatura en formato offset.


Este chip incorpora una diferencia en tecnologıa respecto el anterior, el ADIS16100, yaque tiene una serie de caracterısticas que ayudan a realizar de forma mas facil el trabajosin necesidad de incluir hardware.

Algunas de las caracterısticas que lo hacen diferente son:

• Una funcion de alarma configurable.

• Un ADC de 12 bits.

• Un DAC de 12 bits.

• Puertos I/O configurables.

• Posibilidad de controlar la alimentacion y el modo Sleep a traves del SPI.

El esquema de bloques del ADIS16201 se puede ver en la figura 1.25.

Figura 1.25: Diagrama de bloques del ADIS16201.

Al igual que el ADIS16100, en el datasheet podemos encontrar todas las caracterısticasdel MEMS, pero para nuestro TFC nos interesan las de la tabla 1.11 (Especificaciones aTa = -40oC a 125oC, Vdd = 3,3 V y tilt = 0).

El ADIS16201 tiene 16 pines con los que podremos configurarlo 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 final, se ha de tener en cuenta su posicion parapoder realizar las lecturas de inclinaciones y aceleraciones de forma correcta. Teniendoen cuenta que la gravedad es negativa y queremos que este en el eje ’y’, la posicion en laque se debe colocar el MEMS debe ser la que esta mas a la izquierda en la figura 1.27 .

El funcionamiento del ADIS16201 es similar al del ADIS16100. Por medio de los puertosDIN y DOUT se hacen las transmisiones de datos, con la diferencia que en el ADIS16201


Figura 1.26: Disposicion de los pines del ADIS16201.

Figura 1.27: Posibles orientaciones del ADIS16201.


cada registro de cola del SPI DOUT tiene una direccion (un ’address’) y un formato asig-nado que conlleva a una funcion especıfica.

Para mostrar datos de salida, se requiere previamente una lectura de un comando a travesdel registro DIN. Por lo tanto, para obtener la informacion deseada se necesitan 2 ciclos de16 bits. En el primer ciclo se transmite la direccion del registro, el ’address’, para localizarel tipo de datos que nos piden. En el segundo estan los datos de lectura (Ver la figura1.28).

De este modo, en vez de ir configurando que tipo de lecturas queremos (como en el casodel ADIS16100), en el ADIS16201 cuando enviemos un ’address’ este nos respondera enla siguiente iteracion con un tipo de dato especıfico.

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) ylos ultimos 8 bits no importa que valor tengan (Ver figura 1.29).

Figura 1.29: Registros DIN/DOUT del ADIS16201.

El registro DOUT tiene 16 bits (Ver figura 1.29): El ND (new data ready) se pone a 1 cuandoalgun registro ha sido actualizado, el EA (indicador de alarma) y los bits de datos (del D0al D13). En los bits de datos se ha de destacar que para informacion de aceleracion seutilizaran los 14 bits en complemento a 2, en cambio, para el resto de informacion seutilizan 12 bits despreciando los bits D12 y D13. puede ver detalladamente cada uno delos registros de lectura de comandos.


Parametro Condici on Min Typ Max Units

Inclin ometroRango de entrada ±70 o

Sensibilidad ±70o y T=25oC 9,9 10 10,1 LSB/o

Offset a 25oC 2037 2048 2059 LSBAceler ometro

Sensibilidad a 25oC 2,140 2,162 2,184 LSB/mgOffset a 25oC y 0 g 8151 8192 8233 LSB

Respuesta frecuencial del aceler ometroBW del sensor 2250 Hz

Frecuencia de resonancia 5,5 kHzTermometro

Salida a 25oC 1278 LSBFactor de escala -2,13 LSB/oC

ADCResolucion 12 bits

Ganancia de error ±2 LSBDAC

Resolucion 12 bitsGanancia de error ±0,5 %

ConversionesMınimo tiempo de conversion 244 µsMaximo tiempo de conversion 484 ms

Tabla 1.11: Especificaciones mas importantes del ADIS16201.

Pin Abreviatura Descripci on

1 SCLK Clock para comunicaciones y conversiones2 DOUT Salida del SPI. Cambia cada flanco de bajada del SCLK

3 DINData In del SPI. Se lee en los flancos de SUBIDA del SCLK,

para escribir en registros de control.4 CS Chip Select. Activo en nivel logico bajo ’0’.

5,6 DIO0,DIO1 Pines I/O.7,11 NC No conectado8, 10 AUX COM Conexiones a tierra.

9 RST Reset, activo a nivel bajo12 AUX DAC Salida de voltaje analogico auxiliar para el DAC.13 VDD Alimentacion a +3.3 V14 AUX ADC Entrada de voltaje analogico auxiliar para el ADC15 Vre f Salida de voltaje de referencia preciso.16 COM Comun del circuito.

Tabla 1.12: Descripcion de los pines del ADIS16201.


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 sir-ve de marco de referencia que, combinada con una serie de algoritmos y mecanismos decontrol, nos permiten la establecer un sistema de guiado inercial.

Esta plataforma obtiene medidas de la aceleracion del vehıculo en los tres ejes del espaciomediante tres acelerometros embarcados sobre la plataforma inercial. Por otro lado, latasa de giro en los 3 ejes (Ver la figura 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 vehıculomediante una integracion (Ecuacion 1.1), la posicion del vehıculo con una doble integra-cion (Ecuacion 1.2), y a partir de allı la velocidad angular, la actitud y orientacion delmismo.

v =

Z

adt (1.1)

r =

ZZ

adt2 (1.2)

Debido a que la plataforma giro estabilizada no es perfecta, en los calculos se van introdu-ciendo errores acumulativos que deben ser corregidos mediante fuentes externas (comopor 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 sonmuy 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 paracalcular las aceleraciones, velocidades y posicion del vehıculo 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 gi-roestabilizada, sino fija a la estructura del vehıculo.


Si bien esto reduce la precision del dispositivo, los resultados son lo suficientemente bue-nos como para alcanzar el objetivo que se busca con este TFC (apoyar las practicas deNACC), mientras se gana en sencillez de construccion y operacion.

Metodologıa 37

CAPITULO 2. METODOLOGIA

En este capıtulo de metodologıa trataremos de mostrar que y como desarrollamos nuestroTFC, 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 nivelde aplicacion donde se ha de decidir el tipo de mensajes que habra y sus identificadores.

La distribucion del tipo de mensajes y de sus identificadores es muy importante en elbus CAN. Como ya se ha comentado, el bus CAN es un sistema basado en tipos demensajes y no en direcciones. Por lo tanto, la eficiencia y funcionalidad del bus vendrandeterminados por esta distribucion.

En nuestro sistema utilizaremos paquetes CAN en formato estandar. Eso significa que elcampo ID sera de 11 bits. Sera en este campo en el que el protocolo se fijara a la horade arbitrar el acceso al medio. Es por eso que hemos de tener cuenta la urgencia de losmensajes a la hora de asociar ID’s a los paquetes.

Los 11 bits los hemos dividido en 3 campos (Ver la figura 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’


Los comandos seran utilizados cuando se quiera obligar a los dispositivos a realizar alguncometido. Se les da la prioridad maxima para evitar que estos comandos queden rezaga-dos por otros tipos de mensaje.

En segundo lugar vendrıan los eventos. Los eventos son generados por los dispositivosen respuesta a algun acontecimiento fuera de lo normal. Es por eso que se le da una delas 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 aestos ultimos.

En el ultimo nivel pondremos los mensajes de datos. Esto no significa que los datos nosean 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, sile dieramos una prioridad mas alta podrıamos crear el efecto “starvation”, es decir, haceresperar a un mensaje de comandos (que tendrıa una prioridad mas baja) porque se estanenviando mensajes de datos (con la prioridad mas alta).

Dentro de cada tipo de mensaje tambien vamos a diferenciar las prioridades. Para elloutilizaremos el campo de ’Prioridad de mensaje’, que utiliza otros dos bits:

• Crıtica: 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 fluidez a nuestro bus. Por ejemplo, alos datos del dispositivo que sea mas propenso a enviar datos le damos una prioridad masbaja que a los del dispositivo que envıe los datos con menos asiduidad. De esta maneraconseguiremos no crear el efecto ’starvation’ explicado anteriormente.

Los 7 bits restantes podran diferenciar los diferentes mensajes que esten en el mismogrupo.

Por lo tanto, con este diseno tendremos 4 bits que agruparan los mensajes en 16 gruposposibles (24). Dentro de estos 16 grupos tendremos 128 niveles de prioridad diferentes(27). (Ver la figura 2.2).

Una vez tenemos las prioridades definidas, se ha de decidir que tipo de mensajes salien-tes y entrantes van a tener los dispositivos. En nuestro caso, la placa de adquisicion dedatos tendra los siguientes paquetes;

Como paquetes entrantes podemos tener:

• Comandos en los que se pide informacion de aceleracion en el eje ’x’ (CMND.ACCX).

Metodologıa 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’ (cabe-ceo) (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 ADIS16100numero 1 (CMND.T1).




Como paquetes salientes tendremos:

• Respuesta de aceleracion en el eje ’x’ (DATA.ACCX).


• 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 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 identificadores asociados a cada mensaje.

Una vez asociado el ID a cada paquete ya se puede crear la tabla de aceptacion (o filtro)en el nodo de comunicaciones. Esta tabla es necesaria para poder obviar los paquetesque no interesan al dispositivo. En el sistema disenado, esta tabla estara definida por losID 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 enel nodo de comunicaciones o en el propio dispositivo. Cada una de las opciones tenıa suscaracterısticas (Ver las tablas 2.3 y 2.4).

Los puntos claves son los de la independencia entre nodo y dispositivo y el no tenerque anadir un PIC al dispositivo. Este ultimo hecho es el que nos ha hecho decidir porprogramar la tabla de aceptacion en el nodo de comunicaciones. Es por eso que nosgustarıa 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 deaceptacion de mensajes.

Viendo la distribucion de los mensajes se puede llegar a la conclusion que no hace faltahacer tantas sub-divisiones de prioridades. Esto es cierto si solo se tiene en cuenta undispositivo, pero una de las finalidades de este trabajo es poderlo unir junto con otrosdispositivos, como puede ser un GPS, que anadirıan bastantes mas tipos de mensajes.

Pensando a futuro, al sistema se le podrıa unir otros dispositivos, como por ejemplo una’caja negra’ que fuera registrando los datos, unos servos para tener la posibilidad de dirigirun vehıculo, etc. Es por este motivo que se ha decidido implementar un protocolo CANcon estas sub-divisiones en el campo ID para tener un mayor rango de prioridades, y deesta forma dar mas fluidez al bus.

Metodologıa 41

Tipo de mensaje Prioridad ID Nombre del paquete

Paquetes Entrantes

Comando Alta 00010000000 CMND.ACCXComando Alta 00010000001 CMND.ACCYComando Alta 00010000010 CMND.ACCZComando Alta 00010000011 CMND.INCLXComando Alta 00010000100 CMND.INCLYComando Alta 00010000101 CMND.INCLZComando Alta 00010000110 CMND.WYComando Alta 00010000111 CMND.WZComando Alta 00010001000 CMND.T1Comando Alta 00010001001 CMND.T2Comando Alta 00010001010 CMND.T3Comando Alta 00010001011 CMND.T4

Paquetes Salientes

Respuesta Media 10100000000 DATA.ACCXRespuesta Media 10100000001 DATA.ACCYRespuesta Media 10100000010 DATA.ACCZRespuesta Media 10100000011 DATA.INCLXRespuesta Media 10100000100 DATA.INCLYRespuesta Media 10100000101 DATA.INCLZRespuesta Media 10100000110 DATA.WYRespuesta Media 10100000111 DATA.WZRespuesta Media 10100001000 DATA.T1Respuesta Media 10100001001 DATA.T2Respuesta Media 10100001010 DATA.T3Respuesta Media 10100001011 DATA.T4

Tabla 2.1: Identificadores asociados a los mensajes utilizados en la Placa de Adquisicionde Datos.

2.2. Nodo de Comunicaciones

La finalidad del Nodo de Comunicaciones es la de poder recibir informacion de dispositivosque 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 comoel software para poder cumplir con estos requisitos.


ID a aceptar en la Placa de Adquisici on de Datos

00000000000 00010000000 00010000001 00010000010 0001000001100010000100 00010000101 00010000110 00010000111 0001000100000010001001 00010001010 00010001011

Tabla 2.2: Tabla de aceptacion de mensajes de la Placa de Adquisicion de Datos.

En Nodo de Comunicaci on

Nodo y dispositivo serıan dependientes.Reprogramar el PIC si se pretende cambiar el nodo de comunicacion.

No serıa necesario un PIC complementario.

Tabla 2.3: Caracterısticas si la tabla de aceptacion esta en el Nodo de Comunicaciones.

En Dispositivo

Nodo y dispositivo serıan independientes.No serıa necesario reprogramar el PIC.

Se necesitarıa un PIC extra.

Tabla 2.4: Caracterısticas si la tabla de aceptacion esta en el Dispositivo.

Metodologıa 43

2.2.1. Hardware

2.2.1.1. Esquema electronico

El nodo de comunicaciones consta fısicamente con el hardware necesario (Ver la figura2.3) para poder establecer comunicacion en todos y cada uno de los protocolos descritosen el capitulo 1.1.

Figura 2.3: Diagrama esquematico. Nodo de Comunicaciones.

A parte del microcontrolador PIC18F4580, escogido porque tiene los 3 modulos necesa-rios (EUSART, MSSP, CAN) para implementar los 4 protocolos (SERIE, I2C, SPI, CAN),han sido necesarios un conjunto de bloques a fin de conseguir un funcionamiento optimodel dispositivo.

Estos bloques se pueden diferenciar por su funcion:

• Bloque de alimentaci on : Este bloque consta de un regulador de tension LM7805de la casa TSC y un condensador electrolıtico de 47 µF (Ver la figura 2.5).


Este condensador nos permite alimentar los componentes de nuestro circuito a dis-tancias relativamente grandes de la fuente de alimentacion. Basicamente su funciones eliminar el rizado de la senal de tension que hay en la entrada del regulador paraque la senal de salida no tenga grandes variaciones de tension debido a irregulari-dades, 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 filtro de alimentacion, pudiendo llegar a sersuperfluo. La alimentacion de entrada del regulador puede variar entre un mınimode 7.5 V y un maximo de 20 V a la entrada, consiguiendo 5 V de salida.

Es muy importante el valor mınimo de 7.5 V, ya que el regulador tiene una caıdade tension (Voltaje Drop) de 2 V y el mınimo para trabajar con el nodo son 5 V. Laconexion 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 baterıas de 12 Vconectadas directamente al nodo.

En ambos casos hay que tener muy en cuenta la polaridad con la que se conecta laalimentacion a la placa, puesto que podemos llegar a quemar el regulador 7805 deeste bloque. Siempre tendremos la tierra (GND) por la parte de fuera del conector y9 V o 12 V por la parte de dentro (Ver figura 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 ayudamosdel datasheet del PIC18F4580, donde podemos encontrar un capıtulo dedicado aconfiguraciones 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 noes excesivo.

La frecuencia del oscilador escogido es de 20MHz, que es el maximo que admite elPIC en el modo de alta velocidad, HS (High Speed). (Ver tabla 1.1).

Ademas del cristal de cuarzo son necesarios unos condensadores y una resistenciapara incrementar la estabilidad del oscilador (Ver la figura 2.6 ). Los valores de latabla 1.1 son orientativos. Si se utilizan unos condensadores de mayor capacidad

Metodologıa 45

ganaremos estabilidad, pero se incrementara el tiempo de inicio del reloj. En nuestronodo de comunicaciones hemos utilizados los valores indicados en la tabla.

Figura 2.6: Bloque del clock del Nodo de Comunicaciones.

• Bloque de programaci on : Para programar el PIC se ha utilizado una unidad deprogramacion y debug llamada ICD (Ver apartado 2.2.2.1.) de la casa CCS. Paraconectar este dispositivo es necesario un conector RJ12 (Ver la figura 2.7).

Figura 2.7: Conector RJ12.

Establecida la conexion entre las puertas digitales RB7, RB6, RB5 del PIC y elconector RJ12, tal y como se indica en el esquema de la figura 2.8, disenamosun boton de Reset para reiniciar el nodo en caso de cualquier problema. Esto esposible conectando un pulsador al pin MCLR.

Ademas, en esta figura se pueden observar una serie de resistencias. Estas resis-tencias son muy necesarias ya que evitan que al desconectar el ICD (desconec-tar una impedancia del circuito), las entradas digitales lean informacion incorrectavariando entre el ’0’ y el ’1’ logicos, provocando que las interrupciones que corres-ponden a las puertas digitales RB sean invocadas y creando a su vez un mal fun-cionamiento del software. Estas resistencias deben de ser del orden de 1 k - 10kΩ.

Las resistencias conectadas a RB5 y RB6 son diferentes a la conectada en RB7ya que en estos pines (RB5 y RB6) tambien se conectan unos interruptores paraseleccionar el protocolo a utilizar.

Estos interruptores para seleccionar el protocolo tienen asociadas unas resistenciasque se encuentran conectadas en paralelo con las resistencias de los pines RB5 yRB6 (ver mas abajo en figura 2.9). Estas ultimas hacen variar el nivel de tension ala entrada de los pines RB5 y RB6 de forma incorrecta. Debido a esto es necesarioque el valor de las resistencias de RB6 y RB5 sea mayor que en las resistenciasde los interruptores. De esta forma podemos asegurar una lectura correcta de losniveles de tension en las entradas del PIC.


Figura 2.8: Bloque de programacion del Nodo de Comunicaciones.

• Bloque de comunicaciones y selecci on de protocolo : El bloque de comunicacio-nes 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 lafigura 2.9).

Los transceivers utilizados son los siguientes:

– El MAX232, utilizado para los comunicaciones RS232, es un chip dual formadopor unos drivers (transmisores), unos receivers (receptores) y un generador devoltaje capacitivo para subir de los 0 V - 5 V que transmite el PIC a los ±12 Vdel estandar EIA-2321.

En total el MAX232 dispone de 4 conversores de niveles TTL/CMOS al busestandar RS232 y viceversa. De estos 4 conversores solo utilizaremos 2, unoCMOS⇒RS232 y otro RS232⇒CMOS. Cada receiver convierte las entradasEIA-232 a niveles de 5 V TTL/CMOS, y cada driver convierte las entradasTTL/CMOS a niveles EIA-232.

De forma resumida el MAX232 es un chip que adapta senales electricas (capafısica en los niveles OSI). Su tıpica configuracion (extraıda del datasheet) es laque utilizaremos en el nodo de comunicaciones y es la mostrada en la figura2.10.

En nuestro caso solo utilizaremos un unico canal de comunicacion, por lo queno utilizaremos los pines T1OUT, T1IN, R1IN y R1OUT correspondientes a 2conversores. Los pines R2OUT y T2IN, que corresponden a los niveles CMOSde 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 unconector DB9 hembra2 al cable NULL MODEM que ira al dispositivo final. Elfuncionamiento del cable NULL MODEM se explica mas adelante.

1EIA Electronic Industries Alliance. Al Estandar RS-232 tambien se le puede llamar EIA-232 ya queRS232 fue una propuesta de esta asociacion de empresas.

2Es un conector hembra y no macho porque con este ultimo se produce un ’efecto espejo’ en las cone-xiones (Ver figura 1.11).

Metodologıa 47

Figura 2.9: Bloque de comunicaciones del Nodo de Comunicaciones.

– El PCA82C251 es una interfaz entre el controlador del protocolo CAN quese encuentra en el PIC, y el Bus CAN fısico. Este chip esta formado por unreceiver y un driver que nos convertira las senales que entren por el CANH yCANL a CMOS para tener una lectura correcta de los datos en el PIC (adaptaniveles). Su configuracion de pines se muestra en la figura 2.11.

A parte del PCA82C251 existen otras alternativas en el mercado. En nuestrocaso hemos utilizado este chip porque se ajusta a nuestros criterios de diseno,pero en funcion de estos tambien podemos encontrar otros transceivers (vertabla 2.5).

– En cuanto a SPI e I2C, estos protocolos no necesitan ninguna adaptacion ensus niveles de senal como lo requerıan CAN y RS232, de forma que podemosconectar los dispositivos directamente al PIC. El unico concepto que hay quetener claro es que para el correcto funcionamiento de I2C son necesarias 2resistencias de carga (definidas en el capıtulo 1.1.4.1.) mientras que para SPIestas resistencias provocan un mal funcionamiento del bus.

Debido a que ambos protocolos comparten pines en el PIC, se han disenadounos interruptores que nos permitiran usar las resistencias PULL-UP cuandoestemos trabajando en I2C, y desactivarlas cuando estemos trabajando conSPI. Esta sistema, desarrollado por nosotros, se puede ver en la figura 2.12.

– La conexion a otros dispositivos desde el nodo de comunicaciones se reali-


Figura 2.10: Configuracion MAX232.

Sımbolo Pin Descripci on

TXD 1 Transmision de los datos recibidosGND 2 TierraVCC 3 AlimentacionRXD 4 Salida de los datos recibidosVREF 5 Salida de tension de referenciaCANL 6 Nivel bajo CAN IN/OUTCANH 7 Nivel alto CAN IN/OUT

RS 8 Entrada resistencia Slope

Figura 2.11: Pines del PCA82C251.

zara mediante un User Terminal para los protocolos SPI, I2C y CAN, y me-diante un cable NULL MODEM conectado al DB9 del nodo para el RS232 (Verla figura 2.13).

A continuacion describimos como conectar dos nodos de comunicacion o unnodo y un dispositivo:

En el bus CAN la conexion consiste en unir los dos terminales de CANH y deCANL entre sı (CANH-CANH, CANL-CANL y GND-GND)3.

Por otro lado, para el protocolo I2C la conexion sera SDA-SDA, SCLK-SCLKy 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 podrıa haber sido utilizar uncable 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

3Cuando 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 finalidadde estas resistencias es evitar que los datos transmitidos sean devueltos en forma de eco de los extremosde los cables y que se falsifiquen los datos.

4Es muy importante conectar las tierras entre los dispositivos para evitar problemas de masa flotante enla alimentacion

Metodologıa 49

Transceivers

Fabricante Modelo No Nodos Velocidad tolerancia

PhilipsPCA1 110 1mega NOPCA2 15 125k SI

TJA1054 32 125k SI Low EMC

MaximMAX3058 32 1mega NOMAX3050 32 2mega NOMAX3054 32 250k SI

TiSN65LBC031 500k NOSN65HVD251 120 1mega NOSN65HVD232 120 1mega NO 3.3v

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.


Transmision (TX) del dispositivo 1 debe ir conectado al de recepcion (RX) deldispositivo 2. La diferencia entre utilizar o no un cable NULL MODEM es ellugar donde el pin TX se conecta a RX. En un cable NULL MODEM este crucese hace en el cable, mientras que en un cable serial directo el cruce se haceen el dispositivo (Ver la figura 2.14).

Figura 2.14: Cable NULL-MODEM - Cable directo.

– Finalizando este bloque de comunicaciones, se han conectado 3 interruptoresa las puertas digitales del PIC (RB4, RB5 y RB6) para seleccionar por softwareel protocolo del dispositivo con el que estamos trabajando. Estos interruptoresse pueden ver en la figura 2.3 con el nombre de: INT RS232, INT I2C, INT SPI.En la tabla 2.6 se pueden ver las diferentes configuraciones.

``

``

``

``

``

``

``

ProtocoloInterruptor

INT RS232 INT I2C INT SPI

RS232 1 0 0I2C 0 1 0SPI 0 0 1

Tabla 2.6: Configuracion interruptores de seleccion de protocolos.

Si dos interruptores se ponen en ’ON’, se seleccionara el protocolo pertene-ciente al primer interruptor modificado. Para evitar problemas, es recomenda-ble solo tener un interruptor activado a la vez.

Para poder reconocer visualmente en que protocolo estamos trabajando, he-mos implementado 3 LED’s de colores diferentes. Por cada una de las 3 con-figuraciones se encendera un LED diferente.

Como se ha explicado en el bloque de programacion, las resistencias de losinterruptores que son conectadas en paralelo con los pines RB5 y RB6 han deser de menor valor para no dar lecturas de tension incorrectas, mientras que laresistencia del interruptor RS232 (RB4) no necesita valores concretos ya queen este pin el ICD no esta conectado y no se producen efectos de impedanciasen paralelo.

Metodologıa 51

2.2.1.2. PCB

Una vez desarrollados y probados los bloques que forman el nodo de comunicaciones, ydespues de haber experimentado con el dispositivo sobre un protoboard, pudimos decirque habıamos llegado a una configuracion estable. Con este diseno final se ha elaboradoun circuito integrado que nos permite trabajar de forma continua y estable en un unicomodelo de circuito.

Para realizar el circuito integrado definitivo nos ayudamos del software que utilizan losservicios tecnicos de la EPSC. El software utilizado es el P-CAD 2002. De esta formaevitamos incompatibilidades en los formatos de ficheros, ya que ellos nos realizan lasplacas con las pistas del circuito.

Utilizamos este programa con la finalidad de realizar el PCB. El PCB es un medio parasostener mecanicamente y conectar electricamente componentes electronicos, a travesde rutas o pistas de material conductor, grabados desde hojas de cobre laminadas sobreun sustrato no conductor.

Como se puede ver en la figura 2.15, se utilizo tanto la capa TOP, donde tenemos lamayorıa de conexiones, como la capa BOTTOM5, que es donde tenemos GND y algunasconexiones que no era posible enrutar por la capa TOP. Para enrutar a traves de las doscapas se han utilizado VIAS, que son agujeros metalizados que atraviesan la placa deuna superficie a otra, creando un puente entre ellas.

Debido a que gran parte de los componentes utilizados en el circuito no existıan en laslibrerıas del programa, como por ejemplo el conector del ICD, utilizamos otro software (elPatern Editor, que esta incluido en el paquete de P-CAD2002) para crear los patrones delos componentes que no tenıamos, creando ası una librerıa especial para nuestro nodode comunicaciones. Estos componentes estan adjuntados en el archivo del PCB que seencuentra 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 decomunicaciones.

Primero se hara una pequena introduccion al entorno de programacion utilizado. Segui-damente, y ayudandonos con un diagrama de flujo, se explicara paso a paso el codigoimplementado en los PIC.

2.2.2.1. Entorno de programacion

Como se comentaba en el capıtulo 1.1.1., para que el PIC pueda realizar sus funcionesprimero se ha de programar. Para programar el PIC se necesitan una serie pasos y ele-mentos:

5En el anexo C se pueden ver por separado cada una de las capas de todos los circuitos de este trabajo


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 mayorıa de los casos es el C o el Ensamblador. Ennuestro TFC hemos utilizado C ya que disponıamos de librerıas que nos facilitabanel trabajo, y ademas por su facilidad a la hora de utilizarlo.

• Compilador que traduzca el fichero escrito en C a codigo maquina. En nuestro casohemos 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ı unarchivo en formato hexadecimal (.HEX).

Este compilador se integra en un entorno de desarrollo integrado (IDE) que nospermite desarrollar todos y cada uno de estos pasos, desde la edicion hasta lacompilacion pasando por la depuracion de errores.

• El ultimo paso es el de la programacion. Una forma de programar el PIC es conun programador externo. Este no serıa un metodo muy eficaz ya que cada vezque quisieramos programarlo, tendrıamos que quitar el PIC de nuestro circuito paraponerlo en el programador externo. Para remediar esto utilizamos una unidad deprogramacion y debug, que tambien nos proporciona CCS Inc., llamada ICD (Ver lafigura 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

Metodologıa 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 quierehacer 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 ficheros posibles, y finalmentese crearan unos diagramas de flujo que nos serviran para representar visualmente la se-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 muyimportantes: Los tipos de dispositivos a los que nos ibamos a conectar y la forma deoptimizar 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 diferen-ciado 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 explıcitamente.

• 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 anterior-mente.

Debido a estos tres diferentes tipos de dispositivos, se han implementado dos funcionesespeciales (estas funciones se encuentran en el archivo ’funciones.c’);


• 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 enviarinformacion sobre el ID del mensaje que se transmitira por CAN, y es por eso quenecesitamos 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 tipoComando), y el ID del mensaje saliente (paquete tipo Respuesta).

• mensaje a responder : Gracias a esta funcion sabremos si un paquete necesitauna respuesta o no fijandonos 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 funcionesde las interrupciones.

La idea basica de las interrupciones es la de quitar carga de trabajo al procesador para quepueda realizar otros procesos. Si no se implementaran estas interrupciones se tendrıa queestar preguntando en todo momento al procesador por algun dato en concreto. De estamanera se deja libre al procesador, y solo cuando se produce la circunstancia por la queha sido programada la interrupcion se toma el control de este. Las cuatro interrupcionesutilizadas son las siguientes:

• INT RB: Esta interrupcion se utiliza para el manejo de los interruptores. Su funciones la de configurar las variables internas que utilizamos para seleccionar el proto-colo para enviar o recibir datos. Esta interrupcion salta cuando en cualquiera de lospines RB4, RB5, RB6 y RB7 hay un cambio de nivel.

• INT CANRX0: La funcion de esta interrupcion es detectar paquetes CAN dentro delbus, y pasar la informacion necesaria al dispositivo al que este conectado medianteel protocolo seleccionado (Ver la figura 2.17). Se activa siempre que se recibe unpaquete CAN.

Figura 2.17: Esquema flujo de datos en INT CANRX0.

Debido a la continua llegada de paquetes CAN, en esta interrupcion solamen teserecibe el paquete. El posterior procesado de la informacion se activa mediante unboleano en la rutina ’main’ del programa. De esta forma se podran recibir todos lospaquetes CAN.

• INT SSP: La funcion de esta interrupcion es detectar senal por el pin 23 en elPIC18F4580 o el 15 en el PIC18F2580 (recepcion I2C y SPI), e ir guardando esainformacion en un vector de 8 posiciones (8 bytes es el maximo que se puede anadir

Metodologıa 55

en un paquete CAN) hasta que se llene este vector o hasta que llegue una condicionde final de transmision (Ver la figura 2.18).

En estos casos, se enviara el paquete CAN con el ID recibido y con el paquete deinformacion.

Figura 2.18: Esquema flujo de datos en INT SSP.

• INT RDA: La funcion de esta interrupcion es detectar senal por el pin 26 en elPIC18F4580 o el 18 en el PIC18F2580 (recepcion de datos RS232)(Ver la figura2.19).

Al igual que con la interrupcion INT SSP, los datos se van guardando en un vector de8 posiciones hasta que llegue una condicion de final de comunicacion o el paquetese llene.

Figura 2.19: Esquema flujo de datos en INT RDA.

Otro punto a tener en cuenta antes de ponerse a programar es tener clara la distribuciondel codigo. Nunca se ha de programar todo el codigo de golpe y en un solo fichero, sinoque se ha de hacer con una cierta jerarquıa (Ver la figura 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 configuran los 4 protocolos a utilizar, donde se declaran las variablesglobales, etc. Mas adelante se explica detalladamente el codigo de este fichero.

• ’funciones.c’ : En este fichero es donde se encuentran las funciones con las que elusuario podra modificar 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 esteultimo.

En resumen, cuando se quiera cambiar de dispositivo, este sera el unico ficheroque se tendra que modificar (junto con su librerıa ’funciones.h’). Las funciones sonla siguientes:


Figura 2.20: Jerarquıa de los ficheros utilizados en Nodo de Comunicaciones.

– ’seleccion mensaje(id)’ : Con esta funcion podremos saber si un paquete espara este nodo o no.

– ’id entrante id salida(id)’ : Con esta funcion sabremos cual es el id de salidadependiendo del id de entrada. Por lo tanto, solo utilizaremos esta funcion endispositivos del tipo 2 o 3.

– ’mensaje a responder(id)’ : Con esta funcion sabremos si el paquete recibidonecesita respuesta o no.

– ’imprimir id()’ : Con esta funcion se habilitara o deshabilitara el envıo de los IDpor el protocolo seleccionado.

– ’condicionfinal()’ : En esta funcion se indica cual es la condicion de final detransmision del dispositivo al que se conecta el Nodo de Comunicaciones.

– ’id valido()’ : En esta funcion se indica si el ID que envıa el dispositivo es un IDvalido 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 final can(id)’ : Con esta funcion sabremos cual es la condicion definal de los datos que nos llegan por CAN, gracias al ID con los que llegan lospaquetes.

Esta funcion es necesaria porque cada dispositivo puede tener unas condicio-nes de final de datos diferentes, y por lo tanto el nodo receptor ha de sabercual es esa condicion de final de datos en cada caso.

• ’funciones.h’ : En esta librerıa 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 delcodigo de ’tfc.c’.

• ’can-18f4580.h’ : En esta librerıa se declaran las estructuras, variables y funcionesutilizadas en ’can-18f4580.c’.

Metodologıa 57

• ’18f4580.h’ : En esta librerıa se definen todas las constantes associadas al PIC18F4580.

Para el correcto seguimiento del codigo implementado en el nodo de comunicacioneshemos considerado oportuno realizar un diagrama de flujo (Ver Anexo B).

El diagrama de flujo lo hemos utilizado para representar visualmente la secuencia de datosy procesos a lo largo de nuestro programa. Es un proceso que se ha de hacer siempreantes de ponerse a programar el codigo para facilitar la comunicacion entre los diferentesprogramadores y la comprension de problemas largos y complicados. Una vez que sedibuja el diagrama de flujo, llega a ser facil escribir el programa en cualquier idioma dealto nivel.

Por ultimo, el diagrama de flujo tambien nos ayudara a explicar el programa a otras perso-nas.

Vamos a dividir este diagrama de flujo en varios modulos para explicar el codigo imple-mentado (Para ver el codigo ir a Anexo A):

• Modulo ’Configuraci on Nodo de Comunicaciones’ : El primer paso a realizar esel de la inicializacion del PIC. Es aquı donde configuramos todos los parametrosnecesarios para el correcto funcionamiento del PIC. En este punto se utilizan direc-tivas, que son comandos especıficos precedidos por un ’#’ y que permiten que elcompilador acepte o ignore los datos siguientes.

Primero anadimos las librerıas del PIC (18F4580.h), la librerıa del CAN (can-18F4580.c)y la librerıa ’funciones.c’. En la primera librerıa encontramos todas las definicionesde constantes utilizadas dentro del PIC. En la librerıa del CAN estan las funcionesbasicas del protocolo (recibir paquete, enviar paquete, etc).

Seguidamente, y ayudados con la directiva #fuses, declaramos las opciones a ac-tivarse en el PIC cuando se programe. En nuestro caso hemos activado HS (HighSpeed 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 configuramos con la directiva #use delay(clock = frecuencia). En nuestrocaso lo configuramos con una frecuencia de oscilacion de 20 MHz.

De esta forma indicamos al compilador la frecuencia del procesador, en ciclos porsegundo, 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 utilizarana lo largo del programa. Un ejemplo de estas variables son los contadores, variablesbooleanas para indicar con cual protocolo estamos trabajando o con que tipo dedispositivo nos comunicamos, los pines de los LED’s, etc.

El siguiente paso a realizar es el del Reset de las comunicaciones. Este pasoesta pensado para que cuando un nodo de comunicaciones se resetee, envıe unmensaje advirtiendo a todos los nodos que los proximos datos que transmita serandatos de inicio y no la continuacion de datos de la transmision anterior.

Para conseguir esta finalidad nos ayudamos de la funcion can putd() (explicada masadelante en este mismo capıtulo) con la que enviaremos un paquete con el caracter’\r’ y con el ID ’00000000000’.


Este caracter estara asociado al ID=0 en la funcion ’condicion final can(id)’, y por lotanto, todos los nodos al recibir este paquete inicializaran todas sus variables parapoder iniciar una nueva recepcion de datos.

Gracias a esta funcion, cada dispositivo puede enviar su propia condicion de finalde 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-CAN-PC (o dos PC). Pero si de cara a un futuro se quisiera ampliar el numero de dis-positivos, este sistema de reset se tendrıa que mejorar. Serıa necesario disenar unmetodo 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 interferirıacon otra posibles comunicaciones dentro del bus CAN.

A continuacion, se pretende inicializar los protocolos RS232, CAN y I2C. En estepunto no se inicializa el protocolo SPI ya que el I2C utiliza los mismos pines, y porlo tanto al configurar uno se desconfigura el otro protocolo.

Haciendo pruebas nos dimos cuenta que era la inicializacion del SPI la que descon-figuraba la del I2C (y no al reves). Es por ese motivo que el protocolo SPI solo seinicializa en el momento que se activa su interruptor.

Para poder configurar RS232, es importante tener en cuenta que antes de defi-nir el puerto serie se ha tenido que definir el reloj utilizado. Con la directiva #useRS232(BAUD=baudios, XMIT=pin, RCV=pin) se le dice al compilador la velocidaden baudios y los pines utilizados para la I/O serie. Ademas, tambien se habilitaranlas funciones getc(), putc() y printf(). En nuestro caso pondremos un BAUD de 4800y la configuracion sera la 8N1 (que es la Default Configuration).

Para configurar 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 #usei2c.

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 lacomunicacion. Cuando queramos que el dispositivo se comporte como receptor dedatos, tendremos que utilizar esta directiva como Slave (mas adelante ocurre estecaso). Con esta configuracion, la velocidad del protocolo es de 400 kbps.

En la inicializacion del bus CAN utilizamos la funcion can init(), definida en la librerıaCAN antes mencionada. Esta funcion inicializa el modulo CAN a 125 kbaudios yse limpian todos los filtros y mascaras para que todos los mensajes puedan serrecibidos con cualquier identificador.

Seguidamente se activan las interrupciones. Una interrupcion puede estar imple-mentada, pero si no se habilita nunca llegara a saltar. Utilizamos las funcionesenable interrupts(level) para habilitar la interrupcion del nivel dado en ’level’. El levelGLOBAL 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 condicionfinal() e id valido. En la primera funcion seindicara cual es la condicion de final 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

Metodologıa 59

indicara mediante un booleano si el ID que envıa el dispositivo es valido o no. Eneste caso, tambien guardaremos el booleano en una variable global.

Una vez realizados estos pasos, se entra en un punto de espera. Se saldra de estepunto cuando salte alguna interrupcion o cuando se habilite la opcion de enviar losdatos recibidos por CAN. Una vez finalizadas las interrupciones o el envio de estosdatos recibidos por CAN, se volvera al estado de espera.

Hemos anadido una condicion de Reset (Reset de alimentacion y no reset de co-municaciones). Con este reset volvemos al inicio del diagrama de flujo.

En la figura 2.21 se puede ver el diagrama de flujo de este modulo.

Figura 2.21: Diagrama de flujo del modulo ’Configuracion Nodo de Comunicaciones’.

• Modulo ’Interrupci on Interruptores’ : En un primer paso miramos el nivel que tie-nen los tres pines digitales (RB4, RB5 y RB6). Dentro de la interrupcion tenemos 3filtros que detectan cual de los tres pines es el que ha cambiado su valor. Depen-diendo de cual haya sido, modificaremos las variables correspondientes.

Para poder crear un reconocimiento visual, hemos instalado 3 LED’s 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 filtros activaremos elLED correspondiente.

Una vez hemos modificado las variables y hemos encendido el LED correspondien-te, 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


comunicacion nueva. Es por este motivo que se ha anadido este reset de comuni-caciones.

Como ya se comento anteriormente, el protocolo SPI se inicializa en este punto. Porello, cuando se accione el interruptor de SPI se inicializara el protocolo mediante lafuncion setup spi(), en la que indicaremos el modo de trabajo (master o slave), laforma de enviar los datos (SPI L TO H o SPI H TO L) y la frecuencia a la que seenviaran los datos (DEFAULT, SPI CLK DIV 16 o SPI CLK DIV 4).

Inicialmente configuraremos al dispositivo como SLAVE. De esta forma, cuandoqueramos transmitir por SPI tendremos que volver a utilizar esta funcion confi-gurandolo como MASTER. Las otras dos variables dependeran del dispositivo conel que se tenga que comunicar (el unico requisito es que tanto en el Slave como enel Master han de estar configuradas de la misma forma). La velocidad que hemosconfigurado es la correspondiente a SPI CLK DIV 16 (1,25 Mbps).


Figura 2.22: Diagrama de flujo del modulo ’Interrupcion Interruptores’.

• Modulo ’Interrupci on CAN’ : En esta interrupcion solo recibiremos el paquete CAN,y el procesado de los datos se realizara en la funcion ’main()’ del programa. Elprocesado de los datos se podrıa hacer en la propia interrupcion pero como lallegada de paquetes al Nodo puede ser bastante rapida, hemos preferido liberar

Metodologıa 61

de carga de trabajo a la interrupcion. De esta forma, si mientras se procesan losdatos llega otro paquete, este podra ser atendido por la interrupcion. Con la funcioncan getd() se obtiene el ID, la informacion y el numero de bytes que se han enviado.


Figura 2.23: Diagrama de flujo del modulo ’Interrupcion CAN’.

• Modulo ’Procesado de Datos CAN’ : Una vez obtenidos los datos del paquete CANen la interrupcion CAN, lo primero que se debe hacer es saber si este paquete espara nosotros o no.

Cada nodo tendra que filtrar los paquetes que le lleguen segun el dispositivo al queeste conectado. Por lo tanto, se crea una dependencia entre nodo de comunica-ciones y dispositivo. Si el nodo se quisiera unir a otro dispositivo, se tendrıa queprogramar con los filtros correspondientes a ese dispositivo.

El filtro esta implementado mediante la funcion seleccio1n mensaje(ID). Es en estafuncion donde se guardan los identificadores a aceptar en un vector (cuando sequiera modificar la tabla de aceptacion de mensajes se modificara este vector). Siel ID esta dentro del vector, devuelve un TRUE y si no ha sido encontrado devuelveun FALSE. Dependiendo de este resultado se seguiran procesando los datos (si esTRUE) o se finalizara 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 final can(id)’, y con ella podremos saber la condicion final de los datos enfuncion del ID recibido.

El segundo parametro lo obtendremos de la funcion ’mensaje a responder()’, con laque podremos saber si el paquete recibido es del tipo ’Comando’ o del tipo ’Datos’.Si el paquete es del tipo ’Comando’, se configuran las variables adecuadas paraque los datos provenientes del dispositivo se cojan como datos y no como ID’s.

El tercer parametro lo obtendremos de la funcion ’imprimir id()’, con la que sabre-mos 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 losdatos por el protocolo seleccionado. Este envıo de datos vendra determinado por elresultado de las 4 funciones anteriores. Por ejemplo, si ’imprimir id()’ devuelve unFALSE, no se imprimira el ID.


En la recepcion del ID lo primero que se hace es separarlo en dos bytes. Esto esnecesario porque este identificador es de 11 bits y por lo tanto lo tendremos queguardar 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 8bits siguientes (desplazamos el ID 3 posiciones hacia la derecha y lo igualamos alsegundo 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 valorde los primeros 8 bits (10101010 = 170) (Ver la figura 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 recibidoes 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 final de comunicacionque es el ’\r’). Si no estamos en ese caso, se envıan los dos bytes con el ID porel protocolo seleccionado (el envıo de datos en cada protocolo se explica en lasinterrupciones dedicadas a cada uno de ellos).

Una vez se han enviado los ID, se han de enviar los datos (incluida la condicionde final 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 variablesnecesarias cuando se reciba la condicion de final de datos. Sabremos cual es estacondicion porque en la funcion ’main()’ se llamo a la funcion ’condicion final can(id)’y se guardo en una variable global.

Las formas de enviar los datos son diferentes segun con el protocolo con el queestamos trabajando:

– En RS232 para enviar los datos es suficiente con la funcion printf().

– En I2C lo primero es enviar la condicion de ’start’, lo que se logra con la funcioni2c start(). Seguidamente se ha de enviar la direccion del dispositivo con el quese 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 dehaber enviado la direccion del dispositivo, se pueden enviar todos los datosque se quiera tambien con la funcion i2c write(datos). Para finalizar 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 he-mos de explicar que a diferencia del I2C, cuando transmitimos en SPI salta lainterrupcion INT SSP.

Por lo tanto, antes de enviar los datos hemos de deshabilitar dicha interrupcioncon la funcion disable interrupt(INT SSP). Esto implica que no se podrıa tener

Metodologıa 63

una comunicacion full-duplex, pero para el funcionamiento de nuestro nodo decomunicaciones (en el que solo se envıa o solo se recibe en SPI en un instantedado), esto no es uno es una restriccion importante.

Una vez deshabilitada la interrupcion, hemos de configurar el PIC para quetrabaje en modo Master con la funcion setup spi(). Es en este punto cuandoya se puedeN enviar los datos con la funcion spi write(dato).

Una vez finalizada la transmision de datos volvemos a configurar el PIC enmodo Esclavo. Un ultimo paso es limpiar la interrupcion (creada al transmitirlos datos) con la funcion clear interrupt(INT SSP), y volverla a habilitar conenable interrupts(INT SSP).


Figura 2.25: Diagrama de flujo del modulo ’Procesado de Datos CAN’.

• Modulo ’Interrupci on I2C y SPI’ : La primera accion a realizar es la del filtro se-leccionador de protocolo. Nos tenemos que fijar en las variables indicadoras de


protocolos para determinar donde tenemos que entrar. Al ser una interrupcion com-partida para I2C y SPI se ha de hacer esta especie de filtro al principio.

En los dos protocolos lo primero que hacemos es mirar con que tipo de dispositivoestamos comunicandonos. Si la variable ’transmitir sin preguntar’ esta a TRUE, eldispositivo es del tipo 1, mientras que si la variable esta a FALSE, el dispositivo esdel tipo 2 (los dispositivos del tipo 3, seran tratados como tipo 1 o 2 segun el caso).

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 de11 bits, hemos de volver a juntar los dos bytes con informacion del ID.

Para conseguirlo, al primer byte lo multiplicamos por 8 para anadirle 0’s logicos alfinal. Al segundo byte se le aplica una mascara que nos permite fijarnos solo en los3 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 sumarseloal otro resultado obtendremos el ID = ’10101010100’ = 1364.

Si a la hora de recibir el primer o el segundo byte se recibe una condicion de finalde transmision6, se reconfiguraran las variables para que en la siguiente entrada sevuelva a coger la informacion como si fuera el primer byte que le llega. Es a partirdel 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 envıaes invalido no tendremos que coger los primeros bytes como si fueran ID sino comosi fueran datos (de ahı la importancia de la funcion ’id valido()’. Es por este motivoque cuando se observa el valor de la variable ’transmitir sin preguntar’, tambien nostengamos que fijar en el de la variable ’idvalido’. El ID lo podremos obtener con lafuncion ’set id valido()’).

En dispositivos del tipo 2, todos los bytes recibidos son tratados como si fueranDatos 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 byterecibido es una condicion de final de comunicacion, se envıa un paquete CAN conlos datos almacenados hasta el momento en el vector de 8 posiciones. Si el byterecibido no es una condicion de final de datos, este byte es almacenado en el vectorde 8 posiciones.

En el momento que el vector este completo, se envıa 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 dosprimeros 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 dehaber 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

6Esta condicion de final de datos la tendremos guardada en una variable global que habra sido modifi-cada por la funcion ’condicionfinal()’ en la funcion ’main()’ del programa.

Metodologıa 65

maximo prioridad que es la 3. En el campo ’Extended’ se indica si se va a utilizar elformato estandar o el extendido. Como nuestros ID son de 11 bits en este campoponemos TRUE para indicar que estamos con el formato estandar. Por ultimo, en elcampo ’RTR’ se indica si el paquete es una trama de datos o una trama remota. Ennuestro 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 mismacon la que envıe los datos el nodo de comunicaciones) para poder recibir correcta-mente la informacion. Con la funcion i2c poll() podremos detectar cuando un byteha llegado en el buffer de transmision. Seguidamente con la funcion i2c read() ob-tenemos el valor recibido. Al final de la interrupcion hemos de volver a declarar ladirectiva #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 hemosde volverlo a declarar. La funcion utilizada para detectar la recepcion del byte esspi data is in(). Seguidamente con la funcion spi read() se podra obtener el valor.


Figura 2.26: Diagrama de flujo del modulo ’Interrupcion I2C y SPI’.

• Modulo ’Interrupci on 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 lahora de obtener los datos se realiza con la funcion getc().



Figura 2.27: Diagrama de flujo del modulo ’Interrupcion RS232’.

2.3. Placa de Adquisici on de Datos

La finalidad de la ’Placa de Adquisicion de Datos’ es la de poder integrar 2 ADIS16100 y2 ADIS16201 para que proporcionen informacion sobre velocidad angular en el eje ’z’ y eleje ’y’, ası como aceleracion e inclinacion en los 3 ejes.

Para llegar a este cometido se utiliza el PIC18F2580 comentado en capıtulos anteriores.Este PIC extra se necesita para poder controlar los 4 sensores y, una vez recibidos losdatos, poder enviar el comando NMEA 7 correspondiente. Utilizaremos el protocolo SPIpara comunicarnos con los sensores ADIS y el protocolo RS232 para comunicarnos conel Nodo de Comunicaciones.

En los siguientes apartados se describe detalladamente como ha sido el diseno tanto delsoftware como del hardware.

7El protocolo NMEA es una especificacion combinada electrica y de datos entre aparatos electronicosmarinos, y tambien mas generalmente, para receptores GPS.

Metodologıa 67

2.3.1. Hardware

2.3.1.1. Esquema electronico

Como se puede apreciar en la figura 2.28, esta placa esta formada por unos sensores dela companıa Analog Devices ADIS16100 y ADIS16201, y todo el hardware necesario paraprocesar 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.), ycon 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 haranreferencias a figuras y tablas anteriores. Algunas explicaciones teoricas seran omitidaspuesto 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 alimentaci on 5 V y 3,3 V : En esta placa, el bloque de alimentacionesta dividido en dos secciones.


La primera seccion, al igual que en el nodo de comunicaciones, esta compuesta porun condensador electrolıtico de 47 µF y un regulador LM7805, que se encargara dealimentar todo el dispositivo a 5 V incluyendo los sensores, excepto los ADIS16201que se alimentan a 3,3 V. Como fuente de alimentacion a la entrada del reguladorde tension utilizaremos unas baterıas de 12 V o 9 V, o bien un transformador de 220V a 9 V como hacıamos en el nodo de comunicaciones.

Al igual que para el nodo de comunicaciones, tendremos que ir con mucho cuidadocon la polarizacion de alimentacion, puesto que si se conecta al contrario de lafigura 2.4, la placa no funcionara y podemos quemar los componentes.

La segunda seccion del bloque de alimentacion esta compuesta por otro reguladorde tension, concretamente el M1117t-3,3/NOPB, que a partir de los 5 V de entradaprocedentes del anterior regulador obtiene los 3,3 V necesarios para alimentar losADIS16201. A diferencia del bloque anterior en este regulador no es necesario uncondensador 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 hacerlaestable. No obstante, si sera necesario un condensador de 10 µF (como mınimo)conectado al Vout del M1117t-3,3 para no llevar a inestabilidad el regulador (verfigura 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 elPIC18F2580 (placa de adquisicion de datos) son de la misma familia, las configura-ciones del clock para ambos PIC’s son exactamente iguales. Ası pues trabajaremoscon un oscilador de 20 MHz XT (cristal de cuarzo) y los condensadores de 15 pFnecesarios para que la estabilidad a esta frecuencia sea la adecuada (Ver figura 2.6del capitulo 2.2.1.).

• Bloque de programaci on : Al igual que el bloque del clock, el diseno del bloque deprogramacion en esta placa es practicamente el mismo que el utilizado para el nodode 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 impe-dancias generados por las resistencias de los interruptores que tenemos en la otraplaca para seleccionar el protocolo (En la figura 2.30 se puede ver la configuracion).

• Bloque de comunicaciones : A fin de comunicarse con otros dispositivos (en nues-tro caso el nodo de comunicaciones) y transmitir las cadenas NMEA que contienenla informacion, esta placa se ayuda del protocolo RS232.

Metodologıa 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 lascomunicaciones RS232 del nodo de comunicaciones, con la unica diferencia delconector DB9, que en lugar de ser un DB9 hembra en la placa de adquisicion dedatos 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 capıtulo de teorıa 1.2.2. se explica el funcionamiento y caracterısticas de lossensores. Dicho capıtulo es muy importante a la hora de orientar y colocar los sen-sores, puesto que en funcion de los datos que queramos obtener tendremos queconfigurarlos en el espacio de una forma u otra (En la seccion 2.3.1.2. se explicacual sera la disposicion de estos sensores).

La forma de comunicar este bloque con el PIC es muy sencilla. Esto es ası ya queutilizamos unos conectores estandares ’dual row’ de 2 mm, iguales a los que llevanincorporadas las ’evaluation boards’, que son las tarjetas donde se encuentran lossensores.

Siguiendo la figura 2.31, vemos que de lo unico que tendrıamos que preocuparnosserıa de llevar cada pin (SCLK, CS, DOUT, DIN, etc.) que se encuentra en estatarjeta a su pin correspondiente en la placa. Para facilitar las cosas se ha creadoun cable que al conectarlo por cada extremo une directamente cada pin de la placacon 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-figuracion de los sensores, ha sido necesario crear una segunda placa y colocarlaen 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 mismascondiciones que el PCB del nodo de comunicaciones. El programa utilizado ha sido P-CAD2002 y se han usado tando la capa TOP como la BOTTOM.


Figura 2.31: Diagrama esquematico de la tarjeta y sus conexiones al conector estandardual 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 undispositivo que deberıa ir integrado en un vehıculo.

A la hora de abrir el archivo PCB veremos tres placas diferentes. La mas pequena, quellamamos “acopladora”, la “placa inercial” que contiene todos los bloques excepto el delos sensores, y la placa que contiene los sensores.

• Placa acopladora : Esta placa nos ayuda a unir los sensores con el dispositivo. Paraello, se unira la placa acopladora al sensor mediante unos tornillos que pasan porlos agujeros de la parte superior de la placa, y esta a su vez se unira a la placa delos sensores (donde estan los agujeros rectangulares) soldandola con estano.

• Placa inercial : Esta placa contiene toda la electronica necesaria para procesar ycomunicar, vıa 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 laplaca anterior. Se conecta mediante unos pines que estan soldados en ambas pla-cas de forma que quedan fijas y solidarias entre ellas. Ademas estos pines, a nivelde comunicaciones, son utilizados para comunicar los sensores con el PIC.

Debido a que los sensores ADIS16100 solo capturan datos sobre un eje y losADIS16201 en dos, la configuracion y orientacion de los sensores debe corres-ponder al de la figura 2.32, donde:

8Aun 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

Metodologıa 71

– El sensor 1 corresponde a un ADIS16100 en el que se realizan lecturas decabeceo, giroscopo en eje ’Z’.

– El sensor 2 corresponde a un ADIS16100 en el que se realizan lecturas deguinada, giroscopo en eje ’Y’.

– El sensor 3 corresponde a un ADIS16201 en el que se realizan lecturas deaceleracion en el eje ’X’ y el eje ’Z’.

– El sensor 4 corresponde a un ADIS16201 en el que se realizan lecturas deaceleracion 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 Placade Adquisicion de Datos.

El entorno de programacion utilizado es exactamente el mismo al que se utilizo para desa-rrollar el software del Nodo de Comunicaciones. Es por ese motivo que se pasa a explicardirectamente el Software disenado.

2.3.2.1. Codigo implementado

Como se hizo con el diseno del software del Nodo de Comunicaciones, antes de ponersea escribir el codigo han de quedar claras las principales caracterısticas que ha de tenerdicho codigo.

Hemos considerado que las caracterısticas mas relevantes pueden ser las siguientes:


• 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 especificaciones de los sensores ADIS.Para utilizar una comunicacion Full-duplex hemos utilizado una funcion que hasta ahorano se habıa 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 unpequeno matiz: No es lo mismo utilizar la funcion spi xfer() cuando el protocolo se haimplementado por hardware que cuando se ha implementado por software.

La diferencia esta en que en el primer caso se envıan los 16 bits, pero despues del octavoclock de reloj la lınea CLK se mantiene en estado alto un cierto tiempo con lo que seperdıa la comunicacion con el ADIS. Cuando el protocolo se implementa por software,se envıan los 16 bits seguidos. No nos pudimos dar cuenta de este hecho hasta quefinalmente pudimos examinar el proceso de comunicacion utilizando un osciloscopio.

En la figura 2.33 se puede ver la diferencia entre estos dos casos.

Figura 2.33: Ejemplo de envıo 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 cogeranel ID y el comando que se habra enviado por el bus CAN. Una vez recibidos se activara unavariable global para habilitar el envıo del comando al ADIS correspondiente.

Una vez tenemos estos puntos claros, hemos de especificar la jerarquıa de ficheros queutilizaremos. Tales ficheros 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 finalmente devolverselos al nodo. Por lo tanto, es donde se encuentrala funcion ’main()’ del programa.

Metodologıa 73

• ’funciones adis.c’ : En este fichero podemos encontrar las funciones necesariaspara poderse comunicar con los sensores ADIS e interpretar correctamente la infor-macion que proporcionan. Las funciones dentro de este fichero son las siguientes:

– ’seleccion cs(CS, id)’ : Devuelve el pin del CS a utilizar en funcion del ID reci-bido.

– ’grados minuto(comando, recepcion)’ : Procesa los datos recibidos de los sen-sores 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 alos ultimos 12 bits de la respuesta de los ADIS) y se multiplica por el valor dela resolucion (0,2439o/s en el caso de velocidad angular).

– ’temperatura(comando, recepcion)’ : Procesa los datos recibidos de los senso-res ADIS y devuelve la temperatura en oC.

Primero hemos de calcular el valor binario de los datos (correspondientes alos ultimos 12 bits de la respuesta de los ADIS) y se multiplica por el valor dela resolucion (0,1453oC en el caso de temperatura).

Sumandole 25oC a este resultado, obtendremos el valor de la temperaturainterna del ADIS.

– ’checksum(checksum1, checksum2)’ : Devuelve el checksum 9 del valor recibi-do de los ADIS.

– ’aceleracion(recepcion, recepcion2, id)’ : Procesa los datos recibidos de lossensores 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 ADISy devuelve la temperatura. A diferencia de ’temperatura(comando, recepcion)’,’temperatura 2(recepcion)’ es para los ADIS201.

• ’funciones adis.h’ : En esta librerıa se declaran las funciones de ’funciones adis.c’.

• ’18F2580.h’ : En esta librerıa se definen todas las constantes asociadas al PIC18F2580.

En la figura 2.34 se puede ver la dependencia entre cada uno de los ficheros.

Para poder seguir con mayor facilidad el codigo implementado, se pueden ver el diagramasde flujo del codigo en el Anexo B. Para explicar el codigo, hemos dividido el diagrama deflujo en varios modulos;

• Modulo ’Configuraci on Placa de Adquisici on de Datos’ : Es aquı donde se con-figuran 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-finiciones de constantes utilizadas en el codigo, y seguidamente la librerıa ’funcio-nes adis.c’ para tener acceso a las funciones definidas por nosotros.

9Una suma de verificacion o checksum es una forma de control de redundancia, una medida muy simplepara proteger la integridad de los datos, verificando que no hayan sido corrompidos.


Figura 2.34: Jerarquıa de los ficheros utilizados en la Placa de Adquisicion de Datos.

Seguidamente se declararan las mismas directivas #fuses que se declararon en elsoftware del Nodo de Comunicaciones. Estas son HS, NOWDT, NOLVP y NOPRO-TECT.

El reloj se configura a 20 MHz con la directiva #use delay(clock=frecuencia).

Una vez configurados 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 elpuerto serie se ha utilizado la misma directiva que se utilizo para el Nodo de Comu-nicaciones. Sin embargo, hemos utilizado una directiva diferente para el protocoloSPI.

Como se ha comentado anteriormente, para poder enviar los 16 bits de datos te-niamos que implementar el protocolo por software. Esto nos ha obligado a utilizarla 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 configuracion.

Otro gran problema que tuvimos a la hora de implementar el codigo era la decisiondel modo de trabajo de SPI. En el datasheet del ADIS16100 hacen referencia ala configuracion donde CPOL=1 y CPHA=0. Con esta configuracion, el modo detrabajo es el 2 (Mode=2) pero no obtenıamos datos validos de los ADIS.

Metodologıa 75

Despues de muchos dias de pruebas infructuosas, se decidio probar con los modos0, 1 y 3. Fue una gran sorpresa cuando confirmamos que con el modo 1 los ADISrespondian correctamente a todos los comandos.

Lo anterior significa que la configuracion correcta es CPOL=0 y CPHA=0. Por lotanto, de cara a futuros proyectistas, se ha de tener en cuenta este hecho y notomar 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 semuestran todos los errores en dicho datasheet.

El modo de trabajo de SPI para los ADIS201 no lo sabemos, ya que no se ha podidoexperimentar con ellos al quemarse los dos sensores durante las pruebas.

Para finalizar, activamos las interrupciones a utilizar y ponemos los 4 CS’s de los 4sensores 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 habilitacionde la variable para poder enviar los comandos al ADIS y procesar los datos. Unavez finalizados estos dos procesos, se volvera al punto de espera.

En la figura 2.35 se observa el diagrama de flujo de este modulo.

Figura 2.35: Diagrama de flujo del modulo ’Configuracion Placa Adquisicion de Datos’.

• Modulo ’Interrupci on RDA en ADIS16201’ : En esta interrupcion se cogeran el ID yel 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 valorde las variables globales). Si ya tenıamos el ID, dicho caracter sera guardado comoprimer o segundo byte del comando a enviar al ADIS. Una vez ya se tengo el ID y el

10Ya comprobamos que el datasheet que tenıamos fuera la ultima revision


comando, se activa una variable para que en la funcion ’main()’ se envıe el comando,se reciban los datos, se procesen y se envıen al Nodo de Comunicaciones.


Figura 2.36: Diagrama de flujo 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 ADISsolicitado.

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 dosciclos 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 quenecesita de la directiva #use spi() para configurarse. De esta forma podremos enviarlos 16 bits dentro del mismo ciclo.

Tal y como estan situados los ADIS16201, la medida de la aceleracion e inclinacionen el eje ’z’ se puede obtener a partir de ambos ADIS16201. Es por este motivo quecuando se recibe el ID 130 o 133 (Ver tabla 2.1) se ha de realizar dos veces el dobleciclo de 16 bits y guardar ambas respuestas.

Despues de recibir los datos de los sensores ADIS, hemos de procesar los datosdiferenciandolos 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=129y ID=130), incliniacion (ID=131, ID=132 y ID=133) o temperatura de los sensoresADIS16201 (ID=138 y ID=139). Esta seleccion la realizamos mediante 5 IF’s y seentrara en cada uno dependiendo del ID (Ver tabla 2.1).

Metodologıa 77

En cada IF se llamara a la funcion correspondiente para procesar los datos, secalculara el checksum11 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. Esteprotocolo sigue la estructura de la figura 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 sensoresADIS.

Entre el VALUE y el CHECKSUM hemos anadido una caracter para indicar si losdatos obtenidos son validos o no. Si el resultado de esta variable es una ’A’, elresultado sera valido. Sin embargo, si es una ’V’ el resultado no sera valido.


11Actualmente esta funcion solo devuelve dos ’0’ con lo que se deja para un futuro el calculo real delchecksum.


Figura 2.38: Diagrama de flujo del modulo ’Pedido y Envio de Datos en ADIS16201’.

Experimentos 79

CAPITULO 3. EXPERIMENTOS

3.1. Introducci on

En este capıtulo se explican todos los experimentos realizados para poder certificar yvalidar los requisitos propuestos al principio de esta memoria. Se comprueba tanto elfuncionamiento del protocolo en sı, como el flujo de datos entre un dispositivo y otro.

En el primer apartado se describen los experimentos utilizados para comprobar cada unode 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 elCAN.

En las pruebas de I2C y SPI hemos utilizado RS232 para poder visualizar la recepcionde datos. Es por ese motivo que los experimentos los hemos llamado I2C-CAN-RS232 (yno I2C-CAN-I2C) y SPI-CAN-RS232 (y no SPI-CAN-SPI). A pesar de esto, demostrandoel 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 habledirectamente en estos protocolos, por lo que se necesita de unos codigos extra. En estoscodigos se pretende emular a dispositivos del tipo 1, 2 y 3. Hemos decidido no explicarpaso a paso el codigo utilizado ya que no incumbe al Nodo de Comunicaciones, pero sı sepueden ver en el Anexo A.

Para cada Nodo de Comunicaciones hemos de configurar el fichero funciones.c. En losexperimentos de la parte del Nodo de Comunicaciones esta configuracion sera la mismapara todos los Nodos. Es por eso que los vamos a detallar a continuacion y no en cadaexperimento.

• Funcion imprimir id() : En nuestro experimento no sera necesario visualizar los ID’spor lo que el return de esta funcion sera FALSE. Si se quieren visualizar por pantallaa traves de HyperTerminal los ID’s, simplemente tendremos que cambiar el return aTRUE.

• Funcion condicionfinal() : Configuraremos 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 codigoASCII corresponde a pulsar el intro en el PC, por lo que cuando pulsemos ’ENTER’el nodo interpretara esta accion como final de condicion.

• Funcion id valido() : Los ID’s que enviaremos han sido previamente calculados deforma que sean validos para el protocolo CAN. Por lo tanto, esta funcion ha deretornar un TRUE.

• Funcion set id vallido() : No hace falta configurar esta funcion, puesto que nunca lautilizaremos.

• Funcion condicion final can() : Esta funcion siempre retornara el valor 13 (’\r’).


Las funciones selecci on mensaje() , id entrada id salida() y mensaje a responder() secomentaran en cada experimento.

Tanto para familiarizarnos como para comprobar el correcto funcionamiento del bus CANen 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 capıtulo ya que no son experi-mentos propios del Nodo de Comunicaciones sino del protocolo en general en una placade pruebas. Es por este motivo que hemos decidido incluir los ejercicios realizados enesta 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 seguida-mente la operabilidad entre los dos diferentes ADIS16100.

No se ha podido trabajar con los dos ADIS16201 de que disponıamos debido a diversosproblemas que se tuvo con ellos. Uno de ellos se quemo al tocar accidentalmente el cablede alimentacion la regleta de los 9V (cuando su alimentacion es de 3,3V) y el segundoADIS16201 tenia continuidad entre la alimentacion y el GND. Aun ası, se ha disenadotanto el software como el hardware necesario para que en un futuro se puedan anadiresos dos sensores ADIS16201.

Un ultimo experimento consiste en la union del Nodo de Comunicaciones, la Placa deAdquisicion de Datos, un GPS y un PC para poder monitorizar toda la informacion a travesde otro PC. De esta forma se comprobara el funcionamiento global del sistema utilizandodiferentes dispostivios a la vez.

Es importante destacar que tanto los experimentos del Nodo de Comunicaciones comolos de la Placa de Adquisicion de Datos se han realizado sobre las protoboards en lasque se montaron todos los elementos. Una vez comprobado que se obtenıan resultadospositivos de los experimentos, se paso a disenar el circuito impreso con P-CAD 2002 parasu posterior fabricacion. Volvimos a realizar los experimentos hechos anteriormente enlas 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 figura 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 yconfigurarlo tal y como se presenta en la figura 3.1. Se ha de configurar en el puertodonde se conecte el cable NULL MODEM, que en nuestro caso es el COM1.

Figura 3.1: Configuracion HyperTerminal.

6. Conectar los dos Nodos de Comunicaciones a la alimentacion.

7. Poner el interruptor correspondiente a RS232 en ’ON’, y los otros dos interruptoresen ’OFF’ (Ver figura 3.2).”).

8. Finalmente, para los experimentos en los que se utilizen tres nodos y tres PC’s,la conexion CAN se tendra que hacer conectando los tres nodos a un bus gene-ral(CANH y CANL) con dos resistencias de 120 Ω en paralelo en cada extremo(como se comento en el apartado 2.2.1.).

El montaje final se puede observar en las figuras 3.3 y 3.4.

Antes de realizar los experimentos hemos de configurar las funciones ’seleccion mensaje’,’id entrante id salida’ y ’mensaje a responder’. De esta manera podremos trabajar condispositivos del tipo 1, 2 y 3.


Figura 3.2: Interruptor RS232 en ON.

En la funcion ’seleccion mensaje’ anadiremos los ID’s 778, 779 y 1931. Al mensaje conID = 778 = ’1100001010’ lo trataremos como paquete del tipo ’Datos’ mientras que almensaje con ID = 779 = ’1100001011’ lo trataremos como paquete del tipo ’Comando’. Elpaquete con el ID = 1931 sera el paquete respuesta al Comando.

En estos experimentos tambien utilizaremos el ID = 796 = ’1100011100’ para comprobarque nuestros filtros 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 (poreso hemos de aceptar los paquetes con ID = 1931). En la funcion ’mensaje a responder’anadiremos el ID = 779. En resumen:

• ID’s 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 losdos bytes de informacion del ID. Por ejemplo, si queremos enviar el ID = 778 tendremosque escribir como primer caracter la letra a = 97 = ’1100001’ (recordar que RS232 esorientado 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 loscaracteres que se envıen han de ser procesados como datos y no como ID.

Para comprobar el correcto funcionamiento del puerto serie realizamos las siguientespruebas:

• Prueba 1: El PC1 envıa ’ab12345678ab12345678\r’ y el PC2 tendrıa que recibir’12345678ab12345678\r’. Esta prueba nos sirve para ver si se transmite y recibecorrectamente tanto el ID como los datos.

Experimentos 83

Figura 3.3: Esquema montaje experimentos RS232-CAN-RS232.

• Prueba 2: El PC1 envıa ’cd12345678ab12345678\r’ y el PC2 tendrıa que recibir ”.En esta prueba, al igual que la anterior, se pretende comprobar que el ID y los datosse envıan correctamente. Pero en este caso al enviar otro ID, no tendrıa que salirnada por el Hyperterminal del PC2.

• Prueba 3: El PC1 envıa ’ab1234567812\rab1234567812\r’ y el PC2 tendrıa querecibir ’1234567812\r1234567812\r’. Esta prueba nos sirve para ver si despues deuna condicion de final de datos (\r) enviada en medio de los datos, la comunicacionse inicia correctamente.

• Prueba 4: El PC1 envıa ’ab1234567812\rcd1234567812\r’ y el PC2 tendrıa querecibir ’1234567812\r’. Al igual que en la prueba anterior, en esta se pretende versi despues de un \r enviado en medio de los datos, la comunicacion se inicia co-rrectamente aunque se envıe un ID erroneo.

• Prueba 5: El PC1 envıa ’ab\rab1234567812\r’ y el PC2 tendrıa que recibir’\r1234567812\r’. Esta prueba nos sirve para ver si despues de una condicion definal de datos enviada justo despues del segundo byte con informacion de ID, lacomunicacion se inicia correctamente.

• Prueba 6: El PC1 envıa ’ab\rcd1234567812\r’ y el PC2 tendrıa que recibir ’\r’.Al igual que en la prueba anterior, en esta se pretende ver si despues de un \renviada justo despues del segundo byte con informacion de ID, la comunicacion seinicia correctamente aunque se envıe un ID erroneo.

• Prueba 7: El PC1 envıa ’a\rab1234567812\r’ y el PC2 tendrıa que recibir


Figura 3.4: Montaje experimentos RS232-CAN-RS232.

’1234567812\r’. Esta prueba nos sirve para ver si despues de una condicion de finalde datos enviada despues del primer byte con informacion de ID, la comunicacionse inicia correctamente.

• Prueba 8: El PC1 envıa ’a\rcd1234567812\r’ y el PC2 tendrıa que recibir ”. En estaprueba, al igual que en la anterior, se pretende ver si despues de una condicion definal de datos enviada despues del primer byte con informacion de ID, la comunica-cion se inicia correctamente aunque se envıe un ID erroneo.

• Prueba 9: El PC1 envıa ’\rab1234567812\r’ y el PC2 tendrıa que recibir1234567812\r’. Esta prueba nos sirve para ver si despues de una condicion definal de datos enviada justo al inicio de la comunicacion, la comunicacion se iniciacorrectamente.

• Prueba 10: El PC1 envıa ’\rcd1234567812\r’ y el PC2 tendrıa que recibir ”. En estaprueba, al igual que en la anterior, se pretende ver si despues de una condicion definal de datos enviada justo al inicio de la comunicacion, la comunicacion se iniciacorrectamente aunque se envıe un ID erroneo.

• Prueba 11: El PC1 envıa ’ab123456781234\r\rab123456\r’ y el PC2 tendrıa querecibir ’123456781234\r123456’. Esta prueba nos sirve para ver si enviar dos con-diciones de final de comunicacion seguidas afecta a la siguiente comunicacion.

• Prueba 12: Una ultima prueba es la de la comunicacion en ambos sentidos. En estecaso, los dos PC solo estaran para recibir los datos. La transmision de datos sehara a traves de los PIC’s. Se programaran para que justo despues de un reseteose envıe ’123456781234567812345678’.

Experimentos 85

• Prueba 13: Esta prueba es exactamente igual que la anterior con la diferencia deque 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 figura 3.5.

Figura 3.5: Resultado de las pruebas 1 a la 13.

Despues de estas pruebas, corroboramos el correcto funcionamiento de la recepcion delID y de los datos y su posterior envıo. Pero solo se han hecho las pruebas para los envıosde 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 comprobarel correcto funcionamiento de la recepcion de ID’s).

• Prueba 14: El PC1 envıa ’ac1234\r’. Al ser un comando, el PC2 recibira ’1234\r’ ytendra 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 primerosbytes que envıa 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 lafuncion ’id entrante id salida’.


• Prueba 15: Una ultima prueba es realizar la comunicacion entre tres PC’s en el quecada uno enviara datos con un ID diferente y aceptara paquetes de uno de los otrosdos PC.

Por ejemplo, el PC1 envıa datos con el ID = 778 y acepta el ID = 779, el PC2 envıacon ID = 800 y acepta el ID = 778, y el PC3 envıa con ID = 779 y acepta el ID = 800(Ver figura 3.6).

En esta prueba solo nos interesa saber si el bus CAN funciona correctamente conmas 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 paquetescomo si fueran del tipo ’Datos’. Por lo tanto, en la funcion ’mensaje a responder’ nopondremos ningun ID.

Figura 3.6: Esquema: Ejemplo de la distribucion de ID’s entre 3 PC’s.

Despues de realizar las 15 pruebas, hemos podido certificar el correcto funcionamientode 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

1Un nodo estara configurado 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 delnodo 1 al GND del nodo 2.

• Conectar el bus CAN entre los nodos 2 y 3 mediante los pines CANH y CANL delUserTerminal.

• Conectar los GND de los nodos 2 y 3.

• Al nodo 3 conectaremos en el puerto serie un cable NULL MODEM. Al otro extremodel cable NULL MODEM conectaremos el PC. Este PC leera la informacion que lellegue y la mostrara por el HyperTerminal.

• Configurar el Hyperterminal como se muestra en la figura 3.1.

• Como el nodo 2 sera el que reciba o envıe datos por I2C, hemos de poner en ’ON’el interruptor de I2C y a ’OFF’ el de RS232 y SPI2 (Ver figura 3.7). En el nodo 3solo hemos de activar el interruptor correspondiente a RS232. En el primer nodo nohara falta el interruptor porque ya estara programado como si fuera un dispositivoI2C.

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 ficheros ’experimentos i2c.c’ y ’experimentos i2c modo2.c’(Ver Anexo A). Con estos codigos configuraremos el nodo como dispositivo del tipo1 o 2.

El montaje final del experimento se puede observar en la figura 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

2Recordar que la inicializacion del protocolo SPI desconfigura la del I2C. Por este motivo se recomiendahacer un reset y despues poner en ’ON’ el interruptor de I2C.


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 enI2C).

Se han de volver a configurar 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 experi-mento 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 prue-ba 14. La prueba 15 no se realiza en este caso debido a la imposibilidad de poder escribirdatos en I2C en cualquier momento.

Despues de realizar las 14 pruebas, hemos podido certificar el correcto funcionamientode 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 ex-perimento anterior, uno de los nodos lo programaremos adecuadamente para que puedasimular 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 SDOdel nodo 1 al SDI del nodo 2, el SDI del nodo 1 al SDO del nodo 2, el SCLK delnodo 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 delUserTerminal.

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 extremodel cable NULL MODEM conectaremos el PC. Este PC leera la informacion que lellegue y la mostrara por HyperTerminal.

• Configurar el Hyperterminal como se muestra en la figura 3.1.

• Como el nodo 2 sera el que reciba o envıe datos por SPI, hemos de poner en ’ON’el interruptor de SPI y a ’OFF’ el de RS232 y I2C (Ver figura 3.9). En el nodo 3solo hemos de activar el interruptor correspondiente a RS232. En el primer nodo nohara falta el interruptor porque ya estara programado como si fuera un dispositivoSPI.

Figura 3.9: Interruptor SPI en ON.

• Programar el nodo 1 con los ficheros ’experimentos spi.c’ y ’experimentos spi modo2.c’(Ver Anexo A). Con estos codigos configuraremos el nodo como dispositivo del tipo1 o 2.


Las pruebas a seguir en este experimento son las mismas que las utilizadas en el expe-rimento RS232-CAN-RS232. Al igual que en el experimento anterior, la unica diferenciasera 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 orde-nador no podemos escribir en SPI).

Se ha de volver a configurar 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 experi-mento 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).


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 prue-ba 14. La prueba 15 no se realiza en este caso debido a la imposibilidad de poder escribirdatos en SPI en cualquier momento.

Despues de realizar las 14 pruebas, hemos podido certificar el correcto funcionamientode la interaccion entre los protocolos SPI y CAN en los Nodos de Comunicacion.

3.3. Placa de adquisici on de datos

3.3.1. Recepci on de datos de un solo ADIS16100

Con este experimento se pretende recibir correctamente los datos del ADIS16100. Estepaso es necesario hacerlo antes de realizar el experimento en el que comunicaremos unPC mediante CAN a la Placa de Adquisicion de Datos con los dos ADIS16100.

El codigo utilizado en este experimento no sera el codigo definitivo en la Placa de Ad-quisicion de Datos pero se puede ver en el Anexo A con el nombre de ’experimen-to solo 1 adis.c’.

Para ello configuraremos 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 decada configuracion se enviaran 700 pedidos de lectura. Todas estas lecturas se guardanen memoria para despues imprimirlas por pantalla.

Tanto con los comandos de configuracion 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 configuracion ycomando de lectura.

En nuestro experimento hemos utilizado los siguientes comandos3:

3Ver tabla 1.8 para recordar que significaba cada bit en el registro DIN del ADIS16100

Experimentos 91

• 33552: Este numero corresponde a los bytes ’1000001100010000’. Con lo que con-figuraremos el sensor para que proporcione datos de velocidad angular en formatoOffset Binary.

• 33536: Este numero corresponde a los bytes ’1000001100000000’. Con lo que con-figuraremos el sensor para que proporcione datos de velocidad angular en formatoComplemento a 2.

• 47056: Este numero corresponde a los bytes ’1011011111010000’. Con lo que con-figuraremos el sensor para que proporcione datos de temperatura en formato OffsetBinary.

• 34560: Este numero corresponde a los bytes ’1000011100000000’. Con lo que con-figuraremos el sensor para que proporcione datos de temperatura en formato Com-plemento a 2.

• 784: Este numero corresponde a los bytes ’1100010000’. Con lo que podremosobtener datos del sensor sin reconfigurarlo.

Como se comento en los capıtulos 2.3.2. y 1.2.2.1., el ADIS funciona con ciclos de 16bits. Para poder enviar 16 bits seguidos, implementamos el protocolo SPI por software uti-lizando 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, configurarlos pines de los dos cables de datos y el del reloj, y sobretodo determinar el Modo defuncionamiento que en nuestro caso es el Modo 14.

Los resultados esperados deberıan ser los siguientes (Ver tabla 1.9 para recordar quesignificaba cada bit en el registro DOUT del ADIS16100):

• Para datos de velocidad angular en Offset Binary: Suponiendo que tenemos lossensores sin movimiento, el resultado obtenido deberıa estar entorno al0000100000000000’.

• Para datos de velocidad angular en Complemento a 2: Suponiendo que tenemoslos sensores sin movimiento, el resultado obtenido deberıa estar entorno al’0000000000000000’.

• Para datos de temperatura en Offset Binary: Suponiendo que la temperatura in-terna de los sensores es de 25oC, el resultado obtenido deberıa estar entorno al’0001100000000000’.

• Para datos de temperatura en Complemento a 2: Suponiendo que la temperaturainterna de los sensores es de 25oC, el resultado obtenido deberıa estar entorno al’0001000000000000’.


4Ver Anexo D para ver porque es el Modo 1


• Conectar los pines de los conectores J1 y J2 (Ver figura 2.31) de la placa de eva-luacion de los ADIS16100 a los conectores dual row. Se supone que los sensoresADIS ya estaran situados en la Placa de Adquisicion de Datos, y por lo tanto estepaso nos lo podrıamos saltar.

• Conectar el cable Null Modem de la placa de Adquisicion de datos al PC.

• Configurar el Hyperterminal del PC como se muestra en la figura 3.1.

• Configurar el Hyperterminal para que capture los datos en un fichero ’.txt’5.

• Conectar la alimentacion a la placa.

• Programar el PIC18F2580 con el fichero ’experimento solo 1 adis.c’.

• Esperar a recibir 4 veces los 700 datos solicitados al ADIS16100.

• Configurar el Hyperterminal para que pare de capturar los datos6.

Una vez realizados estos pasos, podremos ver el fichero .txt para comparar los resultadosobtenidos con los teoricos. Haciendo estas comparaciones podremos ver si el sensoresta bien calibrado.

En el caso de las medidas de temperatura no podemos saber si el sensor esta bien cali-brado o no (porque no tenemos ninguna referencia para compararlo). Aun ası, los resul-tados han sido satisfactorios porque estan alrededor de un valor razonable (22oC). Losresultados se pueden observar en las figuras 3.11 y 3.12.

Figura 3.11: Resultados de temperatura en Offset Binary del primer ADIS16100.

5Ir al menu Transferir –> Capturar Texto –> Iniciar6Ir 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. Losresultados se pueden observar en las figuras 3.13 y 3.14.

Como se puede observar, tenemos un Offset8 en las medidas entorno a los 47 LSB. Auna resolucion de 0,2439o/s/LSB a este offset le corresponde un error de alrededor de11,46o/s.

Para evitar este error, en la funcion ’grados minuto(comando, recepcion)’ del fichero ’ad-quisicion datos.c’ (que sera el fichero final que se programara en la placa) se le restara es-te error a las medidas efectuadas.

Tanto en los resultados de temperatura como de velocidad angular se puede observar quetenemos una deriva. Esta deriva nos proporcionara un error maximo de no mas de 5,5o/so 6oC. Desgraciadamente este error no se puede corregir9.

Estos son los resultados de calibracion del primer ADIS16100, pero aun queda por calibrarel segundo ADIS16100. El proceso es el mismo y los resultados obtenidos se puedenobservar en las figuras 3.15, 3.16, 3.17 y 3.18.

El offset obtenido en los datos de velocidad angular de este ADIS16100, tambien setendra en cuenta en la funcion ’grados minuto(comando, recepcion)’ del fichero ’adqui-sicion datos.c’.

Podemos observar que el error maximo que pueden tener los dos ADIS16100 es practi-camente identico. En lo unico que varıan es en el offset de los datos de velocidad angular.Al ser mas grande en el primer ADIS16100, la compensacion que tendremos que anadiren la funcion ’grados minuto(comando, recepcion)’ sera tambien mas grande.

7Como el sensor no se mueve, la velocidad angular ha de ser 0.8Diferencia entre valor teorico y valor real9Aunque se podrıa compensar parcialmente tomando varias medidas


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 parael mismo ADIS el offset para los datos en formato Offset Binary y Complemento a dosdeberıa ser igual. En nuestro caso eso se cumple; en el primer ADIS16100 tenemos offsetde 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 ademashemos podido calibrar los sensores.

3.3.2. Recepci on de datos de la Placa de Adquisici on de Datos porbus 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 estecaso, la placa de Adquisicion de Datos tendra incorporado los dos ADIS16100 y los dosADIS16201.

Al utilizar un PC como transmisor de comandos y receptor de datos, tuvimos una seriede problemas. Los ID’s asociados para la placa de adqusicion de datos no los podemosdividir en dos bytes (Ver figura 2.24). Estos dos bytes resultarıan ser dos caracteres noimprimibles, y por lo tanto no se podrıan 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() sehabilitara 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 elHyperterminal.

• Se envıa un ’1’: La funcion devolvera el ID = 136 y 3 bytes de informacion. Dos bytescon informacion del comando a enviar a los ADIS (183 y 208) y una condicion definal de datos (13).

Con los dos bytes con informacion de comando obtendran el valor 47056, con el quepodremos obtener informacion de temperatura interna en Offset Binary (Recordartabla 1.8). Con el ID = 136 indicamos que la informacion la queremos del primerADIS16100 (Recordar tabla 2.1).

• Se envıa un ’2’: La funcion devolvera el ID = 136 y 3 bytes de informacion. Dos bytescon informacion del comando a enviar a los ADIS (135 y 0) y una condicion de finalde datos (13).

Con los dos bytes con informacion de comando obtendran el valor 34560, con elque podremos obtener informacion de temperatura interna en Complemento a 2(Recordar tabla 1.8). Con el ID = 136 indicamos que la informacion la queremos delprimer ADIS16100 (Recordar tabla 2.1).

• Se envıa un ’3’: La funcion devolvera el ID = 137 y 3 bytes de informacion. Dos bytescon informacion del comando a enviar a los ADIS (183 y 208) y una condicion definal de datos (13).

Con los dos bytes con informacion de comando obtendran el valor 47056, con el quepodremos obtener informacion de temperatura interna en Offset Binary (Recordartabla 1.8). Con el ID = 137 indicamos que la informacion la queremos del segundoADIS16100 (Recordar tabla 2.1).


Figura 3.15: Resultados de temperatura en Offset Binary del segundo ADIS16100.


Con los dos bytes con informacion de comando obtendran el valor 34560, con elque podremos obtener informacion de temperatura interna en Complemento a 2(Recordar tabla 1.8). Con el ID = 137 indicamos que la informacion la queremos delsegundo ADIS16100 (Recordar tabla 2.1).


Con los dos bytes con informacion de comando obtendran el valor 33552, con elque podremos obtener informacion de velocidad angular en Offset Binary (Recordartabla 1.8). Con el ID = 134 indicamos que la informacion la queremos del primerADIS16201 (Recordar tabla 2.1).


Con los dos bytes con informacion de comando obtendran el valor 33536, con el quepodremos obtener informacion de velocidad angular en Complemento a 2 (Recordartabla 1.8). Con el ID = 134 indicamos que la informacion la queremos del primerADIS16201 (Recordar tabla 2.1).


Con los dos bytes con informacion de comando obtendran el valor 33552, con elque 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 segundoADIS16201 (Recordar tabla 2.1).


Con los dos bytes con informacion de comando obtendran el valor 33536, con el quepodremos obtener informacion de velocidad angular en Complemento a 2 (Recordartabla 1.8). Con el ID = 135 indicamos que la informacion la queremos del segundoADIS16201 (Recordar tabla 2.1).

Estas modificaciones de codigo en funciones.c se han hecho para facilitar el envıo y lavisualizacion de los Datos. Pero una vez se haya realizado el experimento se puedeneliminar estas partes de codigo y no afectarıa en nada al funcionamiento global.

Antes de programar los codigos en los PIC’s hemos de reconfigurar la funcion funciones.cpara cada Nodo de Comunicaciones, ya que cada dispositivo tiene un funcionamientodiferente. Estas configuraciones son las siguientes:

• Para el Nodo conectado al PC:

– Funcion selecci on mensaje() : Este PC aceptara ID’s de la placa de adquisi-cion de datos(1280-1291) y del reset de comunicaciones (0).

– Funcion id entrada id salida() : No es necesario configurar esta funcion por-que 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 deID’s tendra que estar vacıo (encontrado=false;).


Figura 3.17: Resultados de velocidad angular en Offset Binary del segundo ADIS16100.

– Funcion imprimir id() : En nuestro experimento no sera necesario visualizarlos ID’s, por lo que el return de esta funcion sera FALSE. Si se quieren visua-lizar por pantalla a traves de HyperTerminal los ID’s, simplemente tendremosque cambiar el return a TRUE.

– Funcion condicionfinal() : Configuraremos el return de la funcion a ’13’ quees 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 cuandopulsemos ’ENTER’ el nodo interpretara esta accion como final de condicion.

– Funcion id valido() : Los ID’s 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 configurar esta funcion, puesto que nun-ca la utilizaremos.

– Funcion config interfaz() : Al igual que en el experimento 3.3.2., para facilitarla transmision de datos de la placa de adquisicion de datos al PC1 utilizaremosesa misma interfaz. De modo que para habilitarla tendremos que configurar elreturn de esta funcion a TRUE (solo en este nodo).

– Funcion condicion final can() : En esta funcion se ha de asociar los ID’s 0,134, 135, 136 y 137 a ’\r’ como condicion final, y los ID’s 1286, 1287, 1288 y1289 a ’\n’ como condicion final.

• Para el Nodo conectado a la Placa de Adquisicion de Datos:

– Funcion selecci on mensaje() : Para la seleccion de mensajes en la placa deadquisicion de datos, y por lo tanto para la configuracion del vector de ID’s aaceptar, seguiremos la tabla 2.2.

Experimentos 99

Figura 3.18: Resultados de velocidad angular en Complemento a 2 del segundoADIS16100.

– Funcion id entrada id salida() : Este dispositivo responde a paquetes entran-tes. Debido a que en la informacion que envıan los chips ADIS16100 yADIS16201 no se encuentran los ID’s de los mensajes que se enviaran, selos 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 ID’s que en lafuncion seleccion mensaje(), menos el ID = ’ 0’ ya que no queremos responderal Reset de las comunicaciones.

– Funcion imprimir id() : Debido a que los ID’s son necesarios en la placa deadquisicion de datos para saber que sensor tiene que capturar los datos, de-bemos enviar (imprimir) el ID al dispositivo. Configuraremos el return a TRUE.

– Funcion condicionfinal() : Configuraremos el return de la funcion a ’10’ quees un ’\n’ en el codigo ASCII. Esto es debido a que en el protocolo standardNMEA, utilizado en la placa de adquisicion de datos, cuando se finaliza unatransmision de datos el ultimo caracter es ’\n’ (ver figura 2.37).

– Funcion id valido() : Este dispositivo no envıa ID’s con el formato adecuadopara CAN (por prioridades, tipos de paquetes, etc), por lo tanto el return deesta funcion tendra que ser configurado a False ya que no es valido.

– Funcion set id valido() : Esta funcion no la tendremos que configurar, puestoque previamente en la funcion id entrada id salida() hemos calculando el IDde salida en funcion del ID de entrada.

– Funcion config interfaz() : En este nodo no es necesario utilizar la interfazpara enviar y recibir datos de la placa de adquisicion de datos por lo quedebemos configurar el return a False.


– Funcion condicion final can() : En esta funcion se han de asociar los ID’s 0,134, 135, 136 y 137 a ’\r’ como condicion final, y los ID’s 1286, 1287, 1288 y1289 a ’\n’ como condicion final.


• Conectar el puerto serie del PC al conector DB9 de un Nodo de Comunicacionesmediante 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 laPlaca de Adquisicion de Datos.

• Configurar el Hyperterminal del PC como se muestra en la figura 3.1.

• Conectar la alimentacion a los dos Nodos de Comunicaciones y a la Placa de Ad-quisicion de Datos.

• Programar el fichero tfc.c en los Nodos de Comunicaciones (modificiar en cada casoel archivo funciones.c como se ha comentado anteriormente).

• Programar el fichero adquisicion datos.c en la Placa de Adquisicion de datos.

• Conectar los interruptores correspondientes al protocolo RS232 en los dos Nodos.


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 deAdquisicion de Datos. La prueba que se ha realizado es bastante sencilla. Escribiremos3 veces seguidas en el Hyperterminal los numeros del 1 al 8. De esta forma pediremos3 veces datos de temperatura y velocidad angular en los dos formatos y a los dos ADIS.Los resultados obtenidos tendrıan que ser los siguientes:

Experimentos 101

• Cuando escribimos un ’1’: Se pide informacion de temperatura y deberıamos recibir’$PADIS,valor obtenido,A*00\r\n’, donde valor obtenido es el valor que devuelvenlos ADIS.




• Cuando escribimos un ’5’: Se pide informacion de velocidad angular y deberıamosrecibir ’$INROT,valor obtenido,A*00\r\n’, donde valor obtenido es el valor que de-vuelven 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 dedatos posibles.

Despues de realizar el experimento el resultado fue el de la figura 3.20.

Figura 3.20: Resultados a los 8 pedidos posibles desde el PC.


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 certifica el correcto funcionamientode la comunicacion Placa de Adquisicion - CAN - PC.

Como ultimo experimento, juntaremos los dos grandes bloques que hemos probado hastaahora (comunicacion PC-CAN-PC y Placa Adquisicion de Datos-CAN-PC) junto con unGPS que nos ha proporcionado el Prof. Dagoberto Salazar.

3.4. Experimento final: Placa Adquisici on de Datos, PC yGPS con otro PC monitorizando

Es el momento de realizar el experimento final donde se probara el correcto funcionamien-to del sistema de comunicaciones que se ha desarrollado a lo largo del TFC. Explicaremoscuales dispositivos se han utilizado, como se han realizado las conexiones y las configu-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 PC’s. 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 PCse comunicara con el primero, enviando y recibiendo paquetes de datos.

• Una Placa de Adquisicion de Datos inerciales.

• Un GPS (Ver figura 3.21), que envıa periodicamente con una cierta frecuencia unascadenas NMEA. Estas contienen informacion de posicionamiento captadas de lossatelites 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 (vertipos de dispositivos en 2.2.2.2.) los nodos de comunicacion deben ser re-configurados deacuerdo con la forma de trabajo de cada uno de los dispositivos.

Experimentos 103

Para realizar estas re-configuraciones del nodo, simplemente tendremos que editar elarchivo ’funciones.c’ como se explica a continuacion para cada uno de los dispositivos y,exclusivamente para este experimento, editar la velocidad de transferencia del protocoloRS232 del archivo ’tfc.c’ para el nodo del dispositivo PC1.

• Los PC’s se comportan como un dispositivo del tipo 3. Por ello cuando vayamos aeditar el archivo ’funciones.c’ realizaremos los siguientes cambios:

PC1: Monitorizar GPS + peticiones datos inerciales + comunicacion PC2

– Funcion selecci on mensaje() : Este PC aceptara ID’s del GPS (1792), delPC2 (779), de la placa de adquisicion de datos(1280-1291) y del reset decomunicaciones (0).


– 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 deID’s tendra que estar vacıo (encontrado = false;).

– Funcion imprimir id() : En nuestro experimento no sera necesario visualizarlos ID’s, por lo que el return de esta funcion sera FALSE. Si se quieren visua-lizar por pantalla a traves de HyperTerminal los ID’s, simplemente tendremosque cambiar el return a TRUE.

– Funcion condicionfinal() : Configuraremos el return de la funcion a ’13’, quees 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 cuandopulsemos ’ENTER’ el nodo interpretara esta accion como final de condicion.

– Funcion id valido() : Los ID’s 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 configurar esta funcion, puesto quenunca la utilizaremos.

– Funcion config interfaz() : Al igual que en el experimento 3.3.2., para facilitarla transmision, recepcion y visualizacion de datos de la placa de adquisicionde datos en el PC1 utilizaremos esa misma interfaz. De modo que para habili-tarla tendremos que configurar el return de esta funcion a TRUE (solo en estenodo).

– Funcion condicion final can() : En esta funcion se han de asociar los ID’s 0,134, 135, 136, 137, 778 y 779 a ’\r’ como condicion final, y los ID’s 1286, 1287,1288, 1289 y 1792 a ’\n’ como condicion final.

Exclusivamente para este experimento, y con la finalidad 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 modificara la tasa de bits porsegundo del protocolo RS232, ascendiendola a 57600 bps.

PC2: Comunicacion con PC1.


– Funcion selecci on mensaje() : Este PC aceptara ID’s del PC1 (778) y del re-set de comunicaciones (0).


– 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 deID’s tendra que estar vacıo (encontrado = false;).

– Funcion imprimir id() : En nuestro experimento no sera necesario visualizarlos ID’s, por lo que el return de esta funcion sera FALSE. Si se quieren visua-lizar los ID’s por pantalla a traves del HyperTerminal, simplemente tendremosque cambiar el return a TRUE.

– Funcion condicionfinal() : Configuraremos el return de la funcion a ’13’, quees 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 cuandopulsemos ’ENTER’ el nodo interpretara esta accion como final de condicion.

– Funcion id valido() : Los ID’s 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 configurar esta funcion, puesto quenunca la utilizaremos.

– Funcion config interfaz() : En este nodo no es necesario utilizar la interfazpara enviar y recibir datos de la placa de adquisicion de datos por lo quedebemos configurar el return a False.

– Funcion condicion final can() : En esta funcion se ha de asociar los ID’s 0,134, 135, 136, 137, 778 y 779 a ’\r’ como condicion final, y los ID’s 1286,1287, 1288, 1289 y 1792 a ’\n’ como condicion final.

• El GPS se comporta como un dispositivo del tipo ’1’. Por ello, cuando vayamos aeditar el archivo ’funciones.c’ realizaremos los siguientes cambios:

– Funcion selecci on mensaje() : El GPS no tiene porque recibir paquetes, porlo que el vector de ID’s (filtro) ha de estar vacıo.

– Funcion id entrada id salida() : El GPS no recibe datos, ni ID’s de entrada, porlo que no necesita calcular las ID’s de salida. Esta funcion no sera necesariay no tendremos que configurarla 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 vaenviando paquetes cada cierto periodo. De forma que en esta funcion no hayque configurar nada.

– Funcion imprimir id() : Al igual que en la funcion anterior, no tenemos que con-figurar nada porque no recibimos mensajes de los que tengamos que imprimirlas ID’s.

– Funcion condicionfinal() : Configuraremos el return de la funcion a ’10’, quees un ’\n’ en el codigo ASCII. Esto es debido a que en el protocolo standard

Experimentos 105

NMEA, utilizado por el GPS, cuando se finaliza una transmision de datos elultimo caracter es ’\n’ (ver figura 2.37).

– Funcion id valido() : El GPS no envıa ID’s con el formato adecuado para CAN(por prioridades, tipos de paquetes, etc), por lo tanto el return de esta funciontendra que ser configurado a FALSE.

– Funcion set id vallido() : Como la funcion anterior ha sido configurada a FAL-SE, no hay identificadores para los paquetes CAN. Por ello, en esta funcionlo que haremos sera configurar como ID CAN del GPS el valor ’1792’. Esteidentificador proporciona a los paquetes del GPS dentro del protocolo CAN,prioridad media y tipo de mensaje de datos.

– Funcion config interfaz() : En este nodo no es necesario utilizar la interfazpara enviar y recibir datos de la placa de adquisicion de datos por lo quedebemos configurar el return a FALSE.


• La placa de adquisicion de datos se comporta como un dispositivo del tipo ’2’. Porello, cuando vayamos a editar el archivo ’funciones.c’ realizaremos los siguientescambios:

– Funcion selecci on mensaje() : Para la seleccion de mensajes en la placa deadquisicion de datos, y por lo tanto configuracion del vector de ID’s 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 envıan los chips ADIS16100 y ADIS16201no se encuentran las ID’s de los mensajes que se enviaran, se los hemosde agregar nosotros. Observando la tabla2.1 determinamos la relacion ID deentrada-salida. En nuestro caso esta relacion sera: id entrada + 1152LSB.

– Funcion mensaje a responder() : Se han de incluir los mismos ID’s que en lafuncion seleccion mensaje() menos el ID = ’ 0’, ya que no queremos responderal reset de las comunicaciones.

– Funcion imprimir id() : Debido a que los ID’s son necesarios en la placa deadquisicion de datos para saber cual sensor tiene que capturar los datos, de-bemos enviar (imprimir) el ID del dispositivo. Por ello, configuraremos el returna TRUE.

– Funcion condicionfinal() : Configuraremos el return de la funcion a ’10’, quees un ’\n’ en el codigo ASCII. Esto es debido a que en el protocolo estandarNMEA (utilizado en la placa de adquisicion de datos) cuando se finaliza unatransmision de datos el ultimo caracter es ’\n’ (ver figura 2.37).

– Funcion id valido() : Este dispositivo no envıa ID’s con el formato adecuadopara CAN (por prioridades, tipos de paquetes, etc), por lo tanto el return deesta funcion tendra que ser configurado a FALSE.

– Funcion set id valido() : Esta funcion no la tendremos que configurar, puestoque previamente en la funcion id entrada id salida() hemos calculando el IDde salida en funcion del ID de entrada.


– Funcion config interfaz() : En este nodo no es necesario utilizar la interfazpara enviar y recibir datos de la placa de adquisicion de datos, por lo quedebemos configurar el return a False.


Segundo. Una vez programados y re-configurados los nodos de comunicacion, tendre-mos que conectarlos entre ellos a traves del bus CAN. Al igual que en los experimentosdel nodo de comunicaciones (3.2.2.), debemos conectar los pines del UserTerminal decada nodo con los pines correspondientes del UserTerminal de los otros nodos: CANHdel nodo 1 al CANH del nodo 2, CANL del nodo 1 al CANL del nodo 2 y GND del nodo 1al GND del nodo 2 (Ver figura 3.22).

Es muy importante no olvidar las dos resistencias de 120 Ω en los extremos del bus entrelas lineas diferenciales CANH y CANL, para evitar que los datos sean devueltos en formade eco de los extremos del bus y se falsifiquen.

Figura 3.22: Esquema de conexion de los pines UserTerminal.

Tercero. Despues de realizar la union entre los nodos, se puede decir que tenemos listoel bus de comunicaciones entre nodos, por lo que seguidamente tendremos que conec-tar cada dispositivo con su nodo correspondiente (previamente configurado) y establecerası el enrutamiento de comunicaciones completo para nuestro experimento.

Experimentos 107

• Caso de los PC’s. Ambos utilizan el mismo sistema de conexion, ya que los dos secomunican con el nodo a traves del protocolo RS232. Por ello, en los dos nodos deestos dispositivos (PC1 y PC2), tendremos que indicar al codigo que el protocoloutilizado en las comunicaciones con el dispositivo es RS232, y no I2C o SPI.

Esta indicacion la podemos hacer mediante los interruptores de seleccion de pro-tocolo que disponen los nodos. Lo unico que tendremos que hacer es poner elinterruptor RS232 en ’ON’ y los interruptores I2C y SPI en ’OFF’ (Ver figura 3.2).

Una vez activado el interruptor correspondiente conectaremos el dispositivo al nodomediante un cable NULL MODEM. La forma de hacerlo es muy sencilla: Simple-mente conectaremos un extremo del cable al puerto serie de los PC’s, y en el otroextremo 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 elcable que tenemos del kit conectaremos el puerto 1 del GPS (conector RJ45) conel puerto serie (conector DB9) del nodo de comunicacion.

Es muy importante conectarlo al puerto 1 y no al 2 por que a diferencia del puerto1, el puerto 2 no utiliza el protocolo NMEA sino un protocolo exclusivo del fabricantepara su software, llamado UBX, que tambien esta disponible en el kit.

Los interruptores se tendran que configurar como en la figura 3.2, ya que el proto-colo 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 PC’s. Por ello, los pasos a seguirpara la conexion nodo-dispositivo sera exactamente igual que en el primer punto(caso de los PC’s). Conectaremos el DB9 de la placa de adquisicion de datos aun extremo del cable NULL MODEM, y el otro extremo va al nodo de comunicacio-nes. Colocaremos en ’ON’ el interruptor correspondiente a RS232, y en ’OFF’ loscorrespondientes a I2C y SPI.

Cuarto. Terminadas de enrutar todas las conexiones dispositivo-nodo y nodo-nodo, elsistema de comunicacion ya esta preparado (Ver figura 3.23).

Seguidamente lo que haremos sera volver conectar a la red electrica los nodos de comu-nicacion y encenderemos los dispositivos10. Si fuese necesario, podemos hacer un resetde un nodo dado pulsando el correspondiente boton ’Reset’.

Una vez todos los dispositivos estan preparados, es el momento de realizar las pruebasfinales y comprobar el funcionamiento del sistema. Pero antes, como ya sabemos, tantopara escribir como para recibir la informacion del PC1 y del PC2 nos ayudaremos delHyperTerminal de Windows.

Por lo tanto, el siguiente paso antes de realizar las pruebas es abrir este programa yconfigurarlo tal y como se presenta en la figura 3.1. Pero hay que tener muy presente ladiferencia en las velocidades: En el HyperTerminal del PC1 los bits por segundo en lugar

10En el caso de los PC’s, conectar HyperTerminal.


Figura 3.23: Montaje del experimento final.

de ser 4800 baudios han de ser 57600 baudios, tal y como se comento en la configuraciondel archivo ’tfc.c’ de este dispositivo (PC1).

Quinto. La puesta a punto de los dispositivos, nodos, conexiones y configuraciones estaterminada, por lo que siguiendo una serie de pasos que comentaremos a continuaciontestearemos la integridad del sistema.

La prueba que realizaremos, funcionalmente, trata de seguir minuciosamente los experi-mentos de los dispositivos comentados en los capıtulos anteriores, incluyendo exclusiva-mente para esta prueba un nuevo dispositivo, el GPS, que simplemente tendra que sermonitorizado por un PC (PC1). La particularidad de este experimento es que esta vezlos dispositivos ya probados individualmente ahora tendran que poder trabajar en paraleloentre ellos (integracion de dispositivos).

Como ya se ha indicado a lo largo de esta seccion, disponemos de un PC (PC1), con elque nos ayudaremos a la hora de monitorizar gran parte del trafico del sistema y comuni-carnos 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 informacionque el GPS transmite periodicamente. Por ello nada mas conectar el GPS y el HyperTer-minal deberıamos poder visualizar por pantalla algo similar a la figura 3.24.

Una vez comprobamos que la recepcion de datos del GPS es correcta, pasaremos acomprobar la comunicacion entre el PC1 y la placa de adquisicion de datos mientrasrecibimos paquetes de informacion del GPS simultaneamente. La forma de comunicarnoscon la placa de adquisicion de datos es la misma que en el experimento de la seccion3.3.2., ya que utilizamos la misma interfaz que nos facilita realizar peticiones y lecturas delos 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. Alrealizar movimientos de la placa de adquisicion de datos, la informacion procedente delos giroscopos sigue siendo coherente y corresponde a valores similares a los obtenidosen las pruebas individuales del dispositivo (Ver figura 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 condispositivos del tipo ’3’ nos ayudaremos del PC2.

Este tipo de dispositivos, como se define en la seccion 2.2.2.2., puede tanto responderordenes como enviar paquetes por CAN cuando se requiera.

Por ello, en este ultimo caso, cuando transmitamos por el PC2 previamente debemosescribir por el Hyperterminal el identificador del paquete que PC1 tiene programado comopaquete a aceptar en su vector de ID’s. Esta ID es ’779’, que corresponde en codigo ASCIIa los caracteres ’a’ y ’c’.

En el caso de la comunicacion recıproca, el identificador del paquete CAN que tendremosque escribir en el HyperTerminal del PC1 es ’778’, que corresponde a los caracteres delcodigo ASCII ’a’ y ’b’. El contenido de datos en estas transmisiones seran cadenas decaracteres que nosotros mismo escribiremos en el HyperTerminal, de la misma maneraque hacıamos en el experimento de la seccion 3.2.1. (Ver figura 3.26).

Con esta prueba, que se puede ver en el video ’prueba final’ incluido en el CD-ROM delTFC, se da por finalizado el capıtulo experimentos y podemos decir que todos los objetivosmarcados previamente al desarrollar del TFC se han visto cumplidos y superados concreces.

Podemos realizar esta afirmacion ya que:


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 dispositivosque siguen protocolos de comunicacion diferentes. Esta diferencia no es solo a nivelde la capa de enlace (nivel 2 del modelo OSI) sino tambien a nivel de la capa fısica(nivel 1 del modelo OSI).

• Se ha conseguido disenar una serie de dispositivos portatiles, ligeros y faciles deacoplar en vehıculos.

• Los errores obtenidos en el experimento de la placa de adquisicion de datos (ver3.3.1.) son consistentes y conocidos. Por lo tanto, se han podido calibrar los dispo-sitivos.

• Durante el desarrollo de los experimentos, los dispositivos han trabajado el 100 %del tiempo y no hemos sufridos caıdas de comunicacion en ningun momento, conlo que podemos decir que la fiabilidad del sistema es alta, y los dispositivos tienenuna buena continuidad de trabajo.

Experimentos 111

Figura 3.26: Resultado al conectar el GPS, la placa de adquisicion de datos y otro PC.

Conclusiones y Recomendaciones 113

CAPITULO 4. CONCLUSIONES YRECOMENDACIONES

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 recibidade estos dispositivos se adaptara para poderla enviar por un bus general, el busCAN. De esta forma se podran unir muchos tipos de dispositivos al bus CAN sinimportar 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 ejesdel vehıculo, siendo capaz de ir embarcado en el mismo. El profesor de la asig-natura “Navegacion Aerea, Cartografıa y Cosmografıa” (NACC) nos proporciono 4sensores (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 PC’s mas.

Una funcionalidad directa que se le va a dar a estos nodos de comunicaciones es la deutilizarlos 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 datossobre velocidad angular, inclinacion y acceleracion, un procesador central y unos servo-motores, entre otros.

De esta forma se podran observar los datos de posicion del vehıculo y guiarlo si hicierafalta. Los nodos de comunicaciones proporcionados realizarıan la funcion de unir todosestos dispositivos al bus CAN, controlando el envıo y recepcion de datos en cada uno deellos. La Placa de Adquisicion de Datos serıa el dispositivo que proporcionarıa los datosde velocidad angular, aceleracion y inclinacion del carrito.

A lo largo del TFC hemos ido siguiendo diferentes etapas. La primera etapa consistio enel estudio de todos los protocolos y del posible hardware a utilizar en cada una de laspartes de nuestro proyecto. Esta etapa resulto ser mucho mas larga de lo esperado, yaque tuvimos que aprender el funcionamiento de 4 protocolos que no habıamos visto a lolargo de nuestros estudios.

Una vez tuvimos claro los conceptos teoricos a utilizar, la siguiente etapa fue el desarrollohardware en ’protoboards’. Este es un paso obligatorio en todos los proyectos en los quese disena un dispositivo, ya que se tiene que comprobar el correcto funcionamiento decada 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 envıo y recepcion de datos delos 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 ser-vido para confirmar que los sensores cometen un error en las lecturas que realizan, y que


por tanto necesitan ser calibrados previamente. Despues de realizar un calculo estadısti-co, se han estimado los parametros de calibracion necesarios para cada sensor, y se hananadido 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 funcionamientotanto del software como del hardware sobre los dispositivos finales. El diseno de los PCBse tuvo que ajustar a unos criterios establecidos por los servicios encargados de realizarla placa. Decidimos utilizar componentes en su formato estandar, y no en formato SMD, yaque para la finalidad de estas placas el primer formato era adecuado, y ademas practica-mente todos los componentes seleccionados cumplen con la normativa RoHs (Restriccionde ciertas Sustancias Peligrosas en aparatos electricos y electronicos), respetando ası almedioambiente.

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 tamanoy peso de las placas.

Desgraciadamente, el funcionamiento de los sensores ADIS16201 no se ha podido com-probar debido a diferentes problemas comentados en el capitulo de experimentos. A pesarde este contratiempo, se diseno el software y el hardware necesario para poderlos utilizaren un futuro. Recomendamos que en el futuro se adquieran otros sensores de este tipopara ası corroborar el diseno del hardware y el software asociado.

Despues de comprobar el resultado de todos los experimentos, podemos decir que hemoscumplido con los objetivos planteados al principio. Aun ası, quisimos ver la flexibilidad delcomportamiento del sistema anadiendole otro dispositivo, un receptor GPS. Este GPS noslo ha proporcionado el profesor de “NACC”, y con el hemos podido ver que nuestro disenodel nodo de comunicacion no es individualizado, o sea, pensado solo para los PC’s y laPlaca de Adquisicion de Datos, sino que se pueden ir agregando dispositivos que utilicenlos protocolos SPI, I2C y/o RS232.

No obstante, creemos que se podrıan mejorar algunas partes de nuestro diseno. Un as-pecto lo hemos comentado anteriormente: Si se pretende incluir estos dispositivos enalgun vehıculo, como por ejemplo un pequeno UAV (Unmanned Aerial Vehicle), tendremosque reducir al maximo el tamano de las placas ya que lo importante en estos vehıculoses la denominada carga de pago o ’payload’. Una forma rapida y eficiente serıa utilizarcomponentes en formato SMD. Tambien se podrıan obviar partes de la placa como porejemplo los interruptores, led’s 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 adquisicionde datos “in situ”.

Otro aspecto a mejorar podrıa ser el funcionamiento del Reset. Nosotros lo hemos di-senado para que resetee todos los nodos que esten conectados al bus CAN. Un resetmas eficiente tendrıa que reiniciar unicamente el dispositivo con el que se estaba comuni-cando. Para ello se tendrıa que dotar de una cierta inteligencia al nodo de comunicaciones,


y esta opcion no entraba en los planes iniciales de nuestro proyecto. Es por ese motivoque, de cara a futuras versiones de nuestro nodo de comunicaciones, se podrıa tener encuenta este aspecto.

Para ir finalizando, hay que remarcar que este TFC en ocasiones se ha ido escribiendo conuna doble finalidad. En un primer plano, y con un sentido mas inmediato, describir todo eldesarrollo llevado a cabo durante el trabajo del dıa a dıa en el TFC; y en un segundo plano,y con un objetivo mas tutorial, crear un guion que ayude a los alumnos de aeronautica enla realizacion de las practicas de NACC. Ademas, debido a este segundo plano, este TFCpudiera servir como base de desarrollo y guıa para otros proyectos dentro de las areas dela aeronautica y las telecomunicaciones.

Animamos a futuros proyectistas a que se involucren en proyectos de este tipo, ya queeste es uno de los sectores con mas potencial, y posiblemente el que mas se desarrolledurante los proximos anos en Cataluna.


SIGLAS Y ABREVIATURAS

ACK : AcknowledgementADC: Analog to Digital ConverterCAL : CAN Application LayerCAN: Controller Area NetworkCCP/ECCP: Enhanced Capture/Compare/PWMCCS: Custom Computer Services inc.CMOS: Complementary Metal-Oxide SemiconductorCPHA: Clock PhaseCPOL: Clock PolarityCRC: Codigos de Redundancia CıclicaCS: Chip SelectCSMA/CD+AMP : Carrier Sense Multiple Access with Collision Detection and ArbitrationMessage PriorityCTS: Clear To SendDAC: Digital to Analog ConverterDCD: Carrier DetectDIN: Data In del SPIDOUT: Data Out del SPIDSR: Data Set ReadyDTR: Data Terminal ReadyEEPROM: Electrically-Erasable Programmable Read-Only MemoryEIA: Electronics Industry AssociationEUSART: Enhanced Universal Synchronous Asynchronous Receiver TransmitterGND: GroundGPS: Global Positioning SystemHS: High SpeedI2C: Inter-Integrated CircuitIC: Integrated CircuitsICD: In-Circuit-DebuggerID: IdentifierIDE: Entorno de Desarrollo IntegradoIMU: Unidad de Medidas InercialesINS: Inertial Navigation SystemISO: Organizacion Internacional para la EstandarizacionLLC : Logical Link ControlMAC: Media Access ControlMEMS: Micro Electro-Mechanical SystemsMISO: Master In/Slave OutMOSI: Master Out/Slave InMSSP: Master Synchronous Serial PortMCLR: Master ClearNOLVP: No Low Voltage ProgrammingNOWDT: No Match Dog TimerOSC: OsciladorOSEK: Offene Systeme und deren Schnittstellen fur die Elektronik in Kraftfahrzeugen


(.Open Systems and their interfaces for the Electronics in Motor vehicles”)OTP: One-Time ProgrammablePCB: Printed Circuit BoardPIC: Peripheral Interface ControllerPLL : Phase Lock LoopPSP: Parallel Slave PortPWM: Pulse-Width ModulationRAM: Random Access MemoryRD: Received DataRI: Ring IndicatorROM: Read-Only MemoryRS232: Recommended Standard 232RTS: Request To SendRX: RecepcionSCL: Serial ClockSCLK : Serial ClockSDA: Serial DataSDI: Serial Data InSDO: Serial Data OutSDS: Smart Distributed SystemSPI: Serial Peripheral InterfaceSS: Slave SelectTD: Transmitted DataTTL: Transistor-Transistor LogicTX: TransmissionUSB: Universal Serial BusXT: Cristal

BIBLIOGRAFIA 119

BIBLIOGRAF IA

Libros

[1] Gardner, N. PICmicro MCU C - An introduction to programming The Microchip PICin 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

Especificaciones de Protocolos

• CAN: can2spec.pdf

• RS232: rs-232.pdf

• I2C: 39340011.pdf

• SPI: S12SPIV3.pdf


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 Exer-cise 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


A.1.2. funciones.c


A.1.3. funciones.h


A.2. Placa de Adquisici on de Datos

A.2.1. adquisicion datos.c


A.2.2. funciones adis.c


A.2.3. funciones adis.h


A.3. Experimentos

A.3.1. experimentos spi.c


A.3.2. experimentos spi modo2.c


A.3.3. experimentos i2c.c


A.4. experimentos i2c modo2.c


A.5. experimento solo 1 adis.c

Diagramas de flujo 161

APENDICE B. DIAGRAMAS DE FLUJO

Antes de mostrar los diagramas de flujo de los codigos ’tfc.c’ y ’adquisicion datos’, vamosa indiciar el significado de cada uno de los sımbolos utilizados:

Figura B.1: Simbolos utilizados en el diagrama de flujo.

B.1. ’tfc.c’

Figura B.2: Diagrama de flujo del modulo ’Configuracion Nodo de Comunicaciones’.


Figura B.3: Diagrama de flujo del modulo ’Interrupcion Interruptores’.

Figura B.4: Diagrama de flujo del modulo ’Interrupcion CAN’.


Figura B.5: Diagrama de flujo del modulo ’Procesado Datos CAN’.


Figura B.6: Diagrama de flujo del modulo ’Interrupcion I2C y SPI’.

Figura B.7: Diagrama de flujo del modulo ’Interrupcion RS232’.


B.2. ’adquisicion datos’

Figura B.8: Diagrama de flujo del modulo Configuracion Placa Adquisicion de Datos.

Figura B.9: Diagrama de flujo del modulo Interrupcion RDA en ADIS16201.


Figura B.10: Diagrama de flujo del modulo Pedido y envio de datos en ADIS16201.

Layout 167

APENDICE C. LAYOUT

C.1. Nodo de comunicaciones

Figura C.1: Capa top del Layout del nodo de comunicacion.


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.


C.2. Placa de adquisici on 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.


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 DATASHEETDEL ADIS16100

A lo largo del proyecto tubimos varios problemas relacionados con el datasheet del ADIS16100que nos supuso bastante retraso. Queremos exponer estos problemas en este Anexo paraevitarle a futuros proyectistas estos problemas. Todos los errores encontrados estan en larevision B del datasheet.

Tambien querıamos comentar que estos errores no son suposiciones nuestras sino quedespues de comunicarselos al ingeniero responsable (Mark Looney, [email protected])del ADIS16100 en Analog Devices, nos dio la razon.

Los errores son los siguientes;

• En la figura 22 (pagina 12 de 16) se indica la configuracion del Modo de trabajo deSPI como Clock Polarity = 1 y Clock Phase = 0. Esta configuracion corresponde alMode=2 en la directiva #use spi(). Despues de muchas pruebas y ver que siempredaban resultados negativos, decidimos cambiar de modo de trabajo. La sorpresa fueal ver que con otro modo la comunicacion con el sensor funcionaba correctamente.Despues de visualizar la nueva comunicacion por un osciloscopio y ver el datasheetdel PIC18F2580 nos dimos cuenta que el correcto modo de trabajo era con ClockPolarity = 0 and Clock Phase = 0. Esto significa que el estado IDLE del reloj ha deser ’0’ y la transmision ha de ser en el primer flanco del reloj (en este caso en elflanco de bajada). Este es el caso del Mode = 1 en la directiva #use spi(). En eldatasheet del PIC18F2580 coincide con los parametros CKP=0 y CKE=1. Como sepuede ver en la figura D.1, la unica diferencia entre los dos modos es el estado IDLEdel reloj.

• En la Tabla 6 (pagina 13 de 16) se indica que el ’Bit Pattern’ para una velocidad an-gular de ’-0.2439’ y ’-0.4878’ es ’1111111111111111’ y ’1111111111111110’. Peroel correcto ’Bit Pattern’ es ’0000111111111111’ y ’0000111111111110’ porque losbits numero 15, 14, 13 y 12 son ’0’ obligatoriamente. Solo los 12 ultimos bits seconfiguran en Complemento a Dos.

• En la Tabla 7 (pagina 13 de 16) se indica que el ’Bit Pattern’ para una velocidad an-gular de ’-0.2439’ y ’-0.4878’ es ’0000111111111111’ y ’0000111111111110’. Peroel correcto ’Bit Pattern’ es ’0000011111111111’ y ’0000011111111110’ porque enesta 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 de85oC en Complemento a Dos es 585. Este ’Code’ corresponde a una temperaturade 115oC y esta no esta dentro del rango del propio ADIS16100. El correcto ’Code’para una temperatura de 85oC es 413 (Bit Pattern: ’0001000110011101’). No sehabıa tenido en cuenta que para el ’Code’ = 0 la temperatura es de 25oC y no 0oC.

• En la Tabla 9 (pagina 13 de 16) se indica que el ’Code’ para una temperatura de85oC en Complemento a Dos es 2633. Este ’Code’ corresponde a una temperatura


Figura D.1: Tabla con los diferentes modos de trabajo de SPI en el PIC18F2580.

de 115oC y esta no esta dentro del rango del propio ADIS16100. El correcto ’Co-de’ para una temperatura de 85oC es 2461 (Bit Pattern: ’0001100110011101’). Nose habıa tenido en cuenta que para el ’Code’ = 2048 la temperatura es de 25oCy no 0oC. Otro error en esta tabla es que el ’Bit Pattern’ para una temperatura de(25-0.1453)oC y (25-0.2906) es ’0001111111111111’ y ’0001111111111110’. El co-rrecto ’Bit pattern’ serıa ’0001011111111111’ y ’000101111111110’.

Lista de componentes y presupuesto del proyecto. 175

APENDICE E. LISTA DE COMPONENTES YPRESUPUESTO DEL PROYECTO.

En el proximo anexo se realiza una estimacion del valor de cada uno de los dispositivosdisenados, y se indican detalladamente caracterısticas como lugar de compra, referenciaen el lugar de compra, fabricante y precio de cada uno de los componentes para facilitarla fabricacion de mas unidades.

A continuacion se detallan los componentes del Nodo de comunicaciones en la tabla E.1y los componentes de la placa de adquisicion de datos en la tabla E.2.

176

Dis

eno

yco

nstr

ucci

onde

bus

deda

tos

yse

nsor

espa

rala

spr

actic

asde

NA

CC

Componente Fabricante Referencia Lugar de compra Cod. articulo e/unidad

Bloque de Alimentaci on

1 x Regulador TSC 7805 TO-220 Onda radio WR7805 0.19301 x Condensador ’Ariston’ Electrolıtico 47µF Onda radio JR47U25 0.02811 x Condensadores ’Ariston’ Ceramico 15pF Onda radio DS15P 0.01691 x Conec alimentacion ’Ariston’ Jack rosca 2,1mm Onda Radio A271 1,130

Bloque del Clock

1 x Reloj de cuarzo ’Ariston’ XB 2000 Onda radio XB2000 0.5502 x Condensadores ’Ariston’ Ceramico 15pF Onda radio DS15P 0.01691 x Resistencia 330Ω Onda radio PR253H3 0.0201

Bloque de Programaci on

1 x Conector RJ12 AMP RJ12 Onda radio TF2266 0.49901 x Pulsador ’Ariston’ Pulsador amarillo Onda radio P42A 0.27801 x Resistencia ’Ariston’ 47KΩ Onda radio PR2547k 0.02013 x Resistencia ’Ariston’ 1KΩ Onda radio PR251k 0.0201

Bloque de comunicaci on y selecci on de protocolos

1 x PIC18F4580 Microchip 18F4580I/P Microchip 4.721 x Transceiver RS232 Texas Inst MAX232 Onda radio MAX232 0.49995 x Condensador ’Ariston’ Ceramicos 100nF Onda radio CCS100K63 0.02801 x Condensador ’Ariston’ Electrolıtico 4,7µF Onda radio JR4U763 0.02481 x Conector ’Ariston’ DB9 hembra Onda radio CO2309H 0.54001 x Transceiver CAN Philips PCA82C251 Ebay 0.30001 x Resistencia ’Ariston’ 10Ω Onda Radio PR2510H 0.02012 x Interruptores ’Maruwa’ Dip negros Onda Radio DIP9301 0.25602 x Resistencia ’Ariston’ 4,7kΩ Onda Radio PR254k7 0.02013 x Interruptores ’Ariston’ DIP azules Onda Radio DIP501 0.32403 x LED’s ’Ariston’ Rojo/Amarillo/Verde Onda Radio WO1003RB/AB/VB 0.27906 x Resistencia ’Ariston’ 3,3KΩ Onda Radio PR253k3 0.02011 x UserTerminal Phoenix MPT 0’5/12-2’54 Onda Radio 1725753 3.0400TOTAL 14,6e

Tabla E.1: Lista de precios componentes nodo.

Listade

componentes

ypresupuesto

delproyecto.177

Componente Fabricante Referencia Lugar de compra Cod. articulo e/unidad

Placa Inercial

Bloque de Alimentaci on

1 x Regulador TSC 7805 TO-220 Onda radio WR7805 0.19301 x Condensador ’Ariston’ Electrolıtico 47µF Onda radio JR47U25 0.02811 x Condensadores ’Ariston’ Ceramico 15pF Onda radio DS15P 0.01691 x Conec alimentacion ’Ariston’ Jack rosca 2,1mm Onda Radio A271 1,130

Bloque del Clock

1 x Reloj de cuarzo ’Ariston’ XB 2000 Onda radio XB2000 0.5502 x Condensadores ’Ariston’ Ceramico 15pF Onda radio DS15P 0.01691 x Resistencia 330Ω Onda radio PR253H3 0.0201

Bloque de Programaci on

1 x Conector RJ12 AMP RJ12 Onda radio TF2266 0.49901 x Pulsador ’Ariston’ Pulsador negro Onda radio P42N 0.27801 x Resistencia ’Ariston’ 47KΩ Onda radio PR2547k 0.02013 x Resistencia ’Ariston’ 1KΩ Onda radio PR251k 0.0201

Bloque de comunicaci on

1 x PIC18F2580 Microchip 18F2580-I/SP Microchip 4.331 x Transceiver RS232 Texas Inst MAX232 Onda radio MAX232 0.49995 x Condensador ’Ariston’ Ceramicos 100nF Onda radio CCS100K63 0.02801 x Condensador ’Ariston’ Electrolıtico 4,7µF Onda radio JR4U763 0.02481 x Conector ’Ariston’ DB9 hembra Onda radio CO2309H 0.54001 x LED’s ’Ariston’ Rojo/Amarillo/Verde Onda Radio WO1003RB/AB/VB 0.27901 x Resistencia ’Ariston’ 3,3KΩ Onda Radio PR253k3 0.02011 x Conector Poste ’Ariston’ Macho 2,54 Dual Onda radio CO3080 0.3370Placa Sensores

1 x Regulador National LM1117 Amidata 535-8663 1.282 x Condensadores ’Ariston’ Tantalio 10µF Onda radio —1 x Conector Poste ’Ariston’ Macho 2,54 Dual Onda radio CO3080 0.33701 x Conector Poste ’Ariston’ Hembra 2 Dual Onda radio CO30972 2,11002 x Sensores Mems ’Analog” ADIS16100/PCB Farnell 1465267 74.352 x Sensores Mems ’Analog” ADIS16201/PCB Farnel 1274171 67,09TOTAL 295,46e

Tabla E.2: Lista de precios componentes placa de adquisicion.

Estudio previo. Ejercicios de familiarizacion con el protocolo CAN 179

APENDICE F. ESTUDIO PREVIO. EJERCICIOSDE FAMILIARIZACI ON 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 guıa resumen de las especificaciones ycaracterısticas de este. Ademas hemos seguido unos ejercicios para familiarizarnos conel IDE (Integrated Development Enviroment, software de desarrollo). Empezaremos porlos ejercicios mas basicos del kit y conforme vayamos avanzando nos iremos desviandohacia el bus.

F.1. Utilizando el software de desarrollo (IDE)Familiarizaci on.

Antes de nada hemos de establecer ciertos parametros de configuracion:

• Seleccionar el compilador para nuestro PIC. En estos ejercicios utilizaremos elPIC16F876A o el PIC18f4580. El primero de los PIC’s nos obliga a seleccionar elcompilador en modo PCM 14 bit. En el segundo hay que seleccionar el compiladoren modo PCH 16 bit.

• En la pestana ’compile’, donde se selecciona el compilador para nuestro PIC, hayque asegurarse de tener programado el chip (Program chip), con el boton ”LookupPart”. Testeamos el COMM, el ICD y la Tarjeta.

• Una vez confirmamos que todo es correcto podemos empezar con los ejercicios. Elejercicio 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 esteejercicio es aprender a programar correctamente el chip. Los pasos a seguir son:

1. Especificacion de la librerıa del chip, en nuestro caso la librerıa 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 ”ProgramChip”.


B. Si queremos Debugar el programa clickaremos en ”Debug / Enable Debugger”.Nos apareceran diferentes opciones ( Reset, Single Step, Go, Step Over). Conla opcion Reset nos aseguramos que la tarjeta esta preparada, con SingleStep podremos ir observando la evolucion del programa paso a paso ( entraen las funciones), con Go ejecutamos el programa y con Step Over lo que seconsigue es ejecutar una linea de codigo C.

El codigo del primer ejercicio es:

Las primeras 4 lıneas definen el hardware utilizado. En este caso un clock de 20MHz, unPIC18F4580 y el ICD Debugger. Los fuses significan 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.


Despues asociamos 3 variables ( LED VERDE, LED AMARILLO, LED ROJO) a sus res-pectivos pines(Ver figura F.1).

Figura F.1: Asociacion LED’s con los puertos RB del PIC

Para finalizar, en el main realizamos un bucle infinito indicando el tiempo de apagado y deencendido de los LED’s.(En el CD-ROM TFC, se encuentra el video de este ejercicio, conel nombre de ’video 1’).

F.3. PIC18F4580 como transmisor y MCP25050 para out-puts

En este ejercicio ejecutaremos el programa correspondiente al codigo F.2:

Las primeras 4 lıneas son parecidas a las del ejercicio anterior. En este caso hemos anadi-do el fuse NOPROTECT ( Code not protected from reading) y la librerıa para trabajar conCAN llamada ”can-18xxx8.c”.Como el programa esta disenado para enviar datos al Nodo D, definimos el identificadorde este nodo. En nuestro caso el identificador sera el 0x400.La funcion write 7 segment enviara los datos necesarios para que en el 7-segmentosse muestren los dıgitos correspondientes. El comando principal de esta funcion es elcan putd que es con el que se construyen paquetes CAN y se ponen en los buffers detransmision. A este comando se le pasan 6 variables que en este caso son las siguientes:

• WRITE REGISTER D ID – Identificador

• buffer – Datos

• 3 – Numero de bytes de datos

• 1– Prioridad


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 identificador a utilizar tenemos que ir a la Tabla 4.2 del datasheet delMCP25050. En nuestro caso queremos que sea ”Write Register” y por lo tanto el iden-tificador tendrıa que tal y como se puede ver en la figura F.3.

Figura F.3: Registro del MCP25050.

Es por eso que utilizamos el identificador 0x400 (que en binario acaba en tres 0’s).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 laprimera posicion se le indica el registro donde se guardara la informacion (0x1E), en el


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 quebits seran en los que nos fijemos (en este ejemplo no nos fijaremos en el ultimo bit que esel del punto en el 7-segmentos). El valor se selecciona de un vector llamado lcd seg en elque 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 todoslos filtros y mascaras para que todos los mensajes puedan ser recibidos con cualquieridentificador.Seguidamente utilizamos el comando can putd, En este caso se le ha pasado los siguien-tes parametros:

• 0x100 – Identificador

• 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 vacıo es necesario para que el MCP25050 pase del estado ”Power-Up” al estado ”Normal”.Seguidamente nos encontramos con un bucle infinito 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 programadebe mostrar un contador del 0 al 9 en el 7-segmentos.A partir de ahora creamos una librerıa llamado ccscana.c En esta anadiremos todas lasdefiniciones de hardware, #define’s y funciones.A continuacion queremos anadir al programa el codigo necesario para poder encender losled’s del nodo C. Nuestra finalidad es que el led verde se encienda cuando el contadorsea mas pequeno que 1, el led amarillo cuando el contador sea mas pequeno que 4 y elrojo cuando sea mas pequeno que 7. Para poder realizar esto, anadiremos el codigo dela figura F.4 en la librerıa ’ccscana.c’.

Figura F.4: Codigo a anadir en la librerıa ’ccscana.c’.

La funcion write c led persigue la misma finalidad que la del 7-segmentos, o sea, enviar unpaquete 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) yen los datos enviaremos un 0 o un 1 dependiendo si queremos apagar o encender el led.


Para finalizar anadimos el codigo siguiente;

El resultado se puede ver en la figura F.5 o tambien en ”Video 2”del CD-ROM.

Figura F.5: Resultado del ejercicio anterior

F.4. MCP25050 para inputs

La finalidad de este ejercicio es encender los led’s del Nodo C dependiendo de los botonesque se hayan apretado.La MCP25050 usada en el nodo C ha sido programada para enviar un frame cuandocualquier de los botones ha sido pulsado (GP4-GP6).El programa tendra que leer estos mensajes y encender los led’s correspondientes.


Para empezar anadiremos el ID de los botones en la librerıa ccscana.c:#define NODE C PUSHBUTTON ID 0x303En este caso hemos puesto el ID como 0x303. Con este ID estaremos en la opcion (0x30301100000001):

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 MCP2050cuando se ha pulsado algun boton. Primero utilizamos la funcion can kbhit(). Esta funcionretorna un TRUE si hay algun valor en los buffers de recepcion.Despues utilizamos la funcion can getd. Con esta funcion podemos coger un paquete delbus y nos devuelve:

• ID del transmisor del paquete – En nuestro caso serıa la de los PUSHBUTTON.

• Datos

• Longitud de los datos

• Estructura con algun tipo de informacion predeterminada.


Una vez tenemos los ID de los paquetes que circulan por el bus, nos fijamos que searealmente el que nos interesa (0X303). Y una vez tenemos nuestro paquete miramos enel campo datos que boton ha sido pulsado.Seguidamente queremos que al igual que los led’s del nodo C, los led’s 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 especificaciones del hardware utilizado ( PIC16F76A a 2,5MHz.)Se incluye la librerıa ”MCP251x.c” que es el controlador que utiliza la PIC16F76A.Seguidamente hacemos referencia a los pines donde estan conectados los LED’s y el IDdel nodo C (que es el que realiza los paquetes) (Ver figura 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 estecaso miramos que el paquete recibido sea el del nodo C y que el registro donde la in-


Figura F.7: LED’s del nodo C.

formacion se guarde sea el 0X1e (Output Latch Register). Una vez tenemos el paquetemiramos que boton era el que se habıa pulsado y encendemos el led correspondiente.(Resultado en el ”video 3” del CD-ROM)

Para finalizar hemos querido probar un programa made in casero. Su funcion es la deincrementar, decrementar o poner a 0 el contador del 7-segmentos con los botones.El programa utilizado es el de la figura F.8: (Resultado en el ”video 4” del CD-ROM)

F.5. MCP250XX para entradas anal ogicas

El MCP25050 puede estar configurado con hasta 4 entradas analogicas. El A/D es de 10bits.El siguiente programa enviara request frame’s pidiendo los resultados del A/d cada 100msy 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 modificando el potenciometrodel 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 (fijarseen el ultimo campo de la funcion can putd que es TRUE).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


Figura F.8: Codigo del ejercicio hecho por nosotros.


Figura F.9: Codigo del ejercicio del potenciometro.

can con 18f4580

Documents

adquisicion datos

canbus y

datos y sensores para

datos por bus

placa adquisicion

compilador ccs y

diseno y construccion

comunicaciones en canbus