Transcription
Universidad de la RepúblicaFacultad de IngenieríaInstituto de Ingeniería EléctricaSistemas Embebidos para Tiempo RealCurso 2013- Informe Final-Grupo: 2NombreIntegrantes: Matías ValdésFederico VanziniFernando VieraTutor:Leonardo Steinfeld1
ÍndiceIntroducción . 3Resumen . 3Descripción del problema a ser resuelto . 3Objetivo del proyecto . 4Antecedentes. 5Alcance . 6Implementación . 6Plataforma de hardware . 6Configuración del Timer . 7Modulo lista Encadenada. 8Modulo gestorHora . 9ISR del Timer . 11Evaluación de Performance y Resultados . 12Puntos de comparación . 12Ciclos de trabajo . 12Potencia media . 16Uso de memoria . 17Cantidad de Interrupciones del Timer . 17Conclusiones . 19Referencias Bibliograficas . 202
IntroducciónResumenEl proyecto consistió en implementar un modulo que brinde el servicio de timer sin tickperiódico a un sistema embebido.Para el manejo de timeOuts se implemento una lista encadenada para almacenar lostiempos de timeOuts y funciones para su manejo que permiten agregar, quitar ydecrementar timeOuts de la lista.Se desarrollo un modulo que permite configurar el timer de forma dinámica según elpróximo tiempo de TimeOut.Para el manejo del tiempo transcurrido de ejecución se desarrollo un modulo quepermite 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 aspectostales como el consumo de potencia, memoria utilizada, cantidad de ticks por segundo yciclos de trabajoDescripción del problema a ser resueltoEn un sistema embebido el manejo del tiempo se basa en interrupciones periódicas deltimer.Este incrementa un tick de forma periódica, el cual es usado para ofrecer servicios degestión de tiempos a los distintos módulos del sistema.Para expresar de manera intuitiva lo que se pretende lograr, se presenta a continuaciónla siguiente imagen en la que se puede observar la secuencia de lectura de 2 sensores, detiempo de lectura (timeout) 3 y 1 segundos respectivamente para un sistema con tickperiódico y otro sin tick periódico como el que se desea implementar.Figura 13
En la figura 1 se puede observar una cantidad de 12 interrupciones (ticks) de un timercon tick periódico (TCTP) requeridas para leer el primer sensor contra 1 solainterrupción del timer sin tick periódico (TSTP).De igual modo se observa una diferencia de 3 interrupciones entre ambos timer para leerel siguiente sensor en un tiempo de 1 segundo.Menor número de interrupciones conlleva en un menor ciclo de trabajo, lo cual podríatraducirse en un ahorro de consumo al hacer uso de los modos de bajo consumo delmicroprocesador.El modulo a implementado puede ser usado por ejemplo para ejecutar de maneradiferida una función, gestionar timeouts, llevar la hora del sistema, etc.Para contar cierto tiempo arbitrario se contabilizan ticks obteniendo tiempos múltiplosde este. Para lograr una buena resolución temporal se requieren ticks relativamentecortos. Por otro lado, elegir ticks cortos aumenta la frecuencia de las interrupcionesincrementando el consumo de energía.Objetivo del proyectoEl objetivo es implementar un modulo de timer sin tick periódico para ser integrado encualquier aplicación.Para probar el módulo funcionando en una aplicación real se integrará el mismo a laaplicación Datalogger (proyecto de curso 2012).Luego se utilizará la aplicación para comparar la performance de la aplicación con y sinel modulo implementado.Además de dar la funcionalidad básica (que el timer interrumpa cuando haya pasado eltiempo correspondiente) se deberán implementar otras funcionalidades relacionadas conel uso del timer como llevar el reloj del sistema.4
AntecedentesAunque la mayor parte de los sistemas operativos embebidos utiliza un tick periódicopara su funcionamiento, existen ejemplos de sistemas operativos embebidos queproveen un servicio de timer sin tick. Un ejemplo de esto es el sistema operativoRETOS que implementa un timer de tiempo variable que es reconfigurado según elpróximo tiempo de timeout [4].También se encuentran ejemplos de sistemas operativos que han sido portados a algúnmicrocontrolador en particular y modificados para proveer un servicio de timer sin tick.El sistema operativo FreeRTOS por ejemplo ha sido modificado para proveer un timersin tick en el microcontrolador LM3S3748 [3].Finalmente existen ejemplos de desarrollos de sistemas embebidos específicos queincorporan el concepto de timer sin tick. En el área de las redes de sensoresinalámbricos se encuentran ejemplos de esto en escenarios de rescate [2] y en elmonitoreo de hábitats naturales [5].5
AlcanceEl 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 eventosqueda fuera del alcance de este proyecto.El proyecto incluye el desarrollo de funciones para el manejo de los tiempos deTimeOut y configuración dinámica del timer.Dentro del alcance consideramos también la realización de medidas para comprobar eldesempeño del sistema desarrollado frente a uno que utiliza un tick periódico.ImplementaciónPlataforma de hardwareComo plataforma de desarrollo se utilizó la placa MSP-TS430PZ5x100 de TexasInstruments junto con un microcontrolador MSP430F5438.Figura 2: Placa de desarrollo utilizadaEsta placa cuenta con un oscilador de cristal de 32768Hz el cual fue utilizado comoreloj fuente para el timer del microcontrolador.6
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 delmicrocontrolador no son los mismos que utiliza la PC para comunicarse a través de supuerto serie, se utilizó también una placa convertidora de niveles de tensión. Esta últimautiliza un circuito integrado MAX3232C.Configuración del TimerPara configurar el Timer usamos un módulo llamado „confTimer‟ mediante el cual seconfigura el timer B0 utilizando un registro de largo 16 bits para cargar las cuentas y unreloj auxiliar de 32768 Hz.En la tabla 1 se presenta el tiempo máximo y mínimo de los períodos de tick que sepueden conseguir mediante la selección del prescaler correspondiente:Tabla 1:Dadas las diferentes escalas se optó por utilizar un prescaler de 8 priorizando un mayoralcance de tiempo de TimeOut máximo, considerando éste como una limitante dediseño.Con un prescaler de 8 para disminuir la frecuencia, configurando el timer para operar enmodo UP (incrementando repetidamente TBR de 0 hasta el valor del registrocomparador) se alcanza una resolución de (32768/8) -1 244us, el equivalente a 1cuenta.Esta elección nos da una limitación de timeOut máximo de (216)/4096 16 seg, que eslo que alcanza el registro de 16 bits.7
Modulo lista EncadenadaPara implementar el Timer Sin Tick periódico se desarrollo un modulo llamadoListEncadenada que implementa una lista, cada elemento de la misma es un nodo y a suvez cada nodo es una estructura como se muestra en la figura 3.Figura 3Los 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 cadavez que un sensor es agregado a la lista, se agregará de forma ordenada según sutimeOut, 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 losnodos en una cantidad igual al timeOut del nodo raíz.La función procesarSensores() incluida en la ISR del timer es quien utiliza el modulolistaEncadena para realizar el manejo de los tiempos de lectura de los sensores, dichafunción es analizada en la sección ISR del Timer.Debemos mencionar que el uso de la lista encadenada hizo necesario la modificación dela función reset() incluida dentro de los comandos ejecutables por el usuario, paramantener su funcionamiento la función reset modificada remueve todos los nodosexistentes excepto el nodo raíz, utilizando para esto la función quitarTimeout() delmodulo listaEncadenada .8
Modulo gestorHoraLa aplicación Datalogger utiliza una función que incrementa el tiempo transcurrido deejecución en cada interrupción. Es decir, al tener un tick periódico incrementa el reloj enun valor equivalente a ese tick.Para adaptar ésta función a un tick dinámico se procedió a diseñar una nueva manera deincrementar el tiempo correspondiente a cada valor de timeout.Se eligió trabajar con una variable de 16bits en la que guardamos la cantidad de cuentasa incrementar (valor obtenido del registro del Timer llamado TBR) o lo que esequivalente, el número total de resoluciones de la escala elegida. Por ejemplo, en el casodel Datalogger con timer sin tick cada cuenta equivale a un incremento de 244us (1resolución).El algoritmo utiliza la representación en punto fijo para evitar usar otras más complejascomo float, que facilita las cosas pero incrementaba bastante el tiempo de atención a lainterrupción del timer (ciclo de trabajo).En la figura 4 se puede observar, a modo de esquema, el procedimiento utilizado paraconocer, a partir del número de cuentas los segundos y milisegundos equivalentes conuna resolución de 244us.Para calcular los segundos se corren los bits de la palabra a la derecha tantos lugarescomo la potencia correspondiente a las cuentas definidas para 1seg. En este caso 1segundo son 212 4096 cuentas. Estos son 12 lugares a la derecha para obtener lainformación de los segundos.Para obtener la cantidad de cuentas correspondientes a los milisegundos (cantidad deresoluciones 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) yal resultado se lo multiplica x1000 para pasar a milisegundos.9
Figura 4Nota: En el ejemplo de la figura se contaron 11.395 segundos11 segundos 1950*(2 -12)*(1000) 395 ms10
ISR del TimerUna de las modificaciones más relevantes que se realizaron al datalogger 2012 fue lamodificación realizada en la ISR del Timer. La rutina original controlaba en cadainterrupción si algún sensor debía ser leído es decir si había expirado o no algúntimeOut y en caso de ser afirmativo lo mandaba leer. Nuestro sistema solo interrumpecuando expira el timeout del nodo raíz, es decir que cuando interrumpe siempre debemandar a leer al menos un sensor, es por ello que luego de la modificación el flujo de larutina quedo como se muestra la figura 5.Diagrama de flujo de la ISR del Timer:Función que incrementa el tiempo transcurrido deejecución del sistema.Función que decrementa los TimeOut de todos losnodos.Función que procesa los sensores.Función que re configura el Timer con el próximotiempo de TimeOut de la lista.Figura 5La función procesarSensores() que manda a leer los sensores fue implementada pornosotros y fue incluida en el modulo ya existente llamado datalogger, su finalidad esprocesar los sensores cuyos timeOuts hayan expirado, para ello primero manda a leer elsensor, luego lo quita de la lista y finalmente lo agrega nuevamente con el mismotimeOut ya que los sensores se leen de forma periódica. Como se dijo anteriormente lafunciones utilizadas son las incluidas en el modulo listaEncadenada.11
Evaluación de Performance y ResultadosPuntos de comparaciónEn la siguiente comparación se consideran tres variantes del Datalogger:1. Datalogger original con un tick periódico de 250ms2. Datalogger con un tick periódico de 7.8ms3. Datalogger sin tick periódico implementado en este proyecto de cursoSe utilizo la variante 2 para hacer más notoria la diferencia con el sistema sin tickperiodico, en esta variante se modifica también la función que incrementa la hora delsistema utilizándose la implementada para el Datalogger sin tick periódico.Los puntos que consideramos de importancia para comparar el desempeño entre lasdistintas variantes del Datalogger son:1. Ciclo de trabajo2. Consumo de potencia media3. Cantidad de interrupciones por segundo4. Memoria ocupada por el código y los datosComo 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 delmicrocontrolador 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 de1 segundo.Ciclos de trabajoEn el caso de un Datalogger con tick periódico (CTP), la señal que se observa en elosciloscopio es una onda rectangular con un periodo igual al tiempo de tickcorrespondiente. El ciclo de trabajo se define entonces en este caso como el cocienteentre el tiempo en que la señal no es nula (ton) a lo largo de un periodo y el tiempo detick:Figura 612
Los valores medidos en este caso fueron los siguientes:Tiempo de Ticktond (ton/ttick)*100250ms235us0.094%7.8ms304us3.9%Tabla 2:En el caso del Datalogger sin tick periódico (STP), la señal es también rectangular perocon un periodo igual al periodo del sensor. En el ejemplo que se está considerando esteperiodo es de 1 segundo. Por lo tanto el ciclo de trabajo es igual al tiempo en que laseñal es no nula a lo largo de un periodo de 1 segundo:Figura 7Los valores medidos fueron:Ttotal Ttond (ton/ttotal)*1001s418us0.042%Tabla 3:13
En las siguientes imágenes se pueden ver las señales medidas en el osciloscopio encada caso:Figura 8: Datalogger con tiempo de tick de 250msFigura 9: Datalogger con tiempo de tick de 7.8ms14
Figura 10: Datalogger sin tick periódico15
Potencia mediaDado que el microcontrolador se encuentra en modo “sleep” cuando no debe procesarinterrupciones provenientes del Timer, la UART o el ADC, es posible expresar lapotencia media total consumida por este mediante:Aplicando esta expresión para el Datalogger CTP y STP, se puede obtener la siguienteexpresión que da la diferencia absoluta de potencia consumida por el Datalogger CTPrespecto al Datalogger STP:Se observa entonces que la diferencia de potencia es directamente proporcional a ladiferencia de ciclos de trabajo.La constante de proporcionalidad la obtuvimos de las medidas de potencia realizadasdurante el proyecto de curso Datalogger 2012. Para el caso del microcontroladorfuncionando a una frecuencia de trabajo de 8MHz la potencia activa media es del ordende 3mW. Por otro lado para la potencia en modo sleep tomamos el peor caso dado porla cota superior de unos 500uW. Con estos valores se obtiene una constante deproporcionalidad de 3mW-500uW 2.5mW.A partir de esto y previo cálculo de la diferencia de ciclos de trabajo, se llega a lossiguientes valores para la diferencia absoluta de potencia media consumida:Tiempo de TickPTP-PSTPSTP vs. 250ms1.30uWSTP vs. 7.8ms96.5uWTabla 4Para hallar la diferencia relativa de potencia media consumida, utilizamos la expresióninicial que nos da los siguientes valores de potencia media:Tiempo de TickPSTP250ms502.35uW7.8ms597.5uWTabla 516
Por lo tanto se obtiene finalmente que el ahorro de potencia con un sistema STPrespecto a uno CTP viene dado en cada caso por:Tiempo de Tick(PTP-PSTP/PTP)*100STP vs. 250ms0.26%STP vs. 7.8ms16.14%Tabla 6Uso de memoriaEl cuadro a continuación es un comparativo en el cual se muestra el tamaño de memoriaque ocupan las aplicaciones Datalogger con tick (TP) y sin tick (STP) 83022718150012520STP92042922149613622Memoria en bytesTabla 7En la tabla 7 se puede observar un consumo en recursos de 12520 bytes en TP contra13622 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 TimerEn el cuadro a continuación se muestra un comparativo de la cantidad de interrupcionesde cada timer, con tick (TP) y sin tick (STP) periódico, al realizar la lectura periódica deun sensor de período fijo 1 segundo.DataloggerTickCantidad de IntTP250ms4TP7.8ms128STPTimeOut Raíz1Tabla 8De la tabla 8 se concluye qué, con un timer de tick periódico (TP) de valor 7.8ms y250ms 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.17
Como se observó anteriormente, la no utilización de TP disminuye el ciclo de trabajodel 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 sensorcada 1 segundo para un timer con tick y sin tick periódico.Tick de 7.8msSe observa unas 13 interrupciones enuna ventana de 100ms. Lo cualequivale aproximadamente a 128interrupciones por cada segundotranscurrido.Figura 11Sin Tick PeriódicoSe observa 1 interrupción por cadasegundo transcurrido.Figura 1218
ConclusionesDurante el desarrollo del proyecto pudimos hacer uso de herramientas impartidas en elcurso tales como el uso de punteros y de estructuras en la implementación de la listaencadenada, el concepto de modularización y la configuración de los módulos delmicrocontrolador tales como el timer.Se logró implementar un modulo que proporciona un servicio de timer sin tick periódicoe integrarlo al datalogger 2012.El consumo de potencia resulto ser menor al integrar nuestro modulo. Este beneficio esmás evidente cuanto menor sea el tiempo de tick del sistema original.Como contra partida el sistema con nuestro modulo integrado utiliza mayores recursosde memoria.La limitante más importante del modulo implementado es el uso de la función mallocpara crear nodos en el modulo que maneja la lista encadenada. Esto puede provocarfragmentación de memoria en el caso de ser utilizado junto con otro sistema quetambié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 liberavariables del mismo tamaño de memoria.Otra limitante de menor peso es que ningún sensor puede solicitar un timeOut mayor a15.99s.19
Referencias Bibliográficas1. “Técnicas de bajo consumo para aplicaciones de tipo ”datalogger” utilizando unMSP430” – Francisco Veirano, Alberto Sebastián Besio y Pablo Sebastián Pérez- Proyecto del curso de Sistemas Embebidos - 20122. “A Real-Time Kernel for Wireless Sensor Networks Employed in RescueScenarios” - Heiko Will, Kaspar Schleiser and Jochen Schiller - Institute ofComputer Science - Computer Systems and Telematics - Freie UniversitätBerlin, Germany.3. “Power Management Implementation in FreeRTOS on LM3S3748” - MirelaSimonović and Lazar Saranovac - Belgrade, Serbia.4. “RETOS: Resilient, Expandable, and Threaded Operating System for WirelessSensor Networks” - Hojung Cha, Sukwon Choi, Inuk Jung, Hyoseung Kim,Hyojeong Shin, Jaehyun Yoo, Chanmin Yoon - Department of ComputerScience - Yonsei University, Seoul, Korea.5. “Wireless Sensor Network for Habitat Monitoring on Skomer Island” - TomaszNaumowicz, Robin Freeman, Holly Kirk, Ben Dean, Martin Calsyn, AchimLiers, Alexander Braendle, Tim Guilford, Jochen Schiller.20
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
