sistemas embebidos para tiempo real curso 2013 · 2018. 3. 13. · finalmente existen ejemplos de...
TRANSCRIPT
-
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.