Capitulo 3: Resultados: IAU Preindustrial.bibing.us.es/proyectos/abreproy/40034/fichero/Capitulos... · Capítulo 3 Resultados: IAU preindustrial. José Gustavo Jiménez Pérez 45

Capítulo 3 Resultados: IAU preindustrial.

José Gustavo Jiménez Pérez 43

Capitulo 3: Resultados: IAU Preindustrial.

3.1. Requisitos de la IAU preindustrial.

El detector de caídas implementado para el laboratorio ha permitido

comprobar la viabilidad de detectar caídas por medio de un sistema de

acelerometría según la arquitectura seguida, basada en un procesamiento

distribuido que en cierto modo mimetiza la forma en la que actúan los sistemas

sensores humanos.

Sin embargo esta unidad no es viable para su producción industrial,

principalmente debido a su tamaño aunque también otros factores como el

hecho de mejorar la sistemática para la decodificación de las señales de

acelerometría, eliminar los errores en la señal que introduce las vibraciones

estructurales por la necesidad de usar dos sensores acelerómetros unidos

perpendicularmente, adoptar la última tecnología en componentes, etc. nos



indica la necesidad de desarrollar, en base a este prototipo de laboratorio, otro

que sea industrialmente factible.

De esta forma la intención es implementar la IAU como un pequeño

parche impermeable que podrá ser fijado en la espalda del paciente,

aproximadamente a la altura del sacro. Esto mejoraría la portabilidad del

dispositivo ya que permite su uso 24 horas, es decir, incluso cuado se está

tomando una ducha, momento en el cual los dispositivos colocados en

cinturones se deben quitar.

Para ello, con respecto al prototipo anterior, se han realizado una serie

de modificaciones, cambiando, tanto componentes hardware como el software

embebido necesario para operar, así como los protocolos de comunicación

entre los distintos entes del sistema.

3.2. Elección de nuevos componentes.

A partir de los requisitos del sistema que imponen que funciones debe

realizar la IAU, y tras un estudio exhaustivo del mercado de componentes

electrónicos se ha decidido cambiar tanto el acelerómetro como el

microcontrolador. Otro cambio, en la IAU que aunque queda fuera de este

proyecto, sin embargo, es necesario comentar, es el transceptor elegido para

las comunicaciones con el PSE.

A continuación se analizarán los componentes seleccionados basándose

en las características nuevas que estos incorporan en relación con la

arquitectura anterior.

3.2.1. Elección del acelerómetro.

Sin duda el dispositivo clave en el desarrollo de este sistema es el

sensor de acelerometría ya que es crítico que este se adapte bien a la

aplicación, en parámetros como el ancho de banda, la amplitud, etc. Además la

elección del acelerómetro será la que guíe la elección del otro componente

esencial en el desarrollo de este proyecto, el microcontrolador.



El acelerómetro que se ha usado para el montaje y prueba del prototipo

de la IAU de laboratorio fue el ADXL202 de Analog Devices. Este es un

acelerómetro capacitivo de dos ejes, por lo que se han tenido que usar dos

acelerómetros para poder medir aceleraciones en los tres ejes de interés:

medio-lateral, vertical y antero-posterior. Aunque como se observa en los

diversos artículos realmente se ha utilizado la medida en los cuatro ejes.

Este dispositivo proporciona una salida de datos digital codificada en

PWM.

Es un acelerómetro con buena relación prestaciones-precio. Es de bajo

consumo (admite alimentación a 3V), bajo coste y posee un filtro configurable

mediante dos capacidades, por lo que podemos reducir el valor eficaz de la

tensión de ruido. Permite la función de autotest y autosleep a través de un pin

del microcontrolador, no requiere señal de reloj externa pero sí un calibrado

inicial.

Tras analizar las características surgen varias preguntas. ¿Por qué

cambiar de acelerómetro? ¿Qué le debemos exigir?

En primer lugar se debe decir que el ADXL202 se encuentra, en la fecha

de realización de este proyecto, en Phase-Out, es decir, se está dejando de

fabricar por lo que no tiene sentido seguir con un dispositivo que estará

obsoleto en breve.

Por otro lado sería interesante examinar la posibilidad de migrar hacia un

acelerómetro triaxial en lugar de los dos biaxiales que se estaban usando, lo

que mejoraría el comportamiento estructural de la IAU, eliminándose ruido

debido a vibraciones entre componentes. Esto es posible gracias a los avances

tecnológicos que los MEMS están sufriendo en los últimos años y que permiten

encontrar en el mercado este tipo de sensores con tales características.

Por otro lado la interfase de comunicación que proporciona, la

codificación de la señal en PWM, generaba cierto ruido en las señales

adquiridas debido al proceso de decodificación de estas en el microcontrolador

utilizado en la IAU que podría ser solucionado con un acelerómetro que

proporcionara una salida completamente digital.



También sería posible optar por un acelerómetro con salida analógica,

pero hay que tener en cuenta para ello que el microcontrolador elegido debería

estar dotado de convertidores Analógico/Digital, además de la carga en

software que supondría la conversión, así como la precisión que se podría

alcanzar.

Otro motivo que nos indica la conveniencia de cambiar de acelerómetro

es por cuestión de tamaño.

En el prototipo de la IAU existente, como ya se ha comentado, se usaron

dos acelerómetros, dispuestos en la placa en dos planos diferentes. De esta

forma, el tamaño no sólo no es óptimo, sino que además esta configuración no

es la más idónea, por su aparatosidad, para una futura IAU más compacta y

real.

Los criterios básicos a tener en cuenta para la elección del nuevo

acelerómetro serán: Bajo consumo, bajo coste, buenas prestaciones en cuanto

a sensibilidad y rango de g, tamaño reducido y que sea triaxial.

En cuanto al rango dinámico del acelerómetro puede ser suficiente,

teniendo en cuenta que el dispositivo está inicialmente diseñado para ser

empleado por personas mayores, con que pudiera variar entre ±2g. No

obstante, queda abierta la posibilidad de que el detector de caídas que

diseñásemos tenga el rango más amplio y programable y sea igualmente válido

en otras situaciones y entornos, como pudiera ser por ejemplo en el mundo de

deportistas profesionales, o simplemente que el personal médico, según su

criterio decida asignar un rango determinado de g a un determinado paciente.

En lo que respecta a la sensibilidad, está vendrá dada en mV/g para

acelerómetros analógicos, en %/g para acelerómetros digitales con señales

PWM y en mg/g para acelerómetros digitales sin salida PWM. Por tanto, para

poder comparar la sensibilidad de los diferentes acelerómetros que hemos

encontrado tenemos dos posibilidades:

• Comparar analógicos con analógicos y digitales con digitales entre sí.

• Comparar la resolución que dan los acelerómetros digitales con la

resolución que tendríamos a la salida del CA/D en el



microprocesador, para un acelerómetro digital. En este caso

tendríamos que tener en cuenta varias cosas:

- El rango de tensiones que daría a la salida el acelerómetro

analógico (esto dependerá de la sensibilidad y rango de g en

el que puede operar).

- Las tensiones de referencia que puede usar el CA/D del

microcontrolador. Cómo configurar y evaluar las diferentes

alternativas o soluciones para optimizar la conversión.

- El número de bits del CA/D que, junto con el rango de

tensiones de referencia del CA/D, nos dará la resolución final

(digital) a la salida del CA/D.

Por todo esto se intentará encontrar un acelerómetro triaxial con

prestaciones adecuadas de acuerdo a las especificaciones requeridas.

Otros puntos que se han tenido en cuenta a la hora de elegir el

acelerómetro son:

Densidad de ruido: Cuando hablamos de densidad de ruido nos

referimos al umbral de ruido por debajo del cual el acelerómetro es capaz de

funcionar con las características de sensibilidad y resolución garantizadas por

el fabricante.

Alimentación: Si bien en el prototipo anterior de la IAU la alimentación

era de 6V, para este nuevo diseño se pretende usar una tensión de

alimentación ≤3V. A la hora de elegir el nuevo acelerómetro y microcontrolador

es importante tener en cuenta esto, porque no todos los dispositivos soportan

un funcionamiento a esta alimentación.

Tamaño y Encapsulado: Ya que el siguiente prototipo de la IAU que se

va a realizar va a ser un montaje preindustrial en el que se pretenden optimizar

el hardware y el software, vamos a intentar hacer un esquema más compacto

en lo que a tamaño se refiere. Será interesante que los componentes que

usemos dispongan de una versión en montaje superficial Chip-Scale-Package.

Coste: Es indispensable que nuestro dispositivo, por su aplicación y

funcionalidad, sea de bajo coste. El coste es junto al consumo un criterio a



minimizar siempre en nuestro detector de caídas. No tiene sentido que el precio

del parche-IAU esté fuera del alcance de los usuarios.

Los productos analizados para encontrar el acelerómetro que mejor se

adapte a nuestra aplicación, son los correspondientes a los siguientes

fabricantes, Analog Devices, Freescale Semiconductor (Motorota), Kionix, y ST

Microelectronics.

En la Tabla I, II y III podemos ver las características y prestaciones de

cada uno, de acuerdo a los parámetros que se han fijado como criterio. En

color amarillo se resaltan los valores interesantes de los parámetros a tener en

cuenta.

En cuanto al precio, la tabla III muestra los precios para tiradas de

10.000 unidades ya que se considera que este puede ser un numero adecuado

de unidades a adquirir a nivel de producción. Aunque estas cantidades están

fuera de lugar en esta fase de desarrollo de un segundo prototipo de la IAU, es

una forma adecuada de compararlos entre sí de forma que se pueda tener una

idea de cuales serán los más caros para una producción industrial.

Por último comentar que el acelerómetro ADXL330 de Analog Devices

está en proceso de prueba previo a su lanzamiento al mercado, por lo que el

