Car App - eva.fing.edu.uy · Car App Sistemas Embebidos para Tiempo Real 2012 RESUMEN Esto proyecto...

Car AppNotificación vía SMS y llamadas a celular de la

activación de una alarma.

Integrantes: Ramiro Barrón, Juan Martín Ortega, Andrea CukermanTutores: Leonardo Barboni, Leonardo Steinfeld

Curso Sistemas Embebidos 2012 – Instituto de Ingeniería EléctricaFacultad de Ingeniería Universidad de la República

Car App Sistemas Embebidos para Tiempo Real 2012

RESUMEN

Esto proyecto se basa en la implementación de un sistema de avisos al detectarse la activación de una alarma.

Para ello, se utiliza un micro controlador con el fin de integrar la alarma con un módulo GSM, el cual es capaz de generar los avisos correspondientes. La aplicación final a la cual se llegó es capaz de enviar y recibir SMSs, así también como de realizar llamadas a los números previamente definidos.

Para realizar esto se estudiaron los comandos AT, quienes permiten comunicarse a través del puerto serial con el módem GSM. Así, se llegó a la conclusión que el módem no respondía siempre de la misma forma, por lo que se implementaron funciones para configurar la uart dinámicamente.

Con el fin de hacerlo simple de configurar, el sistema posee también una lista de comandos, no excluyentes y fácilmente ampliable, que permiten setear los parámetros básicos del mismo.

Éstos, enviados como simples SMSs al número del sistema, permiten desde seleccionar los usuarios habilitados a interactuar con el sistema, hasta elegir el tiempo entre los avisos.

Se desarrolló un aplicación modularizada que permite reutilizar bloques. Además, utilizando herramientas de documentación, se logró una documentación clara que facilita la comprensión por terceros.

1


TABLA DE CONTENIDO

1. Introducción 3

1.1. Descripción del problema …....................................................................................... 3

1.2. Antecedentes …........................................................................................................... 3

2. Objetivos .…............................................................................................................................ 4

3. Alcance …................................................................................................................................ 4

4. Descripción del Sistema 5

4.1. Funcionamiento .......................................................................................................... 5

4.2. Configuración …......................................................................................................... 5

5. Diseño del Sistema 7

5.1. Arquitectura de Software …....................................................................................... 7

5.2. Diagramas de flujo ….…........................................................................................... 7

5.3. Diagrama de Bloques …............................................................................................. 9

6. Implementación 10

6.1. Herramientas de Desarrollo …................................................................................. 10

6.2. Módulos Implementados .......................................................................................... 11

7. Procedimiento de Testing y Resultados 13

7.1. Testeo de los módulos ….......................................................................................... 13

7.2. Testeo de los comandos …....................................................................................... 14

8. Conclusiones 16

9. Referencias 17

10. Anexos 18

10.1. Especificación del Proyecto …................................................................................ 18

10.2. Documentación generada en Doxygen …................................................................ 27

2


1. INTRODUCCIÓN

1.1 DESCRIPCIÓN DEL PROBLEMA

Las alarmas de automóviles convencionales cuentan con un sistema de protección capaz de activar una sirena con destellos de luces cuando se intenta forzar la entrada al vehículo.Esta sirena es activada mediante señales eléctricas provenientes de sensores volumétricos (detectan ruidos estridentes como la rotura de un vidrio) o de un forcejeo a las aberturas bloqueadas de puertas o valija, alertando al dueño de un intento de allanamiento.

En muchas ocasiones el individuo puede encontrarse a una distancia que no le permita escuchar la misma, o directamente no reconocer el sonido de su propia alarma, teniendo entonces que interrumpir sus actividades para verificar si es efectivamente la suya o no.

Con cifras de 70 vehículos robados por día en Uruguay (1), la inmediatez de la notificación cuando suena la alarma del auto de uno pasa a ser una necesidad .

1.2 ANTECEDENTES

El proyecto se basa en la idea original del curso de Sistemas Embebidos de la Facultad de Ingeniería de la Universidad de la República, de desarrollar un dispositivo capaz de sensar la señal de la alarma de seguridad en una casa y enviar mensajes de texto a un celular si se detecta la activación de la misma.

Entre los documentos empleados/consultados para el proyecto se destacan:

Proyecto Sisem 2011: GSM-Contiki. En la documentación de este proyecto se explica la configuración del módem GSM (2).

eZ430-RF2500. Kit de desarrollo que cuenta con el micro controlador MSP430 (3).

EVK-G26H: Kit de desarrollo que cuenta con los módulos GSM y GPS. En particular el módulo Leon G200 (4).

Obligatorio de C Sisem 2012: Shell Command. Se utiliza el shell command del obligatorio para interpretar los comandos enviados desde el celular.

LEON-G100_G200_AT_Commands_Manual_GSM.G1-SW-09002: Manual donde se describen todos los comandos AT empleados en el sistema.

3


2. OBJETIVOS

El proyecto consiste en desarrollar un sistema embebido basado en un microprocesador MSP430, el cual, una vez detectada la activación de una alarma, dé aviso de la misma.Estos avisos se harán mediante un sistema de envíos de mensajes de texto y llamadas a dos números de celular previamente configurados.

Asimismo, el proyecto apunta también a dotar de la mayor configurabilidad posible al sistema, permitiendo, entre otras cosas, elegir y modificar los números de celular mencionados.

Es meta del presente proyecto también, el conocer y aprender los comandos AT necesarios para lograr la comunicación con el módem GSM, ya sea esta para mandar y recibir mensajes de texto, como también para realizar y recibir llamadas de voz.

3. ALCANCE

El proyecto incluye:

✔ Diseño del sistema sobre el micro controlador MSP430✔ Comunicación entre el micro y el módulo GSM Leon G200✔ Circuito para simular la activación de la alarma✔ Respuestas vía mensajes de texto a consultas de comandos predefinidos✔ Elección del usuario de los Nº de celulares a enviar los mensajes y del tiempo de espera entre los avisos✔ Validación de los usuarios que interactúan con el sistema, y respuesta a consultas sólo a los permitidos✔ Gestión de usuarios

Queda fuera del alcance del presente proyecto:

✗ Fabricación de la alarma✗ Determinación de la ubicación usando el módulo GPS incluido en el kit EVK-G26H

En vista de los costos, y dado que las alarmas de los automóviles son distintas entre sí, se opta por simular la activación de la misma mediante el diseño de un circuito RC con switch.Por lo tanto, no será parte del proyecto la interconexión entre la alarma y el micro controlador.

4


4. DESCRIPCIÓN DEL SISTEMA

4.1 FUNCIONAMIENTO

Cada vez que la alarma se dispare, el sistema enviará un mensaje de texto al celular previamente configurado como primario notificando dicho suceso con el texto:

“ALERTA!. ALARMA ACTIVADA”.

Si transcurrido un tiempo dado definido por el usuario, la alarma aún no fue desactivada, el sistema responderá con una llamada de voz a dicho número de celular.

Habiendo pasado el mismo tiempo dado, y si la alarma todavía está activada, se enviará finalmente un nuevo mensaje de texto a otro celular, llamado auxiliar o secundario que también está previamente predefinido, con el texto:

“ALERTA!. ALARMA ACTIVADA. El celular < nºcel prioritario> no responde”.

No está prevista una cuarta instancia en caso de que la alarma continúe activa luego del tercer intento de notificación. Sin embargo, es de suponer que luego de transcurrido ese tiempo y habiendo dado aviso a 2 números de celular, es algo que difícilmente ocurra. De todos modos, es algo que puede ser agregado fácilmente si se quisiera.

4.2 CONFIGURACIÓN

Dado el objetivo planteado de hacer al sistema lo más configurable posible, el mismo cuenta además, con un intérprete de comandos. Estos comandos son simplemente palabras clave enviadas vía SMS al número de celular de Car App.

Los mismos pueden ser tanto de configuración del sistema de respuestas a la activación de la alarma, como también de consultas del usuario, permitiendo al mismo interactuar con el sistema. De este modo se tiene un mayor control sobre el mismo.

Para poder ser usados, el usuario deberá enviar un mensaje de texto al número de celular de Car App con el nombre del comando y sus parámetros, en caso de que corresponda, como cuerpo del mensaje.

Por ejemplo, si el usuario desea habilitar la notificación de mensajes de texto cada vez que se detecte que la alarma está activada, deberá enviar “ACTIVAR” al número de celular de Car App, y recibirá como respuesta:

“NOTIFICACIÓN ACTIVADA”.

5


A continuación, se describen los comandos para la configuración de algunos parámetros del sistema y sus respuestas:

TEXTO DEL SMS RESPUESTA DE Car App FUNCIÓN

ACTIVAR NOTIFICACIÓN ACTIVADAActiva la notificación de mensajes y llamadas cuando se dispara la alarma

DESACTIVAR NOTIFICACIÓN DESACTIVADADesactiva la notificación de mensajes y llamadas cuando se dispara la alarma

ENVIAR1 <nºcel prioritario> CEL PRIORITARIO: <nºcel prioritario>Configura el número dado como celular prioritario

ENVIAR2 <nºcel secundario> CEL SECUNDARIO: <nºcel secundario>Configura el número dado como celular secundario

AGREGAR <nºcel> USUARIO AGREGADO: <nºcel>Agrega el número a la lista de usuarios habilitados a interactuar con Car App

ELIMINAR <nºcel> USUARIO ELIMINADO: <nºcel>Elimina el número de la lista de usuarios habilitados a interactuar con Car App

TIEMPO <tiempo en minutos>TIEMPO ENTRE AVISOS: <tiempo> min.

Configura el tiempo de espera entre el envío del 1er mensaje y llamada, y entre llamada y 2º mensaje (en minutos).

Figura 1. Tabla con los parámetros de configuración del sistema.

Los comandos para la consulta acerca de la configuración son los siguientes:

TEXTO DEL SMS RESPUESTA DE Car App FUNCIÓN

USUARIOS<lista de usuarios habilitados a interactuar con Car App>

Despliega la lista de números de celulares habilitados a interactuar con Car App

CONFIGURACION<activación del envío, nºcel prioritario, nºcel secundario, tiempo>

Responde la configuración elegida por el usuario (estado de notificaciones, cel1, cel2 y tiempo)

AYUDA <lista de comandos disponibles>Despliega la lista de comandos disponibles

AYUDA <comando><descripción del comando>

Muestra la descripción del comando especificado luego de la palabra AYUDA

SALDO NO DISPONIBLEComando no disponible por razones ajenas al proyecto. Respondería el saldo del chip

UBICACION NO DISPONIBLEComando no disponible. No se encuentra dentro del alcance del proyecto

Figura 2. Tabla con los parámetros de consultas al sistema.

6


5. DISEÑO DEL SISTEMA

5.1 ARQUITECTURA DE SOFTWARE

La arquitectura adoptada para el desarrollo fue Round-Robin con interrupciones. Esto se debió principalmente debido a dos factores.

En primer lugar dado que permite asignarle cierta prioridad a las tareas mediante el uso de las interrupciones sin tener grandes requerimientos para el procesador.

En segundo lugar, esta decisión fue tomada en base a los requisitos de tiempo que se tenían. Si se toma en cuenta el tiempo normal que a una persona le lleva darse cuenta que la alarma de su automóvil es la que está sonando, y posteriormente el tiempo que le lleva desactivarla, está claro que se está en el orden de, como mínimo, varios segundos, sino algunos minutos.

Por lo tanto, se cree más que justificado el uso de dicha arquitectura de software en lugar de usar encolado de funciones por ejemplo, que si bien podría beneficiar en algo los tiempos de respuesta, no sería esta ganancia muy apreciable en la práctica.

Por otro lado, debido a la capacidad del micro y a los requerimientos del sistema, se optó por no usar un RTOS en el diseño de la arquitectura. Se consideró además, que la complejidad asociada al aprendizaje y manejo del mismo, no justificaba su elección para este proyecto. No obstante, si se considera que el uso de un RTOS puede traer ciertos beneficios, dada la clara orientación a eventos que tiene el sistema.

5.2 DIAGRAMAS DE FLUJO

Llegar al diseño final no fue sencillo. En una primera instancia se estudió como eran todos los posibles flujos que podía tomar el programa, y a partir de allí se decidió agrupar funcionalidades similares en módulos.

En base a esto, se llegó a la conclusión que la aplicación responde ante dos tipos de eventos bien diferenciados, a saber, la activación de la alarma, y la recepción de algún comando por parte de algún usuario, o, más general, la recepción de un mensaje de texto.

A continuación, se muestran los dos diagramas de flujo correspondientes a cada uno de estos casos:

7


Figura 3. Diagrama de flujo al activarse la alarma. Figura 4. Diagrama de flujo al recibirse un SMS.

Finalmente y habiendo llegado a los diagramas anteriores, se decidió que la mejor opción de diseño para la aplicación era mediante la implementación de máquinas de estado.

