ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA

INGENIERÍA INFORMÁTICA – GRADO EN INGENIERÍA DE COMPUTADORES

Sistema embebido para recolección de datos ambientales alojado en bicicletas de uso público.

Realizado por

ABDESSAMAD EL ABBASSI HAMIDI

Dirigido por

DANIEL CAGIGAS MUÑIZ

Departamento

ARQUITECTURA Y TECNOLOGÍA DE COMPUTADORES

Sevilla, 11 Septiembre de 2014 1

2

Contenido

ÍNDICE DE FIGURAS ...... 5 INTRODUCCIÓN ...... 6 Motivación ...... 6 Objetivos...... 6 Análisis de requisitos ...... 7 DESARROLLO DEL SISTEMA ...... 15 Introducción ...... 15 Desarrollo hardware ...... 20 Sistema de montaje y Alimentación ...... 20 Microcontrolador Cortex-M3 NXP LPC1768 ...... 21 Introduccion ...... 21 Características LPC1768 ...... 24 Sensores de gases resistivos ...... 25 Sensor de humedad y temperatura ...... 33 Módulo uBlox GPS ...... 38 Acelerómetro ...... 40 Modem 3G USB ...... 42 Conversor USB Serial ...... 47 Desarrollo software ...... 48 Introducción ...... 48 Descripción de librerías ...... 51 Mbed-RTOS...... 51 USBHost ...... 52 VodafoneUSBModem ...... 52 HTTPCient ...... 53 Descripción de tareas ...... 54 Descripción sensores ...... 56 Descripción protocolos ...... 57 Protocolo RHT03...... 57

3

Módulo GPS ...... 61 PRUEBAS Y DIFICULTADES ENCOTRADAS ...... 64 Diseño de pruebas ...... 64 Resultado de pruebas ...... 67 Dificultades ...... 72 ANÁLISIS TEMPORAL Y COSTE DE DESARROLLO ...... 72 CONCLUSIONES Y POSIBLES MEJORAS ...... 74 GLOSARIO DE TÉRMINOS ...... 75 ANEXOS...... 76 Instalación del entorno de desarrollo ...... 76 Openocd ...... 76 GCC ARM ...... 78 GNU ARM Eclipse Plugin...... 78 Indicaciones para añadir nuevo Modem USB ...... 79 Descripción Conexiones Junta de desarrollo LPC1768 ...... 80 REFERENCIAS ...... 80

4

ÍNDICE DE FIGURAS Figura 1 estación de bicicletas Sevici ...... 10 Figura 2 configuración sistema M2M ...... 13 Figura 3 IDE Mbed online ...... 18 Figura 4 Entrada alimentación del sistema ...... 20 Figura 5 Junta de desarrolo LPC1768 ...... 22 Figura 6 arquitectura Mbed NXP LPC1768 ...... 23 Figura 7 características típicas de un sensor de gas semiconductor; a) Respuesta transitoria; b) Dependencia de la respuesta con la temperatura; c) Dependencia de la resistencia con la concentración de gas ...... 28 Figura 8 Sensor MQ- 5 ...... 29 Figura 9 Esquematico Sensor MQ- 5 ...... 30 Figura 10 conexión Sensor MQ- 5 ...... 30 Figura 11 Sensor MQ- 7 ...... 31 Figura 12 ciclo precalentamiento MQ-7 ...... 32 Figura 13 esquematico sensor MQ - 7 ...... 33 Figura 14 Conexion MQ- 7 ...... 33 Figura 15 Sensor MHT03 ...... 34 Figura 16 Secuencia de comunicacion serie del MHT03 ...... 35 Figura 17 iniciación Comunicación MHT03 ...... 36 Figura 18 transmisión "0" MHT03 ...... 36 Figura 19 Conexión MHT03 ...... 37 Figura 20 Módulo GPS u-Blox ...... 38 Figura 21 Descripción de pines Modulo GPS ...... 39 Figura 22 Conexión módulo GPS ...... 39 Figura 23 acelerómetro MMA8452 ...... 40 Figura 24 Conexión MMA8452 ...... 41 Figura 25 Modem K3770 vodafone ...... 42 Figura 26 Configuracion low speed con resistencia 1.5 k pull Up ...... 45 Figura 27 Configuración full speed con resistencia de 1.5k de pull up .. 46 Figura 28 Configuración recomendada NXP USB Host ...... 46 Figura 29 Configuración USB Hsot para Modem 3G ...... 47 Figura 30 Arquitectura SDK Mbed ...... 49 Figura 31 Directorios mbed ...... 49 Figura 32 Configuracion sistem de pruebas ...... 65 Figura 33 Descripción de pines LPC ...... 80

5

INTRODUCCIÓN

Motivación