precio que aparece en la Tabla es orientativo ya que aún se desconoce.

Tabla I: Características eléctricas de los acelerómetros del mercado.

Vdd (V) Idd (mA) (ON)

Densidad de ruido

Hzgµ Sensibilidad Salida

ADXL202 (AD) 3 - 5.25 0.6 – 1 200 167mV/g 11%/g

Digital PWM

ADXL330 (AD) 2 - 3.6 0.32 170 (X,Y) - 350 (Z) 300mV/g Analógica

LIS3L02AL (ST) 2.4 - 3.6 0.85 – 1.5 50 660mV/g Analógica

LIS3L06AL (ST) 2.4 - 3.6 0.95 – 1.5 50 660/220mV/g Analógica

LIS3L02AQ3 (ST) 2.4 - 3.6 0.85 – 1.5 50 660/220mV/g Analógica



LIS3LV02DQ (ST) 2.16 - 3.6 0.65 – 0.80 ¿ 0.97/2.94mg Digital

12/16 bits

KXP74 (Kionix) 2.7 - 5.25 0.8 175 1.25mg Digital

12 bits

KXP84 (Kionix) 2.7 - 5.25 1 175 - 250 1.22mg Digital

12 bits

KXPA4 (Kionix) 2.7 - 5.25 1.1 175 560mV/g Analógica

MUX3

MMA7260Q (Freescale) 2.2 - 3.6 0.5 – 0.8 350 800/600/300

200mV/g Analógica

Tabla II: Características mecánicas de los acelerómetros del mercado.

Nº ejes

Rango Dinámico Ancho de Banda (Hz) Tamaño (mm)

ADXL202 (AD) 2 2g 6000 5 x 5 x 2 LCC-8

ADXL330 (AD) 3 2g X,Y: 1600 Z: 555

4x4x1.45 LFCSP-16

LIS3L02AL (ST) 3 2g 1500 5 x 5 x 1.6

LGA-8

LIS3L06AL (ST) 3 2g/6g

Programable 1500 5 x 5 x 1.6 LGA-9

LIS3L02AQ3 (ST) 3 2g/6g

Programable 1500 7 x 7 x 1.8 QFN-44

LIS3LV02DQ (ST) 3 2g/6g

Programable Configurable

10, 40, 160, 640 7 x 7 x 1.8 QFN-28

KXP74 (Kionix) 3 1.5g/6g

Fabrica X, Y: 3300

Z: 1700 5 x 5 x 1.2 DFN-14

KXP84 (Kionix) 3 1.5g/6g

Fabrica X, Y: 3300

Z: 1700 5 x 5 x 1.2 DFN-14

KXPA4 (Kionix) 3 1.5g/6g

Fabrica X, Y: 3300

Z: 1700 5 x 5 x 1.2 DFN-14

MMA7260Q (Freescale) 3 1.5g/2g/4g/6g

Programable X, Y: 350

Z: 150 6 x 6 x 1.45

QFN-16

.



Tabla III: Características de valor añadido de los acelerómetros del mercado.

Modo

Power-Down

Calibrado de

fabrica Selftest Precio ($)

(10000u)

ADXL202 (AD) No No Si 8.50

ADXL330 (AD) No No Si ~ 2

LIS3L02AL (ST) No Si Si 4.25

LIS3L06AL (ST) No Si Si 4.65

LIS3L02AQ3 (ST) Si Si Si 13.27

LIS3LV02DQ (ST) Si Si Si 5.35

KXP74 (Kionix) Si Si Si 7

KXP84 (Kionix) Si Si Si ¿

KXPA4 (Kionix) Si Si Si ¿

MMA7260Q (Freescale) Si No No 5.67

3.2.2. Acelerómetros candidatos

Existen varios criterios a la hora de decantarse por un acelerómetro

dentro de todos los que aparecen en las tablas anteriores. Realmente en todos

se podrían encontrar que determinados parámetros son óptimos, por ejemplo:

el ADXL330 es muy interesante desde el punto de vista de tamaño, consumo y

precio (es el más pequeño y el de menor consumo), el MMA7260Q posee

mayor diversidad de opciones de configuración, etc.

Sin duda, dos parámetros muy importantes para la elección del

acelerómetro son el tamaño y el consumo, sin embargo, hay otras opciones

como la posibilidad de configuración del rango dinámico y el ancho de banda



que nos permitiría hacer un sistemas más flexible, de forma que podamos

cumplir un requisito fundamental como la adaptación del sistema al contexto, o

la posibilidad de tener una salida digital que promocionaría un menor error así

como facilitaría la implementación del software. Además para la conversión

analógico-digital es necesario activar en el microcontrolador el modulo CAD,

que produce un aumento del consumo así como la necesidad de tener una

referencia de tensión que implicaría la incorporación de un conjunto de

componentes adicionales que repercutiría en el incremento del tamaño final.

En cuanto a la posibilidad de cambiar el rango dinámico encontramos en

la tabla II, el LIS3L02AQ3 y el LIS3LV02DQ [29] de ST Microelectronics así

como el MMA7260Q de Freescale Semiconductors.

Todas las características de estos se encuentran en los

correspondientes Datasheet.

De estos tres el único con salida digital es el LIS3LV02DQ [29].

Debemos notar que aunque su tamaño es mayor que los otros este solo

necesita 2 condensadores adicionales mientras que por ejemplo el MMA7260Q

necesitaría 4 condensadores y 3 resistencias con lo que el espacio real

ocupado en placa aumentaría considerablemente para este último.

3.2.3. Acelerómetro elegido

Una vez analizadas las características de forma más exhaustiva, la

elección ha sido el LIS3LV02DQ [29]. Principalmente esta elección se ha hecho

en base a la interfase digital y las posibilidades de configuración además de las

características de valor añadido que presenta que, como se vera en próximos

apartados, permitirá simplificar en cierto modo el diseño del software.

También la relación prestaciones/precio ha jugado un importante papel,

ya que aunque no es el de coste más bajo, sin embargo, el aumento con

respecto a los otros es asumible gracias a las mejoras que incorpora.

La interfase digital se presenta como una mejora considerable ya que se

evita el proceso de decodificación de la señal de aceleración que se muestra

en [28] mejorando la eficiencia y fiabilidad del sistema. En comparación con los



acelerómetros analógicos ya no es necesaria la elección de un

microcontrolador con conversor analógico digital.

En principio, se continuará con el formato de datos establecido en el

prototipo de laboratorio, es decir, se operará con datos de 8 bit en

complemento a dos, en punto fijo. El acelerómetro elegido es capaz de

proporcionar datos de 16 bits en complemento a dos. Estos datos serán

truncados para adaptarlos al formato con el que se va a trabajar.

3.2.4 Elección del microcontrolador.

El microcontrolador usado en el prototipo de laboratorio de la IAU es el

PIC16LC66 de Microchip. Este microcontrolador pertenece a la arquitectura

media (PIC16XXXX) de microcontroladores PIC de Microchip. LC indica que

pertenece a una subfamilia que tienen memoria EPROM y trabajan en un rango

extendido de tensiones. El PIC16LC66 permite el uso de interrupciones,

presenta un abanico amplio de posibilidades bastante versátil y el precio en

cantidades pequeñas puede oscilar entre 5US$ y 15US$ aproximadamente. Un

inconveniente en esta arquitectura es que han eliminado dispositivos que

combinen una EEPROM embebida para datos con memoria no volátil para el

código: ROM o EPROM. Esto supone un inconveniente, ya que, en nuestra

aplicación será necesario almacenar datos de configuración de los elementos

clientes de la WPAN, tales como el identificativo de la WPAN, identificativo del

cliente dentro de la WPAN, datos de calibración del sensor, etc. Esto fue

solucionado con una EEPROM externa.

Para satisfacer los requerimientos que se necesitan, se acudió a un

modelo de tensión extendida: PIC16LXXX. En estos se garantiza su

alimentación con tensiones de 3V o mayores. El consumo es menor de 2mA a

5V, lo que permite trabajar con valores medios inferiores a 0.2mA, aprovechado

el modo SLEEP del micro.

El microcontrolador PIC16LC66 proporciona 8K de memoria EPROM

para código y 368 bytes de RAM. Por razones económicas se optó por un

micro con memoria OTP en lugar de ROM. Esta es una memoria no volátil, de



sólo lectura y programable una sola vez por el usuario. La versión OTP es

recomendable cuando es muy corto el ciclo de diseño del producto, o bien, en

la construcción de prototipos y series muy pequeñas.

¿Por qué cambiar de microcontrolador?

Haciendo un análisis de los resultados obtenidos del prototipo anterior

de la IAU con el PIC16LC66, en estos se evidencian posibles carencias en la

decodificación de las señales PWM proporcionadas por el acelerómetro.

Aunque es cierto que la decodificación fue implementada completamente en

software y que podría mejorar si se empleara el hardware específico para tal

fin, es decir, se emplearan los módulos CCP del microcontrolador, sin embargo,

el cambio al nuevo acelerómetro nos obliga a plantearnos otras posibilidades.

Otras características que se considera necesario mejorar sobre el

microcontrolador del prototipo de laboratorio es el tipo de memoria de

programa, ya que tanto para el prototipado como para la fabricación en serie

del dispositivo la opción de usar microcontroladores con memoria flash es más

interesante.

Aunque en el análisis de los distinto microcontroladores que se ha

realizado, se incluyen también algunos con memoria OTP, sin embargo, la

elección a priori que se ha elegido es usar un microcontrolador con memoria

FLASH lo que permitiría grabarlo en laboratorio y además se podría borrar

eléctricamente cuando fuese necesario, de esta forma permitiría una mayor

comodidad en cuanto a optimización del software y modificación de los

algoritmos de detección de caídas, y no haría necesario el uso de una