En total, se decidieron realizar cuatro máquinas de estado:

Una de ellas es la que se encarga del envío de SMSs, otra es la que realiza las llamadas de voz. Luego, hay una cuya función es implementar el diagrama de flujos para el caso de la activación de la alarma, y finalmente, hay otra que realiza la configuración del módem GSM.

Posteriormente, en el main de la aplicación, se llaman a éstas máquinas de estados a través del seteo de banderas, implementando la ya mencionada arquitectura de round robin (con interrupciones).

8


5.3 DIAGRAMA DE BLOQUES

Como bien se dijera anteriormente, el sistema fue pensado para ser modular.El mismo, como se muestra en la Figura 5, consta esencialmente de 3 módulos base que son CONTROL, SHELL, y COMUNICACIÓN.

Cuando el sistema es interrumpido lo que indica que la alarma se activó, el módulo CONTROL actúa como una máquina de estados decidiendo según el timer y el estado de la señal que indica la activación de la alarma, el envío de los mensajes de texto, y la llamada a los celulares correspondientes.

Por el contrario, si un usuario, esté o no habilitado para interactuar con el sistema, envía un SMS al número de Car App, es el módulo SHELL el que ejecutará el comando enviado como palabra en el mensaje (previa validación tanto del usuario como del comando).

El módulo de COMUNICACIÓN tiene como finalidad el envío y la decodificación de los mensajes de texto enviados al sistema. Es quien interactúa, por intermedio del módulo UART, que hace las veces de capa física, con el módulo GSM, ya sea enviándole comandos AT o recibiendo e interpretando las respuestas del mismo.

Figura 5. Diagrama de bloques del sistema.

Finalmente, como se expusiera previamente, no consistió parte del presente proyecto la fabricación de la alarma, sino que la misma, o más concretamente, la activación de la misma, fue simulada utilizando un pequeño circuito de hardware de fabricación propia.

El mismo tomaba la alimentación del propio módulo ezRF2500, y simplemente la realimentaba luego de pasarla por un circuito RC y un switch, a uno de sus puertos. De esta forma, mediante el uso del switch se controlaba la activación o no de la alarma.

Asimismo, dado el hardware con el que se disponía, no se logró una comunicación directa entre el micro y el módulo GSM. Esto fue debido a los requisitos de handshaking del módem GSM, el cual necesitaba usar las señales RTS/CTS no disponibles en el ezRF2500. Se pudo haber manejado las mismas usando los puertos de éste último módulo, pero lamentablemente no se contó con tiempo suficiente.

La conexión se hizo en definitiva, utilizando la PC como puente lo cual se explica a continuación.

9


6. IMPLEMENTACIÓN

La aplicación que se va a desarrollar no requiere mucha memoria, por lo que la memoria disponible en el micro controlador MSP430F2274 contenido en el RF2500 se considera más que suficiente.

Por otra parte, el kit de desarrollo EVK-G26H, es la plataforma de hardware donde residen tanto el módulo de comunicación GSM como el módulo GPS, mediante los cuales se logran el envió y recepción de mensajes de texto y la localización del automóvil. El módulo GPS está fuera del alcance del proyecto.

Estos módulos se comunican a través de la UART con el micro controlador, que es donde reside el corazón del sistema.

6.1 HERRAMIENTAS DE DESARROLLO

Durante el transcurso del proyecto se trabajó con el software IAR Embedded Workbench de Texas Instruments tanto para la compilación como también para la descarga de programas al micro. Esta herramienta fue también fue utilizada para debuggear el programa en busca de los errores que fueron surgiendo durante el testing, y más en general, durante todo el desarrollo del proyecto.

Para realizar la comunicación con el módem GSM se utilizaron dos programas de terminal. En una primera instancia se utilizó Terminal.exe para poder identificar claramente cuales eran las respuestas del módem GSM ante las distintas acciones como ser concretamente llamadas o mensajes de texto. Luego, se utilizó la aplicación Realterm. Esto se debió a que la misma cuenta con una función denominada echo port la cual permitió comunicar el micro con el módem GSM. Es decir, fue gracias a la misma que se logró “bypassear” la PC y simular la interconexión directa entre el micro y el módulo GSM.

IAR Embedded Workbench for MSP430

Set de herramientas de IAR Systems para la familia MSP430 de Texas Instruments. Incluye compilador, ensamblador, linker y debugger. Fue la herramienta de desarrollo que se utilizó durante el transcurso de todo el proyecto.

Realterm

Terminal que permite la conexión a los puertos seriales. Dentro de las variadas configuraciones que posee, se utilizó especialmente el echo port para conectar el módem GSM al micro, utilizando la PC de enlace.

Terminal

Al igual que Realterm, Terminal permite conectarse a los puertos seriales de las PCs. A diferencia de Realterm, no posee echo port. Sin embargo, su utilización se debió a que es bastante más simple el envío de mensajes, o más genéricamente, de datos, mediante este programa que mediante Realterm.Por lo tanto, éste fue el software elegido durante la etapa de pruebas de las respuestas del módem a los diferentes comandos AT enviados.

10


6.2 MÓDULOS IMPLEMENTADOS

Para facilitar su entendimiento y agrupar funcionalidades, se decidió separar la aplicación en 8 módulos.Cada uno de ellos cuenta con su archivo de encabezado donde se define su interfaz pública, y con su archivo fuente.

En el siguiente diagrama se muestra la interconexión de los módulos principales junto con sus funciones públicas.

Figura 6. Estructura de archivos.

El archivo central, carapp.h, es donde reside el corazón del programa. Éste se comunica con control.h, que como fue descrito anteriormente, es la máquina de estados que decide, según el timer (ubicado en timer.h) y el estado de la bandera que indica si la señal externa sigue activa, el envío de mensajes de texto y llamados.

De ésto mismo se encargan las funciones del archivo gsm.h, que se comunican a su vez con la uart para determinar el correcto envío del mensaje según las respuestas del módulo GSM.

Esta comprobación se realiza mediante el seteo de caracteres de fin de línea como separadores en la uart.h, y la decodificación de la trama en base a esto en el gsm.h.

Finalmente, los módulos shell y shell_commands son utilizados para ejecutar los comandos una vez decodificados por la función en el archivo gsm.h (stream_deco()).

NOTA: En el diagrama no se muestra para mayor claridad, el módulo aux_functions el cual contiene algunas funciones auxiliares usadas principalmente por los módulos shell y shell_commands.

11


A continuación se listan todos los módulos con una pequeña descripción de los mismos:

Car-app.c - Módulo que contiene el programa principal del sistema. Desde su bucle infinito se van chequando las banderas e invocando según estas a las funciones pertinentes de los diferentes módulos.

Uart.c - Módulo encargado de transmitir y recibir los datos. Es la capa física del sistema que permite la interacción entre el módulo gsm y el microcontrolador. Incluye funciones para poder elegir el caracter deseado, y la cantidad de veces que tiene que aparecer, para considerar el mensaje como completo. Además, tiene funciones que se encargan de toda la inicialización, así también como del envío de datos.

Gsm.c - Módulo que maneja la comunicación del micro con el módem. En este módulo se implementan las máquinas de estados para realizar llamadas, enviar mensajes y configurar el modem. Además, se definen los celulares de notificación junto con las funciones necesarias para modificarlos y consultarlos. Define un proceso que filtra los comandos recibidos desde la Uart.

Control_alarma.c - Módulo encargado de controlar las notificaciones a los celulares predefinidos. Controla las notificaciones mediante una máquina de estados, la cual envía los mensajes, o realiza la llamada correspondiente a partir de eventos externos como activación de la alarma, o expiración del tiempo entre avisos. Tambíen incluye un proceso para configurar el puerto de interrupción y la rutina de atención al mismo.

Shell.c - Intérprete de comandos. Recibe una cadena de carecteres que especifica un comando. El comando está especificado por el nombre y además permite recibir parámetros separados por espacios. Al recibir un string lo procesa para obtener los parámetros y el nombre de comando. Luego llama a la función correspondiente.

Shell_commands.c - Módulo donde se definen los comandos y la lista de los mismos con el puntero que apunta a la función y su descripción. En este módulo también se definen la lista de usuarios que tienen permitido modificar la configuración de la alarma.

Timer.c - Módulo encargado del control de tiempos del sistema. El mismo se usa tanto para medir el tiempo entre las distintas notificaciones, como también para implementar los time out en caso de que el sistema tenga algún problema imprevisto.

Aux_functions.c - Archivo que contiene funciones auxiliares que se utilízan en los distintos módulos de la aplicación. Incluye funciones para comparar dos cadenas de forma insensible a mayúsculas y minúsuculas, y para convertir un entero en una cadena.

Para ver una descripción detallada de las funciones que cada uno de ellos posee, ver la Documentación Doxygen incluida en el Anexo.

12


7. PROCEDIMIENTO DE TESTING Y RESULTADOS

7.1 TESTEO DE LOS MÓDULOS

Dado que el sistema completo, como se vio, involucra diversos módulos, no se intentó comprobar su correcto funcionamiento desde el inicio, sino que se siguieron una serie de pruebas antes.

Estas pruebas en esencia, consistieron en probar primeramente la funcionalidad de todos los módulos por separado, para luego ir probando la correcta interacción entre los mismos.

Así, dado que los módulos UART y TIMER habían sido previamente implementados como parte de los laboratorios de la asignatura, los mismos fueron los primeros en revisarse y ajustarse acorde a las necesidades del sistema.

Usando la aplicación Terminal.exe se verificó el correcto funcionamiento del módulo UART, haciendo hincapié principalmente en la correcta detección del carácter de fin de trama elegido, el cual, contrariamente a lo hecho en el laboratorio, se hizo configurable así también como la cantidad de veces que debía detectarse para considerarse el mensaje como completo. Esto, claramente apuntaba al uso que se le dio después para detectar las diferentes respuestas del módem como se explicó anteriormente.

Simultáneamente con esto, y como primer acercamiento a los comandos AT, lo primero que se hizo con el módulo GSM fue probarlo usando el propio software que viene con el kit EVK-G26H. Esto permitió aprender como se usan los comandos AT, que comandos iban a ser necesarios, y fundamentalmente, cuales iban a ser las respuestas del módem a cada uno de éstos, y en cada uno de los casos.

Analizados éstos y con la UART andando, se procedió a verificar la correcta comunicación entre el micro controlador y el módulo GSM, a través de la misma.Para esto, básicamente se usaron las propias funciones definidas en el módulo UART para mandarle comandos AT al módem.

Para esta instancia resultó crucial el uso de la aplicación RealTerm la cual permitió el reenvío de los datos enviados por el micro controlador por uno de los puertos de la PC, hacia otro de los puertos de la PC en donde se encontraba conectado el módulo GSM, y viceversa. Todos los datos intercambiados además, podían ser visualizados en una misma pantalla.

Luego de lograda la comunicación, se procedió a implementar y testear el módulo GSM encargado de manejar toda la interacción con el módem.El correcto funcionamiento de éste fue claramente verificado una vez se logró recibir en un celular cualquiera un mensaje de texto proveniente del sistema. Para poder llegar a esto se fue verificando paso a paso, que la máquina de estados implementada para lograr el envío de mensajes de texto, estuviese andando bien y cambiando de estado correctamente.

Una vez chequeado lo anterior, se pasó a la etapa de integración de los módulos GSM y UART con los módulos TIMER y CONTROL_ALARMA.

Esencialmente, al igual que con la verificación del envío de mensajes de texto, acá se procedió a revisar paso a paso que la máquina de estados que controla el funcionamiento básico del sistema estuviera cambiando de estado correctamente, y que se estuvieran ejecutando las funciones correspondientes. Asimismo, fue acá que también se verificó que el timer estuviera interrumpiendo adecuadamente.

13


7.2 TESTEO DE LOS COMANDOS

Finalmente y con todos los módulos ya implementados y funcionando, se pasó a probar los módulos SHELL y SHELL_COMMANDS, quienes se encargan de la interacción con los usuarios mediante la decodificación y ejecución de los comandos.

Esta etapa se hizo de forma bastante exhaustiva:

En primer lugar se probaron todos y cada uno de los comandos tanto los implementados como los que aún no están disponibles (SALDO y UBICACIÓN), escribiendo los mismos todo con mayúsculas. Se constataron en todos los casos las respuestas esperadas de antemano.

Seguido a esto, se volvieron a probar todos los comandos escribiéndolos de forma aleatoria. Esto es, todo en minúsculas, con la primera letra en mayúscula y luego el resto en minúscula, etc.

Esto se hizo para verificar que efectivamente el sistema fuera insensible a mayúsculas y minúsculas, cosa que nos pareció necesaria (aunque no era un requisito de diseño) dados los distintos métodos de escritura de los diferentes celulares. Nuevamente, se vio que las respuestas eran las esperadas.

Con todos los comandos verificados, se pasó a chequear la lógica del sistema.

