1

Universidad de la República Facultad de Ingeniería

Instituto de Ingeniería Eléctrica

Sistemas Embebidos para Tiempo Real Curso 2013

- Informe Final-

Grupo: 2

Nombre

Integrantes: Matías Valdés

Federico Vanzini

Fernando Viera

Tutor: Leonardo Steinfeld

2

Índice

Introducción .................................................................................................................... 3

Resumen ........................................................................................................................... 3

Descripción del problema a ser resuelto ........................................................................... 3

Objetivo del proyecto ...................................................................................................... 4

Antecedentes ..................................................................................................................... 5

Alcance ............................................................................................................................. 6

Implementación .............................................................................................................. 6

Plataforma de hardware .................................................................................................... 6

Configuración del Timer .................................................................................................. 7

Modulo lista Encadenada.................................................................................................. 8

Modulo gestorHora ........................................................................................................... 9

ISR del Timer ................................................................................................................. 11

Evaluación de Performance y Resultados .................................................................. 12

Puntos de comparación ................................................................................................... 12

Ciclos de trabajo ............................................................................................................. 12

Potencia media ............................................................................................................... 16

Uso de memoria .............................................................................................................. 17

Cantidad de Interrupciones del Timer ............................................................................ 17

Conclusiones .................................................................................................................. 19

Referencias Bibliograficas .............................................................................................. 20

3

Introducción

Resumen

El proyecto consistió en implementar un modulo que brinde el servicio de timer sin tick

periódico a un sistema embebido.

Para el manejo de timeOuts se implemento una lista encadenada para almacenar los

tiempos de timeOuts y funciones para su manejo que permiten agregar, quitar y

decrementar timeOuts de la lista.

Se desarrollo un modulo que permite configurar el timer de forma dinámica según el

próximo tiempo de TimeOut.

Para el manejo del tiempo transcurrido de ejecución se desarrollo un modulo que

permite incrementar el tiempo en múltiplos de la resolución temporal.

El modulo implementado fue integrado a la aplicación datalogger del curso 2012.

Para medir el desempeño del datalogger con y sin tick periódico se estudiaron aspectos

tales como el consumo de potencia, memoria utilizada, cantidad de ticks por segundo y

ciclos de trabajo

Descripción del problema a ser resuelto

En un sistema embebido el manejo del tiempo se basa en interrupciones periódicas del

timer.

Este incrementa un tick de forma periódica, el cual es usado para ofrecer servicios de

gestión de tiempos a los distintos módulos del sistema.

Para expresar de manera intuitiva lo que se pretende lograr, se presenta a continuación

la siguiente imagen en la que se puede observar la secuencia de lectura de 2 sensores, de

tiempo de lectura (timeout) 3 y 1 segundos respectivamente para un sistema con tick

periódico y otro sin tick periódico como el que se desea implementar.

Figura 1

4

En la figura 1 se puede observar una cantidad de 12 interrupciones (ticks) de un timer

con tick periódico (TCTP) requeridas para leer el primer sensor contra 1 sola

interrupción del timer sin tick periódico (TSTP).

De igual modo se observa una diferencia de 3 interrupciones entre ambos timer para leer

el siguiente sensor en un tiempo de 1 segundo.

Menor número de interrupciones conlleva en un menor ciclo de trabajo, lo cual podría

traducirse en un ahorro de consumo al hacer uso de los modos de bajo consumo del

microprocesador.

El modulo a implementado puede ser usado por ejemplo para ejecutar de manera

diferida una función, gestionar timeouts, llevar la hora del sistema, etc.

Para contar cierto tiempo arbitrario se contabilizan ticks obteniendo tiempos múltiplos

de este. Para lograr una buena resolución temporal se requieren ticks relativamente

cortos. Por otro lado, elegir ticks cortos aumenta la frecuencia de las interrupciones

incrementando el consumo de energía.

Objetivo del proyecto

El objetivo es implementar un modulo de timer sin tick periódico para ser integrado en

cualquier aplicación.

Para probar el módulo funcionando en una aplicación real se integrará el mismo a la

aplicación Datalogger (proyecto de curso 2012).

Luego se utilizará la aplicación para comparar la performance de la aplicación con y sin

el modulo implementado.