EEPROM externa con la consiguiente reducción de espacio en placa.

También sería interesante que el nuevo microcontrolador tuviera algo

más de memoria de programa.

Antes de analizar los distintos microcontroladores que se presentan en el

mercado y elegir el más adecuado se van a exponer los requisitos básicos que

deberían tener para ser útiles para nuestra aplicación.

El microcontrolador debe ser capaz de comunicarse con el acelerómetro

elegido, por lo que debe incorporar una interfase I2C o SPI. También es

interesante, cara a la comunicación con otros dispositivos como por ejemplo el



transceptor Zigbee, que como se verá más adelante es la tecnología elegida

para implementar las comunicaciones, que contenga una interfase USART.

Debido a que la aplicación es un sistema portable y embebido, es

conveniente que su consumo y tamaño sea pequeño. En cuanto al consumo es

necesario que incorpore un modo SLEEP de forma que el micro quede en un

estado de bajo consumo cuando no se requiera su operación.

Por otro lado, el hecho de que esta aplicación está dirigida básicamente

hacia las personas mayores hace necesario que el microcontrolador sea de

bajo coste.

La posibilidad del uso de microprocesadores de bajo coste también

podría ser interesante, sin embargo, estos no suelen incluir periféricos de

comunicaciones ni memoria, ya que por lo general exponen al exterior los

buses para estos fines y se requeriría un hardware adicional que ocuparía

espacio en placa, además del posible incremento del consumo.

En nuestra aplicación no requerimos, inicialmente, de una gran potencia

de cálculo con lo que la ALU puede ser simple, ya que el micro principalmente

se va a encargar de la gestión de la comunicación controlando la transferencia

de tramas entre los diversos dispositivos de la IAU así como entre la IAU y el

PSE. No obstante la potencia debe ser suficiente para poder realizar un

pequeño preprocesado de la señal ejecutando el algoritmo de detección de

impacto, así como para incluir diversos filtros.

En cuanto a los elementos usados para la aplicación es importante el

cumplimiento de la directiva RoHS (“Residuos de aparatos eléctricos y

electrónicos”) ya que en pocos años no se podrán fabricar aparatos de estas

características que no la cumplan.

En la tabla IV se muestran diferentes alternativas, todos los micros son

PICs de Microchip con arquitectura de 8 bits, con CA/D y un tamaño de

memoria de programa no inferior a la que ya teníamos (8KBytes). En primer

lugar se ha colocado el empleado en el prototipo de laboratorio, el PIC16LC66,

a modo comparativo.



El estudio se ha centrado en los dispositivos PIC de Microchips ya que

se ha considerado que ofrecen la mejor relación prestaciones-precio del

mercado.

Debemos notar que pese a que hemos elegido un acelerómetro con

interfase digital sin embargo todos los micros examinados poseen CA/D lo cual

es debido, en primer lugar a la posibilidad de migrar a un acelerómetro

analógico si fuera necesario y en segundo lugar a que los microcontroladores

que proporcionan las prestaciones que requerimos incluyen también este

periférico.

Tabla IV: Características básicas de los Microcontroladores

Memoria

de Programa

Kbytes EEPROMBytes

RAM Bytes I/O Precio

$

PIC16LC66 OPT 8 - 368 22 3

PIC16C745 OTP 14 - 256 22 2.54

PIC16C926 OTP 14 - 336 52 4.02

PIC18C658 OTP 32 - 1536 52 7.45

PIC16F76 FLASH 14.3 - 368 22 3.26

PIC16F777 FLASH 14 - 368 33 3.59

PIC16F876A FLASH 14 256 368 22 3.40

PIC18F2320 FLASH 8 256 512 25 3.82

PIC18F2331 FLASH 8 256 768 24 4.12

PIC18F2431 FLASH 16 256 768 24 3.63

PIC18F4331 FLASH 8 256 768 36 4.52



Examinando la tabla podemos comprobar que el microcontrolador que

mejor se aproxima a las necesidades y por lo tanto es el elegido para el

desarrollo de la aplicación es el PIC18F2431 [30] cuyas características se

discuten en el siguiente punto.

Si es necesario aclarar aquí algunos aspectos de porque esto es así. En

primer lugar como ya se avanzo, se ha descartado la elección de

microcontroladores OTP. En cuanto a la memoria de programa el elegido

presenta una mayor capacidad. Otro punto que indica la elección de este, es

que tiene 256 Bytes de memoria EEPROM, que nos puede ser muy útil para

salvaguardar ciertos datos y que nos permite eliminar la EEPROM externa del

prototipo de laboratorio con el consiguiente ahorro en tamaño y consumo. Es

cierto que existen 4 micros en la tabla que comparten estas características pero

de ellos solo 3 tienen una memoria RAM de 768 Bytes que sin duda será muy

necesaria para el desarrollo de la aplicación. Por último, de estos tres el

PIC18F2431 [30] es el de menor precio siendo este también un punto decisivo

para tomar la decisión. Si observamos el PIC18F4331 mejora las prestaciones,

sin embargo, en el caso de nuestra aplicación, esta mejora no es necesaria y

encarecería algo más el coste del dispositivo final.

3.2.5. Estudio del microcontrolador: PIC18F2431.

En este punto se hará una breve introducción al PIC18F2431 [30],

atendiendo a aquellas características que resultan interesantes desde el punto

de vista de la aplicación. Para un conocimiento más amplio se debe acudir al

datasheet del componente.

El PIC18F2431 [30] es un microcontrolador basado en memoria Flash.

Posee un juego de instrucciones de 75 (en vez de las 35 que poseía el

PIC16C66) la mayoría de las cuales tienen un tamaño de 2 Bytes (1 palabra de

la memoria de programa) aunque hay también instrucciones que ocupan 2

palabras (lo que deberá ser tenido en cuenta a la hora del calculo de ocupación

de la memoria de programa).



3.2.5.1. Memoria Flash y EEPROM

La memoria de programa es de 16 KBytes, sin embargo, debido al

tamaño de cada instrucción podemos establecer que para almacenar el

programa contamos con menos de 8 KBytes.

Otra ventaja interesante es que la memoria de programa, puede ser

utilizada también para almacenamiento de datos, para lo cual el

microcontrolador incorpora una serie de instrucciones para manejo de tablas

sobre a memoria de programa. Esto puede ser útil, entre otras cosas, para

almacenar en la memoria de programa datos de forma no volátil como

complemento a la EEPROM.

Analizando el uso de la memoria Flash más detenidamente se llega a la

conclusión de que esta debe ser usada para almacenar datos de solo lectura o

que solo varíen en casos muy concretos, ya que aunque el microcontrolador

usado da facilidades para el empleo de esta memoria durante la ejecución del

programa, estas básicamente implican la posibilidad de leer tablas como si se

trataran de datos en ROM. Por otro lado el borrado y escritura implican que la

ejecución de código se detenga durante ciertos periodos de tiempo.

Como alternativa, el microcontrolador posee también una memoria

EEPROM de 256 bytes que permiten salvaguardar los datos críticos durante la

ejecución normal del código.

Aspectos importantes a resaltar en este punto son:

- La escritura de un byte borra automáticamente la posición

indicada, lo que descarga al software de realizar esta

operación.

- La escritura está controlada por un timer on-chip.

La memoria EEPROM será utilizada para la salvaguarda de datos, como

los umbrales requeridos por el algoritmo, que serán actualizados para adaptar

el sistema al contexto cada vez que el PSE lo decida, o datos en caso de fallo

crítico, en cuyo caso es conveniente inhabilitar las interrupciones durante la

ejecución del código de salvaguarda.



3.2.5.2. Memoria de datos

En lo que respecta a la memoria de datos, esta consta de 768 Bytes,

dividida en 3 bancos de 256 Bytes cada uno como registros de carácter general

y de 159 Bytes como registros de carácter especial. Además posee un modo

de acceso a memoria muy rápido denominado Acces Banck, en donde el

microcontrolador, trabajando solo sobre el banco 0, tiene acceso a un conjunto

de variables y a los registros del sistema sin tener que cambiar de banco.

Este microcontrolador también incorpora instrucciones para el manejo de

una pila creada por el usuario, así como la pila del sistema. Esto nos permitirá

una mejora en la forma de atender a las interrupciones y subrutinas.

3.2.5.3. Velocidad de operación

Atendiendo a continuación a la velocidad de operación del micro, en la

versión anterior del hardware de la IAU se tomo un reloj de 4MHz, si en este

caso tomamos la misma velocidad de reloj, los tiempos que tardarían la

ejecución de cada instrucción serían de:

- Instrucción normal: 1µs

- Instrucción simple de bifurcación: 2µs

- Instrucción doble de bifurcación: 3µs.

3.2.5.4. Consumo

Sin duda, uno de los aspectos principales de la aplicación es la

reducción del consumo.

El microcontrolador PIC18F2431 [30] presenta un conjunto de

características que son muy interesantes en relación con el consumo del

dispositivo.

En primer lugar, el dispositivo presenta un rango de tensiones extendido,

por lo que puede ser alimentado en un rango de 2 a 5,5V, lo que permite en



primer lugar reducir el consumo bajando la tensión de alimentación y segundo

da compatibilidad de alimentación con el acelerómetro.

Por otro lado, la estrategia básica que incorpora este micro para la

reducción del consumos se basa en habilitar diversos modos de operación,

permitiendo la desconexión total del sistema (modo SLEEP clásico) u otros

modos de operación que permiten realizar ciertas funciones desconectando del

reloj principal solo una parte del sistema (el núcleo y/o los periféricos),

haciéndolos operar a frecuencias menores y por lo tanto con un menor

consumo.

3.2.5.5. Programar el PIC18F2431

De acuerdo con las especificaciones de Microchip existen dos modos

para la programación de microcontroladores FLASH de la familia PIC18FXX31