El presente proyecto ha sido llevado a cabo dentro un marco interdisciplinar dentro del proyecto Sinergias (http://personal.us.es/mcromerot/sinergia/).

Se pretende desarrollar un primer prototipo hardware para la adquisición de datos medioambientales y contaminación en el aire en tiempo real. Dicho sistema estará alojado en bicicletas móviles por todo una ciudad, un ejemplo de ello es el servicio de biciclet as en la ciudad de Sevilla, el cual se ha mantenido como destino del dispositivo final. De modo que entre todo los dispositivos alojado en la red de bicicletas de la ciudad forman una red de sensores que permitirá obtener datos medioambientales en tiempo real de gran utilidad para realizar estudios medioambientales, monitorización de concentración de gases contaminantes en distintas zonas de la ciudad, así como detectar los intervalos de tiempo en los que estos son altos, de modo como resultado también puede ser un servicio muy importante para los ciudadanos, como es un sistemas de alertas de zonas con concentración alta de agentes contaminantes peligrosos para la salud.

Sin mencionar el valor añadido que tendría un sistema como este en la ciudad de Sevilla, el cual daría un gran paso al concepto de Smart City.

Objetivos

El principal objetivo de este proyecto es el diseño e implementación de un prototipo hardware basado en microcontrolador para la recogida y envío en tiempo real de los datos medioambientales y gases

6 contaminantes a un servidor remoto, sin olvidar el objetivo personal y académico de aprendizaje sobre las tecnologías utilizadas que permitan complementar y profundizar en los conocimientos adquiridos durante los años del grado en ingeniería de computadores.

Este objetivo puede desglosarse en las siguientes tareas:

- Estudio de las distintas soluciones tecnologías disponibles para determinar el tipo de sistema y tecnologías más adecuadas para el sistema.

- Definición de la estructura del sistema basada en la tecnología determinada en el paso anterior.

- Diseño del sistema definido.

- Diseñar un sistema básico para pruebas.

- Propuesta del prototipo final con un sistema de alimentación basado en batería recargable.

Análisis de requisitos El cometido del sistema a desarrollar es la adquisición de datos a partir de sensores analógicos y digitales y su envío a un servidor remoto, el sistema debe tener sensores para la detección y medición de gases contaminantes, en concreto, concentraciones de monóxido de carbono en el aire y concentraciones de LPG (gas licuado de petróleo (LPG, compuesto en su mayor parte de propano y butano) en el aire. Además de estos datos, es necesario conocer la posición geográfica exacta de estas mediciones y bajo qué condiciones climatológicas, es decir temperatura y humedad en el aire, sin olvidar registrar la fecha y hora exacta de las mediciones realizadas. También es interesante tener información sobre la gravedad en coordenadas XYZ y coordenadas geográficas para posibles extracciones de información sobre rutas y estado de las bicicletas en el momento de la medición.

7

En base a estos requisitos se ha decidido implementar un sistema basado en microprocesador o microcontrolador, para la lectura y envío de los datos al servidor. Dicho requisito implica el diseño de un sistema con una conexión a internet inalámbrica, para ello existen dos soluciones basadas en distintas tecnologías principalmente Telefonía móvil 3G ( GSM/UMTS/HSDPA) y Wifi.

Ambas soluciones requieren de un microcontrolador y dotarlo de dicha habilidad mediante el uso de módulos hardware externos, actualmente muy extendidos en el desarrollo de sistemas M2M (Machine to Machine) que avanza en el concepto de “Internet of things” (internet de la cosas). El primer concepto hace referencia a la comunicación directa o intercambio de información, comunicación en formato de datos entre dos máquinas remotas, donde se ejecuta una aplicación con una lógica de negocio definida.

Un dispositivo en un sistema M2M también constar de capacidad de proceso de datos. Este dispositivo por una parte implementa el protocolo específico de para poder comunicarse con la máquina y por otra parte implementa el protocolo de comunicación para el envío de información.

El segundo concepto (“Internet of things”) se refiere a la interconexión digital de objetos o sistemas muy básicos con Internet. Alternativamente, Internet de las cosas es el punto en el tiempo en el que se conectarían a Internet más “cosas u objetos” que personas.

Volviendo a nuestro sistema, existen varias soluciones cada una de ellas con sus ventajas e inconvenientes, sin embargo se puede clasificar en dos tipos, donde el factor de diferenciación radica en la naturaleza de la tecnología de conexión inalámbrica. Podemos clasificarlos en sistemas que requieren disponer en sistemas de una serie de estaciónes base que son la que tendrían la tarea de enviar los datos al servidor, y los que son pueden ser totalmente independientes de cualquier tipo de estación ba se,

8 distinta al servidor remoto, todo esto visto desde el punto de vista del sistema de red final necesario a implementar.

Wifi

Cuando hablamos de WIFI nos referimos a una de las tecnologías de comunicación inalámbrica mediante ondas más utilizada hoy en día. WIFI, también llamada WLAN (wireless lan, red inalámbrica) o estándar IEEE 802.11. Su alcance es de unos 100-150 metros en hardware asequible

Dentro de los que necesitan una estación base se encuentra, los sistemas que utilizan, Wifi. Lo que tienen en común estas tecnologías es la distancia máxima a la que debe estar el sistema final, es decir con el que es necesario realizar el enlace de comunicación de datos. Esto implica hacer un diseño basado en nodos.

En el caso de Wifi, es necesario un punto de acce so a la red de internet al cual se debe de asociar el dispositivo para enviar los datos al servidor, el número de puntos de acceso varía dependiendo de la zona geográfica objeto de estudio y donde el intervalo de tiempo para realizar el muestreo de los datos se ve directamente afectado y descontrolado, dado que sería muy difícil de estimar cada cuanto tiempo pasa una bicicleta por un punto de acceso. Esto sería adecuado si el tiempo para disponer de los datos en el servidor no es crítico y puede demorarse hasta varias horas, la arquitectura estaría compuesta de muchos puntos de acceso colocados en puntos de la ciudad cuidadosamente elegidos, donde se ha tenido en cuenta todos los factores de tiempo antes mencionados. Otra opción para usar esta tipo de tecnología es que el dispositivo almacene las muestras recogidas con los sensores en alguna unidad de almacenamiento tipo memorias flash hasta alcanzar un punto de acceso estable, es decir, poniendo como ejemplo el sistemas de bicicletas de Sevilla, colocar l os puntos de acceso en los aparcamientos de bicicletas del Sevici disponibles en toda la ciudad.

9

Figura 1 estación de bicicletas Sevici

Anotaciones a tener en cuenta para el desarrollo de un sistema usando la tecnología Wifi.

- Dado que el dispositivo posiblemente será alimentado mediante baterías recargables, el proceso de asociación y des asociación del dispositivo con los puntos de acceso conlleva un gasto considerable de energía eléctrica, sumado al del propio dispositivo y sensores acoplados. - No se dispondrá de los datos de forma inmediatamente posterior a la realización de las mediciones, sino que habrá un retraso de incluso varias horas.

10

- El almacenamiento temporal de los datos conlleva a tener en cuenta que el dispositivo deberá poseer memoria suficiente, lo que implica el uso de unidad de almacenamiento por motivos de seguridad y no confiar el almacenamiento a memorias volátiles dado que el dispositivo será pendiente de la duración de la batería.

Telefonía móvil 3G

La segunda opción es disponer de un sistema que hace uso de tecnología s de Telefonía móvil 3G.

3G es la abreviación de tercera generación de transmisión de voz y datos a través de telefonía móvil mediante UMTS (Universal Mobile Telecommunications System o servicio universal de telecomunicaciones móviles).

Los servicios asociados con la tercera generación proporcionan la posibilidad de transferir tanto voz y datos (una llamada telefónica o una videollamada) y datos no-voz (como la descarga de programas, intercambio de correos electrónicos, y mensajería instantánea).

Aunque esta tecnología estaba orientada a la telefonía móvil, desde hace unos años las operadoras de telefonía móvil ofrecen servicios exclusivos de conexión a Internet mediante módem USB, sin necesid ad de adquirir un teléfono móvil, por lo que cualquier computadora puede disponer de acceso a Internet. Existen otros dispositivos como algunos ultraportátiles (netbooks) y tablets que incorporan el módem integrado en el propio equipo. En todos los casos requieren de una tarjeta SIM para su uso, aunque el uso del número de teléfono móvil asociado a la tarjeta para realizar o recibir llamadas pueda estar bloqueado o estar asociado a un número con contrato 3G.

Ventajas: 11

El protocolo IP está basado en paquetes, pues solo se paga en función de la descarga lo que supone, relativamente, un menor costo.

Velocidad de transmisión alta: fruto de la evolución de la tecnología, hoy en día se pueden alcanzar velocidades superiores a los 3 Mbit/s por usuario móvil.

Mayor velocidad de conexión, ante caídas de señal.

Desventajas:

Dependiendo de la localización, la velocidad de transferencia puede disminuir drásticamente (o incluso carecer totalmente de cobertura).

Disminución de la velocidad si el dispositivo desde el que nos conectamos está en movimiento.

Elevada latencia respecto a la que se obtiene normalmente con servicios ADSL. La latencia puede ser determinante para el correcto funcionamiento de algunas aplicaciones del tipo cliente-servidor.

Elevada Tasa de Absorción Específica (SAR)

Aparición del efecto conocido como "respiración celular", según el cual, a medida que aumenta la carga de tráfico en un sector (o celda), el sistema va disminuyendo la potencia de emisión, o lo que es lo mi smo, va reduciendo el alcance de cobertura de la celda, pudiéndose llegar a generar zonas de "sombra" (sin cobertura), entre celdas adyacentes, además de acarrear un importante consumo de energía eléctrica.

El uso de esta tecnología en el sistema a desarrollar, supone un incremento en la complejidad en dispositivo móvil en sí y no en la arquitectura del sistema completo y no requiere de estaciones bases propias.

Dada la naturaleza de los requisitos temporales y de conexión, se ha decidido utilizar esta tecnología. Par ello los operadores de telefonía

12 disponen de servicios especiales conocido de hecho por servicio M2M, algunas a considerar para sistema final en relación a estos servicios.

Figura 2 configuración sistema M2M

Precio de la tarjeta SIM para M2M:

El operador pone a nuestra disposición una tarjeta SIM para la conectividad. Ese coste no tiende a 0 como para una línea de voz tradicional. La razón es que el ingreso medio que obtiene el operador de una línea M2M dista mucho de la telefonía tradicional y el despliegue se realiza sobre varios centenares de líneas móviles (es una inversión).

Precio del MB :

Las aplicaciones M2M suelen necesitar una cantidad de datos que ronda los pocos megas. Existen 3 modalidades de pago: Todo in cluido en una franquicia, pago por uso o prepago. El pago por uso tiene la ventaja de adaptarse al uso real que hacemos de la línea pero suele acarrear un pago mensual fijo. De todos modos en M2M solo pagaremos por la línea cuando está activada (es decir en uso); lo que la diferencia claramente de una línea móvil de voz clásica (que pagamos cuando la adquirimos o cuando se activa la tarifa independientemente de su uso).

Tipo de tarjeta SIM para M2M

La tarjeta SIM clásica es la que utilizamos en un teléfono móvil normal. Pero existen otros tipos de tarjetas más idóneas para las aplicaciones

13

M2M. Unas tienen un soporte de plástico y resisten a altas temperaturas, otras son soldables.

Homologación del dispositivo

El dispositivo que utiliza la tarjeta SIM tiene un comportamiento hacía la red del operador móvil que debemos controlar. Los intentos de conexión fallidos y repetidos pueden sobrecargar la red del operador y ese puede decir bloquear los intentos de conexión. Es importante que el dispositivo esté homologado en la red del operador (al igual que lo es un teléfono móvil clásico). Los intentos de lectura/escritura agresivos de la tarjeta SIM puede desgastarla e invalidarla.

Tiempo de activación

Las líneas M2M entran en un proceso industrial con la inclusión d e la tarjeta SIM en una cadena de producción. El dispositivo que incluye la tarjeta SIM suele ponerse a la venta o instalarse después de un tiempo de almacenamiento. Hay que tomar en cuenta estos tiempos. Calculamos que una tarjeta M2M tarda de media unos 6 meses en activarse (dependiendo del tipo de aplicación).

Plataforma de gestión

Los despliegues de aplicaciones M2M son de varios centenares de líneas móviles y precisan de una plataforma potente. Su principal virtud es que nos independizan del operador para la gestión de líneas: Podemos activar las líneas, desactivarlas, retirarlas del parque a nuestro antojo y directamente a través de un interfaz Web. La plataforma nos debe ofrecer la posibilidad de consultar las facturas en línea de nuestro consumo.

Inclusión de los SMS y de la voz

14

Las líneas M2M son típicamente líneas móviles de datos pero a menudo tenemos que considerar la inclusión de los SMS. Suelen servir para la gestión remota del dispositivo cuando no disponemos de cobertura GPRS.

Cobertura simple o doble de operadores

Existe la posibilidad de trabajar con 2 operadores en vez de uno solo. Tiene la ventaja de que reducimos los problemas de cobertura y de dependencia hacía un solo operador. La tarjeta SIM que se considera entonces es una SIM en itinerancia (o global). La utilización de una SIM global capaz de trabajar en varios países implementa una serie de mecanismos de selección del operador que pueden ralentizar el arranque del dispositivo (al igual que cuando bajamos del avión con un teléfono n ormal).

DESARROLLO DEL SISTEMA

Introducción

En base a los requisitos del sistema y la decisión de usar la tecnología de red móvil para el envío de los datos al servidor, se ha comenzado una intensa investigación y estudio de ésta tecnología en busca de que soluciones ofrece el mercado para realizar este tipo de conexiones. Comenzado con módulos GSM/GPRS basados en chips SIM900 principalmente que se ofrecen con sus respectivas especificaciones y permiten una conexión con los sistemas mediante conexión s eries a través de UARTS principalmente y usan un protocolo basado en comandos AT siguiendo las especificaciones de la 3GPP 3rd Generation Partnership Project, la cual es un es una colaboración de grupos de asociaciones de telecomunicaciones, conocidos como Miembros Organizativos. El objetivo inicial del 3GPP era asentar las especificaciones de un sistema global de comunicaciones de tercera generación 3G para móviles basándose en las

15 especificaciones del sistema evolucionado "Global System for Mobile Communications" GSM dentro del marco del proyecto internacional de telecomunicaciones móviles 2000 de la Unión Internacional de Telecomunicaciones ITU.

Estos módulos descritos tienen la desventaja de ser extremadamente difíciles de integrar y configurar para una red de una operadora en concreto y sin hablar de su alto coste, que comienza a partir de unos 45 euros los modelos más sencillos. Para el sistema final se puede considerar estos módulos y la posibilidad de imitarlos dado que todos están basados en mismo chip y existe información y documentación suficiente para implantarlos en un diseño propio. El otro inconveniente de estos módulos es que sus fabricante no ofrecen software de prueba el cual integre soporte para conexiones usando el protocolo TCP/ IP necesar io para la comunicación con el servidor, y nos veríamos en la ardua tarea de implementarlo o de portar una pila TCP/IP existe de tercero a nuestro sistema.

A raíz de estos inconvenientes se ha contemplado otras soluciones más adecuadas para un primer prototipo, y que no suponga un alto coste. La segunda opción es usar un modem 3G USB de los muchos que se pueden encontrar en la actualidad, los cuales son ofrecidos por diversas operadoras de telefonía móvil. El primer intento ha sido utilizar uno de estos módems con una placa de desarrollo basadas en un microcontrolador STM32F4. La utilización de estos modem añade una complejidad en el desarrollo bastante elevada dado que no existe documentación técnica de estos productos, ya que están diseñados para uso cotidiano y no de desarrollo, la mejor documentación que se puede encontrar son los intentos de desarrollo de un driver para Linux abierto. En muchos casos es suficiente para tener una idea de su funcionamiento, en apartados futuros detallaremos el funcionamiento general y un caso concreto de estos módems.

16

Afortunadamente, fruto de una exhaustiva búsqueda de una solución dentro de los sistemas sistemas embebidos, se ha encontrado un proyecto de Vodafone en colaboración con la plataforma Mbed.org para dar soport e a uno de sus modem USB más común en el mercado el modelo k3770 para su plataforma. Dicho desarrollo está basado en su placa de prototipado mbed NXP 1768, este desarrollo junto con el uso a varias librerías de esta plataforma nos darán una completa solución para realizar la conexión con el servidor.

MBED es una plataforma online gratuita, la cual te brinda una serie de herramientas como un compilador C/C++, almacenamiento de archivos y proyectos, la posibilidad de poder compartirlos y una serie de librerí as como Ethernet (TCP IP), USB Host y Device, UART, ADC, etc; también como comunicación con pantallas gráficas, sensores I2C, SPI, memorias EEPROM, SD Card. etc. Haciendo en suma, una valiosa herramienta a la hora de desarrollar proyectos fácil y rápidamente, sin necesidad de desarrollar todo desde cero.

MBED es un proyecto desarrollado originalmente en Inglaterra, por un grupo de entusiastas, y con la colaboración de la empresa NXP (antes Phillips) para promocionar sus microcontroladores ARM Cortex M3 LPC, a medida que fue pasando el tiempo, esta herramienta se fue haciendo más popular, y fueron añadiendo más familias de microcontroladores de diferentes fabricantes. Todos bajo un mismo concepto y requisito, y es que sean con un núcleo ARM Cortex M.

17

Figura 3 IDE Mbed online

El compilador es una aplicación web que corre directamente en tu navegador (una idea novedosa), lo cual significa que no necesitas instalar ni configurar ningún software IDE en tu sistema local, aunque debes pose er una conexión a internet para acceder al compilador. También tienes un acceso a las librerías mbed online, las cuales te proporcionan una API que te permiten usar las variadas funciones del microcontrolador.

El compilador en línea está basado en RealView MDK, el mismo compilador que encontramos en el IDE KEIL de ARM , también en DS – 5 ARM el cual es un ide multiplataforma basado en el famoso IDE eclipse. No obstante actualmente la herramienta en línea ofrece exportar nuestro código a varios compiladores o entornos de desarrollos, entre ellos GCC Arm Toolchain. Hay que tener en cuenta que no todo el software disponible como librerias y ejemplos es compatible con otros compiladores distintos a RealView MDK y no todo el software se puede exportar a otros I DE, esto dependerá de la plataforma hardware mbed que utilicemos, el caso mas claro actualmente se encuntra en los nuevos modelos ST nucleo de ST microelectronic donde hasta la fecha solo es compatible con Realview, y requiere de modificaciones sobre el SDK de mbed para funcionar con otros 18 compiladores. Además de no disponer de muchas librerías como mbed RTOS, USB Host o Device, Parte importante del tiempo dedicado a este proyecto se ha centrado en portar dichas librerias a la placa ST Nucleo F401RE dado a la diefernecia de precio con respecto a otras plataformas , hasta la fecha se hecho fucncionar RTOS y USB Device realizando ciertas modificaciones sobre el hardware para hacer funcionar la interface USB sin mucho éxito dado a la gran complejidad de este protocolo de comunicaciones , dicha interfaz a implicado la adicion de un reloj externo para generar disponer de una señald e reloj lo mas estable posible de USB, el cual necesita que de 48 MHz. Dado la restricciones de tiempo para dedicar al proyecto son muy acotadas se ha apartado el uso de la plataforma STM32 a la espera de soporte en USB Host a favor un LPC1768 acualmente soportado por la plataforma Mbed , no obstante se ha incluido en DVD software fruto de esta investigación, entre ello proyectos preparados para eclipse y GCC ARM para los microcontroladores stm32F401xx y stm32f407VG, en concreto la placas de desarrollo Nucleo F401RE y Stm32F4 Discovery, dichos proyecto incluyen librerias RTOS mbed funcional y USB Device.

Para este proyecto se ha hecho uso los dos compiladores (RealView y GCC), además se incluye al final de este documento un anexo para configurar un entorno de desarrollo usando GCC y Eclipse lo cual ofrece una ciertas de ventajas que facilitan el desarrollo dado que abstrae del manejo del fichero Makefile para la compilación y linkado en tanda de nuestros ficheros de código, dado que para el sistemas GNU/Linux hasta la fecha de este documento no existe ningún entorno integrado de desarrollo para plataformas ARM.

Para la programación y depuración se usará el programador ARM-USB-OCD de Olimex junto con la herramienta de programación de microcontroladores ARM Openocd.

19

Al final de este documento se encuentra un anexo sobre cómo configurar esta herramienta bajo el sistemas GNU/Linux utilizar esta herramienta.

Desarrollo hardware

En esta sección se describirán los componentes que se han utilizado para desarrollar el prototipo construido en este trabajo.

Sistema de montaje y Alimentación

Figura 4 Entrada alimentación del sistema

En un principio se ha hecho el montaje del sistema sobre una Breadboard de prototipado, en la cual como se puede observar en la figura de arriba incorpora un sistema de alimentación controlada, dicho puede obtener corriente desde una fuente de alimentación de pared de un rango entre 6.5 y 12 Voltios o bien a través del puerto USB de un PC. También permite seleccionar para cada una de las líneas de alimentación de la breadboard tener un voltaje de 3.3V o bien 5V totalmente independientes. De estas dos líneas se alimentan todos los sensores, módulos y componentes del sistema.

20

Microcontrolador Cortex-M3 NXP LPC1768

Introduccion Tal como se ha reflejado en el apartado anterior el soporte para este microcontrolador en la plataforma mbed ha sido decisivo para su elección como elemento principal del prototipo.

Mbed dispone de una plataforma de desarrollo basada en el NXP LPC1768, el inconveniente de esta es su coste de adquisición que supera los 50 euros por unidad. De modo que buscando alternativas se ha decido comprar una junta de desarrollo con el mismo o compatible microcontrolador. Dicha no incluye ningún periférico adicional solo mapea todas los pines del microcontrolador en cuatro pares de tiras tal como se observa en la figura a excepción de la entrada de alimentación que ofrece dos entradas, una a través de USB y otra dedicada , además de un cuarzo de 12Mhz externo lo que nos permite trabajar a la más alta frecuencia con la mejor estabilidad de frecuencia, algo indispensable si se desea usar periféricos tan estrictos como controlador de USB Host . Dado que de origen incorpora un bootloader para su programación usando la técnica de drag and drop, ya que monta la memoria flash como almacenamiento en nuestro pc permitiendo copiar directamente el binario y luego acometer un reset para su ejecución . Este bootloader ha sido eliminado dado que no puede ser usado por nuestra aplicación. En las pruebas realizas el firmware basado en el SDK de mbed no llegaba a iniciarse debido al offset en la memoria flash, que provoca el que script de inicialización no pueda copiar la tabla de vectores de interrupción en RAM, y por tanto el cargador inicial termina por no encontrar la entrada a la posición de memoria de Reset_Handler. Afortunadamente esta junta de desarrollo también incorpora la interfaz de programación JTAG de 20 pines con lo que es posible utilizar un programador depurador ARM jtag

21 para cargar y depurar nuestra aplicación, en nuestro caso utilizaremos el ARM-USB-OCD de Olimex junto con Openocd.

Figura 5 Junta de desarrolo LPC1768

Posteriormente se ha tenido que realizar ciertas modificaciones a la junta para su correcto funcionamiento con nuestro propósito . Dichos cambio incluyen la supresión de las resistencias R1, R2 y R3, desoldando éstas físicamente de la junta. Esto es debido a los requisitos de funcionamiento de controlador USB. Dado que la resistencia R3 hace de resistencia de pullUp desde D+ de forma activa y permanente esto identifica el modo USB Device para el microcontrolador tal como se explicará en breve, esto impide que el controlador de USB pueda ponerse en modo HOST. La resistencia R2 y R1 no era necesaria su supresión, pero se ha realizado evitar posibles caídas de tensión si se alimenta mediante cable USB. La Otra modificación ha sido la adición de tiras de pines para facilitar la conexión de los componentes.

La plataforma mbed NXP LPC1768 es bastante más compleja, como se ilustra en la siguiente figura. Hay que tener en cuenta la ausencia de estas características en nuestro diseño y realizar los cambios indicados en el apartado siguiente para un correcto funcionamiento.

22

Figura 6 arquitectura Mbed NXP LPC1768

Ésta, está compuesta de una interfaz (mbed interface) para la programación y depuración compatible con el nuevo estándar depuración CMSIS-DAP de ARM, el cual permite el acceso al DAP ( Coresight Debug Access Port) de core ARM Cortex a través de USB, en el caso de la mbed nxp lpc1768 se encuentra implementado en un LPC11xx. Este a su vez es capaz de acceder al core del LPC1768 a través de su interfaz JTAG/SWD . Ésta interfaz no necesita de software adicional en PC para programar el binario en la flash del LPC1768, sino que al conectarlo al PC aparece una una unidad de almacenamiento para copiar el binario, y al aplicarle un reset al sistema este automáticamente cargado y ejecutado. Esto lo lo consigue gracias a una memoria flash de 16 Mb que usa como almacenamiento temporal. También mediante “Semihosting” es la salida estándar de Entrada salida de la librería de C, en el SDK mbed a través de una conexión directa a una de las entradas UART del micro controlador, además ofrece otras utilidades accesibles desde la API del SDK como la posibilidad de hacer un hardware reset, utilizar l a unidad flash de 16 Mb como unidad de almacenamiento local en la aplicación mediante la librería LocalFilesystem y todo esto usando la ventaja de Semihosting

23 mediante la comunicación serie. Ademas de esto esta plataforma incluye una interfaz Ethernet PHY.

Características LPC1768

El microcontrolador Cortex-M3 LPC1768 cuenta con un alto nivel de integración y la mejor compatibilidad con periféricos a frecuencias de hasta 100 MHz. La arquitectura ofrece un bus AHB multicapa que admite varios flujos de datos de banda ancha que se ejecutan simultáneamente desde periféricos tales como Ethernet, USB o CAN. En la serie, cada MCU es compatible con las clavijas de las series ARM7 LPC2x00 y Cortex - M4/M4F LPC4000.

Características

- Núcleo ARM Cortex-M3 - Funcionamiento de hasta 120 MHz - Controlador de interrupción de activación para encendido automático desde cualquier función de irrupción prioritaria - Unidad de protección de memoria - Consumo de energía en modo activo: 420 μA/MHz - Cuatro modos de consumo reducido: Inactivo (2 mA), Inactivo completo (240 μA), Apagado (31 μA), Apagado completo (630 nA)

Memorias

- Hasta 512 KB de memoria Flash - Hasta 64 KB SRAM

Periféricos seriales

- Dispositivo USB 2.0 de máxima velocidad/host/controlador de OTG con PHY en chip - Cuatro UART con índice de generación de baudios fraccional, control de módem E/S RS-485 y IrDA

24

- Dos controladores CAN 2.0B - Tres controladores de SSP/SPI - Tres interfaces l2C-bus con un soporte rápido modo plus (tasas de datos de 1 Mbit/s) - Interfaz l2S de audio digital

Periféricos analógicos

- ADC de 12 bits con ocho canales - DAC de 10 bits

Otros periféricos:

- Reloj en tiempo real con funcionamiento a <1 uA - Hasta 70 GPIO - Interfaz PWM de control de motor y codificador de cuadratura para impulsar motores trifásicos - Cuatro temporizadores/contadores de uso general de 32 bits - Oscilador RC interno de 4 MHz con 1% de precisión

Compatibilidad y migración

- Series compatibles con clavijas de las series ARM7 LPC2x00 y Cortex - M4/M4F LPC4000

Sensores de gases resistivos

Los sensores de gases resistivos en adelante SGR son un conjunto de sensores que detectan la concentración de distintos gases en el aire. Se basan en la variación de la conductividad que presentan algunos materiales semiconductores ante la presencia de dichos gases. Los SGR tienen gran cantidad de usos. Son los componentes principales de numerosos sistemas de seguridad gracias a su capacidad de detectar gases inflamables o tóxicos. También podemos encontrar estos sensores en otros ámbitos como en los alcoholímetros o como parte del sistema de regulación de la combustión en los motores de los vehículos.

Los SGR son sensores que tienen una resistencia base llamada resistencia al aire o RA formada por un material semiconductor. A través de un

25 proceso su resistencia varía ante la presencia de algunos gases pasando a tener una resistencia RG. Si hacemos circular una corriente por el semiconductor veremos cómo varía la conductividad del mismo. Así, con una serie de pruebas con concentraciones conocidas de gases seremos capaces de calibrarlo para medir la concentración que haya en todo momento.

En la figura tenemos un resumen del comportamiento de uno de estos sensores bajo distintas circunstancias -en la figura a se nos muestra la respuesta del sensor en función del tiempo-. Se observa como claramente al introducir un gas determinado la resistencia del sensor disminuye. Cuando se extrae el gas el sensor recupera su resistencia original. Este comportamiento es en realidad el comportamiento en un laboratorio. En los sensores comunes la variación de la resistencia ante la presencia del gas es casi inmediata pero la recuperación no lo es. Es lógico ya que en el laboratorio podemos extraer el gas de muestra en un momento mientras que fuera debemos esperar a que se diluya poco a poco la concentrac ión hasta recuperar la atmósfera normal -en la figura b vemos la respuesta del sensor a una concentración dada en función de la temperatura -. En primer lugar llama la atención que el sensor tiene que trabajar a una temperatura bastante alta. Esto es necesario para que se produzca el fenómeno físico en el que se basa. Pero afortunadamente sólo es necesario que esté a esa temperatura la resistencia semiconductora por lo que con incluir un calentador en el sensor basta. De hecho el consumo de estos sensores es casi exclusivamente producido por el calentador. Esto aunque por un lado es una desventaja también nos puede beneficiar ya que nos permite trabajar en un rango relativamente amplio de temperaturas. En este ejemplo si el calentador estuviese programado par a alcanzar 350°C podríamos trabajar entre -50°C y 50°C aunque perderíamos exactitud. En función de nuestras necesidades deberemos informarnos de la temperatura adecuada a la que trabaja cada sensor y del error que nos proporcionaría trabajar en otras temperaturas. - en la figura c tenemos la

26 variación de la resistencia en función de la concentración de gas. Como vemos el rango de entrada es bastante alto pues se puede medir en este caso desde 0 hasta 1000 ppm. Además su comportamiento es muy lineal por lo que no necesitamos cálculos muy complicados para determinar la concentración una vez calibrado. Este conjunto de sensores es muy utilizado en aplicaciones cotidianas gracias a su facilidad de uso a su pequeño tamaño y por lo general a su bajo precio. Por ot ra parte esto conlleva algunas desventajas. En primer lugar el comportamiento depende mucho de la composición exacta a nivel microscópico del material por lo que debemos calibrar muy bien cada sensor que utilicemos. Además aunque el rango de temperaturas para obtener medidas es bastante alto en seguida se notan variaciones en la medida en función de la temperatura. Por tanto la precisión de estos sensores depende mucho de las condiciones ambientales así como su exactitud pues aunque estemos a temperatura constante podemos obtener valores que no son los esperados. Así estos sensores son utilizados para aplicaciones sencillas. Por ejemplo podrían ser utilizados para determinar la presencia de un gas tóxico ya que no es necesario que sepamos la concentración exacta. Aun así estos sensores se pueden mejorar por ejemplo incluyendo un sensor de temperatura que permita variar los calentadores a la temperatura óptima.

27

Figura 7 características típicas de un sensor de gas semiconductor; a) R espuesta transitoria; b) Dependencia de la respuesta con la temperatura; c) Dependencia de la resistencia con la concentración de gas