Además de dar la funcionalidad básica (que el timer interrumpa cuando haya pasado el

tiempo correspondiente) se deberán implementar otras funcionalidades relacionadas con

el uso del timer como llevar el reloj del sistema.

5

Antecedentes

Aunque la mayor parte de los sistemas operativos embebidos utiliza un tick periódico

para su funcionamiento, existen ejemplos de sistemas operativos embebidos que

proveen un servicio de timer sin tick. Un ejemplo de esto es el sistema operativo

RETOS que implementa un timer de tiempo variable que es reconfigurado según el

próximo tiempo de timeout [4].

También se encuentran ejemplos de sistemas operativos que han sido portados a algún

microcontrolador en particular y modificados para proveer un servicio de timer sin tick.

El sistema operativo FreeRTOS por ejemplo ha sido modificado para proveer un timer

sin tick en el microcontrolador LM3S3748 [3].

Finalmente existen ejemplos de desarrollos de sistemas embebidos específicos que

incorporan el concepto de timer sin tick. En el área de las redes de sensores

inalámbricos se encuentran ejemplos de esto en escenarios de rescate [2] y en el

monitoreo de hábitats naturales [5].

6

Alcance

El proyecto no incluye diseño específico de hardware ni el agregado de periféricos.

Todo modulo del datalogger que no intervengan en la gestión de tiempos de eventos

queda fuera del alcance de este proyecto.

El proyecto incluye el desarrollo de funciones para el manejo de los tiempos de

TimeOut y configuración dinámica del timer.

Dentro del alcance consideramos también la realización de medidas para comprobar el

desempeño del sistema desarrollado frente a uno que utiliza un tick periódico.

Implementación

Plataforma de hardware

Como plataforma de desarrollo se utilizó la placa MSP-TS430PZ5x100 de Texas

Instruments junto con un microcontrolador MSP430F5438.

Figura 2: Placa de desarrollo utilizada

Esta placa cuenta con un oscilador de cristal de 32768Hz el cual fue utilizado como

reloj fuente para el timer del microcontrolador.

7

Para la comunicación serie con la PC se utilizaron los pines 53 (UCA1TX) y 54

(UCA1RX) del microcontrolador. Dado que los niveles de tensión de las señales del

microcontrolador no son los mismos que utiliza la PC para comunicarse a través de su

puerto serie, se utilizó también una placa convertidora de niveles de tensión. Esta última

utiliza un circuito integrado MAX3232C.

Configuración del Timer

Para configurar el Timer usamos un módulo llamado „confTimer‟ mediante el cual se

configura el timer B0 utilizando un registro de largo 16 bits para cargar las cuentas y un

reloj auxiliar de 32768 Hz.

En la tabla 1 se presenta el tiempo máximo y mínimo de los períodos de tick que se

pueden conseguir mediante la selección del prescaler correspondiente:

Tabla 1:

Dadas las diferentes escalas se optó por utilizar un prescaler de 8 priorizando un mayor

alcance de tiempo de TimeOut máximo, considerando éste como una limitante de

diseño.

Con un prescaler de 8 para disminuir la frecuencia, configurando el timer para operar en

modo UP (incrementando repetidamente TBR de 0 hasta el valor del registro

comparador) se alcanza una resolución de (32768/8) -1

= 244us, el equivalente a 1

cuenta.

Esta elección nos da una limitación de timeOut máximo de (216

)/4096 = 16 seg, que es

lo que alcanza el registro de 16 bits.

8

Modulo lista Encadenada

Para implementar el Timer Sin Tick periódico se desarrollo un modulo llamado

ListEncadenada que implementa una lista, cada elemento de la misma es un nodo y a su

vez cada nodo es una estructura como se muestra en la figura 3.

Figura 3

Los campos de cada nodo son:

» timeOut: tiempo en que debe ser leído un sensor.

» next: puntero al siguiente nodo.

» numSensor: número que identifica a un sensor.

En la lista se almacenan los tiempos de timeOuts de forma ordenada, es decir que cada

vez que un sensor es agregado a la lista, se agregará de forma ordenada según su

timeOut, siendo el nodo raíz el nodo con menor timeOut.

El modulo implementa las siguientes funciones:

iniModulo: Función que inicializa el modulo.

agregarTimeOut: Función que agrega un nodo a la lista.