seleccionables a través del bit LVP: programación serie en circuito (ICSP In-

Circuit Serial Programming) a alta o baja tensión.

- En el modo ICSP alta tensión, el microcontrolador requiere dos fuentes

de tensión programables: una para Vdd y otra el pin MCRL/Vpp (master clear o

tensión de programación).

- En el modo ICSP baja tensión, el microcontrolador puede ser

programado usando únicamente la fuente Vdd en su rango de trabajo. Esto

quiere decir que no hay que llevar el pin MCLR/Vpp a una tensión diferente,

sino que se puede dejar a la tensión de trabajo normal.

Tanto para un modo como para otro, el fabricante impone ciertas

restricciones en algunos parámetros hardware, como son las tensiones y

corrientes de determinados pines, especificaciones para los tiempos de reloj,

etc.

3.2.6. Otros componentes.

Los componentes anteriormente elegidos forman básicamente la unidad

sensora, aunque para una operación correcta del sistema, deben ser añadidos



un conjunto de componentes auxiliares, como un sistema de alimentación

adecuado, cristales para el oscilador principal, así como para el Timer1 del

microcontrolador, condensadores de desacoplo para ambos dispositivos, etc..

En la figura 3.1 se muestra el esquemático de la aplicación, quedando

detallados los componentes necesarios en la tabla V.

Figura 3.1: Esquemático de la IAU preindustrial.



Tabla V: Componentes necesarios para la IAU preindustrial.

ACELERÓMETRO COMPONENTE CANT. VALOR USO Acelerómetro 1 -- Acelerómetro LIS3LV02DQ Condensador 1 100nF (cerámico) Desacoplo alimentación LIS3LV02DQ Condensador 1 10µF (AI) Desacoplo alimentación LIS3LV02DQ

MICROCONTROLADOR COMPONENTE CANT. VALOR USO Microcontrolador 1 -- Microcontrolador PIC18F2431 Condensador 2 27pF Oscilador principal XT 4MHz Cristal 1 4MHz Oscilador principal XT 4MHz Cristal 1 32,768KHz Reloj tiempo real PIC18F2431 Condensador 2 32pF(27pF1) Reloj tiempo real PIC18F2431 Condensador 1 100nF Desacoplo de alimentación Pulsador 1 -- Circuito de reset Resistencia 1 100Ω Circuito de reset Resistencia 1 33KΩ Circuito de reset Condensador 2 100nF Circuito de reset Diodo 1 1N4001 Circuito de reset Batería 1 1000mAh Power Suply Notas: 1Microchip recomienda este valor como comienzo para la verificación del oscilador.

Por otro lado, aunque como se ha comentado en otras ocasiones el

hardware de comunicaciones no es un objetivo de este proyecto, si sería

interesante en cambio, hacer un breve comentario sobre el elegido para la

aplicación, ya que sin duda este, junto con el acelerómetro y el

microcontrolador conforma la parte más crítica del diseño de la IAU.

3.2.6.1. Hardware de comunicaciones

Debido a la importancia que está adquiriendo en la actualidad y a que se

trata de un protocolo estándar, se ha optado para las comunicaciones entre la

IAU y el PSE, por adoptar Zigbee como base para las comunicaciones.

En el prototipo anterior, como se muestra en [26], se eligió una solución

propietaria para dichas comunicaciones haciendo uso del transceptor TRF6901

de Texas Instruments. Esta solución, aunque inicialmente dio buenos

resultados, no permite de forma fácil la interoperatividad entre dispositivos de

diversos fabricantes, lo que puede ser un inconveniente. Sin embargo, Zigbee



brinda la posibilidad de implementar una plataforma de telemonitorización

abierta haciendo uso de un conjunto de unidades sensorias diversas, es decir,

conformando una red de sensores.

Para la elección del transceptor más adecuado se han barajado diversas

alternativas quedando la decisión final entre dos.

La primera es usar el transceptor CC2420 de Chipcon. Este implementa

el estándar IEEE 802.15.4, que se corresponde con las capas física y parte de

la MAC, dejando el resto de capas de la torre de protocolos Zigbee para

implementar en software sobre el micro.

El consumo de este dispositivo, según el datasheet es de 18.8mA en

modo Rx y de 17.4mA en modo Tx. En power down el consumo es de 20µA, y

en modo Idle es de 426µA. En modo Idle el reloj del sistema sigue corriendo

para permitir acceder a los registros internos. Como vemos el consumo es muy

elevado lo que hace que haya que buscar un sistema de sincronización

adecuado entre el dispositivo maestro y el esclavo para minimizarlo.

En este caso la comunicación con el microcontrolador se realizaría a

partir del puerto SPI.

Este transceptor porta también un sistema de supervisión de baterías

que será analizado por si pudiera sustituir al del micro. El consumo máximo de

este módulo es de 90µA, (siendo el del micro de 35µA). Por otro lado el

microcontrolador ofrece más potencia con respecto al control de la carga de la

batería, ya que permite establecer dos límites, mientras que el transceptor solo

impone un límite a partir del cual realizar las acciones oportunas. Inicialmente

optamos por el modulo del microcontrolador.

La segunda alternativa es usar un SoC, el CC2430. Ciertamente este

dispositivo nos permitiría descargar al micro de todos los aspectos de

comunicaciones, además de poder implementar las capas altas del protocolo

Zigbee completamente.

La implementación de la pila de protocolos sobre el microcontrolador

puede ser muy pesada para este, como ejemplo se menciona la referencia [31],

donde microchip implementa esta torre de forma básica sobre un PIC de la



familia 18F. Como se observa, en esta referencia y como se puede ver en las

especificaciones Zigbee, la implementación de una torre simple de protocolos

podría llegar a ocupar unos 10K de la memoria Flash, lo que para el dispositivo

seleccionado sería demasiado. Sin duda se pueden buscar alternativas que

simplifiquen mucho el protocolo, como se muestra en el apartado siguiente,

aunque perderíamos muchas de las bondades del estándar.

En cuanto al consumo del SoC, este es de 27mA en modo Rx y de

25mA en modo Tx. En modo Power-Down el consumo es de 0.9µA. Aunque el

consumo es más elevado con una buena estrategia, que de todas maneras es

necesaria para el otro caso, se podría conseguir un buen rendimiento.

Otra ventaja que ofrece es que tiene dos USART lo que permite su

conexión con el microcontrolador a partir de estas, de forma que evitaríamos

tener que multiplexar el puerto SPI.

Otro problema, es que se necesitaría conocer otro entorno de desarrollo,

así como el juego de instrucciones del microcontrolador que incorpora el SoC.

Eso si, en un momento dado nos permitiría una migración a este micro,

reduciendo considerablemente el tamaño de la IAU.

Su tamaño (máximo teniendo en cuenta las tolerancias) es de

7.1x7.1mm, idéntico a la primera opción.

Tras este análisis para las comunicaciones se ha optado por el CC2430.

3.2.6.2. Sistema de alimentación.

Uno de los aspectos críticos a la hora de implementar la IAU es, sin

duda, la elección de un sistema de alimentación adecuado para satisfacer los

requisitos de la aplicación. Debemos recordar que el consumo es unos de los

aspectos claves y que, sin duda, pude ser decisivo a la hora de llevar hasta el

usuario final un dispositivo de este tipo.

Algunos parámetros a considerar en la elección de la batería son, la

capacidad instantánea de intensidad que puede proporcionar, los niveles de

autodescarga, el peso de las baterías y la capacidad.



Se deberá estudiar además, la necesidad de usar reguladores de

tensión para proporcionar las tensiones necesarias a los distintos dispositivos

que componen la IAU.

La primera decisión a tomar estriba en dos posibilidades, la elección de

una batería recargable o una pila.

Según los requisitos del sistema, hay que llegar a un acuerdo entre

tamaño y tiempo de funcionamiento. Además el sistema final, que se

implementa como un parche, debe ser impermeable lo que, como se verá

introduce dificultades adicionales en ambos casos.

Al elegir una batería recargable como sistema de alimentación, vamos a

requerir de un conjunto auxiliar de circuitos que permitan realizar la carga de

forma adecuada, lo cual aumenta el espacio en placa, aunque será necesario

comprobar la ocupación del sistema completo batería-circuitería auxiliar y

compararlo con el espacio que necesitaría una pila. Por otro lado, las baterías

recargables proporcionan una menor capacidad. Otro inconveniente que surge

radica en el método de carga escogido. Si esta se hace por conexión a la red

eléctrica, necesitaríamos un sistema de conexión al dispositivo a partir del cual

no se perdiera la impermeabilidad requerida. Además, se necesitaría un

sistema de conexión a la red con un transformador y circuitería adicional que

encarecería más el prototipo. Otros sistemas de carga son más complejos de

desarrollar actualmente para este tipo de aplicaciones, auque no se deben

perder de vista para futuros avances.

En cuanto al uso de una pila, esta debe ser de tamaño pequeño, bajo

coste ya que deberá ser sustituida a intervalos regulares de tiempo, fácil de

encontrar ya que sería el usuario final el encargado de su adquisición, y fácil de

cambiar. En lo que respecta al último punto surge el inconveniente del

aislamiento del parche.

De las dos opciones posibles se elige el uso de pilas no recargables ya

que proporcionan mayor capacidad y ocupan un menor espacio. Además, entre

las pilas, las más recomendables por su relación tamaño/capacidad son las

pilas de botón de Litio.



Debido a los requisitos de consumo la tensión de operación de los

distintos componentes, debe ser la menor posible compatible con la tensión

proporcionada por la pila.

El microcontrolador permite un rango de operación entre 2 a 5.5 V y el

acelerómetro operaría entre 2.16 y 3.6V.

El transceptor Zegbee permite una alimentación entre 2 y 3,6V, tanto