Entre otras cosas, se verificaron las siguientes situaciones:

➢ Activar y Desactivar las notificaciones – Se vio que efectivamente se manden o dejen de mandar los avisos a los celulares según el estado de las notificaciones se encuentre activo o no.

➢ Intento de Eliminar el número de celular madre – El sistema responde “NO PERMITIDO”. Esto es porque se entiende que el sistema debe tener siempre al menos un número de celular, llamado madre, guardado para su correcto funcionamiento. De lo contrario, no tiene a quien avisar perdiendo su razón de ser.

➢ Intento de Eliminar un número de celular no existente – Se comprobó que el sistema efectivamente, primero comprueba la existencia del número antes de intentar eliminarlo. Responde “USUARIO INEXISTENTE”.

➢ Intento de Agregar un número de celular ya agregado – Análogo al caso anterior, se pudo ver que el sistema antes de añadir un nuevo número a la lista de usuarios habilitados, verifica primeramente su existencia. Esto se hizo para evitar completar la lista con un mismo número de teléfono lo cual no tendría mucho sentido. El sistema responde: “USUARIO EXISTENTE”.

➢ Control de respuestas de mensajes a lista de usuarios permitidos únicamente – Se verificó que el sistema responde exclusivamente a aquellos usuarios que reconoce, ignorando las solicitudes de otros usuarios. Si bien se podría haber optado por responderles a los mismos indicándoles que no tienen permisos suficientes o algo similar, se optó por ignorar sus solicitudes a efectos de preservar el saldo del chip.

➢ Agregar más usuarios de los permitidos – El sistema responde: “AGENDA COMPLETA”. Se comprobó que el sistema no deja agregar usuarios si no tiene lugar en el espacio reservado en memoria para tal fin.

➢ Respuesta a comando no existente – Se constató que en caso de que el comando no sea reconocido por el sistema o tenga una cantidad errónea de parámetros, el mismo responde: “COMANDO NO EXISTE. UTILICE: AYUDA (COMANDO)” o “CANTIDAD DE PARAMETROS ERRONEA” respectivamente.

14


➢ Control de mayúsculas y minúsculas en todos los comandos – Por lo dicho antes, se vio que el sistema responde tanto si los comandos se pasan en mayúsculas, en minúsculas, o con cualquier variante entre ambas.

➢ Interrupción de la alarma durante la comunicación de SMS – Se pudo comprobar que si la alarma es activada mientras se está llevando a cabo el envío de un SMS, el mismo se termina de enviar primero, y recién después se pasa a atender a la alarma. Esto, como ya se dijo, se debe a los tiempos que se manejan para el envío de los mensajes, y en ningún caso causó problemas para responder a la activación de la alarma. Las “demoras” siempre fueron mínimas, del orden de algunos pocos segundos.

Por último, cabe destacar que también se testeó el correcto funcionamiento del hardware diseñado para simular la alarma, así también como se chequeó que efectivamente interrumpía al micro controlador de la forma esperada.

También se constató que el envío de mensajes y las llamadas de voz fueran hechos según el estado de la señal proveniente del hardware y el tiempo configurado previamente.

15


8. CONCLUSIONES

Como primera conclusión se puede decir que se cumplió con el objetivo primario planteado dado que se cumplieron con todos los requisitos impuestos y deseados cuando se comenzó el proyecto.

Se logró una aplicación modular que permite al usuario interactuar con el sistema, permiténdole además, confiurarlo de manera deseada y fácil.

Se crearon ciertos aspectos de seguridad, entre los que se destacan: listas de usuarios para validación de los mismos, notificaciones con mensajes de error, y la encapsulación de ciertas variables sensibles del sistema.

Por todo esto se puede concluir que, a no ser por algunos aspectos que quedaron fuera del alcance del proyecto, se logró desarrollar una aplicación “usable” en la realidad.

Otro punto a destacar, es la posibilidad que nos brindó el proyecto para aprender y aplicar, no sólo los conceptos desarrollados durante el curso, sino también de aprender sobre la tecnología GSM. En concreto, sobre los diferentes comandos AT, sus usos y respuestas esperables.

Si bien se plantearon algunas complicaciones al momento de implementar la aplicación, la mayor dificultad creemos surgió de que no se partió de una buena planificación. Esto, evidentemente nos deja como aprendizaje que realizar una buena planificación y un buen diseño antes de empezar a desarrollar los proyectos resulta clave luego a la hora de su implementación.

El proyecto fue además, una muy buena oportunidad para profundizar ciertos conceptos vistos en clase. En particular, la buena estructuración del código y el diseño modular del mismo, la metodología de desarrollo haciendo hincapié sobre todo en el constante testeo de lo que se va haciendo, detectar y prevenir el problema de datos compartidos, etc.

Por último, también hay que hacer mención al aprendizaje que nos brindó el proyecto en cuanto a 2 de las herramientas usadas. En concreto, al uso de SubVerion como forma de controlar las distintas versiones que se iban haciendo, y a DoxyGen como generador automático de documentación.

Como conclusión final se puede decir que si bien se alcanzaron los objetivos, el desarrollo del proyecto no fue el ideal dado que creemos hay cosas que se deberían mejorar.

Entre estas destacamos:

● Integrar los elementos del sistema en un mismo dispositivo● Poder consultar el saldo del chip● Desarrollar la aplicación del módulo GPS capaz de sincronizar y desplegar en el GPS del celular la

ubicación del automóvil● Lograr conectar y probar el sistema con una alarma real

16


9. REFERENCIAS

(1) http://www.elpais.com.uy/090105/pciuda-391153/ciudades/ (2) http://iie.fing.edu.uy/cursos/file.php/29/proyectos/2011/GSM-Contiki/GSM-Contiki.pdf (3) http://www.ti.com/lit/ug/slau227e/slau227e.pdf (4) http://www.rfdesign.co.za/files/5645456/evk-g26h.pdf

17

http://www.rfdesign.co.za/files/5645456/evk-g26h.pdf

http://www.ti.com/lit/ug/slau227e/slau227e.pdf

http://iie.fing.edu.uy/cursos/file.php/29/proyectos/2011/GSM-Contiki/GSM-Contiki.pdf

http://www.elpais.com.uy/090105/pciuda-391153/ciudades/


10. ANEXOS

18

Especificación Finalcar-app

car-appDesarrollo de un sistema embebido conectado a la alarma de un auto capaz de enviar

mensajes de texto a un celular cada vez que la alarma se active

Integrantes: Ramiro Barron, Juan Martin Ortega, Andrea CukermanTutores: Leonardo Barboni, Leonardo Steinfeld

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Descripción del problema a ser resuelto

Las alarmas de automóviles convencionales cuentan con un sistema de protección capaz de activar una sirena con destellos de luces cuando se intenta forzar la entrada al vehículo.Esta sirena es activada mediante señales eléctricas provenientes de sensores volumétricos (detectan ruidos estridentes como la rotura de un vidrio) o de un forcejeo a las aberturas bloqueadas de puertas o valija, alertando al dueño de un intento de allanamiento.

En muchas ocasiones el individuo puede encontrarse a una distancia que no le permita escuchar la sirena o no reconocer el sonido de su propia alarma, interrumpiendo sus actividades para verificar si es efectivamente la suya. Con cifras de 70 vehículos robados por día en Uruguay, la inmediatez de la notificación cuando suena la alarma del auto pasa a ser una necesidad (1).

El proyecto apuntará a desarrollar un sistema embebido capaz de sensar la señal de cualquier alarma instalada en el auto y alertar mediante un sistema de envíos de mensajes de textos y llamadas a dos celulares de elección que se está intentando forzar la entrada del auto. Además contará con la funcionalidad de obtener la ubicación del vehículo mediante el módulo GPS integrado al sistema.

Antecedentes

Se basa en la idea original del curso de Sistemas Embebidos de la Facultad de Ingeniería de la Universidad de la República de desarrollar un dispositivo capaz de sensar la señal de la alarma de seguridad en una casa y enviar mensajes de texto a un celular.Se anexa el manual de la alarma a utilizar.

Proyecto Sisem 2011: GSM-Contiki. En la documentación de este proyecto se explica brevemente la configuración del modem GSM.

eZ430-RF2500. Kit de desarrollo que cuenta con el microcontrolador.

EVK-G26H: Kit de desarrollo que cuenta con los modulos GSM y GPS.

Obligatorio C Sisem 2012: Shell Command. Se utiliza el shell command del obligatorio para interpretar los comandos desde el celular.


Objetivo

Desarrollo de un sistema embebido sobre un RF2500 que interactúa con un Módulo GSM y comprende la recepción de la señal trasmitida por la alarma de un auto y el envío de mensajes de texto y un sistema de llamadas a celulares especificados por el usuario. Además contará con funcionalidad del GPS integrado al Módulo GSM para localizar el automóvil en caso de robo o extravío.Se documenta y publica el proyecto.

Alcance del proyecto

La fabricación de la alarma no está contemplada dentro del alcance. Se trabajará en un principio con una alarma elegida del mercado según su costo y aplicaciones, pero se tomará como prioridad a lo largo del proyecto la adaptación del dispositivo para cualquier tipo de alarma de autos. No se creará hardware adicional, a excepción de un modulo de entrada para interpretar si la alarma se ha activado por algún motivo.

Descripción del sistema

Se desarrollará sobre un microcontrolador RF2500 que estará comunicado con un Módulo GSM Leon-G200 integrado al sistema, capaz de conectarse a la alarma en el auto mediante un modulo de entrada que sensará la señal de la alarma a la sirena.

Cada vez que la alarma se dispare, el sistema enviará un mensaje de texto al celular del usuario notificando que la entrada está siendo forzada. Si en un lapso de tiempo, definido por el usuario, no se desactiva la alarma, el sistema responderá con una llamada al celular. Transcurrido el mismo tiempo con la alarma todavía encendida, se llamará finalmente a un celular auxiliar predefinido.

Contará con la funcionalidad de localización del auto a través del GPS ya integrado al Módulo GSM. El usuario solicitará esta asistencia mediante el envío de un mensaje de texto con la palabra “Ubicación” y recibirá como respuesta la dirección (a definir en qué formato: calle-esquina, calle-numero) en forma de SMS.

Se contará con la siguiente lista de comandos administrados por el shell para la configuración del sistema:- Activar: habilita el envío de mensajes y llamadas.- Desactivar: inhabilita el envío de mensajes y llamadas.- Enviar1 <cel1>: setea como celular madre el número ingresado como cel1. - Enviar2 <cel2>: setea como celular auxiliar el número ingresado como cel2. - Tiempo <t>: selecciona <t> minutos como el tiempo que debe de esperar antes de llamar al celular

1 si no se apaga la alarma luego de haber enviado un mensaje de texto, que es el mismo tiempo que debe de esperar para llamar al celular 2 como último recurso.

- MostrarConfig: responde con un mensaje de texto al celular 1 la configuracion del sistema: el estado (activado o desactivado), los celulares configurados como 1 y 2, el tiempo que se especificó.

- Ubicación: responde con un mensaje del texto al celular 1 la dirección en donde se encuentra el auto.

- Saldo: responde con el saldo restante del GSM. Además notificará mediante un SMS al celular 1 cuando queden 5 mensajes de texto disponibles para enviar antes de que se acabe el saldo.

- Ayuda: responde con un mensaje de texto al celular 1 con un lista de comandos disponibles y su descripción correspondiente.


Estos comandos podrán ser accedidos a través del envío de mensajes de texto por parte del usuario al número del Módulo GSM con el nombre del comando como texto.

Diagrama de bloques del sistema:

Diagrama de bloques del EVK-G26H: (2)

Requerimientos y restricciones del sistema

La aplicación que se va a desarrollar no requiere mucha memoria, por lo que la memoria disponible en el microcontrolador MSP430F2274 se considera mas que suficiente.

Diseño preliminar El kit de desarrollo EVK-G26H, es la plataforma de hardware donde residen el modulo de comunicación GSM y el modulo GPS, mediante el cual se logra el envio y recepción de mensajes de texto y la localización del automóvil. Este modulo se comunica a través de la UART con el microcontrolador, donde reside el core del sitema. Para obtener el estado de la alarma, se crea un pequeño dispositivo de hardware que repite la señal que manda la alarma a la sirena.Debido a la capacidad del micro, se opto por no usar RTOS en el diseño de la arquitectura. La arquitectura adoptada para el desarrollo fue Round-Robin con interrupciones, ya que permite asignarle prioridad a las tareas mediante las interrupciones y no tiene grandes requerimientos para el procesador.

Planificación

Se planteará el proyecto según el cronograma del curso de Sistemas Embebidos.La cantidad de horas contempla el trabajo en conjunto de los integrantes del grupo.

Semanas según cronograma del curso

ETAPA TAREA Hrs 7 8 9 10 11 12 13 14 15 16

1 Releva


miento

Investigación de funcionamiento general de alarmas

6