quitarTimeOut: Funcion que remueve el nodo raíz de la lista.

decrementarTimeOut: Función que decrementa los timeOuts de todos los

nodos en una cantidad igual al timeOut del nodo raíz.

La función procesarSensores() incluida en la ISR del timer es quien utiliza el modulo

listaEncadena para realizar el manejo de los tiempos de lectura de los sensores, dicha

función es analizada en la sección ISR del Timer.

Debemos mencionar que el uso de la lista encadenada hizo necesario la modificación de

la función reset() incluida dentro de los comandos ejecutables por el usuario, para

mantener su funcionamiento la función reset modificada remueve todos los nodos

existentes excepto el nodo raíz, utilizando para esto la función quitarTimeout() del

modulo listaEncadenada .

9

Modulo gestorHora

La aplicación Datalogger utiliza una función que incrementa el tiempo transcurrido de

ejecución en cada interrupción. Es decir, al tener un tick periódico incrementa el reloj en

un valor equivalente a ese tick.

Para adaptar ésta función a un tick dinámico se procedió a diseñar una nueva manera de

incrementar el tiempo correspondiente a cada valor de timeout.

Se eligió trabajar con una variable de 16bits en la que guardamos la cantidad de cuentas

a incrementar (valor obtenido del registro del Timer llamado TBR) o lo que es

equivalente, el número total de resoluciones de la escala elegida. Por ejemplo, en el caso

del Datalogger con timer sin tick cada cuenta equivale a un incremento de 244us (1

resolución).

El algoritmo utiliza la representación en punto fijo para evitar usar otras más complejas

como float, que facilita las cosas pero incrementaba bastante el tiempo de atención a la

interrupción del timer (ciclo de trabajo).

En la figura 4 se puede observar, a modo de esquema, el procedimiento utilizado para

conocer, a partir del número de cuentas los segundos y milisegundos equivalentes con

una resolución de 244us.

Para calcular los segundos se corren los bits de la palabra a la derecha tantos lugares

como la potencia correspondiente a las cuentas definidas para 1seg. En este caso 1

segundo son 212

=4096 cuentas. Estos son 12 lugares a la derecha para obtener la

información de los segundos.

Para obtener la cantidad de cuentas correspondientes a los milisegundos (cantidad de

resoluciones de 244us) se le aplica una máscara de (4096-1) a la cantidad de cuentas.

Luego se obtienen los segundos al dividir entre 4096 el total de cuentas (resoluciones) y

al resultado se lo multiplica x1000 para pasar a milisegundos.

10

Figura 4

Nota: En el ejemplo de la figura se contaron 11.395 segundos

11 segundos + 1950*(2^-12)*(1000) = 395 ms

11

ISR del Timer

Una de las modificaciones más relevantes que se realizaron al datalogger 2012 fue la

modificación realizada en la ISR del Timer. La rutina original controlaba en cada

interrupción si algún sensor debía ser leído es decir si había expirado o no algún

timeOut y en caso de ser afirmativo lo mandaba leer. Nuestro sistema solo interrumpe

cuando expira el timeout del nodo raíz, es decir que cuando interrumpe siempre debe

mandar a leer al menos un sensor, es por ello que luego de la modificación el flujo de la

rutina quedo como se muestra la figura 5.

Diagrama de flujo de la ISR del Timer:

Figura 5

La función procesarSensores() que manda a leer los sensores fue implementada por

nosotros y fue incluida en el modulo ya existente llamado datalogger, su finalidad es

procesar los sensores cuyos timeOuts hayan expirado, para ello primero manda a leer el

sensor, luego lo quita de la lista y finalmente lo agrega nuevamente con el mismo

timeOut ya que los sensores se leen de forma periódica. Como se dijo anteriormente la

funciones utilizadas son las incluidas en el modulo listaEncadenada.

Función que incrementa el tiempo transcurrido de

ejecución del sistema.

Función que decrementa los TimeOut de todos los

nodos.

Función que procesa los sensores.

Función que re configura el Timer con el próximo

tiempo de TimeOut de la lista.

12

Evaluación de Performance y Resultados

Puntos de comparación

En la siguiente comparación se consideran tres variantes del Datalogger:

1. Datalogger original con un tick periódico de 250ms

2. Datalogger con un tick periódico de 7.8ms