para la parte analógica, como para la digital. Además de esta alimentación, el

dispositivo por medio del pin RREG_OUT (24) proporciona una salida de

tensión regulada que permite la alimentación a 1,8V de otro conjunto de pines.

Según se ha podido observar en diversos catálogos, la tensión más

estandarizada y que permite el uso de pilas con una capacidad adaptable a

nuestra aplicación (>500mAh), es de 3V.

Algunas pilas analizadas que resultan interesantes son las ofrecidas por

los siguientes fabricantes y mostradas en la tabla VI.

Tabla VI: Análisis de pilas.

Fabricante Tipo Tensión Capacidad Altura Diámetro

Varta CR2450 3 V 560mAh 5mm 24,5mm

Sanyo CR2450 3 V 610mAh 5mm 24,5mm

Panasonic DR3032 3V 500mAh 3.2mm 30mm

Panasonic BR2450A 3V 550mAh 5mm 24,5mm

Panasonic BR2477A 3V 1000mAh 7,7mm 24,5mm

Sony CR2450 3V 610mAh 5mm 24,5mm

Sony CR2477 3V 1000mAh 7,7mm 24,5mm



La elección final está entre la Panasonic BR2477A y la Sony CR2477,

que proporciona una alimentación a 3V, una capacidad de carga de 1000mAh y

unas dimensiones de 24.5mm x 7.7mm, eligiendose la Sony ya que es más

accesible comercialmente.

Su precio aproximado es de 4.35€/und para la Sony en RS (para más de

100 unidades el precio es de 3,91€).

La elección se ha basado en la capacidad, más que en otros parámetros

como el tamaño, ya que el consumo es el requisito más restrictivo de la

aplicación.

3.2.6.3. Desacoplo en alimentación del acelerómetro.

Para la alimentación del acelerómetro LIS3LV02DQ, según el datasheet

del fabricante, se requieren dos condensadores, uno de 10µF de AI y otro de

100nF cerámico, entre la línea de alimentación y tierra, y lo más próximo

posible al pin 3.

Condensadores cerámicos de 100nF:

- Siemens: B37872K5104K60: Condensador, cerámico, montaje

superficial, X7R, 10%, 50V, 100nF, 1206 (3.2mm x 1.6mm),

precio RS: 0.12€. código RS: 211-3401.

Condensadores de Al de 10µF:

- Vishay: ofrece condensadores SMD de dimensión: 8.8 x 3.7 x

3.9 mm para una tensión de 6.3V. En cuanto a capacidades Al

es el más pequeño encontrado.

- Panasonic: ofrece también un condensador SMD de larga vida

útil, de dimensiones 5mm de Ø x 5.1 de altura y 35V. Su

código RS es: 367-9744 y su precio de 0.30€.



3.2.6.4. Desacoplo en alimentación del microcontrolador

Para la alimentación del microcontrolador, es conveniente usar un

condensador cerámico de 100nF. En este caso, podemos usar el mismo que

para la alimentación del acelerómetro, es decir, el B37872K5104K60.

3.2.6.5. Condensadores para los osciladores

Los osciladores son elementos que requieren una gran precisión, por lo

que los componentes deben tener pocas tolerancias. En este sentido lo más

adecuado es escoger condensadores con NP0 (COG) como dieléctrico, ya que

son los que ofrecen un mejor comportamiento ante variaciones en la

temperatura y además se adecuan a las capacidades necesarias.

Para el oscilador principal del PIC se recomiendan condensadores de

27pF. En este caso, ocurre lo mismo que ya se ha mencionado en el anterior,

por lo que se considera también usar condensadores de 33pF.

Para el reloj de tiempo real del PIC, se recomienda una capacidad entre

27pF y 32pF. Si se va a la medida de capacidad estándar de 33pF, se puede

adquirir el RS: 204-0511.

3.2.6.6. Oscilador Principal de microcontrolador.

Para el oscilador principal, en principio se considera que podríamos

seguir manteniendo el usado en la versión anterior de la IAU siendo este el:

86SMX [R86SMX] a 4MHz.

3.2.6.7. Reloj de tiempo real.

Microchip recomienda para la realización del reloj de tiempo real el

cristal: Epson C-001R32.768K-A, con una tolerancia de ±20ppm. Este reloj

opera a 32.768KHz. Según las características del datasheet, este no es SMD,

con lo que puede ser útil para un prototipo pero sería conveniente buscar otros

cristales SMD de características similares para reducir el tamaño de la placa.



En el mercado podemos encontrar diversos fabricantes, de los que a

continuación se comentan algunos.

- Epson, además del recomendado por microchip, proporciona el FC-

135. Este es SMD, con unas dimensiones de 3.2mm x 1.5mm x 0.8mm y con

una tolerancia de ±20ppm, con lo que se plantea como la mejor solución.

- Micro Crystal Switzerland suministra el CC5V-T1A. Este es un cristal

SMD con tolerancia en frecuencia entre ±30 y ±100ppm. Sus dimensiones son

de 4.1mm x 1.5mm x 0.90mm.

- C-MAC suministra cristales tanto de montaje superficial como normal.

3.2.6.8. Circuito de Reset.

Como nuestro sistema consta de varios módulos, se debe asegurar que

cuando se genere un reset este llegue a todos los dispositivos del sistema.

El reset del acelerómetro será producido por el PIC en su inicialización.

En cuanto al microcontrolador del transceptor, habrá que considerar si el

reset se lo da el PIC o proviene también del circuito externo.

Para los componentes del circuito de reset, se elijen los ya establecidos

en la versión anterior de la IAU.

- 1 diodo rectificador.

- 1 resistencia de 33KΩ.

- 1 resistencia de 100Ω.

- 1 resistencia de 47Ω.

- Pulsador genérico.

3.2.6.9. Componentes auxiliares para el sistema de comunicación.

Los componentes auxiliares para el sistema de comunicaciones Zigbee

quedan fuera del alcance de este proyecto.



3.3. Operación del Sistema

Como se expone en los diversos artículos del grupo examinados, la IAU

se corresponde con la unidad sensora portable. Esta ha de ser implementada

como un parche. Además, ha de ser capaz, por medio de comunicaciones

inalámbricas, de establecer comunicación con el PSE (Servidor Personal).

Auque la mayor carga de procesamiento es responsabilidad del PSE la IAU,

debe contener un mínimo de inteligencia para llevar a cabo con mayor

eficiencia sus funciones. Inicialmente, según se muestra en [23], la IAU

realizaba un algoritmo de detección de caídas a partir de la adquisición de las

aceleraciones en 4 ejes. Las aceleraciones leídas contienen tanto la

componente gravitacional, como la componente inercial causada por el

movimiento del cuerpo.

El algoritmo presentado en [23] es simplificado en [26]. En este proyecto

adoptamos el algoritmo mostrado en [26], pero con una reducción a 3 ejes. Es

decir, el algoritmo para la detección de impactos seguirá basándose en la

superación de ciertos umbrales.

( )

[ ]( )[ ]( ) .3,2,1,

.3,2,1,

·

,

3

1

=+>=

=+>=

=∑=

itttEEefitttAaaf

efafh

hiACi

hii

iii

(3.1)