Para construir nuestro prototipo haremos uso de dos sensores entre los tantos existentes dependiendo del gas a detectar, en nuestro caso como caso práctico de funcionalidad nos interesa sensor de monóxido de carbono y de gas licuado de petróleo. No obstante en un futuro se puede añadir más sensores para diferentes gases.

Para nuestro prototipo hemos adquirido módulos que incorporan la circuitería analógica necesaria incluida, dado que no es objetivo del proyecto profundizar en la física de estos sensores sino más bien su integración con un sistema digital, y el tratamiento de los datos se

28 realizará en otra aplicación software en servidor para su posterior explotación junto con otros parámetros.

MQ-5

El MQ5 se utiliza en equipos de detección de fugas de gas en aplicaciones domesticas e industriales, este sensor es adecuado para la detección de Gas LP, gas natural, gas de carbón. Evite el vapor de alcohol, humo de la cocina y el humo del cigarrillo. La sensibilidad puede ser ajustada por el potenciómetro.

Figura 8 Sensor MQ- 5

Características:

- Rango de detección: a 300 10000 ppmm - Las características de gas: 1000 ppmm isobutano - La sensibilidad: r en el aire/rin típico de gas 5 o superior - Sensible a la resistencia del cuerpo: k 1& omega; a k 20& omega; ppm 50 en tolueno - Tiempo de respuesta: 10 s o menos - El tiempo de recuperación: 30 s o menos - Resistencia al calor: 31 Ohmios +/- 3 - La corriente de calentamiento: 180 ma o menos - La tensión de calentamiento: v 5.0 +/0.2- v

