Embed Size (px)
Citation preview
DOMÓTICA Proyecto Final – Sistemas embebidos para tiempo real
TUTORES
Conrado Rossi
Javier Schandy
INTEGRANTES
Nicolás Barreto
Richard Rodríguez Rodrigo
Barboza
Tabla de Contenidos
RESUMEN ...................................................................................................................................... 1
INTRODUCCION ............................................................................................................................. 2
Descripción del problema ......................................................................................................... 2
Antecedentes ............................................................................................................................ 2
OBJETIVOS ..................................................................................................................................... 3
ALCANCE ........................................................................................................................................ 3
MODELO FUNCIONAL .................................................................................................................... 4
Panel Central ............................................................................................................................. 4
Paneles Remotos ....................................................................................................................... 5
DISEÑO .......................................................................................................................................... 6
Hardware ................................................................................................................................... 6
Arquitectura de Software .......................................................................................................... 7
IMPLEMENTACION ........................................................................................................................ 8
Modularización .......................................................................................................................... 8
Estructuras .............................................................................................................................. 10
Fecha ................................................................................................................................... 10
Dispositivos ......................................................................................................................... 11
Dispositivos Locales ............................................................................................................. 12
Tareas .................................................................................................................................. 13
Comandos ................................................................................................................................ 14
Comunicación con los paneles remotos .................................................................................. 15
Procesamiento de Tareas ........................................................................................................ 16
TESTING ....................................................................................................................................... 18
CONCLUCIONES ........................................................................................................................... 20
REFERENCIAS ............................................................................................................................... 21
ANEXOS ....................................................................................................................................... 22
Conceptos del curso aplicados al proyecto ............................................................................. 22
Planificación del proyecto ....................................................................................................... 23
Especificación del proyecto ..................................................................................................... 24
1
RESUMEN
Se construyó un panel de control central de domótica, utilizando un LaunchPad
MSP430G2553. Simulamos, utilizando el módulo UART y el RealTerm, tanto la comunicación
entre el usuario y el panel central, como la del panel central y posibles paneles secundarios. El
usuario puede controlar dispositivos locales y remotos (manejados por paneles secundarios)
agregando tareas de apagado y prendido con distintas opciones de configuración (tarea única,
de Lunes a viernes, Sábado y Domingo, entre otras). El panel de control contiene una tabla de
tareas de todos los dispositivos del sistema (remotos y locales), la cual es recorrida una vez por
minuto, para luego ejecutar la tarea si el dispositivo es local ,o en caso de ser remoto, enviar
un paquete a través de la UART. También contiene tres tablas mas, una tabla con todos los
puertos lógicos del sistema (esta contiene todos los dispositivos del sistema), otra con los
puertos locales correspondientes a dispositivos locales y una última tabla guardada en ROM
que contiene las direcciones de los puertos locales.
.
2
INTRODUCCION
La domótica es un conjunto de técnicas orientadas a la automatización de los
electrodomésticos del hogar. También apunta a controlar otros elementos que no son
necesariamente eléctricos, como puertas, ventanas y persianas, mediante la implementación
de motores.
Nuestro proyecto consiste en la construcción de un prototipo de panel de control principal
para automatizar funciones de prendido y apagado de estos electrodomésticos. Para ello
utilizaremos el Launchpad MSP430G2553 el cual posee dos puertos de 8 bits, que da la
capacidad de controlar 16 dispositivos. Este panel contendrá una lista de todos los dispositivos
del sistema y llevará el registro de las tareas que se le vayan agregando al mismo. También
podrá enviar datos a paneles remotos, ya sea para agregar o borrar dispositivos, o para
ejecutar una función en uno de ellos.
Descripción del problema
Hoy en día los dispositivos digitales están acaparando la mayor parte del mercado, y por esta
razón los nuevos hogares y/o empresas están apuntando a automatizarse. Es por eso que se
decidió estudiar este problema de automatizar los distintos electrodomésticos y elementos
que se pueden encontrar en una casa común, y poder agregarle algunas funcionalidades
extras.
Antecedentes
La domótica se inicia a comienzos de la década del ’70, cuando aparecieron los primeros
dispositivos de automatización en edificios. Pero fue en la década del ‘80 cuando los sistemas
integrados se utilizaron a nivel comercial, para luego desarrollarse en el aspecto doméstico de
las casas urbanas.
Allí es cuando la domótica consigue integrar dos sistemas (el eléctrico y el electrónico) en pos
de la comunicación integral de los dispositivos del hogar. El desarrollo de la tecnología
informática permite la expansión del sistema, sobre todo en países de vanguardia como
Estados Unidos, Alemania y Japón.
Estas instalaciones regían bajo el sistema X-10, protocolo de comunicaciones que transmite
datos por líneas de baja tensión. Esto hace a la relación costo-beneficio la mejor opción en el
rubro. Sigue siendo la tecnología más utilizada dentro de la domótica.
Nuevos protocolos permiten un desarrollo que en un principio era impensado.
3
Sistemas de desarrollo 2.0 como el ZigBee permiten conformar un protocolo inalámbrico de
comunicación domótica. Al requerir una baja tasa de envío de datos, es en la actualidad uno de
los protocolos más requeridos para las casas inteligentes.
Actualmente existen varias empresas dedicadas a la domótica. Por ejemplo, en Uruguay,
Tecnohaus y Domotec son dos de las más reconocidas. Podemos encontrar muchos artículos al
respecto y algunas soluciones disponibles como por ejemplo aplicaciones con Arduino.
OBJETIVOS
El objetivo del proyecto es estudiar la automatización de acciones de distintos
electrodomésticos y artefactos que se encuentran en el hogar.
Al finalizar el proyecto se entregará un panel de control de domótica, programable vía UART,
compuesto por el Launchpad MSP430. La comunicación con los electrodomésticos será
simulada vía serie por la UART y se podrá realizar desde una terminal como Realterm.
ALCANCE
En un principio nos habíamos planteado el diseño e implementación de una interfaz de usuario
utilizando un Display LCD y un teclado numérico. Luego de estudiar estos periféricos y realizar
un diseño básico de seteo de fecha, nos percatamos de la dificultad que implicaba escalarlo al
proyecto en su totalidad. Por esta razón decidimos utilizar el módulo UART del Launchapad
para simular esta comunicación usuario – panel central en nuestro entorno de desarrollo.
Figura 1 – Display LCD y teclado numérico.
4
MODELO FUNCIONAL
Nuestro modelo consiste en un panel central y varios paneles remotos donde cada uno de los
cuales podrá controlar varios dispositivos como se puede ver en el diagrama de bloques (figura
2).
Figura 2 – Diagrama de bloques del modelo del sistema.
Panel Central
El panel central podrá recibir comandos del usuario para realizar las siguientes acciones:
- Setear fecha y hora
- Prender/Apagar un dispositivo al instante
- Agregar/Eliminar dispositivos
- Listar los dispositivos del sistema
- Agregar/Eliminar tareas
- Listar las tareas del sistema
Existen dos tipos de tareas que el usuario puede programar para un determinado dispositivo
(local o remoto), tareas con fecha y sin fecha. Las tareas con fecha se ejecutan una única vez
en la fecha y hora especificada y luego son automáticamente eliminadas del sistema. Las
tareas sin fecha son aquellas que se ejecutan en determinados periodos de tiempo también
indicados por el usuario. Estos periodos pueden ser: Lunes, Martes, Miércoles, Jueves, Viernes,
Sábado, Domingo, Todos los días, Entre semana, Fines de semana y Única vez. Por ejemplo, si
el usuario agrega una tarea sin fecha para que se prenda un dispositivo los fines de semana a
las 15 hrs, esta tarea se ejecutará únicamente los días Sábados y Domingos.
5
Este panel contendrá una tabla con todas las tareas del sistema, tanto para dispositivos locales
(del panel central) como para los dispositivos de los paneles remotos.
A su vez, almacenará una lista de todos los dispositivos del sistema, distinguiéndolos con un
número único al que llamamos canal lógico. También sabrá en que panel se encuentra cada
dispositivo. Al agregar o eliminar un dispositivo remoto el panel central enviará un paquete de
datos al panel remoto correspondiente, el cual se encargará de procesar la acción.
Cada un minuto el panel central chequea en su lista de tareas en busca de una tarea para
realizar. Si encuentra una, verifica si es una tarea para un dispositivo remoto o local. Si el
dispositivo es local, ejecuta la tarea, de ser remoto, envía un paquete de datos al panel remoto
que controla dicho dispositivo, para que ejecute la función que corresponda.
Cada panel del sistema, incluyendo el central, contiene el registro de sus dispositivos locales
en una tabla, indicando su canal lógico, el puerto y el bit donde se encuentran conectados.
Paneles Remotos
En nuestro modelo los paneles remotos son en gran medida, dependientes del panel central,
ya que no interactúan con el usuario ni guardan información de las tareas programadas para
sus dispositivos. Estos paneles, se encargan de procesar los paquetes de datos que son
enviados desde el panel central, ya sea para agregar o eliminar un dispositivo local, o para
ejecutar una tarea en el dispositivo especificado.
Como se mencionó anteriormente, estos paneles, al igual que el central, contienen una lista de
dispositivos locales, indicando su canal lógico, el puerto y el bit donde se encuentran
conectados.
6
DISEÑO
Nuestro proyecto se basará en la construcción de un panel central, tal como fue descripto en la
sección anterior. La comunicación del usuario con el panel central se realizará mediante la PC
utilizando un módulo UART incorporado en el hardware y el programa RealTerm, en donde el
usuario podrá ingresar los comandos apropiados para utilizar todas las funcionalidades del
sistema. Para lograr esto, utilizamos un módulo de software, proporcionado por nuestros
tutores, el cual nos permite procesar los comandos ingresados por el usuario de una manera
eficiente.
La comunicación, unidireccional, del panel central hacia los paneles remotos, se simulará
imprimiendo en la pantalla del Realterm los paquetes de datos a ser transmitidos.
Hardware
Para este proyecto utilizamos el Launchpad MSP430G2553, ya que cuenta con un módulo
UART (necesario para realizar la recepción y transmisión de datos) y dos puertos de
entrada/salida con 8 pines cada uno (suficientes para nuestros propósitos).
Firgura 3 – Launchpad MSP430G2553
Para el control de dispositivos que requieran más potencia utilizaremos un relé con la conexión
que se muestra en la siguiente figura:
Figura 4 – Esquema de conexión de un dispositivo
mediante un relé.
7
Arquitectura de Software
Decidimos trabajar con una arquitectura de Round Robin para llevar a cabo las tareas a realizar
mediante el chequeo de una serie de banderas. Creemos que esta elección es la que mejor se
adapta a las características de nuestro sistema ya que debemos consultar si hay tareas
pendientes, datos completos recibidos o datos a transmitir, pudiendo usar una bandera para
cada una de estas funciones.
Figura 5 – Arquitectura de Round Robin utilizada en nuestro proyecto.
8
IMPLEMENTACION
Para el desarrollo de este proyecto utilizamos el IDE IAR Embedded Workbench con el
toolchain del MSP430, el cual nos fue útil para debuggear colocando breakpoints en
determinados lugares del código. También nos facilitó el trabajo de compilación, programación
del microcontrolador y revisión del consumo de memoria de manera detallada.
Figura 6 – Imagen del IDE IAR Embedded Workbench
Modularización
El proceso de modularización fue una etapa importante para el desarrollo del proyecto ya que
se realizó en sus inicios y ayudó a la mejor comprensión del mismo y a la división de las tareas
dentro del equipo. Nuestro proyecto cuenta con 8 módulos los cuales describiremos a
continuación:
Módulo de Tareas: Contiene la estructura de las tareas junto con las funciones que tienen
relación directa con el manejo de las mismas. Aquí encontramos las funciones para inicializar la
tabla de tareas, agregar tareas con y sin fecha, eliminarlas, listarlas, chequear si existe alguna
tarea para ejecutar, ejecutarlas y prender y apagar dispositivos de manera instantánea. A
continuación, listamos dichas funciones indicando el tipo de datos que retornan y sus
parámetros:
void InicializarTareas(void);
int16_t ListadoDeTareas(uint16_t argc, int8_t** argv);
int16_t AgregarTarea(uint16_t argc, int8_t** argv);
int16_t AgregarTareaConFecha(uint16_t argc, int8_t** argv);
int16_t EliminarTarea(uint16_t, int8_t** argv);
9
void ChequeoDeTareas(void);
void RealizarTarea(int8_t canal_logico, int8_t funcion);
int16_t PrenderYa(uint16_t argc, int8_t** argv);
int16_t ApagarYa(uint16_t, int8_t** argv);
Módulo de Dispositivos: Contiene la estructura de dispositivos junto con las funciones que
tienen relación directa con el manejo de los mismos. Aquí encontramos las funciones para
inicializar, agregar, eliminar y listar los dispositivos. A continuación, listamos dichas funciones
indicando el tipo de datos que retornan y sus parámetros:
void InicializarDispositivos(void);
int16_t ListarDispositivos(uint16_t argc, int8_t** argv);
int16_t ListarDispositivosLocales(uint16_t argc, int8_t** argv);
int16_t AgregarDispositivo(uint16_t argc, int8_t** argv);
int16_t EliminarDispositivo(uint16_t argc, int8_t** argv);
Módulo de Comunicaciones: Este módulo tiene las funciones diseñadas para el envío de
paquetes de datos desde el panel central hacia los remotos y aquellas para facilitar la
comunicación con el usuario. Como se mencionó en el modelo funcional, se envían paquetes
cuando se agrega o elimina un dispositivo remoto, así como también cuando se tiene que
ejecutar una acción de prendido o apagado en un dispositivo remoto. Tenemos otras funciones
encargadas de la conversión de datos para su posterior trasmisión. A continuación, listamos
dichas funciones indicando el tipo de datos que retornan y sus parámetros:
void transmitir_paquete(uint8_t panel,uint8_t ch_logico,uint8_t funcion);
void transmitir_eliminar_dispositivo(uint8_t ch_logico);
void transmitir_dispositivo(uint8_t panel, uint8_t ch_logico, uint8_t puerto, uint8_t
bit);
int16_t transmitir_fecha(uint16_t argc, int8_t** argv);
char* itoa(int i, char b[]);
char* itoa2(uint16_t i,char mens[]);
int8_t* strQueDiaEs(dia_sem_t dia);
int8_t* strQuePeriodoEs(periodo_t dia);
int8_t* strQueFuncionEs(int8_t funcion);
Módulo de Tiempos: Aquí se encuentra la estructura que creamos para la fecha, la cual tiene
atributos de año, mes, día, hora, minutos, segundos y centi-segundos, así como también el día
de la semana. Contiene funciones para inicializar la fecha en el comienzo del programa, para
cambiarla mediante un comando por parte del usuario, para incrementar un centi-segundo,
función que es llamada desde la ISR del Timer (también contenida en este módulo), el cual
interrumpe cada un centi-segundo.
Módulo UART: Este módulo contiene las ISR de recepción y transmisión de datos, así como
también las funciones encargadas de transmitir y recibir un mensaje completo.
10
Módulo Shell: Este módulo fue proporcionado por los docentes tutores. Su objetivo es
procesar los comandos ingresados por el usuario, mediante el módulo UART, a través del
RealTerm. Con este módulo podemos fácilmente indicar que función se ejecuta al recibir
determinado comando y pasarle los parámetros ingresados por el usuario.
Módulo de Abstracción: Mediante este módulo generamos una capa de abstracción la cual
contiene todas las funciones que manejan registros del MSP430, como la inicialización de los
puertos, las funciones de apagado y prendido de dispositivos locales y la configuración de la
UART y el Timer. De esta manera, si cambiamos de hardware y utilizamos otro
microcontrolador, sólo tendríamos que modificar este módulo y modificar sus registros como
corresponda.
Módulo de Tipos de datos: En este módulo definimos los tipos de datos que van a tener las
variables de nuestro proyecto.
Estructuras
A continuación, presentamos las estructuras principales de nuestro sistema.
Fecha
El diseño de la estructura de la fecha cuenta con atributos que especifican año, mes, día, hora,
minutos, segundos, centi-segundos y día de la semana. Para este último atributo contamos con
una enumeración con los días de la semana para una mejor manipulación de los datos dentro
de nuestro software (ver figura 8). Como se puede ver en la estructura, se optimizó el uso de la
memoria para cada una de sus atributos calculando el máximo valor que podrían tomar y
asignado la cantidad de bits necesarios.
Figura 7 – Enumeración para los días de la semana.
Figura 8 – Estructura para la fecha.
11
Dispositivos
Nuestro sistema cuenta con una estructura de dispositivos el cual tiene atributos que indican
el canal lógico, el panel y si se encuentra activo. El canal lógico es la identificación del
dispositivo en el sistema, este número es único ya que no pueden existir dos dispositivos con
el mismo canal lógico. También se indica el panel donde se encuentra el dispositivo, donde
establecimos por una cuestión de diseño que el número cero corresponde al panel central y el
resto a paneles remotos. El atributo activo funciona como un indicador de existencia, es decir,
si está en cero, significa que el dispositivo no existe, por lo tanto, al agregar uno nuevo, se
puede sobreescribir.
Figura 9 – Estructura de dispositivos.
Para lograr formar una tabla de dispositivos, creamos un arreglo de tipo dispositivo_t. De esta
forma podemos luego listar los dispositivos del sistema recorriendo este arreglo y desplegando
aquellos dispositivos que estén activos. Por una cuestión de diseño, el canal lógico asignado a
cada dispositivo corresponde al índice en donde se encuentran ubicados en el arreglo.
Figura 10 – Tabla de dispositivos
12
Dispositivos Locales
Cada panel contará con una tabla de dispositivos locales, la cual detallará para cada
dispositivo, su número de canal lógico, el puerto y bit desde donde es controlado, y si el mismo
está activo. Esta tabla se forma creando un arreglo de datos con la siguiente estructura:
Figura 11 – Estructura de Dispositivos Locales
Figura 12 – Tabla de Dispositivos Locales
Como se puede ver en la tabla de dispositivos locales (figura 12), el puerto simplemente
contiene un número. Aunque podríamos almacenar directamente la dirección del puerto en
esta tabla, decidimos por una cuestión de ahorro de memoria, tener estas direcciones
guardadas en ROM en un arreglo constante (aprovechando el hecho de que son datos
constantes en el tiempo). Para hacer uso de este arreglo de puertos locales, asociamos el
número de puerto indicado en la tabla de dispositivos locales, con el índice en donde se
encuentra la dirección del puerto en el arreglo de puertos locales (ver figura 13).
Figura 13 – Tabla de puertos
locales.
Tanto la estructura de dispositivos locales (en la cual se calculó para cada atributo los bits
necesarios para contener la información correspondiente) como el manejo de las direcciones
de puertos locales, se diseñaron específicamente para lograr un menor consumo de memoria
RAM.
13
Tareas
Para almacenar todas las tareas del sistema en el panel central, creamos un arreglo de datos
con la estructura tarea_t, la cual se puede ver en la figura 14. Esta estructura tiene atributos
para contener el ID (identificación de la tarea, corresponde al índice del arreglo de tareas en
donde se encuentre), el canal lógico del dispositivo que se quiera controlar, una bandera
tienefecha que nos indica si es una tarea con (1) o sin fecha (0), un bandera de existencia que
indica si esta activa la tarea o si se puede sobrescribir ese lugar en el arreglo, la función (indica
si la tarea prende (1) o apaga (0) el dispositivo, la fecha y/u hora a la cual se ejecuta la tarea
(dependiendo si es una tarea con o sin fecha), y el periodo en el cual se realiza la tarea. Este
último atributo es del tipo periodo_t, el cual es una enumeración que se muestra en la figura
16.
Por ejemplo, si una tarea tiene periodo EntreSemana, sólo se realizará los días Lunes, Martes,
Miércoles, Jueves y Viernes. En caso de tener periodo Once, se ejecutará una sola vez, en la
próxima instancia que encuentre y luego se eliminará automáticamente. Las tareas con fecha,
tienen este periodo ya que sólo se ejecutan una vez al alcanzar la fecha indicada por el usuario.
Figura 14 – Estructura de Tarea
Figura 15 – Tabla de Tareas
Figura 16 – Enumeración para el periodo de la tarea.
14
Comandos
En la descripción del modelo funcional del sistema, se detalló una serie de acciones que el
usuario podía realizar enviando comandos al panel central. Con el fin de introducir de manera
más clara estos comandos, los hemos dividido en tres conjuntos, en función de las estructuras
con las que trabajan.
En primer lugar, el sistema cuenta con dos comandos básicos para setear la fecha, SD (Set
Date), y para desplegarla en pantalla, RD (Return Date). Estos comandos son fundamentales
para realizar pruebas relacionadas con tareas y sus distintas configuraciones de periodos.
Figura 17 – Comandos para setear y desplegar la fecha del sistema.
El usuario puede agregar, eliminar y listar tanto dispositivos locales como remotos. En caso de
agregar un dispositivo, se deberá ingresar como parámetros el panel, el puerto y el bit donde
se encuentra conectado el mismo. Para eliminar un dispositivo simplemente se debe ingresar
el comando junto con su canal lógico. Los comandos para desplegar listados no requieren
parámetros.
Figura 18 – Comandos para agregar, eliminar y listar los dispositivos del sistema.
Por último, presentamos los comandos para apagar (ON) y prender (OFF) dispositivos de
manera instantánea, agregar tareas con y sin fecha, eliminarlas y listarlas. Para prender u
apagar un dispositivo, se debe ingresar el comando ON u OFF, junto con el canal lógico
correspondiente (el mismo se podrá consultar listando los dispositivos). Para agregar una tarea
sin fecha (comando NT – New Task), se debe primero especificar el canal lógico del dispositivo
que se quiere controlar, luego el periodo (ingresando un valor, literal, dentro de la
enumeración periodo_t), la hora (hora y minutos), y la función (ON / OFF). En cuanto a las
tareas con fecha (comando NTD – New Task with Date), las mismas se agregan indicando el
canal lógico, la función y la fecha, no siendo necesario especificar el periodo, dado que, como
ya explicamos, en este tipo de tareas se setea su periodo siempre en Once (única vez) para que
se elimine luego de ser ejecutado.
15
Para eliminar una tarea, se ingresa el comando DT (Delete Task) junto con el ID de la tarea. El
comando LT (List Tasks) no requiere ningún parámetro.
Figura 19 – Comandos para prender y apagar de forma instantánea los dispositivos del sistema
y agregar, eliminar y listar tareas.
Comunicación con los paneles remotos
La comunicación del panel central con los paneles remotos se reduce al envío de paquetes de
datos en 4 situaciones, cuando se agrega un dispositivo remoto, cuando se lo elimina y cuando
se lo enciende o apaga.
Cuando se quiere encender o apagar un dispositivo remoto, se envía dentro del paquete, el
panel en el cual se encuentra el dispositivo, su canal lógico y la función a realizar. A
continuación, se muestra en las figuras 20 y 21, estos paquetes de datos, de manera
entendible para el usuario.
Figura 20 – Paquete de datos enviado al panel remoto para encender dispositivo.
Figura 21 – Paquete de datos enviado al panel remoto para apagar dispositivo.
16
En caso de agregar un dispositivo remoto, el paquete de datos a enviar contiene el panel, el
puerto y el bit donde se encuentra conectado el nuevo dispositivo, y también se envía el canal
lógico que le fue asignado.
Figura 22 – Paquete de datos enviado al panel remoto para agregar un nuevo dispositivo.
Al eliminar un dispositivo remoto, basta con enviar un paquete de datos indicando el panel y el
canal lógico, como se muestra a continuación:
Figura 23 – Paquete de datos enviado al panel remoto para eliminar dispositivo.
Procesamiento de Tareas
En esta sección explicaremos en detalle el proceso que se realiza para ejecutar las tareas
programadas en el sistema.
Cada un minuto se levanta la bandera CheckTasks_flag, que utilizamos en nuestra arquitectura
de Round Robin (ver figura 5), para llamar a la función ChequeoDeTareas, la cual recorre toda
la lista de tareas en busca de aquellas que estén listas para ejecutar. Una vez que encuentra
una tarea para ejecutar llama a la función RealizarTarea, pasándole como parámetros el canal
lógico y la función a realizar (prendido o apagado). Dentro de esta función se controla si es un
dispositivo remoto o uno local. En caso de ser local, se llama a la función PrenderPFL o
ApagarPFL, dependiendo de la acción que se desee realizar, pasándole como parámetro el
canal lógico del dispositivo a controlar. El termino PFL se refiere a Puerto Físico Local. Estas
funciones entran a la tabla de dispositivos locales para chequear en que puerto se encuentra el
dispositivo para luego ir a la tabla de puertos físicos alojada en ROM y obtener la dirección de
memoria del puerto en cuestión. Una vez obtenida esta información están en condiciones de
setear el bit de ese puerto, en 1 si la acción es de encendido o en 0 si es de apagado. En caso
de que el dispositivo sea remoto, se envía un paquete de datos tal como se explicó en la
sección anterior.
17
Figura 24 - Diagrama de flujo del procesamiento de tareas.
Cada un min llamamos a la
función ChequeoDeTareas
Llamamos a la función
RealizarTarea con parámetros
canal lógico y función
¿Encontró tarea
a realizar?
¿El dispositivo
es local?
Envío paquete de datos.
¿Función?
PrenderPFL ApagarPFL
ON OFF
SI
NO
SI
NO
18
TESTING
Para realizar el test del proyecto se utilizaron dos métodos.
Scripts
Programación manual
El primer método (scripts) consiste en que mediante archivos de texto de extensión (.txt), que
tiene cargada previamente una secuencia de comandos, se lo carga en la terminal REALTERM y
este, se lo va enviando línea por línea con un delay configurable por el usuario.
Estos scripts consisten en programar el sistema en casos particulares, tanto en casos más
comunes como sería la acción de PRENDER YA o APAGAR YA como en los menos comunes
como sería realizar una tarea en una fecha determinada a una hora determinada.
Realizar tests de este estilo, facilita identificar la secuencia de acciones que hacen fallar al
sistema. Otro punto a favor de esta metodología es que es mucho más ágil, ya que de otra
manera se debería de escribir en la terminal los comandos uno por uno y si hay un fallo se
debe de comenzar el proceso de programación nuevamente.
SCRIPTS PARA DISPOSITIVOS
ADD DISP DEL DISP DEL ALL DISP
ND 0 1 4 ND 0 1 5 ND 0 2 0 ND 0 2 1 ND 0 2 2 ND 0 2 5 ND 1 2 7
LD LDL
LD LDL
DD 4 DD 6
LD LDL
DD 0 DD 1 DD 2 DD 3 DD 4 DD 5 DD 6
LD LDL LT
Figura 25 – Tabla de scripts para probar agregar y eliminar dispositivos.
SCRIPTS PARA TAREAS
TAREAS CON FECHA TAREAS SIN FECHA
ND 0 2 2 ND 1 2 7 SD 15/6/2016 X 9:59:55 RD NTD 0 15/6/2016 10:00 ON NTD 0 15/6/2016 10:1 OFF LT
SD 15/6/2016 X 10:09:50 RD NT 0 X 10:10 ON NT 0 J 10:10 OFF NT 0 F 00:00 ON LT
Figura 26 – Tabla de scripts para probar agregar tareas con y sin fecha.
19
SCRIPTS PARA TAREAS INSTANTANEAS
TAREAS INSTANTANEAS
ON 0 ON 1 OFF 1 ON 2 OFF 2 ON 3 OFF 3 ON 4
Figura 25 – Tabla de scripts para testear las tareas instantáneas.
El ingreso de comandos de manera manual es un método de gran utilidad en las primeras
etapas de testing ya que nos permite comprobar el funcionamiento básico de las funciones
recientemente creadas. De esta manera también es posible cambiar el rumbo de las pruebas
en función de los resultados obtenidos. Con los scripts esto no es posible dado que ya están
establecidos los comandos a ejecutarse.
Concluimos que ambos tipos de prueba son necesarios para una correcta evaluación del
sistema. A nuestro entender, la programación manual se debe utilizar en los comienzos del
proyecto, dejando los scripts para una etapa final.
20
CONCLUCIONES
Habiendo finalizado el proyecto concluimos que se cumplieron con los objetivos principales
planteados al principio, pudiendo también controlar dispositivos conectados a través de relés y
resistencias, que fue planteado como un objetivo secundario.
Con respecto al HW seleccionado, se puede concluir que no es apto para la realización de un
panel de control con las características descritas en nuestro modelo funcional. Esto se debe
principalmente a la falta de memoria RAM. En principio podríamos decir que serviría como
panel remoto, pero esto es sin tener en cuenta el software necesario para la comunicación
inalámbrica.
Como objetivo secundario se manejo la posibilidad de hacer una interface de usuario mediante
un teclado y un display LCD, esto no fue posible ya que debido a que por su complejidad nos
iba a demandar mucho tiempo, y no aportaba demasiado a los efectos del curso, también nos
limitaba la poca memoria RAM.
Por último, podemos decir que gracias a la capa de abstracción de HW el proyecto es
fácilmente portable a un HW nuevo con mejores prestaciones.
21
REFERENCIAS
Texas Instruments, “User’s Guide” MSP-EXP430G2 LaunchPad™ Development Kit, July
2010–Revised March 2016. [Fecha de consulta Marzo. 2016].
Texas Instruments, “MIXED SIGNAL MICROCONTROLLER” MSP430G2x53
MSP430G2x13, Nov. 2008 [Fecha de consulta Marzo. 2016].
Texas Instruments, “User’s Guide” MSP430x2xx Family datasheet, Nov. 2008 [Fecha de
consulta Marzo. 2016].
Arkiplus, “Historia de la Domótica,” arkiplus.com, 05/10/2013. [Online]. Disponible:
http://www.arkiplus.com/historia-de-la-domotica. [Fecha de acceso Junio. 12, 2016].
22
ANEXOS
Conceptos del curso aplicados al proyecto
Dentro de los conocimientos del curso aplicados al proyecto podemos destacar los aprendido
del lenguaje C, el manejo del debugger del IAR Embedded Workbench y manejo de hojas de
datos del HW.
Con ayuda de las hojas de datos y lo aprendido en las instancias de laboratorios, pudimos
configurar periféricos e interfaces I/O, como por ejemplo el TIMER A y la UART, y adaptarlos a
nuestro proyecto.
A continuación mostramos las configuraciones del TIMER A y la UART respectivamente.
Configuración del TIMER A:
Configuración de la UART:
23
En cuanto a la arquitectura de software, después de haber analizado las cuatro arquitecturas
aprendidas en el curso (Round-Robin, Round-Robin con interrupciones, encolado de funciones
y RTOS), decidimos utilizar Round-Robin con interrupciones por ser una arquitectura sencilla y
lo suficientemente robusta para los requerimientos de nuestro proyecto.
Planificación del proyecto
Respecto a la planificación podemos decir, que si bien hubo cambios en el proyecto y las horas
dedicadas fueron mayores a las estimadas, nos pudimos adaptar bien al cronograma planteado
en la especificación inicial del proyecto.
Esta diferencia se dio principalmente por dos razones. En primer lugar, por la escasez de
memoria RAM en el Hardware seleccionado. Esto nos forzó a optimizar todos nuestros
módulos (en especial el módulo Shell) y las estructuras del sistema (fecha, tareas y
dispositivos).
La otra razón que nos llevó a aumentar las horas dedicadas, fue la detección de un problema
con la tierra del LaunchPad. En determinadas circunstancias el TIMER no interrumpía por
razones que aún no comprendemos. Esto se solucionó trabajando con una Laptop alimentada
únicamente con batería.
Uno de los cambios importantes en el diseño del proyecto fue la decisión de utilizar el panel
central como un banco de memoria donde se guardan todas las tareas del sistema, en vez de
que cada panel contenga las tareas correspondientes a sus dispositivos. Esta decisión se tomó
para alivianar la carga de trabajo en lo que respecta a la transmisión de paquetes de datos, ya
que esta comunicación podría requerir la utilización de un buffer más grande para nuestras
transmisiones lo que se traduce en más consumo de RAM. De esta manera los paneles
secundarios sólo reciben paquetes de datos para agregar, eliminar, prender o apagar
dispositivos, y no para agregar y eliminar tareas.
24
Especificación del proyecto
A continuación, se presenta la segunda entrega de la especificación del proyecto, la cual
contiene una versión más detallada del mismo.
Domótica
Sistemas embebidos para tiempo Real
Integrantes
Nicolás Barreto Richard Rodríguez
Rodrigo Barboza
Tutores
Javier Schandy Conrado Rossi
Descripción del problema a ser resuelto
Hoy en día los dispositivos digitales están acaparando la mayor parte del mercado, y por esta
razón los nuevos hogares y/o empresas están apuntando a automatizarse. Es por eso que se
decidió estudiar este problema de automatizar los distintos electrodomésticos que se pueden
encontrar en una casa común, y poder agregarle algunas funcionalidades extras.
En fin, proyecto consiste en la construcción de un panel de control principal para automatizar
distintas funciones de los electrodomésticos, como por ejemplo calefón, aire acondicionado,
luces, puertas, entre otras. De esta manera se puede consultar el estado del dispositivo y/o
enviarle instrucciones para realizar tareas.
Antecedentes
Actualmente existen varias empresas dedicadas a la domótica. Por ejemplo, en Uruguay,
tecnohaus y domotec son dos de las más reconocidas. Podemos encontrar muchos artículos al
respecto y algunas soluciones disponibles como por ejemplo aplicaciones con arduino.
Objetivos del proyecto
El objetivo del proyecto es estudiar la automatización de acciones de distintos
electrodomésticos y artefactos que se encuentran en una habitación.
Al finalizar el proyecto se entregará un panel de control de domótica para una habitación,
programable vía UART compuesto por el Launchpad MSP430. La comunicación con los
electrodomésticos será simulada vía serie por la UART y se podrá realizar desde una terminal
como Realterm.
Alcance del proyecto
Como se mencionó anteriormente, el proyecto incluirá la realización de un módulo de control de
domótica, compuesto por un módulo de comunicación serial UART, para establecer
comunicación con dispositivos remotos, un módulo de manejo de tiempos, dos puertos de
entrada salida para manejo de electrodomésticos locales, y un módulo de configuración.
El proyecto NO incluirá la implementación de la comunicación inalámbrica con los dispositivos
remotos, mientras que en su lugar se simulará utilizando la UART. Tampoco se utilizará una
interfaz de usuario amigable, sino que el dispositivo se configurará mediante un Shell.
Se estudiará la posibilidad, según la disponibilidad de tiempo de usar un banco de relés para
controlar dispositivos que requieran más potencia y de esta forma simular el comportamiento
de lo que sería un electrodoméstico.
Descripción del sistema
Descripción funcional
El sistema consiste en un panel principal central y varios paneles remotos donde cada uno de
los cuales podrá controlar varios dispositivos como se puede ver en el diagrama de bloques. El
panel principal se encargará de enviar paquetes a los paneles remotos vía UART donde estos
lo procesarán y realizarán acciones pertinentes. En el caso que los dispositivos estén
conectados directamente al panel de control principal, este usará puertos de entrada/salida
para enviarle la acción a realizar a cada dispositivo.
Cada panel dispondrá de una tabla de configuración donde se guardarán los estados de los
dispositivos controlados por ese panel, configuración de puertos y electrodomésticos
disponibles, fecha y hora actual, y programaciones de funciones automatización.
El panel de control podrá recibir datos a través de la UART los cuales permitirán setear
funciones de apagado, prendido, prendido y apagado por franjas horarias, setear hora y fecha,
configuración de puertos. Y también consultar el estado del dispositivo, guardado en la tabla de
configuración. Las opciones de configuración se podrán setear mediante un Shell como
Realterm.
El sistema consta de varios puertos de 8 bits de los cuales se utilizará cada bit para controlar
un dispositivo (mediante un relé). Para este caso, como el hardware a utilizar es el
MSP430g2553, contaremos con dos puertos locales, uno de 8 bits y otro de 6 bits.
El paquete de datos a transmitir, para la comunicación entre los paneles será de 4 bytes donde:
Byte 3: indica el panel remoto al cual va dirigido el paquete.
Byte 2: indica el puerto donde está conectado el dispositivo.
Byte 1: indica el bit del puerto donde está conectado el dispositivo.
Byte 0: indica la función a realizar
Las funciones a realizar son las siguientes:
Prender ahora
Apagar ahora
Prender indicando fecha y hora
Apagar indicando fecha y hora
Observación: Utilizando estas dos últimas funciones se puede lograr el prendido por franja
horaria. Si se utilizan las funciones de prendido y apagado indicando fecha y hora, se
transmitirá también un paquete de datos conteniendo, AÑO, MES, DÍA, HORA, MINUTOS.
Diagrama de bloques
Requerimientos y restricciones del sistema
Procesamiento y memoria
Dependiendo de la cantidad de dispositivos a controlar, el sistema deberá contar con la
memoria suficiente como para almacenar toda la información necesaria de cada dispositivo,
como su estado actual y las funciones a realizar. En este proyecto nos limitaremos a utilizar
una pequeña cantidad de dispositivos (locales y remotos) a modo de prueba para verificar el
correcto funcionamiento del sistema, y por este motivo, la memoria a utilizar no será un factor
de mayor importancia.
Tiempos de respuesta
Dadas las características de nuestro proyecto, consideramos que no existen exigencias en los
tiempos de respuesta ya que no se controlan dispositivos que manejen tiempos críticos.
Dispositivo 6
UART
PANEL DE
CONTROL
Remoto 4
Dispositivo R41 Dispositivo R42
Dispositivo R43
UART
P1
P2
Remoto 3
Dispositivo 1
Dispositivo 2
Dispositivo 3 Dispositivo 4 Dispositivo 5
Diseño preliminar
Plataforma de Hardware
Para este proyecto utilizaremos el LaunchPad MSP430G2553, ya que cuenta con un módulo
UART (necesario para realizar la recepción y transmisión de datos), dos puertos de
entrada/salida (suficientes para nuestros propósitos) y memoria suficiente para almacenar toda
la información tanto de la tabla de configuraciones como de las funciones a realizar.
Arquitectura de Software
Decidimos trabajar con una arquitectura de Round Robin para llevar a cabo las tareas a realizar
mediante el chequeo de una serie de banderas. Creemos que esta elección es la que mejor se
adapta a las características de nuestro sistema ya que debemos consultar si hay tareas
pendientes, datos completos recibidos o datos a transmitir, pudiendo usar una bandera para
cada una de estas funciones.
Actividades a realizar
Modificación del módulo tiempo utilizado en el laboratorio para agregarle la
funcionalidad de día, mes y año. (Tres días)
Realización del módulo que implementa el protocolo de comunicación con los
electrodomésticos. (Una semana)
Realización del módulo de procesamiento de comandos (una semana)
Realización de las funciones generales del sistema: (dos semanas)
Seteo de hora y fecha del sistema
Función prendido siempre
Función prendido apagado
Seteo de hora de encendido
Seteo de hora de apagado
Verificación del correcto funcionamiento del sistema (una semana)
Dependiendo del avance del proyecto y la disponibilidad de tiempo, se estudiará la posibilidad
de conexión de un display LCD para verificar status de configuraciones, fecha y hora.
Cronograma
Hito intermedio
Para el hito intermedio presentaremos el panel de control con el módulo de tiempo modificado,
y las funciones básicas respondiendo a algunos comandos.