3. Datalogger sin tick periódico implementado en este proyecto de curso

Se utilizo la variante 2 para hacer más notoria la diferencia con el sistema sin tick

periodico, en esta variante se modifica también la función que incrementa la hora del

sistema utilizándose la implementada para el Datalogger sin tick periódico.

Los puntos que consideramos de importancia para comparar el desempeño entre las

distintas variantes del Datalogger son:

1. Ciclo de trabajo

2. Consumo de potencia media

3. Cantidad de interrupciones por segundo

4. Memoria ocupada por el código y los datos

Como se verá a continuación, algunos de estos puntos están relacionados entre sí.

Las medidas se realizaron con el osciloscopio digital y mediante el pin 97 del

microcontrolador el cual corresponde al pin 0 del puerto 6 (P6.0).

En cada caso se configuró al Datalogger con un único sensor de un periodo de lectura de

1 segundo.

Ciclos de trabajo

En el caso de un Datalogger con tick periódico (CTP), la señal que se observa en el

osciloscopio es una onda rectangular con un periodo igual al tiempo de tick

correspondiente. El ciclo de trabajo se define entonces en este caso como el cociente

entre el tiempo en que la señal no es nula (ton) a lo largo de un periodo y el tiempo de

tick:

Figura 6

13

Los valores medidos en este caso fueron los siguientes:

Tiempo de Tick ton d=(ton/ttick)*100

250ms 235us 0.094%

7.8ms 304us 3.9%

Tabla 2:

En el caso del Datalogger sin tick periódico (STP), la señal es también rectangular pero

con un periodo igual al periodo del sensor. En el ejemplo que se está considerando este

periodo es de 1 segundo. Por lo tanto el ciclo de trabajo es igual al tiempo en que la

señal es no nula a lo largo de un periodo de 1 segundo:

Figura 7

Los valores medidos fueron:

Ttotal=T ton d=(ton/ttotal)*100

1s 418us 0.042%

Tabla 3:

14

En las siguientes imágenes se pueden ver las señales medidas en el osciloscopio en

cada caso:

Figura 8: Datalogger con tiempo de tick de 250ms

Figura 9: Datalogger con tiempo de tick de 7.8ms

15

Figura 10: Datalogger sin tick periódico

16

Potencia media

Dado que el microcontrolador se encuentra en modo “sleep” cuando no debe procesar

interrupciones provenientes del Timer, la UART o el ADC, es posible expresar la

potencia media total consumida por este mediante:

Aplicando esta expresión para el Datalogger CTP y STP, se puede obtener la siguiente

expresión que da la diferencia absoluta de potencia consumida por el Datalogger CTP

respecto al Datalogger STP:

Se observa entonces que la diferencia de potencia es directamente proporcional a la

diferencia de ciclos de trabajo.

La constante de proporcionalidad la obtuvimos de las medidas de potencia realizadas

durante el proyecto de curso Datalogger 2012. Para el caso del microcontrolador

funcionando a una frecuencia de trabajo de 8MHz la potencia activa media es del orden

de 3mW. Por otro lado para la potencia en modo sleep tomamos el peor caso dado por

la cota superior de unos 500uW. Con estos valores se obtiene una constante de

proporcionalidad de 3mW-500uW=2.5mW.

A partir de esto y previo cálculo de la diferencia de ciclos de trabajo, se llega a los

siguientes valores para la diferencia absoluta de potencia media consumida:

Tiempo de Tick PTP-PSTP

STP vs. 250ms 1.30uW

STP vs. 7.8ms 96.5uW

Tabla 4

Para hallar la diferencia relativa de potencia media consumida, utilizamos la expresión

inicial que nos da los siguientes valores de potencia media:

Tiempo de Tick PSTP

250ms 502.35uW

7.8ms 597.5uW

Tabla 5

17

Por lo tanto se obtiene finalmente que el ahorro de potencia con un sistema STP

respecto a uno CTP viene dado en cada caso por:

Tiempo de Tick (PTP-PSTP/PTP)*100

STP vs. 250ms 0.26%

STP vs. 7.8ms 16.14%

Tabla 6

Uso de memoria

El cuadro a continuación es un comparativo en el cual se muestra el tamaño de memoria

que ocupan las aplicaciones Datalogger con tick (TP) y sin tick (STP) periódico.