29

- Energía de la calefacción: mw 900 o menos - Medir la tensión: 24 v o menos - Las condiciones de trabajo de la temperatura ambiente: - 20 ~ + 55 - La humedad: 95% rh o menos - Del medio ambiente de contenido de oxígeno: 21% - La temperatura de las condiciones de almacenamiento:- 20 ~ + 70 - La humedad: 70% rh o menos

Esquemático del módulo mq-5:

Figura 9 Esquematico Sensor MQ- 5

El sensor se encuentra conectado a la entrada analógica del LPC 1768 número P0_24 como indica la figura:

Figura 10 conexión Sensor MQ- 5 30

MQ-7

Figura 11 Sensor MQ- 7

Este es un sensor que se usa para detectar la presencia de monóxido de carbono .El sensor MQ - 7 Puede detectar concentraciones de gas en cualquier rango dentro de las 10 hasta las 1000 ppm (ppm= partículas por millón).

Este sensor tiene una alta sensibilidad y un tiempo de respuesta rá pido. La salida del sensor tiene una resistencia analógica que varía de 0 a 5 volts

La temperatura del ambiente no afecta en la medición de monóxido de carbono, ya que el sensor trabaja en un rango de - 20°C a 50°C aproximadamente

La capa sensitiva de los componentes del sensor MQ - 7 está hecha de SnO2 con estabilidad, de modo que tiene una excelente sensibilidad a largo plazo. Su vida de servicio puede alcanzar 5 años. Para su correcto funcionamiento requiere de un tiempo de precalentamiento de 60 a 90 segundos con un rango de lectura del sensor de 20 a 2000 ppm .

31

Figura 12 ciclo precalentamiento MQ-7

Características técnicas:

 Resistencias de sensibilidad :2K to 20K in 100ppm co.  Sensibilidad:3%.  Tiempo de respuesta :1s.  Tiempo de recuperacion :30s.  Heating Resistance:313.  Heating Current:180mA.  Voltaje de calentamiento: 5.0V0.2V /1.50.1V.  Potencia de calentamiento: alrededor 350mW.  Rango de temperatura :-20 +50.  Humedad: 95%RH.  Contenido de oxígeno: 21%.  Tamaño: 3.5cm X 2.2cm - 1.4inch x 0.9inch.  . La sensibilidad puede ser ajustada por el potenciómetro.

32

Figura 13 esquematico sensor MQ - 7

El sensor se encuentra conectado a la entrada analógica del LPC 1768 número P0_25 como indica la figura:

Figura 14 Conexion MQ- 7

Sensor de humedad y temperatura

33

El RHT03 (también conocido como RHT-22, DHT22, AM2302) es un sensor de humedad y temperatura de bajo costo, con una única interfaz digital. El sensor está calibrado y no requiere de componentes adicionales para que pueda obtener la medición de la humedad relativa y la temperatura dado que está dotado de un microcontrolador de 8 bits interno encargado de la comunicación también. El protocolo de comunicación es a través una señal digital, por lo tanto hace que la integración de este sensor en nuestros proyectos sea rápida y sencilla. Además presenta un tamaño reducido y puede transmitir hasta 100 metros de distancia.

Características.

Figura 15 Sensor MHT03

 Entrada 3.3 - 6V  1 - 1.5mA consumo de corriente durante medida  40 - 50 uA consumo en reposo

34

 Mediada de la humedad en el rango 0-100% RH  Rango de temperatura -40 - 80 grados C,  Precisión +-2% RH accuracy  Precisión +-0.5 grados C

Funcionamiento

Figura 16 Secuencia de comunicacion serie del MHT03

El microcontrolador (LPC) inicia la comunicación configurando el pin como salida y enviando la señal de Start. Esta señal consiste en establecer nivel bajo durante un mínimo de 1ms – 10 ms y nivel alto durante 20us - 40us. A continuación ponemos el pin como entrada y el sensor responderá estableciendo un nivel bajo de 80us y un nivel alto de 80us. Acto seguido, el sensor enviará 5 bytes (40 bits) de forma continua. El primer bit recibido de cada byte será el más significativo.

35

Figura 17 iniciación Comunicación MHT03

Cada uno de los bits se envía siguiendo esta estructura. Cuando el sensor va a enviar un bit, siempre tira la línea abajo durante 50us, y luego l a levanta durante 26 - 28us para señalizar un "0", o durante 70us si quiere enviar un "1"

Figura 18 transmisión "0" MHT03

36

Cuando se han enviado todos los bits, el sensor baja la línea durante 50us y luego la libera.

El protocolo 1 - wire requiere de la existencia de una resistencia de pull - up para que cuando está libre se mantenga a nivel alto. Una vez terminada la transmisión, el sensor pasa al estado de bajo consumo de energía.

Figura 19 Conexión MHT03

37

Módulo uBlox GPS

Figura 20 Módulo GPS u-Blox

El Modulo GPS UBLOX NEO-6M con la antena incluida está basado en el chip de arquitectura UBLOX NEO-6M-0-001 puede ser integrado en un dispositivo y recibidor como un PND, Mouse GPS, Rastreadores de Auto, Detector de velocidad y muchas otras aplicaciones más. Este modelo en especial incorpora una función de almacenamiento EEPROM, donde se almacenaran los datos de forma temporal para mantener dichos datos en la memoria incluye una pequeña batería. Velocidad de transmisión: 4800 ~ 115200 (cualquier configuración) y requiere de una alimentación de 5v.

Caracteristicas:

- Menos de 1 segundo para primera lectura en los inicios rápidos o asistidos. - SuperSense ® GPS Interiores: -162 dBm de sensibilidad de rastreo. - Tecnologías Anti-jamming - Soporta SBAS (WAAS, EGNOS, MSAS, GAGAN) - sistema de posicionamiento de 50 canales de u-blox 6, con más de 2 millones de correlatores efectivos. - Timepulse

38

- Rango de actualización de posición 5Hz - Rango de temperatura de operacion: -40 TO 85°C - Socket UART TTL - EEprom para guardar configuraciones - Batería recargable para respaldos - Antena GPS Cerámica de 25X25mm - RoHS compliant

La conexión con el microcontrolador se realiza a través de un puerto serie (UART), en nuestro caso se ha conectado al pin RX – P0.1, a continuación se describe la interfaz de conexión serie incluida en el módulo GPS.

Figura 21 Descripción de pines Modulo GPS

Figura 22 Conexión módulo GPS

39

Acelerómetro

Figura 23 acelerómetro MMA8452

El acelerómetro es un dispositivo que se encarga de medir el grado de aceleración aplicado y mediante un procesamiento adicional se puede obtener la posición relativa del mismo con respecto al plano horizontal de tierra. En este prototipo se ha seleccionado el MMA8452 Q como acelerómetro digital de 3 ejes con 12 bits de resolución y bajo consumo, el cual se comunica con el controlador a través del Bus I2C a 800 Mhz. que permite obtener valores de aceleración a una frecuencia muy eleva - da, muy superior a la frecuencia mínima requerida para determinar la posición de la mano con suficiente precisión.

El MMA8452Q se puede configurar por software para cambiarle el fond o de escala, que para esta aplicación, dado que no vamos a necesitar detectar con precisión aceleraciones muy bruscas, se ha configurado para medir ±2g/±4g/±8g.

I2C es un protocolo de comunicación serie diseñado por Philips que se utiliza esencialmente entre dispositivos que pertenecen al mismo circuito, por ejemplo, sensores con un microcontrolador.

Las características del bus I2C son:

40

- Se necesitan solamente dos líneas, la de datos (SDA) y la de reloj (SCL). - Cada dispositivo conectado al bus tiene un código de dirección seleccionable mediante software. Habiendo permanentemente una relación Master/ Slave entre el micro y los dispositivos conectados - El bus permite la conexión de varios Masters, ya que incluye un detector de colisiones. - El protocolo de transferencia de datos y direcciones posibilita diseñar sistemas completamente definidos por software. - Los datos y direcciones se transmiten con palabras de 8 bits.

La conexión con el microcontrolador se realiza mediante los pines P0_11 y P0_10.

Figura 24 Conexión MMA8452

41

Modem 3G USB

Figura 25 Modem K3770 vodafone

Con un aspecto similar a una memoria USB, el modem USB 3G es un pequeño Gadget que permite a un usuario acceder a Internet a través de su PC. El modem USB 3G, una especie de modem inalámbrico de tipo WiFi, utiliza la red de los operadores de telefonía para conectarse a Internet. Al igual que los teléfonos móviles, el modem USB 3G posee un lugar reservado para una tarjeta SIM. Para que funcione, es necesario que previamente se haya suscrito a un plan en un operador de telefonía.

Desde el inicio de este proyecto se ha buscado la forma de poder utilizar este Gadget con un microcontrolador. Al principio de la investigación usaba una placa de desarrollo, STM32F4 Discovery la cual provee de conexión USB Host necesaria en primer lugar, además de que dentro de la librería STM32F4 Cube incluye ejemplos de uso.

Durante la investigación me he centrado en los modem Huwei E1550 y K3765, E170 y E220 los cuales junto con el K3770 son los más extendidos con la operadora Vodafone. Su funcionamiento se basa en una comunicación serie usando comandos AT estándares de la 3GPP además

42 de unos propios. Para la implementar la comunicación serie lo a través de puertos USB serie virtuales, además de que implementa entre dos a tres puertos, para configuración del modem otro el que realiza la comunicación y otro que no he llegado a averiguar de qué se trata. Aparte de estos tres puertos usb virtuales (Endpoints) se incorpora una unidad de almacenamiento masivo la cual contiene el software de instalación del dispositivo para sistemas Windows y Mac, dicha unidad es la que por defecto monta el modem normalente, con lo que el primer paso sería cambiar la configuración del modem para cambiar al endpoint de tipo Bulk encargado de comunicación GSM, es decir, poner el modem en modo modem GSM, para dicho proceso es necesario enviar una secuencia de caracteres en hexadecimal conocido como “Flip String”, dicha secuencia se puede conseguir instalando el software del modem en un sistema Windows y analizar el tráfico USB usando alguna herramienta en el caso de Linux se puede usar Wireshark con cierta configuración y ejecutada como usuario root, de modo que al ver que el modem cambia de estado recupera las ultimas tramas e interpretarlas con el fin de conseguir esa secuencia. Una vez conseguido esto tenemos el dispositivo listo para recibir comandos AT en la correspondiente conexión virtual, para ello se puede consultar la guía del estándar 3GPP y probar los comandos básicos para registro en red y similares.

