proyecto fin de grado grado en ingeniería en...
TRANSCRIPT
Proyecto Fin de Grado
Grado en Ingeniería en tecnologías
industriales
Aplicación de módulos RF en la Electrónica
de consumo utilizando el reloj Chronos como
interfaz de control.
Autor: Pablo Montero Robina
Tutor: Manual Ángel Perales Esteve
Departamento de Ingeniería Electrónica
Escuela técnica superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
2
3
Proyecto Fin de Grado
Grado de Ingeniería en tecnologías industriales
Aplicación de módulos RF a la Electrónica
de consumo utilizando el reloj Chronos
como interfaz de control
Autor:
Pablo Montero Robina
Tutor:
Manual Ángel Perales Esteve
Profesor Contratado Doctor
Departamento de Ingeniería Electrónica
Escuela técnica superior de Sevilla
Universidad de Sevilla
Sevilla, 2014
4
5
Índice general
Índice general ...................................................................... 5
Lista de símbolos y acortaciones ................................ 7
Lista de figuras, esquemas y tablas ........................... 8
1. Resumen ........................................................................... 11
2. Antecedentes................................................................... 15
1. Sistemas existentes .............................................. 15
2. Equipos usados ...................................................... 17
1. Reloj Chronos Ez-430 .................................. 18
2. MSP430G2553 ................................................ 24
3. CC110L RF Module Boosterpack ........... 31
4. Audio Capacitive Touch Boosterpack . 39
3. Sistemas referenciados ...................................... 40
3. Análisis ............................................................................. 45
1. Interfaz de Control .............................................. 46
1. SimpliciTI.......................................................... 47
2. Reloj Chronos.................................................. 51
2. Módulo RF y MCU ................................................ 57
1. Ejemplo "Titan Tank".................................. 57
2. Ejemplo "Luz" ................................................ 60
3. Ejemplo "Multimedia" ................................ 60
3. Conjunto de equipos .......................................... 65
4. Diseño .............................................................................. 67
1. Reloj Chronos ....................................................... 67
2. Repetidor ................................................................ 70
3. Tanque ..................................................................... 73
4. Luz ............................................................................. 75
5. Multimedia ............................................................ 76
1. MCU más módulo RF .................................. 77
2. MCU más módulo audio ............................ 78
6
5. Resultados ...................................................................... 83
1. Tanque ..................................................................... 83
2. Luz .............................................................................. 84
3. Multimedia ............................................................. 84
6. Conclusiones .................................................................. 85
1. Problemas encontrados .................................... 85
2. Trabajos futuros ................................................... 86
7. Referencias ..................................................................... 89
Anexos
1. Manual de Usuario
2. Desarrollo y Revelado de placas
3. Código implementado
7
Lista de símbolos y acortaciones
RF: Radiofrecuencia
MCU: Microcontrolador
PCB: Printed circuit Board
SoC: System on Chip
CCS: Code Composer Studio
GPIO: General Porpuse Input Output
SPI: Serial Port Interface
USCI: Universal Serial Communication
Interface
UART: Universal asynchronous
Receiver-Transmitter
Vcc: Tensión de alimentación
PDIP: Dual in-line package
PWM: Pulse Width Modulation
CC: Compare/Capture
MISO: Master input, Slave output
MOSI: Master output, Slave input
MSB: Most significant bite
LSB: Least significant bite
CSn: Chip Select Enable
FIFO: First in, First Out
DSP: Digital Signal Processor
OLED: Organic light emitting diode
CRC: Comprobación de redundancia
cíclica
WPAN: Wireless Personal Area Network
P2P: Peer to peer
8
Lista de figuras, esquemas y tablas
Figuras
Fig. 1.1: Esquema genérico del proyecto
Fig. 2.1: a) Reloj inteligente de Apple
b) Reloj inteligente de Samsung
Fig. 2.2: Dispositivo de comunicación inalámbrica con protocolo Z-wave
Fig. 2.3: Módulo Anaren R08A con armadura desmontada
Fig. 2.4: Launchpad MSP430G2XXX.
Fig. 2.5: Reloj Chronos, módulo de punto de acceso y módulo de programación
Fig. 2.6: a) Aspecto externo Chronos
b) Pantalla LCD del reloj
c) Menú de funcionalidades de la Línea 1
d) Menú de funcionalidades de la Línea 2
Fig. 2.7: Periféricos del sistema CC430F6137 interno en el reloj Chronos
Fig. 2.8: Diagrama de bloques de los periféricos del MSP430G2553
Fig. 2.9: pin-out del MSP430G2553 y las posibles funcionalidades de cada uno
Fig. 2.10: pin-out del módulo de Anaren R08A
Fig. 2.11: Captura del programa SmartRF
Fig. 2.12: Máquina de estados del módulo CC110L
Fig. 2.13: Estructura de los paquetes del módulo CC110L
Fig. 2.14: Audio Capacitive Touch Boosterpack
Fig. 3.1: Ejemplo topología de red SimpliciTI
Fig. 3.2: Estructura de los paquetes en el protocolo SimpliciTI
Fig. 3.3: a) Referencia de los ejes respecto al reloj
b) Valores de las medidas según la inclinación del ejeX
c) Valores de las medidas según la inclinación del ejeY
d) Valores de las medidas según la inclinación del ejeZ
Tablas
Tabla 2.1: Registros para la configuración de los pines del MSP430G2553
Tabla 2.2: Registros para la configuración del Timer_A del MSP430G2553
Tabla 2.3: Registros para configurar el periférico USCI_X0 del MSP430G2553
Tabla 2.4: Registros del módulo CC110L
Tabla 2.5: Dirección, nombre y descripción de los Strobes del módulo CC110L
Tabla 2.6: Valores a sumar para realizar operaciones con los registros
Tabla 3.1: Diversos gestos y pulsaciones posibles en el control del audio
9
Tabla 3.2: Pines asignados a los distintos gestos
Tabla 3.3: Efectos en el control de los diversos gestos
Esquemas
Esquema 2.1: Diagrama de flujo de la función main.c del programa del reloj
Esquema 3.1: Diagrama de flujo que sigue el código del reloj al pulsar 'DOWN'
Esquema 3.2: Diagrama de flujo de la función "Deteccion_evento()"
Esquema 3.3: Diagrama de flujo de la función "Procesar_evento()"
Esquema 3.4: Bucle de envío de datos por SimpliciTI una vez inicializado y
conectado
Esquema 3.5: Diagrama de flujo de la función "main" del programa por defecto
del audio capacitive touch boosterpack
Esquema 4.1: Diagrama insertado en el código original del reloj
Esquema 4.2: Diagrama de flujo del modo 'Tank'
Esquema 4.3: Diagrama de flujo del modo 'Luz'
Esquema 4.4: Diagrama de flujo implementado del repetidor
Esquema 4.5: Diagrama de flujo del MCU del ejemplo 'Tank'
Esquema 4.6: Diagrama de flujo del MCU del ejemplo 'Luz'
Esquema 4.7: Diagrama de flujo del MCU encargado del módulo RF del ejemplo
'Musk'
Esquema 4.8: Diagrama de flujo de la función "Pulsaciones()"
10
11
1. Resumen
Son numerosos los dispositivos inalámbricos presentes hoy en día tanto en el hogar
como en la calle y uno de los objetivos que la industria ha ido persiguiendo desde que
este mercado comenzó a explotarse es otorgar al usuario un interfaz de control
sencilla e intuitiva.
Este documento se centrará en plantear un método de control de los dispositivos que
resulte trivial y suponga el más mínimo esfuerzo al usuario. Evidentemente, este
método debe gozar de una comunicación inalámbrica, larga duración y un alcance
mínimo de funcionamiento.
No hay que olvidar, a la hora de plantear soluciones en estos ámbitos, la normativa
referente a dispositivos inalámbricos y al nivel de ruido emitido, siendo esto una
variable más que añadir a nuestro problema.
El tamaño de los dispositivos es otro factor a tener en cuenta ya que, en el ámbito de
la electrónica de consumo y sobre todo aquel en el que el usuario deba cargar con el
aparato, es de vital importancia ofrecer un tamaño versátil y ligero.
Finalmente, el que probablamente sea el factor más importante es el precio. Se estará
más limitado por este factor que por ningún otro y, por tanto, será de vital importancia
considerar un precio de los dispositivos asequible y viable.
Resumiendo, se plantea la búsqueda de uno o varios dispositivos que en su conjunto
sean capaces de comunicarse inalámbricamente con otros dispositivos, sean pequeños
y versátiles, sean sencillos, cumplan la normativa referente a emisiones
electromagnéticas y sean baratos.
Por todo esto, se ha considerado unos módulos de radio frecuencia que cumplen, a
primera vista, todos los requisitos mencionados anteriormente. Los módulos se basan
en un transceiver de radiofrecuencia montado y soldado junto a una pequeña antena y
componentes pasivos que actúan como filtro de la señal. Estos módulos carecen de
una interfaz propia y están diseñados para ser utilizados junto a un microcontrolador
que gestione los mensajes recibidos y sea capaz de enviar otros. En este proyecto, se
planteará un modelo de microcontroladores y se diseñará un sistema acorde a él que
permita la intercomunicación entre estos mismos módulos.
Retomando el planteamiento inicial del problema propuesto como la necesidad de una
interfaz de control intuitiva y versátil que se comunique con otros dispositivos
inalámbricamente, se llega a deducir que un reloj supondría una buena solución.
12
Resultó sencillo encontrar relojes que satisficieran estas especificaciones y nos
decantamos por el más barato de todos: Reloj "Chronos". Este reloj goza de numerosas
propiedades que lo hacen idóneo para nuestro sistema: Funciones de reloj,
Comunicación inalámbrica, acelerómetro de 3 ejes...
El problema pasó de convertirse en una búsqueda de dispositivos a una adaptación de
ellos para trabajar conjuntamente acorde a las peticiones del usuario.
Para presentar la aplicación finalmente resuelta, se plantearon varias aplicaciones del
producto propias de un entorno de la electrónica de consumo: Encendido y regulación
de la intensidad de una Luz LED, Control de un vehículo de juguete con el giro de
muñeca y un pequeño control multimedia. El esquema de conexión se muestra en la
Figura 1.1.
Fig.1.1: Esquema genérico del proyecto
13
El manual de usuario del sistema en funcionamiento se expondrá más adelante. El
funcionamiento que se alcanza en este proyecto consiste en el envío de paquetes del
reloj Chronos al módulo RF, el cual lo gestiona y envía otros paquetes al resto del
sistema. El mismo sistema se encarga de realizar la gestión del nuevo paquete y
obtener la información que necesita específicamente.
Cada ejemplo implementa un Microcontrolador y un módulo RF(radiofrecuencia) como
el expuesto en la figura anterior. Será en el apartado de Antecedentes dónde se
expondrán estos hardwares y las funcionalidades a las que se van a recurrir; en el
apartado Análisis se expondrá las conclusiones alcanzadas y cómo se han llegado
hasta ellas paso a paso; en el apartado de Diseño se expondrá de forma más detallada
la implementación de esas conclusiones; y en el apartado de Resultados se expondrá el
sistema al completo junto al manual de Usuario.
El resultado del sistema completo consta de un reloj con diversas opciones de control
expuestas en la pantalla del mismo durante su uso, de otro sistema con un módulo RF
junto a un microcontrolador (MCU) configurado únicamente como repetidor de la
señal del reloj y de los 3 ejemplos mencionados cada uno de ellos con un MCU y
módulo RF más el equipo necesario para la aplicación específica.
14
15
2. Antecedentes
Toda investigación o desarrollo de un sistema comienza con la búsqueda de proyectos
similares en los que apoyarse, de esta forma se consigue alcanzar objetivos más
ambiciosos. Tras una búsqueda más exhaustiva de proyectos que compartan los
objetivos o componentes usados se llega a encontrar algunos, mencionados más
adelante, que sirvieron como base de este proyecto.
Igualmente, también se menciona sistemas ya existentes para dar una mayor idea al
lector de por dónde se situan nuestras ambiciones.
2.1 Sistemas existentes
No se encontró un sistema comercial que cumpla exactamente los mismos detalles
que se impondrán en este proyecto, sin embargo el mercado de dispositivos
inalámbricos para la electrónica de consumo es muy amplio por lo que resulta
imposible no hallar similitudes.
Además, el uso de dispositivos bien conocidos y baratos en este proyecto da la
posibilidad de que cualquier individuo pueda realizarlo paralelamente o en el futuro.
Igualmente, respetando el principal objetivo de este proyecto se puede encontrar
numerosos dispositivos comercializados:
· IHEALTH ACM: Reloj inalámbrico de seguimiento de actividad para iPod,iPhone,iPad.
· Samsung Galaxy Gear:
Reloj inteligente con sistema Android
instalado.
Todos ellos ofrecen una interfaz de
control sencilla conectada al terminal del
móvil, ofreciendo una gestión y control de la interfaz sencilla. Aunque en estos casos el
Fig. 2.1 a) Reloj Ihealth de Apple
Fig. 2.1 b) Reloj Samsung Galaxy Gear de Samsung
16
reloj no ha sido diseñado para ser reprogramado, quedando el sistema cerrado a la
inclusión de otros protocolos o comunicaciones.
También cabe mencionar lo referente a la implementación de módulos inalámbricos
en redes domóticas entrando dentro del campo de la electrónica de consumo:
Fig. 2.2: Dispositivos de comunicación inalámbrica con protocolo Z-Wave.
Estos sistemas ya están siendo comercializados y su instalación resulta de lo más
elemental para la mayoría de los usuarios. Posee un software propio para
configuración de modalidades y comunicación con smartphones para un control
remoto.
Aunque se debe añadir, como defensa del proyecto, que los módulos implementados
aquí (uno para el LED, otro para el juguete y otro para multimedia) no superan los 15€
de precio por equipo, mientras estos módulos no bajan por debajo de los 40€ la
unidad.
Para concluir la comparativa, hay que decir que el sistema que se plantea en este
proyecto es fijo en lo referente a programación, por tanto su función sólo es
modificable reprogramando el sistema. Pero esto siempre se puede replantear como
un trabajo futuro.
17
Fig.2.3: Módulo Anaren R08A con armadura desmontada
2.2 Equipos usados
En este apartado se mostrarán los dispositivos usados, las capacidades de los mismos y
el porqué de su implicación en este proyecto.
Este proyecto comenzó a plantearse a raíz del reloj de Texas Instruments "Chronos"
que ofrecía una gran variedad de periféricos para implementar en la electrónica de
consumo. El aspecto más llamativo fue su posibilidad de ser reprogramado, lo que
abría la posibilidad de "retocar" el código inicialmente instalado para que cumpliera
cualquier especificación.
Conociendo que uno de los periféricos de este reloj era un transceiver de RF, toda
persona reconocería el potencial de lo que ello implica. Por lo que se pasó a la
búsqueda de dispositivos capaces de reconocer los mensajes enviados por el reloj para
así gozar de éste como la interfaz de control que se propone.
El transceiver RF que el reloj posee está integrado en el mismo sistema como un
periférico externo, por tanto se necesitaba un módulo RF que pudiera comunicarse
con él externamente. Tras aplicar ciertos criterios de búsqueda que se explicaran más
adelante se encontraron los módulos CC1101 (Transceiver sub<1GHz).
El mayor problema que este módulo
presentaba era la necesidad de
instalación de un conjunto de
componentes pasivos (bobinas,
condensadores y resistencias) que
ejercieran de filtro RF junto a una
antena. Finalmente, se encontraron
unos módulos que la compañía
Anaren proporcionaba y que
constaban de estos dispositivos y los componentes
pasivos ya montados sobre una pequeña PCB
junto a una antena (Figura 2.3).
Tras varias consultas en mayor detalle se
descubrió que este módulo era compatible con el
reloj y se procedió a pedir muestras de ellos al
fabricante.
El sistema que se busca debe gozar de un bajo
consumo a la vez que de un tamaño reducido. Esto
llevó a la búsqueda de un microcontrolador (MCU) Fig.2.4: Launchpad MSP430G2553
18
Fig. 2.5: Reloj Chronos, módulo de punto de acceso y módulo para programación
de bajo consumo, precio asequible y tamaño ligero encontrando el más representativo
de la compañía Texas Instruments: el G2553 de la serie MSP430 (Figura 2.4).
Es importante mencionar que el reloj va a ser programado y testeado usando la
herramienta Code Composer Studio v5.5 proporcionada por Texas instruments y el
MCU MSP430G2553 será programado a través de la plataforma IAR Embebbed
Workbench Studio ambos a través de códigos en Lenguaje C.
El primer caso se debe a que el programa por defecto del reloj que se va a modificar se
proporciona únicamente para esta plataforma, mientras que en el segundo caso, al no
haber programa fijo de partida (sólo algunas inicializaciones y funciones que se
mencionarán), se utilizará la otra plataforma por ser una plataforma con herramientas
de Debug más rápidas.
2.2.1 Reloj Chronos-Ez-430
Para comenzar se explicara qué es y de qué se trata el dispositivo que ha originado
todo este proyecto.
El reloj Chronos se trata de un reloj basado en el
sistema CC430F6137 sub 1 GHz RF tipo "System on
Chip" (SoC) que integra una pantalla LCD de 96
segmentos, un sensor de presión, un acelerómetro
de 3 ejes, un sensor de temperatura interno y un
medidor del nivel de batería. [1]
El sistema CC430F6137 tipo SoC consta a nivel de
hardware de un MCU de la serie MSP430 y un
transceiver inalámbrico de RF para frecuencias
menores a 1 GHz.
Goza de numerosos periféricos (Fig. 2.7) y aunque viene con un programa de
funcionamiento por defecto, el reloj puede ser desmontado y reprogramado con CCS.
El sistema es alimentado por una pila tipo CR2032 de 3 V.
Aunque la mayoría de estos periféricos no se mencionarán por formar parte del
desarrollo del código a más bajo nivel, cabe mostrarlos para una mayor comprensión
del sistema que estamos hablando y su potencial.
19
Para realizar tal tarea, se proporciona un dispositivo (parte superior izquierda de la
figura 2.5) que permite reprogramar y testear a tiempo real el sistema del reloj
conectándolo a un PC. También se proporciona un dispositivo que ejerce como punto
de acceso para el protocolo de SimpliciTI [2] basado en otro MCU de la misma serie del
reloj y un módulo RF basado en el sistema CC1101 que se explicará más adelante.
De aquí proviene el criterio de búsqueda de dispositivos compatibles con el reloj en
cuanto a comunicaciones por RF se refiere. Si este dispositivo funcionaba con el reloj a
través del protocolo pertinente significaba que el módulo era capaz de reconocer las
señales que éste mismo enviaba, por lo que se optó por indagar en este transceiver RF.
El aspecto externo, así como los botones accesibles por el usuario se muestra en la
Fig. 2.6 a) Aspecto externo del reloj Chronos Fig. 2.6 b) Pantalla LCD del reloj
Fig. 2.7: Periféricos del sistema CC430F6137, interno en el reloj. Incluye módulo RF (CC1101)
20
figura 2.6 a).
Estos son los que definirán la interfaz de control del sistema y se hará referencia a ellos
siguiendo la leyenda expuesta en la imagen.
La pantalla LCD consta de 2 líneas de números (Top y Bottom), que constan de 4
dígitos y 5,5 dígitos respectivamente, y una serie de símbolos predefinidos. Será a
través de ellos como se informará al usuario de la tarea que está ejerciendo (Figura 2.6
b).
El funcionamiento del reloj a nivel de usuario se detalla en la figura 2.6 c) y d).
La función ACC es en la que este proyecto se centra, ya que activa el modo de envío se
los valores del acelerómetro y de los botones según el protocolo expuesto.
El protocolo que el reloj utiliza es propio de la compañía Texas Instruments el cual
denomina SimpliciTI [2]. El protocolo en sí resultaba sencillo de interpretar una vez
implementado, pero su implementación en el MCU resultó más costoso de lo que se
pensaba por lo que se optó por examinar paso a paso su desarrollo, alterar el código
para saltarse el protocolo y proceder directamente al envío de la información a los
dispositivos cercanos.
Fig.2.6 c) Funcionalidades del reloj según pulsación del botón “*”
21
En los aspectos que concierne a este proyecto nos interesa desentrañar más
exhaustivamente el proceso de comunicación inalámbrica, así como cual es su
potencial y capacidades.
En [1] se puede encontrar los primeros indicios del protocolo de comunicación
inalámbrica así como enlaces a documentos técnicos del módulo periférico que utiliza
el reloj para este fin. El módulo periférico del reloj comparte numerosas similitudes
con el sistema RF que se va a utilizar, de ahí que sea el ideal para este uso, por lo que
el funcionamiento de éste no se expondrá en este apartado y se considerará que su
gestión será tramitada por las funciones de alto nivel del programa por defecto del
reloj.
Reconociendo el código predefinido como punto de partida, se examinará
superficialmente para saber cómo procesa la información, en el apartado de Análisis se
mostrará el flujo de información en el modo ACC (envío de datos del acelerómetro y
botones) y en el apartado de Diseño se indicará los cambios que se realizarán para
adaptar el código.
Hay que decir que al ser un programa por defecto ya integrado en el reloj, las
funciones resultantes son de alto nivel y por ello las mencionaremos junto a la
funcionalidad que cumplen sin entrar en detalle de lenguaje a más bajo nivel.
La función "main.c" resulta:
· Comienza inicializando el MCU (GPIOs, Reloj, cristal resonante (XOSC), Puerto de
comunicaciones (SPI) )y seguidamente inicializa los periféricos del sistema como son el
acelerómetro, el sensor de presión, la pantalla LCD y el módulo RF.
· A continuación, carga varias variables internas en la memoria para un correcto
funcionamiento. Entre ellas se encuentran los valores de calibración del acelerómetro,
los dígitos iniciales de la pantalla, los registros del módulo RF (se explicarán más
adelante), funcionalidades iniciales del reloj, etc.
· Una vez inicializado todo el hardware del reloj, se procede a pasar al modo "test" en
el que se conserva en un estado de bajo consumo, con todos los dígitos de la pantalla
encendidos y a la espera de que el usuario pulse algún botón. Este modo es el idóneo
para conservar el reloj en caso de largos periodos de inactividad, tanto es así que al
desempaquetarlo se encuentra en este estado.
Fig.2.6 d) Funcionalidades del reloj según pulsaciones del botón “#”
22
Esquema 2.1: Diagrama de flujo de la función 'main.c' del programa por defecto del reloj
· Seguidamente, entra en el bucle infinito de funcionamiento en el que comprueba
cíclicamente los botones pulsados e interrupciones del sistema, procesa el evento
causado y actualiza la pantalla LCD.
Tras realizar estas comprobaciones entre en el modo de bajo consumo en el que
desactiva las funcionalidades principales pero manteniendo los periféricos en
funcionamiento. Esto permite que ante algún evento causado por alguno de éstos, el
MCU del reloj despierte y atienda al evento.
En este sistema, las interrupciones causadas por los botones son las provenientes de
los GPIOs. Por ello, será en la función llamada por las interrupciones de los GPIOs
dónde se tramitará que botón se ha pulsado y cómo (larga o corta duración). De esta
forma, resulta sencillo mantener un sistema de bajo consumo atento a los botones
pulsados:
Entra en modo bajo consumo atento a interrupciones.
La pulsación de un botón genera una interrupción.
Se atiende a la interrupción mediante la función pertinente que
detectará que botón se ha pulsado.
BAJO CONSUMO
¿INTERRUPCIÓN?
SI
NO
DETECCIÓN
EVENTO
PROCESAR
EVENTO
ACTUALIZAR
DISPLAY
23
La secuencia del código vuelve al estado inicial en el que entró en el
modo bajo consumo pero al haberse producido una interrupción sale de
éste y prosigue con la siguiente línea de código.
Cómo se dijo anteriormente, el bucle de funcionamiento tras el modo
de bajo consumo consiste en comprobar evento, procesar evento y
actualizar pantalla.
Tras todo esto, vuelve a ejecutar el bucle comenzando por entrar en
modo bajo consumo atento a interrupciones.
Esta idea no es única para la atención de pulsaciones de botones, de forma muy similar
funciona el sistema al completo, por ejemplo la actualización de la hora en el reloj.
Aunque para cada periférico la función que llama la interrupción es diferente.
Otro aspecto del funcionamiento del reloj que se debe tener en cuenta es la distintas
funcionalidades de los botones según el estado en el que se encuentre (referidos en la
figura 2.6.c y 2.6.d). Esto se cita para indicar que el procesado de un evento no es
absoluto y la secuencia de código es alterada cada vez que se pulsa uno de los botones
"*" o "#" bajo un funcionamiento normal. El proceso "Detección evento" puede hacer
llamar a una de las funciones del modo actual (Figura 2.6c y 2.6d): función principal,
función secundaria, display y actualización del display; de forma que ejecute una
secuencia de código distinta para cada uno.
Aunque lo explicado pueda resultar elemental a primera vista, con ello se intenta
aclarar que el procesado de un evento no es inmediato, sino que requiere de una serie
de ejecuciones previas que sitúen la línea de código en la posición acorde al estado
actual y seguidamente se procese el evento. Esto se tendrá en cuenta en el apartado
de análisis para interpretar el flujo de datos del aspecto que nos interesa, así como
saber dónde realizar las modificaciones pertinentes.
Hay que recordar que estamos ante un sistema de bajo consumo dirigido al público
por lo que no sería eficiente mantener los sensores siempre activados, por ello sus
inicializaciones no se realizan hasta que el usuario (de forma directa o indirecta) las
solicite. Para este fin se declaran varias funciones que inicializan el periférico
correspondiente (Acelerómetro de 3 ejes, Módulo RF, sensor de presión, sensor de
temperatura, etc...) cuando el sistema lo requiere por el fin que busca, por ejemplo:
Inicializar el módulo RF y el acelerómetro cuando se active el modo ACC.
Aunque sólo se ha hablado del protocolo de SimpliciTI para conectarse con otros
sistemas, este sistema viene programado para soportar otro tipo de protocolo del que
solo se va a hacer mención ya que no es objeto de este trabajo. Se habla del protocolo
BlueRobin, usado en el reloj para comunicar el sistema con otros dispositivos
necesarios para hacer viables algunas funcionalidades del reloj. Es en los modos de
"Calories", "Heart Rate" y "Speed" en los que se llama a su inicialización para
comunicarse con un dispositivo que mande las medidas de velocidad de la persona, sin
24
éste es imposible que estos modos sean operativos. Este dispositivo es comercializado
de forma individual por Texas Instruments y permite aplicar ciertas funcionalidades de
reloj deportivo al Chronos. Gracias a este sistema, es posible monitorear el ritmo
cardíaco del usuario, la velocidad a la que corre y , de forma estimativa, las calorías
quemadas (variables de cálculo de las calorías quemadas modificables: peso, altura y
sexo).
2.2.2 MSP430G2553
El MSP430G2553 es un microcontrolador(MCU) de la compañía Texas instruments que
satisface las especificaciones impuestas de bajo consumo al disponer de un modo
“Low Power Mode” junto a numerosos periféricos.
La elección de este microcontrolador fue realizada por ser uno de los más avanzados
de la serie MSP430G2XXX (serie de MCUs de bajo consumo) que dispusiera en
formato PDIP la suficiente cantidad de pines de salida para realizar los ejemplos que se
proponen en este proyecto y que pudiera ser utilizado junto al módulo RF adoptado.
Esto no quita que pueda utilizarse otro MCU de una serie inferior (mientras posea los
periféricos necesarios para este sistema) si la aplicación final así lo permite, o incluso
de una serie superior para aplicaciones más ambiciosas. Pero como primera toma de
contacto se ha considerado este sistema como una ponderación intermedia que
permite exhibir el potencial del mismo sin suponer una gran dificultad de
programación y sin estar muy limitados por el sistema.
Los periféricos de los que goza este MCU se muestran en la figura2. 8 [3]
25
Algunos de los periféricos no han sido usados en el proyecto, pero no se descarta que
se les pueda dar uso en proyectos futuros.
Entre los periféricos disponibles, los más destacables de cara a este proyecto son:
USCI A0 : Utilizado como UART para comunicarse con el hiperterminal del PC.
USCI B0 : Utilizado como protocolo de comunicación SPI para comunicarse con
el módulo inalámbrico.
Port P1,P2 : Utilizado para definir numerosos “General ports input-output”
(GPIO) necesarios para la sincronización del MCU y del módulo.
Timer0 y Timer1 : Utilizado para el ejemplo del control de un vehículo de
juguete como generador de salidas “Pulse width modulator” (PWM).
El resto de periféricos son básicos para el funcionamiento del sistema (Flash, Clk…) ó
no se usan en este proyecto.
La memoria Flash es el elemento que contendrá el programa de funcionamiento así
como las variables que se utilicen en el programa. La herramienta de desarrollo (IAR
Embebbed Workbench) junto al Launchpad (Figura 2.4) son los encargados de mapear
la memoria e insertar el programa en ella, por lo que no nos preocuparemos de ella
para este sistema.
El reloj interno es la referencia del sistema completo, tanto para la línea secuencia de
la línea de código como para los periféricos, por lo que su programación determinará
el comportamiento de éste y de los periféricos. Un señal de un reloj no deja de ser una
serie de pulsos cuadrados de tensión a la misma frecuencia y hay determinados
registros de configuración que permiten reducir esa frecuencia para minimizar el
consumo y/o adaptarlo al sistema que buscamos (menor frecuencia, menor consumo).
Los pulsos que este reloj puede generar son de 16 MHz como máximo gracias a un
oscilador digital interno que no requiere de un cristal oscilador externo. Igualmente el
Fig.2.8 : Diagrama de Bloques de periféricos del MSP430G2553
26
cristal puede ser instalado para actuar como oscilador y los pines a los que se conecta
programados para tal fin.
Ya sea de una forma u otra, se generan 3 señales de reloj que son las usadas por el
resto del sistema: ACLK (Auxiliary clock), SMCLK (Sub System clock) y MCLK (Main
Clock). La importancia de estas señales reside en las aplicaciones que se requiera un
nivel de sincronismo muy preciso así como la velocidad del mismo sistema para
efectuar operaciones. Estas 3 señales son las referencias del sistema y pueden ser
modificadas. En el caso que se plantea, el sistema utiliza el oscilador digital interno
cuyos registros permiten modificar la frecuencia del sistema.
A la hora de configurar un periférico, se puede elegir el reloj de referencia entre una
de estas 3 señales, de forma que se puede tener uno de ellos configurados a una
frecuencia para determinados periféricos y otro a otra frecuencia para los periféricos
que requieran un valor distinto. Aún así, la mayoría de periféricos tienen la posibilidad
de incluir divisores de frecuencia a la entrada de la señal de referencia del reloj para
poder gozar de un mayor espectro de posibilidades sin afectar al resto del sistema.
Ahora se procede a explicar el funcionamiento de los periféricos principales que se van
a utilizar.[4]
2.2.2.1 Port P1,P2
Este periférico tramita la gestión del pin-out externo, dotándolo de una de las
funcionalidades que pueda disponer cada pin.
Por defecto, todos los pines (Exceptuando algunos especialmente indicados para otras
funciones, como Vcc o Vdd) están configurados como pines de entrada. Hay varios
registros que permiten modificar la funcionalidad del pin en cuestión, aunque hay
determinadas funcionalidades que son sólo accesibles para varios pines en concreto.
El pin-out se descompone en dos vectores (específico para el MSP430G2553 en
formato PDIP) según el puerto que le corresponda P1 y P2; y dentro de cada puerto
hay otro vector para denominar cada pin específico. La denominación de cada pin se
realiza atribuyéndole un puerto y seguidamente del número que le corresponde
dentro de él. En el caso que aquí se presenta los pines del puerto 1 van desde P1.0
hasta P1.7 y del puerto 2 van desde P2.0 hasta P2.7.
27
Tabla 2.1: Registros de configuración de los pines
Las funcionalidades de estos serán elegidas a través de los registros del puerto
pertinente (Tabla 2.1) y seleccionando el bit correspondiente al pin que se quiera
modificar.
Las posibles funcionalidades de cada pin se muestran en la figura 2.9:
Se hará referencia a esta figura para citar el pin en cuestión que estemos configurando.
No se detallará en el resto del documento cada una de las posibles funciones de cada
pin, ya que no es producto de este trabajo, pero se mencionará en adelante el pin
configurado para desempeñar la función específica.
2.2.2.2 Timer_A
Como se puede apreciar en la figura 8, este sistema consta de 2 periféricos Timer con 3
registros Compare/Capture (CC).
Fig.2.9: pin-out del MSP430G2553 y posibles funcionalidades de cada pin
28
Un timer se puede interpretar como un contador configurable (Registro TAXR). La
frecuencia de este contador depende del reloj que elijamos como entrada y del
registro divisor de frecuencia del reloj que configuremos.
Este contador está pensado para que su valor sea comparado con los registros CC
antes mencionados (llamados a partir de ahora TAXCCR0/TAXCCR1/TAXCCR2) y genere
determinados eventos cuando su valor se iguale ante el de ellos. El comportamiento
del contador también puede modificarse según el registro TAXCTL.
Hay 3 métodos de cuenta: cuenta hacia arriba, cuenta hacia abajo y cuenta arriba y
abajo. El primero de ellos hace que el contador se inicie en 0, se vaya incrementando
por cada pulso de reloj (con divisor de frecuencia incluido) hasta llegar al valor del
primer registro CC (TAXCCR0) en el que se reinicia y vuelve a valer 0; el Segundo actúa
de forma similar pero a la inversa, comenzando en el valor del primer registro CC,
decrementándose por pulso de reloj y reiniciándose al llegar a 0; y por último, el
tercero comienza desde 0 en sentido creciente hasta llegar al valor de TAXCCR0 en el
que invierte el sentido a forma descendente hasta llegar a 0 dónde vuelve a invertir el
sentido.
La verdadera funcionalidad de este periférico reside en los eventos que pueden
generarse cuando se igualan los registros comparadores CC al contador. A través de
varios registros (TAXCTLX) se pueden definir los eventos generados por los diferentes
registros comparadores, entre los que cabe destacar las interrupciones y los “Pulse
Width Modulator” (PWM).
Aunque el primer registro comparador sea necesario para poner un límite al contador
también puede ser utilizado para generar interrupciones. De esta forma se pueden
configurar interrupciones cada X tiempo en función del registro TAXCCR0. A su vez, el
resto de registros CC también pueden ser configurados para generar interrupciones,
aunque su uso más preferente es el de generador de PWM.
Se puede configurar a través de los registros CC el modo del que se desea generar los
pulsos, no sólo eligiendo el método de conteo (arriba, abajo, arriba y abajo), sino
también el efecto que supone para el pin de salida el que el contador se iguale al
Tabla 2.2: Registros del Timer_A
29
registro CC. Por ejemplo: poner a ‘1’ cuando contador iguale al TAXCCRX y poner a ‘0’
cuando contador iguale a TAXCCR0 o a la inversa.
Volviendo a la Figura 2.9, los pines seleccionables como salidas del timer X según el
registro CCY vienen marcados como TAX.Y.
Aunque este periférico posea un mayor potencial, no se entrará en más detalle porque
se aleja de los aspectos mencionados en este proyecto.
2.2.2.3 USCI_B0
“Universal Serial communication interface” (USCI) es el periférico encargado de
comunicarse con el resto de dispositivos a través de alguno de los protocolos de
comunicación serie.
Aunque el periférico mostrado en la figura 2.8 dispone de dos interfaces de
comunicación (USCI_A0 y USCI_B0), se entrará en mayor detalle del segundo caso
porque es el usado para comunicarse con el módulo RF.
Este periférico en concreto permite comunicarse con otros dispositivos usando uno de
los dos estándares integrados: I2C o SPI. Tras consultar el módulo RF, que se explicará
más adelante, el estándar de comunicación que usa es el SPI por lo que se expondrá
brevemente en qué consiste y cómo configurar este periférico para su correcto
funcionamiento.
El estándar de comunicaciones SPI es un bus usado para transmitir datos entre
diferentes equipos electrónicos. Requiere de un mínimo de 3 pines para establecer una
conexión Maestro-esclavo y un pin más por cada esclavo adicional que quiera incluirse
en el sistema.
Estos 3 pines son "Master input-Slave output" (MISO), "Master output-Slave
input"(MOSI) y el reloj (UCB0CLK). El estándar resulta bastante sencillo: El reloj es
generado por el maestro como señal de sincronismo, a cada pulso de reloj el maestro
establece un bit en el puerto MOSI y lee el bit del puerto MISO y el esclavo realiza la
misma operación pero con los puertos invertidos. La lectura del puerto debe
sincronizarse para realizarse en el mismo momento (rampa de subida del reloj, nivel
alto del reloj o rampa de bajada), al igual que la escritura debe realizarse lo más
alejado posible del instante de lectura (rampa de bajada, nivel bajo o rampa de
subida).
En lo respectivo al sistema del que se habla, se requiere habilitar el registro
(UCB0SYNC) que determina el uso de un estándar síncrono y configurarlo para usarlo
con 3 o 4 pines y en modo maestro o esclavo.
30
Los registros de este periférico se muestran en la Tabla 2.3.
Como se ha dicho anteriormente, el estándar requiere de un reloj de salida para el
maestro que sincronice todos los sistemas, esto resulta muy ventajoso ya que no
generará problemas de sincronismo al utilizar sistemas de distintas velocidades. Al
igual que en otros periféricos, el reloj puede ser elegido entre 2 posibilidades (SMCLK y
ACLK). Para tener un mayor margen de maniobrabilidad, se dispone de los registros
UCB0BR1 y UCB0BR0 que son divisores del reloj de entrada de forma que partiendo del
reloj seleccionado se pueda elegir un gran espectro de frecuencias inferiores a ésta.
Otras posibilidades de configuración son el disponer el bit más significativo (MSB) en el
puerto primero o el menos significativo (LSB), transmisiones de paquete de datos de 7
u 8 bits continuos y habilitar interrupciones de escritura (Buffer de escritura vacío) o
lectura (Paquete entrante en el buffer de lectura).
Los buffers de escritura y lectura son 2 registros de desplazamiento de 8 bits situados
antes de los puertos MOSI y MISO respectivamente. Los registros de desplazamiento
van desplazando bit a bit en el sentido que corresponda del puerto según los pulsos de
reloj, por ejemplo una vez relleno el buffer de escritura con 7 u 8 bits, este irá situando
(comenzando por MSB o LSB según se haya elegido) bit a bit a la salida del puerto
MOSI cada bit de la cadena hasta haber vaciado el buffer. Hay que mencionar que
ambos registros de desplazamiento operan concurrentemente, por lo que para poder
"rellenar" el buffer de lectura con los datos entrantes del puerto MISO es necesario
transmitir datos por el buffer de escritura aunque esto suponga transmitir datos
basura.
En cuanto al pin-out usado, el sistema usa los pines 1.5, 1.6 y 1.7 para el UCB0CLK,
MISO Y MOSI respectivamente.
Tabla 2.3 : Registros del periférico USCI_X0
31
2.2.3 CC110L RF Module Boosterpack.
Este módulo prefabricado está formado por una placa de conexionado adaptada al
Launchpad de la serie MSP430G2XXX y uno de los dispositivos antes mencionados de
Anaren (R08A) y este dispositivo está formado por un transceiver RF (CC1101) junto a
los componentes pasivos necesarios para su funcionamiento. El interés de este equipo
es que el transceiver en cuestión resulta ser el mismo que el que el reloj Chronos
posee internamente.
El pin-out necesario (Figura 2.10, [5]) para comunicar el MCU con el módulo RF viene
detallado en el datasheet del componente CC1101 [6], así como su funcionamiento y
maneras de proceder para su puesta en
marcha.
La comunicación del MCU con el módulo
se realiza a través del puerto SPI, un pin
que actúa a modo de “Chip Select
Enable” (CSn) y varios GPIOs cuya
funcionalidad es configurable (GDO0,
GDO1 y GDO2).
El sistema posee numerosos registros
modificables que permiten determinar
los parámetros de operación (frecuencia,
ancho de banda, tipo de modulación…)
así como comportamientos ante
determinadas eventualidades del
sistema. El cálculo de estos parámetros
se realizó a través de la herramienta
“SmartRF Studio 7” de Texas Instruments en el que ingresamos los valores operativos
del reloj ez-430 Chronos (frecuencia de comunicación, modulación, ancho de banda…)
y los funcionales del boosterpack (Frecuencia del cristal, potencia de emisión RF…) y
éste nos generó los valores que los registros del módulo debe poseer.
Fig. 2.10: pin-out del módulo de Anaren R08A
32
En la Tabla 2.4 se muestran todos los registros de este módulo.
El color de los registros indica su efecto en el certificado de uso en zonas Europeas:
verde indica ninguna alteración del certificado ante cualquier valor del registro, azul
indica que se recomienda usar la configuración dispuesta por defecto ya que en caso
contrario puede afectar negativamente al funcionamiento, rojo indica que cualquier
Tabla 2.4: Registros del módulo CC1101.
33
variación del código por defecto supone una violación del certificado y por tanto el
usuario debe obtenerlo por su cuenta, marrón son registros de sólo lectura y gris son
bits sin usar.
El módulo ha sido aprobado a través de diversos test estándares por la "European
telecommunication Standards Institute" (ETSI). Para información más detallada
consultar [5], página 14.
Entre los registros expuestos se van a detallar aquellos más relevantes en el
funcionamiento del sistema. La definición de todos ellos viene expuesta en [6].
Este módulo permite realizar y recibir transmisiones inalámbricas en un gran espectro
de frecuencia y diferentes modulaciones. A través de los registros FREQ2[5:0],FREQ1 Y
FREQ0 que definen el vector FREQ[23:0] se puede elegir cuál es la frecuencia base de
la señal portadora que se quiere usar siguiendo la fórmula:
.
El ancho de banda del canal se elige a través del subregistro CHANBW_M del registro
MDMCFG4; el tipo de modulación también es configurable en el subregistro
MOD_FORMAT en el registro MDMCFG2, pudiéndose elegir entre "2-
FSK","GFSK","ASK/OOK","4-FSK" y "MSK".
Como se puede observar todos estos registros (y muchos que no se han comentado)
permiten una gran variedad de configuraciones, lo cual puede convertirse en algo muy
Fig. 2.11: Smart RF Studio. Registros modificados por los parámetros RF resaltados verde.
34
tedioso si se quiere configurar una banda ya definida. Por ello, el distribuidor de este
módulo (CC1101) ha puesto a disposición del público un programa (SmartRF, figura 14)
para obtener estos registros de forma directa tan sólo ingresando los parámetros que
queremos obtener.
El resto de registros que no determinan el comportamiento del módulo a cómo se
desea y no han sido generados por este programa se recomienda dejarlos en el valor
por defecto para asegurar que no se produce un incorrecto funcionamiento.
El módulo posee un modo de bajo consumo al que puede acceder en cualquier
momento, en este estado el dispositivo permanece a la espera de alguna señal que le
haga pasar a alguno de los estados de la máquina de estado. Hay que añadir que el
sistema requiere calibrarse "On-line" cada cierto tiempo para asegurar un correcto
funcionamiento, este es otro estado al que se puede acceder manualmente o
configurarlo para que acceda automáticamente al cambiar de estado (Registro
FS_AUTOCAL).
El comportamiento viene determinado por una máquina de estado (Figura 2.12):
Fig. 2.12: Máquina de estados del módulo CC1101
35
Los círculos representan el estado que contienen y las flechas indican el cambio de
estado ante las eventualidades que indican.
El cambio de estado se realiza a través del envío de las llamadas “Strobes” (Tabla 2.5)
desde el MCU hasta el módulo (enviar la dirección expuesta en la Tabla 2.4 por el
puerto SPI) o por fin de estado, por ejemplo: (Figura 12) Si estamos en Modo “RX”
(Lectura) y finaliza de leer el paquete, pues puede permanecer en estado RX si
“RXOFF_MODE” es igual a ‘11’; pasar al estado “CALIBRATE” si “RXOFF_MODE” es igual
a ‘00’ y “FS_AUTOCAL” es igual a ‘10’ ó ‘11’; pasar al estado “IDLE” si “RXOFF_MODE”
es igual a ‘00’ y “FS_AUTOCAL” es igual a ‘00’ ó ‘01’, ó si se genera un error en la
lectura por saturación de la memoria (“RXFIFO_OVERFLOW”)...
La mayoría de los registros arriba mencionados son subregistros de los registros
MCSMX (Control de la máquina de estados del módulo).
El dispositivo posee dos memorias de 64 bits “First in First out” (FIFO) para lectura y
escritura respectivamente, de forma que ante la detección de una señal RF legible la
almacene en la FIFO de lectura (estado RX) e informe al MCU de la llegada de un
paquete a través de uno de los GPIO´s configurados para ello.
La escritura de los registros de configuración, así como una de las memorias FIFO se
realiza a través del puerto SPI. Primero se envía la dirección del registro a modificar (en
caso de enviar un "Strobe" basta sólo con enviar la dirección de éste para notificar al
módulo) y seguidamente se envía el valor del registro. La lectura de los registros se
efectúa de forma similar pero sumando un valor absoluto a la dirección del registro
(Tabla 2.6).
Tabla 2.5 : Dirección en memoria de las "Strobes", nombre y descripción
36
Existe la posibilidad de realizar varias escrituras/lecturas en cadena incrementando la
posición de memoria por cada byte escrito/leído de forma que se agiliza el proceso
total. Se habla de BurstWriting/Burstreading, y para ello tan sólo hay que sumar una
valor absoluto a la dirección de memoria dónde queremos empezar a escribir (Tabla
2.6) y desde ese entonces mientras mantengamos el pin de CSn bajo podremos
escribir/leer de forma continua.
Cada vez que se realiza la primera escritura para enviar la dirección del registro que
queremos manipular o "Strobe" que queremos enviar, el sistema nos devuelve,
concurrentemente a la escritura, el "Status Chip Byte" (SCB) que incluye información
del sistema: estado del chip{7} (1 si el cristal está estabilizado, 0 si no lo está o se está
usando la interfaz SPI), estado en la máquina de estados{6:4}, número de bits
disponibles en la FIFO RX o bits libres en la FIFO TX {3:0}.
La configuración de los GDOX se realiza a través de los registros IOFGX que determina
que comportamiento a realizar según la situación que se presente (Ref. [6].Tabla
41.pág 62.). El más usual es el de indicador de "chip ready" (CHP_RDYn) y el de
activación por paquete entrante en modo RX. Gracias a este último, se puede generar
una interrupción al MCU que lea la memoria RX cuando esto ocurra.
El procedimiento para enviar un mensaje por RF desde el MCU comienza por su
escritura en la memoria FIFO de escritura seguido de un “Strobe” que mande al
sistema a emitir la señal (Pasar al estado TX).
2.2.3.1 Formato de los paquetes
Este sistema incluye numerosas opciones para el tratamiendo de los paquetes de
información. Un paquete es una cadena de bytes que se almacena en la memoria FIFO
correspondiente para luego ser procesado.
Cada paquete tiene una estructura fija que puede ser modificada según la
configuración de los registros (MDMCFGX y PKTCTRLX). La estructura de un paquete se
muestra en la figura 2.13.
Los "preamble bits" son cadenas 8xn bits de 1 y 0 alternados, siendo n el valor
configurado en el registro MDMCFG1.NUM_PREAMBLE. Cuando se habilita el estado
de TX, éste comienza a emitir los bits de "preamble" para luego enviar el resto del
Tabla 2.6 : Valores que sumar a la dirección a acceder para proceder con la operación pertinente.
37
paquete. En caso de encontrarse la TX FIFO vacía cuando termine de emitir los
"preamble bits" seguirá emitiendo bits de preamble hasta que se escriba el primer
byte en la memoria.
La siguiente parte del paquete son los bytes de sincronización. Estos bytes sirven para
sincronizar los bytes del paquete entrante y son definidos por el registro SYNC1 y
SYNC2. Por defecto, tiene una longitud de 16 bits (un byte por registro) aunque puede
configurarse para ser de 8 bits (estableciendo SYNC1 igual al patrón de los Preamble
bits) o para ser de 32 (cambiando el registro MDMCFG2) enviando 2 veces ambos
bytes.
La longitud del paquete puede tener diferentes modalidades
(PKTCTRL0.LENGTH_CONFIG) y de ello depende el uso del campo "Length field". La
modalidad de la longitud del paquete puede ser elegida entre longitud fija, longitud
variable y longitud infinita:
Longitud fija: (PKTCTRL0.LENGTH_CONFIG=0) En este caso la longitud del
paquete está fijada por el registro PKTLEN que debe ser distinta de 0.
Longitud variable: (PKTCTRL0.LENGTH_CONFIG=1) En este caso la longitud del
paquete está fijada por el primer byte después del byte de sincronización. Este
valor será el primero que habrá que escribir en la memoria FIFO para un
paquete de esta modalidad y debe ser distinto de 0. Bajo esta configuración, el
registro PKTLEN marcará la longitud máxima permitida.
Longitud infinita: (PKTCTRL0.LENGTH_CONFIG=2) En este caso se admite la
posibilidad de que el paquete pueda ser una retransmisión constante o de
longitud mayor que de 255 bytes (máximo valor del contador de bytes leídos).
En este caso el paquete se irá tratando (conforme a las configuraciones de
tratamiento de paquetes) a la vez que va llegando.
El caso de longitud infinita es especialmente interesante para casos en los que el
paquete a enviar tenga una mayor longitud de 255 bytes, ya que este es el valor
máximo que se puede fijar como longitud del paquete (tanto el byte de longitud para
el caso de longitud variable, como para el regitro PKTLEN en caso de longitud fija).
Fig. 2.13: Estructura de un paquete antes de ser procesado
38
Para procesar un paquete mayor que la memoria FIFO de lectura (64 bytes) es
necesario que ésta se vaya leyendo a la vez que se escribe en ella, por lo que resulta
vital la sincronización del MCU con el módulo ya que puede resultar en un incorrecto
funcionamiento el caso de que se vacíe la memoria mientras se siga rellenando o que
la memoria sature (en cuyo caso pasaría al estado de RXFIFO_OVERFLOW y dejaría de
recibir paquetes). Para ello se utiliza el registro FIFO_THR junto con los pines GDOX.
Este registro permite generar un cambio en el pin GDOX cuando el número de bytes
en la memoria FIFO supere un determinado umbral. De esta forma se puede
sincronizar con el MCU para leer cierta cantidad de bytes y no permitir que se vacíe ni
que sature.
Entre las posibilidades que ofrece este módulo está la posibilidad de asignarle una
dirección fija (Registro CHANRR) de forma que tras haber comprobado la longitud del
paquete (en caso de longitud variable) pasaría a comprobar si el siguiente byte
("Address field") concuerda con el registro definido. En caso de no ser el mismo, el
paquete se descarta y el proceso termina (que puede permanecer en estado de RX si
así está configurado o pasar a otro estado).
Por último, en la gestión de los paquetes se da la opción de añadir numerosos
procesos y comprobaciones para asegurar que el paquete no se ha corrompido en la
transmisión. Destaca la opción "Auto-CRC" configurable en el registro
PKTCTRL1.CRC_AUTOFLUSH que descartará cualquier paquete que no haya pasado el
chequeo CRC. Este chequeo consiste en la aplicación de un algoritmo al paquete
saliente que da como resultado un byte, este byte se envía junto al paquete al final del
mismo y el sistema receptor, aplicando el mismo algoritmo, debe obtener el mismo
número si el paquete no está corrupto.
También existen diferentes opciones para codificar, según distintos métodos, el
paquete a la salida para hacerlo más inmune al ruido externo, siendo el módulo
receptor el encargado de decodificarlo tras haber reconocido los bytes de
sincronización.
2.2.4 Audio Capacitive touch Boosterpack
Este será el módulo que se utilizará para la gestión del control multimedia. Es un pack
con el formato de montaje igual que el CC110L RF Boosterpack y ofrece una interfaz de
control mediante un teclado capacitivo de un reproductor de Audio. Los archivos de
audio a reproducir se almacenan en una tarjeta SD o mediante un dispositivo de
almacenamiento USB.
El dispositivo posee un DSP ya programado, una salida jack, un zócalo para tarjetas
mini SD, una pantalla OLED, una rueda gráfica (como interfaz capacitiva) con varios
LEDs en una capa inferior y una entrada mini USB.
39
El estudio y análisis de este sistema se ha realizado a través del programa por defecto
ya cargado en el sistema [7]. Este estudio tenía como objeto localizar los registros a
modificar para gestionar el control, así como formas de modificarlo.
Este sistema estaba programado inicialmente para hacer esta gestión a través de los
botones capacitivos pudiendo realizar diversos gestos (deslizar en sentido horario,
presionar derecha, mantener botón central...).
En este apartado se aclara que el teclado capacitivo no se contemplará en el diseño del
sistema ya que se pretende usar el reloj para su fin, por lo que se suprimirá del código.
Los archivos compatibles con este sistema están en formato .mp3. El diseño está
planteado para ofrecer al arranque una navegación entre los directorios de la tarjeta
SD en los que se podrá elegir el archivo a reproducir. Una vez en reproducción
avanzará archivo a archivo según se indique o al finalizar la canción actual.
También ofrece una gestión del volumen a la salida del puerto Jack, así como el cambio
de pistas una vez en reproducción.
La comunicación entre el MCU (cuyo programa se analizará y modificará) y el DSP se
realiza a través de la SCI en formato UART. También se utiliza un pin (P2.7) para
encender (P2.7='1') o apagar (P2.7='0') el DSP.
Los LEDs se gestionan con el pin-out
del puerto 1 (P1.0, P1.3, P1.4, P1.5,
P1.6 y P1.7) tal y como se indica en el
programa (se comentará más
adelante). Hay 9 LEDs en total,
definidos en el programa según el
grado de giro en sentido horario
(45,80,100,135,225,160,280 y 315) en
adición del LED central. El teclado
capacitivo está comandando por los
pines del puerto 2 (P2.0 ~ P2.5)
formando una red bajo la rueda
gráfica para el reconocimiento de los
gestos según ésta.
Tanto la reproducción de audio, como la gestión de la pantalla quedan a cargo del DSP.
Las órdenes de ejecución se realizan a través del estándar UART por dónde se enviarán
los comandos al DSP.
El formato de funcionamiento, así como la adaptación al sistema que se quiere
desarrollar se realizará en el apartado de Análisis.
Fig. 2.14: Audio Capacitive touch boosterpack
40
2.3 Sistemas referenciados
El módulo inalámbrico usado llevaba en el mercado más de 1 año cuando este
proyecto comenzó a realizarse, resultaría imprudente no revisar posibles sistemas ya
desarrollados para no empezar con una base nula de conocimientos. De la misma
forma, el reloj usado llevaba también bastante tiempo a disposición del público
habiendo, pues, una gran variedad de proyectos disponibles.
El primer trabajo [8] en el que se apoyó este proyecto era uno que desarrollaba un
código en el mismo microcontrolador aquí usado para comunicar 2 módulos entre sí. El
sistema tan sólo enviaba un carácter a uno de los micros por un terminal virtual desde
el PC y los mostraba en el terminal del otro.
Tomando como base este sistema se pudo diseñar el principio del proyecto: La
comunicación entre dos módulos. Este proyecto incluía todas las inicializaciones
necesarias para hacer funcionar el MCU en conjunto con el módulo, así como las
funciones primarias de comunicación entre ambos.
Hubo otro proyecto [9] vital para el conocimiento del protocolo de comunicación del
reloj en el que, usando el mismo sistema que se propone aquí, se pudo obtener las
medidas del acelerómetro y las pulsaciones de botones del reloj. Este sistema se
diferencia del realizado aquí en que el código del reloj no es alterado para esta
aplicación, de forma que el desarrollo del sistema consiste en adaptarse al modo de
funcionamiento que el reloj realiza y sin posibilidad de mostrar al usuario un mayor
detalle de lo que está haciendo.
Igualmente, sirvió como piedra angular para descifrar el funcionamiento del modo
inalámbrico del reloj por lo que es digno de mención.
2.3.1 Working with Anaren Boosterpack [8]
El desarrollo de este primer proyecto al que referimos plantea como objetivo la
comunicación entre dos dispositivos inalámbricos que están conectados
respectivamente a través de la UART a una máquina virtual.
La idea consiste en mantener ambos dispositivos a modo de escucha, de forma que si
alguno de los dos realiza algún envío de información, éste sea capaz de tramitarla
imprimiendo el dato recibido en pantalla. Seguidamente, en el caso de que alguna de
las máquinas virtuales envíe algún carácter (una letra) al microcontrolador éste
abandone el modo de escucha para enviar el mensaje lo antes posible y retornar al
modo escucha inicial.
41
Los datos que se envían se tratan únicamente de carácteres ASCII (8 bits) enviados
individualmente e impresos por pantalla uno a uno.
Este proyecto fue la fundamentación del resto al incluir las inicializaciones de la
mayoría de los periféricos que se usan: GPIOs y USCIB0 como SPI.
Además, por el objetivo del propio programa, incluía varias inicializaciones de otros
periféricos como numerosos GPIOs para encender LEDs y el periférico USCIA0
inicializado para funcionar a través del estándar UART. El mismo launchpad del
MSP430G2553 contiene un integrado que permite adaptar la señal UART al USB para
conectarlo al PC. De esta forma, utilizando una máquina virtual que reconociera el
protocolo de comunicación serie y configurando el MCU para emitir con el "Baud rate"
(a través del registro de divisor del reloj UCA0BR1 y UCA0BR2) correspondiente al
configurado en la máquina virtual, se puede establecer una comunicación y enviar
caracteres de uno a otro. La máquina virtual utilizada es el "Tera Term" obtenido
gratuitamente en línea.
La configuración más relevante de este sistema es que realiza las comunicaciones en
modulación GFSK, formato de longitud de paquete variable y 32 bytes de
sincronización. Realiza también el chequeo CRC pero no descarta automáticamente el
paquete. La máquina de estado está configurada para no abandonar el modo RX ,a
menos que se mande un Strobe que lo fuerze a salir, y realizar la calibración al cambiar
del estado RX a TX o viceversa.
Este código además de las inicializaciones correspondientes y las tablas de registros de
configuración fácilmente accesibles (para ser modificadas si se requiere) posee
también numerosas funciones de alto nivel para hacer uso del módulo RF.
Entre ellas cabe destacar:
setup_cc110L(void): esta función llama a otras funciones para inicializar el
módulo. Comienza realizando un proceso llamado "power-on start-up
sequence" definido en la referencia [6] pág. 51, en la que el sistema debe ser
reiniciado manualmente según la secuencia descrita para funcionar
correctamente; a continuación escribe los registros de configuración por el
puerto SPI siguiendo el método escrito y finalmente envía el Strobe SRX para
entrar en el estado RX.
writeRFSettings(void): LLama a la función SPIWriteReg(char dir, char value), el
cual escribe por el puerto SPI la dirección enviada como argumento dir seguido
del valor del argumento value, para cada registro de configuración (cuyas
direcciones están incluidas en fichero de cabecera ".h") y ésta escribe el valor
en el registro usando el puerto SPI.
RFReceivePacket(char *rxBuffer, char size): Esta función debe ser llamada ante
la interrupción de que un paquete ha sido registrado. Devuelve un carácter que
42
indica si tal paquete pasa el chequeo CRC, en caso afirmativo almacena el
paquete leído desde la RX FIFO en txBuffer y guarda en size la longitud de éste.
RFSendPacket(char *txBuffer, char size): Esta función carga en la memoria FIFO
de escritura el paquete al que apunta txBuffer con la longitud descrita en size.
Partiendo de estas funciones ya definidas, se puede alcanzar un programa más
simplificado recurriendo a ellas para hacer uso del módulo.
El flujo de los datos que el programa propone es el que sigue:
Envío por TeraTerm del PC un carácter ASCII.
Interrupción del microcontrolador para leer el carácter.
El microcontrolador lee el dato y lo reenvía por el hiperterminal para mostrarlo
por pantalla y que el usuario sepa que su carácter ha sido registrado.
El carácter es empaquetado incluyendo el bit de longitud del paquete, enviado
por puerto serie SPI al módulo y el MCU espera la activación del CHP_RDYn.
El módulo almacena el paquete y activa el pin de CHP_RDYn.
El MCU reconoce la activación, envía el Strobe STX y vuelve al modo bajo
consumo.
El módulo pasa al estado de TX (calibrándose primero) y procede a enviar el
paquete. Al finalizar vuelve al estado RX
El módulo receptor reconoce el paquete y lo almacena en memoria.
Realiza las comprobaciones de longitud de paquete y activa el GDO encargado
de avisar al MCU de paquete entrante.
El MCU despierta del modo de bajo consumo y solicita el paquete por el puerto
SPI.
Reconoce el paquete, su longitud y comprueba el chequeo CRC.
En caso afirmativo envía el carácter por la UART y éste es impreso por pantalla.
En caso negativo ignora el mensaje.
El MCU vuelve al estado de bajo consumo.
A ojos del usuario, es capaz de escribir cadenas de caracteres a velocidad de escritura
estándar y verlos impreso en la ventana del Tera Term del módulo receptor.
2.3.2 Ti MSP430 Launchpad [9]
Cómo se dijo anteriormente, en este proyecto se parte del conocimiento del protocolo
de comunicación SimpliciTI y su desarrollo se basa en la adaptación de este protocolo
para hacer creer al reloj que está estableciendo la conexión con un punto de acceso [2]
y proceder al envío de datos. Goza de la ventaja de no tener que alterar el código del
reloj por lo que el sistema podría implementarse con el código de partida, aunque en
el sistema que se busca no sería especialmente eficiente.
43
Este proyecto aclaró el protocolo de SimpliciTI a nivel de orden de paquetes enviados y
bajo que propósito. Por ello, el protocolo se expondrá con un detalle similar en el
apartado de análisis.
La idea de este proyecto era recurrir a las medidas del acelerómetro y a los botones
pulsados para incluirlos en cualquier sistema, pero este desarrollo no contemplaba la
idea de realimentar las acciones del usuario al mismo a través del reloj, algo
imprescindible en una interfaz de control.
44
45
3.Análisis
Este apartado se centra en alcanzar una serie de conclusiones a través del estudio de
las referencias una a una, ponerlas en común e implementarlo en un sistema. La
explicación detallada de cómo se ha implementado junto a los ejemplos planteados se
expondrán en el apartado de Diseño.
Se comenzará estudiando la interfaz de control, seguidamente se procederá a analizar
los módulos captores de la señal y finalmente, la implementación de estos últimos con
el MCU propuesto.
El objetivo de este proyecto es programar un reloj para que actúe como interfaz de
control en un sistema diseñado exclusivamente para ello. Por ello, los aspectos más
importante a tener en cuenta son:
Realimentación al usuario de que tarea está desempañando.
Despreocupación por las limitaciones de Alcance de las señales RF.
Duración de la batería.
El primer aspecto debe cubrirse en el programa interno del reloj, por lo que debe ser
objeto de análisis el suplir ese requisito.
El segundo y tercer aspecto están correlacionados: Si incrementamos la potencia de la
señal RF aumentamos el consumo y a la inversa. Habría que buscar una solución de
compromiso que no suponga un problema para ambos casos: ofrecer un alcance
mínimo típico de interiores al menor consumo posible.
Hay que recalcar que se está hablando de una red del estilo WPAN cuyo nivel físico es
el aquí descrito y usado: el control del transceiver RF junto al tratamiento de los
paquetes. La extensión de este sistema a capas superiores queda propuesto como
futuro posible trabajo.
46
3.1 Interfaz de Control
Una Interfaz de control puede ser entendida como aquel sistema que identifique una
señal generada por el usuario (ya sea interna al sistema o externa a él), la transforme
en otra y ésta genere un cambio en los equipos actuadores del sistema. Para
ejemplificarlo se analiza un caso muy común, un mando de la televisión:
1. El usuario pulsa un botón cuya funcionalidad se explica visualmente en la
etiqueta del mando → Identificación.
2. El mando reconoce la señal, la codifica y genera otra de estilo óptico
→Transformación.
3. El sensor de la televisión reconoce la nueva señal, la decodifica y actúa en
consecuencia →Actuación.
El sistema planteado debe cumplir estas especificaciones de una forma similar. Aunque
para saber que señales hay que identificar, cómo y cuándo; se debe recordar los
objetivos finales planteados en este sistema. Ellos fueron:
Control de un vehículo de juguete con el acelerómetro interno del reloj.
Regulación y conmutación de una luz LED.
Control multimedia de audio.
Sabiendo esto, hay que informar al usuario cuál de estos ejemplos está tramitando,
darle algunos parámetros de control y mostrar de forma visual las acciones ejercidas.
Para el primer caso se utilizará un vehículo de juguete "Titan Tank" comercializado
cuyo diseño y control serán explicados más adelante . Cuando estemos manipulando
su funcionamiento debe mostrarse por la pantalla del reloj una serie de caracteres que
así lo indiquen y la señal interna generada por el acelerómetro debe ser leída y enviada
a los módulos receptores. Las medidas del acelerómetro deben ser tramitadas para
reconocer la posición relativa de la aceleración gravitacional y de esta forma conocer la
inclinación de la muñeca.
Para el segundo caso se utilizará una luz LED de 3W. La regulación de la intensidad de
luz se realizará a través del giro de muñeca y la conmutación ON-OFF a través de los
pulsadores. Es evidente que para este caso la señal del acelerómetro no debe ser
tramitada continuamente, sólo si el usuario desea regular su intensidad.
Para el tercer y último caso se utilizará un módulo audio capacitive boosterpack para
MSP430 que se expondrá más adelante. En este caso se plantea realizar una regulación
del volumen a través del giro de muñeca sólo en el caso de que el usuario así lo desee
además de cambio de estación en reproducción por pulsación de botones.
47
Antes de empezar a indagar en aspectos que involucran al módulo RF o al MCU, se
comenzará detallando el código del reloj centrándose en la función "ACC" a través de
la cual realiza el envío de las medidas del acelerómetro y de los botones pulsados.
Cómo se comentó en las referencias, el Chronos está programado para permanecer en
un estado de bucle en la función principal en el que comprueba los eventos ocurridos,
los procesa y actualiza el display. Pero antes de indagar en el código es necesario
exponer cual es el protocolo de comunicación RF que el reloj sigue para enviar
información: El protocolo SimpliciTI.
3.1.1 SimpliciTI
SimpliciTI es un protocolo desarrollado por Texas Instruments cuyas librerías de
funciones de alto nivel están a disposición del público para numerosos sistemas de la
misma compañía.
Utilizando las referencias [2],[5] y [10] se puede alcanzar a comprender el sistema de
forma bastante clara.
SimpliciTI es un protocolo de red para dispositivos de bajo consumo, sus funciones
ocupan menos de 8k de flash por lo que es un protocolo de bajo coste, soporta
configuraciones en estrella o "peer to peer" (p2p) y admite MCU con funcionalidades
de modo "Sleeping" (ultra bajo consumo).
Cada dispositivo puede poseer 3 funcionalidades en la red: Dispositivo final, punto de
acceso y repetidor (Figura
3.1).
El punto de acceso es el
dispositivo central que
interconecta todo el sistema y
debe estar siempre activo. Es
el encargado de gestionar el
direccionamiento de la red y
de almacenar los envíos para
dispositivos en modo
"Sleeping".
Los repetidores tienen la
funcionalidad de incrementar
el alcance de la red,
reenviando todo mensaje que
le alcanza. Deben estar siempre operativos y pueden ejercer algunas funcionalidades
como dispositivos finales. Fig. 3.1: Ejemplo de topología de red SimpliciTI
48
Los dispositivos finales son aquellos que realizan las funciones del sistema en sí, los
que el usuario gestiona o sensores instalados.
En el ejemplo de la Fig. 3.1 se pueden apreciar varias de las posibilidades de este
sistema: Flujo Directo del mensaje (mensaje "peer to peer") o mensajes dirigidos al
punto de acceso.
Cada dispositivo final posee una serie de variables, definidas internamente en el
programa del dispositivo, que lo identifica en la red. El proceso de iniciación de la red
consiste en inicializar el punto de acceso (Dispositivo físico) y dejarlo en modo de
escucha para tramitar peticiones de unión a la red. A continuación, cualquier
dispositivo final que quiera realizar algún envío al punto de acceso sólo tiene que
(después de inicializarse) llamar al punto de acceso para unirse a la red ("Join")y una
vez unido, enviar el mensaje.
El punto de acceso les asignará varios caracteres que deberá incluir en los mensajes
para que estos sean aceptados en la red (llamados "Join Token") y serán los mismos
para todos los dispositivos dentro de la red. El proceso de unión a la red es confirmado
por el punto de acceso a través de un mensaje que éste le devuelve.
Es evidente que en un principio que se inicializa la red es bastante probable que los
dispositivos no están sintonizados, por ello al inicializarse el punto de acceso este
manda un mensaje en todas las frecuencias tabuladas en el que incluye información
sobre la Frecuencia que se está utilizando.
En el caso de los mensajes "peer to peer" el proceso se inicia de forma similar, pero en
este caso el dispositivo receptor debe estar a la escucha de propuestas de "Link"
(conexión) para que otro dispositivo se le una directamente a él. El Cliente (dispositivo
que quiere conectarse) enviará la propuesta de unión a toda la red y el servidor
(dispositivo a la espera de conexiones) responderá a este dispositivo únicamente.
Ambos dispositivos almacenan la dirección del opuesto y el "link Token" asignado
(generado en este caso por el cliente).
La estructura de los paquetes en este protocola es la que sigue:
Fig. 3.2: Estructura de los paquetes en el protocolo SimpliciTI
49
Los bytes de "preamble" y "sync" son propios del módulo RF y se explicaron en los
apartados anteriores. El byte de Length se dispone así ya que tratamos de un sistema
configurado para paquetes de longitud variable (ver apartado 2.2.3.1). El byte de MISC
puede ser insertado automáticamente por el módulo RF, no es el caso de este
proyecto.
El resto de bytes tienen un sentido expuesto:
DSTADDR: Es la dirección de destino del mensaje. Esta es propia de cada
dispositivo y el dispositivo que envía el mensaje debe conocerla previamente.
SRCADDR: Es la dirección del dispositivo que realiza el envío, dejando una
huella de quién realiza el envío. Se utiliza primordialmente para responder a
peticiones o enviar mensajes de confirmación.
PORT: El MSB indica si es un mensaje reenviado ('1') proveniente de otro
dispositivo o no ('0'), el bit 6 indica si el mensaje está encriptado ('1') o no ('0') y
el resto de bits {5:0} indican el número del puerto. El número del puerto es un
indicador de la aplicación para la que se ha enviado el mensaje (Link, unión a la
red, reconocimiento de dispositivos...)
DEVICE INFO: Contiene información sobre el dispositivo que está enviando el
mensaje. Incluye un bit indicador de solicitud de respuesta de confirmación; un
bit indicador de si el dispositivo entra en modo "Sleeping" o escucha
periódicamente (para proveer de almacenamiento del mensaje en el punto de
acceso); dos bits para indicar su función en la red (Dispositivo final, repetidor o
punto de acceso); un bit para indicar de si se trata de una respuesta de
confirmación; y los 3 últimos bits son un valor que se va decrementando por
cada transmisión hasta llegar a 0, momento en el que se descarta.
TRACTID: Es un número generado por cada lado de la comunicación para añadir
robustez al protocolo.
App Payload: Es el paquete dónde reside la información importante del
sistema. Incluye un byte de petición y otro de identificación de identificación.
Dependiendo del contexto del mensaje, puede incluir un "Link Token", un
puerto Local (puerto por el que el dispositivo en escucha debe responder) y un
byte indicador del valor del contador que se decrementa por transmisión.
Este protocolo también dispone de la posibilidad de añadir una clave de seguridad a la
red que es gestionada por el punto de acceso, especificando un puerto (PORT)
concreto para tramitarla.
50
Las funciones principales que se usan en este protocolo son:
SMPL_Init (unsigned int *(linkID_t)): Inicializa el protocolo de SimpliciTI con la
modalidad del dispositivo definida y envía peticiones de conexión a la red.
Almacena en el puntero linkID_t el valor del identificador de la transacción de
conexión.
SMPL_Link(unsigned int *(linkID)): Envía una propuesta de conexión a los
dispositivos que estén en escucha en ese momento. Almacena en el puntero
linkID el valor del identificador de la transacción.
SMPL_LinkListen(unsigned int *(linkID)): Pone el dispositivo a la escucha de
peticiones de conexión.
SMPL_Send(lid, *msg, len): Envía el mensaje apuntado por el puntero msg de
longitud fijada en len al dispositivo cuyo identificador de transacción sea el
expuesto en lid.
SMPL_Receive(lid, *msg, *len): Pone el dispositivo a la escucha de mensajes
provenientes del dispositivo cuyo identificador de transacción sea el expuesto
en lid. Almacena el mensaje en la dirección msg y la longitud de éste en la
dirección len.
SMPL_Ioctl(object, action, *val): Función de configuración del dispositivo.
"Object" indica el objetivo a configurar, "action" la acción a realizar y val puede
indicar el valor a configurar o proveer de una dirección en la que almacenar un
valor en el caso de que la acción sea de lectura.
Aunque este protocolo resulte muy completo, puede resultar excesivamente complejo
para el sistema que aquí se plantea. El sistema que se busca en este documento no
requiere por el momento de un protocolo de seguridad, mensajes de confirmación de
recibimiento ni de preconexionado a una red para establecer las comunicaciones.
En este sistema no se espera disponer de sistemas que estén siempre conectados ya
que predomina la idea del bajo consumo y, al igual que una persona enciende la
televisión manualmente antes de utilizar el mando, puede optarse por un encendido
manual de los dispositivos finales.
Se puede considerar por tanto que la opción más interesante es hacer que el reloj
envíe los datos sólo cuando el usuario lo desee, suponiendo que los dispositivos finales
estén encendidos. Por ello, un protocolo de esta envergadura ralentizaría el
conexionado inicial, además de requerir más dispositivos y dificultar la programación
de los MCU.
Por lo mencionado anteriormente, se profundizará en el código del reloj (conociendo
ahora el protocolo expuesto) para modificarlo y hacer que el envío de la información
se realice sin importar el protocolo seguido.
51
3.1.2 Reloj Chronos
Este apartado se centrará en el flujo de código del programa por defecto del reloj en el
modo "ACC", funciones que utiliza y cambios realizables.
La funcionalidad de esto modo explicada en el manual de usuario indica que actúa
como un dispositivo final en el protocolo de SimpliciTI, enviando los datos del
acelerómetro y de los botones pulsado al punto de acceso. Este punto de acceso viene
de serie en el reloj montado en un formato Dongle (pequeño dispositivo conectado al
PC por USB), formado por el hardware ez-430 y el módulo RF CC430.
Suponiendo que el reloj se enciende con el programa por defecto instalado y
accedemos al modo "ACC" (pulsando el botón '#', ver figura 6d). El flujo que el
programa realiza en el momento que pulsamos 'down'(activa actual función de la línea
2) está mostrado en los esquemas siguientes según la función que se desempeñe:
Esquema 3.1: Diagrama de flujo de la Interrupción cuando pulsamos la tecla 'DOWN'
INTERRUPCIÓN
¿BOTÓN PULSADO?
¿ACTIVADO MÓDULO RF?
ACTUALIZAR VALORES DE “simpliciti_data” PARA ENVIO DE
PULSACIONES
SI
NO
SI
FIN INTERRUPCIÓN
DESHABILITAR INTERRUPCIONES
POR BOTONES
¿BOTÓN ‘*’ PULSADO?
¿BOTÓN ‘#’ PULSADO?
NO
NO
. . .¿BOTÓN ‘DOWN’
PULSADO?
ACTIVAR BANDERA DE BOTON PULSADO
ACTIVAR BUZZER
HABILITAR INTERRUPCIONES
POR BOTONES
NO
NO
52
La función principal del modo ACC que se cita en el esquema 3.2 inicializa el protocolo
de SimplicitTI para el envío de las medidas del acelerómetro.
Primero, comprueba si el nivel de la batería es demasiado pequeño, en cuyo caso no
inicia la conexión; después, desactiva el botón de iluminación; y finalmente llama a
otra función que inicia SimpliciTI en modo escritura unicamente. Esta nueva función:
Limpia la línea 1 de la pantalla
Inicializa el valor de las variables que van a ser enviadas
Actualiza la línea 1 de la pantalla
Envía un Strobe de reset al módulo RF del sistema y prepara el pin GDO para las
interrupciones que éste genere
Configura el módulo RF, inicializa el protocolo de SimpliciTI (SMPL_Init) y
procede a enviar una petición de "Link" (SMPL_Link)
Enciende e inicializa el acelerómetro en caso de que se esté en el modo ACC.
Después de esto, permanece en un bucle de envío de datos hasta que se pulse el
botón Down de nuevo, momento en el que vuelve a cerrar la radio y las
comunicaciones.
A continuación vuelve a la función main.c dónde realiza la función de "procesar
evento" y "actualizar display". La primera se muestra en el esquema 3.3 y la segunda
tan solo se encarga de actualizar los mensajes a mostrar en el display en caso de que
sean necesarios llamando a la función pertinente de cada modo.
Esquema 3.2: Diagrama de flujo de la función "Deteccion evento"
DETECCIÓN EVENTO
¿ALGÚN BOTÓN PULSADO?
¿BOTÓN ‘*’ PULSADO?
¿BOTÓN ‘#’ PULSADO?
¿BOTÓN ‘DOWN’
PULSADO?
LIMPIAR BANDERA DE BOTÓN ‘DOWN’
PULSADO
FIN DETECCIÓN EVENTO
. . .
FUNCIÓN PRINCIPAL DEL
MODO ACTUAL (ACC)
SI NO NO
SI
53
Considerando que el objetivo es obtener una alternativa para enviar los datos
directamente sin tener que inicializar el protocolo, tan solo hay que recopilar las
funciones de alto nivel que puedan realizar esta función y situarlas en el contexto
apropiado.
A raíz de lo anteriormente dicho, hay que analizar que funciones se requieren para
poder diseñar el sistema.
Para cumplir los objetivos satisfactoriamente, se requiere encontrar una función que
permita al reloj mostrar el usuario el proceso que está desempeñando, otra función
que obtenga las medidas del acelerómetro y otra función que realice el envío del
paquete.
3.1.2.1 Display
La primera de ellas debería encontrarse siguiendo la secuencia de códigos expuestos
en la función "actualizar display" ya que se encarga de actualizar la pantalla.
Esquema 3.3: Diagrama de flujo de la función "Procesar evento"
PROCESAR EVENTO
¿BANDERA DE REALIZAR MEDIDA DE
TEMPER ATUR A?
MEDIDA DE TEMPERATURA
¿BANDERA DE REALIZAR MEDIDA DE ALTITUD?
MEDIDA DE ALTITUD
BAN DERA DE REALIZAR MEDIDA DE ACELERACIÓN?
MEDIDA DE ACELERACIÓN
SI
SI
SI
NO
NO
NO
. . .
54
El código comienza comprobando actualizaciones pendientes de la línea 1 como puede
ser la hora, una nueva medida del acelerómetro... (Estas se han solicitado previamente
debido a una interrupción que ha actualizado la bandera pertinente). En el caso de que
no se haya solicitado una actualización, hace llamar a la función display de la misma
del modo en el que estamos.
Siguiendo ahora a la función de display llamada anteriormente, tabulada en la tabla
que se hizo mención en el apartado del reloj Chronos (aquella que contiene la función
principal, secundaria, display y actualización de display de cada módulo), por ejemplo
para el caso del modo aceleración (muestra por pantalla las medidas del acelerómetro
en tanto por uno respecto a la gravitacional) se puede ver la función que escribe un
carácter en el display: "display_chars(LCD_SEG_L1_2_0, (u8 *) "ERR", SEG_ON)" que
parece imprimir un mensaje de error si el acelerómetro no se ha iniciado
correctamente.
Accediendo al archivo en el que está definido esta función, encontramos el significado
de los argumentos de entrada así como numerosas funciones para mostrar caracteres
por la pantalla LCD.
Las principales funciones que se van a utilizar son:
display_chars(unsigned (8 bits) segments, unsigned (8 bits) *str, unsigned (8
bits) mode):
· El argumento 'segments' define que línea y que elementos de la pantalla se
van a modificar con caracteres tabulados. (por ejemplo: LCD_SEG_L1_3_0
indica la línea 1 y los elementos desde el 3 hasta el 0).
· El argumento '*str' es un puntero que indica la dirección dónde se almacenan
los caracteres que se quieren mostrar.
· El argumento 'mode' puede tener 3 topologías: SEG_ON, SEG_OFF o
SEG_BLINK. La primera activa los segmentos indicados con el caracter deseado,
la segunda los desactiva y la tercera los activa y desactiva alternativamente de
forma que simule un parpadeo para el usuario.
display_symbol(unsigned (8 bits) symbol, unsigned (8 bits) mode).
El argumento 'symbol' es una cadena de 8 bits que indica uno de los símbolos
presentes en la pantalla LCD. Estos están tabulados desde el 0 hasta el 42.
3.1.2.2 Acelerómetro
Las funciones de inicialización del acelerómetro se mencionó en la secuencia de código
anterior en la que se pulsaba el botón 'DOWN' en el modo ACC. Pero sigue faltando la
función que obtiene los valores del acelerómetro.
55
Si continuamos la secuencia de código que se comentó anteriormente como un bucle
de envío de datos, observamos la secuencia realizada (Esquema 3.4)
Las funciones "Despertar Radio" y "Dormir Radio" se realizan a través de la función
SMPL_Ioctl (IOCTL_OBJ_RADIO, IOCTL_ACT_AWAKE, 0) y SMPL_Ioctl
(IOCTL_OBJ_RADIO, IOCTL_ACT_SLEEP, 0) anteriormente explicada. "Enviar mensaje"
se realiza a través de una función que monta el paquete según el protocolo de
SimpliciTI, lo carga en la FIFO de escritura del módulo y envía el Strobe STX. Tras
comprobar que no se ha producido ningún error en el envío vuelve a poner el módulo
en modo Lectura (si así lo estaba antes de realizar el envío) y finaliza el envío.
En el esquema 3.4, sólo se hace una llamada a una función para obtener los datos del
acelerómetro: "simpliciti_get_ed_data_callback". Observando con detalle el interior de
Esquema 3.4: Bucle de envío de datos por SimpliciTI una vez inicializado y conectado
SIMPLICITI JOIN
SIMPLICITI LINK¿BOTÓN ‘DOWN’
PULSADO?
FIN TRANSMISIÓN
SIMPLICITI
¿BANDERA DE ENVIAR DATOS?
DESPERTAR RADIO ENVIAR MENSAJE DORMIR RADIO
FUNCION:“simpliciti_get_ed_callback()”
INICIALIZAR ACELERÓMETRO
NO
SI
SI
NO
56
esta función para el caso de modo 'ACC' con bandera de petición de medición de
acelerómetro activada:
Limpia la bandera de petición de medición de acelerómetro.
LLama a la función de obtención de las medidas del acelerómetro en los ejes
X,Y y Z y las almacena en las variables simpliciti_data[1:3].
Activa bandera de enviar datos.
Resumiendo, llamar a esta función con la bandera de medida de acelerómetro activa
supone una actualización de los parámetros de simpliciti_data[1], simpliciti_data[2] y
simpliciti_data[3] con los valores de las medidas del acelerómetro de los ejes Y, X y Z
respectivamente.
3.1.2.3 Envío del paquete por RF
Para esta última prestación y la más importante se prestará atención a la secuencia de
funcionamiento de SimpliciTI. Se recuerda que el primer paso para iniciar el protocolo
es el envío de una petición de conexión al punto de acceso, por tanto, si se consigue
localizar el punto exacto en el que se realiza el envío se puede alterar el código en este
punto para enviar lo que consideremos oportuno.
Volviendo a la función principal del modo 'ACC' hay un momento en el que llama a la
función "SMPL_Init", desentrañando esta función:
Inicializa el módulo RF y lo despierta.
Pone el módulo en modo escucha
Llama a la función que conecta el dispositivo a la red SimpliciTI.
Dentro de esta nueva función monta el paquete según el esquema de SimpliciTI para
peticiones de conexión y realiza el envío escribiéndolo directamente en la memoria
FIFO del módulo RF.
Es en este punto dónde se podría realizar cualquier modificación del paquete enviado
ya que, al no estar el protocolo inicializado, no supondría un efecto encadenado en el
sistema el falsear el paquete. El protocolo nunca se iniciará y pasará a enviar las
medidas de forma directa, justo lo que se busca.
Se pasó por alto comentar que el programa del reloj está pensado para realizar la
petición de conexión repetidas veces en caso de no recibir respuesta del punto de
acceso. El proceso consiste en: enviar petición, cambiar a modo de escucha, esperar 1
segundo y comprobar si ha llegado un paquete al módulo: Tramitarlo en caso
afirmativo ó volver al proceso inicial. Por cada bucle que se ejecuta se incrementa un
contador de forma que a llegar a 10 se abandona el intento de conexión y el sistema
actúa de igual forma que si el usuario cancelara el envío de datos.
57
Este mismo bucle también puede servir de utilidad, ya que el objetivo es no cesar de
enviar paquetes hasta que el usuario desee cancelarlo. El bucle podría retocarse para
no abandonar nunca el proceso de envío hasta que se pulse el botón 'DOWN'.
También habría que modificar la espera, que podría ser demasiado exagerada si
queremos que el seguimiento de las medidas del acelerómetro sean los más continuas
a ojos del usuario.
El resto de código encargado de tramitar los paquetes recibidos puede ser ignorado
para simplificar el código.
3.2 Módulo RF y MCU
En este apartado se hará una descripción superficial de la implementación del módulo
y el MCU en conjunto con los ejemplos propuestos como demostración.
Para esta implementación se recurrirán a las funciones implementadas por la
referencia [8] comentadas en el apartado de antecendentes.
Los 3 ejemplos compartirán la misma inicialización comentada en la referencia [8], con
la adición de un Timer más que se utilizará como temporizador-contador. Este timer
corresponde con el TA0 y será configurado igual que el otro pero para generar una
interrupción cuando su contador llegue a 0xf0 bits.
En lo respectivo a la comprobación de paquetes entrantes, el sistema se configurará
para que el pin GDO0 del módulo RF se active ante la llegada de un paquete en la
memoria, de forma que configurando el MCU para que detecte una subida de pulso
como una señal de interrupción se entenderá que el sistema accede a esta
interrupción si y sólo si hay un paquete en la memoria del módulo.
El tratamiendo bit a bit del paquete así como la interpretación de las medidas se
detallará en el apartado de Diseño.
3.2.1 Ejemplo del vehículo de juguete "Titan Tank"
En este ejemplo se propone realizar un sistema que reconozca la inclinación del reloj y
transformarlo en una variable de control que indique la velocidad y dirección del
vehículo (tanque).
58
Partiendo del reconocimiento del paquete entrante dentro de la interrupción
generada por el módulo, se continúa con la interpretación de la medida.
Hay que tener en cuenta que la medida está realizada por un acelerómetro, es decir un
sistema que mide la aceleración del mismo. En un principio se puede pensar que es
muy inexacto utilizar la medida absoluta como referencia de la inclinación (al medir la
aceleración gravitatoria) ya que el sistema seguramente no sea estático. Como
respuesta, se considera que el sistema puede despreciar las aceleraciones causadas
por el usuario ya que si el sistema se dimensiona para medir un máximo igual a la
gravedad, la aceleración que el usuario debe inducir en el sistema debe ser de un
orden similar al gravitacional, fenómeno difícil de observar.
Las medidas obtenidas directamente de la función son las mostradas en la Figura 3.3
para cada eje.
A partir de los valores arrojados por el sensor, se puede hacer una estimación de la
inclinación del sistema, por ejemplo: si la medida X arroja un valor entre 255 y 190 se
sabe que está inclinado en el sentido positivo de la aceleración gravitatoria formando
90º o menos con ella.
Y
Y Y
Y
X
Y
Z
Fig. 3.3 a): Referencia de los ejes del reloj
g
Fig. 3.3 b): Valores obtenidos según la inclinación del eje X
255 0
190
60 60
255
X
X
X
X
0
190
60 60
255
255 0
190 190
0
g
Fig. 3.3 c): Valores obtenidos según la inclinación del eje y
60 60
0
255
0
255
190 190
Z
Z
Z
Z
Fig. 3.3 d): Valores obtenidos según la inclinación del eje Z
59
Realmente, podemos controlar el vehículo con 2 grados de libertad, por lo que una de
las medidas resultaría redundante y no sería necesaria para controlarlo. En este
sistema, se utilizarán la medida del eje Y para indicar avance del vehículo y la medida
del eje X para indicar el giro de éste. Se comentará con más detalle en el apartado de
Diseño.
En lo respectivo al hardware del vehículo, se disponen de dos motores DC de 6 voltios.
La idea es poder regular la velocidad de estos según la inclinación del reloj, por ello se
recurrirá al control por PWM a través del periférico Timer_B0 para proporcionar a cada
uno de los motores una tensión aparente menor o igual a 6 voltios. Mientras menores
sean la duración de los pulsos en estado alto, menor potencia recibirán los motores y
por tanto, menor velocidad tendrán.
Aunque el control PWM pueda realizarlo el MCU, éste no es capaz de generar pulsos
con la potencia suficiente como para activar un motor, por ello se requiere de algún
sistema de potencia que, a partir de la referencia PWM genere una señal igual pero de
mayor amplitud desde una fuente de mayor potencia (Driver de los motores).
Para este fin se ha recurrido al circuito conocido como Puente H. A través de 4
interruptores digitales permite cambiar la tensión establecida a cada borne del motor,
de forma que se pueda invertir la tensión dispuesta para cambiar el sentido de giro del
motor así como regular la tensión de salida para disminuir su velocidad.
Se utilizará un puente H y 2 señales de control para cada motor. De esta forma, el
sentido de giro se definiría por la señal que este activa mientras la opuesta esté
inactiva. En caso de que ambas estuvieran activas o inactivas el motor permanecería
parado. Si una de estas señales es generada en formato PWM y la otra permanece
inactiva puede regularse la velocidad de giro en un sentido, y consiguiendo invertir los
papeles podría regularse la velocidad de giro en el sentido contrario.
La elección del integrado que realice la función de puente H se decide conforme a la
potencia que pueda manejar, que en este caso viene limitada por los motores.
Sabiendo que los motores absorben aproximadamente 200 miliamperios a 6 Voltios
basta con encontrar un integrado que soporte esa tensión y corriente. Finalmente, se
decidió por la elección del integrado L293D [11] al disponer de 4 semipuentes que
pueden ser combinados para formar 2 puentes-H.
60
3.2.2 Ejemplo de regulación de luz LED
Este caso incorpora respecto al anterior el uso de los botones en el sistema para el
control de encendido y apagado de la luz. La idea inicial es permitir al usuario tanto el
encendido y apagado completo del sistema con un botón como la regulación de la
intensidad al pulsar otro.
Al igual que en el caso anterior, se utilizará una referencia PWM para regular la tensión
de entrada al LED y así controlar su intensidad. En el caso de que se solicite su
encendido completo, tan solo hay que fijar esta referencia a su valor máximo
(quedando siempre a nivel alto) o a cero en caso contrario (referencia nula).
El control de la intensidad sólo requiere un grado de libertad y para ello se utilizará la
medida obtenida en el eje X.
En este sistema es importante considerar que no se requiere un envío constante de las
medidas del acelerómetro ni de los botones. Esta solución se plantea desde la
perspectiva energética de que un envío que no produce cambios en el sistema es un
envío inútil que supone pérdidas. Por ello, se considera que lo óptimo sería enviar un
paquete sí y sólo sí el usuario a pulsado el botón de encender/apagar luz ó desea
regular la intensidad del LED, en cuyo caso se pasaría a un modo de envío de paquetes
constantes hasta que el usuario decida cancelarlo para fijar la intensidad dispuesta.
El sistema tan sólo tendría que reconocer los botones pulsados y en caso de recibir
paquetes sin tener un botón asignado entendería que se está regulando la intensidad
del LED.
Para el control de potencia del LED se utiliza el mismo integrado que en el sistema
anterior, aunque en este caso sólo es necesario un semipuente controlado por una
señal.
3.2.3 Ejemplo de control Multimedia
A través de este sistema se propone el control sobre un sistema de audio que permita
la regulación del volumen, reanudación o parada de la reproducción y cambio de pista
a través del reloj.
En este apartado se estudiará y analizará el programa por defecto y se determinará
qué acciones habría que realizar para modificar la interfaz de control según convenga.
La primera consideración importante es que se va a utilizar dos MCUs, uno para
61
MULTIMEDIA
INICIALIZAR DSP Y LAUNCHPAD
DETECTAR GESTOS Y PULSACIONES
¿ALGUNA PULSACIÓN?
“Update_State()”REINICIAR TIMER
¿INTERRUPCIÓN TIMER?
INCREMENTAR CONTADOR.
REINICIAR TIMER
¿CONTADOR IGUAL A 4?
MODO BAJO CONSUMO.
INTERRUPCIÓN CADA 500 ms
¿ALGUNA PULSACIÓN?
SI
NO
NO
SI
NO
SI
NO
SI
Esquema 3.5: Diagrama de flujo del programa por defecto cargado en el MCU del audio boosterpack
gestionar el módulo RF y otro para el control de audio. Esto se debe a que el módulo
RF utilizaba una cantidad de pines importante que no permitiría usar, por ejemplo, los
LEDs del boosterpack, a la vez que complicaba mucho el diseño del programa.
Por todo esto, se opta por hacer dos diseños por separados que se intercomuniquen a
través de los GPIOs. El porqué de esto y su funcionamiento se expondrá más adelante.
El programa main.c por defecto del boosterpack sigue la estructura expuesta en el
esquema 3.5.
Como se observa, la lectura de las pulsaciones no se realiza a través de interrupciones,
sino que se llama a una función que comprueba las pulsaciones capacitivas en un bucle
infinito.
El sistema está pensado para funcionar en modo Low power mode, de forma que
siempre que se espera una pulsación se programa uno de los timer para activarse
62
cuando hayan pasado 15 segundos, durante los cuales el bucle infinito comprobará
constantemente alguna pulsación.
En caso de no recibir acción del usuario tras 4 interrupciones de este timer, pasará a
un modo de bajo consumo y el timer se reprogramará para sacar el MCU del modo
bajo consumo cada 500 ms y que éste compruebe las pulsaciones. En caso de que no
se detecten pulsaciones volverá a repetir este ciclo.
La detección de pulsaciones se realizaba únicamente para sacar la MCU del modo bajo
consumo y que éste llamara a la función (situada al comienzo del bucle infinito) que
determinaba que gesto se había realizado.
En el caso de que el estado del sistema fuera la elección del directorio o archivo a
reproducir tras las 4 interrupciones se procede a apagar el DSP (desactivando el pin
que tiene asignado para tal) y activar el modo de bajo consumo del MCU con
interrupción cada 500 ms para detección de pulsación. Si finalmente se abandona el
estado de inactividad, se reinicia el sistema y se enciende el DSP.
La propuesta comienza por borrar todo lo relacionado con la gestión de pulsaciones
capacitivas consiguiendo así liberar los pines del puerto 2. Serán estos, pues, los que se
utilizarán para el reconocimiento de gestos.
Antes de dividir la programación entre el encargado del módulo RF y el del audio, hay
que concretar que protocolo se utilizará para la transmisión de los distintos gestos.
Los gestos posibles se exponen en la tabla 3.1
SCROLL-RIGHT RIGHT RIGHT_HOLD RIGHTx2
SCROLL-LEFT LEFT LEFT_HOLD LEFTx2
DOWN DOWN_HOLD DOWNx2
UP UP_HOLD UPx2
MID MID_HOLD Tabla 3.1: Distintos gestos y pulsaciones posibles en el control del audio boosterpack
En este diseño se va a otorgar prioridad a los gestos y pulsaciones más relevantes de
un control multimedia, quedando la última columna descartada.
Para el resto de gestos y pulsaciones se determina la activación de unos GPIOs
específicos para cada uno.
Para los casos más simples se asignarán un pin a cada uno de ellos de forma directa, de
tal forma que la activación única del pin pertinente se entendería como ese gesto en
cuestión.
Para el reconocimiento de gestos más avanzados ("SCROLL" y "HOLD") se asignarán
dos pines cuya activación significará únicamente que se está ante uno de estos gestos.
Las asignaciones se detallan en la tabla 3.2.
63
GESTO PIN ASIGNADO (P2)
PULSACIÓN ÚNICA "SCROLL" "HOLD"
LEFT BIT4 BIT5 BIT0
RIGHT BIT3 BIT5 BIT0
UP BIT1 BIT5 BIT0
DOWN BIT2 BIT5 BIT0
MID BIT6 BIT5 BIT0 Tabla 3.2: Pines asignados a los distintos gestos
Por ejemplo: Si se quisiera transmitir el gesto "RIGHT" se activaría únicamente el pin
P2.3, pero si este gesto fuera "SCROLL_RIGHT" habría que activar los pines P2.3 y P2.5
simultáneamente.
Quedado esto acordado, solo queda analizar cada programa (MCU + módulo RF y MCU
+ módulo audio) por separado.
3.2.3.1 Microcontrolador y módulo de audio
Este sistema partirá del programa por defecto presentado, sustituyendo la detección
de gestos y pulsaciones por una función que reconozca los GPIOs comentados
anteriormente.
Lo primero es modificar la inicialización del sistema para disponer los pines del puerto
2 como entradas con una resistencia de pull-down.
Los diferentes LEDs están conectados de forma que se requiere la activación de varios
GPIOs simultáneamente para encender a cada uno, exceptuando el pin central que tan
sólo requiere la activación del pin P1.0. Por ello, se aprovecha esta ventaja para, a la
vez de reconocer la pulsación de MID, encender el LED central a modo de
realimentación de la acción. De esta forma, se configura el pin 1.0 para actuar como
entrada con una resistencia de pull-down. Esta cuestión habrá que tenerla en cuenta a
la hora de "rutar" la placa.
Otra modificación importante es borrar toda función que implique el reconocimiento
del teclado capacitivo, así como sus librerías del proyecto. Las funciones que se
utilizaban para reconocimiento de pulsación y/o de gestos se reemplazarán por una
función que en el momento de su llamada identificará el gesto pertinente y activará la
bandera de notificación de pulsación.
Lo destacable de esta función es que pueda hacer entender al sistema que se ha
reconocido una pulsación del teclado capacitivo y que reconozca el evento que ello
supone.
64
3.2.3.2 Microcontrolador y módulo RF
Este sistema se programará de forma similar a los ejemplos anteriores, pero tramitará
los paquetes recibidos del reloj para el reconocimiento de los distintos gestos.
Los gestos que se deben realizar para las distintas acciones deben ser acordes e
intuitivas al mismo (algo imprescindible en una interfaz de control). También hay que
decir que el gesto más utilizado sea probablemente "MID", ya que con él se eligen los
directorios y se paran/reanudan las reproducciones.
Se recuerda que el reloj ofrecía dos parámetros de control: el botón '#' y la
activación/desactivación de envío de medidas del acelerómetro pulsando '*'. La
pulsación del botón '#' es única por lo que solo se le podría asignar un gesto que, como
se dijo anteriormente, debería ser "MID".
Para descartar complicaciones, se va a considerar únicamente aquellos gestos
implicados en el control multimedia que sean imprescindibles. Estos son: pasar pista,
comenzar pista de nuevo, incrementar volumen, disminuir volumen, pausar/reanudar
y los necesarios para selección de directorio.
La asignación del gesto y su acción vienen expuestos en la tabla 3.3
Situación Gesto Evento
Elección de Directorio/archivo
SCROLL_RIGHT Avanzar directorio/archivo
SCROLL-LEFT Retroceder directorio/archivo
MID Acceder directorio/reproducir archivo
Pista en reproducción SCROLL_RIGHT Aumentar volumen
SCROLL-LEFT Disminuir volumen
MID Pausar/Reanudar Reproducción
LEFT Reproducir pista desde el comienzo
RIGHT Reproducir siguiente pista Tabla 3.3: Efecto de los diversos gestos
El gesto de "MID" queda resuelto por su asignación a uno de los botones del reloj, pero
el resto aún queda por determinar. Por ello, se propondrá asignar el reconocimiento
de estos gestos cuando se active el envío continuo de medidas desde el reloj.
El reconocimiento de estos gestos se realizará mediante las medidas del acelerómetro
para cada eje, de forma que si supera cierto nivel de inclinación en un sentido se
entenderá que el usuario ha inclinado el reloj con el fin de enviar el gesto pertinente.
Una vez reconocido el gesto, se activarán los pines correspondientes para notificar al
otro sistema durante un tiempo limitado por el timer.
Hay que mencionar que el tiempo en el que se mantiene a nivel alto estos pines, debe
ser los suficientemente largo para que el sistema pueda reconocerlo aún cuando
65
realice las comprobaciones cada 500 ms, y lo más breve posible para evitar un
reconocimiento repetido. Aún así, el sistema está programado por defecto para dejar
tiempo suficiente entre gesto y gesto de forma que no se realicen gestos repetidos.
3.3 Conjunto de equipos
Una vez desarrollado los ejemplos anteriores, hay que realizar algunas
consideraciones de funcionamiento de ambos equipos.
La primera de ellas va directamente relacionada con el consumo. Es importante que
una interfaz de control sea medianamente duradera por lo que habrá que intentar que
el sistema consuma lo mínimo posible. Esto supone limitar los modos de escritura del
reloj a lo mínimo imprescindible.
Por ello, el planteamiento pasa por realizar envíos únicos ante pulsación de botón y
activación/desactivación de envío continuo de datos para actualizar las medidas del
acelerómetro.
Cabe mencionar que la velocidad de envío de paquetes por defecto es muy superior a
la necesaria para un seguimiento apreciablemente continuo. Por ello, habrá que limitar
el código para efectuar los envíos de forma más limitada asegurándose también que el
MCU tenga tiempo suficiente para procesar la información.
Aunque teóricamente el envío de paquetes ante pulsación de botones sea único, esto
no suele ocurrir por culpa de que el usuario mantiene los botones pulsados por varios
recorridos de bucle de envío, llegándose a efectuar varios envíos ante una misma
pulsación. Este filtrado debe tenerse en cuenta en el diseño del procesamiento de los
paquetes ya que de lo contrario podría realizarse una acción repetidas veces.
La otra consideración a tener en cuenta es el alcance de los módulos RF. Aunque los
módulos estén diseñados para emitir hasta un alcance de 500 metros, no sería un
sistema eficiente por el consumo que supondría. Además, hay que añadir que el
módulo del reloj (por la forma en la que se dispone dentro de él) posee un alcance
muy limitado para una potencia de envío medio.
Juntando la eficiencia de los módulos RF frente a la interna del reloj a la idea de
mantener una interfaz de control de bajo consumo puede considerarse la inserción de
un repetidor de la señal del Chronos para magnificar su alcance sin incrementar su
consumo.
Esto podría plantearse como un dispositivo de muñeca externo que quede cercano al
reloj. El dispositivo podría activarse manualmente para comenzar la retransmisión de
66
forma que su consumo no supondría un gran problema y también fortalecería el
pretexto de dar prioridad a la duración de la batería del reloj frente a un dispositivo de
uso intermitente.
Además, este nuevo dispositivo no requerirá de un diseño más complejo que el de los
ejemplos propuestos ya que no poseería nada más que el MCU y un módulo RF
alimentados por una batería anexa.
Este nuevo sistema también proporciona mayor versatilidad al conjunto: podría
programarse para extraer la información que se necesita de los paquetes del reloj y
enviarla directamente al resto de módulos siguiendo otro protocolo mucho más
simplificado y modificable.
La programación de los dispositivos finales (ejemplos propuestos) debe ser
reprogramada para extraer la información únicamente del paquete que el repetidor
envía y descartar los del reloj.
También habría que considerar oportuno repetir los envíos del reloj un número
determinado de veces para cersiorarse de que el paquete llega a todos los dispositivos
y programar éstos para que una vez recibido el paquete, ignoren los consecutivos.
El consumo de los módulos según la potencia configurada de escritura se detalla en la
referencia [12].
67
4.Diseño
En este apartado se entrará en el detalle de cada paso seguido para realizar el sistema,
así como particularidades de funcionamiento.
4.1 Reloj Chronos
Tras introducir las funciones que se van a utilizar para programar la interfaz de control
se procede a introducir la secuencia de funcionamiento propuesta.
Las funciones principales del reloj, así como aquellas que no tienen que ver con el
protocolo SimpliciTI se han mantenido intactas. La propuesta consiste en hacer que el
reloj entre en un bucle constante de inicialización del protocolo pero enviando el
paquete manipulado.
El primer paso será modificar el display del modo 'ACC' a 'Projkt' en la línea 2, para ello
se entra en la función de display correspondiente al modo 'ACC' y cambiar en la
función de "display_chars" los carácteres escritos por los que se quiere cambiar. Con
esto se consigue indicar al usuario que es el modo 'Projkt' el que va a iniciar, aunque a
efectos de código es el mismo que 'ACC'.
En el siguiente punto ya entrará en consideración el arranque del modo de la Línea 2
(Pulsación de botón 'Down'), y el primer paso es actualizar el display para informar al
usuario de que el programa se ha iniciado. Para ello, se añade la función
"display_chars(línea 1)" con los caracteres "PROG" en la función de inicialización de
SimpliciTI en modo de escritura para indicar que el programa se ha iniciado.
Seguidamente, antes de entrar en la función que inicializa el hardware del módulo RF e
intenta conectarse al punto de acceso, se inicializa el acelerómetro con la función
pertinente.
Procede con la inicialización del módulo RF, configuración de parámetros y de potencia
de escritura (el cual modificaremos para insertar el valor mínimo posible). A
continuación, llama al bucle de intentos de conexión al punto de acceso. Este bucle
estaba pensado para realizar varios intentos de conexión y salir de la función si no se
conectaba o si el usuario cancelaba el intento (presionando 'Down'). Por tanto, se
suprimirán aquellos parámetros que contabilicen el número de intentos para hacerlo
ilimitado y se dejarán aquellos relacionados con el fin de la función si el usuario lo
solicita.
68
Dentro de este bucle se encontraba una espera que aseguraba que el paquete llegaba
al punto de acceso, lo tramitaba y enviaba la respuesta, para así al entrar en el modo
lectura tenerlo dentro de la memoria.
Esta espera podría suponer un problema en el nuevo código incluso si se redujera la
espera a fracciones de segundo porque toda pulsación e interrupción generada
durante éste sería ignorada, pudiendo tener como consecuencia el ignorar la petición
del usuario de cancelar envío de paquetes. Por ello, esta espera se suprime en
sustitución de una entrada al modo bajo consumo atento a interrupciones para
ralentizar un poco el código y limitar el envío de paquetes.
Cada inicio de bucle realiza una llamada a la función de inicializar el protocolo y es ahí
donde se modificará el paquete a enviar. El código restante hasta llegar al punto de
escribir el mensaje en la FIFO de escritura se mantendrá inalterado ya que contiene
inicializaciones importantes del módulo RF.
Llegado a este punto se insertará el código expuesto en el esquema 4.1
INICIO
Simpliciti_get_ed_callaback()
envio=0
¿Botón ‘Up’ pulsado y contador igual a 100?
INCREMENTAR ‘modo’ EN UNA UNIDAD
contador=0
SI ‘modo’>3modo=1
¿‘modo’ =1? ¿’modo’=2? ¿’modo’=3?
LUZ MULTIMEDIATANQUE
INCREMENTAR CONTADORSATURA EN
100
¿’envio’=0?ENVIAR
PAQUETE
FIN
SI
NO
NO NO
SISI SI
NO
SI
Esquema 4.1: Diagrama insertado en el código original del reloj
69
INICIO TANQUE
IMPRIMIR POR PANTALLA EN LÍNEA 1: Tank
‘simpliciti_data’= “XXXX 0001"
¿’simpliciti_data’=”0001 XXXX”?
MOSTRAR SÍMBOLO DE CAMPANA PARPADEANTE
DESACTIVAR SÍMBOLO DE CAMPANA
SI
NO
‘envio’=1;FIN TANQUE
Esquema 4.2: Diagrama del modo Tanque
INICIO LUZ
IMPRIMIR POR PANTALLA EN LÍNEA 1: Luz
‘simpliciti_data’= “XXXX 0002"
¿’simpliciti_data’=”0001 XXXX”?
MOSTRAR SÍMBOLO DE CRONÓMETRO
PARPADEANTE
DESACTIVAR SÍMBOLO DE
CRONÓMETRO
SI
NO
‘envio’=1;FIN LUZ
¿’simpliciti_data’!=”0000 XXXX” y ‘contador’=100?
‘envio’=1;‘contador’=0;
SI
NO
Se debe aclarar respecto al esquema anterior que el “FIN” de este diagrama está
implementado con un ‘return’ en la función original por lo que permanecerá en el
bucle superior pero no llegará a realizar el envío. Para enviar el paquete tan sólo se
deja que finalice la función como lo haría originalmente de forma que se acceda a la
función que realiza el envío.
También se buscó los valores que establecían la potencia del envío de la señal en el
archivo cabecera de la radio y se pasó a modificarlos según se expone en [12] para
minimizar el consumo.
Esquema 4.3: Diagrama del modo Luz
70
En los esquemas 4.2-3 se muestran los diagramas implementados para los distintos
modos. Hay que recordar que la función ‘simpliciti_get_ed_callback()’ almacena en los
cuatro primeros bits del carácter ‘simpliciti_data(0)’ los botones pulsados, siendo
‘simpliciti_data(0)=0001 XXXX’ equivalente a decir que se ha pulsado el botón ‘*’. De la
misma forma, en caso de que ‘simpliciti_data(0)=0000 XXXX’ se interpreta que no se ha
pulsado ningún botón.
El modo "Multimedia" es igual que el esquema 4.3 con la diferencia de mostrar otro
icono (campana parpadeante) e imprimir por pantalla "Musk".
La primera asociación del valor de simpliciti_data(0) tiene como objetivo insertar el
valor de ‘modo’ en el primer mensaje para notificar al resto de sistemas que
funcionalidad queremos manipular.
Por último, antes de realizar el envío y en el caso de que no se haya invocado el
comando “return”, se asigna el vector simpliciti_data[4] al mensaje según la estructura
del protocolo expuesto anteriormente. Este vector incluye la pulsación de botones y
modo (simpliciti_data(0)) y las medidas de los 3 ejes del acelerómetro
(simpliciti_data(1-3)).
Con todo esto queda resuelto la programación del reloj. El resultado final es que el
repetidor recibirá un paquete con la estructura del paquete de SimpliciTI con la
información de los botones pulsados y de la medida del acelerómetro de forma que
que éste pueda tramitarlo a antojo.
4.2 Repetidor
El repetidor es el sistema que se va a encargar de recibir los mensajes del reloj,
tramitarlos y reenviar los datos de interés al resto de dispositivos.
Como se dijo anteriormente, esto va a permitir prolongar la batería del reloj al ser el
dispositivo principal del sistema. La idea de uso que se quiere extender consiste en
disponer del repetidor como un sistema externo al reloj que se pueda encender y
apagar a antojo para conservar el mayor tiempo posible el nivel de batería.
El sistema del repetidor consta únicamente del módulo RF propuesto y del MCU que se
está usando en el resto del sistemas. El funcionamiento del sistema se muestra en el
esquema 4.4.
Las funciones “RfReceivePacket()” y “RfSendpacket()” se explicaron en el apartado de
análisis. El sistema está configurado para que uno de los GDO del módulo RF se active
a la llegada de un paquete haciendo saltar una interrupción del MCU.
71
En el esquema se observa que el sistema solo opera ante una interrupción causada por
la llegada de un paquete al módulo RF.
Inicialmente el sistema se configura de la misma forma que se hace el resto de los
sistemas y entra en modo de bajo consumo. Ante una interrupción causada por el
módulo RF el sistema pasa a leer la memoria FIFO de lectura de éste para detectar el
paquete entrante.
Si los 4 primeros caracteres del paquete son ‘0xff’ eso significa que es un paquete del
chronos (esto se debe a que a la hora de enviar la petición de conexión, el reloj
desconoce la dirección del punto de acceso por lo que envía una dirección genérica ‘ff
ff ff ff’). En caso afirmativo, se pasa a reconocer los caracteres dónde se guardó el
vector ‘simpliciti_data[4]’ y se almacenan en el MCU.
Debido a que los envíos del reloj se realizaban con demasiado velocidad se ha optado
por controlar esta tasa de envíos para no saturar al resto de sistema que tenían que
realizar diversas operaciones aparte de tramitar el mensaje. Por ello, ante un paquete
del chronos se procede a almacenar el vector anteriormente mencionado y enviarlos
INICIALIZACIÓN DEL SISTEMA
MODO BAJO CONSUMO
¿INTERRUPCIÓN GDO MÓDULO RF?
“RfReceivePacket()”¿PAQUETE DEL
RELOJ?
Montar paquete con los datos de
interés“RfSendPacket()”
RESETEAR MÓDULO RF
INTERRUPCIÓN
SI
NONO
SI
Esquema 4.4: Diagrama implementado del repetidor
72
cada 200 interrupciones generadas por un timer configurado para saltar cada 250 us
aproximadamente.
Otro aspecto a tener en cuenta es el reenvío de los mensajes ante pulsaciones de
botones, esto se debe a los rebotes que se producen al presionarlos. Para evitar esto
se dispuso en el reloj un temporizador que evitaba que se enviaran mensajes muy
repetidamente. Más tarde se demostró que esta medida era insuficiente, razón que se
sumó a la consideración de enviar mensajes a una frecuencia fija desde el repetidor.
Por todo esto, cuando se pulsa un botón y el repetidor recibe uno o más mensajes con
esta notificación se procede a activar una bandera de botón pulsado que guarda en un
registro que botón que se ha pulsado (igual que en 'simpliciti_data[0]’). Cuando se
activa la interrupción del temporizador se envía un mensaje con los últimos datos
recibidos más los botones pulsados y se borran las banderas pertinentes.
Tras numerosas pruebas para los diversos sistemas se detectó que ante pulsaciones
únicas de los botones sólo se enviaba un mensaje para notificarlo. Esto podría suponer
un problema en el caso de que el mensaje no llegara al dispositivo final, por ello se
consideró realizar varios envíos seguidos con la información de los botones antes de
limpiar la bandera y que fuera el dispositivo final el encargado de reconocer la
secuencia de paquetes como uno único.
Hay que recordar que el envío de los botones sólo se tramita para los casos de Luz y
multimedia cuando no se quiere regular ningún parámetro con el giro de muñeca. En
el caso de Luz sería para reconocer el encendido y apagado de ésta y en el caso de
audio para reconocer el control multimedia que no fuera el cambio de volumen. Por
ello, el dispositivo final puede reconocer si se trata de una notificación de pulsación de
botón en el caso de que el vector ‘simpliciti_data(0)>>4’ sea distinto de cero, ya que
para el resto de casos solo interesan los vectores que contienen las medidas del
acelerómetro. Para facilitar esto, en caso de envío continuo (cuando parpadea algún
símbolo en el reloj) los valores de ‘simpliciti_data(0)>>4’ se resetean en el programa
del reloj, de forma que no se reconozcan pulsaciones de botones mientras.
Para realizar lo anteriormente mencionado se utilizan dos registros a modos de
contador de interrupciones para gestionar el envío de paquetes y las pulsaciones de
botones. En el primer caso se refiere a la variable ‘t’ que se incrementa cada
interrupción del timer y se resetea cuando llega a 200. Es en ese momento cuando se
prepara el paquete para el envío (incluyendo pulsaciones de botones). La otra variable
se la denomina ‘contador’, ésta se actualiza cada interrupción, se utiliza para
contabilizar las interrupciones sucedidas desde que se recibió el último paquete del
reloj y satura en 1000. Cuando llega un paquete del Chronos el contador se resetea y
se desactivan las interrupciones “Port 1” (no recibirá interrupciones del módulo RF)
hasta que contador sea igual a 150 cuando se reactivarán, consiguiendo así atenuar la
tasa de llegadas de paquetes del reloj.
73
Éste registro permite repetir los envío del reloj cada vez que ‘t’ llega a 200 y mantiene
los valores de los botones almacenados hasta que ‘contador’ sea mayor que 500. De
esta forma, se repetirá el envío de una señal del reloj un total de 5 veces, tres de los
cuales almacenarán las señales de botones pulsados. Cada vez que se recibe un
mensaje antes que ‘contador’ llegue a 1000 se reinicia el proceso, enviando los nuevos
datos cuando ‘t’ llegue a 200.
El paquete se asigna en una cadena de 7 caracteres dónde el primero indica la longitud
del paquete (6), los 3 siguientes almacenan ‘0xff’ (similar al chronos), el quinto
almacena el estado (modo) del reloj y las pulsaciones detectadas, y los dos últimos
almacenan las medidas del ejeX y ejeY del reloj (igual que simpliciti_data(0-2)).
El sistema se configura para enviar mensajes con mucha mayor potencia que el reloj
supliendo todo el alcance que se necesita. También se propone el diseño de una placa
única para ello que sea fácilmente portable por el usuario alimentado por una pila de
botón CR2032.
4.3 Tanque
El ejemplo del tanque consiste en una estructura de plástico con forma de tanque y 2
motores DC de 6 V que controlan el giro de las ruedas de los laterales del tanque.
El sistema se diseña partiendo del reenvío de los paquetes por el repetidor siguiendo el
esquema 4.5.
Esquema 4.5: Diagrama de flujo propuesto para el ejemplo del tanque
INICIALIZACIÓN DEL SISTEMA
MODO BAJO CONSUMO
¿INTERRUPCIÓN MÓDULO RF?
¿MENSAJE DEL REPETIDOR?
OBTENER MEDIDAS DEL
ACELERÓMETRO
MODIFICAR PWM ACORDE A LAS MEDIDAS DEL
ACELERÓMETRO
RESETEAR MÓDULO RF
INTERRUPCIÓN PORT1
SI
NO
SI
NO
¿CONTADOR IGUAL A 2000?
SI
NO
INCREMENTAR CONTADOR.
SATURA EN 2000
INTERRUPCIÓN TIMER
74
El esquema anterior refleja el funcionamiento que se ha ido explicando en este
documento.
La interrupción del timer es la misma que la del apartado anterior y actualiza otra
variable ‘t’ que en este caso se dispone para limitar la modificación de los PWM que
controlan la tensión dispuesta en los motores.
Para poder administrar potencia a los motores utilizando referencias digitales en
formato PWM se utiliza dos configuraciones de puente H con la referencia de entrada
de los PWM que salen del MCU. El dispositivo que consta de esta configuración es el
L293D que posee dos puentes H internos junto a los diodos dispuestos en antiparalelo
a los Mosfets.
La alimentación de este dispositivo es de 6 V (4 pilas AA) y permite un rango de
frecuencia de conmutación de las ramas del puente H, así como una corriente máxima
suficiente para este sistema.
La configuración de puente H requiere de dos entradas como referencias digitales, una
para cada rama. Para poder invertir el sentido de giro del motor solo hay que alternar
la alimentación de éste. Por ello se sitúan resistencias de Pull-down en cada entrada
del dispositivo dejando al MCU la función de situar una rama u otra a la tensión Vcc.
Para alternar las salidas del registro comparador entre los distintos pines, se diseña el
sistema para configurar uno de los pines como entrada del MCU (de forma que el pull-
down tenga efecto) y otro como la salida del comparador. Se utilizará el registro PDIR
para gestionar los GPIOs, asignando primero ambos pines (de un puente H) como
entradas y a continuación como salida el pin de interés.
El fundamento de control del sistema se base en la obtención de dos medidas en
distintos ejes (eje X y eje Y), el primero (giro angular en el sentido del brazo) determina
el avance total del vehículo y el segundo (giro angular perpendicular al sentido del
brazo) determina la velocidad diferencial entre ambos lados del vehículo.
Para llevar a cabo esta gestión se llama a una función llamada “fijarveloc(int, int)”
cuyos argumentos de entrada son las medidas del eje X e Y respectivamente. Esta
función asigna a dos variables ‘velocidadX’ y ‘velocidadY’ un valor en función de las
medidas reconociendo un cierto margen de histéresis para evitar movimientos
caóticos cuando no se detecta una inclinación apreciable. Estas dos variables pueden
resultar negativas si el movimiento que se quiera realizar se considera inversa al
sentido de avance. Finalmente, se hace llamar a otra función
“cambioreferencias(int,int)”.
Esta nueva función asigna al registro del comparador (TA1CCR1 y TA1CCR2) el valor
que le corresponda según el valor de la variable velocidad más un valor mínimo para
75
comenzar por encima de la región muerta de tensión, y asignar el pin de salida propio
del sentido de giro.
Para este sistema se diseña una placa (expuesta en el Anexo) dónde se insertará el
MCU ya programado, el módulo RF encima de éste en formato “shield” y el integrado
L293D. Posee 3 pines para entradas de alimentación (6V, 3V y GND) y 4 pines de
salidas (2 para cada motor). Esta misma placa puede ir anclada encima del vehículo
junto a los portapilas.
4.4 Luz
El ejemplo de Luz consta del sistema planteado MCU + Módulo RF más una luz tipo LED
de 3 W controlada por un semipuente H.
Se propone el control de encendido y apagado de la luz, así como la regulación de su
intensidad con el reloj.
Para ello, se propone hacer uso del otro timer que dispone el MCU y uno de los
registros comparadores asociados a él para modular una salida PWM. Esta salida se
dispondrá para ser la referencia digital de un semipuente H que tendrá como salida el
terminal positivo del LED.
Se utilizará el mismo integrado del ejemplo del tanque (L293D) por disponibilidad,
aunque hay que reseñar que este dispositivo posee 4 entradas, 3 de las cuales no se
utilizarán en este ejemplo.
El diagrama de flujo a seguir se muestra en el esquema 4.6.
Como ya se dijo, se podrá controlar el encendido y apagado de la luz, así como regular
su intensidad. Éste último se realiza con las medidas del acelerómetro y al ser
necesario únicamente una variable, se dispondrá para que la referencia de intensidad
quede fijada por la medida del eje X.
Para evitar complicaciones, se ha considerado que la regulación sólo se realiza en el
intervalo de 0 a 90 grados (giro horario en el sentido del brazo) siendo 0 grados una
referencia nula y 90 grados la referencia máxima. Para medidas fuera de este rango, se
mantendrá la intensidad fijada anteriormente.
Se recuerda que el reloj está programado para no enviar datos de medidas a no ser
que se pulse el botón '*', momento en el que se enciende un icono parpadeante que
indica que se están realizando envíos del acelerómetro. Es en ese momento cuando se
tramitan las lecturas del acelerómetro y se regula la intensidad del LED.
Por tanto, se supondrá que si no se reconoce la pulsación del botón de encendido o
apagado de la luz se está gestionando la intensidad de éste.
76
Esquema 4.6: Diagrama de flujo del ejemplo LUZ
El diseño del circuito impreso se expone en el anexo con la misma estructura que el
ejemplo anterior en cuanto a MCU + módulo RF. A la salida del L293D se dispondrá en
serie una resistencia de 100 ohm con el LED para regular la intensidad administrada a
éste. La placa tiene como entrada 2 pines de alimentación (6 V y 3 V), un pin GND y el
LED está soldado a la misma.
4.5 Multimedia El ejemplo "Mulitmedia" consta de dos MCUs, el audio capacitive touch boosterpack y
el módulo RF.
Como se comentó en el apartado de Análisis, la implementación de este ejemplo se
realiza en dos partes, una para el módulo RF y otra para el módulo de Audio. El
primero se encargará de reconocer los gestos enviados por el usuario a través del reloj
y comunicar al otro sistema el gesto pertinente. El segundo se encargará de
reconocerlo e introducirlo en el programa original.
Se expone a continuación el diseño del sistema según el flujo de datos.
INICIALIZACIÓN DEL SISTEMA
MODO BAJO CONSUMO
¿INTERRUPCIÓN MÓDULO RF?
¿MENSAJE DEL REPETIDOR?
OBTENER MEDIDAS DEL
ACELERÓMETRO Y PULSACIONES
MODIFICAR PWM ACORDE A LAS MEDIDAS DEL
ACELERÓMETRO
RESETEAR MÓDULO RF
INTERRUPCIÓN PORT1
SI
NO
SI
NO
¿CONTADOR IGUAL A 2000?
SI
NO
INCREMENTAR CONTADOR.
SATURA EN 2000
INTERRUPCIÓN TIMER
¿PULSADO BOTÓN ‘#’?
ENCENDER/APAGAR LED
SI
NO
77
4.5.1 MCU más módulo RF
Este programa parte de la implementación ya planteada en ejemplos anteriores del
módulo RF en el sistema. A partir de ahí hace distinciones entre envío de una pulsación
única (botón '#') o envío continúo de medidas del acelerómetro. En el primer caso
activa el pin pertinente de gesto "MID" y en el segundo caso tramita las medidas para
reconocimiento del gesto realizado.
Los gestos a reconocer son: SCROLL_RIGHT, SCROLL_LEFT, LEFT,RIGHT, UP y DOWN.
El acelerómetro posee 3 ejes y resultaría bastante intuitivo reconocer un gesto con la
mera inclinación del reloj en uno de sus sentidos.
Hay que proporcionar una prioridad en la lectura de los ejes, de forma que si se
solapan dos medidas (inclinación oblicua por ejemplo) se tienda a elegir una de ellas.
Para desempeñar estas condiciones se ha programado una estructura expuesta en el
esquema 4.7.
INICIALIZACIÓN DEL SISTEMA
MODO BAJO CONSUMO
¿INTERRUPCIÓN MÓDULO RF?
¿MENSAJE DEL REPETIDOR O DEL
CHRONOS?
OBTENER MEDIDAS DEL
ACELERÓMETRO Y PULSACIONES
RESETEAR MÓDULO RF
INTERRUPCIÓN PORT1
SI
NO
SI
NO
¿CONTADOR ‘t’ IGUAL A 2000?
SI
NO
INCREMENTAR CONTADOR ‘t’ y ‘q’.‘t’ SATURA EN 2000.‘q’ SATURA EN 1000.
INTERRUPCIÓN TIMER
¿PULSADO BOTÓN ‘#’?
ACTIVAR BOTÓN ‘MID’
SI
NO
¿MEDIDA EJE X.Y O Z SUPERA MARGEN DE
SENSIBILIDAD?
NO
ACTIVAR PINES CORRESPONDIENTE
AL GESTO DETECTADO.‘q’ igual a 0
¿‘q’ IGUAL O MAYOR A 50?
P2OUT=0
SI
NO
SI
Esquema 4.7: Diagrama implementado en el microcontrolador encargado del módulo RF
78
El eje Y, que determina los "SCROLL", es el eje preferente; seguido del eje X que
determina los gestos de "LEFT" y "RIGHT"; y finalmente el eje Z, que determina los
gestos de "UP" y "DOWN".
Este orden se ha dispuesto así porque una inclinación en cualquiera de los ejes supone
una alteración de la medida en los otros dos. Por ello, para evitar un doble
reconocimiento se opta por asignar la inclinación a los ejes X e Y, y para los gestos "UP"
y "DOWN" se requiere de un movimiento brusco ascendente o descendente de la
muñeca respectivamente.
Una vez que se ha decantado por un gesto, se activan los pines del puerto 2
correspondientes al gesto (uso del registro P2OUT) y tras 50 interrupciones del timer
(misma interrupción que en los ejemplos anteriores) se desactivan todos los pines de
este puerto.
El margen de sensibilidad de la inclinación se ha determinado de forma que se ignoren
aceleraciones esporádicas (causadas por la imprecisión a la hora de mantener una
mano en suspensión) y no resulte complicado realizar el gesto.
Se recuerda que las medidas oscilaban entre [0]~[60] o [190]~[255] dependiendo de si
la aceleración es negativa o positiva, siendo [0] y [255] valores nulos de aceleración. El
margen de sensibilidad, por tanto, queda fijado a partir de 25 unidades por encima del
valor nulo. Esto se traduce en: "Hay un gesto reconocible si
(medida>25)&&(medida<230)".
4.5.2 MCU más módulo audio
Este otro programa parte del programa por defecto que la compañía deja a disposición
del público. Las modificaciones para adaptar el programa al sistema que se quiere
diseñar pasan por suprimir las lecturas capacitivas en sustitución de una función que
reconozca los pines activados por el MCU encargado del módulo RF, para así reconocer
los gestos que éste envía.
Lo primero es modificar los registros de inicialización de los pines del puerto 2 para
establecerlos todos (menos el P2.7 que se utiliza para encender el DSP) como entradas
con una resistencia de pull-down (Registros P2DIR para definir entradas, P2OUT para
definir tipo de resistencia de pull y P2REN para activarla).
También hay que recordar la decisión tomada en el apartado de análisis de fijar el pin
P1.0 como entrada para el gesto de "MID" (P1DIR&=~BIT0) y añadirle una resistencia
de pull-down (P1OUT&=~BIT0; P1REN|=BIT0;).
En este programa hay varias funciones referidas al teclado capacitivo, algunas
dedicadas a su configuración y otras dedicadas a la detección de pulsos y gestos.
79
Las funciones referidas a la configuración serán suprimidas del código y las otras serán
estudiadas para reconocer que registros hay que modificar para simular una pulsación.
La primera de ellas es "GetCapTouchInput()" que detecta los gestos y eventos.
Entrando en su código se observa que realiza un análisis de los botones pulsados del
teclado capacitivo y concluye (en caso de botón pulsado) actualizando el registro
"context.current_event" dónde almacena el gesto generado y activando una bandera
"eventFlag".
Examinando también el código de "main.c" se concluye que la bandera "eventFlag" es
la que notifica al sistema de que un nuevo evento ha tenido lugar y la que permite la
llamada a la función "Update_State()" que actualiza el estado del sistema según el
gesto almacenado en "context.current_event".
La segunda función es "TI_CAPT_Custom(&proximity_sensor, deltaCnts)" cuya llamada
se repite siempre que el MCU sale del modo bajo consumo cada 500 ms. Para este
caso, sólo se necesita determinar que registro haría entender al sistema que se ha
detectado una pulsación. Por ello, se identifica la condición que hace que se repita el
bucle "bajo consumo -> interrupción -> comprobación pulsaciones -> bajo consumo..."
mientras no se detecte pulsación: "do{bucle} while (deltaCnts[0] <= 50)".
Se puede concluir que siempre que el registro "deltaCnts[0]" sea superior a 50 el
sistema entenderá que hay una pulsación detectada y saldrá del bucle de bajo
consumo.
Resumiendo todo lo anterior, la introducción de un nuevo gesto en el sistema debe
pasar por modificar "deltaCnts[0]" para notificar de pulsación, incluir el gesto
pertinente en el registro "context.current_event" y activar la bandera "eventFlag" para
que el sistema se actualice.
Igualmente, la llamada de la función para introducción de un gesto debe ser
introducida dónde se situaban las funciones "GetCapTouchInput()" y
TI_CAPT_Custom(&proximity_sensor, deltaCnts)".
Finalmente, se declara y diseña una función llamada "Pulsaciones()" que se encarga de
introducir el gesto que el MCU del módulo RF quiera transmitir. El diagrama de flujo a
seguir se expone en el esquema 4.8.
En este esquema no se expone la actualización del registro 'deltaCnts[0]', pero se
informa al lector de que dicho registro se iguala a 60 (superior a 50) siempre que se
detecta una pulsación ('eventFlag'='1').
80
Al igual que las funciones anteriores, no existe una interrupción del puerto que haga
que se reconozca la pulsación inmediatamente después de haberse activado un pin,
sino que se realiza la comprobación muy frecuentemente. Es por ello por lo que los
pines deben permanecer activos un tiempo mínimo para asegurar su reconocimiento.
La bandera 'eventFlag' y el registro 'deltaCnts[0]' se resetean al actualizar el sistema y
al entrar en el modo bajo consumo respectivamente.
Para ofrecer cierta realimentación al usuario, en el momento en el que se detecta el
nuevo evento se activan los LEDs del teclado táctil correspondientes al gesto durante
50 ms. Así por ejemplo, para el caso de "LEFT" se activará el LED de la derecha,
mientras que para el caso "SCROLL_RIGHT" se encenderán una secuencia de LEDs que
describe este gesto.
Este temporizador de 50 ms se incluye al final de la función "Pulsaciones()" y mantiene
al sistema en modo bajo consumo hasta que salte la interrupción y prosiga con el
código. Para el caso de los "SCROLL" se realiza un bucle en el que se activa un pin
distinto por cada interrupción, siendo por tanto un total de 200 ms los que permanece
en modo bajo consumo.
Esta espera sirve a su vez para añadir cierto margen al MCU del módulo RF para que
desactive los pines del gesto y evitar así un doble reconocimiento.
Pulsaciones()
‘context.current_event=invalid_evnt’
¿PIN DE HOLD ACTIVADO?
¿PIN DE SCROLL ACTIVADO?
¿PIN DE ‘UP’ ACTIVADO?
¿PIN DE ‘LEFT’ ACTVADO?
¿PIN DE ‘RIGHT’ ACTIVADO?
PIN DE ‘DOWN’ ACTIVADO?
¿PIN DE ‘LEFT’ ACTVADO?
¿PIN DE ‘RIGHT’ ACTIVADO?
¿PIN DE ‘UP’ ACTIVADO?
¿PIN DE ‘LEFT’ ACTVADO?
¿PIN DE ‘RIGHT’ ACTIVADO?
PIN DE ‘DOWN’ ACTIVADO?
‘eventFlag=1’‘context.current_ev
ent= UP’
‘eventFlag=1’‘context.current_ev
ent= LEFT’
‘eventFlag=1’‘context.current_ev
ent= RIGHT’
‘eventFlag=1’‘context.current_ev
ent= DOWN’
‘eventFlag=1’‘context.current_event=
SCROLL_LEFT’
‘eventFlag=1’‘context.current_event=
SCROLL_RIGHT’
FIN Pulsaciones()
‘eventFlag=1’‘context.current_ev
ent= UP_HOLD’
‘eventFlag=1’‘context.current_ev
ent= LEFT_HOLD’
‘eventFlag=1’‘context.current_event= RIGHT_HOLD’
‘eventFlag=1’‘context.current_event= DOWN_HOLD’
SI
SI SI SI SI
SI SI
SI
SI SI SI SI
NO
NO
NO NO NO NO
NO NO
NO NO NO NO
Esquema 4.8: Diagrama de flujo de la función 'Pulsaciones()'
81
4.6 Conjunto equipos
Desarrollados todos los ejemplos, se dispone finalmente de un sistema gobernado por
el reloj.
El concepto total consiste en que una vez estén alimentados los dispositivos finales y
encendido el repetidor, el usuario tiene acceso a 3 módulos con funcionalidades
distintas aplicables en el entorno de la electrónica de consumo.
La selección de estos módulos se realiza mediante un pequeño menú mostrado en el
reloj y su control mediante los botones '#' y '*'.
En caso de no requerir de éste uso, tan sólo hay que desactivar el modo 'Prjkt' y apagar
el repetidor. Se consigue así una gran longevidad en términos de coste energético.
El uso de estos módulos es perfectamente compatible en paralelo, lo que permite el
uso de varios módulo simultáneos con la interfaz de control dirigida a uno en concreto.
82
83
5. Resultados
El conjunto final de los equipos es:
El reloj Chronos con un modo llamado 'Prjkt' que deja al usuario elegir entre 3
modos: 'Tank', 'Luz' y 'Musk' con diversas opciones de control.
Un repetidor que debe situarse cerca del reloj (preferentemente en el
antebrazo por comodidad).
Un tanque de juguete alimentado por 4 pilas AA y una placa sobre él.
Una placa con un LED de 3 W.
Una placa con un boosterpack y una salida jack.
El reloj se ha programado junto al repetidor para satisfacer la demanda de larga
duración de la pila del reloj. También se ha dispuesto así para ofrecer un mayor
alcance sin inconvenientes de consumo.
Para satisfacer las demandas planteadas en el apartado inicial de Análisis, sólo queda
contemplar la realimentación de las acciones. Éstas se expondrán en cada uno de los
apartados de cada ejemplo.
5.1 Tanque
El resultado de este ejemplo es la integración del reloj Chronos en el control de
elementos móviles. En este caso el control resultó bastante simple ya que solo se
requerían de 2 variables de control (medidas en eje X e Y).
El movimiento del tanque es diferencial y el control es como sigue:
Rotación del brazo en sentido de las agujas del reloj (referencia de un giro
angular en el sentido paralelo al brazo, positivo en dirección codo-muñeca)
supone una aceleración positiva del avance del tanque. Una rotación en sentido
contrario supone una aceleración negativa del avance del tanque.
Inclinación del brazo en sentido horario (referencia de un giro angular en el
sentido perpendicular al brazo, positivo desde el usuario hasta el exterior)
supone una aceleración en las ruedas izquierdas y desaceleración en las
derechas. De forma análoga ocurre con una inclinación en sentido contrario.
La realimentación de las acciones se contempla en los propios movimientos del
tanque, así como saber si se está controlando a tal mediante el icono parpadeante de
la pantalla del reloj.
84
5.2 Luz
El resultado de este ejemplo es el reconocimiento de la potencialidad del reloj como
interfaz de control en un ambiente domótico. Aunque el ejemplo se haya diseñado
alejado de un contexto de hogar, la acción de control es extrapolable a tal contexto.
El control y regulación de intensidad se realiza como sigue:
Pulsación del botón '#' supone un encendido/apagado de la luz siempre que no
se esté regulando su intensidad
En modo regulación de intensidad (haber presionado '*'), rotar el brazo en
sentido horario (referencia de sentido paralelo al brazo con dirección codo-
muñeca positiva) para regular su intensidad. Reloj paralelo al suelo
corresponde a intensidad nula y reloj perpendicular a él corresponde una
intensidad máxima. La intensidad se puede fijar pulsando de nuevo '*'.
A parte de la respuesta casi inmediata de la luz adherida a la placa se conoce si es está
en modo regulación de intensidad por el piloto parpadeante en la pantalla del reloj.
5.3 Multimedia
El resultado de este ejemplo es la adición de una interfaz de control para acciones
rápidas propias de un dispositivo de reproducción de audio. Este ejemplo se ha
diseñado para ser un complemento al control multimedia y permite diversas acciones:
Pausa o Reanudación de la pista en reproducción pulsando el botón '#'.
Avance o comienzo de nuevo de pista inclinando el brazo en sentido horario o
antihorario respectivamente.
Subir o bajar el volumen girando el brazo en sentido horario o antihorario
respectivamente.
Se permite así que el usuario pueda realizar las acciones más típicas de un reproductor
sin generar distracciones ni la necesidad de tener que acceder al dispositivo.
A parte del icono parpadeante en la pantalla del reloj cuando se está controlando el
dispositivo con el giro de muñeca, también se puede apreciar el encendido y apagado
de los LEDs coherentes al gesto en el boosterpack de audio.
85
6. Conclusiones
Este trabajo comenzó con el conocimiento del reloj Chronos y su módulo inalámbrico
interno. Luego, se le atribuyó la idea de comunicarse inalámbricamente con otros
dispositivos. Finalmente, se buscaron módulos inalámbricos compatibles y se
integraron en diversos sistemas.
Se ha partido de un equipo y a éste se le han ido añadiendo otros nuevos para
finalmente formar un sistema completo y operativo que contempla varios de los
aspectos de la electrónica de consumo.
Pero el ámbito de aplicación de la electrónica de consumo es ilimitado y difícilmente
podría uno quedarse plenamente satisfecho tras estas implementaciones. Pero con
ello se espera mostrar al lector que este trabajo podría ser, bien la base de estos
mismos ejemplos pero mejor depurados, o bien la base de nuevos proyectos más
ambiciosos.
El enfoque de este trabajo no ha sido crear un programa nuevo para el reloj, sino
únicamente modificar los aspectos que pueden interesar del ya creado para adaptarlo.
Siguiendo los análisis aquí planteados podría entenderse fácilmente el código del reloj
y hacer modificaciones más completas sin alterar el resto de funcionalidades.
6.1 Problemas encontrados
Aunque muchos de los planteamientos realizados han sido aplicados directamente a la
hora de desarrollarlos, realmente han sido productos de numerosos ensayos de
prueba y error.
El primer planteamiento realizado fue si seguir el protocolo de SimpliciTI por
simplicidad en el código del reloj, pero resultó muy difícil implementarlo en la MCU
con las librerías del módulo CC110L. Una vez implementado el módulo con el MCU y
programado a la frecuencia del reloj, se observaba que recibía los paquetes de
inicialización de SimpliciTI (aunque el contenido siempre fuera el mismo) por lo que se
optó por encontrar el momento en el que se enviaba este mensaje y modificarlo en el
programa del reloj con la información de interés. El resto de funcionalidades del
programa del reloj se fueron implementando a medida que los inconvenientes los iban
sugeriendo.
En todos los códigos de los MCUs se observa que la SCIA está programada con el
estándar UART. Esto se realizaba así para poder testear el sistema desde el PC con una
máquina virtual antes de implementar el código que gestionaba los paquetes del reloj.
86
Esto sirvió de gran utilidad en el ejemplo "Multimedia" que al poseer uno de los MCUs
con este estándar de comunicación ocupado por el boosterpack de audio resultaba
imposible "debugear" el programa o utilizar este estándar para enviar comandos. Por
ello, el testeo del programa se realizaba a través la otra MCU cuyos comandos se
enviaban por la UART y éste establecía los pines como ya se ha explicado.
La idea de implementar un repetidor de la señal se planteó inicialmente por el
exagerado consumo que presentaba el reloj para enviar una señal a un dispositivo a 1
metro de distancia (suponiendo que no había obstáculos intermedios). Su consumo era
tal que agotaba las pilas de botón en horas. Esto no podía ser tolerable en el proyecto
que se desarrolla aquí, por lo que se optó por un dispositivo que leyera la señal al estar
cerca y la retransmitiera. Estos dispositivos (módulos CC110L de Anaren) al poseer una
antena integrada pueden alcanzar mayores distancias con menos potencia. Además,
en el supuesto caso de agotar la batería de los módulos RF, esto no supondría un
problema ya que no se trataría del reloj, que se entiende como el elemento crítico en
términos de longevidad.
El último aspecto a considerar del trabajo está referido al ejemplo Multimedia.
Inicialmente se planteó realizar el sistema con un solo MCU que se comunicara con el
boosterpack de audio por la SCIA y con el boosterpack del módulo RF por la SCIB. El
primer inconveniente fue el rutado de la señal del módulo RF, que ,debido a su
disposición, ocupaba todos los pines de los LEDs del teclado capacitivo. Estos no solo
no podían ser utilizados, si no que se encenderían y apagarían caóticamente según se
usaran los pines pertinentes en la gestión del módulo CC110L.
Otro problema era la tramitación de los paquetes del módulo RF, esto se
desempeñaba a raíz de una interrupción generada por la activación de un pin de salida
del módulo. Esta interrupción sacaba al sistema del modo de bajo consumo antes de
que el timer llegara cero produciendo un comportamiento indeseado.
En adición a todo lo anterior, estaba el problema de que la gestión de la interrupción
del pin no era inmediata y recurría a numerosas esperas, que en combinación el
boosterpack de audio resultaba en que el MCU saturaba en numerosas ocasiones. Para
solucionar esto se intentó calibrar el reloj del sistema para actuar a mayor velocidad y
que el reloj asignado a las interfaces SCIA y SCIB se dividiera para ser el mismo. Aún
así, no se obtuvo mejoría del sistema.
6.2 Trabajos futuros
La primera idea a plantear sería implementar un sistema en el que el reloj no haga
únicamente envíos unidireccionales, sino que también escuchara a los dispositivos
finales y actualizara algunos datos en pantalla por ejemplo.
87
También se puede pensar que en el momento en que este sistema se clonara, habría
dos relojes que controlan los mismos equipos, y en caso de interferencias de señal
podría haber una manipulación no deseada. Este planteamiento se consideró en el
diseño del repetidor y por ello el paquete está encabezado por 3 bytes a modo de
dirección de dispositivo final. Aunque el mayor inconveniente es que estos bytes son
solo modificables por programación. Un posible trabajo futuro sería la selección de
estos bytes por medio de interruptores de varias posiciones. De forma que un reloj
tuviera una dirección concreta y todos aquellos dispositivos finales que se quieran
controlar desde el mismo deban elegir su dirección para que sea la misma.
Un trabajo muy interesante sería la combinación del acelerómetro del reloj con un
giróscopo para que (suponiendo una posición estática inicial) se pudiera estimar la
posición relativa de éste, además de su posición angular. Si a este sistema se le
atribuyera otro sistema para cálculo de posicionamiento medianamente preciso en un
ámbiente domótico, se podría plantear el control inteligente de un hogar con este
reloj. Siguiendo lo anteriormente dicho, se podría encender una luz con solo señalarla
y pulsar un botón del reloj; además de reconocimiento de gestos complejos.
En los respecto al posicionamiento, hay que añadir que los módulos RF almacenan en
un registro los valores de RSSI1 y LQI2. Ambos se utilizan para determinar la validez de
la señal, pero hay numerosos estudios que extrapolan su uso a una estimación de la
posición (usando el registro RSSI o en combinación con el LQI), por lo que podría
plantearse como otro trabajo futuro.
1 Received signal strenght indicator: Indicador de la intensidad de la señal en db.
2 link quality indicator: Indicador de la fuerza de la señal dentro de los márgenes de RSSI admisibles. El
RSSI no hace distinciones entre la señal esperada y el ruido coherente de esa frecuencia.
88
89
7. Referencias
[1]. Texas Instruments. Ez-430 Chronos [en línea] . Mayo 2014 [fecha de consulta: 23
Marzo 2014]. Disponible en: <http://processors.wiki.ti.com/index.php/EZ430-
Chronos>.
[2]. Texas Instruments. Introduction to SimpliciTi [en línea]. 2008 [fecha de consulta: 16
Abril 2014 ]. Disponible en: < http://www.ti.com/lit/ml/swru130b/swru130b.pdf>.
[3]. Texas Instruments. Mixed signal microcontroller [en línea].2014 [fecha de consulta:
2 Marzo 2014]. Disponible en: < http://www.ti.com/lit/ds/symlink/msp430g2553.pdf>.
[4]. Texas Instruments. MSP430X2XX Family: User´s guide [en línea]. Diciembre 2004
[fecha de consulta: 2 Marzo 2014]. Disponible en:
<http://www.ti.com/lit/ug/slau144j/slau144j.pdf>.
[5]. Texas Instruments. A1101R08X User´s guide [en línea]. Febrero 2012 [fecha de
consulta: 8 Abril 2014]. Disponible en:
<http://www.anaren.com/sites/default/files/user-manuals/A1101R08x_Users_
Manual.pdf>.
[6].Texas Instruments. Low-Power Sub-1GHz RF transceiver [en línea]. 2014 [fecha de
consulta: 8 Abril 2014]. Disponible en:
<http://www.ti.com/lit/ds/swrs061i/swrs061i.pdf>.
[7].Texas Instruments. Audio capacitive touch Boosterpack [en línea]. [fecha de
consulta 10 julio 2014]. Disponible en: <http://www.ti.com/tool/430boost-
c55audio1>.
[8]. Working with Anaren Boosterpack [en línea]. Abril 2012 [fecha de consulta: 18
Abril 2014]. Disponible en: <http://msuraj.wordpress.com/author/msuraj/>.
[9].Briandm82. Ti MSP430 Launchpad [en línea]. [fecha de consulta: 10 Mayo 2014].
Disponible en: <http://briandm82.com/ti-msp430-launchpad/>.
[9]. Texas Instruments. C500 Ultra Low power DSP audio capacitive touch boosterpack
[en línea]. 2012 [fecha de consulta: 13 Julio 2014]. Disponibel en:
<http://www.ti.com/lit/ml/sprt630/sprt630.pdf>.
[10]. Texas Instruments. SimpliciTI: Simple Modular RF Network Specification [en línea].
2007 [fecha de consulta: 17 Abril 2014]. Última actualización: 24/03/2009. Disponible
en: <http://vip.gatech.edu/wiki/images/a/ad/SimpliciTI+Specification.pdf>.
90
[11]. Texas Instruments. Quadruple Half-H Drivers [en línea]. Septiembre 1986 [fecha
de consulta: 17 Marzo 2014]. Disponible en:
<http://www.ti.com/lit/ds/symlink/l293d.pdf>.
[12]. Charlotte Seem. Design Note DN012 [en línea]. 2007 [fecha de consulta: 19 Junio
2013]. Disponible en: <http://www.ti.com/lit/an/swra150a/swra150a.pdf>.