Donde:

)()()1()( ,,,, τ−−+−= nananEnE iACiACiACiAC (3.2)

Se genera un aviso de impacto si 1≥h , es decir, si durante el instante de

tiempo que transcurre desde que se genera un flag iaf hasta ht , se produce un

flag iaf .

Debemos notar que la IAU determina, por medio del algoritmo

propuesto, que se ha producido un evento de impacto pero es, en definitiva, el

PSE el que establece si el impacto se corresponde con una caída y en tal caso

gestiona las alarmas a enviar al Centro Virtual.



Además, se implementará un proceso de aprendizaje (adaptación)

continuo entre IAU y PSE que debe ser tenido en cuenta, en este proceso de

adaptación se actualizan los umbrales dependiendo del contexto en el que se

desenvuelve el individuo.

Aunque queda fuera de este proyecto, se comentará que el PSE deberá

implementar una metodología que, a partir de los datos de aceleración, permita

la actualización de los umbrales, así como de otros parámetros que esta

segunda unidad pueda necesitar.

Una vez definido el algoritmo de detección de impacto a utilizar, es

necesario establecer como se realizará la operación completa de todo el

sistema de forma que se ajuste a los requisitos.

3.3.1. Desde el punto de vista del consumo.

Es evidente que un individuo no permanece todo el día activo y que

además, en los periodos en los que este permanezca activo, las actividades

realizadas pueden ser muy diversas. Por supuesto que la solución más básica

es mantener el sistema micro-acelerómetro en modo activo todo el tiempo,

ejecutando el algoritmo de detección de impactos, sin embargo esta solución

es poco eficiente en consumo.

Por ello se plantea un modo de operación que permitirá dotar de la

seguridad necesaria al individuo pero que además será eficiente en consumo.

Básicamente se establecen dos periodos de operación; “actividad” e

“hibernación”.

Inicialmente podemos suponer, sin perdida de generalidad, que partimos

del modo de “hibernación”.

En este modo de operación, el sistema completo permanece en

situación de bajo consumo, modo SLEEP de los distintos componentes,

despertando para hacer un reconocimiento de actividad cada cierto intervalo de

tiempo como se verá más adelante.



El micro deberá despertar para entrar en el modo de “actividad” y hacer

un muestreo de la actividad del paciente entre 2 o 4 horas de duración al día,

distribuidas a lo largo del periodo de actividad normal. En este periodo de

tiempo, se deberán tomar los datos de aceleración, realizar los cálculos para

determinar un posible impacto y enviar la información al PSE. Las muestras

tomadas en este periodo van a permitir la adaptación del sistema al contexto.

Como es lógico durante estas 2 o 4 horas también pueden aparecer impactos.

Veamos de forma más detenida como establecer los periodos de

muestro. Un día completo tiene una duración de 24 horas = 86400s. Teniendo

en cuenta que la frecuencia de muestreo inicial de la aplicación es de 40Hz, y

empleamos un buffer de 255 muestras, es decir de 85 muestras por eje para

cada periodo de muestreo, cada uno de estos periodos tendrá una duración de

2.125s. Periodos de muestreo de 2 horas implican un mínimo de 3388 periodos

de muestreo, mientras que 4 horas implican un máximo de 6776 a lo largo del

tiempo de actividad de las personas. El número de muestreos durante el

periodo de actividad de la persona será 67763388 ≤≤ N . Aunque la elección

adecuada del número de periodos de muestreo a realizar debe venir dado

experimentalmente, teniendo en cuenta un equilibrio entre seguridad del

individuo y consumo del dispositivo, en este proyecto se adoptará como

número de muestreos en el periodo de actividad un número de 6000=N .

Considerando las 24 horas del día, tendríamos que realizar un periodo de

muestreo cada 14.4s. Como durante los periodos de inactividad, como por

ejemplo las horas de sueño no es necesario realizar estos muestreos, se

establece un tiempo de 14 horas = 50400s de actividad, lo que implicaría

realizar estos muestreos cada 8.4s. Pero como la duración del muestreo es de

2.125s, entre un periodo de muestreo y el siguiente transcurrirán 6.275s. Estos

muestreos van a permitir la adaptación al contexto aunque durante ellos

también pueden producirse eventos de caída.

En el siguiente diagrama, figura 3.2, se muestra de forma más concreta

como opera el sistema durante las 14 horas en las que el individuo presenta

mayor actividad y el sistema, por lo tanto se encontrará en modo “actividad”.



Figura 3.2: Estados del microcontrolador

En modo “actividad”, además de tomar datos de aceleración para enviar

al PSE, para no perder eventos de impacto, será necesario realizar para cada

triada de muestras adquiridas, el algoritmo de detección de impactos.

El microcontrolador pasará de modo SLEEP a modo RUN, para realizar

los muestreos y ejecutar el algoritmo.

Operando de esta forma, y teniendo en cuenta que el acelerómetro

requiere una intensidad de 800µA en modo RUN, podemos calcular su

consumo con vistas a un mes de operación correspondiente al estado de

“actividad”, así el acelerómetro contribuiría con un consumo de 336mAh.

Por otro lado, la operación del micro sería llevada a cabo por la

conmutación entre el modo SLEEP, estado en el que se quedará durante

6.275s y el modo RUN, en el que permanecerá durante 2.125s. Los requisitos

de intensidad son de 6.5µA y de 1mA respectivamente. El consumo para un

mes sería de 4mAh + 106.3mAh, por lo tanto el consumo correspondiente al

micro sería de 110.3mAh para el estado de actividad.

El resto del tiempo, hasta completar las 24 horas, el sistema permanece

en estado de “hibernación”.

Durante los periodos de “hibernación”, tanto el micro como el

acelerómetro permanecen en modo de bajo consumo, SLEEP, excepto en los

periodos de reconocimiento de la actividad.

Como ya se ha comentado, el que el sistema esté en estado de

hibernación no implica que el individuo este desprotegido. De estudios

experimentales se sabe que el tiempo característico de una caída está

Hibernación

Actividad

8.4s 6.275s

2.125s



alrededor de 1s. Esto implica que un tiempo mayor de un segundo sin revisar el

estado de actividad de la persona puede implicar riesgos. Por ello cuando el

sistema se encuentre en hibernación, realizará la rutina que se ha denominado

“periodos de reconocimiento de la actividad”, como se muestra en el siguiente

diagrama, figura 3.3:

Figura 3.3: Algoritmo de reconocimiento de actividad.

Ejecutando esta rutina cada segundo, durante las 10 horas

correspondiente al periodo de “hibernación”, esta se repetiría 36000. Según la

figura 3.3, el tiempo que permanecería el acelerómetro en ON sería de

INICIO

RDY=1?

Si

ESTADO ACTIVIDAD

SPIBUFF DIR (20h)

SPIBUFF DATO (11)

FIN

No

2 TCY

2 TCY

8 TCY

SLEEP 1 TCY

ContC 4 1 TCY

ContC ContC - 1

ContC=0?

No

Si

MICRO ON

1 TCY

SPIBUFF DIR (20h)

SPIBUFF DATO (00)

SLEEP

2 TCY

8 TCY

8µs +

125ms +

4*25ms

1 TCY

256µs

1 TCY

IWU=1?

Si

2 TCY No ~20µs

MICRO ON 256µs Despertar acelerómetro

Dormir acelerómetro



225,02ms. Por otro lado el microcontrolador tendría que permanecer en ON,

1,4ms. De esta forma el consumo para un mes de operación sería de 54mAh.

Este tiempo se puede reducir configurando el acelerómetro, antes de

este modo, a la frecuencia de muestro más elevada, de forma que el tiempo de

encendido de este pasaría a ser de 2ms, en vez de 125ms y el tiempo que este

permanecería en ON sería de 102.02s y el consumo para un mes de operación

sería de 25mAh.

De esta forma el sistema operando durante un mes tendría un consumo

de 336mAh + 110.3mAh + 25mAh =471mAh.

Como se ha comentado, la pila elegida para la aplicación tiene una

capacidad de 1Ah, lo que posibilitaría al sistema, teniendo en cuenta solo estos

componentes, a operar durante 2 meses sin necesidad de sustituir la batería.

3.3.2. El interprete de comandos.

Hasta ahora el sistema explicado funcionaría de forma autónoma, sin

embargo la IAU debe permitir la atención a comandos del PSE, tanto en los

periodos de “hibernación”, como en los de “actividad”. Para ello sobre el

microcontrolador se ha implementado un “intérprete de comandos”, de forma

que cada vez que el PSE emite un comando la IAU realiza la acción requerida.

Figura 3.4: Estados de la IAU

Así, podemos decir que la IAU estará en uno de tres estados posibles,

como se muestra en la figura 3.4.

Hibernació Actividad

Interprete



Al estado Intérprete se podrá entrar desde cualquiera de los otros dos

modos a partir de una interrupción del sistema. En este estado el

microcontrolador atiende al comando correspondiente y vuelve al estado inicial.

Para minimizar el consumo aseguramos un tiempo mínimo entre dos entradas

al estado de intérprete de 0.5 seg y un máximo de 1seg.

Cada 1 seg el PSE pide datos de aceleración. Entre dos peticiones de

datos el PSE puede pedir la ejecución de algún otro comando.

Como se comentó con anterioridad, el PSE y la IAU se comunican por

medio de una interfase Zigbee. Realmente lo que interesa, desde el punto de

vista de este proyecto, es la interfase entre el transceptor y el microcontrolador,

por ello cuando analicemos las tramas de comando, se entiende que al

especificar que un comando va del PSE a la IAU, estamos hablando de la

trama entre el transceptor y el microcontrolador, con lo que las partes de la

trama correspondientes al protocolo Zigbee no son tenidas en cuenta.

Para dicha interfase se ha elegido el protocolo USART que incorporan

ambos dispositivos, además el microcontrolador está capacitado para salir del

modo SLEEP por medio de la comunicación por USART.

Así, el PSE manda comandos que por medio de una interrupción, que el

transceptor genera en el microcontrolador puede, si se encuentra en modo

SLEEP, sacarlo de este estado y llevarlo al intérprete de comandos, o llevarlo

directamente al intérprete de comandos, en caso de que se encuentre en modo

ON. Debemos notar que, si el micro se encontraba en modo SLEEP, la trama

debe inicialmente llevar un campo que permita al micro sincronizarse para la

recepción.

El intérprete de comandos realiza las siguientes acciones: Cuando un

comando es recibido este es almacenado en una variable, de forma que la

acción a realizar es determinada decrementando en una unidad el valor del

contador hasta que llegue a cero, como se muestra en la figura 3.5, momento

en el que es determinado el comando y ejecutado. Para que resulte más

eficiente, se establece un esquema de prioridad en la situación de los

comandos, de forma que los comandos más probables son aquellos que

necesitarán un menor número de pasos para ser determinados.



Figura 3.5: Determinación del comando a ejecutar.

Los comandos son codificados en 1 Byte sin signo, lo que permite la

codificación de 256 comandos. Debemos notar que los comandos son siempre

enviados del PSE a la IAU, y en función de estos la IAU puede enviar una

trama de datos o de información que haya sido requerida por el PSE.

En la tabla IV se muestran los comandos básicos de la aplicación.

Tabla VII: Comandos básicos de la aplicación.

Código Comando

00000001 Petición Dato Aceleración

00000010 Cargar Umbral Aceleración

00000011 Cargar Umbral Energía

00000100 Petición Estado Batería Sistema

00000101 Petición SelfTest

00000110 Petición Comprobación Calibración

00000111 Listo

00001000 Activar periodo nocturno

00001001 Activar periodo diurno

00001010 Establecer fs = 40Hz

Interprete de comandos

CMMD Codigo comando

Comando = 0?

Ejecutar comando cuyo código corresponde a CMMD

CMMD = CMMD - 1

Si

No






00001111 Establecer RD = 2g

00010000 Establecer RD = 6g

La descripción de cada comando es la siguiente:

• Petición Dato Aceleración: El PSE pide datos de aceleración a una

cadencia determinada. Inicialmente la cadencia es de 1s, enviándose

cada vez que se reciba este comando 10 muestras de aceleración en

cada eje. Debemos notar, que si se ha producido un impacto, este es

indicado al PSE por medio de un código específico.

Así la trama PSE IAU tendrá un tamaño de 1 byte, correspondiente a

la emisión del comando, mientras que la respuesta, es decir la trama en

dirección IAU PSE, tendrá 11 bytes como se muestra en la figura 3.6:

Figura 3.6: Trama del comando de petición de datos

En el campo de Impacto SI/NO, se envía un código 0x80 si se produjo

un impacto y el código 0x00 si no se produjo. El PSE debe comprobar

este código para tomar la acción requerida. En el resto de campos de la

trama se envían los 10 datos de muestra de aceleración.

• Cargar Umbral Energía: Como el algoritmo pretende un proceso de

adaptación, cuando el PSE ha determinado un nuevo valor para el

umbral de energía, este es enviado a la IAU para su actualización.

Byte 1 Byte 2 – Byte 11

Impacto SI/NO Datos de aceleración



La trama en este caso consta de dos campos de 1 bytes. El comando y

el dato del umbral de energía.

• Cargar Umbral Aceleración: Al igual que ocurría con el umbral de

energía, al determinar un nuevo valor para el umbral de aceleración por

el PSE, este es enviado a la IAU para su actualización.

Los umbrales, tanto de energía como de aceleración, estarán

almacenados en la memoria EEPROM ya que a ella se puede acceder

para escritura byte a byte, continuando con la ejecución de código y,

mientras que a la memoria flash se necesitaría una escritura de 8 bytes

además de que se pararía la ejecución de código como ya se comento.

• Petición Estado Batería: El PSE pide información sobre el estado de

carga de la batería del sistema.

En respuesta a este comando, la IAU activa el modulo de detección de

carga de la batería (LVD). Este modulo determina el estado de la batería

y contesta al PSE con un byte. En el PSE se deberá implementar la

sistemática adecuada para la recepción correcta de la respuesta al

comando.

Para el funcionamiento del módulo LVD, se establecen dos umbrales de

tensión. Dependiendo del umbral que se superé, el PSE deberá realizar

una acción determinada.

Inicialmente se establece una tensión de 3V para alimentar al sistema,

de forma que no haga falta ningún regulador de tensión adicional para la

alimentación. Pese a ello, no debemos perder de vista que a menor

tensión de operación menor será el consumo, pero el uso de un

regulador, además de ser un elemento adicional que redunda en el

aumento del espacio de la placa, también requerirá cierto consumo.

Para establecer los umbrales debemos examinar tanto la curva de

descarga de la batería así como el rango de tensiones en el que los

distintos dispositivos pueden funcionar de forma correcta.

Como se comentó en un punto anterior, la mínima tensión de operación

a la que puede funcionar el sistema será de 2.16V e irá marcada por el



microcontrolador, sin duda el umbral inferior de modulo LVD no debe ser

inferior a este.

Entre los diversos rangos de tensión que ofrece el microcontrolador para

la elección de los umbrales de la IAU, el más interesante en nuestro

caso será el de 2,26V para el umbral inferior y de 2.65V, para el umbral

superior.

Por debajo del segundo umbral el acelerómetro no podría operar, con lo

que el microcontrolador lo desconecta, pudiendo mantener el sistema de

comunicaciones Zigbee y el mismo en operación, para permitir gestionar

las peticiones de carga de batería, así como salvar los datos que fueran

necesarios. Debemos también notar que el chip de acelerometría por

debajo de 2.16V queda incapacitada su unidad sensora, pero sí podría

seguir funcionando su interfase, con lo que podríamos salvar los datos

de sus registros. Por eso podemos forzar el límite de la tensión de

alimentación a 2.16V.

• Petición de SelfTest: Se invoca a la IAU para realizar el SelfTest del

acelerómetro. De nuevo, una vez realizado el SelfTest, se comunica al

PSE si este ha sido o no correcto.

• Petición de Comprobación de Calibración: Este comando será utilizado

de forma excepcional, por ejemplo tras haberse producido un impacto

que pudiera haber dañado al sistema, de forma que se compruebe que

la calibración sigue siendo la correcta.

• Activar periodo nocturno: El PSE indica a la IAU que debe entrar en

modo nocturno.

• Activar periodo diurno: El PSE indica a la IAU que debe entrar en modo

diurno.

• Establecer fs = 40Hz, fs = 160Hz, fs = 640Hz, fs = 2560Hz: Estos cuatro

comandos nos permiten configurar la frecuencia de muestreo de la

aplicación. El sistema se configurará inicialmente para una frecuencia de

muestreo de 40Hz, pero en algún caso puede ser necesario el aumento

de esta debido al procedimiento de adaptación al contexto del sistema.



• Establecer RD = 2g, 6g: Estos dos comandos, tambien tienen como

misión reconfigurar el sistema para adaptarlo, en este caso variando el

rango dinámico que puede ser de 2g o 6g.

Como se ha comentado para el comando de “Petición Dato Aceleración”,

la IAU siempre responde con la trama que se ha mostrado.

En los comandos en los que se pide a la IAU que realice una acción,

también es necesario implementar una trama respuesta que informe al PSE

que la acción ha sido realizada correctamente. Así la IAU responde con una

trama de “Acción Correcta 0x00” o “Error 0x01”, dependiendo si se ha

podido o no realizar la acción requerida.

De nuevo recordar que la simplicidad de las tramas se debe a las

facilidades que ofrece Zegbee para implementar la pila de protocolo completas.

Las tramas, en nuestro caso serían tramas de aplicación.

Aunque el número de comandos aquí implementados es muy simple, la

posibilidad de ampliación de su número puede ser de gran utilidad a la hora de

mejorar la aplicación.

También es necesario comentar que la primera vez que una IAU

concreta se conecta con un PSE concreto se establece un intercambio básico

de parámetros de configuración.

La IAU recibe el comando “LISTO” y responde con un “OK”, tras ello el

PSE le pasa los umbrales iniciales a partir de un comando “Carga Umbral

Aceleración” y “Carga Umbral Energía”. Puede ser posible configurar otros

parámetros.

3.3.3. Comunicaciones Acelerómetro-Microcontrolador

Como se comento anteriormente, el acelerómetro presenta una interfase

digital compatible con I2C o SPI. Por otro lado, el micro también permite ambos

tipos de conexión.

El puerto I2C actualmente está estandarizado para tres velocidades de

operación 100Kbps, 400Kbps y 1Mbps. Sin embargo, el acelerómetro admite



las dos primeras velocidades, mientras que el microcontrolador elegido solo

admite la primera, por lo que solo sería posible, mediante una interfase I2C,

comunicar ambos dispositivos a 100Kbps, velocidad que se considera es

demasiado baja.

En cuanto a SPI, podemos configurar diversas velocidades de

transmisión. Como se ha elegido para el reloj de sistema un modo de

funcionamiento XT con FOSC = 4MHz, las velocidades a las que podrá

transmitirse serán:

- FOSC/4 = 1Mbps.

- FOSC/16 = 250Kbps

- FOSC/64 = 62,5Kbps

El acelerómetro no establece velocidad de operación, lo cual es lógico

ya que operará como esclavo siendo el micro el que genere el reloj.

El único inconveniente que se encuentra al usar SPI es que el pin RX de

la EUSART coincide con el pin SDO de SPI. Este no es un problema ya que se

podría usar otro pin como selector de chip (de momento el puerto RB está libre

por lo que se podría usar cualquiera de ellos).

Parece ser que la mejor elección es usar el bus SPI a 1Mbps y por lo

tanto es la que se ha adoptado para la realización de este proyecto.

La comunicación entre el PIC y el Acelerómetro se establece para

adquirir las aceleraciones, así como para configurar los registros del

acelerómetro, de forma que este funciones según nuestros requisitos.

Como se ha comentado anteriormente, las aceleraciones que

proporciona el acelerómetro son datos de 2 bytes, codificados en complemento

a 2. Para la realización del algoritmo se ha elegido la opción de operar con

datos de 1 byte en complemento a dos y punto fijo, de forma que se debe

establecer la forma de pasar los datos de 2 bytes a datos de 1 bytes. La

solución adoptada es la de truncar el dato de aceleración adquiriendo solo el

byte más significativo, de forma que aunque la precisión es peor en relación

con otros métodos de redondeo, se gana en tiempo de transmisión como se

muestra en los correspondientes diagramas.



La adquisición de datos de 2 bytes se hará según el esquema mostrado

en la figura 3.7:

Figura 3.7: Rutina de adquisición de aceleraciones.

Para la adquisición de datos de 1 byte, se adquieren solo los datos de

aclaración del byte más significativo según la figura 3.8.

Figura 3.8: Rutina de adquisición de aceleraciones truncadas.

INICIO

SPI Dirección1

SPI Dirección3

Ax1 AxL SPI Dirección5

Ay1 AyL SPI Dirección1

Az2 AzH

FIN

2µs

2µs

4µs

4µs

2µs

8µs

8µs

8µs

8µs

INICIO

SPI Dirección1

SPI Dirección2

Ax1 AxL SPI Dirección3

Ax2 AxH SPI Dirección4

Ay1 AyL SPI Dirección5

Ay2 AyH SPI Dirección6

Az1 AzL SPI Dirección1

Az2 AzH

FIN

2µs

2µs

4µs

4µs

4µs

4µs

4µs

2µs

8µs

8µs

8µs

8µs

8µs

8µs

8µs



La recepción y transmisión de datos se puede realizar de dos formas, o

por espera activa o por interrupción. Teniendo en cuenta que el tiempo de

transmisión (o recepción) de un dato es de 8µs, tiempo en el cual solo

podemos ejecutar 8 instrucciones, como máximo, parece ser que lo mejor es la

opción de espera activa, ya que por interrupción casi todo el tiempo se

consumiría en el cambio de contexto, pudiendo incluso ralentizarse la

operación.

En el caso del empleo de espera activa, el tiempo de transmisión sería

de: 82µs para la adquisición de datos de 2 bytes y de 46µs en el caso de datos

de 1 byte. Es importante notar en este punto, que para la recepción/transmisión

de los datos, se emplean buffer circulares de forma que esta se realiza con

cierto grado de paralelismo, consiguiendo un tiempo menor en la adquisición de

los datos de aceleración.

A medida que las aceleraciones son adquiridas serán almacenadas en

un buffer para el posterior tratamiento y envío al PSE.

3.3.4. Modulo Supervisor.

Como ya se ha comentado, el micro incorpora características que

permiten supervisar diversos aspectos de la operación del sistema, como por

ejemplo la alimentación, WDT, etc.

Es conveniente establecer algunos requisitos de seguridad en la

supervisión, de forma que la IAU no quede inutilizada sin que se entere el

usuario o el centro de asistencia. Por ejemplo, si se detectara que la batería

está baja, el sistema debería entrar en un modo de consumo mínimo, con la

única posibilidad de despertarse en caso de que se produzca un impacto. A la

vez deberá enviar un mensaje al PSE, el cual deberá avisar al usuario e incluso

al centro virtual, para que el personal sanitario al cuidado tenga consciencia del

hecho y procure la sustitución o recarga de la batería. Debemos notar que el

sistema se crea inicialmente para personas mayores que pueden tener un

concepto ambiguo del dispositivo.



Teniendo en cuenta que la IAU debe tener una tamaño reducido y un

consumo muy bajo, básicamente se implementan los dos siguientes módulos

para seguridad que son proporcionados por el microcontrolador y el

acelerómetro elegido:

- El WDT, supervisa la ejecución del código de forma que si el programa

entra en un bucle sin salida o queda en un punto determinado el sistema

es reiniciado. Debemos notar que en el prototipo de laboratorio el WDT

era usado para realizar el muestreo de las aceleraciones. En la IAU

preindustrial el muestreo de las aceleraciones es llevado de forma

autónoma por el acelerómetro, de forma que este módulo, que además

es más versátil en el micro actual que en el anterior, queda directamente

ligado a la función de protección de la ejecución del código, mejorando

la fiabilidad del sistema.

- Otro elemento muy importante a controlar es la carga de la batería. En el

mercado existen diversos dispositivos que permiten esta supervisión,

como es el MAX705, sin embargo el microcontrolador que vamos a usar,

el PIC18F2431, proporciona un módulo denominado Low Voltaje Detect

(LVD) que nos permitirá implementar el sistema supervisor de carga de

la batería sin añadir hardware extra.

Este modulo se puede activar independientemente de otros módulos del

sistema.

Su funcionamiento se basa en la posibilidad de habilitar dos umbrales

configurables por el usuario. Una vez sobrepasado el primer umbral, se

procedería a la comunicación con el PSE para indicar al usuario la falta

de batería. Además sería conveniente que se enviara una alerta al

centro de proceso para que el personal sanitario tenga conciencia de la

situación y se proceda a la sustitución de la batería.

Si la alimentación del sistema cayera por debajo del segundo umbral,

todo el sistema se desconectaría generando una alerta para que el

individuo conozca la situación. Antes de desconectarse el sistema se

procederá a salvar los datos críticos.



Por supuesto el umbral inferior siempre deberá estar por encima del

mínimo para el correcto funcionamiento de los dispositivos implicados,

siendo estos de 2.16V para el acelerómetro y de 2V para el

microcontrolador.

- El SelfTest es una característica que proporciona el acelerómetro y que

permite comprobar que este opera correctamente.

La rutina de Sefttest es llevada a cabo como sigue (figura 5.5). En primer

lugar indicamos al acelerómetro que se va a realizar el SelfTest por

medio de la escritura del comando adecuado en sus registros de control.

Figura 3.9: Flujograma de realización de la rutina de SelfTest.

Rutina de SelfTest

CTRL_REG1 = ‘11111111’

AxSELFTEST = OUTx_L α OUTx_H

AySELFTEST = OUTy_L α OUTy_H

AzSELFTEST = OUTz_L α OUTz_H

CTRL_REG1 = ‘11110111’

Ax = OUTx_L α OUTx_H

Ay = OUTy_L α OUTy_H

Az = OUTz_L α OUTz_H

100Lsb ≤ AxSELFTEST – Ax ≤ 400Lsb

100Lsb ≤ AySELFTEST – Ay ≤ 400Lsb

100Lsb ≤ AzSELFTEST – Az ≤ 350Lsb

¿Correcto?

Salir

AVISO al PSE

Si

No



Tras ello, se toman los datos de aceleración proporcionados por el

acelerómetro y se guardan en una variable determinada. Seguidamente

se desconecta el modo de SelfTest del acelerómetro y se procede a la

toma de una nueva muestra de aceleraciones. Si la comparación de

ambos datos de aceleración adquiridos para cada eje queda dentro de

un determinado rango, se indica que el sistema sigue funcionando

correctamente. Si no fuera así, se indicaría al PSE que el acelerómetro

tiene algún problema.

Es importante mencionar que para llevar a cabo la rutina de selftest es

importante que el individuo no presente actividad, por ello lo conveniente

será ejecutarla cuando esté en modo nocturno, es decir cuando el

paciente esté acostado. Además se aumenta la frecuencia de muestreo

al máximo para que el error entre dos adquisiciones debido a un posible

movimiento sea mínimo.

3.3.5. Modo de calibrado del dispositivo

Como ya se ha dicho, aunque el dispositivo se proporciona calibrado de

fábrica, pude ser necesario que este tenga que ser calibrado en determinados

momentos. El método para la calibración del dispositivo expuesto en el

Datasheet es el siguiente:

La medida de la sensibilidad se haría poniendo el eje de interés en la

dirección del campo gravitatorio, se anota el valor de salida y se gira 180º,

volviendo a anotar el valor de salida. De esta forma medimos ±1g sustrayendo

al valor de la salida mayor, el de la salida menor y dividiéndolos por 2, conduce

al valor de la sensibilidad real.



3.4. Diagrama de bloques de la IAU preindustrial.

En la figura 3.10 se muestra un diagrama de bloque funcional de la IAU

preindustrial donde se detallan los flujos de información.

Figura 3.10: Diagrama de bloques funcional de la IAU.

3.5. Material auxiliar para el desarrollo de la aplicación.

El diseño de una aplicación no solo pasa por la elección de los

componentes y la implementación del sistema. Una de las fases de gran

importancia en el ciclo de vida del desarrollo de una aplicación, es la fase de

prueba y verificación tanto del hardware como del software. Básicamente el

prototipo establecido en este proyecto tiene esta finalidad, es decir su objetivo

primario es el de verificar que tanto el hardware elegido como el software

cumplen con las especificaciones iniciales de la aplicación.

ACELEROMETROS

COMPROBADOR CARGA BATERIA

RELOJ DE TIEMPO REAL

BATERIA

GENERADOR DE ALARMA

COMUNICACIÓN USART

CENTRO DE CALCULOS

BUS SPI

COMUNICACIONES SPI

USART TRANCEPTOR

ZEGBEE

PIC18F2431

MODULO SUPERVISOR

IAU

INTERPRETE DE COMANDOS



Para tal fin ha sido necesario disponer de material auxiliar. En el caso de

este proyecto hay dos aspectos claves a verificar, el microcontrolador y el

acelerómetro. Aunque las comunicaciones también son de suma importancia,

estas exceden del ámbito de este proyecto y no serán tratadas aquí.

Como ya se ha comentado, el microcontrolador elegido ha sido el

PIC18LF2431 de la empresa Microchip.

Para el desarrollo de aplicaciones Microchip dispone de un entorno de

desarrollo específico denominado MPLAB IDE que es, como es natural, el que

se ha usado para implementar el software de nuestra aplicación.

En nuestro caso el código de la aplicación está escrito en lenguaje

ensamblador, debido a que requerimos de una mayor eficiencia en la ejecución

sobre todo desde el punto de vista, de nuevo, de la minimización del consumo.

Dentro de este entorno de desarrollo la herramienta usada para la elaboración

del software ha sido MPASM Assembler

Tras la implementación del código fuente, este entorno nos permite

realizar un primer depurado de la aplicación. Por medio de la herramienta

MPLAB SIM, se realiza una emulación de la ejecución del código en la

computadora. Aunque esta herramienta permite un buen nivel de depuración,

sigue siendo una emulación y por lo tanto se hace necesaria la comprobación

real en el micro de la ejecución del software ya que permite cierta emulación de

los eventos que en nuestro caso no es de gran utilidad.

Tras esta primera depuración se procede a la programación del

dispositivo. Además, pensando en una mejor depuración del código así como

de una verificación de la operación del micro más real, se realizó una búsqueda

de alguna herramienta adecuada para tal fin. Entre todas las que ofrece

Microchip se ha elegido la placa de desarrollo PICDEM 2 PLUS junto con el

entorno de programación y depurado MPLAB ICD 2.

En cuanto al acelerómetro ST Microelectronic también ofrece un entorno

de demostración que permite hacer una evaluación previa, con ciertas

limitaciones de la operación de este sensor. El entorno de demostración

STEVAL-IFS001V1 consta de la placa madre DK3420 – USB que porta un

microcontrolador de la familia uPSD34xx de ST Microelectronic para permitir la



adquisición de datos de aceleración y envío al ordenador a partir de un puerto

USB, y de la placa ST-MEMS-DQ-EVAL que porta el acelerómetro en cuestión.

Esta última placa, la ST-MEMS-DQ-EVAL, nos va a permitir comprobar

además, junto con la placa PICDEM 2 PLUS, la implementación del primer

prototipo objetivo de este proyecto.

Documents

Capitulo 3: Resultados: IAU Preindustrial.bibing.us.es/proyectos/abreproy/40034/fichero/Capitulos... · Capítulo 3 Resultados: IAU preindustrial. José Gustavo Jiménez Pérez 45