Estudio de envío de mensajes de texto 6

Definición de hardware a utilizar 6

2

Presentación preliminar de proyectos

Preparación para la presentación 1

Presentación del proyecto en el curso 1

3

Compra de hardware

Compra del hardware elegido en la etapa 1 6

4

Especificación final del proyecto

Documentación de la especificación final 5

5Programación

Estudiar los comandos AT: Probar las funcionalidades de envio y recepcion de SMS

5

Estudiar las funcionalidades del GPS 5

Desarrollo de módulos: Implementar core. Adaptar SHELL. Desarrollar módulo de comunicación.

50

Comunicar EVK-G26H mediante UART.Desarrollar hardware IO.

10

6 Testing

Realizar el testing que comprenda el envío y recepción de mensajes

20

7

Presentación final del proyecto

Preparación para la presentación 8

Presentación del proyecto en el curso 1

Fin del Proyecto 130


Tiempos y costos

Según el cronograma, se prevé un tiempo de desarrollo de 10 semanas para tres estudiantes. El costo de equipamiento y componentes a adquirir es menor de U$S 200.

Referencias

(1) http://www.elpais.com.uy/090105/pciuda-391153/ciudades/ (2) http://www.rfdesign.co.za/files/5645456/evk-g26h.pdf

http://www.elpais.com.uy/090105/pciuda-391153/ciudades/

http://www.rfdesign.co.za/files/5645456/evk-g26h.pdf


ANEXO

CarApp

Generado por Doxygen 1.8.1

Indice general

1 Índice de estructura de datos 1

1.1 Estructura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Indice de archivos 3

2.1 Lista de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Documentación de las estructuras de datos 5

3.1 Referencia de la Estructura buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2 Documentación de los campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2.1 datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2.2 indice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Referencia de la Estructura cell_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5



3.2.2.1 number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Referencia de la Estructura shell_command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6



3.3.2.1 descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3.2.2 funcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3.2.3 nombre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Documentación de archivos 9

4.1 Referencia del Archivo aux_functions.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


4.1.2 Documentación de las funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.2.1 itoa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.2.2 stricmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Referencia del Archivo aux_functions.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10



II ÍNDICE GENERAL

4.2.2.1 itoa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.2.2 stricmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3 Referencia del Archivo car-app.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11



4.3.2.1 activate_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3.2.2 deactivate_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.3 get_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.4 get_flagConfigurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.5 get_sendingFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.6 get_status_flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.7 init_conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.8 main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3.2.9 reset_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.10 reset_flagConfigurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.11 reset_sendingFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.12 set_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.13 set_continue_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.14 set_continue_config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.15 set_continue_sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.16 set_control_flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.17 set_flagConfigurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.2.18 set_sendingFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 Referencia del Archivo car-app.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15



4.4.2.1 activate_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.2.2 deactivate_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.2.3 get_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.2.4 get_flagConfigurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.2.5 get_sendingFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.2.6 get_status_flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.7 init_conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.8 reset_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.9 reset_flagConfigurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.10 reset_sendingFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.11 set_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.12 set_continue_calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.13 set_continue_config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2.14 set_continue_sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Generado para CarApp por Doxygen

ÍNDICE GENERAL III

4.4.2.15 set_control_flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.2.16 set_flagConfigurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.2.17 set_sendingFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5 Referencia del Archivo control_alarma.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


4.5.2 Documentación de las enumeraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5.2.1 alarm_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


4.5.3.1 alarm_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5.3.2 conf_alarm_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5.3.3 Port_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5.4 Documentación de las variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5.4.1 alarm_control_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6 Referencia del Archivo control_alarma.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



4.6.2.1 alarm_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6.2.2 conf_alarm_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.7 Referencia del Archivo gsm.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


4.7.2 Documentación de las enumeraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.7.2.1 conf_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.7.2.2 sms_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7.2.3 state_call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


4.7.3.1 call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7.3.2 config_modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7.3.3 continue_sending_sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7.3.4 get_first_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7.3.5 get_second_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7.3.6 send_sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7.3.7 set_first_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7.3.8 set_second_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7.3.9 stream_deco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


4.7.4.1 call_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.4.2 estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.4.3 estate_config_modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.4.4 modem_response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.4.5 msj_text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


IV ÍNDICE GENERAL

4.7.4.6 recibed_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.4.7 RXbuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.4.8 text_to_send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.8 Referencia del Archivo gsm.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26



4.8.2.1 call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.8.2.2 config_modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8.2.3 continue_sending_sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8.2.4 get_first_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8.2.5 get_second_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8.2.6 send_sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8.2.7 set_first_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8.2.8 set_second_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.8.2.9 stream_deco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.9 Referencia del Archivo shell.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28


4.9.2 Documentación de los ’defines’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.9.2.1 MAX_PAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


4.9.3.1 shell_exec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


4.9.4.1 command_par . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.9.4.2 commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.9.4.3 number_par . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.9.4.4 users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.10 Referencia del Archivo shell.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30



4.10.2.1 shell_exec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.11 Referencia del Archivo shell_commands.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31



4.11.2.1 MAX_USERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32


4.11.3.1 activate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.11.3.2 addUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.11.3.3 credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.11.3.4 deactivate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.11.3.5 deleteUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


ÍNDICE GENERAL V

4.11.3.6 help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.11.3.7 location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.11.3.8 send1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.11.3.9 send2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.11.3.10 setTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.11.3.11 showConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.11.3.12 showUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


4.11.4.1 alarm_reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.11.4.2 commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.11.4.3 users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.12 Referencia del Archivo shell_commands.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36



4.12.2.1 activate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.12.2.2 addUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.12.2.3 credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.12.2.4 deactivate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.12.2.5 deleteUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.12.2.6 help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.12.2.7 location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.12.2.8 send1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.12.2.9 send2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.12.2.10 setTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.12.2.11 showConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.12.2.12 showUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.13 Referencia del Archivo timer.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39



4.13.2.1 MINUTE_TO_SECOND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41


4.13.3.1 conf_control_timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13.3.2 conf_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13.3.3 control_counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13.3.4 control_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13.3.5 get_control_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13.3.6 init_control_timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13.3.7 init_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.13.3.8 set_control_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.13.3.9 Timer_A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


VI ÍNDICE GENERAL

4.13.3.10 Timer_B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


4.13.4.1 alarm_control_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.14 Referencia del Archivo timer.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42



4.14.2.1 conf_control_timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.14.2.2 conf_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.14.2.3 get_control_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.14.2.4 init_control_timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.14.2.5 init_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.14.2.6 set_control_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.15 Referencia del Archivo uart.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44



4.15.2.1 P3RXD0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.15.2.2 P3TXD0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45


4.15.3.1 cargarTXbuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.15.3.2 get_flagRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.15.3.3 init_UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.15.3.4 initUART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.15.3.5 ISR_Rx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.15.3.6 ISR_Tx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.15.3.7 reset_flagRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.15.3.8 set_eofl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.15.3.9 set_number_eofl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


4.15.4.1 RXbuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.16 Referencia del Archivo uart.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47



4.16.2.1 TAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


4.16.3.1 cargarTXbuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.16.3.2 get_flagRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.16.3.3 init_UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.16.3.4 reset_flagRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.16.3.5 set_eofl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.16.3.6 set_number_eofl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49


Capıtulo 1

Indice de estructura de datos

1.1. Estructura de datos

Lista de estructuras con una breve descripción:

buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5cell_phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5shell_command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Índice de estructura de datos


Capıtulo 2

Indice de archivos

2.1. Lista de archivos

Lista de todos los archivos con descripciones breves:

aux_functions.cArchivo que contiene funciones auxiliares que se utilízan en los distintos módulos de la aplica-ción. Incluye funciones para comparar dos cadenas de forma insensible a mayúsculas y minús-cular, y para convertir un entero en una cadena . . . . . . . . . . . . . . . . . . . . . . . . . 9

aux_functions.hDefine la interfaz pública del módulo aux_functions . . . . . . . . . . . . . . . . . . . . . . . 10

car-app.cMódulo que contiene el programa principal del sistema. Desde su bucle infinito se van chequan-do las banderas e invocando según estas a las funciones pertinentes de los diferentes módulos 11

car-app.hDefine la interfaz pública del módulo car-app . . . . . . . . . . . . . . . . . . . . . . . . . . 15

control_alarma.cMódulo encargado de controlar las notificaciones a los celulares predefinidos. Controla las no-tificaciones mediante una máquina de estados, la cual envía los mensajes, o realiza la llamadacorrespondiente a partir de eventos externos como activación de la alarma, o expiración deltiempo entre avisos. Tambíen incluye un proceso para configurar el puerto de interrupción y larutina de atención al mismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

control_alarma.hDefine la interfaz pública del módulo control_alarma . . . . . . . . . . . . . . . . . . . . . . . 20

gsm.cMódulo que maneja la comunicación del micro con el módem. En este módulo se implementanlas máquinas de estados para realizar llamadas, enviar mensajes y configurar el modem. Ade-más, se definen los celulares de notificación junto con las funciones necesarias para modificarlosy consultarlos. Define un proceso que filtra los comandos recibidos desde la Uart . . . . . . . 21

gsm.hDefine la interfaz pública del módulo gsm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

shell.cIntérprete de comandos. Recibe una cadena de carecteres que especifica un comando. El co-mando está especificado por el nombre y además permite recibir parámetros separados porespacios. Al recibir un string lo procesa para obtener los parámetros y el nombre de comando.Luego llama a la función correspondiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

shell.hDefine la interfaz pública del módulo shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

shell_commands.cMódulo donde se definen los comandos y la lista de los mismos con el puntero que apunta ala función y su descripción. En este módulo también se definen la lista de usuarios que tienenpermitido modificar la configuración de la alarma . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Indice de archivos

shell_commands.hDefine la interfaz pública del módulo shell_commands. Se definen estructuras para listar loscomandos y los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

timer.cMódulo encargado del control de tiempos del sistema. El mismo se usa tanto para medir eltiempo entre las distintas notificaciones, como también para implementar los time out en casode que el sistema tenga algún problema imprevisto . . . . . . . . . . . . . . . . . . . . . . . 39

timer.hDefine la interfaz pública del módulo timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

uart.cMódulo encargado de transmitir y recibir los datos. Es la capa física del sistema que permitela interacción entre el módulo gsm y el microcontrolador. Incluye funciones para poder elegir elcaracter deseado, y la cantidad de veces que tiene que aparecer, para considerar el mensajecomo completo. Además, tiene funciones que se encargan de toda la inicialización, así tambiéncomo del envío de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

uart.hDefine la interfaz pública del módulo uart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


Capıtulo 3

Documentacion de las estructuras de datos

3.1. Referencia de la Estructura buffer

#include <uart.h>

Campos de datos

char datos [TAM]

int indice

3.1.1. Descripcion detallada

Define el formato de los buffers, tanto de transmisión como de recepción.

Definición en la línea 26 del archivo uart.h.

3.1.2. Documentacion de los campos

3.1.2.1. char datos[TAM]

Arreglo de caracteres donde se almacenan los datos.


3.1.2.2. int indice

Índice para recorrer el buffer.


La documentación para esta estructura fue generada a partir del siguiente fichero:

uart.h

3.2. Referencia de la Estructura cell phone

#include <shell_commands.h>

6 Documentación de las estructuras de datos

Campos de datos

char number [15]


Guarda los números de celulares habilitados a interactuar con el sistema.

Definición en la línea 34 del archivo shell_commands.h.


3.2.2.1. char number[15]

Arreglo de caracteres donde se almacena el número de celular.



shell_commands.h

3.3. Referencia de la Estructura shell command

#include <shell_commands.h>

Campos de datos

char ∗ nombre

char ∗ descripcion

void(∗ funcion )()


Define el formato de los comandos.



3.3.2.1. char∗ descripcion

String que describe la funcionalidad del comando.


3.3.2.2. void(∗ funcion)()

Puntero a la función que implementa el comando.



3.3 Referencia de la Estructura shell_command 7

3.3.2.3. char∗ nombre

String para el nombre del comando.



shell_commands.h


8 Documentación de las estructuras de datos


Capıtulo 4

Documentacion de archivos

4.1. Referencia del Archivo aux functions.c

Archivo que contiene funciones auxiliares que se utilízan en los distintos módulos de la aplicación. Incluye funcionespara comparar dos cadenas de forma insensible a mayúsculas y minúscular, y para convertir un entero en unacadena.

#include <string.h>#include <ctype.h>#include "aux_functions.h"

Funciones

int stricmp (char ∗str1, char ∗str2)

Compara la cadena apuntada por str1 con la cadena apuntada por str2 sin sensibilidad a mayúsculas.

char ∗ itoa (int integer)

Convierte el entero integer en una cadena de caracteres.