Esto en cuanto a la teoría, para implementar un software para la comunicación con el modem sobre STM32F4, es necesario tener disponible la clase ACM/CDC, la cual permite la comunicación con puertos USB virtuales, y realizar los pasos indicados previamente. La dificultad radica en la complejidad de esta Integración de clase con la librería ST USB host que hasta fecha de marzo del 2014 no la incluía, de modo que era necesaria implementarla o bien usar librerías comerciales de terceros. La segunda complejidad es implementar una API de envoltorio para los comandos AT en funciones C útiles, de modo que se pueda atomizar acciones tales como el registro en red, envió de tramas GPRS/UMTS ect. Sin mencionar la

43 integración de la pila TCP/IP en el desarrollo, con el fin de poder realizar conexiones con internet y comunicarse con el servidor usando el protocolo HTTP.

Todo esto supone un coste en tiempo e investigación muchísimo mayor que el disponible para realizar el prototipo como proyecto fin de carrera. De modo que se ha optado por la solución mencionada en la introducción de este apartado, la de mbed.

Volviendo al modem USB Vodafone, que a partir de ahora los vamos a acotar a los modelos K3770 y K3772-z, únicos modelos soportados por la librería VodafoneUSBModem usada en este proyecto, al final de esta documentación se incluirá indicaciones de cómo se podría añadir soporte a otros modelos en base a la teoría arriba explicada y el análisis de la librería.

Este modem tiene una conexión USB como se ha indicado. Para el correcto funcionamiento de estos modem con la junta de desarrollo utilizada en este prototipo es necesario realizar las modificaciones mencionadas en el apartado anterior, que consiste en anular las resistencias R1, R2 y R3. Esto se debe a los requisitos del protocolo USB, para entenderlo hablaremos de este protocolo a continuación, centrándonos en USB Host desde el punto de vista de La configuración hardware.

El protocolo USB especifica que los datos en binario se transmiten usando transmisión diferencial entre dos líneas (D+ y D-) conocidas como líneas de datos. Un “1” lógico o diferencial “1” se transmite a 2.8V tirando D+ a tierra mediante una resistencia de valor 15k ohmios de pull-down y D- a menos de 0.3V con 1.5k ohmios de resistencia de pullUp. Un “0” lógico o diferencial “0” consiste en D- a más de 2.8V y D+ a menos de 0.3V con la apropiada resistencia de pullup/pull-down.

La velocidad del dispositivo debe ser indicada ya sea median te las líneas D+ o D- en alto a 3.3 Voltios, para ello se configura la línea correspondiente

44 con una resistencia de pullUp. Esta resistencia también es usada por el Host o Hub USB para detectar la presencia de un dispositivo conectado a su puerto. Esta anotación es la que explica la modificación realizada sobre la junta de desarrollo usada para el prototipo describida en el apartado anterior. Algunos microcotroladores incorporan esta resistencia de pull - Up junto a la PHY del USB, interna, de modo que pueda ser controlada mediante software su activación o anulación, como es el caso de los STM32F4. En la siguientes figuras se puede observar la configuración para USB full Speed y Low speed. High speed tiene la misma configuración que full speed, pero una vez conectado este resetea su configuración software para pasar high speed.

Figura 26 Configuracion low speed con resistencia 1.5 k pull Up

45

Figura 27 Configuración full speed con resistencia de 1.5k de pul l up

Se puede observar electrónica del dispositivo USB Host es la de incorporar tirar a tierra las dos líneas de datos mediante resistencia de pull down de valor 15k.

Esta teoría es necesaria dado que la junta de desarrollo con LPC 1768 no incorpora la configuración para USB host necesario para conectar el modem Vodafone USB.

NXP recomienda la siguiente configuración que se puede observar en la figura para utilizar el controlador de USB interno en modo USB Host.

Figura 28 Configuración recomendada NXP USB Host

46

De la configuración anterior sólo se ha incluido la parte que concierne a las líneas de datos D+ y D-, dado que los requisitos eléctricos del modem impiden que este se alimente la señal de alimentación de salida del microcontrolador. La alimentación a este es obtenida de una fuente externa a 5V. El modem requiere 150mA que puede llegar hasta los 250mA por un periodo de tiempo durante la realización de la conexión con la red . Para una mejor estabilidad en la comunicación del circuito y correcto funcionamiento se ha incluido dos capacitores de un valor de 18pF a modo de rectificadores para las señales de datos, quedando el circuito final para el socket USB Host al que se encuentra conectado el modem USB.

Figura 29 Configuración USB Hsot para Modem 3G

Como se puede observar en el esquemático anterior, las líneas de datos de USB están conectadas a los p0_29 y p0_30.

Conversor USB Serial

Como último componente a mencionar utilizado durante el desarroll o de este prototipo es un conversor serie a USB encargado que de hacer de interfaz serie para el PC. Este componente es usado para realizar la salida estándar de entrada salida de C (stdout, stdin and stderr), de modo que es posible obtener dichas salidas a través de un terminal como minicom o

47 cutecom, dado que este dispositivo se monta como un dispositivo USB serie virual.

Este dispositivo está compuesto de un chip FTDI FT232RL, y no requiere de alimenta externa dado que se alimenta de la conexión USB con el PC

Conexión:

La señal RX serie de este dispositivo se encuentra conectada la señal TX de la UART0 del LPC1768, la cual se encuentra en el pin p0_2. En el apartado siguiente de desarrollo software se encuentra los detalles con los cambios necesarios a realizar para utilizar este dispositivo como salida estándar de printf y así cubrir las necesidades de prueba y depuración.

En el apartado de Anexos de este documento se encuentra un anexo con los detalles del esquemático de la junta de desarrollo utilizada .

Desarrollo software

Introducción

Como se ha indicado anteriormente para el desarrollo de este prototipo se ha decidido utilizar el SDK de la plataforma mbed.

El SDK mbed está compuesto de API en alto nivel, C++ donde abstrae de toda la complejidad y configuración rutinaria de inicialización de periféricos y demás. Esto ofrece a gente experimentada y no tan experimentada a crear prototipos en un tiempo relativamente rápido.

El código desarrollado usando el SDK de mbed se puede ejecutar en cualquier plataforma mbed, interdependientemente del hardware o de la marca, modelo o fabricante del microcontrolador, siempre y cuando este pertenezca a la familia de plataformas mbed, actualmente entre las

48 plataformas encontramos a varios fabricante, NXP, Freescale, ST microelectronic etc.

Esta independencia de la plataforma se logra gracias a su arquitectura y control sobre los parámetros de compilación del SDK. A continuación se puede observar una imagen de la arquitectura de SDK mbed.

Figura 30 Arquitectura SDK Mbed

Añadir soporte para nueva plataforma consiste en implementar la capa de Mbed HAL e incluir la implementación del ARM CMSIS que en casi todos los casos es ofrecido por el propio fabricante del microcontrolador.

A continuación vemos la estructura del directorio del SDK.

Figura 31 Directorios mbed

 mbed/api: encontramos los ficheros de cabecera .h de la API de mbed, esta API es la que debemos usar en nuestro código. Dado que es la que ofrecerá portabilidad a nuestro código entre plataformas mbed.

49

 mbed/common: ficheros de código comunes a todas las plataformas, aquí se incluye la parte de retarget que se realiza hacía la interfaz mbed. En breve comentare los a realizar para redirigir la salida estándar de C al sitio deseado.  mbed/hal: Aquí se encuentra la HAL API de mbed que deben ser implementadas por cada plataforma.  Mbed/target: Se encuentra la implementación del HAL API de mbed junto con fichero de código de inicialización, script de linker propios para cada compilador, además de posibles drivers específicos del microcontrolador.

A continuación vemos el ejemplo más popular en los sistemas embebidos usando la API de mbed. El ejemplo se encarga de encender de forma intermitente un led.

#include "mbed.h"

DigitalOut led1(LED1); int main() { while (true) { led1 = 1; wait(0.5);

led1 = 0; wait(0.5); } }

Para redirigir la salida estándar de C al sitio deseador es necesario redefinir o modificar el fichero mbed/common/retarget.cpp donde se implementan las funciones de _write y _read necesarias por la librería de C. En nuestro caso suficiente modificar en el constructor de del puerto serie utilizado, al pin deseado en nuestro caso a la UART0 o bien otra, en el ejemplo siguiente se usa la UART1.

[…]

serial_init(&stdio_uart, P0_15, P0_16);

[...]

50

Otra modificación a tener presente es el mapeo de pines que tiene el mbed NXP LPC1768, dado que este utiliza otra nomenclatura y define funcionalidad para los periféricos mas i mportantes. De modo que al usar el software de la API que hay que consultar el esquemático de la junta de desarrollo incluida al final de este documento para conocer su localización. En el caso de desear cambiar la configuración de esta por ejemple la junta de desarrollo incorpora un led en el pin p2_0, y la definición de led existe en el SDK no tiene sentido para nuestra junta dado que no existen dichos Leds. Para ello nos dirigimos al fichero Pinames.h disponible en el directorio TARGET_MBED_LPC1768.

Además para la plataforma encontramos infinidad de libreria s que se pueden consultar en el apartado “Handbook” en su página web.

Para nuestro propósito haremos uso, aparte del SDK mbed para LPC1768, de las siguientes librerías.

Descripción de librerías

Mbed-RTOS.

La plataforma Mbed proporciona un interesante sistema operativo de tiempo real el cual nos proporciona de toda la funcionalidad necesaria mediante clases C++, para la comunicación y sincronización entre tareas.

Ésta se basa en una implementación del estándar CMSIS RTOS, lo que facilita su integración en las distintas plataformas Mbed.

Actualmente ofrece clases para:

 Threads: para crear un thread usamos Thread thread(led2_thread), donde led2_thread es la funcion a ejecutar, este constructor ofrece mas parámtros para configurar. Para más información consultar el sitio oficial.  Mutex: usado para la sincronización de ejecución de Threads ,

51

 Semaphore: Semáforos que son útiles para gestionar el acceso de varios threads a un conjunto de recursos de cierto t ipo.  Signals: Los Thread pueden ser notificados mediante señales para salir de una espera activa. Este componente del Kernel lo usamos en nuestra aplicación para informa del fin de la lectura de datos de los sensores al Thread encargado de enviar dicha doc umentación mediante un POST HTTP al servidor.  Queue: Permite implementar funciones que responden al problema de consumidor productor, básicamente es un puntero a datos bloqueante.  Además de estos se encuentran otros más como Mail, memoryPool, RTOS Timer que permite controlar funciones de tiempo del sistema, osEvent para comunicación media banderas. Todo esto junto a estructras de datos para gestionar estado y códigos de errores.

USBHost

Librería que implementa la pila del protocol USB, y la cual permite a nuestro LPC1768 actuar como USB Host y permitir comunicarse con el modem, para ello incluye un driver para modem 3G ya que dispone de la clase ACM/CDC implentada.

VodafoneUSBModem

La existencia de esta librería ha sido el factor decisivo para optar por esta plataforma. Dicha librería proporciona implementada la funcionalidad para controlar un modem Vodafone modelos K3770 o k3772-z, modelos soportados hasta la fecha, permitiendo su uso con redes 3G.

52

Esta librería nos abstrae del funcionamiento interno del modem y las peculiaridades del estándar 3GPP y así evitar la comunicación mediante comandos AT.

Ofrece una API en alto nivel para inicializar el modem y su correcta configuración donde solo es necesario indicar la configuración del APN de la operadora Vodafone en nuestro país.

Esta librería además de ofrecer la API para el manejo del modem, integra varias librerías:

 lwip, que implementa la pila TCP/IP y por tanto nos permite usar este protocolo y establecer conexiones HTTP al servidor.  Librería IP que hace de interfaz de red para la librería Lwip.  Socket Librería de networking para la creación y gestión de Socket TCP o UDP, permitiendo conexiones directas con server Sockets en servidores remotos.  Otra librería interesante que integra es serial, la c ual permite establecer conexiones con puertos virtuales del modem y permitir el envío de comandos AT.  Sms, para el envío y recepción de mensaje de texto usando el modem.  Link librería para monitorizar la calidad y estado de la conectividad 3G de nuestro modem.

