Desarrollo del firmware de control de los nodos de una plataforma experimental de WSN

ESCUELA DE INGENIERÍA DE TELECOMUNICACIÓN Y ELECTRÓNICA TRABAJO FIN DE GRADO DESARROLLO DEL FIRMWARE DE CONTROL DE LOS NODOS DE UNA PLATAFORMA EXPERIMENTAL DE WSN Titulación: Grado en Ingeniería en Tecnologías de la Telecomunicación Mención: Sistemas Electrónicos Autor: Ricardo Antonio Rios Peña Tutores: Dr. Roberto Esper-Chaín Falcón Dr. Félix B. Tobajas Guerrero Fecha: Julio 2015 ESCUELA DE INGENIERÍA DE TELECOMUNICACIÓN Y ELECTRÓNICA TRABAJO FIN DE GRADO DESARROLLO DEL FIRMWARE DE CONTROL DE LOS NODOS DE UNA PLATAFORMA EXPERIMENTAL DE WSN HOJA DE FIRMAS Alumno Fdo.: Ricardo Antonio Rios Peña Tutor Tutor Fdo.: Dr. Roberto Esper-Chaín Falcón Fdo.: Dr. Félix B. Tobajas Guerrero Fecha: Julio 2015 ESCUELA DE INGENIERÍA DE TELECOMUNICACIÓN Y ELECTRÓNICA TRABAJO FIN DE GRADO DESARROLLO DEL FIRMWARE DE CONTROL DE LOS NODOS DE UNA PLATAFORMA EXPERIMENTAL DE WSN HOJA DE EVALUACIÓN Calificación: ___________________________ Presidente Fdo.: Presidente Vocal Secretario/a Fdo.: Vocal Fdo.: Secretario Fecha: Julio 2015 Ricardo Antonio Rios Peña Página | i Índice de Contenidos CAPÍTULO 1: INTRODUCCIÓN .......................................................................................................... 1 1.1 ANTECEDENTES. ........................................................................................................................ 1 1.2 OBJETIVOS. ............................................................................................................................... 5 1.3 SOLUCIÓN ADOPTADA. ................................................................................................................ 7 1.4 ESTRUCTURA DE LA MEMORIA. ..................................................................................................... 8 CAPÍTULO 2: DESCRIPCIÓN HARDWARE ........................................................................................ 11 2.1 INTRODUCCIÓN. ...................................................................................................................... 11 2.2 MÓDULOS SENSORES INALÁMBRICOS. .......................................................................................... 11 2.3 MICROCONTROLADOR ATMEL AT90CAN. ................................................................................... 15 2.3.1 Descripción general. .................................................................................................. 15 2.3.2 La arquitectura AVR. .................................................................................................. 17 2.3.3 Diagrama de bloques del microcontrolador AT90CAN128. ...................................... 19 2.4 FUNCIONALIDADES DEL MICROCONTROLADOR AT90CAN128. ........................................................ 22 2.4.1 Puertos de entrada/salida de propósito general (GPIO). .......................................... 23 2.4.1.1 Configuración del Pin. ......................................................................................................... 25 2.4.2 USART. ....................................................................................................................... 27 2.4.2.1 Generación de Reloj. ........................................................................................................... 29 2.4.2.2 Formato de la trama. .......................................................................................................... 31 2.4.2.3 Transmisor. ......................................................................................................................... 32 2.4.2.4 Receptor. ............................................................................................................................ 34 2.4.2.5 Descripción de registros. ..................................................................................................... 35 2.4.3 CAN. ........................................................................................................................... 40 2.4.3.1 Protocolo CAN. .................................................................................................................... 41 2.4.3.2 Controlador CAN. ................................................................................................................ 44 2.4.3.3 Objetos de mensajes (MOb). .............................................................................................. 45 2.4.3.4 Interrupciones. .................................................................................................................... 48 2.4.3.5 Descripción de los registros generales. ............................................................................... 48 2.4.3.6 Descripción de los registros MOb. ...................................................................................... 52 2.4.4 Bootloader. ................................................................................................................ 57 CAPÍTULO 3: DESARROLLO SOFTWARE .......................................................................................... 63 3.1 INTRODUCCIÓN. ...................................................................................................................... 63 Página | ii Ricardo Antonio Rios Peña 3.2 DESCRIPCIÓN GENERAL. ............................................................................................................. 63 3.3 SISTEMA DE INTERRUPCIONES. .................................................................................................... 66 3.3.1 Vector de interrupción CAN. ...................................................................................... 66 3.3.2 Vector de interrupción USART: transmisión. ............................................................. 68 3.3.3 Vector de interrupción USART: recepción. ................................................................ 71 3.4 BIBLIOTECA CAN. ..................................................................................................................... 74 3.4.1 Configuración previa. ................................................................................................. 75 3.4.2 Funciones públicas: configuración del bus. ............................................................... 75 3.4.3 Funciones públicas: transmisión. ............................................................................... 76 3.4.4 Funciones públicas: recepción. .................................................................................. 77 3.5 APLICACIÓN ROUTER. ................................................................................................................ 78 3.6 APLICACIÓN BOOTLOADER. ......................................................................................................... 83 CAPÍTULO 4: RESULTADOS.............................................................................................................. 91 CAPÍTULO 5: CONCLUSIONES Y LÍNEAS FUTURAS ........................................................................ 101 5.1 CONCLUSIONES. ..................................................................................................................... 101 5.2 LÍNEAS FUTURAS. ................................................................................................................... 103 REFERENCIAS BIBLIOGRÁFICAS ........................................................................................................ 105 PLIEGO DE CONDICIONES ................................................................................................................. 107 PL.1 CONDICIONES HARDWARE. .................................................................................................. 107 PL.2 CONDICIONES SOFTWARE. ................................................................................................... 107 PRESUPUESTO .................................................................................................................................. 109 P.1 RECURSOS MATERIALES. ........................................................................................................... 109 P.1.1 Recursos Hardware. ................................................................................................. 109 P.1.2 Recursos Software. .................................................................................................. 110 P.2 TRABAJO TARIFADO POR TIEMPO EMPLEADO. ............................................................................... 111 P.3 MATERIAL FUNGIBLE. .............................................................................................................. 112 P.4 COSTES DE REDACCIÓN DEL TRABAJO FIN DE GRADO. .................................................................... 113 P.5 DERECHOS DE VISADO DEL COITT.............................................................................................. 114 P.6 COSTES DE TRAMITACIÓN Y ENVÍO. ............................................................................................. 114 P.7 APLICACIÓN DE IMPUESTOS. ..................................................................................................... 115 ANEXO I. CONTENIDO DEL CD-ROM ............................................................................................ 117 A.I.I ESTRUCTURA DEL CD-ROM. ....................................................................................................... 117 Ricardo Antonio Rios Peña Página | iii Índice de Figuras FIGURA 1.1. WIRELESS SENSOR NETWORK .................................................................................................................. 2 FIGURA 1.2. CONFIGURACIÓN EN BUS ........................................................................................................................ 5 FIGURA 1.3. ESTRUCTURA DE LA PLATAFORMA ............................................................................................................. 7 FIGURA 2.1. PCB DE LOS MÓDULOS SENSORES INALÁMBRICOS ...................................................................................... 12 FIGURA 2.2. CHIP FT232R .................................................................................................................................... 13 FIGURA 2.3. ESQUEMÁTICO DEL CIRCUITO USB A UART ............................................................................................. 13 FIGURA 2.4. CHIP SN65HVD255 .......................................................................................................................... 14 FIGURA 2.5. CONECTOR CAN................................................................................................................................. 14 FIGURA 2.6. ESQUEMÁTICO DEL CIRCUITO TRANSCEPTOR DEL CAN ................................................................................ 15 FIGURA 2.7. ATMEL AT90CAN128 MICROCONTROLLER ............................................................................................ 17 FIGURA 2.8. DIAGRAMA DE BLOQUES DEL MICROCONTROLADOR AT90CAN128 ............................................................. 20 FIGURA 2.9. ARQUITECTURA AVR ........................................................................................................................... 22 FIGURA 2.10. ESQUEMÁTICO EQUIVALENTE DE UN PIN I/O .......................................................................................... 23 FIGURA 2.11. I/O DIGITAL GENERAL ....................................................................................................................... 25 FIGURA 2.12. DESCRIPCIÓN DE REGISTROS DE LOS PUERTOS I/O ................................................................................... 26 FIGURA 2.13. DIAGRAMA DE BLOQUES DE LA USART ................................................................................................. 28 FIGURA 2.14. LÓGICA DE GENERACIÓN DE LA SEÑAL DE RELOJ DE LA USART ................................................................... 30 FIGURA 2.15. ECUACIONES PARA CALCULAR LA CONFIGURACIÓN DE LA TASA DE BAUDIOS ................................................... 31 FIGURA 2.16. FORMATO DE TRAMA ......................................................................................................................... 31 FIGURA 2.17. REGISTRO DE DATOS I/O DE LA USART ................................................................................................ 35 FIGURA 2.18. REGISTRO DE ESTADO Y DE CONTROL A ................................................................................................. 36 FIGURA 2.19. REGISTRO DE ESTADO Y DE CONTROL B ................................................................................................. 37 FIGURA 2.20. REGISTRO DE ESTADO Y DE CONTROL C ................................................................................................. 38 FIGURA 2.21. CONFIGURACIÓN DEL BIT UMSELN ...................................................................................................... 38 FIGURA 2.22. CONFIGURACIÓN DE LOS BITS UPMN ................................................................................................... 39 FIGURA 2.23. CONFIGURACIÓN DEL BIT USBSN ......................................................................................................... 39 FIGURA 2.24. CONFIGURACIÓN DE LOS BITS UCSZN ................................................................................................... 40 FIGURA 2.25. TRAMA CAN ESTÁNDAR ..................................................................................................................... 42 FIGURA 2.26. TRAMA CAN EXTENDIDA .................................................................................................................... 43 FIGURA 2.27. ARBITRAJE DEL BUS ........................................................................................................................... 44 FIGURA 2.28. ESTRUCTURA DEL CONTROLADOR CAN ................................................................................................. 45 Página | x Ricardo Antonio Rios Peña Ricardo Antonio Rios Peña Página | xi Acrónimos ACK ACKnowledge ADC Analog-to-Digital Converter ALU Arithmetic Logic Unit AS Application Section ASIC Aplication-Specific Integrated Circuit BLS Bootloader Section BS Back Space CAN Controller Area Network CD-ROM Compact Disc Read-Only Memory CMOS Complementary Metal Oxide Semiconductor COITT Colegio Oficial de Ingenieros Técnicos de Telecomunicación CPU Central Processing Unit CR Carry Return CRC Cyclic Redundant Check DLC Data Length Code DSP Digital Signal Processor EEPROM Electrically Erasable Programmable Read-Only Memory EITE Escuela de Ingeniería de Telecomunicación y Electrónica EOF End Of Frame FIFO First In First Out FPGA Field Programmable Gate Array Página | xii Ricardo Antonio Rios Peña GPIO General Purpose Input Output I2C Inter-Integrated Circuit IDE IDentifier Extension IEEE Institute of Electrical and Electronics Engineers IFS Intermission Frame Space IGIC Impuesto General Indirecto Canario ISO International Organization for Standardization JTAG Joint Test Action Group LF Line Feed LLC Logical Link Control MAC Medium Access Control MCU MicroController Unit MIPS Million Instructions Per Second MOb Message Object OSI Open Systems Interconnection PC Program Counter PCB Printed Circuit Board PLS PhysicaL Signalling PWM Pulse Width Modulation QFN Quad Flat No Leads RAM Random Access Memory RF Radio Frecuencia RISC Reduced Instruction Set Computer Ricardo Antonio Rios Peña Página | xiii RTC Real Time Counter RTR Remote Transmission Request SOF Start Of Frame SPI Serial Peripheral Interface SPM Store Program Memory SRAM Static Random Access Memory TFG Trabajo Fin de Grado TQFP Thin Quad Flat Pack ULPGC Universidad de Las Palmas de Gran Canaria USB Universal Serial Bus USART Universal Synchronous Asynchronous serial Receiver and Transmitter WSN Wireless Sensor Network Página | xiv Ricardo Antonio Rios Peña Introducción Ricardo Antonio Rios Peña Página | 1 Capítulo 1: Introducción 1.1 Antecedentes. Los avances en la tecnología de sistemas micro-electrónicos, comunicaciones inalámbricas, y electrónica digital han posibilitado el desarrollo de nodos sensores de bajo coste, reducido consumo de potencia y mínimo tamaño, que se comunican a distancia. Estos pequeños nodos sensores inalámbricos se fundamentan en la idea de redes de sensores basadas en el esfuerzo conjunto de un gran número de nodos [1, 2]. Una red de sensores inalámbricos (Wireless Sensor Network, WSN) consiste en una serie de nodos sensores distribuidos espacialmente con el objetivo de medir magnitudes físicas, como pueden ser sonido, temperatura, presión, etc. Dichos nodos sensores se comunican entre sí de forma inalámbrica con el fin de transmitir la información medida, por lo general a una unidad de procesamiento central, o bien para llevar a cabo algunas tareas de coordinación, como se representa en la Figura 1.1. Los componentes hardware más usuales en un nodo sensor incluyen un procesador empotrado, un transceptor de radio, fuente de alimentación y uno o más sensores [1, 2]. Introducción Página | 2 Ricardo Antonio Rios Peña Figura 1.1. Wireless Sensor Network En un nodo sensor, la funcionalidad del procesador empotrado es la de programar tareas, procesar datos y controlar el funcionamiento de los otros componentes hardware. Los tipos de procesadores empotrados que pueden ser usados en un nodo sensor incluyen Microcontroladores (MicroController Unit, MCU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA) y Aplication-Specific Integrated Circuit (ASIC). De entre todas estas alternativas, los Microcontroladores han sido los más usados en la práctica debido a su flexibilidad para conectar con otros dispositivos, así como su reducido precio [3]. El transceptor es el responsable de la comunicación inalámbrica del nodo sensor. Las opciones disponibles como medio de comunicación inalámbrico son Radio Frecuencia (RF), Láser, e Infrarrojo. De ellas las comunicaciones basadas en RF encajan mejor en la mayoría de aplicaciones de WSN [3]. En un nodo sensor, el consumo de energía se produce principalmente debido a las tareas de detección, comunicación y procesamiento de los datos. Así, se requiere mayor energía para la comunicación que para el resto de las tareas, siendo las baterías la principal fuente de energía para los nodos sensores, por lo que, debido a su limitada capacidad, Introducción Ricardo Antonio Rios Peña Página | 3 minimizar el consumo de energía siempre es un aspecto clave durante las operaciones de los nodos en las WSNs [3]. Un sensor es un dispositivo hardware que ante un cambio en una magnitud física, como pueden ser temperatura, presión o humedad, genera como respuesta una señal eléctrica medible. La señal eléctrica analógica detectada por los sensores es digitalizada por un conversor analógico-digital (Analog-to-Digital Converter, ADC) y enviada al procesador empotrado para un procesamiento posterior. Debido a que un nodo sensor es un dispositivo micro-electrónico alimentado por una fuente de energía limitada, los sensores acoplados deben ser igualmente de reducido tamaño y tener muy poco consumo de energía. Un nodo sensor puede tener varios tipos de sensores integrados dentro, o conectados al nodo [3]. En los últimos años, las redes de sensores inalámbricos han ganado mucha popularidad, experimentando un gran desarrollo y despliegue acrecentado conforme al aumento de las capacidades tecnológicas de fabricación de sistemas integrados y al desarrollo de nuevos estándares y estructuras de comunicación. La base de este auge proviene de maximizar la utilización de una de sus principales ventajas: la movilidad. Haciendo uso de este tipo de redes, se elimina la necesidad de usar cables para la transferencia de datos entre dispositivos, dotando de una gran flexibilidad a la red, y por tanto, incrementando su eficiencia y productividad, independientemente del lugar donde ésta se encuentre instalada. La flexibilidad en el despliegue es una propiedad fundamental de los dispositivos que empleen este tipo de redes, y que está cada vez más presente en la sociedad actual [1-3]. Las redes de sensores inalámbricos presentan un gran potencial para aplicaciones en escenarios como el seguimiento y la vigilancia de objetivos militares, atenuación de desastres naturales, monitorización biomédica de la salud, exploración en entornos Introducción Página | 4 Ricardo Antonio Rios Peña peligrosos y detección de seísmos. En el seguimiento y vigilancia de objetivos militares, una WSN puede ayudar en la detección de intrusos e identificación. En desastres naturales, los nodos sensores pueden detectar el entorno para predecir desastres con antelación a que ocurran. En aplicaciones biomédicas, la implantación quirúrgica de sensores ayudan a monitorizar la salud del paciente. Para la detección de seísmos, el despliegue de sensores ad-hoc a lo largo del área volcánica puede detectar el desarrollo de terremotos y erupciones [2]. Sin embargo, este tipo de redes también presentan una serie de desventajas, siendo una de ellas el que, a pesar de que emplean tecnología inalámbrica, la programación y configuración de los nodos debe realizarse por lo general con el dispositivo físicamente conectado. Esto implica que en redes que sean relativamente extensas puede resultar muy costoso en tiempo el ir programando nodo por nodo, sin tener en cuenta que la red puede estar desplegada en una superficie de gran tamaño, por lo que se requerirá estar desplazándose de un nodo a otro para realizar dicha programación [4, 5]. De modo similar, se hace muy difícil la depuración y el control de la WSN, ya que cuando se detecta que ocurre algún fallo en alguno de los nodos, la única forma que habría de comprobar qué es lo que está pasando, es desplazarse al lugar donde se encuentra dicho nodo y realizar una depuración in situ. Las desventajas que esto trae consigo son evidentes, ya que puede representar un trabajo muy engorroso tener que ir de nodo en nodo verificando su funcionamiento. Si además se dispone de una red ya desplegada, el proceso de detectar el error, corregirlo y verificar nuevamente el funcionamiento, lo que seguramente será necesario realizar varias veces, se puede fácilmente estimar que consumirá un tiempo significativo [4, 5]. Actualmente existen alternativas que permiten programar los nodos de forma inalámbrica, si bien esta solución no es demasiado eficaz, ya que si ocurre algún problema Introducción Ricardo Antonio Rios Peña Página | 5 con la transmisión, dicha programación no se llevará a cabo y no será posible saber qué es lo que ha pasado. En este trabajo se pretende dar una solución a los problemas comentados anteriormente con el desarrollo de una red experimental de sensores inalámbricos [4, 5]. 1.2 Objetivos. El objetivo principal del presente Trabajo Fin de Grado (TFG) consiste en desarrollar una infraestructura que facilite la experimentación en el desarrollo de redes de sensores inalámbricos. Una de las principales características de la red experimental de sensores inalámbricos relacionada con este trabajo será que estos sensores estarán conectados mediante un bus común a un Servidor central (Host), siendo el bus utilizado CAN (Controller Area Network) (Figura 1.2). Figura 1.2. Configuración en bus Los sensores proporcionarán constantemente información de su estado al servidor, con lo cual se busca facilitar las tareas de depuración y control que pueden resultar complejas en caso de que la red no esté cableada, ya que habría que ir nodo por nodo verificando su funcionamiento. Además, dichos informes de los nodos se almacenarán en Descripción Hardware Página | 12 Ricardo Antonio Rios Peña Figura 2.1. PCB de los módulos sensores inalámbricos Enmarcados con los distintos bloques de colores se han señalado los elementos que intervienen directamente en este TFG. En color rojo se ha señalado la zona donde va colocado el microcontrolador AT90CAN128. El color negro señala el pin con el cual se indica al microcontrolador que se debe iniciar en modo bootloader. El color azul corresponde a la conexión USB (Universal Serial Bus) con su correspondiente interfaz hacia la USART. Por último en color verde están los elementos relacionados con el CAN. El pin para seleccionar el modo bootloader se encuentra ubicado en uno de los puertos de expansión de la placa. Colocando un jumper entre este pin y masa, se le indica al microcontrolador que se debe iniciar en modo bootloader, en caso contrario saltará directamente a la aplicación de usuario. El conector USB está compuesto por cuatro pines. Uno correspondiente a la alimentación, otro para masa y los dos restantes corresponden al par diferencial de datos. A través de este conector se puede alimentar a toda la placa. La señal de datos se lleva a un chip que hace de interfaz entre USB y la USART. El FT232R es un chip que simplifica los Descripción Hardware Ricardo Antonio Rios Peña Página | 13 diseños USB a serie, reduce el número de componentes externos necesarios al integrar en el dispositivo una EEPROM, resistencias de terminación USB y un circuito integrado de reloj que no requiere de cristal externo. En la Figura 2.2 se presenta una imagen del chip FT232R en su formato QFN (Quad Flat No Leads) [6]. Figura 2.2. Chip FT232R En la Figura 2.3 se puede observar el esquemático de cómo está conectado este chip con el microcontrolador y con el conector USB. Por un lado se tiene la señal de datos USB (USBDP, USBDM), que una vez pasa por la interfaz se convierte en las señales del transmisor y receptor de la USART (TXD, RXD). Figura 2.3. Esquemático del circuito USB a UART Descripción Hardware Página | 14 Ricardo Antonio Rios Peña El microcontrolador AT90CAN128 dispone de un controlador pero no de un transceptor CAN, por lo tanto es necesario añadirlo de forma externa. El dispositivo utilizado en este caso es el chip SN65HVD255, del cual se puede observar una imagen en la Figura 2.4. Este es un chip que cumple con los requerimientos del estándar ISO 11898, pudiendo soportar hasta 1Mbps de velocidad en buses altamente cargados y proporciona varias características de protección que permiten aumentar la robustez del bus [7]. Figura 2.4. Chip SN65HVD255 En la Figura 2.5 se puede observar la posición del transceptor externo que se ha añadido en los módulos, así como la de los pines correspondientes a las conexiones de CAN_H y CAN_L, en los cuales se ha colocado una clema para facilitar su conexionado. Figura 2.5. Conector CAN Descripción Hardware Ricardo Antonio Rios Peña Página | 15 Por último, se incluye en la Figura 2.6 el esquemático de cómo se ha realizado el conexionado del transceptor. En ella se puede observar cómo por un lado se tienen las señales de transmisión y recepción CAN del microcontrolador que una vez pasan por el transceptor se convierten en CAN_H y CAN_L como establece el estándar. Destacar también que se dispone de un jumper con el cual se establece si se añade o se quita la terminación resistiva, dependiendo si se trata de un nodo final o uno intermedio respectivamente. Figura 2.6. Esquemático del circuito transceptor del CAN 2.3 Microcontrolador Atmel AT90CAN. 2.3.1 Descripción general. El microcontrolador Atmel AT90CAN32/64/128 es un microcontrolador CMOS de 8 bits de propósito general y bajo consumo [8]. El diseño de su núcleo está basado en la arquitectura RISC (Reduced Instruction Set Computer) de AVR. La arquitectura del núcleo AVR combina la utilización de un amplio repertorio de instrucciones con un banco de 32 registros de propósito general. Estos 32 registros están directamente conectados a la ALU (Arithmetic Logic Unit), permitiendo realizar operaciones entre dos registros independientes en un sólo ciclo de reloj. Descripción Hardware Página | 16 Ricardo Antonio Rios Peña En este TFG se hará uso de la versión AT90CAN128, la cual consta de 128KBytes de memoria de programa, implementados en una memoria tipo Flash, 4KBytes de memoria tipo EEPROM (Electrically Erasable Programmable Read-Only Memory), 4KBytes de memoria SRAM (Static Random Access Memory). Además cuenta con 53 líneas de entrada/salida de propósito general (General Purpose Input Output, GPIO), 32 registros de propósito general, un controlador CAN, contador de tiempo real (Real Time Counter, RTC), 4 Timers/Contadores flexibles con modo de comparación y PWM (Pulse Width Modulation). También cuenta con hardware USART (Universal Synchronous Asynchronous serial Receiver and Transmitter), hardware SPI (Serial Peripheral Interface), una interfaz serie de dos cables (Inter-Integrated Circuit, I2C), conversor analógico-digital (Analog to Digital Converter, ADC) de 8 canales y resolución de 10 bits con la opción de incluir una etapa de entrada diferencial con ganancia programable, Watchdog programable con oscilador interno, interfaz JTAG (Joint Test Action Group) para test conforme al estándar IEEE 1149.1, también usada para acceder al sistema de depuración en chip y la programación. El sistema está dotado con 5 modos distintos de ahorro de energía. El modo Idle detiene la CPU (Central Processing Unit) mientras permite que la RAM, timer/counters, puertos SPI/CAN y el sistema de interrupciones siga funcionando. El modo Power-down almacena el contenido de los registros pero detiene el oscilador, deshabilitando el resto de funciones del chip hasta la próxima interrupción o reset. En el modo Power-save, el timer asíncrono continua contando, permitiendo al usuario mantener un timer de referencia, mientras que el resto del dispositivo está inactivo. El bloque conversor analógico-digital dispone de un modo especial de operación, ADC Noise Reduction, que desconecta todo el hardware del sistema, excepto el contador asíncrono, con el fin de realizar una conversión fiable, aportando el mínimo ruido posible a la medida realizada. El último modo es el Standby, en el que el oscilador, ya sea basado en cristal o un resonador, continúa operando mientras que el resto del dispositivo está inactivo, lo que permite un arranque muy rápido del dispositivo a la vez que un bajo consumo de potencia. Descripción Hardware Ricardo Antonio Rios Peña Página | 17 En la Figura 2.7 se puede observar una imagen del microcontrolador Atmel AT90CAN128 en el formato TQFP (Thin Quad Flat Pack), que es el que ha sido utilizado, el cual consta de 64 pines. Figura 2.7. Atmel AT90CAN128 Microcontroller 2.3.2 La arquitectura AVR. La arquitectura AVR es una modificación de la arquitectura RISC de 8 bits existente para microcontroladores. Fue desarrollada por Atmel en 1996; concretamente, fue inventada por dos estudiantes del Norwegian Institute of Technology, y posteriormente refinada y desarrollada en Atmel Norway, la empresa subsidiaria de Atmel, fundada entonces por los dos diseñadores del chip. Los de AVR fueron los primeros microcontroladores que empleaban una memoria Flash integrada para almacenar el programa [9-11]. AVR es una CPU de arquitectura Harvard, en la que la memoria de programa y la memoria de datos se encuentran separadas físicamente. Sin embargo, existen una serie de instrucciones especiales que permite el acceso a la memoria de programa durante la ejecución del mismo. Descripción Hardware Página | 18 Ricardo Antonio Rios Peña La arquitectura AVR está diseñada para soportar frecuencias de reloj de hasta 20MHz, pudiendo llegar algunos dispositivos hasta los 32MHz. Sin embargo, las aplicaciones que requieran un bajo consumo requerirán menores frecuencias de reloj. Algunas series de microcontroladores AVR integran un oscilador en el chip, eliminando así la necesidad de utilizar una fuente de reloj externa, o un circuito resonador. Con el fin de incrementar las posibilidades del sistema, también se incluye un prescaler para la señal de reloj, de forma que es posible dividir la frecuencia de reloj principal por un valor máximo de 256. El valor del prescaler puede ser configurado en el momento de la programación o durante la ejecución de la aplicación, aportando máxima flexibilidad. Casi todas las instrucciones ejecutadas en el AVR duran 1 ciclo de reloj, lo que permite realizar 1 MIPS (Million Instructions Per Second) por MHz. En cuanto a memoria, tanto Flash como EEPROM y SRAM, se encuentran integradas en el hardware disponible en el chip. De este modo se elimina la necesidad de emplear memorias externas. Sin embargo, algunos dispositivos disponen de un bus, que permite hacer uso de una memoria externa, estando ésta mapeada en la memoria del chip. En la mayoría de las variantes de la arquitectura AVR, los 32 registros de uso general se encuentran mapeados en las primeras 32 direcciones de memoria, y los 64 registros de entrada-salida se encuentran mapeados consecutivamente a los de uso general. De este modo, la concatenación de los 32 registros de uso general con los registros de entradasalida y la memoria de datos conforman un espacio de direcciones unificado, accesible mediante operaciones de carga/almacenamiento. Las CPU AVR poseen un pipeline simple de 2 etapas (cargar y ejecutar), haciendo posible que la mayor parte de las instrucciones se ejecuten en un solo ciclo de reloj. Esta característica particular hace que esta arquitectura resulte significativamente más rápida frente a otros microcontroladores de 8 bits con otras arquitecturas. Descripción Hardware Ricardo Antonio Rios Peña Página | 19 AVR fue diseñado desde un comienzo para la ejecución eficiente de código C compilado. Como este lenguaje utiliza punteros para el manejo de variables en memoria, los tres últimos pares de registros internos del procesador AVR se usan como punteros de 16 bits al espacio de memoria externa, bajo los nombres X, Y y Z. Este compromiso se aplica en arquitecturas de ocho bits debido a que el tamaño de palabra de 8 bits tan solo puede direccionar 256 registros. 2.3.3 Diagrama de bloques del microcontrolador AT90CAN128. En la Figura 2.8 se muestra el diagrama de bloques completo del microcontrolador Atmel AT90CAN128. En él se pueden diferenciar los distintos bloques funcionales, englobados mediante cuadros coloreados atendiendo a la función que desempeñan. Descripción Hardware Página | 20 Ricardo Antonio Rios Peña Figura 2.8. Diagrama de Bloques del microcontrolador AT90CAN128 Los bloques encuadrados en azul se encuentran formados por los puertos de entrada y salida del dispositivo. El Atmel AT90CAN128 posee 53 líneas de entrada/salida que pueden ser utilizadas para propósito general, y que se encuentran organizadas en 6 puertos de 8 bits y un puerto de 5 bits, denotados como PORTA, PORTB, PORTC, PORTD, PORTE, PORTF y PORTG, respectivamente. Las líneas de uso general comparten conexión Descripción Hardware Ricardo Antonio Rios Peña Página | 21 con los diferentes bloques funcionales implementados en el hardware del dispositivo, de forma que éstos poseen conexión con el exterior. Los bloques resaltados en color amarillo son algunos de los distintos bloques funcionales implementados en el chip. Dichos bloques poseen una variada funcionalidad, que va desde la USART, SPI, bloque de conversor analógico-digital (ADC), timers, etc. Por otro lado el bloque resaltado en color verde se corresponde con el controlador CAN, siendo este el bloque más importante para nuestro TFG. En la Figura 2.9 se muestra el diagrama de bloques del núcleo del microcontrolador, que se corresponde con el bloque resaltado en rojo en la Figura 2.8. Descripción Hardware Página | 28 Ricardo Antonio Rios Peña Figura 2.13. Diagrama de bloques de la USART Los cuadros señalados con líneas discontinuas separan los tres bloques principales de la USART, mencionándolos desde arriba hacia abajo: Generador de Reloj, Transmisor y Receptor. Los registros de control son compartidos por todas las unidades. La lógica del Generador de Reloj (Clock Generator) consiste en lógica de sincronización para la entrada de señal de reloj externa utilizada como esclavo en modo síncrono, y el generador de la tasa de baudios. El pin XCKn (Reloj de transferencia) se usa sólo en el modo de transferencia Descripción Hardware Ricardo Antonio Rios Peña Página | 29 síncrono. El Transmisor (Transmitter) consiste en un único buffer de escritura (UDRn), un registro de desplazamiento serie (Shift Register), un generador de paridad (Parity Generator) y lógica de control (TX Control) para gestionar diferentes formatos de trama. El buffer de escritura permite una transferencia continua de datos sin retardo entre tramas. El Receptor (Receiver) es el bloque más complejo de la USART debido a sus unidades de recuperación de reloj (Clock Recovery) y de datos (Data Recovery). Estas unidades se utilizan para la recepción asíncrona de datos. El Receptor además incluye un comprobador de paridad (Parity Checker), lógica de control (RX Control), un registro de desplazamiento (Shift Register) y un buffer de recepción (UDRn). El Receptor soporta el mismo formato de tramas que el Transmisor, además puede detectar errores de trama (Frame Error), desbordamiento de datos (Data OverRun) y errores de paridad (Parity Errors). 2.4.2.1 Generación de Reloj. La lógica de generación de la señal de reloj genera el reloj de referencia para el Transmisor y el Receptor. La USART soporta cuatro modos de operación: Normal asíncrono, Asíncrono a doble velocidad, Maestro síncrono y Esclavo síncrono. El bit UMSELn en el registro de estado y control C de la USART (Control and Status Register, UCSRnC) selecciona entre los modos de operación síncrono y asíncrono. En la Figura 2.14 se muestra el diagrama de bloques del generador de reloj de la USART. Descripción Hardware Página | 30 Ricardo Antonio Rios Peña Figura 2.14. Lógica de generación de la señal de reloj de la USART Cuando se utiliza el modo síncrono (UMSELn = 1), el registro DDR para el pin XCKn (DDR_XCKn) controla si la señal de reloj es interna (Maestro) o externa (Esclavo). El pin XCKn sólo está activo cuando se utiliza el modo de operación síncrono. La generación interna del reloj se utiliza para los modos de operación asíncrono y maestro síncrono. El registro de tasa de baudios (Baud Rate Register, UBRRn) y el contador regresivo conectado a él funcionan como un prescaler programable. El contador regresivo, ejecutándose a la velocidad del reloj del sistema (fclkio), se carga con el valor de UBRRn cada vez que el contador llega a cero, o bien cuando se escribe en el registro UBRRn. Se genera un pulso de reloj cada vez que contador llega al valor cero. Este reloj es la salida del generador de la tasa de baudios (= fclkio/(UBRRn+1)). El Transmisor divide la salida de este reloj por 2, 8 o 16 dependiendo del modo de operación. Por otro lado este reloj es usado directamente por las unidades de recuperación de datos y reloj del Receptor. Sin embargo, las unidades de recuperación utilizan una máquina de estados que usa 2, 8 o 16 estados en función del modo de operación establecido. En la Figura 2.15 se muestran las distintas ecuaciones para calcular tanto la tasa de baudios como el valor del registro UBRRn. Descripción Hardware Ricardo Antonio Rios Peña Página | 31 Figura 2.15. Ecuaciones para calcular la configuración de la tasa de baudios 2.4.2.2 Formato de la trama. Una trama serie se define como una serie de bits de datos en conjunto con bits de sincronización (bits de start y stop). Opcionalmente se puede incluir un bit de paridad para comprobación de errores. En la Figura 2.16 se observa gráficamente este formato, donde los bits dentro de corchetes son opcionales. Figura 2.16. Formato de trama Descripción Hardware Página | 32 Ricardo Antonio Rios Peña La USART acepta las 30 combinaciones de los siguientes formatos de trama válidos:  1 bit de start.  5, 6, 7, 8 o 9 bits de datos.  Bit de paridad par, impar o sin paridad.  1 o 2 bits de stop. Una trama comienza con el bit de start seguido del bit de datos menos significativo. A continuación se encuentran los siguientes bits de datos, hasta un máximo de 9, terminando con el bit más significativo. Si está habilitado, el bit de paridad se inserta justo después de los bits de datos, antes de los bits de stop. Cuando una trama es transmitida completamente, se puede transmitir directamente una nueva trama, o la línea de comunicación se puede llevar a un estado desocupado (nivel alto). 2.4.2.3 Transmisor. La USART debe ser inicializada antes de que pueda tener lugar cualquier comunicación. El proceso de inicialización normalmente consiste en el establecimiento de la tasa de baudios, el formato de la trama, y en la habilitación del Transmisor o del Receptor dependiendo del uso que se le vaya a dar. Si la USART va a ser gestionada mediante interrupciones, el flag de interrupciones globales (Global Interrupt Flag) debe estar desactivado, y las interrupciones globales deshabilitadas, en el momento de hacer la inicialización. El Transmisor de la USART se habilita al establecer el bit de habilitar transmisión (Transmit Enable, TXENn) en el registro UCSRnB a nivel alto. Una vez habilitado, el modo de operación normal del puerto en el pin TxDn es ignorado por la USART y se le asigna la función de salida serie del Transmisor. La tasa de baudios, el modo de operación y el formato de la trama deben ser establecidos antes de hacer ninguna transmisión. Descripción Hardware Ricardo Antonio Rios Peña Página | 33 Una transmisión se inicia cargando los datos a transmitir en el buffer de transmisión. Los datos que se encuentran en el buffer serán movidos al Registro de Desplazamiento cuando éste se encuentre listo para enviar una nueva trama. El Registro de Desplazamiento se carga con los nuevos datos si se encuentra en un estado inactivo (no hay transmisiones en curso), o inmediatamente después de que se haya transmitido el último bit de stop de la trama anterior. El Transmisor de la USART cuenta con dos flags que indican su estado: registro de datos vacío (USART Data Register Empty, UDREn) y transmisión completada (Transmit Complete, TXCn). Ambos flags pueden ser utilizados para generar interrupciones. El flag de registro de datos vacío (UDREn) indica si el buffer de transmisión está listo para recibir nuevos datos. Este bit se activa cuando el buffer está vacío, y se desactiva cuando contiene datos para transmitir que no han sido pasados aún al Registro de Desplazamiento. El flag de transmisión completada (TXCn) se activa cuando en el Registro de Desplazamiento la trama completa ha sido desplazada hacia la salida y no hay datos nuevos en el buffer de transmisión. El flag TXCn es automáticamente desactivado cuando la interrupción de transmisión completada se ejecuta, si bien también puede ser desactivado escribiendo un “1” lógico en el bit correspondiente al flag. Cuando el bit de habilitación de la interrupción por transmisión completada (Transmit Complete Interrupt Enable, TXCIEn) en el registro UCSRnB se pone a nivel lógico alto, se ejecutará dicha interrupción siempre que el flag TXCn se active, asumiendo que las interrupciones globales está habilitadas. La acción de deshabilitar el Transmisor (establecer el bit TXENn a nivel bajo) no será efectiva hasta que la transmisión en curso y las pendientes se completen, por ejemplo Descripción Hardware Página | 34 Ricardo Antonio Rios Peña cuando el Registro de Desplazamiento y el buffer de transmisión no contengan datos para transmitir. Una vez deshabilitado, el Transmisor no continuará sobrescribiendo la función del pin TxDn. 2.4.2.4 Receptor. El Receptor de la USART se habilita al establecer el bit de habilitar recepción (Receive Enable, RXENn) en el registro UCSRnB a “1” lógico. Una vez habilitado, el modo de operación normal del puerto en el pin RxDn es ignorado por la USART y se le asigna la función de entrada serie del Receptor. La tasa de baudios, el modo de operación y el formato de la trama deben ser establecidos antes de realizar ninguna transmisión. El Receptor comienza la recepción de datos cuando detecta un bit de start válido en el bus. Cada bit que le sigue al bit de start será muestreado a la velocidad de la tasa de baudios, y luego será desplazado hacia el Registro de Desplazamiento de recepción hasta que se reciba el primer bit de stop de la trama. Un segundo bit de stop será ignorado por el receptor. Cuando se recibe el primer bit de stop, el Registro de Desplazamiento contiene una trama completa, la cual será trasladada al buffer de recepción. El buffer de recepción puede ser leído en la dirección UDRn. El Receptor de la USART cuenta con un flag que indica su estado: recepción completada (Receive Complete, RXCn), el cual puede generar una interrupción. El flag recepción completada (RXCn) es un indicador de si hay datos sin leer en el buffer de recepción. El flag se encuentra activado cuando se dispone de datos no leídos en el buffer de recepción, y desactivado cuando dicho buffer se encuentra vacío. Si el Receptor es deshabilitado (RXENn = 0) el contenido del buffer de recepción será borrado, y en consecuencia el flag RXCn se desactivará. Descripción Hardware Ricardo Antonio Rios Peña Página | 35 Cuando el bit de habilitación de la interrupción por recepción completada (Receive Complete Interrupt Enable, TXCIEn) en el registro UCSRnB se pone a “1” lógico, se ejecutará dicha interrupción siempre que el flag TXCn se active, asumiendo que las interrupciones globales están habilitadas. Cuando la recepción es gestionada mediante interrupciones, la rutina de servicio debe leer los datos recibidos en UDRn con el fin de desactivar el flag RXCn, de lo contrario se volverá a generar una nueva interrupción una vez finalice la rutina de servicio. Al contrario del Transmisor, deshabilitar el Receptor tiene efecto inmediatamente. Por tanto se perderán los datos de cualquier recepción en curso. Una vez deshabilitado, el Receptor no continuará sobrescribiendo la función del pin RxDn y los datos que queden en el buffer de recepción se perderán. 2.4.2.5 Descripción de registros. En este apartado se explicarán cada uno de los registros utilizados en la configuración y la gestión de la USART, así como la descripción del significado de los bits dentro de cada registro. Únicamente se explicarán los registros y bits relevantes a este TFG. En primer lugar se pueden observar los registros de datos en la Figura 2.17. Figura 2.17. Registro de datos I/O de la USART Descripción Hardware Página | 36 Ricardo Antonio Rios Peña  Bit 7:0 – RxBn7:0: Receive Data Buffer.  Bit 7:0 – TxBn7:0: Transmit Data Buffer. Los buffers de recepción y transmisión de la USART comparten la misma dirección en el espacio de memoria, referido como USARTn Data Register o UDRn. El buffer de transmisión (TXBn) será el destino de los datos escritos en la dirección del registro UDRn, mientras que leer del registro UDRn devolverá el contenido del buffer de recepción (RXBn). En las figuras que siguen a continuación se pueden observar los registros de estado y de control de la USART. Figura 2.18. Registro de Estado y de Control A  Bit 7 – RXCn: USARTn Receive Complete. Este bit se activa cuando hay datos en el buffer de recepción que no han sido leídos, y se desactiva cuando el buffer de recepción se vacía. Si el Receptor se deshabilita, los datos que hayan en el buffer de recepción son descartados y por tanto el flag RXCn se desactiva. Este flag puede ser utilizado para generar una interrupción.  Bit 6 – TXCn: USARTn Transmit Complete. Este bit se activa cuando la trama completa del Registro de Desplazamiento se ha desplazado hacia la salida y no hay nuevos datos en el buffer de transmisión. El flag TXCn Descripción Hardware Ricardo Antonio Rios Peña Página | 37 se desactiva automáticamente cuando la interrupción de transmisión completada se ejecuta, o bien escribiendo un “1” lógico en el bit correspondiente al flag. Este flag puede ser utilizado para generar una interrupción. Figura 2.19. Registro de Estado y de Control B  Bit 7 – RXCIEn: RX Complete Interrupt Enable. Escribir un “1” lógico en este bit habilita la interrupción del flag RXCn. Se generará una interrupción de recepción completada sólo si el bit RXCIEn está a nivel alto, las interrupciones globales están habilitadas y el flag RXCn se encuentra activo.  Bit 6 – TXCIEn: TX Complete Interrupt Enable. Escribir un “1” lógico en este bit habilita la interrupción del flag TXCn. Se generará una interrupción de transmisión completada sólo si el bit TXCIEn está a nivel alto, las interrupciones globales están habilitadas y el flag TXCn se encuentra activo.  Bit 4 – RXENn: Receiver Enable. Escribir un “1” lógico en este bit habilita el Receptor de la USART. El Receptor ignorará el modo de operación normal del pin RxDn cuando está habilitado. Deshabilitar el Receptor descartará el contenido del buffer de recepción. Descripción Hardware Página | 44 Ricardo Antonio Rios Peña Por lo general, los conflictos de acceso al bus se resuelven en el campo de arbitraje a partir del valor del identificador. Si una trama de datos y una trama remota con el mismo identificador se envían al mismo tiempo, la trama de datos prevalece sobre la trama remota. Figura 2.27. Arbitraje del bus 2.4.3.2 Controlador CAN. El controlador CAN implementado en el AT90CAN128 soporta la versión 2.0 B del estándar CAN. Este controlador CAN completo proporciona todo el hardware necesario para un filtrado de aceptación adecuado y la gestión de mensajes. Para cada mensaje a ser transmitido o recibido, este módulo contiene lo que se llama un “objeto de mensaje” (Message Object, MOb), en el cual se almacena toda la información relacionada con el mensaje (identificador, bytes de datos, etc.). Durante la inicialización del periférico, la aplicación define qué MObs son para enviar y cuales para recibir. Sólo si el controlador CAN recibe un mensaje cuyo identificador coincide con uno de los identificadores programados en los MObs destinados a la recepción se guarda el mensaje y la aplicación es informada mediante una interrupción. Otra ventaja es que las tramas remotas entrantes pueden ser respondidas automáticamente por el controlador con la correspondiente trama de datos. De esta forma, la carga de la CPU se Descripción Hardware Ricardo Antonio Rios Peña Página | 45 reduce considerablemente en comparación con una solución CAN básica. Usando este controlador CAN completo, se pueden gestionar altas tasas de baudios y buses cargados con muchos mensajes. Figura 2.28. Estructura del controlador CAN 2.4.3.3 Objetos de mensajes (MOb). Un MOb describe una trama CAN, conteniendo toda la información para controlar una trama. Esto quiere decir que los MObs han sido definidos de forma que permitan describir un mensaje CAN como si fuera un objeto. Este dispositivo tiene 15 MObs, numerados del 0 al 14. Los MObs son independientes entre sí pero se le da prioridad al de menor número en caso de que se produzcan múltiples coincidencias. Cada MOb tiene su Descripción Hardware Página | 46 Ricardo Antonio Rios Peña propio campo para controlar el modo de operación. Antes de habilitar el periférico CAN, cada MOb debe ser configurado, ya que no existe un modo de operación por defecto. Los modos de operación se pueden observar en la Figura 2.29. Figura 2.29. Configuración de los MObs Cada MOb está mapeado en una página para ahorrar espacio. El número de página se corresponde con el número de MOb, el cual se establece en el registro CANPAGE. El registro CANHPMOB devuelve el MOb con mayor prioridad que haya generado una interrupción en el registro CANSIT. Cada MOb contiene un buffer para los datos, el cual puede ser accedido a través del registro CANMSG. El índice de datos (INDX) es el puntero de dirección al byte de datos requerido. El byte de datos puede ser leído o escrito. El índice de datos se autoincrementa después de cada acceso siempre que el bit AINC en el registro CANPAGE esté a nivel bajo. Además, se ha implementado un reinicio del índice, con lo que después de INDX=7 se pasa a INDX=0. Para enviar una trama se sigue el siguiente proceso:  Se deben inicializar varios campos antes de poder enviar: Descripción Hardware Ricardo Antonio Rios Peña Página | 47 o Identificador (IDT). o Extensión de identificador (IDE). o Petición de transmisión remota (RTRTAG). o Código de longitud de datos (DLC). o Bytes de datos del mensaje (MSG).  El MOb estará listo para enviar la trama cuando se configure como transmisor en el registro CONMOB.  Entonces se escanean todos los MObs configurados como transmisor, se encuentra el de mayor prioridad y se intenta enviar.  Cuando la transmisión se ha completado se activa el flag TXOK.  Todos los parámetros y datos están disponibles en el MOb hasta una nueva inicialización. Por otro lado, el proceso para la recepción es el siguiente:  Se deben inicializar varios campos antes de poder recibir: o Identificador (IDT). o Máscara de identificador (IDMSK). o Extensión de identificador (IDE). o Máscara de extensión de identificador (IDEMSK). o Petición de transmisión remota (RTRTAG). o Máscara de petición de transmisión remota (RTRMSK). o Código de longitud de datos (DLC).  El MOb estará listo para recibir cuando se configure como receptor en el registro CONMOB.  Cuando se recibe un identificador de trama, se escanean todos los MObs en modo de recepción y se intenta encontrar el MOb con mayor prioridad que genere una coincidencia. Descripción Hardware Página | 48 Ricardo Antonio Rios Peña  Ante una coincidencia, el IDT, IDE y DLC del MOb que ha generado la coincidencia se actualizan con los valores de la trama recibida.  Una vez se ha completado la recepción, los bytes de datos recibidos se almacenan en el buffer de datos del MOb que ha generado la coincidencia y se activa el flag RXOK.  Todos los parámetros y datos del MOb están disponibles hasta una nueva inicialización. 2.4.3.4 Interrupciones. Cuando ocurre una interrupción, un bit que actúa como flag se activa en el registro CANSTMOB del MOb correspondiente, o en el registro general CANGIT. Si los bits ENRX, ENTX o ENERR en el registro CANIE están a “1” lógico, entonces se activa el bit correspondiente al MOb en el registro CANSITn. Para reconocer una interrupción generada por un MOb, los bits correspondientes (RXOK, TXOK,...) en el registro CANSTMOB deben ser limpiados por la aplicación. Para reconocer una interrupción general, los bits correspondientes (BXOK, BOFFIT,...) en el registro CANGIT deben ser inicializados por la aplicación. Esta operación se realiza escribiendo un “1” lógico en estos flags de interrupción (escribir un “0” lógico no modifica el valor de los mismos). 2.4.3.5 Descripción de los registros generales. En este apartado se explicarán cada uno de los registros generales utilizados en la configuración y la gestión del CAN, así como la descripción del significado de los bits dentro de cada registro. Únicamente se explicarán aquellos que sean relevantes a este TFG. En primer lugar se puede observar el registro de control general en la Figura 2.30. Descripción Hardware Ricardo Antonio Rios Peña Página | 49 Figura 2.30. Registro de control general  Bit 1 – ENA/STB: Enable / Standby Mode. Debido a que este bit es un comando y no es efectivo inmediatamente, el bit ENFG en el registro CANGSTA indica el verdadero estado del controlador. - 0: modo standby: Si existe alguna transmisión en curso se termina normalmente y el CAN se detiene. El transmisor constantemente establece un nivel recesivo. En este modo, el receptor no está habilitado pero todos los registros y MObs continúan siendo accesibles por la CPU. - 1: modo habilitado: El CAN se habilita una vez se hayan leído 11 bits recesivos.  Bit 0 – SWRES: Software Reset Request. Este bit inicializa el controlador CAN. - 0: no reset. - 1: reset. Figura 2.31. Registro de interrupciones generales Descripción Hardware Página | 50 Ricardo Antonio Rios Peña  Bit 7 – CANIT: General Interrupt Flag. Este es un bit de sólo lectura. - 0: no hay interrupciones. - 1: interrupción CAN: es una imagen de todas las interrupciones del controlador CAN. Este bit puede ser usado para métodos de acceso basados en polling. Figura 2.32. Registro de habilitación de interrupciones generales  Bit 7 – ENIT: Enable all Interrupts. - 0: interrupciones deshabilitadas. - 1: interrupciones habilitadas (CANIT).  Bit 5 – ENRX: Enable Receive Interrupt. - 0: interrupción deshabilitada. - 1: interrupciones por recepción habilitadas.  Bit 4 – ENTX: Enable Transmit Interrupt. - 0: interrupción deshabilitada. - 1: interrupciones por transmisión habilitadas. Descripción Hardware Ricardo Antonio Rios Peña Página | 51 Figura 2.33. Registros de habilitación de los MObs  Bits 14:0 - ENMOB14:0: Enable MOb. Este bit indica la disponibilidad del MOb. - 0: MOb deshabilitado, disponible para una nueva transmisión o recepción. - 1: MOb habilitado, en uso. Figura 2.34. Registros de habilitación de las interrupciones de los MObs  Bits 14:0 - IEMOB14:0: Interrupt Enable by MOb. - 0: interrupciones deshabilitadas. - 1: interrupciones de los MOb habilitadas. Ejemplo: CANIE2 = 0000 1100: habilita las interrupciones de los MObs 2 y 3. Descripción Hardware Página | 52 Ricardo Antonio Rios Peña Figura 2.35. Registro de página MOb  Bit 7:4 – MOBNB3:0: MOb Number. Selecciona el número de MOb, yendo los números disponibles desde el 0 al 14.  Bit 3 – AINC: Auto Increment of the FIFO CAN Data Buffer Index. - 0: autoincremento del índice activado (por defecto). - 1: autoincremento del índice desactivado.  Bit 2:0 – INDX2:0: FIFO CAN Data Buffer Index. Ubicación del byte de datos en la FIFO para el MOb definido. 2.4.3.6 Descripción de los registros MOb. En este apartado se explicarán cada uno de los registros relacionados con los MObs que han sido utilizados en la configuración y la gestión del CAN, así como la descripción del significado de los bits dentro de cada registro. Únicamente se explicarán aquellos que sean relevantes a este TFG. En primer lugar se puede observar el registro de estado en la Figura 2.36. Descripción Hardware Ricardo Antonio Rios Peña Página | 53 Figura 2.36. Registro de estado del MOb  Bit 6 – TXOK: Transmit OK. Este flag puede generar una interrupción. Indica una transmisión completada.  Bit 5 – RXOK: Receive OK. Este flag puede generar una interrupción. Indica una recepción completada. Figura 2.37. Registro de control y DLC del MOb  Bit 7:6 – CONMOB1:0: Configuration of Message Object. Estos bits establecen el tipo de comunicación que se va a realizar (sin valor inicial después de un reset). Estos bits no se inicializan una vez se ha realizado la comunicación. El usuario debe rescribir la configuración para iniciar una nueva comunicación. - 00: deshabilitado. - 01: transmisión. - 10: recepción. - 11: recepción en buffer. Descripción Hardware Página | 60 Ricardo Antonio Rios Peña Figura 2.43. Puntero Z Dado que la memoria Flash está organizada en páginas, las cuales se pueden observar en la Figura 2.44, el contador de programa (Program Counter, PC) se puede tratar como si tuviera dos secciones diferentes. Una sección, que consiste en los bits menos significativos, direcciona las palabras dentro de una página, mientras que los bits más significativos direccionan las páginas. Figura 2.44. Páginas de la memoria Flash Descripción Hardware Ricardo Antonio Rios Peña Página | 61 Figura 2.45. Direccionamiento de la memoria Flash durante SPM Descripción Hardware Página | 62 Ricardo Antonio Rios Peña Desarrollo Software Ricardo Antonio Rios Peña Página | 63 Capítulo 3: Desarrollo Software 3.1 Introducción. En este capítulo se presenta una descripción a nivel funcional del firmware desarrollado en este Trabajo Fin de Grado. Así, en primer lugar se plantea una visión general del funcionamiento de la plataforma, describiéndose posteriormente el funcionamiento del sistema de interrupciones, así como la biblioteca CAN desarrollada. Por último se explican detalladamente las aplicaciones router y bootloader de los nodos, implementadas en este TFG. 3.2 Descripción general. La plataforma experimental desarrollada se compone de tres elementos claramente diferenciables: el primer elemento es el Servidor central, el segundo elemento es el router que comunica dicho servidor con el bus CAN, y el último elemento estaría constituido por los nodos inalámbricos que se encuentran conectados al bus. En la Figura 3.1 se muestra un diagrama de bloques de la plataforma. Desarrollo Software Página | 64 Ricardo Antonio Rios Peña Figura 3.1. Estructura de la plataforma A continuación se describe el proceso para programar uno de los nodos inalámbricos mediante la plataforma propuesta, que se encuentra representado en el diagrama de flujo de la Figura 3.2. Así, en primer lugar se toma el firmware que ha sido desarrollado (archivo .hex generado por el compilador) y se le pasa a la aplicación del Servidor, la cual lo analiza y divide en pequeños fragmentos de código. Esto se hace necesario debido a que el bus CAN sólo permite tramas con un tamaño máximo de 8 bytes, por lo que no es posible enviar todo el código en una sola transmisión. En segundo lugar se selecciona la dirección del nodo que se desea programar y se envía al router un comando que establece esa dirección. El tercer paso consiste en tomar los fragmentos de código, formar con ellos los distintos comandos que posteriormente deben interpretar los nodos, y enviarlos al router. En cuarto lugar el router recibe los comandos del servidor a través de la USART, los convierte en tramas CAN, y los envía por este bus a la dirección previamente establecida. En quinto lugar los nodos, una vez hayan recibido un comando, lo interpretan y llevan a cabo la tarea correspondiente. Por último, cualquiera de los nodos puede enviar mensajes al servidor a través del router; si este es el caso, el router toma la trama CAN recibida, la convierte en un mensaje serie, y lo transmite al Servidor a través de la USART. Desarrollo Software Ricardo Antonio Rios Peña Página | 65 Figura 3.2. Diagrama de flujo de la programación de un nodo La aplicación que se ejecuta en el Servidor, el cuál en principio es un ordenador común, ha sido desarrollada previamente por los profesores tutores y no forma parte de este TFG. Dicha aplicación ofrece una serie de opciones sobre las cuales se basa la implementación de las aplicaciones router y bootloader desarrolladas. En primer lugar permite la conexión con el router a través de la USART, estableciendo una comunicación directa entre ambos dispositivos a través de este bus serie. En segundo lugar es necesario seleccionar la dirección del nodo inalámbrico que se desea programar. Finalmente se dispone básicamente de tres opciones: programar el nodo, borrar la memoria Flash y ejecutar la aplicación remota. De esta forma se dispondrá de un Servidor desde el cual será posible programar todos los nodos conectados al bus, haciendo uso de un router que permitirá direccionar cada uno de ellos, además de poder recibir mensajes provenientes de dichos nodos. Con esta finalidad se desarrollará el firmware correspondiente a la aplicación router y a la aplicación bootloader de los nodos inalámbricos. De esta forma se creará una infraestructura que permitirá programar y depurar los nodos de la plataforma de manera remota, concentrando los datos en un Servidor central. Desarrollo Software Página | 66 Ricardo Antonio Rios Peña 3.3 Sistema de interrupciones. Las aplicaciones router y bootloader desarrolladas tienen un comportamiento similar. Así, su funcionamiento normal está contenido en un bucle infinito en el cual realizan una serie de tareas periódicas. Por otro lado, tanto la USART como el CAN han sido configurados para trabajar mediante interrupciones. Así, la aplicación se encontrará normalmente realizando las tareas del bucle infinito, pudiendo ser interrumpidas en cualquier momento por uno de los buses, pasando entonces a atender la rutina de servicio correspondiente. En los siguientes apartados se procederá a explicar en detalle cada una de las rutinas de servicio de las interrupciones asociadas a los buses, comenzando con las interrupciones relacionadas con el bus CAN, y continuando con las relacionadas con la USART. 3.3.1 Vector de interrupción CAN. En el microcontrolador AT90CAN128 existe un solo vector de interrupción asociado al bus CAN, tanto para la recepción como para la transmisión, motivo por el que se hace necesario atender ambos eventos dentro de la misma rutina de servicio. En la Figura 3.3 se puede observar un diagrama de flujo de la rutina de servicio CAN desarrollada. El código fuente de esta rutina puede encontrarse dentro de los ficheros CAN128ROUTER.c y CAN128BOOTLOADER.c de la aplicación router y la aplicación bootloader, respectivamente. Desarrollo Software Ricardo Antonio Rios Peña Página | 67 Figura 3.3. Diagrama de flujo de la rutina de servicio CAN Desarrollo Software Página | 68 Ricardo Antonio Rios Peña Como se puede observar, en primer lugar se almacena la página CAN que se encuentra seleccionada al entrar en la rutina de servicio. En segundo lugar se carga la página correspondiente a la transmisión y se guardan los flags de interrupción asociados a ella. En tercer lugar se comprueba si la interrupción ha sido generada por una transmisión completada; en caso afirmativo se activa el flag que indica una transmisión completada. Un cuarto paso sería limpiar los flags de interrupción, siempre que alguno de ellos se encuentre activado. A continuación se repite este mismo proceso pero para el caso de la recepción. Por último se restaura la página CAN que fue guardada al inicio, finalizando la rutina de servicio. 3.3.2 Vector de interrupción USART: transmisión. En el caso de la USART, sí que se dispone de vectores de interrupción diferenciados para la transmisión y la recepción. Antes de pasar a describir la rutina de servicio correspondiente a la transmisión, se explicará el proceso para enviar un carácter a través de la USART. Para empezar, se ha redireccionado la salida estándar, de forma tal que cada vez que se utiliza la función printf() los datos son enviados por la USART. Así, en primer lugar, se almacenan los caracteres a enviar en un buffer circular estructurado como una FIFO (First In First Out). Puesto que la USART ha sido configurada para enviar 8 bits, cada transmisión se corresponderá con un carácter. En segundo lugar se llama a la función que transmite un carácter, lo cual, una vez se ha completado la transmisión genera una interrupción. Por último, la rutina de servicio de la interrupción inicia una nueva transmisión en caso de que haya más caracteres en la FIFO. El código fuente de las funciones que realizan estas acciones puede encontrarse dentro de los ficheros CAN128ROUTER.c y CAN128BOOTLOADER.c de la aplicación router y la aplicación bootloader, respectivamente. Desarrollo Software Ricardo Antonio Rios Peña Página | 69 Para insertar los caracteres en la FIFO se utiliza la función insertTxFIFO(), de la cual se puede observar su diagrama de flujo en la Figura 3.4. Figura 3.4. Diagrama de flujo de la función insertTxFIFO En esta función se comprueba en primer lugar que la FIFO de transmisión no se encuentre llena, en cuyo caso no es posible agregar el elemento al buffer y simplemente se invoca la función de transmitir un carácter. En segundo lugar, en caso de que haya espacio en la FIFO, se almacena el carácter en el buffer. El tercer paso es incrementar el puntero utilizado para gestionar la FIFO circular. Por último, se invoca la función de transmitir un carácter. Para transmitir un carácter almacenado en la FIFO se utiliza la función TxChar(), de la cual se puede observar su diagrama de flujo en la Figura 3.5. Desarrollo Software Página | 76 Ricardo Antonio Rios Peña Antes de poder enviar y recibir por el bus CAN se hace necesario configurarlo e inicializarlo, para lo cual se proporciona una de las funciones públicas. Esta función, con cabecera void initCAN() se encarga de configurar y habilitar el controlador CAN integrado en el microcontrolador, haciendo uso de los parámetros definidos previamente, además de inicializar todas las páginas CAN a sus valores por defecto. Un elemento a tener en cuenta es que esta configuración establece el uso de interrupciones como forma de gestionar los eventos, de forma que los usuarios necesitarán definir en sus aplicaciones la rutina de servicio correspondiente. 3.4.3 Funciones públicas: transmisión. Una vez realizada la configuración del bus es posible comenzar, tanto la transmisión como la recepción. En el caso de la transmisión, se cuenta con tres funciones que permitirán establecer la dirección CAN, añadir un elemento al buffer de transmisión, y por último, iniciar una transmisión. La primera de estas funciones es la de establecer la dirección CAN, la cual tiene la siguiente cabecera: void set_can_address(unsigned char Can_base_id). Esta función requiere de un parámetro que es la dirección del nodo que va a transmitir la trama. A pesar de que la implementación se ha realizado estableciendo direcciones CAN de 29 bits, el usuario no se tiene que preocupar por esto, teniendo que proporcionar la dirección como un número entero, siendo la función la encargada de confeccionar el identificador adecuado. El identificador se conforma con un formato origen-destino, de forma que la mitad superior de los 29 bits del identificador corresponden a la dirección del nodo que envía la trama, mientras que la mitad inferior corresponde al destino de la trama. Como la plataforma se ha diseñado para que los nodos sólo puedan enviar tramas hacia el router, los 14 primeros bits correspondientes al destino siempre serán 0, que es la dirección asignada por defecto al router. Desarrollo Software Ricardo Antonio Rios Peña Página | 77 La siguiente función es la de añadir un carácter en el buffer de transmisión, que tiene la siguiente cabecera: int can_putchar(char c). Esta función toma el carácter que se le pasa por parámetro y lo inserta en el buffer de transmisión, que está implementado como una FIFO circular. Además de esto, una vez se añade el elemento a la FIFO, también se inicia la transmisión de una trama. Como elemento adicional se ha definido esta misma función con el formato necesario en caso de que se deseara redirigir la salida estándar hacia el CAN: static int can_putchar(char c, FILE *stream). Esta función en principio se encuentra comentada, quedando a disposición del usuario para su uso. Por último se tiene la función que inicia la transmisión de una trama CAN, cuya cabecera es la siguiente: void CanTx(). En este caso lo que se hace es tomar los caracteres que haya disponibles en la FIFO, hasta un máximo de 8 que permite la trama CAN, y se transmite el identificador que fue establecido previamente; en caso de que la FIFO esté vacía, no se hace nada y se termina la función. 3.4.4 Funciones públicas: recepción. Las funciones destinadas a la recepción también son tres, comenzar la recepción, guardar la trama recibida en el buffer de recepción, y por último, extraer un carácter del buffer. La primera de estas funciones es la de iniciar la recepción, la cual tiene la siguiente cabecera: void can_rx_mob(uint32_t Can_base_id). Esta función requiere de un parámetro que es la dirección del nodo. Al igual que en el caso de la transmisión, la dirección es de 29 bits y tiene un formato origen-destino, siendo los últimos 15 bits la dirección de quien envía la trama y los primeros 14 bits la dirección del destino. Puesto que Desarrollo Software Página | 78 Ricardo Antonio Rios Peña en nuestra plataforma experimental los nodos solo pueden recibir tramas provenientes de la pasarela, la dirección origen en este caso siempre será 0. Una vez se invoca esta función, el nodo comenzará a aceptar tramas y comparar las direcciones con la que tiene programada, generándose una interrupción en caso de coincidencia. La siguiente función es la de guardar la trama recibida en el buffer de recepción, siendo su cabecera la siguiente: void can_retrieve_frame(). En este caso no hay ningún parámetro, y simplemente se debe invocar la función cada vez que se reciba una trama, con lo cual se extraen los datos recibidos y se almacenan en el buffer. Tener en cuenta que si en un momento determinado el buffer se llena, los datos que se reciban a continuación se perderán, ya que el control del estado del buffer queda en manos del usuario. Por último se tiene la función que extrae un carácter del buffer, cuya cabecera es la siguiente: char can_getchar(). Esta función no tiene parámetros y devuelve el primer elemento del buffer, es decir, el carácter más antiguo que se haya recibido. 3.5 Aplicación router. Como se indicó al inicio del capítulo, el módulo router es el encargado de recibir los comandos provenientes del Servidor a través de la USART y enviarlos al nodo destino que se encuentra conectado al bus CAN. Por otra parte, también hace el proceso inverso, es decir, toma los mensajes que envían los nodos y se los pasa al Servidor. En la Figura 3.9 se puede observar el diagrama de flujo que sigue el programa principal, la función int main(void), durante la cual se configura el microcontrolador y sus periféricos, además de realizarse todas las inicializaciones necesarias, para luego entrar en el bucle infinito. El código fuente de la aplicación router puede encontrarse dentro de los ficheros CAN128ROUTER.c y CAN128ROUTER.h. Desarrollo Software Ricardo Antonio Rios Peña Página | 79 Figura 3.9. Diagrama de flujo de la aplicación router Desarrollo Software Página | 80 Ricardo Antonio Rios Peña Configuración del Sistema. La configuración del sistema consiste en una serie de inicializaciones de los distintos elementos que serán utilizados para gestionar los periféricos. En primer lugar, se inicializa la cola circular en la cual se almacenarán los datos para ser enviados a través de la USART. En segundo lugar se inicializa el buffer donde se guardarán todos los datos que se reciban a través de la USART. El tercer paso es inicializar la cola circular en la que se almacenarán los datos para ser enviados a través del bus CAN. El último paso consiste en inicializar una serie de parámetros relacionados con el controlador CAN, como pueden ser la dirección base, la máscara de recepción, etc. Configuración del Microcontrolador. En este bloque se realiza la inicialización hardware. En primer lugar se lleva a cabo la configuración de la USART, que será el medio de comunicación con el servidor. La configuración de este puerto es básica, ya que en ella se seleccionan los parámetros de la comunicación serie, tales como la tasa de transferencia de datos, la longitud de los datos, la paridad, bits de stop, y el modo de funcionamiento. Para este TFG se ha definido una velocidad de 38400 baudios, 8 bits de datos, sin paridad, 1 bit de stop y que sea gestionado mediante interrupciones. Estos parámetros fueron elegidos puesto que, cuando se llevaron a cabo las pruebas iniciales, se comprobó que la USART funcionaba correctamente con el resto de la plataforma, y por tanto se mantuvo esta configuración. En segundo lugar se procede a la configuración del controlador CAN, que será el medio de comunicación con los nodos inalámbricos. La configuración de este controlador abarca aspectos tales como la velocidad del bus, inicialización de las páginas CAN y modo de funcionamiento. Además, como parte de la configuración del controlador hay que configurar el pin GPIO que actúa como enable del transceptor CAN externo. Para este TFG se ha establecido una velocidad de bus de 100Kbps, una página dedicada a la recepción y otra para la transmisión, igualmente gestionado mediante interrupciones. Finalmente, el Desarrollo Software Ricardo Antonio Rios Peña Página | 81 último paso consiste en habilitar las interrupciones generales. En este caso, se estableció la velocidad más baja del bus para evitar posibles cuellos de botella en el router, además de dedicar una página CAN a la transmisión y otra a la recepción para facilitar la gestión del controlador CAN. A continuación, y como paso previo antes de entrar al bucle cíclico, se redirige en primer lugar la salida estándar hacia la USART, de forma que cada vez que se invoque la función printf() los datos sean enviados a través de la USART, y en segundo lugar se inicia la recepción CAN, con lo cual se comienzan a analizar todas las tramas del bus, y en caso de que estén dirigidas al router, se genera una interrupción. Bucle Cíclico. El siguiente bloque dentro de la función principal corresponde con el bucle infinito. En apartados anteriores se ha explicado que cuando una interrupción es generada en el bus CAN, se activa un flag para indicar que se ha completado la recepción o transmisión, siendo en este bucle donde se atienden estos. En este bloque se comprueba en primer lugar el estado del flag que indica que se ha completado una recepción CAN. En caso de que se encuentre activo, se llevan a cabo las siguientes acciones. En primer lugar, se desactiva el flag para indicar que la recepción ha sido atendida. Lo segundo es extraer los parámetros asociados a la trama, que son la dirección y número de bytes de datos (DLC) que contiene la misma. En tercer lugar se extraen los bytes de datos y se almacenan en un buffer temporal. En cuarto lugar se realiza un eco a través de la USART de la trama recibida, añadiendo una cabecera con la dirección del nodo que envía el. Por último se vuelve a activar la recepción en el controlador CAN. Desarrollo Software Página | 82 Ricardo Antonio Rios Peña En segundo lugar se comprueba el estado del flag que indica que se ha completado una transmisión CAN. En caso de que se encuentre activo, lo primero es desactivar el flag para indicar que ya ha sido atendida dicha transmisión. A continuación, se inicia una nueva transmisión, lográndose de esta forma estar transmitiendo continuamente hasta que no haya más elementos disponibles en la FIFO. Dentro de la función de transmisión se comprueba si la FIFO está vacía o no; una vez se haya vaciado, se da por terminada la transmisión. El último elemento dentro del bucle infinito es una llamada a la función Parse Line, encargada de tomar la línea de comandos enviada por el Servidor, e interpretarla para llevar a cabo las acciones correspondientes. En la Figura 3.10 se observa un diagrama de su flujo de ejecución. Figura 3.10. Diagrama de flujo de la función parseLine Desarrollo Software Ricardo Antonio Rios Peña Página | 83 En primer lugar se comprueba el estado del flag que indica que hay una línea lista para procesar. En caso de que esté activo, en segundo lugar lo que se hace es reiniciar el índice que recorre el buffer de recepción. Al tratarse del router, los comandos pueden estar dirigidos, bien al propio router, o a alguno de los nodos. Es por esto que el tercer paso consiste en identificar el comando, que puede ser: fijar la dirección CAN del nodo que se desea programar, imprimir la dirección MAC del router, activar o desactivar el eco por la USART, o enviar la línea de comandos hacia el nodo inalámbrico. Por último se desactiva el flag para indicar que la línea ya ha sido procesada, y se sale de la función. 3.6 Aplicación bootloader. Los nodos inalámbricos son los dispositivos finales que estarán conectados al bus CAN, los cuales están constantemente a la escucha del bus esperando recibir los comandos provenientes del servidor. El firmware de los nodos está alojado en la zona de bootloader, dejando el resto de la memoria Flash disponible para almacenar la aplicación de usuario. En la Figura 3.11 se puede observar el diagrama de flujo que sigue el programa principal, la función int main(void), en la que se configura el microcontrolador y sus periféricos, además de realizarse todas las inicializaciones necesarias, para luego entrar en el bucle infinito. El código fuente de la aplicación bootloader puede encontrarse dentro de los ficheros CAN128BOOTLOADER.c y CAN128BOOTLOADER.h. Desarrollo Software Página | 84 Ricardo Antonio Rios Peña Figura 3.11. Diagrama de flujo de la aplicación bootloader Desarrollo Software Ricardo Antonio Rios Peña Página | 85 Configuración del Sistema. La configuración del sistema consiste en una serie de inicializaciones de los distintos elementos que serán utilizados para gestionar los periféricos. En primer lugar, se comprueba el pin GPIO que indica si se debe lanzar la aplicación o entrar en modo bootloader. En caso de que se lance dicha aplicación, los siguientes pasos representados en el diagrama no se llevarán a cabo. En segundo lugar se inicializa la cola circular en la que se almacenarán los datos para ser enviados a través de la USART. El tercer paso consiste en inicializar la cola circular en la cual se almacenarán los datos para ser enviados a través del bus CAN. En cuarto lugar se inicializa el buffer donde se guardarán todos los datos que se reciban a través del bus CAN. El último paso consiste en inicializar una serie de parámetros relacionados con el controlador CAN, como pueden ser la dirección base, la máscara de recepción, etc. Configuración del Microcontrolador. En este bloque se realiza la inicialización hardware. En primer lugar se mueven los vectores de interrupción a la zona de bootloader. Esto es necesario debido a que cuando se realiza alguna operación desde esta zona, no es posible acceder a ningún código que se encuentre localizado en la zona de la memoria destinada a la aplicación, que es donde se encuentran ubicados los vectores de interrupción por defecto. En segundo lugar se realiza la configuración de la USART, que en el caso de los nodos ha sido utilizada como medio de depuración. La configuración de este puerto es básica, seleccionándose en ella los parámetros de la comunicación serie, como son la tasa de transferencia de datos, la longitud de los datos, la paridad, bits de stop y el modo de funcionamiento. Para este TFG se ha definido una velocidad de 38400 baudios, 8 bits de datos, sin paridad, 1 bit de stop y que sea manejado mediante interrupciones. Esta configuración fue elegida, puesto que permitía llevar a cabo correctamente las tareas de depuración. Resultados Página | 92 Ricardo Antonio Rios Peña Para el desarrollo del ejemplo aquí presentado, se han utilizado tres módulos sensores inalámbricos, de los cuales dos actúan como nodos inalámbricos conectados al bus CAN, y el restante actúa como router, que por un lado se comunica con el bus CAN y por el otro, con el Servidor central a través de la USART. Para cumplir con el estándar CAN, al nodo intermedio se le ha retirado la terminación resistiva del bus. Por otro lado, el Servidor central se ejecuta en un ordenador portátil. La primera de estas pruebas consiste en realizar la programación de un único nodo, para lo cual se desarrolló una aplicación de ejemplo que imprime por la USART la cadena "Hola" al inicio de la función principal. Se decidió imprimir una cadena a través de la USART como método para poder comprobar visualmente que, efectivamente, el microcontrolador había sido correctamente programado. En este caso, al tratarse de la primera parte del proyecto, no se utiliza ningún direccionamiento, de forma que todos los mensajes iban dirigidos siempre a un único nodo sobre el que se estaba realizando la prueba. La segunda prueba incrementaba el número de nodos de la red, además de mejorar la aplicación de ejemplo. Para este caso se tomó la aplicación de la prueba anterior y se le añadió la posibilidad de enviar la cadena "Hola" hacia el bus CAN, con el objetivo de probar la otra funcionalidad de la plataforma, que permite que los nodos inalámbricos envíen mensajes al Servidor. Para ello se hizo uso de la biblioteca CAN que fue desarrollada como parte de este TFG. Además, en el Servidor fue agregada la opción de seleccionar la dirección del nodo que se desea programar. De esta forma, la aplicación de ejemplo para la segunda prueba lo que hace es que cada cierto tiempo imprime la cadena "Hola", tanto por la USART como por el bus CAN. De esta forma, es posible comprobar la correcta programación de varios nodos conectados al bus, así como el funcionamiento del eco que realiza el router hacia el Servidor de todos los mensajes recibidos a través del bus CAN. A continuación se explica esta segunda prueba más en detalle, comenzando con la interfaz de la aplicación Servidor, que se muestra en la Figura 4.2. Resultados Ricardo Antonio Rios Peña Página | 93 Figura 4.2. Interfaz aplicación Servidor El proceso para conectarse al router se muestra en la Figura 4.3. En primer lugar es necesario seleccionar el puerto serie al cual está conectado el router, lo cual se realiza a través del menú desplegable que se encuentra enmarcado en rojo. A continuación, dentro del menú Acciones, se selecciona la opción Conectar. Figura 4.3. Conexión con el router Resultados Página | 94 Ricardo Antonio Rios Peña El siguiente paso consiste en establecer la dirección del nodo que se desea programar, proceso mostrado en la Figura 4.4. En primer lugar es necesario seleccionar la dirección del nodo que se desea programar, lo cual se realiza a través del menú desplegable que se encuentra enmarcado en rojo. A continuación, dentro del menú Acciones, se selecciona la opción Fijar Dirección CAN. Figura 4.4. Establecer dirección CAN del nodo Para añadir el código fuente de la aplicación que se desea programar, en primer lugar, dentro del menú Archivo, se selecciona la opción Aplicación que se encuentra incluida dentro del submenú Abrir, tal como se muestra en la Figura 4.5. Esto abrirá una nueva ventana del explorador de archivos, como se puede observar en la Figura 4.6, en la que es necesario buscar el fichero generado por el compilador con la extensión .hex. Resultados Ricardo Antonio Rios Peña Página | 95 Figura 4.5. Cargar código fuente Figura 4.6. Fichero .hex generado por el compilador En la Figura 4.7, enmarcado en rojo, se encuentra la zona de la aplicación Servidor en la cual se muestran los distintos mensajes de estado. Como se puede observar, entre otra cosas indica a qué puerto está conectada, la dirección MAC del router, versión, etc. Resultados Página | 96 Ricardo Antonio Rios Peña Figura 4.7. Mensajes de estado de la aplicación Servidor Para programar el nodo con la aplicación que ha sido previamente cargada, es necesario seleccionar la opción Aplicación, que está dentro del submenú Programar, que a su vez se encuentra dentro del menú Acciones. En la Figura 4.8 se muestra este proceso. Figura 4.8. Ejecutar programación del nodo Resultados Ricardo Antonio Rios Peña Página | 97 Por otro lado, se ha establecido una conexión con el nodo destino a través de puerto serie, utilizando la aplicación HyperTerminal. Como se observa en la Figura 4.9, antes de ejecutar la programación del nodo en la aplicación Servidor, el nodo destino ha enviado a través de la USART un mensaje con la versión de la aplicación bootloader. Figura 4.9. Mensaje inicial de la aplicación bootloader En la Figura 4.10 se puede observar la barra que indica el porcentaje completado de la programación del nodo destino. Figura 4.10. Porcentaje completado de la programación del nodo Resultados Página | 98 Ricardo Antonio Rios Peña En la Figura 4.11 se pueden observar los mensajes de confirmación que genera el nodo que está siendo programado para cada comando recibido. Figura 4.11. Mensajes de confirmación del nodo Una vez se haya programado el nodo, desde el Servidor es posible lanzar la aplicación de usuario. Para ello es necesario seleccionar la opción Lanzar Aplicación, que se encuentra dentro del menú Acciones, tal como se muestra en la Figura 4.12. Figura 4.12. Lanzar aplicación de usuario Resultados Ricardo Antonio Rios Peña Página | 99 Como se indicó anteriormente, la aplicación de ejemplo imprime el mensaje "Hola" cada cierto tiempo, tanto por la USART como por el CAN. En el caso del nodo, en la Figura 4.13 se muestra cómo se reciben estos mensajes en el terminal una vez ha sido lanzada la aplicación. Por otro lado, en el caso del router, en la Figura 4.14 se muestra cómo además de hacer eco de los mensajes que recibe desde el bus CAN, les añade una cabecera indicando la dirección del nodo que ha enviado el mensaje. En este caso es posible comprobar que tanto la dirección establecida previamente en el Servidor, como la de los mensajes recibidos, coinciden. Figura 4.13. Aplicación de ejemplo en el nodo Figura 4.14. Mensajes recibidos en el router Resultados Página | 100 Ricardo Antonio Rios Peña A través de estas dos pruebas fue posible comprobar el correcto funcionamiento de la plataforma experimental propuesta. La primera de ellas sirvió para validar la primera parte del proyecto, que era lograr la programación de un nodo a través del bus CAN, y así poder continuar con el desarrollo del mismo. Por otro lado, la segunda prueba validaba el proyecto completo permitiendo validar diferentes aspectos, como son: la posibilidad de seleccionar el nodo inalámbrico que se desea programar, el correcto direccionamiento de estos nodos en el bus, o el funcionamiento del eco del router hacia el servidor de todos los mensajes provenientes de los nodos. Conclusiones y Líneas Futuras Ricardo Antonio Rios Peña Página | 101 Capítulo 5: Conclusiones y Líneas Futuras 5.1 Conclusiones. Con la finalización de este Trabajo Fin de Grado se han conseguido implementar las funciones básicas de programación y monitorización que permiten crear una plataforma experimental que facilitará la realización de pruebas en redes de sensores inalámbricos de una manera mucho más práctica de cara al usuario. Por un lado, el hecho de que los módulos sensores inalámbricos se basen en el microcontrolador AT90CAN128 ha permitido llevar a cabo un estudio de sus capacidades funcionales, prestando principal atención a aquellas características que han sido de utilidad para la realización de este Trabajo de Fin de Grado. Además se ha podido comprobar que, a pesar de ser un microcontrolador relativamente sencillo, en principio cumple perfectamente con los requisitos necesarios para implementar la plataforma experimental que se pretende desarrollar. La plataforma a desarrollar permite realizar la programación a distancia y monitorización de los nodos inalámbricos que se encuentran conectados al bus CAN. Para Pliego de Condiciones Página | 108 Ricardo Antonio Rios Peña Presupuesto Ricardo Antonio Rios Peña Página | 109 Presupuesto Siguiendo las recomendaciones del COITT (Colegio Oficial de Ingenieros Técnicos de Telecomunicación), el presupuesto ha sido desglosado en varias secciones. En estas secciones se han separado los distintos costes orientativos asociados al desarrollo del proyecto. Estos costes se dividen en: 1. Recursos materiales. 2. Trabajo tarifado por tiempo empleado. 3. Material fungible. 4. Costes de redacción del Trabajo Fin de Grado. 5. Derechos de visado del COITT. 6. Costes de tramitación y envío. 7. Aplicación de impuestos. P.1 Recursos materiales. Para la realización de este Trabajo Fin de Grado ha sido necesario utilizar tanto recursos hardware como recursos software. La amortización de estos recursos se calcula sobre el tiempo de vida útil del mismo. P.1.1 Recursos Hardware. Para la realización del presente TFG se han empleado las herramientas hardware que se detallan en la Tabla P.1. Presupuesto Página | 110 Ricardo Antonio Rios Peña Recurso Valor de adquisición Vida útil (meses) Coste mensual Tiempo de uso (meses) Importe Ordenador personal Asus A53S 500 € 48 10,42 € 4 41,68 € Módulos Sensores Inalámbricos 150 € x 2 - - - 300,00 € Emulador AVR – JTAGICE3 90 € - - - 90,00 € Impresora 50 € 48 1,04 € 4 4,16 € TOTAL 435,84 € Tabla P.1. Recursos hardware P.1.2 Recursos Software. Para la realización del presente TFG se han empleado herramientas software que se detallan en la Tabla P.2. Recurso Valor de adquisición Vida útil (meses) Coste mensual Tiempo de uso (meses) Importe Microsoft Office 2013 269 € 48 5,06 € 4 20,24 € Microsoft Visual Studio 2010 647,00 € 48 13,48 € 4 53,92 € Atmel Studio 6.2 0 € - - - 0 € TOTAL 74,16 € Tabla P.2. Recursos software Los costes totales asociados a los recursos materiales libres de impuestos ascienden a quinientos diez euros (510,00 €). Presupuesto Ricardo Antonio Rios Peña Página | 111 P.2 Trabajo tarifado por tiempo empleado. El importe de las horas de trabajo empleadas para la realización de un proyecto se calcula siguiendo las recomendaciones del COITT a partir de la siguiente ecuación: 𝐻𝑜𝑛𝑜𝑟𝑎𝑟𝑖𝑜𝑠 (€)= 𝐻𝑛∗58 + 𝐻𝑒∗63 Donde:  𝐻𝑛 son las horas normales trabajadas (dentro de la jornada laboral).  𝐻𝑒 son las horas especiales. Estos honorarios tendrán una reducción variable en función del número de horas empleadas de acuerdo con la Tabla P.3. Horas empleadas Factor de corrección 𝑪𝒕 Hasta 36 horas 1.00 Desde 36 a 72 horas 0.90 Desde 72 a 108 horas 0.80 Desde 108 a 144 horas 0.70 Desde 144 a 180 horas 0.65 Desde 180 a 360 horas 0.60 Desde 360 a 510 horas 0.55 Tabla P.3. Factor de corrección según las horas trabajadas En este Trabajo Fin de Grado se han invertido 300 horas en las tareas de preparación, desarrollo y documentación necesarias para la elaboración del mismo. Por Presupuesto Página | 112 Ricardo Antonio Rios Peña tanto el factor de corrección correspondiente es 𝐶𝑡 = 0,60 y el resultado de aplicar la ecuación anterior es el siguiente: 𝐻𝑜𝑛𝑜𝑟𝑎𝑟𝑖𝑜𝑠 (€)=(300 ∗58 + 0 ∗ 63)∗ 0,6 = 10.440,00 Los honorarios totales por tiempo dedicado libres de impuestos ascienden a diez mil cuatrocientos cuarenta euros (10.440,00 €). P.3 Material fungible. Los costes relacionados con el material fungible utilizado en la realización de este TFG se detallan en la Tabla P.4. Material Coste Materiales de papelería 10,00 € CD-ROM 5,00 € Impresión 40,00 € Encuadernación 5,00 € TOTAL 60,00 € Tabla P.4. Costes material fungible Los costes totales asociados al material fungible libres de impuestos ascienden a sesenta euros (60,00 €). Presupuesto Ricardo Antonio Rios Peña Página | 113 P.4 Costes de redacción del Trabajo Fin de Grado. El importe de la redacción del proyecto viene definido por la siguiente ecuación: 𝑅 = 0,07 ∗ 𝑃 ∗ 𝐶𝑛 Donde:  𝑃 es el presupuesto del proyecto.  𝐶𝑛 es el coeficiente de ponderación en función del presupuesto. El presupuesto acumulado hasta el momento se muestra en la Tabla P.5. Concepto Coste Recursos materiales 510,00 € Honorarios por tiempo empleado 10.440,00 € Material fungible 60,00 € TOTAL 11.010,00 € Tabla P.5. Presupuesto acumulado El presupuesto acumulado hasta el momento es de 11.010,00 €. Por su parte, el coeficiente de ponderación 𝐶𝑛 tiene valor unitario, ya que se trata de un proyecto que no supera los 30.050,00 € de coste. 𝑅 = 0,07 ∗11.010,00 ∗ 1,00 =770,70 Presupuesto Página | 114 Ricardo Antonio Rios Peña Los costes de redacción del presente TFG libres de impuestos ascienden a setecientos setenta euros con setenta céntimos (770,70 €). P.5 Derechos de visado del COITT. Los gastos de visado del COITT se tarifan mediante la siguiente ecuación: 𝑉 = 0,006 ∗ 𝑃 ∗ 𝐶𝑣 Donde:  𝑃 es el presupuesto del proyecto.  𝐶𝑣 es el coeficiente reductor en función del presupuesto del proyecto. Teniendo en cuenta el presupuesto acumulado hasta el momento asciende a 11.780,70 €, y que el valor del coeficiente 𝐶𝑣 es de valor unidad ya que se trata de un proyecto que no supera los 30.050,00 € de coste, se tiene: 𝑉 = 0,006 ∗11.780,70 ∗ 1,00 =70,68 Los costes de obtención de los derechos de visado del COITT del presente TFG libres de impuestos ascienden a setenta euros con sesenta y ocho céntimos (70,68 €). P.6 Costes de tramitación y envío. Los gastos de tramitación y envío están fijados en 6,01 euros. Presupuesto Ricardo Antonio Rios Peña Página | 115 P.7 Aplicación de impuestos. Para la actividad económica del presente TFG el valor del Impuesto General Indirecto Canario (I.G.I.C.) graba el presupuesto con un 7%. El coste total del proyecto se desglosa en la Tabla P.6. Concepto Coste Recursos materiales 510,00 € Honorarios por tiempo empleado 10.440,00 € Material fungible 60,00 € Costes de redacción 770,70 € Derechos de visado del COITT 70,68 € Costes de tramitación y envío 6,01 € Subtotal 11.857,39 € I.G.I.C. (7%) 830,02 € TOTAL 12.687,41 € Tabla P.6. Coste total del Trabajo Fin de Grado El presupuesto final del presente Trabajo Fin de Grado, titulado “Desarrollo del Firmware de Control de los Nodos de una Plataforma Experimental de WSN”, asciende a un total de doce mil seiscientos ochenta y siete euros con cuarenta y un céntimos (12.687,41 €). Las Palmas de Gran Canaria a 14 de julio de 2015. Fdo.: Ricardo Antonio Rios Peña. Presupuesto Página | 116 Ricardo Antonio Rios Peña Contenido del CD-ROM Ricardo Antonio Rios Peña Página | 117 Anexo I. Contenido del CD-ROM Adjunto a la memoria de este Trabajo Fin de Grado se encuentra disponible un CDROM. En este anexo se describe la estructura del mismo. A.I.I Estructura del CD-ROM. El contenido y la estructura del CD-ROM que se adjunta es el siguiente:  Directorio “Memoria”. Memoria del presente TFG en formato PDF.  Directorio “CAN128ROUTER”. Aplicación router desarrollada.  Directorio “CAN128BOOTLOADER”. Aplicación bootloader desarrollada.  Directorio “CAN128LIB”. Biblioteca CAN desarrollada.  Directorio “Summary”. Resumen del TFG en inglés.