Archivo que contiene funciones auxiliares que se utilízan en los distintos módulos de la aplicación. Incluye funcionespara comparar dos cadenas de forma insensible a mayúsculas y minúscular, y para convertir un entero en unacadena.

Autor

Juan Martín Ortega, Ramiro Barrón, Andrea Cukerman

Fecha

Junio 2012

Definición en el archivo aux_functions.c.

4.1.2. Documentacion de las funciones

4.1.2.1. char ∗ itoa ( int integer )


10 Documentación de archivos

Parametrosinteger Entero a convertir.

Devuelve

Retorna un puntero que apunta a la cadena convertida.

Definición en la línea 60 del archivo aux_functions.c.

4.1.2.2. int stricmp ( char ∗ str1, char ∗ str2 )


Parametrosstr1 Cadena a comparar.str2 Cadena a comparar.

Devuelve

Retorna un número entero indicando la relación entre las dos cadenas. Cero si ambas cadenas son iguales,mayor que cero si la cadena apuntada por str1 es mayor que la apuntada por str2, y menor que cero en el casocontrario al anterior.


4.2. Referencia del Archivo aux functions.h

Define la interfaz pública del módulo aux_functions.

Funciones

int stricmp (char ∗str1, char ∗str2)


char ∗ itoa (int integer)



Define la interfaz pública del módulo aux_functions.

Autor


Fecha

Junio 2012

Definición en el archivo aux_functions.h.


4.3 Referencia del Archivo car-app.c 11


4.2.2.1. char∗ itoa ( int integer )


Parametrosinteger Entero a convertir.

Devuelve

Retorna un puntero que apunta a la cadena convertida.


4.2.2.2. int stricmp ( char ∗ str1, char ∗ str2 )


Parametrosstr1 Cadena a comparar.str2 Cadena a comparar.

Devuelve

Retorna un número entero indicando la relación entre las dos cadenas. Cero si ambas cadenas son iguales,mayor que cero si la cadena apuntada por str1 es mayor que la apuntada por str2, y menor que cero en el casocontrario al anterior.


4.3. Referencia del Archivo car-app.c

Módulo que contiene el programa principal del sistema. Desde su bucle infinito se van chequando las banderas einvocando según estas a las funciones pertinentes de los diferentes módulos.

#include <string.h>#include "gsm.h"#include "uart.h"#include "shell.h"#include "control_alarma.h"#include "car-app.h"#include "timer.h"

Funciones

void main ()

Programa principal.

void init_conf ()

Inicializa las banderas para que configure el módem.

void activate_alarm ()



Función que setea la bandera flagActive para indicar que la notificación de eventos de la alarma está activa.void deactivate_alarm ()

Función que setea la bandera flagActive para indicar que la notificación de eventos de la alarma ya NO está activa.int get_status_flag ()

Función que devuelve el estado de la bandera control_flag.void set_control_flag ()

Función que setea la bandera control_flag.int get_sendingFlag ()

Función que devuelve el estado de la bandera que indica que se está enviando un SMS.void set_sendingFlag ()

Función que setea la bandera de enviando SMS.void set_calling ()

Función que setea la bandera de llamada en curso.void reset_calling ()

Función que resetea la bandera de llamada en curso.void set_continue_config ()

Función que setea la bandera para continuar configurando.int get_flagConfigurando ()

Función que devuelve el estado de la bandera que indica que se está configurando el módem.void set_flagConfigurando ()

Función que setea la bandera que indica que se está configurando el módem.void reset_flagConfigurando ()

Función que indica que se termino de configurar bajando la bandera.void reset_sendingFlag ()

Función que baja bandera que indica que se está enviando un SMS.void set_continue_sending ()

Función que setea la bandera continue_sending para continuar con el envío de SMS.int get_calling ()

Función que devuelve si se está realizando una llamada o no.void set_continue_calling ()

Función que devuelve el estado de la bandera control_flag.


Módulo que contiene el programa principal del sistema. Desde su bucle infinito se van chequando las banderas einvocando según estas a las funciones pertinentes de los diferentes módulos.

Autor


Fecha

Junio 2012

Definición en el archivo car-app.c.


4.3.2.1. void activate alarm ( )

Función que setea la bandera flagActive para indicar que la notificación de eventos de la alarma está activa.

Definición en la línea 145 del archivo car-app.c.


4.3 Referencia del Archivo car-app.c 13

4.3.2.2. void deactivate alarm ( )

Función que setea la bandera flagActive para indicar que la notificación de eventos de la alarma ya NO está activa.


4.3.2.3. int get calling ( )

Función que devuelve si se está realizando una llamada o no.

Devuelve

Entero que indica el estado de la bandera.


4.3.2.4. int get flagConfigurando ( )

Función que devuelve el estado de la bandera que indica que se está configurando el módem.

Devuelve



4.3.2.5. int get sendingFlag ( )

Función que devuelve el estado de la bandera que indica que se está enviando un SMS.

Devuelve



4.3.2.6. int get status flag ( )


Devuelve



4.3.2.7. void init conf ( )



4.3.2.8. void main ( )

Programa principal.




4.3.2.9. void reset calling ( )

Función que resetea la bandera de llamada en curso.


4.3.2.10. void reset flagConfigurando ( )

Función que indica que se termino de configurar bajando la bandera.


4.3.2.11. void reset sendingFlag ( )

Función que baja bandera que indica que se está enviando un SMS.


4.3.2.12. void set calling ( )

Función que setea la bandera de llamada en curso.


4.3.2.13. void set continue calling ( )



4.3.2.14. void set continue config ( )

Función que setea la bandera para continuar configurando.


4.3.2.15. void set continue sending ( )

Función que setea la bandera continue_sending para continuar con el envío de SMS.


4.3.2.16. void set control flag ( )

Función que setea la bandera control_flag.


4.3.2.17. void set flagConfigurando ( )

Función que setea la bandera que indica que se está configurando el módem.



4.4 Referencia del Archivo car-app.h 15

4.3.2.18. void set sendingFlag ( )

Función que setea la bandera de enviando SMS.


4.4. Referencia del Archivo car-app.h

Define la interfaz pública del módulo car-app.

Funciones

void init_conf ()


void activate_alarm ()


void deactivate_alarm ()


int get_status_flag ()


void set_control_flag ()


int get_sendingFlag ()


void set_sendingFlag ()


void set_calling ()


void reset_calling ()


void set_continue_config ()


int get_flagConfigurando ()


void set_flagConfigurando ()


void reset_flagConfigurando ()


void reset_sendingFlag ()


void set_continue_sending ()


int get_calling ()


void set_continue_calling ()





Define la interfaz pública del módulo car-app.

Autor


Fecha

Junio 2012

Definición en el archivo car-app.h.


4.4.2.1. void activate alarm ( )



4.4.2.2. void deactivate alarm ( )



4.4.2.3. int get calling ( )


Devuelve



4.4.2.4. int get flagConfigurando ( )


Devuelve



4.4.2.5. int get sendingFlag ( )


Devuelve




4.4 Referencia del Archivo car-app.h 17

4.4.2.6. int get status flag ( )


Devuelve



4.4.2.7. void init conf ( )



4.4.2.8. void reset calling ( )



4.4.2.9. void reset flagConfigurando ( )



4.4.2.10. void reset sendingFlag ( )



4.4.2.11. void set calling ( )



4.4.2.12. void set continue calling ( )



4.4.2.13. void set continue config ( )



4.4.2.14. void set continue sending ( )





4.4.2.15. void set control flag ( )



4.4.2.16. void set flagConfigurando ( )



4.4.2.17. void set sendingFlag ( )



4.5. Referencia del Archivo control alarma.c

Módulo encargado de controlar las notificaciones a los celulares predefinidos. Controla las notificaciones medianteuna máquina de estados, la cual envía los mensajes, o realiza la llamada correspondiente a partir de eventosexternos como activación de la alarma, o expiración del tiempo entre avisos. Tambíen incluye un proceso paraconfigurar el puerto de interrupción y la rutina de atención al mismo.

#include "control_alarma.h"#include "gsm.h"#include "uart.h"#include "timer.h"#include <io430x22x4.h>#include "car-app.h"#include <string.h>

Enumeraciones

enum alarm_state { ENVIAR1 = 1, LLAMAR1, ENVIAR2 }

Define los estados de la máquina de estados encargada de enviar notificaciones.

Funciones

void alarm_control ()

Este proceso es la máquina de estados encargada de enviar notificaciones. Primero envía un sms con la alerta alcelular prioritario. Si pasado el tiempo entre notificaciones, previamente configurado, no se desactivo la alarma; llamaal celular prioritario. Si transcurre nuevamente el tiempo entre notificaciones y la alarma sigue activa, envía un smsal celular secundario.

void conf_alarm_control ()

Este proceso configura el pin 4 del puerto 2 para que interrumpa cuando se activa la alarma. También configura elpin 1 del puerto 1 (luz verde) como salida, y apaga la luz verde.

__interrupt void Port_1 (void)

Rutina de interrupción del pin 4 del puerto 2. Se verifíca si están habilitadas las notificaciones. Si están habilitadasse prende la bandera que habilíta la máquina de estados encargada de enviar las notificaciones y se deshabilita lainterrupción de este puerto. Si no están habilitadas, simplemente borra la bandera de la interrupción.


4.5 Referencia del Archivo control_alarma.c 19

Variables

int alarm_control_state

Variable tipo int que indica el estado de la máquina de estados encargada de enviar notificaciones.


Módulo encargado de controlar las notificaciones a los celulares predefinidos. Controla las notificaciones medianteuna máquina de estados, la cual envía los mensajes, o realiza la llamada correspondiente a partir de eventosexternos como activación de la alarma, o expiración del tiempo entre avisos. Tambíen incluye un proceso paraconfigurar el puerto de interrupción y la rutina de atención al mismo.

Autor


Fecha

Junio 2012

Definición en el archivo control_alarma.c.

4.5.2. Documentacion de las enumeraciones

4.5.2.1. enum alarm_state

Define los estados de la máquina de estados encargada de enviar notificaciones.

Valores de enumeraciones:

ENVIAR1

LLAMAR1

ENVIAR2

Definición en la línea 46 del archivo control_alarma.c.


4.5.3.1. void alarm control ( )

Este proceso es la máquina de estados encargada de enviar notificaciones. Primero envía un sms con la alertaal celular prioritario. Si pasado el tiempo entre notificaciones, previamente configurado, no se desactivo la alarma;llama al celular prioritario. Si transcurre nuevamente el tiempo entre notificaciones y la alarma sigue activa, envíaun sms al celular secundario.


4.5.3.2. void conf alarm control ( )





4.5.3.3. interrupt void Port 1 ( void )

Rutina de interrupción del pin 4 del puerto 2. Se verifíca si están habilitadas las notificaciones. Si están habilitadasse prende la bandera que habilíta la máquina de estados encargada de enviar las notificaciones y se deshabilita lainterrupción de este puerto. Si no están habilitadas, simplemente borra la bandera de la interrupción.


4.5.4. Documentacion de las variables

4.5.4.1. alarm control state



4.6. Referencia del Archivo control alarma.h

Define la interfaz pública del módulo control_alarma.

Funciones

void alarm_control ()

Este proceso es la máquina de estados encargada de enviar notificaciones. Primero envía un sms con la alerta alcelular prioritario. Si pasado el tiempo entre notificaciones, previamente configurado, no se desactivo la alarma; llamaal celular prioritario. Si transcurre nuevamente el tiempo entre notificaciones y la alarma sigue activa, envía un smsal celular secundario.

void conf_alarm_control ()



Define la interfaz pública del módulo control_alarma.

Autor


Fecha

Junio 2012

Definición en el archivo control_alarma.h.


4.6.2.1. void alarm control ( )

Este proceso es la máquina de estados encargada de enviar notificaciones. Primero envía un sms con la alertaal celular prioritario. Si pasado el tiempo entre notificaciones, previamente configurado, no se desactivo la alarma;llama al celular prioritario. Si transcurre nuevamente el tiempo entre notificaciones y la alarma sigue activa, envíaun sms al celular secundario.



4.7 Referencia del Archivo gsm.c 21

4.6.2.2. void conf alarm control ( )



4.7. Referencia del Archivo gsm.c

Módulo que maneja la comunicación del micro con el módem. En este módulo se implementan las máquinasde estados para realizar llamadas, enviar mensajes y configurar el modem. Además, se definen los celulares denotificación junto con las funciones necesarias para modificarlos y consultarlos. Define un proceso que filtra loscomandos recibidos desde la Uart.

#include "uart.h"#include "gsm.h"#include "shell.h"#include "timer.h"#include "car-app.h"#include <string.h>

Enumeraciones

enum sms_state { SEND_PHONE_NUMBER = 1, SEND_TEXT }

Define los estados de la máquina de estados encargada de enviar los SMS.

enum state_call { DO_CALL = 1, WAIT_ANSWER }

Define los estados de la máquina de estados encargada de realizar llamadas de voz.