Datalogger Código Datos Constantes Total

TP 8302 2718 1500 12520

STP 9204 2922 1496 13622

Memoria en bytes

Tabla 7

En la tabla 7 se puede observar un consumo en recursos de 12520 bytes en TP contra

13622 bytes en STP. Se consume aproximadamente 1kbyte de memoria adicional.

Este adicional se le puede asociar a la nueva versión de la función IncrementarHora().

Cantidad de Interrupciones del Timer

En el cuadro a continuación se muestra un comparativo de la cantidad de interrupciones

de cada timer, con tick (TP) y sin tick (STP) periódico, al realizar la lectura periódica de

un sensor de período fijo 1 segundo.

Datalogger Tick Cantidad de Int

TP 250ms 4

TP 7.8ms 128

STP TimeOut Raíz 1

Tabla 8

De la tabla 8 se concluye qué, con un timer de tick periódico (TP) de valor 7.8ms y

250ms tenemos que esperar 128 y 4 interrupciones respectivamente para leer el sensor,

en comparación con una sola interrupción al utilizar un timer sin tick periódico.

18

Como se observó anteriormente, la no utilización de TP disminuye el ciclo de trabajo

del microprocesador lo que equivale en una mejora en el consumo del mismo.

A continuación se exhiben fotos tomadas del ejemplo anterior en el cual se lee un sensor

cada 1 segundo para un timer con tick y sin tick periódico.

Tick de 7.8ms

Se observa unas 13 interrupciones en

una ventana de 100ms. Lo cual

equivale aproximadamente a 128

interrupciones por cada segundo

transcurrido.

Figura 11

Sin Tick Periódico

Se observa 1 interrupción por cada

segundo transcurrido.

Figura 12

19

Conclusiones

Durante el desarrollo del proyecto pudimos hacer uso de herramientas impartidas en el

curso tales como el uso de punteros y de estructuras en la implementación de la lista

encadenada, el concepto de modularización y la configuración de los módulos del

microcontrolador tales como el timer.

Se logró implementar un modulo que proporciona un servicio de timer sin tick periódico

e integrarlo al datalogger 2012.

El consumo de potencia resulto ser menor al integrar nuestro modulo. Este beneficio es

más evidente cuanto menor sea el tiempo de tick del sistema original.

Como contra partida el sistema con nuestro modulo integrado utiliza mayores recursos

de memoria.

La limitante más importante del modulo implementado es el uso de la función malloc

para crear nodos en el modulo que maneja la lista encadenada. Esto puede provocar

fragmentación de memoria en el caso de ser utilizado junto con otro sistema que

también utilice esta función. En el caso de datalogger que no utiliza la función malloc,

el uso del mismo no genera fragmentación ya que siempre se reserva y se libera

variables del mismo tamaño de memoria.

Otra limitante de menor peso es que ningún sensor puede solicitar un timeOut mayor a

15.99s.

20

Referencias Bibliográficas

1. “Técnicas de bajo consumo para aplicaciones de tipo ”datalogger” utilizando un

MSP430” – Francisco Veirano, Alberto Sebastián Besio y Pablo Sebastián Pérez

- Proyecto del curso de Sistemas Embebidos - 2012

2. “A Real-Time Kernel for Wireless Sensor Networks Employed in Rescue

Scenarios” - Heiko Will, Kaspar Schleiser and Jochen Schiller - Institute of

Computer Science - Computer Systems and Telematics - Freie Universität

Berlin, Germany.

3. “Power Management Implementation in FreeRTOS on LM3S3748” - Mirela

Simonović and Lazar Saranovac - Belgrade, Serbia.

4. “RETOS: Resilient, Expandable, and Threaded Operating System for Wireless

Sensor Networks” - Hojung Cha, Sukwon Choi, Inuk Jung, Hyoseung Kim,

Hyojeong Shin, Jaehyun Yoo, Chanmin Yoon - Department of Computer

Science - Yonsei University, Seoul, Korea.

5. “Wireless Sensor Network for Habitat Monitoring on Skomer Island” - Tomasz

Naumowicz, Robin Freeman, Holly Kirk, Ben Dean, Martin Calsyn, Achim

Liers, Alexander Braendle, Tim Guilford, Jochen Schiller.