HTTPCient

Esta librería implementa la funcionalidad necesaria para realizar peticiones HTTP de tipo POST y GET, además de permitir obtener su respuesta, para ello hace uso de la pila de red TCP/IP implementada por Lwip.

53

Para el manejo de datos de estas peticiones nos dota cuatro clases de contenedores de datos HTTP.

 HTTPMap: para el almacenamiento de datos en una estructura tipo pares clave / valor, útil para comunicaciones POST. De esta forma podemos cargar una serie de parámetros con la request HTTP. Este es el método utilizado en nuestra aplicación para el prototipo, donde se envían los datos de los sensores mediante una petición HTTP POST. De modo que no requiera de software especial para la recogida de datos y no tener que implementar un proto colo especial para recibir los datos del dispositivo.  HTTPText: contenedor de datos tipo textos cortos.  HTTPFile: Contenedor para fichero de datos de entrada salida, como puede ser formatos binarios.  HTTPStream: para aplicaciones que requieren streamming d e datos, como es el caso de aplicaciones multimedia.

NTPClient

Es un cliente de NTP básico que hace uso del protocolo UDP, y actualiza el RTC del microcontrolador de forma automática. Es útil para obtener ajustar la hora al inicio de la ejecución y poder marcar en tiempo las mediciones de los sensores realizadas.

En el DVD se incluye el proyecto software desarrollado así como las librerías utilizadas.

Descripción de tareas

El cometido principal de la aplicación consiste en la posibilidad de leer los datos de los sensores y enviar dichos datos a un servidor remoto, para ello como se ha especificado en el apartado anterior se realizará mediante petición HTTP de tipo POST, de este modo ofrecerá flexibilidad

54 para implementar varios tipos de aplicaciones servid oras, desde páginas web hasta aplicaciones de servicio en el servidor.

La aplicación en cuestión que se ejecuta en el microcontrolador por simpleza, consiste principalmente en otras tareas o Threads de ejecución paralelas.

El primer Thread que comienza al inicio de la ejecución de la aplicación es el propio main, este simplemente se encarga de inicializar y configurar la interfaz serie para depuración , además de lanzar el segundo Thread o Tarea llamada “SendData” , y permanecer ejecutándose en paralelo indicando cambiado el estado de un led de forma intermitente con un periodo de un segundo, esto es para indicar que la aplicación se encuentra en ejecución.

Esta tarea de nombre “sendData” tiene la siguiente misión:

1. Inicializar el Modem USB, para ello hace uso de las librerías anteriormente descritas.

2. Configurar los parámetros de tiempo de la aplicación de tiempo y todos los que se deseen configurar. Como primer paso consulta la hora a un servidor NTP remoto para así ajustar el RTC del microcontrolador, esta tarea la facilita la librería NTPClient.

3. Consultar los parámetros deseados al servidor remoto, como caso práctico se consulta la versión de la aplicación y del periodo de tiempo para realizar la lectura de los sensores.

4. Inicialización de la siguiente Thread “sensorReadTask”, con el que establece una comunicación mediante Signals. 5. Como último paso, mantiene una espera activa de una señal proporcionada por la terea iniciada en el paso anterior que indica la disponibilidad de dados cargados para enviar al servidor remoto,

55

este envío como se ha especificado con anterioridad se realiza mediante la complementación de una petición HTTP POST, además de leer la respuesta del servidor a dicha petición, aquí se puede incuir mensajes para comunicar la correcta recepción de los o avisar de errores ante fallos en el servidor.

La tercera tarea identificada como sensorReadTask tiene la misión de:

 inicializar la configuración de los sensores, mediante sus respectivas clases.

Las siguientes acciones se realizan de forma permanente, en un bucle cada cierto periodo de tiempo, el cual es indicado por un parámetro consultado al servidor

 Realizar la lectura y carga en un contenedor de datos de tipo HTTPMap de los siguientes datos de los sensores acoplados. o longitud y latitud. o Humedad y temperatura o Datos decimales de ambos sensores de GAS. o Fecha y hora actual. o Datos del acelerómetro, es decir gravedad en formato XYZ.

 Avisar mediante el envío de una señal a la tarea anterior para que proceda el envío de dichos parámetros al servidor remoto.

Para facilitar las tareas anteriores se ha implementado varias Clases y funciones útiles que pueden consultar en el proyecto adjunto en DVD.

Descripción sensores

Los sensores de gas, como hemos visto ofrecen una salida analógica, pero requieren un tiempo de precalentamiento dicho tiempo está cubierto por las tareas inicialización descrita en el apartado anterior.

56

Para la lectura de los datos es necesario realizar una lectura de datos analógicos utilizando alguno de los ADC que incorpora el microcontrolador, esta tarea se ve tremendamente simplificada mediante el uso de la API de mbed, se reduce a crear/instanciar un objeto (clase cpp) tipo AnalogIn y llamar a la función read() que este ofrece.

Ejemplo:

AnalogIn gas_pin(gas1PIN);

unsigned int gasValue = gas_pin.read();

Descripción protocolos

A continuación se detalla las características del protocolo de comunicación con el sensor de humedad y temperatura y con el módulo GPS U-Blox NEO 6M.

Protocolo RHT03

Tal como se explicó en apartado anterior este sensor tiene una comunicación serie con un protocolo propio, por lo tanto veremos un ejemplo de trama recibida el código en cuestión que realiza dicha comunicación.

Detalle de la trama recibida, al enviar la señal de start.

Los 5 bytes recibidos serán los siguientes:

 Byte1: parte entera de humedad relativa (RH)  Byte2: parte decimal de humedad relativa  Byte3: parte entera de temperatura (T)  Byte4: parte decimal de temperatura  Byte5: checksum

57

El checksum se utiliza para confirmar que la información recibida es correcta, y se calcula sumando los 4 bytes anteriores y quedándonos sólo con los 8 bits menos significativos del resultado.

Ejemplo de cálculo.

Se han recibido 40 bits de datos del sensor de la siquinte forma

0000 0010 1000 1100 0000 0001 0101 1111 1110 1110

RH T checksum

check sum=0000 0010+1000 1100+0000 0001+0101 1111=1110 1110

RH= (0000 0010 1000 1100)/10=65.2% de humedad relativa.

T = (0000 0001 0101 1111)/10= 35.1 grados centígrados.

Cuando el bit más significativo de la temperatura es 1, significa que la temperatura está por debajo de 0 grados centígrados.

Ejemplo. T= 1000 0000 0110 0101, es decir temperatura es menos 10.1 grados centígrados.

Implementación del protocolo para la obtención de los datos.

[…]