enum conf_state {ATEO = 1, CMGF, CNMI, CLIP,END_C }

Define los estados de la máquina de estados encargada de configurar el módem.

Funciones

void send_sms (char ∗phone_number, char ∗msj_text)

Prepara el mensaje a ser enviado.

void continue_sending_sms ()

Máquina de estados que termina de enviar el sms preparado por send_sms(). Envía información al modem gsm, yespera respuesta del mismo para continuar con el flujo de información esperado.

void call ()

Máquina de estados encargada de realizar las llamadas. Envía comando AT para realizar la llamada y espera que lallamada finalice.

void config_modem ()

Esta función es la máquina de estados que realiza la configuración inicial del modem. Configura el modem en modotexto, que reenvíe mensajes recibidos por el puerto serie, que no mande ID de llamante, y que no mande por elpuerto serial un eco de lo recibido por el mismo.

void stream_deco ()

Función que se encarga de filtrar lo obtenido por la uart, para luego llamar al proceso correspondiente. Si recibe uncomando se encarga de ejecutar el shell. Si lo que recibe no es un comando, no modifica lo recibido y llama a lamáquina de estados necesaria para continuar con el flujo. No recibe parámetros de entrada, sin embargo, modificael buffer de recepción.

void set_first_phone (char ∗cel)

Configura el celular principal.



void set_second_phone (char ∗cel)

Configura el celular secundario.

char ∗ get_first_phone ()

Función pública que retorna el celular primario.

char ∗ get_second_phone ()

Función pública que retorna el celular secundario.

Variables

int estado

Variable tipo int que indica el estado del envío del SMS.

int estate_config_modem = ATEO

Variable tipo int que indica el estado en que se encuentra la configuración del módem.

int call_state = DO_CALL

Variable tipo int que indica el estado de la llamada de voz.

char msj_text [70]

Variable tipo arreglo de caracteres usada para guardar el texto del SMS a enviar.

char recibed_info [70]

Variable tipo arreglo de caracteres usada para almacenar el mensaje de texto que se recibe.

char text_to_send [100]

Variable tipo arreglo de caracteres donde se guarda el texto a enviar al módem.

char ∗ modem_response

Variable tipo char∗ usada para almacenar la respuesta del módem.

buffer RXbuffer

Variable tipo buffer para la recepción.


Módulo que maneja la comunicación del micro con el módem. En este módulo se implementan las máquinasde estados para realizar llamadas, enviar mensajes y configurar el modem. Además, se definen los celulares denotificación junto con las funciones necesarias para modificarlos y consultarlos. Define un proceso que filtra loscomandos recibidos desde la Uart.

Autor


Fecha

Junio 2012

Definición en el archivo gsm.c.

4.7.2. Documentacion de las enumeraciones

4.7.2.1. enum conf_state

Define los estados de la máquina de estados encargada de configurar el módem.


ATEO



CMGF

CNMI

CLIP

END_C

Definición en la línea 54 del archivo gsm.c.

4.7.2.2. enum sms_state

Define los estados de la máquina de estados encargada de enviar los SMS.


SEND_PHONE_NUMBER

SEND_TEXT


4.7.2.3. enum state_call

Define los estados de la máquina de estados encargada de realizar llamadas de voz.


DO_CALL

WAIT_ANSWER



4.7.3.1. void call ( )

Máquina de estados encargada de realizar las llamadas. Envía comando AT para realizar la llamada y espera quela llamada finalice.


4.7.3.2. void config modem ( )



4.7.3.3. void continue sending sms ( )





4.7.3.4. char ∗ get first phone ( )


Devuelve

Celular primario.


4.7.3.5. char ∗ get second phone ( )


Devuelve

Celular secundario.


4.7.3.6. void send sms ( char ∗ phone number, char ∗ msj text )


Parametrosphone_number Destinatario del mensaje.

msj_text Contenido del mensaje.


4.7.3.7. void set first phone ( char ∗ cel )


Parametroscel Celular principal.


4.7.3.8. void set second phone ( char ∗ cel )


Parametroscel Celular secundario.


4.7.3.9. void stream deco ( )

Función que se encarga de filtrar lo obtenido por la uart, para luego llamar al proceso correspondiente. Si recibe uncomando se encarga de ejecutar el shell. Si lo que recibe no es un comando, no modifica lo recibido y llama a la



máquina de estados necesaria para continuar con el flujo. No recibe parámetros de entrada, sin embargo, modificael buffer de recepción.



4.7.4.1. call state = DO_CALL

Variable tipo int que indica el estado de la llamada de voz.


4.7.4.2. estado

Variable tipo int que indica el estado del envío del SMS.


4.7.4.3. estate config modem = ATEO

Variable tipo int que indica el estado en que se encuentra la configuración del módem.


4.7.4.4. modem response

Variable tipo char∗ usada para almacenar la respuesta del módem.


4.7.4.5. msj text[70]

Variable tipo arreglo de caracteres usada para guardar el texto del SMS a enviar.


4.7.4.6. recibed info[70]

Variable tipo arreglo de caracteres usada para almacenar el mensaje de texto que se recibe.


4.7.4.7. RXbuffer


Definición en la línea 79 del archivo uart.c.

4.7.4.8. text to send[100]

Variable tipo arreglo de caracteres donde se guarda el texto a enviar al módem.




4.8. Referencia del Archivo gsm.h

Define la interfaz pública del módulo gsm.

Funciones

void send_sms (char ∗phone_number, char ∗msj_text)


void continue_sending_sms ()


void set_first_phone (char ∗cel)


void set_second_phone (char ∗cel)


char ∗ get_first_phone ()


char ∗ get_second_phone ()


void config_modem ()


void stream_deco ()


void call ()

Máquina de estados encargada de realizar las llamadas. Envía comando AT para realizar la llamada y espera que lallamada finalice.


Define la interfaz pública del módulo gsm.

Autor


Fecha

Junio 2012

Definición en el archivo gsm.h.


4.8.2.1. void call ( )

Máquina de estados encargada de realizar las llamadas. Envía comando AT para realizar la llamada y espera quela llamada finalice.



4.8 Referencia del Archivo gsm.h 27

4.8.2.2. void config modem ( )



4.8.2.3. void continue sending sms ( )



4.8.2.4. char∗ get first phone ( )


Devuelve

Celular primario.


4.8.2.5. char∗ get second phone ( )


Devuelve

Celular secundario.


4.8.2.6. void send sms ( char ∗ phone number, char ∗ msj text )


Parametrosphone_number Destinatario del mensaje.

msj_text Contenido del mensaje.


4.8.2.7. void set first phone ( char ∗ cel )


Parametroscel Celular principal.




4.8.2.8. void set second phone ( char ∗ cel )


Parametroscel Celular secundario.


4.8.2.9. void stream deco ( )



4.9. Referencia del Archivo shell.c

Intérprete de comandos. Recibe una cadena de carecteres que especifica un comando. El comando está especi-ficado por el nombre y además permite recibir parámetros separados por espacios. Al recibir un string lo procesapara obtener los parámetros y el nombre de comando. Luego llama a la función correspondiente.

#include <string.h>#include <ctype.h>#include "shell_commands.h"#include "gsm.h"#include "shell.h"#include "aux_functions.h"

’defines’

#define MAX_PAR 4

Constante que define la máxima cantidad posible de parámetros esperados para un comando.

Funciones

void shell_exec (char ∗str)

Función que procesa el string recibido para obtener el comando y sus parámetros. Luego, busca y ejecuta el comandopasado. De no encontrarse el comando devuelve un mensaje de error.

Variables

char ∗ command_par [MAX_PAR]

Variable tipo char∗ donde se guardarán el comando, y los parámetros pasados al mismo.

unsigned int number_par

Variable tipo int que indica la cantidad de argumentos que se pasan en la cadena de caracteres.

shell_command commands [ ]

Variable tipo shell_command donde están listados todos los comandos disponibles. El arreglo debe terminar en{0,0,0}.


4.9 Referencia del Archivo shell.c 29

cell_phone users [ ]

Variable tipo cell_phone para almacenar los números de teléfono de los usuarios habilitados a interactuar con elsistema. El arreglo debe terminar en {"0"}.


Intérprete de comandos. Recibe una cadena de carecteres que especifica un comando. El comando está especi-ficado por el nombre y además permite recibir parámetros separados por espacios. Al recibir un string lo procesapara obtener los parámetros y el nombre de comando. Luego llama a la función correspondiente.

Autor


Fecha

Junio 2012

Definición en el archivo shell.c.

4.9.2. Documentacion de los ’defines’

4.9.2.1. #define MAX PAR 4

Constante que define la máxima cantidad posible de parámetros esperados para un comando.

Definición de constantes privadas MAX_PAR 4

Definición en la línea 41 del archivo shell.c.


4.9.3.1. void shell exec ( char ∗ str )

Función que procesa el string recibido para obtener el comando y sus parámetros. Luego, busca y ejecuta elcomando pasado. De no encontrarse el comando devuelve un mensaje de error.

Parametrosstr Cadena con el comando a buscar.



4.9.4.1. command par[MAX_PAR]

Variable tipo char∗ donde se guardarán el comando, y los parámetros pasados al mismo.

Declaración de variables privadas




4.9.4.2. commands[ ]


Definición en la línea 55 del archivo shell_commands.c.

4.9.4.3. number par

Variable tipo int que indica la cantidad de argumentos que se pasan en la cadena de caracteres.


4.9.4.4. users[MAX_USERS]



4.10. Referencia del Archivo shell.h

Define la interfaz pública del módulo shell.

Funciones

void shell_exec (char ∗str)

Función que procesa el string recibido para obtener el comando y sus parámetros. Luego, busca y ejecuta el comandopasado. De no encontrarse el comando devuelve un mensaje de error.


Define la interfaz pública del módulo shell.

Autor


Fecha

Junio 2012

Definición en el archivo shell.h.


4.10.2.1. void shell exec ( char ∗ str )

Función que procesa el string recibido para obtener el comando y sus parámetros. Luego, busca y ejecuta elcomando pasado. De no encontrarse el comando devuelve un mensaje de error.

Parametrosstr Cadena con el comando a buscar.


4.11 Referencia del Archivo shell_commands.c 31


4.11. Referencia del Archivo shell commands.c

Módulo donde se definen los comandos y la lista de los mismos con el puntero que apunta a la función y sudescripción. En este módulo también se definen la lista de usuarios que tienen permitido modificar la configuraciónde la alarma.

#include <string.h>#include "aux_functions.h"#include "shell_commands.h"#include "gsm.h"#include "timer.h"#include "car-app.h"#include "shell.h"

’defines’

#define MAX_USERS 6

Constante que define la máxima cantidad de usuarios permitidos a interactuar con el sistema.

Funciones

void activate (unsigned int argc, char ∗∗argv)

Función que habilita el envío de notificaciones vía SMS. Envía al usuario un SMS de confirmación.

void deactivate (unsigned int argc, char ∗∗argv)

Función que inhabilita el envío de notificaciones vía SMS. Envía al usuario un SMS de confirmación.

void send1 (unsigned int argc, char ∗∗argv)

Función que envía una notificación vía SMS al celular configurado como primario.


Función que envía una notificación vía SMS al celular configurado como secundario.

void setTime (unsigned int argc, char ∗∗argv)

Función que modifica la ventana de tiempo entre las notificaciones. Se espera el parámetro esté dado en minutos. Seconsidera además que los tiempos entre notificaciones son los mismos tanto para avisos entre 1er SMS y llamada,como entre llamada y 2º SMS.

void location (unsigned int argc, char ∗∗argv)

Función NO IMPLEMENTADA AÚN que determina y notifica al usuario la ubicación actual según indique el GPS.

void credit (unsigned int argc, char ∗∗argv)

Función NO IMPLEMENTADA que averigua con el proveedor de servicios cual es el saldo restante en el chip usadoy se lo notifica al usuario vía SMS.

void help (unsigned int argc, char ∗∗argv)

Función que devuelve en un SMS la lista con todos los comandos disponibles al momento. También, si se le pasa uncomando como parámetro, devuelve la descripción del mismo o error si no existe.

void showConfig (unsigned int argc, char ∗∗argv)

Función que envía un SMS con los parámetros de configuración actual. Esto es: estado de notificaciones, celularesprimario y secundario, y tiempo entre notificaciones.

void addUser (unsigned int argc, char ∗∗argv)

Función que agrega el usuario pasado como parámetro a la lista de usuarios habilitados a interactuar con el sistema.

void deleteUser (unsigned int argc, char ∗∗argv)

Función que elimina el usuario pasado como parámetro de la lista de usuarios habilitados a interactuar con el sistema.

void showUser (unsigned int argc, char ∗∗argv)

Función que envía un SMS con el listado de usuarios habilitados a interactuar con el sistema.



Variables

char alarm_reply [250]

Variable tipo arreglo de caracteres usada para guardar el mensaje a enviar al usuario vía SMS.