RHT03_ERROR RHT03::readData() { int i, j, retryCount; int currentTemperature=0; int currentHumidity=0; unsigned int checkSum = 0, csPart1, csPart2, csPart3, csPart4; unsigned int bitTimes[RHT03_DATA_BIT_COUNT]; RHT03_ERROR err = RHT_ERROR_NONE; time_t currentTime = time(NULL);

DigitalInOut DATA(_data);

for (i = 0; i < RHT03_DATA_BIT_COUNT; i++) { bitTimes[i] = 0; }

58

// if (int(currentTime - _lastReadTime) < 2) { // printf("RHT22 Error Access Time < 2s"); // err = RHT_ERROR_TOO_QUICK; // } retryCount = 0; // Pin needs to start HIGH, wait unit it is HIGH with a timeout do { if (retryCount > 125) { //pc1.printf("RHT22 Bus busy!"); err = RHT_BUS_HUNG; return err; } retryCount ++; wait_us(2); } while (DATA==0); // exit on RHT22 return 'High' Signal within 250us

// Send the activate pulse // Step 1: MCU send out start signal to RHT22 and RHT22 send // response signal to MCU. // If always signal high-voltage-level, it means RHT22 is not // working properly, please check the electrical connection status. // DATA.output(); // set pin to output data DATA = 0; // MCU send out start signal to RHT22 wait_ms(18); // 18 ms wait (spec: at least 1ms) DATA = 1; // MCU pull up wait_us(40); DATA.input(); // set pin to receive data // Find the start of the ACK Pulse retryCount = 0; do { if (retryCount > 40) { // (Spec is 20-40 us high) //pc1.printf("RHT22 not responding!"); err = RHT_ERROR_NOT_PRESENT; return err; } retryCount++; wait_us(1); } while (DATA==1); // Exit on RHT22 pull low within 40us if (err != RHT_ERROR_NONE) { // initialisation failed return err; } wait_us(80); // RHT pull up ready to transmit data

for (i = 0; i < 5; i++) { for (j = 0; j < 8; j++) { // Instead of relying on the data sheet, just wait while the RHT03 pin is low retryCount = 0; do { if (retryCount > 75) { //pc1.printf("RHT22 timeout waiting for data!"); err = RHT_ERROR_DATA_TIMEOUT; 59

} retryCount++; wait_us(1); } while (DATA == 0); // We now wait for 40us wait_us(40); if (DATA == 1) { // If pin is still high, bit value is a 1 bitTimes[i*8+j] = 1; } else { // The bit value is a 0 bitTimes[i*8+j] = 0; } int count = 0; while (DATA == 1 && count < 100) { wait_us(1); // Delay for 1 microsecond count++; } } } // Re-init RHT22 pin DATA.output(); DATA = 1;

// Now bitTimes have the actual bits // that were needed to find the end of each data bit // Note: the bits are offset by one from the data sheet, not sure why currentHumidity = 0; currentTemperature = 0; checkSum = 0; // First 16 bits is Humidity for (i=0; i<16; i++) { //printf("bit %d: %d ", i, bitTimes[i+1]); if (bitTimes[i+1] > 0) { currentHumidity |= ( 1 << (15-i)); } }

// Second 16 bits is Temperature for (i=0; i<16; i ++) { //printf("bit %d: %d ", i+16, bitTimes[i+17]); if (bitTimes[i+17] > 0) { currentTemperature |= (1 <<(15-i)); } }

// Last 8 bit is Checksum for (i=0; i<8; i++) { //printf("bit %d: %d ", i+32, bitTimes[i+33]); if (bitTimes[i+33] > 0) { checkSum |= (1 << (7-i)); } }

_lastHumidity = (float(currentHumidity) / 10.0);

// if first bit of currentTemperature is 1, it is negative value. 60

if ((currentTemperature & 0x8000)==0x8000) { _lastTemperature = (float(currentTemperature & 0x7FFF) / 10.0) * -1.0; } else { _lastTemperature = float(currentTemperature) / 10.0; }

// Calculate Check Sum csPart1 = currentHumidity >> 8; csPart2 = currentHumidity & 0xFF; csPart3 = currentTemperature >> 8; csPart4 = currentTemperature & 0xFF; if (checkSum == ((csPart1 + csPart2 + csPart3 + csPart4) & 0xFF)) { _lastReadTime = currentTime; //pc1.printf("OK-->Temperature:%f, Humidity:%f\r\n", _lastTemperature, _lastHumidity); err = RHT_ERROR_NONE; } else { //pc1.printf("RHT22 Checksum error!\n"); //pc1.printf("Calculate check sum is %d\n",(csPart1 + csPart2 + csPart3 + csPart4) & 0xFF); //pc1.printf("Reading check sum is %d",checkSum); err = RHT_ERROR_CHECKSUM; } return err; }

[…]

Módulo GPS

Este dispositivo como mencionamos con anterioridad dispon e de una salida de datos serie y leemos los datos geográficos a través de una de las entradas serie asíncronos (UART) del microcontrolador.

El formato de datos usado por el módulo para la transmitir los es el conocido como NMEA. MEA en realidad es una institución (National Marine Electronic Asociation, pero al protocolo también se le conoce por sus siglas) dedicada a establecer un estándar para la comunicación de dispositivos periféricos marinos, ya que hace algunas décadas atrás, cada marca manejaba su propia forma de comunicarse (protocolo de datos), a fin de hacer más fácil la comunicación entre diversos dispositivos (tanto a nivel del protocolo de datos como de la interfaces eléctrica), se creó esta

61 institución en la cual participan fabricantes, distribuidores, instituciones educacionales y otros interesados en equipos periféricos marinos. Este protocolo se caracteriza por que transmite sentencias, cada una de las sentencias comienza con "$", y termina con (CR: Carriage Retun, LF: Line Feed), los 2 caracteres que preceden a "$" son los que identifican el equipo (Para los GPS "GP"), los siguientes 3 caracteres indican la sentencia que se está enviando, hay 3 tipos de sentencias que son de consulta (Query Sentences), de origen del equipo (Proprietary Sentences) y de envío (Talker Sentences).

Ejemplo de las sentencias recibidas por este módulo. $GPGGA,155850.00,,,,,0,00,99.99,,,,,,*6A $GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,3,1,10,01,53,302,16,04,31,282,37,11,70,335,16,14,23,066,*70 $GPGSV,3,2,10,19,60,119,,20,33,223,33,22,14,046,,27 ,30,131,*7D $GPGSV,3,3,10,28,27,306,30,32,75,181,*7A $GPGLL,,,,,155850.00,V,N*46

En nuestro caso la línea que nos interesa es la primera, “GPGGA” que identifica a Global Positioning System Fix Data, es decir, Datos del Sistema Global de Posicionamiento. Lo interesante de este mensaje es, que aparte de darnos la longitud y latitud de la posición nos informa de la hora del reloj también. a continuación tenemos los detalles de este mensaje.

$GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxx x*hh

1. = Hora 2.= Latitud 3.= N o S 4.= Longitud 5.= E u O

62

6.= Indicador de la Calidad de la señal de GPS (0=no Válido; 1=Fijo de GPS; 2=Fijo de GPS(DGPS) 7.= Número de Satélites en uso 8. = Dilución Horizontal de la Posición (DOP) 9. = Altura de la Antena Sobre/Bajo Nivel del Mar Intermedio (geoide) 10.= Metros (Unidad de usada para la altura) 11.= Separación Geoidal (Diferencia entre elipsoide terrestre WGS-84 y nivel del mar) 12.= Metros (Unidad de la separación geoidal) 13.= Intervalo en Segundos desde la última actualización de una Estación de Referencia dif. 14.= Estación de Referencia ID#. 15.= Suma de Verificación (Opcional

La parte del código más relevante es la que realiza el parseo de los datos, y toma una muestra de la longitud y latitud, a continuación adjunto dicha porción de código. int GPS::sample() { float time; char ns, ew; int lock;

while (1) { getline();

if (sscanf(msg, "GPGGA,%f,%f,%c,%f,%c,%d", &time, &latitude, &ns, &longitude, &ew, &lock) >= 1) { if (!lock) { longitude = 0.0; latitude = 0.0; return 0; } else { if (ns == 'S') { latitude *= -1.0; } if (ew == 'W') { longitude *= -1.0; } float degrees = trunc(latitude / 100.0f); float minutes = latitude - (degrees * 100.0f); 63

latitude = degrees + minutes / 60.0f; degrees = trunc(longitude / 100.0f * 0.01f); minutes = longitude - (degrees * 100.0f); longitude = degrees + minutes / 60.0f; return 1; } } } } float GPS::trunc(float v) { if (v < 0.0) { v *= -1.0; v = floor(v); v *= -1.0; } else { v = floor(v); } return v; } void GPS::getline() { while (_gps.getc() != '$') for (int i = 0; i < 256; i++) { msg[i] = _gps.getc(); if (msg[i] == '\r') { msg[i] = 0; return; } } error("Overflowed message limit"); }

PRUEBAS Y DIFICULTADES ENCOTRADAS

Diseño de pruebas Para la realización de las pruebas se ha diseñado un servicio web remoto con acceso a una base de datos MySql. Se ha hecho uso de un servicio de alojamiento gratuito (Hostinger.com), y la base de datos MySql se encuentra en otro servidor de alojamiento gratuito (db4free.net).

Resultando en la siguiente configuración general .

64

Figura 32 Configuracion sistem de pruebas

Este sistema se encarga de recibir las peticiones POST HTTP, extrae los datos y según el parámetro “type” especificado por el dispositivo realizará una acción u otra, como caso práctico se ha implementado dos posibles acciones:

 Responder con el valor de un parámetro, el cual es consultado por el dispositivo.  Realizar el guardado de los datos de los sensores enviada por el dispositivo en una base de datos.

En la base de datos se han creado dos tablas, una llamada sensor_data donde se insertan los datos recibido y otra llamada pa rameters, que almacena los parámetros que puede consultar el dispositivo o incluso realizar modificaciones.

65

A continuación se adjunta el script php que realiza estas acciones.

// Get values from request

$tipo =$_POST['type']; $order = ""; switch ($tipo) { case '0':#solicitar lectura parámetro en fichero output0 $order= "select * from parameters where name like '%".$_POST['parameter']."%'"; break; case '1':#actualizar parámetro # code... $order = "INSERT INTO parameters VALUES ('".$_POST['parameter']."','".$_POST['parameterValue']."',0)"; break; case '2':#insertar datos en base de datos # code... $gas1 = $_POST['gas1']; $gas2 = $_POST['gas2']; $lat= $_POST['lat']; $long = $_POST['long']; $grav = $_POST['grav']; $time= $_POST['time']; $hum = $_POST['hum']; $temp = $_POST['temp'];

$order = "INSERT INTO sensors_data VALUES ('".$gas1."','".$gas2."','".$lat."','".$long."','".$temp."','".$h um."','".$time."','".$grav."')"; //print($order); break; case '3':#solicitar actualización firmware, # code... break; } $result = mysql_query($order); //order executes if($result) { //echo("Input data is succeed\n"); switch ($tipo) { case '0':#solicitar lectura parámetro en fichero output0 while ($fila = mysql_fetch_assoc($result)) { echo $fila['value']; } break;

66

case '1':#actualizar parámetro # code... print($order); echo("\rInput data is succeed\n"); break; case '2':#insertar datos en base de datos print($order); echo("\rInput data is succeed\n"); break; case '3':#solicitar actualización firmware, # code... break; } } else { echo("FAIL"); } mysql_close($link); //echo ("connection closed\n"); }else{ echo "FAIL"; } ?>

Resultado de pruebas

Las pruebas han sido exitosas llegando a realizarse la comunicación entre los sistemas correctamente y ofreciendo una correcta lectura por parte del dispositivo de los sensores.

A continuación se adjunta el LOG obtenido mediante la salida estándar de C. y la captura de datos los datos insertados en la base de datos.

LOG:

[START] starting

[DBG] Module VodafoneUSBModem.cpp - Line 527: Trying to connect the dongle [DBG] Module VodafoneUSBModem.cpp - Line 527: Trying to connect the dongle [DBG] Module VodafoneUSBModem.cpp - Line 531: Great the dongle is connected - I've tried 11 times to connect [DBG] Module VodafoneUSBModem.cpp - Line 565: Starting AT thread if needed

67

[DBG] Module VodafoneUSBModem.cpp - Line 572: Sending initialisation commands [INFO] Module VodafoneUSBModem.cpp - Line 601: Using a Vodafone K3772-Z Dongle [DBG] Module VodafoneUSBModem.cpp - Line 668: Waiting for network registration [DBG] Module VodafoneUSBModem.cpp - Line 670: Result of command: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 671: ATResult: AT return=0 (code 0) [DBG] Module VodafoneUSBModem.cpp - Line 668: Waiting for network registration [DBG] Module VodafoneUSBModem.cpp - Line 670: Result of command: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 671: ATResult: AT return=0 (code 0) [DBG] Module VodafoneUSBModem.cpp - Line 668: Waiting for network registration [DBG] Module VodafoneUSBModem.cpp - Line 670: Result of command: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 671: ATResult: AT return=0 (code 0) [DBG] Module VodafoneUSBModem.cpp - Line 668: Waiting for network registration [DBG] Module VodafoneUSBModem.cpp - Line 670: Result of command: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 671: ATResult: AT return=0 (code 0) [DBG] Module VodafoneUSBModem.cpp - Line 668: Waiting for network registration [DBG] Module VodafoneUSBModem.cpp - Line 670: Result of command: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 244: ATResult: AT return=0 (code 0) [DBG] Module VodafoneUSBModem.cpp - Line 245: APN set to ac.vodafone.es [DBG] Module VodafoneUSBModem.cpp - Line 251: Connecting [DBG] Module VodafoneUSBModem.cpp - Line 270: Connecting PPP [DBG] Module VodafoneUSBModem.cpp - Line 273: Result of connect: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 531: Great the dongle is con nected - I've tried 1 times to connect [DBG] Module VodafoneUSBModem.cpp - Line 565: Starting AT thread if needed [DBG] Module VodafoneUSBModem.cpp - Line 572: Sending initialisation commands

68

[INFO] Module VodafoneUSBModem.cpp - Line 601: Using a Vodafone K3772-Z Dongle [DBG] Module VodafoneUSBModem.cpp - Line 668: Waiting for network registration [DBG] Module VodafoneUSBModem.cpp - Line 670: Result of command: Err code=0

[DBG] Module VodafoneUSBModem.cpp - Line 671: ATResult: AT return=0 (code 0)

[DBG] Module VodafoneUSBModem.cpp - Line 238: Result of command: Err code=11

[DBG] Module VodafoneUSBModem.cpp - Line 238: Result of command: Err c ode=11

[DBG] Module VodafoneUSBModem.cpp - Line 238: Result of command: Err code=11

[DBG] Module VodafoneUSBModem.cpp - Line 238: Result of command: Err code=0 [DBG] Module VodafoneUSBModem.cpp - Line 244: ATResult: AT return=0 (code 0) [DBG] Module VodafoneUSBModem.cpp - Line 245: APN set to ac.vodafone.es [DBG] Module VodafoneUSBModem.cpp - Line 251: Connecting [DBG] Module VodafoneUSBModem.cpp - Line 270: Connecting PPP

[DBG] Module VodafoneUSBModem.cpp - Line 273: Result of connect: Err code=0 set time ok Current time is (UTC): Mon Sep 15 00:02:18 2014

Getting parameter FWVERSION

Executed POST successfully - read 1 characters Result: 2

parame ter value: 2

Firmware UPDATE!!!! Reading data

69

longitud: -9.054348, Latitude: 37.394108 temp: 33.0000043.799999,hum: 43.799999

X Y Z = 221,53,17

GAS 1:0.895971: GAS 2:0.038584: Time is: Mon Sep 15 02:00:58 2014 Trying to post data...

Executed POST successfully - read 190 characters Result: INSERT INTO sensors_data VALUES ('0.895971','0.038584','37. 394108','- 9.054348','33.0000043.79999221,53,17','43.79999221,53,17','Mon Sep 15 02:00:58 2014','221,53,17') Input data is succeed

Reading data longitud: -9.054336, Latitude: 37.394108 temp: 33.0000043.79999221 ,53,17,hum: 43.79999221,53,17

X Y Z = 222,52,17 GAS 1:0.904518: GAS 2:0.038584: Time is: Mon Sep 15 02:01:07 2014 Trying to post data...

Executed POST successfully - read 190 characters Result: INSE RT INTO sensors_data VALUES ('0.904518','0.038584','37.394108',' - 9.054336','33.0000043.79999222,52,17','43.79999222,52,17','Mon Sep 15 02:01:07 2014','222,52,17') Input data is succeed

Reading data longitud: -9.054335, Latitude: 37.394112 temp: 33.0000043.000000,hum: 43.000000

X Y Z = 221,53,17 GAS 1 :0.912088: GAS 2:0.038584:

70

Time is: Mon Sep 15 02:01:18 2014 Trying to post data...

Executed POST successfully - read 190 characters Result: INSERT INTO sensors_data VALUES ('0.912088','0.038584','37.394112',' - 9.054335','33.0000043.00000221,53,17','43.00000221,53,17','Mon Sep 15 02:01:18 2014','221,53,17') Input data is succeed

Reading data longitud: -9.054335, Latitude: 37.394112 temp: 33.0000043.00000221, 53,17,hum: 43.00000221,53,17

X Y Z = 222,53,17 GAS 1:0.918437: GAS 2:0.038584: Time is: Mon Sep 15 02:01:27 2014 Trying to post data...

Executed POST successfully - read 190 characters Result: INSERT INTO s ensors_data VALUES ('0.918437','0.038584','37.394112',' - 9.054335','33.0000043.00000222,53,17','43.00000222,53,17','Mon Sep 15 02:01:27 2014','222,53,17') Input data is succeed

[....]

El result que se puede observar es la respuesta del servidor, que en este caso indica que se ha realizado el insert correctamente

71

Dificultades

La principal dificultad en este desarrollo radica en la falta de conocimientos inicial de la que disponía sobre las tecnologías inalámbricas y la alta complejidad de desarrollo de dispositivos con USB Host y a la relativa poca documentación existente sobre estos dispositivos.

Otro tema que ha ido en en contra es la falta de un entorno de desarrollo integrado para sistemas operativos GNU/Linux que ha llevado a dedicar una buena cantidad de tiempo configurando el proyecto para su uso con GCC y eclipse.

A estas dificultades hay que añadir las restricciones de tiempo de la que disponía para dedicarle a este proyecto.

ANÁLISIS TEMPORAL Y COSTE DE DESARROLLO

72

La planificación temporal consiste en la estimación del tiempo y esfuerzo durante las fases de desarrollo, con el fin de incrementar los niveles de servicio, calidad y coste. Para ello, dividimos el cicl o de vida del proyecto en una serie de tareas a las cuales se les asignará las dos estimaciones siguientes:

- Estimación inicial: empleadas en los inicios del desarrollo. Son las menos exactas, pero se emplean como primera aproximación a la viabilidad del proyecto.

- Estimación Final: expresan la duración y el esfuerzo real empleado.

Estos valores serán comparados para evaluar la exactitud de la estimación, empleando el Error Relativo de la estimación, RE es el cociente entre el error absoluto y la dedicación final:

Tarea Horas Horas Error Error Estimadas invertidas Absoluto relativo Introducción 8 6 -2 -0.33 Planificación 6 4 -2 -0.50 Análisis de 20 25 5 0.20 Requisitos Estudio, 40 60 20 0.33 comprensión y adaptación del código Búsqueda de 40 100 60 0.60 información e instalación del entorno Diseño del 12 20 8 0.40 sistema completo Pruebas 30 50 20 0.40 Implementación 20 45 25 0.56 Presentación 10 6 -4 -0.67 Total 186 316 130 0.41

73

El presupuesto en material y con su respectivo coste que se ha obtenido para la investigación y desarrollo del siguiente prototipo, es la siguiente.

CONCLUSIONES Y POSIBLES MEJORAS

El tiempo dedicado a la investigación en este desarrollo a tenido grandes frutos en conocimientos, lo que se traduce en una gran satisf acción personal. Además de enriquecer y complementar mis conocimientos sobre los sistemas embebidos basados en microcontrolador.

Este tipo de desarrollos requieren de mucha dedicación y poseer sólidos conocimiento sobre el funcionamiento de los sistemas di gitales en concreto los microcontroladores.

De entre las mejoras o ampliaciones que se le pueden aplicar, algunas de ellas estaban en proceso y por falta de tiempo no se han podido implementar.

 Incluir en la lógica de la aplicación software que permita la calibración de los sensores y si es posible mediante parámetros. Esto requiere de un desarrollo hardware y software bastante complejo.

74

 Incluir un sistema de detección y recuperación de fallos en el dispositivo.  Realizar el desarrollo de un sistema de alime ntación junto con un sistema de carga de batería. Dado que el dispositivo irá colocado en bicicletas, este sistema obtendrá la corriente alterna desde una Dinamo acoplada a la bicicleta.  Realizar una fabricación de una placa PCB con todos los componentes utilizados de modo que pueda ser más portable y permitir realizar pruebas en campo usando bicicletas.  Investigación en sensores detectores de gases más precisos y rápidos dado, que al estar alojado el sistema en una bicicleta puede verse afectados de algún modo los valores leído por los sensores, esto es una hipótesis.  Y por último punto y no ultima mejora posible, el desarrollo de un bootloader para la aplicación en dispositivo que permita la actualización del firmware OTA (over the air). Esta investigación estaba en curso y dada la poca memoria RAM y el tamaño final del Firmware imposibilita su almacenamiento temporal en memoria para ser copiado a la memoria flash.

GLOSARIO DE TÉRMINOS

JTAG: Joint Test Action Group.

SWD: Serial Wire Debug.

DAP: Coresight Debug Access Port.

Semihosting: Mecanismo que permite a código ejecutado en sistemas ARM comunicarse y usar la entrada salida estándar del PC de desarrollo donde se ejecuta el depurador.

Endpoints: se puede definir como origen y fin de los datos que se transmiten por la interfaz usb. 75

ANEXOS

Instalación del entorno de desarrollo

Para disponer de un entorno de desarrollo en un sistema GNU /Linux se requiere de tres herramientas instaladas. Openocd, compilador gcc arm y el famoso entorno de desarrollo eclipse. Al final de este documento en el apartado de referencias se puede se puede encontrar enlaces estos proyectos de software abierto. De entre las tres herramientas voy openocd es la más desconocida, por ello incluyo una descripción de la misma y luego procederemos a integrar esta herramientas con eclipse.

Openocd

Una de las herramientas más poderosas para alguien que trabaja con sistemas empotrados es el JTAG. Éste es un puerto, incluido en prácticamente la totalidad de circuitos integrados del mercado q ue disponen de cierta funcionalidad avanzada. Permite el acceso al mismo para su borrado, programación, verificación, depuración y prácticamente cualquier cosa que queramos hacer. Además, un único puerto JTAG permite acceder a todos los componentes de un mismo sistema siempre que se encuentren correctamente conectados y configurados.

OpenOCD es un software totalmente abierto que permite acceder al puerto JTAG de una amplia variedad de circuitos integrados, como memorias, procesadores o microcontroladores de diversas arquitecturas. OpenOCD permite además el uso de una gran variedad de interfaces distintas para poder conectar nuestro sistema objeto de inspección a nuestra estación de trabajo.

76

OpenOCD puede interactuar con una gran cantidad de hardware y para e llo puede hacer uso de bastantes tipos distintos de interfaces. Por ello es necesario poder darle los paramétros de configuración correctos para poder hacerlo funcionar.

En la distribución estándard de OpenOCD se distribuyen varios scripts de configuración que pueden ser utilizados para configurar nuestro hardware. Al final de este anexo se adjunta el fichero de configuración para LPC1768 y el programado depurador ARM-USB-OCD.

Dichos scripts se encuentran en el directorio /usr/share/openocd/scripts. Dentro de este directorio existen, entre otros, tres subdirectorios que contienen casi todo lo qu necesitas para poder configurar correctamente OpenOCD:

interface: En este subdirectorio se encuentran scripts para distintos tipos de cable JTAG soportados por OpenOCD, que son una gran variedad de los existentes en el mercado, tanto propietarios como libres. Un usuario puede añadir soporte para cualquier cable a veces con tan solo escribir el correspondiente script de configuración.

board: Aquí podemos encontrar la configuración para los distintos tipos de tarjetas de desarrollo soportadas por OpenOCD. Estas tarjetas pueden contener varios procesadores, FPGAs, memorias, etcétera. En estos archivos de configuración se describe cómo están interconectados entre s i los distintos componentes de una determinada tarjeta de modo que desde el JTAG se pueda acceder a todos ellos. Si has desarrollado una tarjeta específica y deseas utilizar OpenOCD para trabajar sobre ella, estos archivos pueden ser un buen punto de partida sobre el que escribir la configuración de tu hardware.

target: Finalmente este directorio contiene la configuración para los distintos integrados soportados por OpenOCD. Los scripts dentro del subdirectorio board explicado anteriormente incluyen scripts de este

77 subdirectorio para informar de qué componentes conforman la tarjeta con la que queremos conectar.

OpenOcd se encuentra normalmente en los repositorios ofciales de casi todas las distribuciones Linux. Por ejemplo en Archlinux lo podemos encontrar el repositorio AUR, que es el repositorio de software de la comunidad.

GCC ARM

Este es el compilador de código y linker para arquitecturas ARM por excelencia, para el desarrollo de proyecto se ha hecho uso desde IDE, pero en las ultimas compilaciones se ha realizado con RealView del IDE en línea de mbed.org, dado que estaba mejor optimizado para la plataforma mbed

GNU ARM Eclipse Plugin. Para integrar GCC y Openocd con eclipse tenemos un P lugin llamado GNU ARM Eclipse que nos hace todo el trabajo. En la web oficial de este proyecto se encuentra detallado el procedimiento de instalación. Este plugin incorpora varias Plantilla de de proyectos para ARM cortex m3 y M4, en concreto para micorocntroladores stm32 y freeScale kinetis hasta el momento, aunque según el autor se irán incorporando microcontrolador de mas fabricante en el futuro.

Proceso de instalación se encuentra en la siguiente URL. http://gnuarmeclipse.livius.net/blog/plugin s-install/

Se adjunta en el DVD, proyectos configurados para la placa ST Nucleo F401RE y la placa stm32F4 discovery, además para la junta de desarrollo LPC1768.

78

Indicaciones para añadir nuevo Modem USB

A continuación detallo unas indicaciones para añadir soporte a un nuevo modem USB Vodafon recopiladas durante el análisis de la libreria VodafoneUSBModem, y gracias a las respuestas en el foro de mbed.org. solo son indicaciones no quiere decir que es suficiente para su funcionamiento.

1. El primer paso sería editar el fichero “WANDongleInitializer.cpp” y añadir una copia de una de las clases de inicialización de modem presentes por ejemplo la de K3770. 2. Cambiar el VID y PID en las funciones getMSDVid y getMSDPid de la nueva clase creada, estos dos datos deben ser el identifcador de vendedor (VID) e identificador de porducto (Pid) del modem cuando está en modo almacenamiento masivo. 3. Cambiar el VID y PID en las funciones getSerialVid y getSerialPid de la nueva clase para concordar con el VID y Pid del modem cuando está en modo ACM. 4. Editar vodafone_XXX_switch_packet para codificar el “flip String” necesario para cambiar de modo el modem de MSD(modo almacienamiento) a ACM(modo puerto serie virtual). 5. Ajustar el número endpoints en el método setVidPid de la nueva clase. 6. Añadir el nuevo el constructor de la nueva a clase la lista en: WANDongleInitializer::getInitializers 7. Añadir el tipo del nuevo modem al fichero “WANDongleInitializer.h”. 8. Añadir el código de inicialización oportuno a VodafoneUSBModem::init().

79

Descripción Conexiones Junta de desarrollo LPC1768

Figura 33 Descripción de pines LPC

REFERENCIAS - http://www.beyondlogic.org/usbnutshell/usb1.shtml#Intro duction. - http://home.mira.net/~gnb/gps/nmea.html#gprmc. - http://www.3gpp.org/DynaReport/27007.htm. - http://laboratorios.fi.uba.ar/lse/seminario/material- 2011/Sistemas_Embebidos-2011_2doC-C_para_Embebidos_ARM- Cruz.pdf - https://wiki.archlinux.org/index.php/Huawei_E1550_3G_modem - http://forum.xda-developers.com/showthread.php?t=2396752 - https://www.sparkfun.com/datasheets/Sensors/Biometric/MQ- 7.pdf - http://www.parallax.com/sites/default/files/downloads/605- 00009-MQ-5-Datasheet.pdf 80

- http://www.embedded.com/design/mcus-processors-and- socs/4026080/Building-Bare-Metal-ARM-Systems-with-GNU-Part-31 - http://www.beyondlogic.org/usbnutshell/usb1.shtml#Introduction - http://mbed.org/handbook/mbed-SDK - http://mbed.org/handbook/mbed-library-internals - http://gnuarmeclipse.livius.net/blog/ - https://launchpad.net/gcc-arm-embedded - https://www.olimex.com/Products/ARM/JTAG/_resources/OpenOC D/Introduction_to_Olimex_ODS.pdf - http://www.nxp.com/documents/leaflet/LPC1768.pdf - http://datasheet.octopart.com/LPC1768FBD100,551-NXP- datasheet-8326490.pdf - http://www.eclipse.org/cdt/ - http://openocd.sourceforge.net/ - https://launchpad.net/gcc-arm-embedded -

81

82