shell_command commands [ ]


cell_phone users [MAX_USERS]



Módulo donde se definen los comandos y la lista de los mismos con el puntero que apunta a la función y sudescripción. En este módulo también se definen la lista de usuarios que tienen permitido modificar la configuraciónde la alarma.

Autor


Fecha

Junio 2012

Definición en el archivo shell_commands.c.


4.11.2.1. #define MAX USERS 6

Constante que define la máxima cantidad de usuarios permitidos a interactuar con el sistema.

Definición de constantes privadas MAX_USERS 6



4.11.3.1. void activate ( unsigned int argc, char ∗∗ argv )


Parametrosargc Cantidad de parámetros.argv Parámetros del comando.


4.11.3.2. addUser ( unsigned int argc, char ∗∗ argv )

Función que agrega el usuario pasado como parámetro a la lista de usuarios habilitados a interactuar con elsistema.





4.11.3.3. credit ( unsigned int argc, char ∗∗ argv )




4.11.3.4. void deactivate ( unsigned int argc, char ∗∗ argv )




4.11.3.5. deleteUser ( unsigned int argc, char ∗∗ argv )

Función que elimina el usuario pasado como parámetro de la lista de usuarios habilitados a interactuar con elsistema.



4.11.3.6. help ( unsigned int argc, char ∗∗ argv )

Función que devuelve en un SMS la lista con todos los comandos disponibles al momento. También, si se le pasaun comando como parámetro, devuelve la descripción del mismo o error si no existe.





4.11.3.7. location ( unsigned int argc, char ∗∗ argv )




4.11.3.8. send1 ( unsigned int argc, char ∗∗ argv )




4.11.3.9. send2 ( unsigned int argc, char ∗∗ argv )




4.11.3.10. setTime ( unsigned int argc, char ∗∗ argv )

Función que modifica la ventana de tiempo entre las notificaciones. Se espera el parámetro esté dado en minutos.Se considera además que los tiempos entre notificaciones son los mismos tanto para avisos entre 1er SMS yllamada, como entre llamada y 2º SMS.



4.11.3.11. showConfig ( unsigned int argc, char ∗∗ argv )






4.11.3.12. showUser ( unsigned int argc, char ∗∗ argv )





4.11.4.1. alarm reply[250]

Variable tipo arreglo de caracteres usada para guardar el mensaje a enviar al usuario vía SMS.


4.11.4.2. shell_command commands[ ]

Valor inicial:

{{"ACTIVAR","Activa notificaciones.", activate},{"DESACTIVAR","Desactiva notificaciones.",deactivate},{"ENVIAR1","Configura celular prioritario.",send1},{"ENVIAR2","Configura celular secundario.",send2},{"TIEMPO","Configura tiempo, en minutos, entre notificaciones.",setTime},{"UBICACION","Consulta coordenadas actuales del automovil.",location},{"SALDO","Consulta saldo.",credit},{"AYUDA","Imprime una lista con todos los comandos disponibles.",help},

{"CONFIGURACION", "Muestra configuracion actual.", showConfig},

{"AGREGAR", "Agrega el numero de celular a la lista de usuarioshabilitados", addUser},{"ELIMINAR", "Elimina el numero de celular de la lista de usuarios

habilitados", deleteUser},{"USUARIOS", "Muestra todos los usuarios habilitados a configurar el

sistema", showUser},

{0,0,0}}



4.11.4.3. cell_phone users[MAX_USERS]

Valor inicial:

{{"+59899939633"},

{"0"}}





4.12. Referencia del Archivo shell commands.h

Define la interfaz pública del módulo shell_commands. Se definen estructuras para listar los comandos y los usua-rios.

Estructuras de datos

struct shell_command

struct cell_phone

Funciones

void activate (unsigned int argc, char ∗∗argv)


void deactivate (unsigned int argc, char ∗∗argv)






void location (unsigned int argc, char ∗∗argv)


void credit (unsigned int argc, char ∗∗argv)


void setTime (unsigned int argc, char ∗∗argv)

Función que modifica la ventana de tiempo entre las notificaciones. Se espera el parámetro esté dado en minutos. Seconsidera además que los tiempos entre notificaciones son los mismos tanto para avisos entre 1er SMS y llamada,como entre llamada y 2º SMS.

void help (unsigned int argc, char ∗∗argv)

Función que devuelve en un SMS la lista con todos los comandos disponibles al momento. También, si se le pasa uncomando como parámetro, devuelve la descripción del mismo o error si no existe.

void showConfig (unsigned int argc, char ∗∗argv)


void addUser (unsigned int argc, char ∗∗argv)

Función que agrega el usuario pasado como parámetro a la lista de usuarios habilitados a interactuar con el sistema.

void deleteUser (unsigned int argc, char ∗∗argv)

Función que elimina el usuario pasado como parámetro de la lista de usuarios habilitados a interactuar con el sistema.

void showUser (unsigned int argc, char ∗∗argv)



4.12 Referencia del Archivo shell_commands.h 37


Define la interfaz pública del módulo shell_commands. Se definen estructuras para listar los comandos y los usua-rios.

Autor


Fecha

Junio 2012

Definición en el archivo shell_commands.h.


4.12.2.1. void activate ( unsigned int argc, char ∗∗ argv )




4.12.2.2. void addUser ( unsigned int argc, char ∗∗ argv )

Función que agrega el usuario pasado como parámetro a la lista de usuarios habilitados a interactuar con elsistema.



4.12.2.3. void credit ( unsigned int argc, char ∗∗ argv )




4.12.2.4. void deactivate ( unsigned int argc, char ∗∗ argv )






4.12.2.5. void deleteUser ( unsigned int argc, char ∗∗ argv )

Función que elimina el usuario pasado como parámetro de la lista de usuarios habilitados a interactuar con elsistema.



4.12.2.6. void help ( unsigned int argc, char ∗∗ argv )

Función que devuelve en un SMS la lista con todos los comandos disponibles al momento. También, si se le pasaun comando como parámetro, devuelve la descripción del mismo o error si no existe.



4.12.2.7. void location ( unsigned int argc, char ∗∗ argv )




4.12.2.8. void send1 ( unsigned int argc, char ∗∗ argv )





4.13 Referencia del Archivo timer.c 39

4.12.2.9. void send2 ( unsigned int argc, char ∗∗ argv )




4.12.2.10. void setTime ( unsigned int argc, char ∗∗ argv )

Función que modifica la ventana de tiempo entre las notificaciones. Se espera el parámetro esté dado en minutos.Se considera además que los tiempos entre notificaciones son los mismos tanto para avisos entre 1er SMS yllamada, como entre llamada y 2º SMS.



4.12.2.11. void showConfig ( unsigned int argc, char ∗∗ argv )




4.12.2.12. void showUser ( unsigned int argc, char ∗∗ argv )




4.13. Referencia del Archivo timer.c

Módulo encargado del control de tiempos del sistema. El mismo se usa tanto para medir el tiempo entre las distintasnotificaciones, como también para implementar los time out en caso de que el sistema tenga algún problemaimprevisto.



#include "timer.h"#include <stdlib.h>#include <io430x22x4.h>#include "car-app.h"#include "uart.h"

’defines’

#define MINUTE_TO_SECOND 60

Funciones

void control_counter ()

Funcion que lleva la cuenta, en segundos, del tienpo transcurrido entre notificaciones. Cuando llega al númeroseteado llama a la función alarm_control.

void control_timeout ()

Funcion que implementa el timeout del envío de mensajes.

void set_control_time (char ∗time)

Función pública que setea el intervalo entre notificaciones.

int get_control_time ()

Función pública que devuelve el intervalo configurado entre notificaciones.

void init_control_timer ()

Función que reinicia el timer usado para control (timer A) y habilita sus interrupciones.

void conf_control_timer ()

Función que configura el timer usado para control (timer A). Se setean entre otras cosas la fuente de reloj a usar, lafrecuencia de interrupción, y el modo. Además, se deshabilitan sus interrupciones.

void conf_timeout ()

Función que configura el timer usado para controlar los time out (timer B). Se setean entre otras cosas la frecuenciade interrupción, y el modo. Además, se deshabilitan sus interrupciones.

void init_timeout ()

Función que reinicia el timer usado para controlar los time out (timer B) y habilita sus interrupciones.

__interrupt void Timer_A (void)

ISR del Timer de control (TA): reinicia el contador y llama a la función que hace su control.

__interrupt void Timer_B (void)

ISR del Timer que controla los time out (TB): reinicia el contador y llama a la función que hace su control.

Variables

int alarm_control_state



Módulo encargado del control de tiempos del sistema. El mismo se usa tanto para medir el tiempo entre las distintasnotificaciones, como también para implementar los time out en caso de que el sistema tenga algún problemaimprevisto.

Autor



4.13 Referencia del Archivo timer.c 41

Fecha

Junio 2012

Definición en el archivo timer.c.


4.13.2.1. #define MINUTE TO SECOND 60

Definición en la línea 33 del archivo timer.c.


4.13.3.1. void conf control timer ( )

Función que configura el timer usado para control (timer A). Se setean entre otras cosas la fuente de reloj a usar,la frecuencia de interrupción, y el modo. Además, se deshabilitan sus interrupciones.


4.13.3.2. void conf timeout ( )



4.13.3.3. void control counter ( )

Funcion que lleva la cuenta, en segundos, del tienpo transcurrido entre notificaciones. Cuando llega al númeroseteado llama a la función alarm_control.


4.13.3.4. void control timeout ( )

Funcion que implementa el timeout del envío de mensajes.


4.13.3.5. int get control time ( )


Devuelve

Devuelve el tiempo especificado en minutos.


4.13.3.6. void init control timer ( )





4.13.3.7. void init timeout ( )



4.13.3.8. void set control time ( char ∗ time )


Parametrostime Cadena que especifica el intervalo a setear. El tiempo se tomará como expresado en minutos.


4.13.3.9. interrupt void Timer A ( void )

ISR del Timer de control (TA): reinicia el contador y llama a la función que hace su control.


4.13.3.10. interrupt void Timer B ( void )

ISR del Timer que controla los time out (TB): reinicia el contador y llama a la función que hace su control.



4.13.4.1. int alarm control state



4.14. Referencia del Archivo timer.h

Define la interfaz pública del módulo timer.

Funciones

void set_control_time (char ∗time)


int get_control_time ()


void init_control_timer ()


void conf_control_timer ()

Función que configura el timer usado para control (timer A). Se setean entre otras cosas la fuente de reloj a usar, lafrecuencia de interrupción, y el modo. Además, se deshabilitan sus interrupciones.

void conf_timeout ()



4.14 Referencia del Archivo timer.h 43

void init_timeout ()



Define la interfaz pública del módulo timer.

Autor


Fecha

Junio 2012

Definición en el archivo timer.h.


4.14.2.1. void conf control timer ( )

Función que configura el timer usado para control (timer A). Se setean entre otras cosas la fuente de reloj a usar,la frecuencia de interrupción, y el modo. Además, se deshabilitan sus interrupciones.


4.14.2.2. void conf timeout ( )



4.14.2.3. int get control time ( )


Devuelve

Devuelve el tiempo especificado en minutos.


4.14.2.4. void init control timer ( )



4.14.2.5. void init timeout ( )





4.14.2.6. void set control time ( char ∗ time )


Parametrostime Cadena que especifica el intervalo a setear. El tiempo se tomará como expresado en minutos.


4.15. Referencia del Archivo uart.c

Módulo encargado de transmitir y recibir los datos. Es la capa física del sistema que permite la interacción entre elmódulo gsm y el microcontrolador. Incluye funciones para poder elegir el caracter deseado, y la cantidad de vecesque tiene que aparecer, para considerar el mensaje como completo. Además, tiene funciones que se encargan detoda la inicialización, así también como del envío de datos.

#include <stdio.h>#include <string.h>#include "uart.h"

’defines’

#define P3TXD0 4

#define P3RXD0 5

Funciones

void initUART ()

Función que configura la UART para una comunicación 9600, 8, N, 1.

void init_UART ()

Función que configura la UART e inicializa las banderas e índices relacionadas con el envío y la recepción demensajes a través de la UART.

void set_eofl (char end_of_line)

Función que especifica cual será el caracter a considerar como fin de trama.

void set_number_eofl (int number_end_of_line)

Función que configura la cantidad de caracteres de fin de trama para considerar que el mensaje está completo.

__interrupt void ISR_Rx ()

ISR de RX: copia al buffer de RX el caracter recibido y setea bandera en caso de detectar el final de la trama.

__interrupt void ISR_Tx ()

ISR de TX: envia siguiente caracter del buffer de TX. Si es el último deshabilita interrupciones y resetea indice.

void cargarTXbuffer (char ∗string1)

Función que carga en el buffer de transmisión el string a enviar. Envía el primer caracter a enviar y habilita lasinterrupciones de transmisión.

int get_flagRX ()

Función que indica si se ha recibido una cadena por la UART.

void reset_flagRX ()

Función que baja la bandera de recepción de la UART.


4.15 Referencia del Archivo uart.c 45

Variables

buffer RXbuffer



Módulo encargado de transmitir y recibir los datos. Es la capa física del sistema que permite la interacción entre elmódulo gsm y el microcontrolador. Incluye funciones para poder elegir el caracter deseado, y la cantidad de vecesque tiene que aparecer, para considerar el mensaje como completo. Además, tiene funciones que se encargan detoda la inicialización, así también como del envío de datos.

Autor


Fecha

Junio 2012

Definición en el archivo uart.c.


4.15.2.1. #define P3RXD0 5

Constante que define el puerto de entrada.


4.15.2.2. #define P3TXD0 4

Constante que define el puerto de salida.



4.15.3.1. void cargarTXbuffer ( char ∗ string1 )


Parametrosstring1 Cadena con el texto a enviar.

string1,: cadena con el string a enviar.


4.15.3.2. int get flagRX ( )




Devuelve

Retorna el valor de la bandera de recepción.


4.15.3.3. void init UART ( )



4.15.3.4. void initUART ( )

Función que configura la UART para una comunicación 9600, 8, N, 1.


4.15.3.5. interrupt void ISR Rx ( )

ISR de RX: copia al buffer de RX el caracter recibido y setea bandera en caso de detectar el final de la trama.


4.15.3.6. interrupt void ISR Tx ( )

ISR de TX: envia siguiente caracter del buffer de TX. Si es el último deshabilita interrupciones y resetea indice.


4.15.3.7. void reset flagRX ( )


Devuelve



4.15.3.8. void set eofl ( char end of line )


Parametrosend_of_line Final de la trama.

end_of_line,: caracter que indicará el caracter de final de la trama.


4.15.3.9. void set number eofl ( int number end of line )



4.16 Referencia del Archivo uart.h 47

Parametrosnumber_enf_of-

_lineCantidad de fin de trama.

number_enf_of-_line,:

Entero que setea la cantidad de finales de trama a esperar para considerar que el mensajeestá completo.



4.15.4.1. buffer RXbuffer



4.16. Referencia del Archivo uart.h

Define la interfaz pública del módulo uart.

#include <io430.h>

Estructuras de datos

struct buffer

’defines’

#define TAM 128

Funciones

void cargarTXbuffer (char ∗string1)


void init_UART ()


void set_eofl (char end_of_line)


void set_number_eofl (int number_end_of_line)


void reset_flagRX ()


int get_flagRX ()





Define la interfaz pública del módulo uart.

Autor


Fecha

Junio 2012

Definición en el archivo uart.h.


4.16.2.1. #define TAM 128

Constante que define el tamaño de los buffers, tanto de recepción como de transmisión.



4.16.3.1. void cargarTXbuffer ( char ∗ string1 )


Parametrosstring1 Cadena con el texto a enviar.

string1,: cadena con el string a enviar.


4.16.3.2. int get flagRX ( )


Devuelve



4.16.3.3. void init UART ( )



4.16.3.4. void reset flagRX ( )



4.16 Referencia del Archivo uart.h 49

Devuelve



4.16.3.5. void set eofl ( char end of line )


Parametrosend_of_line Final de la trama.

end_of_line,: caracter que indicará el caracter de final de la trama.


4.16.3.6. void set number eofl ( int number end of line )


Parametrosnumber_enf_of-

_lineCantidad de fin de trama.

number_enf_of-_line,:

Entero que setea la cantidad de finales de trama a esperar para considerar que el mensajeestá completo.



Indice alfabetico

ATEOgsm.c, 22

activateshell_commands.c, 32shell_commands.h, 37

activate_alarmcar-app.c, 12car-app.h, 16

addUsershell_commands.c, 32shell_commands.h, 37

alarm_controlcontrol_alarma.c, 19control_alarma.h, 20

alarm_control_statecontrol_alarma.c, 20timer.c, 42

alarm_replyshell_commands.c, 35

alarm_statecontrol_alarma.c, 19

aux_functions.c, 9itoa, 9stricmp, 10

aux_functions.h, 10itoa, 11stricmp, 11

buffer, 5datos, 5indice, 5

CLIPgsm.c, 23

CMGFgsm.c, 22

CNMIgsm.c, 23

callgsm.c, 23gsm.h, 26

call_stategsm.c, 25

car-app.c, 11activate_alarm, 12deactivate_alarm, 12get_calling, 13get_flagConfigurando, 13get_sendingFlag, 13get_status_flag, 13

init_conf, 13main, 13reset_calling, 13reset_flagConfigurando, 14reset_sendingFlag, 14set_calling, 14set_continue_calling, 14set_continue_config, 14set_continue_sending, 14set_control_flag, 14set_flagConfigurando, 14set_sendingFlag, 14

car-app.h, 15activate_alarm, 16deactivate_alarm, 16get_calling, 16get_flagConfigurando, 16get_sendingFlag, 16get_status_flag, 16init_conf, 17reset_calling, 17reset_flagConfigurando, 17reset_sendingFlag, 17set_calling, 17set_continue_calling, 17set_continue_config, 17set_continue_sending, 17set_control_flag, 17set_flagConfigurando, 18set_sendingFlag, 18

cargarTXbufferuart.c, 45uart.h, 48

cell_phone, 5number, 6

command_parshell.c, 29

commandsshell.c, 29shell_commands.c, 35

conf_alarm_controlcontrol_alarma.c, 19control_alarma.h, 20

conf_control_timertimer.c, 41timer.h, 43

conf_stategsm.c, 22

conf_timeout

ÍNDICE ALFABÉTICO 51

timer.c, 41timer.h, 43

config_modemgsm.c, 23gsm.h, 26

continue_sending_smsgsm.c, 23gsm.h, 27

control_alarma.cENVIAR1, 19ENVIAR2, 19LLAMAR1, 19

control_alarma.c, 18alarm_control, 19alarm_control_state, 20alarm_state, 19conf_alarm_control, 19Port_1, 19

control_alarma.h, 20alarm_control, 20conf_alarm_control, 20

control_countertimer.c, 41

control_timeouttimer.c, 41

creditshell_commands.c, 33shell_commands.h, 37

DO_CALLgsm.c, 23

datosbuffer, 5

deactivateshell_commands.c, 33shell_commands.h, 37

deactivate_alarmcar-app.c, 12car-app.h, 16

deleteUsershell_commands.c, 33shell_commands.h, 38

descripcionshell_command, 6

END_Cgsm.c, 23

ENVIAR1control_alarma.c, 19

ENVIAR2control_alarma.c, 19

estadogsm.c, 25

estate_config_modemgsm.c, 25

funcionshell_command, 6

get_callingcar-app.c, 13car-app.h, 16

get_control_timetimer.c, 41timer.h, 43

get_first_phonegsm.c, 23gsm.h, 27

get_flagConfigurandocar-app.c, 13car-app.h, 16

get_flagRXuart.c, 45uart.h, 48

get_second_phonegsm.c, 24gsm.h, 27

get_sendingFlagcar-app.c, 13car-app.h, 16

get_status_flagcar-app.c, 13car-app.h, 16

gsm.cATEO, 22CLIP, 23CMGF, 22CNMI, 23DO_CALL, 23END_C, 23SEND_PHONE_NUMBER, 23SEND_TEXT, 23WAIT_ANSWER, 23

gsm.c, 21call, 23call_state, 25conf_state, 22config_modem, 23continue_sending_sms, 23estado, 25estate_config_modem, 25get_first_phone, 23get_second_phone, 24modem_response, 25msj_text, 25RXbuffer, 25recibed_info, 25send_sms, 24set_first_phone, 24set_second_phone, 24sms_state, 23state_call, 23stream_deco, 24text_to_send, 25

gsm.h, 26call, 26config_modem, 26


52 ÍNDICE ALFABÉTICO

continue_sending_sms, 27get_first_phone, 27get_second_phone, 27send_sms, 27set_first_phone, 27set_second_phone, 27stream_deco, 28

helpshell_commands.c, 33shell_commands.h, 38

ISR_Rxuart.c, 46

ISR_Txuart.c, 46

indicebuffer, 5

init_UARTuart.c, 46uart.h, 48

init_confcar-app.c, 13car-app.h, 17

init_control_timertimer.c, 41timer.h, 43

init_timeouttimer.c, 41timer.h, 43

initUARTuart.c, 46

itoaaux_functions.c, 9aux_functions.h, 11

LLAMAR1control_alarma.c, 19

locationshell_commands.c, 33shell_commands.h, 38

MAX_PARshell.c, 29

MAX_USERSshell_commands.c, 32

MINUTE_TO_SECONDtimer.c, 41

maincar-app.c, 13

modem_responsegsm.c, 25

msj_textgsm.c, 25

nombreshell_command, 6

numbercell_phone, 6

number_parshell.c, 30

P3RXD0uart.c, 45

P3TXD0uart.c, 45

Port_1control_alarma.c, 19

RXbuffergsm.c, 25uart.c, 47

recibed_infogsm.c, 25

reset_callingcar-app.c, 13car-app.h, 17

reset_flagConfigurandocar-app.c, 14car-app.h, 17

reset_flagRXuart.c, 46uart.h, 48

reset_sendingFlagcar-app.c, 14car-app.h, 17

SEND_PHONE_NUMBERgsm.c, 23

SEND_TEXTgsm.c, 23

send1shell_commands.c, 34shell_commands.h, 38

send2shell_commands.c, 34shell_commands.h, 38

send_smsgsm.c, 24gsm.h, 27

set_callingcar-app.c, 14car-app.h, 17

set_continue_callingcar-app.c, 14car-app.h, 17

set_continue_configcar-app.c, 14car-app.h, 17

set_continue_sendingcar-app.c, 14car-app.h, 17

set_control_flagcar-app.c, 14car-app.h, 17

set_control_timetimer.c, 42timer.h, 43


ÍNDICE ALFABÉTICO 53

set_eofluart.c, 46uart.h, 49

set_first_phonegsm.c, 24gsm.h, 27

set_flagConfigurandocar-app.c, 14car-app.h, 18

set_number_eofluart.c, 46uart.h, 49

set_second_phonegsm.c, 24gsm.h, 27

set_sendingFlagcar-app.c, 14car-app.h, 18

setTimeshell_commands.c, 34shell_commands.h, 39

shell.c, 28command_par, 29commands, 29MAX_PAR, 29number_par, 30shell_exec, 29users, 30

shell.h, 30shell_exec, 30

shell_command, 6descripcion, 6funcion, 6nombre, 6

shell_commands.c, 31activate, 32addUser, 32alarm_reply, 35commands, 35credit, 33deactivate, 33deleteUser, 33help, 33location, 33MAX_USERS, 32send1, 34send2, 34setTime, 34showConfig, 34showUser, 35users, 35

shell_commands.h, 36activate, 37addUser, 37credit, 37deactivate, 37deleteUser, 38help, 38

location, 38send1, 38send2, 38setTime, 39showConfig, 39showUser, 39

shell_execshell.c, 29shell.h, 30

showConfigshell_commands.c, 34shell_commands.h, 39

showUsershell_commands.c, 35shell_commands.h, 39

sms_stategsm.c, 23

state_callgsm.c, 23

stream_decogsm.c, 24gsm.h, 28

stricmpaux_functions.c, 10aux_functions.h, 11

TAMuart.h, 48

text_to_sendgsm.c, 25

timer.c, 39alarm_control_state, 42conf_control_timer, 41conf_timeout, 41control_counter, 41control_timeout, 41get_control_time, 41init_control_timer, 41init_timeout, 41MINUTE_TO_SECOND, 41set_control_time, 42Timer_A, 42Timer_B, 42

timer.h, 42conf_control_timer, 43conf_timeout, 43get_control_time, 43init_control_timer, 43init_timeout, 43set_control_time, 43

Timer_Atimer.c, 42

Timer_Btimer.c, 42

uart.c, 44cargarTXbuffer, 45get_flagRX, 45ISR_Rx, 46


54 ÍNDICE ALFABÉTICO

ISR_Tx, 46init_UART, 46initUART, 46P3RXD0, 45P3TXD0, 45RXbuffer, 47reset_flagRX, 46set_eofl, 46set_number_eofl, 46

uart.h, 47cargarTXbuffer, 48get_flagRX, 48init_UART, 48reset_flagRX, 48set_eofl, 49set_number_eofl, 49TAM, 48

usersshell.c, 30shell_commands.c, 35

WAIT_ANSWERgsm.c, 23


Car App - eva.fing.edu.uy · Car App Sistemas Embebidos para Tiempo Real 2012 RESUMEN Esto proyecto...

Documents

Transcript of Car App - eva.fing.edu.uy · Car App Sistemas Embebidos para Tiempo Real 2012 RESUMEN Esto proyecto...