Escuela Politcnica Superior Universidad de Huelva Departamento de Ing.

Electrnica, Sistemas Informticos y Automtica

Tema 5: Introduccin a STR

TERCER CURSO. INFORMTICA INDUSTRIAL II

Manuel Snchez Raya Versin 0.7 2 de Octubre de 2009

INFORMTICA INDUSTRIAL II NDICE

Introduccin a multitarea y STR

5.1.- Introduccin a la multitarea y los sistemas de Tiempo Real................................................. 2 5.1.1.- Las ideas bsicas. Como implementar la multitarea y el tiempo real. ........................... 2 5.1.1.1.- Multitarea tareas, prioridades y plazos. ............................................................... 2 5.1.1.2.- Qu es "tiempo real"?............................................................................................ 4 5.1.2.- Como conseguir multi-tarea mediante simple programacin secuencial....................... 5 5.1.2.1.- Evaluacin del bucle principal. ........................................................................... 5 5.1.2.2.- Tareas disparadas por tiempo y disparadas por eventos. ........................................ 6 5.1.2.3.- Empleo de las interrupciones para la fijacin de prioridades, la estructura primer plano / trasfondo.................................................................................................................... 6 5.1.2.4.- Introduccin de un "tick de reloj" para sincronizar la actividad del programa. ...... 7 5.1.2.5.- Un sistema operativo de propsito general. ........................................................ 7 5.1.2.6.- Los lmites de la programacin secuencial para hacer multi-tarea. ........................ 8 5.2.- El sistema operativo de tiempo real (RTOS) ........................................................................ 9 5.3.- La planificacin y el planificador. ........................................................................................ 9 5.3.1.- Planificacin cclica. ...................................................................................................... 9 5.3.2.- Planificacin Round Robin y cambio de contexto....................................................... 10 5.3.3.- Estados de las Tareas. .................................................................................................. 11 5.3.4.- Planificacin pre-emptiva con prioridades. ................................................................. 12 5.3.5.- Planificacin Cooperativa............................................................................................ 14 5.3.6.- El papel de las interrupciones en la planificacin........................................................ 14 5.4.- El desarrollo de las tareas. .................................................................................................. 15 5.4.1.- La definicin de las tareas............................................................................................ 15 5.4.2.- Escritura de las tareas y establecimiento de prioridades.............................................. 15 5.5.- La proteccin de los Datos y recursos - el semforo. ......................................................... 16 5.6.- El Sistema Operativo Salvo. ............................................................................................... 17 5.7.- La idea principal - Salvo, un RTOS de ejemplo. ................................................................ 17 5.7.1.- Caractersticas bsicas de Salvo................................................................................... 17 5.7.2.- Versiones de Salvo y referencias. ................................................................................ 18 5.7.3.- Configuracin de la aplicacin Salvo. ......................................................................... 18 5.7.3.1.- Programacin de aplicaciones Salvo - construir la librera................................... 19 5.7.3.2.- Las libreras de Salvo............................................................................................ 19 5.7.4.- Escritura de programas con Salvo............................................................................... 20 5.7.4.1.- Inicializacin y planificacin. ............................................................................... 20 5.7.4.2.- Escribiendo las tareas en Salvo............................................................................. 22

Bibliografa:
Tim Wilmshurst. Designing embedded systems with PIC microcontrollers : principles and applications. Newnes, 2007. Richard Barnett, Larry OCull, Sarah Cox, Embedded C Programming and the Microchip PIC. Thomson Delmar Learning, 2004.

Kenneth L. Short. Embedded microprocessor systems design. Prentice-Hall, 1.998.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica Pg. 1/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.1.- Introduccin a la multitarea y los sistemas de Tiempo Real.

Casi todos los sistemas empotrados necesitan llevar a cabo ms de una actividad. Un programa para un robot, por ejemplo, debe tener el control de su entorno a travs de diversos sensores, medir la distancia que se ha movido y, por tanto, calcular y aplicar los valores al sistema de control de motores. A medida que un sistema se vuelve ms complicado, cada vez es ms difcil equilibrar las necesidades de las diferentes tareas que realiza. Cada una de ellas competir por tiempo de CPU y por lo tanto pueden causar retrasos en otras actividades del sistema. El programa necesita una manera de dividir su tiempo correctamente entre las diferentes exigencias establecidas por la tarea a realizar. Un importante aspecto paralelo a la necesidad de compartir el tiempo de la CPU es la necesidad de garantizar que las cosas tienen lugar en el momento adecuado. Esto es muy importante en prcticamente todos los sistemas empotrados, y el problema empeora cuando hay varias actividades que compiten por la atencin de la CPU. Este captulo analiza las necesidades de los sistemas que tienen muchas cosas que hacer. Investiga los problemas y desarrolla una estrategia para tratar con ellos: el sistema operativo de tiempo real. Esto nos conduce a un enfoque completamente nuevo de la programacin: ya no es la secuencia del programa lo que determina lo que va a pasar, si no que es el sistema operativo el que lo controla. 5.1.1.- Las ideas bsicas. Como implementar la multitarea y el tiempo real. Muchos de nosotros en este complejo mundo moderno ocupamos nuestras vidas haciendo multi-tarea. Un padre puede necesitar tener dos o tres nios listos para ir a la escuela: uno ha perdido un calcetn, otro se siente enfermo y el otro ha derramado la leche. Y el perro tiene que alimentarse, la olla est hirviendo y se derrama, el cartero est en la puerta y el telfono est sonando. Hay que realizar muchas actividades, pero slo podemos hacer una cosa a la vez. El microcontrolador en un sistema empotrado puede sentirse acosado del mismo modo. Puede rodearse de muchas actividades por hacer, cada una exige su atencin. Tendr que decidir qu hacer primero y qu se puede dejar para ms tarde. Empezamos este captulo mediante la exploracin de la naturaleza del concepto de multi-tarea y del concepto tiempo real. 5.1.1.1.- Multitarea tareas, prioridades y plazos. La Figura 5.1 muestra un diagrama de flujo simplificado de un programa, un programa para que un robot realice un seguimiento de luz.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 2/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

El programa se compone de una serie de actividades distintas, cada una de las cuales aparece en la figura. Vamos a adoptar de inmediato la prctica de llamar a estas actividades tareas. Una tarea es un trozo del programa o seccin que tiene una finalidad y resultado claro y distinto. El concepto multi-tarea, simplemente describe una situacin en la que hay muchas tareas que deben realizarse, a ser posible de manera simultnea. En este ejemplo se identifican cuatro tareas. El programa est estructurado de manera que cada tarea se coloca en un bucle principal y cada una se ejecuta secuencialmente. Una de las tareas, la salida a pantalla (cuando los datos se enva al controlador para mostrarse en la pantalla LCD), se ejecuta slo una vez cada 10 ciclos del bucle. El bucle finaliza con un retraso, lo que determina la tasa de repeticin de bucle y, por tanto, influye en las caractersticas de temporizacin del programa.

Figura 4.1 Diagrama de flujo simplificado del sistema de bsqueda de luz de un robot.

Este es un ejemplo muy sencillo de multi-tarea. El programa tiene que realizar una serie de tareas. Las va realizando estrictamente en rotacin, realizando un pequeo descanso antes de comenzar otra vez. En realidad, las tareas no son todas de igual importancia. Volviendo a los acosados padres: si el telfono suena, el perro probablemente tenga que esperar para recibir su cena. Por lo tanto, reconocemos que diferentes tareas tienen diferentes prioridades. Una tarea de alta prioridad debe tener derecho a ejecutarse antes que una tarea de baja prioridad. Cada tarea tambin tiene un plazo, o podra tenerlo de forma estimada. El telfono tiene que ser descolgado en 30 segundos, en caso contrario la persona que llama cuelga; los nios tienen que estar listos para salir de casa a las 8.30 horas, en caso contrario pierden el autobs, y as sucesivamente. El concepto de las prioridades est vinculado al de los plazos. En general, una tarea con un plazo estricto requiere un alto grado de prioridad.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 3/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Las tareas de este programa de ejemplo se muestran en la tabla siguiente, junto con alguna clasificacin preliminar. Se emplean tres niveles de prioridad, con tres plazos estimados. Para la asignacin de prioridades, la pulsacin de un microinterruptor porque se haya detectado un obstculo, es considerada como una emergencia, el robot ha chocado con algo y el motor probablemente se ha estancado. Por lo tanto, es de alta prioridad. En cambio, el usuario humano apenas se dar cuenta si la funcin de visualizacin se ha retrasado un segundo o menos. Por lo tanto, esta ltima puede ser de menor prioridad.

5.1.1.2.- Qu es "tiempo real"? Cmo funciona el programa del robot para bsqueda de luz, o cmo se relacionan los padres acosados con el concepto de tiempo real? El concepto es ampliamente usado, pero a menudo parece estar rodeado de una cierta mstica. Una definicin simple pero efectiva de funcionamiento en tiempo real, es la siguiente: Un sistema operativo en tiempo real debe ser capaz de proporcionar resultados correctos los plazos de tiempo sealados. Observemos que esta definicin no significa que el trabajo en tiempo real implique alta velocidad, aunque a menudo esto puede ayudar. Simplemente indica que lo que se necesita debe estar listo en el momento en que se necesita. Por lo tanto, si el padre lleva a todos los nios a la escuela a tiempo, alimenta al perro antes de que empiece a aullar, abre la puerta al cartero antes de que se vaya y contesta al telfono antes de la persona que llama cuelgue, entonces los requisitos de tiempo real de este entorno se han cumplido. Del mismo modo, si el robot cumple todos los plazos cuantificados en la tabla, podemos afirmar que tambin opera en tiempo real. Detrs de esta simple definicin, y todo lo que implica, se encuentra una multitud de desafos en el diseo del programa. El resto de este captulo constituye una introduccin a estos desafos, y sobre cmo pueden ser resueltos.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 4/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.1.2.- Como conseguir multi-tarea mediante simple programacin secuencial. El tipo de programacin que hemos realizado hasta a la fecha, ya sea en ensamblador o C, se denomina programacin secuencial. Esto simplemente significa que el programa se ejecuta de forma normal, cada una de las instrucciones o sentencias sigue a la anterior, a menos que el programa ejecute un salto, o tenga lugar una llamada a subrutina o funcin. Ms adelante en este captulo nos vamos a desmarcar de este tipo de programas. Por ahora, vamos a estudiar cmo se puede optimizar esta estructura para aplicaciones multi-tarea, abordando algunas de las debilidades de la estructura del programa de la figura 5.1. 5.1.2.1.- Evaluacin del bucle principal. Este programa parece funcionar bastante bien, pero esto se debe principalmente a que no es muy exigente en sus necesidades. Veamos algunos de sus inconvenientes, todos ellos relacionados entre s: El tiempo de ejecucin del Bucle no es constante. El tiempo que tarda en ejecutarse el bucle una vez es igual a la suma de los tiempos de cada tarea, ms el tiempo de retardo. Evidentemente, esto puede variar. Si, por ejemplo, se activa un sensor, el robot para y luego se da la vuelta. Esto provoca una ejecucin larga del bucle, que puede alterar alguna otra actividad del bucle. Las tareas interfirieren unas con otras. Una vez que una tarea tiene la posibilidad de ejecutarse, mantendr ocupada a la CPU hasta que se haya completado lo que necesite hacer. De acuerdo, cada una de las tareas est escrita de manera que no debera tardar mucho tiempo. Supongamos, sin embargo, que la tarea de la pantalla empieza a ejecutarse y el robot de repente golpea una pared. El procesador seguir enviando datos a la pantalla y luego completar la rutina de retardo antes de que se d cuenta que se ha producido una situacin de emergencia. Las tareas de alta prioridad no reciben la atencin que necesitan. Ya hemos reconocido que algunas tareas son ms importantes que otras. Por lo tanto, deben tener mayor prioridad, un concepto que ya se han tratado en el contexto de las interrupciones. En esta estructura de bucle continuo, cada tarea tiene la misma prioridad.

Tenemos que encontrar una forma de estructuracin de programas que reconozca la naturaleza y las necesidades de las tareas que contiene, y que pueda satisfacer sus demandas de tiempo real.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 5/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.1.2.2.- Tareas disparadas por tiempo y disparadas por eventos. Es fcil reconocer que algunas tareas se activan por tiempo (time triggered) y otras por eventos (event triggered). Una tarea activada por tiempo se produce al trmino de un cierto perodo de tiempo y suele ser peridica. Un ejemplo de ello es la lectura de los sensores de luz en este programa. Las tareas disparadas por eventos se producen cuando un tiene lugar un determinado evento. En este caso, la deteccin de un obstculo con el sensor correspondiente es un buen ejemplo. 5.1.2.3.- Empleo de las interrupciones para la fijacin de prioridades, la estructura primer plano / trasfondo. Para solucionar el problema de la falta de prioridades entre las tareas en el programa de seguimiento de luz, sera posible convertir las tareas de alta prioridad en interrupciones. Estas interrupciones tomarn el control de la CPU tan pronto como sea necesario, sobre todo si slo se utiliza una interrupcin. La estructura de programa ser la siguiente:

Figura 4.2 Empleo de interrupcin para priorizar en el programa de bsqueda de luz.

Es muy probable que las tareas en el bucle vengan disparadas por tiempo, las cuales podrn utilizar la tasa de repeticin del bucle como base de tiempo. Las tareas dirigidas por interrupciones es probable que vengan disparadas por eventos. Con esta estructura simple del programa hemos logrado una tasa de repeticin fiable para las tareas del bucle, y adems hemos priorizado las tareas que lo necesitan. Esta estructura del programa se denomina estructura en primer plano/trasfondo (foreground/background). Las tareas con mayor prioridad vienen dirigidas por interrupciones en el primer plano (cuando tienen que ejecutarse), mientras que las tareas de menor prioridad se ejecutan en el bucle de forma casi continua en segundo plano.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 6/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.1.2.4.- Introduccin de un "tick de reloj" para sincronizar la actividad del programa. Para minimizar el impacto de la variacin de tiempos en la ejecucin de las tareas sobre el tiempo de ejecucin del bucle, es posible disparar el bucle completo mediante una interrupcin peridica, por ejemplo, mediante el desbordamiento de un timer. El programa entonces tendra la estructura de la figura 5.3. El bucle principal se dispara por el desbordamiento de un timer, de forma que se produce con una cadencia fija y fiable. Las tareas dirigidas por tiempo pueden basar su actividad en su tasa de repeticin. Las tareas dirigidas por eventos, a travs de interrupciones, se pueden producir cuando sea necesario. Las temporizaciones de las tareas, por supuesto, tienen que ser calculadas y controladas, de modo que el bucle tenga tiempo suficiente para ejecutarse en los plazos previstos, y las tareas dirigidas por eventos no perturben demasiado el carcter repetitivo del bucle de temporizacin. La idea de emplear una interrupcin del timer usada de esta forma para sincronizar la actividad del programa se ha comentado ya en prcticas y se ilustra en la Figura 5.3. Como se ha mencionado ya, a esta interrupcin se la denomina tick de reloj. La idea es simple, pero resulta fundamental para muchas estructuras de programa que vamos a considerar. El tick de reloj no debe confundirse con el propio oscilador de reloj, a pesar de que el tick normalmente viene derivado del oscilador.

Figura 4.3 Empleo de una interrupcin del Timer en el programa de bsqueda de luz.

5.1.2.5.- Un sistema operativo de propsito general. La estructura que aparece en la Figura 5.3 se puede abstraer en un sistema operativo de propsito general, como se muestra en la Figura 5.4. Aqu el bucle principal contiene una serie de tareas de prioridad baja o media. Este bucle se ejecuta mediante un tick de reloj.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 7/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

La estructura general de cada una de las tareas se muestra a la izquierda. Segn sea necesario, cada tarea tiene un bit de habilitacin (un bit en una direccin de memoria) y cada uno tiene un contador de tarea. Las tareas que se deben ejecutar cada tick de reloj lo harn. Algunas tareas slo tienen que ejecutarse con menos frecuencia, con un intervalo de tiempo fijado por el valor de su contador de tarea. Las tareas se pueden activar o desactivar mediante la puesta a uno o la puesta a cero de su bit de habilitacin, ya sea mediante la ejecucin de otras tareas o por las interrupciones.

Figura 4.4 Estructura de sistema operativo de propsito general, usando programacin secuencial.

5.1.2.6.- Los lmites de la programacin secuencial para hacer multi-tarea. El enfoque de la programacin de mltiples tareas que acabamos de describir por lo general ser aceptable, siempre y cuando: No existen demasiadas tareas Las prioridades de las tareas puedan tener cabida en la estructura Las tareas tengan un comportamiento moderadamente bueno, por ejemplo, su exigencia de tiempo de CPU debe ser siempre razonable y las tareas dirigidas por interrupcin no se produzcan con demasiada frecuencia.

Si no se cumplen estas condiciones, hay que considerar una estrategia de programacin radicalmente distinta. El candidato natural es el sistema operativo de tiempo real.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 8/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.2.- El sistema operativo de tiempo real (RTOS)

Cuando se emplea un verdadero sistema operativo, nos alejamos de las hiptesis de la secuencia normal de la programacin. En lugar de ello, vamos a entregar el control de la CPU y todos los recursos del sistema al sistema operativo. Es el sistema operativo, el que ahora determina el trozo de programa que se ejecuta y durante cunto tiempo, y cmo se accede a los recursos del sistema. El programa de aplicacin est sometido al sistema operativo y est escrito de forma que reconozca las necesidades del sistema operativo. Debido a que estamos preocupados por satisfacer las necesidades de tiempo real, hacemos uso de un tipo particular de sistema operativo que cumpla este requisito, el Sistema Operativo en Tiempo Real (RTOS). Un programa escrito para un RTOS est estructurado mediante tareas, generalmente (pero no siempre) por orden de prioridad, que son controladas por el sistema operativo. El RTOS realiza tres funciones principales: Decide qu tarea debe realizar y durante cuanto tiempo Proporciona comunicacin y sincronizacin entre tareas Controla la utilizacin de los recursos compartidos entre las tareas, por ejemplo, la memoria y los perifricos hardware. Un RTOS en s mismo es un programa de propsito general. Est adaptado para una aplicacin particular mediante la escritura de las tareas para ella y por la personalizacin de la aplicacin de varias maneras. Si bien podemos escribir nuestro propio RTOS, realmente es una actividad especializada y, en general, realizada por especialistas.

5.3.- La planificacin y el planificador.

Una parte central del RTOS es el planificador. Este determina a que tarea se le permite ejecutarse en un determinado momento. Entre otras cosas, el planificador debe ser consciente de qu tareas estn listas para ejecutarse y sus prioridades (si las tuvieran). Hay una serie de estrategias de planificacin fundamentalmente diferentes, que consideramos ahora. 5.3.1.- Planificacin cclica. La planificacin cclica es simple. A cada tarea se le permite ejecutarse totalmente antes de pasar a la siguiente. Una tarea no puede ser suspendida cuando ya se est ejecutando. Esto es equivalente al funcionamiento del bucle principal que hemos visto anteriormente en este captulo.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 9/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Un ejemplo de diagrama de programacin cclica se muestra en la Figura 5.5. Aqu la banda horizontal representa la actividad de la CPU y los bloques numerados las tareas a medida que se ejecutan. Las tareas se van ejecutando unas detrs de otras, con la tarea 3, inicialmente, la ms larga y 2, la ms corta. En la tercera iteracin, sin embargo, la tarea 1 toma ms tiempo y el tiempo total del bucle es mayor. La planificacin cclica tiene las desventajas de la programacin secuencial en un bucle, como se ha sealado anteriormente. Al menos es simple.

Figura 4.5 Planificacin cclica Las tareas 1,2 y 3 se ejecutan secuencialmente.

5.3.2.- Planificacin Round Robin y cambio de contexto. En la planificacin Round robin el sistema operativo se ejecuta mediante una interrupcin peridica (el tick de reloj). Las tareas son seleccionadas en un orden fijo para su ejecucin. En cada tick de reloj, la tarea actual se suspende y se permite que la siguiente comience la ejecucin. Todas las tareas se consideran de igual importancia y esperan en secuencia a su trozo de tiempo de CPU. A las tareas no se las permite ejecutarse hasta el final, si no que son interrumpidas (pre-empted), es decir, su ejecucin se detiene en medio del proceso. Este es un ejemplo de un planificador pre-emptivo.

Figura 4.6 Planificacin Round Robin.

Las implicaciones de esta conmutacin de tareas pre-emptiva, y sus necesidades de recursos, no son despreciables y deben ser tenidas en cuenta. Cuando se permite a la tarea ejecutarse de nuevo, debe ser capaz de continuar el funcionamiento sin problemas, sin ningn efecto secundario debido a la planificacin. Por lo tanto, se debe guardar el contexto completo (todas las banderas, registros y otras direcciones de memoria) cuando se realiza la conmutacin de la tarea. Sin embargo, los elementos del programa que resultan crticos en cuanto a su temporizacin no deben ser interrumpidos, y este requisito tendr que ser escrito en el programa. Un ejemplo de diagrama de planificacin round robin se muestra en la Figura 5.6. Los bloques numerados representan una vez ms las tareas a medida que se ejecutan, pero hay una gran diferencia con la figura 5.5. Ahora cada tarea obtiene un tiempo de CPU, que tiene una longitud fija.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 10/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

El tick de reloj, que hace que se produzca la conmutacin de tareas, est representado en el diagrama por una flecha. Cuando este tiempo expira, la siguiente tarea pasa a ejecutarse, haya terminado o no la actual. En un momento dado la tarea 2 se acaba y ya no necesita tiempo de CPU durante varios trozos de tiempo. A continuacin, queda de nuevo lista para su ejecucin y toma su turno en el ciclo. Como la tarea y el contexto se han conmutado, existe una inevitable sobrecarga de tiempo, que est representado por las barras negras. Este es el tiempo ocupado al servir las necesidades del RTOS, que se pierde para el programa de aplicacin. 5.3.3.- Estados de las Tareas. Vale la pena considerar lo que les est pasando ahora a las tareas que estn siendo controladas por el planificador. Evidentemente, slo se est ejecutando una tarea en un momento dado. Otras pueden necesitar ejecutarse, pero en un instante dato no tienen esa posibilidad. Otras pueden simplemente responder a unas circunstancias particulares y, por tanto, slo se activan en ciertos momentos durante la ejecucin del programa.

Figura 4.7.- Estados posibles para las tareas.

Un diagrama de estados de las tareas se muestra en la Figura 5.7. Hay que tener en cuenta, sin embargo, que la terminologa utilizada y la forma en que el estado se lleva a cabo varan en cierta medida de un RTOS a otro. Por lo tanto, en algunos casos, se utilizan varios trminos para describir un cierto estado. Listo (o elegible). La tarea est lista para ejecutarse y lo har tan pronto como se le asigne tiempo de CPU. La tarea deja este estado y entra en el estado activo cuando es iniciada por el planificador.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 11/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

En ejecucin (running). A la tarea se le ha asignado tiempo de CPU y se est ejecutando. Varias causas pueden provocar que la tarea salga de este estado. Tal vez simplemente se complete y ya no necesite tiempo de CPU. Alternativamente, el planificador puede detenerla, de modo que otra tarea se pueda ejecutar. Por ltimo, puede entrar en un estado de bloqueo o en espera por alguna de las razones se describen a continuacin. Bloqueada / esperando / retrasada. Este estado representa a una tarea que est lista para ejecutarse, pero por una u otra razn no se le permite. Hay varias razones por las que este puede ser el caso y, de hecho, este nico estado en el diagrama puede ser sustituido por varios, si se desea mayor detalle. La tarea puede estar esperando a que lleguen algunos datos o a que quede disponible un recurso que necesita, que actualmente est siendo utilizado por otra tarea, o bien puede estar esperando un perodo de tiempo para ejecutarse. El estado se abandona cuando la tarea se libera de la condicin que la mantiene en este estado. Parada / suspendida / inactiva. La tarea no necesita tiempo de CPU en este momento. Una tarea deja este estado y entra en el estado de preparada cuando se activa de nuevo, por la razn que sea. Sin Inicializar / destruida. En este estado la tarea ya no existe en lo que al RTOS se refiere. Una consecuencia de esto es una tarea no necesita tener existencia continua en el curso de la ejecucin del programa. En general, tienen que ser creadas o inicializadas en el programa antes de que se puedan ejecutar. Si es necesario pueden ser destruidas ms tarde y, posiblemente, creadas de nuevo otra vez. La eliminacin de tareas innecesarias de la lista de tareas simplifica el funcionamiento del planificador y reduce la demanda de memoria. 5.3.4.- Planificacin pre-emptiva con prioridades. Volvemos ahora a nuestro estudio de las estrategias de planificacin, armados con una mayor comprensin de la vida de las tareas. Como hemos visto, en la planificacin de tareas de tipo Round robin las tareas quedan subordinadas al sistema operativo. Sin embargo, todas las tareas tienen la misma prioridad, por lo que una tarea de poca importancia tiene el mismo acceso a la CPU que una de mxima prioridad. Podemos cambiar esto dando prioridad a las tareas ms importantes. En el planificador pee-emptivo con prioridad, a las tareas se les dan prioridades. Las tareas de alta prioridad ahora estn autorizadas a terminar antes de cualquier otra tarea de menor prioridad. El planificador todava funciona mediante un tick de reloj. En cada tick de reloj, comprueba qu tareas listas tienen la ms alta prioridad. Estas son las que consiguen el acceso a la CPU.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 12/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Una tarea que se encuentre en ejecucin y que todava necesite tiempo de CPU, y sea de alta prioridad, mantiene la CPU. Una tarea de baja prioridad que se est ejecutando es sustituida por una de mayor prioridad, en caso de que est ltima haya pasado al estado de lista.

Figura 4.8.- Planificacin pre-emptiva con prioridades.

La tarea de alta prioridad se convierte en la tarea que se lleva el gato al agua. En casi todos los casos, prosigue su camino. La manera en que funciona esta estrategia de planificacin se ilustra en el ejemplo de la Figura 5.8. Este diagrama contiene varios conceptos clave del RTOS y vale la pena entenderlo bien. El diagrama muestra tres tareas, cada una de diferentes prioridades y diferentes tiempos de ejecucin. Al principio, todas estn listas para ejecutarse. La tarea 1, es seleccionada por el planificador para ejecucin, ya que tiene la ms alta prioridad. En la siguiente tick de reloj, el planificador reconoce que la tarea 1 todava debe ejecutarse, por lo que se le permite que contine. Lo mismo ocurre en el siguiente tick de reloj y por fin se completa la tarea durante el siguiente tramo. La tarea 1 no necesita ahora tiempo de CPU y pasa a estar suspendida. En el siguiente tick de reloj el planificador, por lo tanto, selecciona la tarea que tiene la prioridad ms alta, que ahora es la tarea 3. Esta tambin se ejecuta hasta que se completa. Por ltimo, la tarea 2 tiene la oportunidad de ejecutarse. Por desgracia para ella, sin embargo, durante su primer cuanto de tiempo la tarea 1 pasa al estado de lista de nuevo. En el siguiente tick de reloj, por lo tanto, se selecciona la tarea 1 para ejecutarse de nuevo. Una vez ms, se permite su ejecucin hasta su finalizacin. Cuando la tarea 2 est lista para ejecucin, y slo cuando ninguna otra tarea est lista, la tarea 2 puede volver a entrar en ejecucin y, finalmente se completa. A raz de esto, durante una porcin de tiempo, no hay ninguna tarea activa y por eso no hay actividad de la CPU. La tarea 1 pasa a estar lista una vez ms y comienza a ejecutarse de nuevo hasta su terminacin.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 13/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.3.5.- Planificacin Cooperativa. La estrategia de planificacin a la que acaba de hacerse referencia, planificacin pre-emptiva con prioridades, representa el funcionamiento clsico de los RTOS. Sin embargo, tambin tiene desventajas. El planificador debe mantener toda la informacin de contexto para todas las tareas que suspende. Esto generalmente se hace mediante una pila por tarea y emplea mucha memoria. El cambio de contexto tambin gasta mucho tiempo de CPU. Por otra parte, las tareas deben ser escritas de tal forma que se puede suspender en cualquier momento durante su funcionamiento. Una alternativa a la planificacin pre-emptiva es la planificacin cooperativa. Ahora, cada tarea debe renunciar, por su propia voluntad, a su acceso a la CPU en algn momento de su funcionamiento. Esto suena como que estamos bloqueando el sistema operativo, pero si cada una de las tareas que est escrita correctamente esto no ser realmente as. La ventaja es que la tarea devuelve el control en un momento de su eleccin, por lo que puede controlar el almacenamiento de su propio contexto y no es necesario gastar memoria extra en el control central. La planificacin cooperativa es poco probable que sea tan rpida en respuesta a los ajustados plazos como la planificacin pre-emptiva. Sin embargo, necesita menos memoria y puede cambiar de tarea rpidamente. Esto es muy importante en los pequeos sistemas, como los basados en microcontroladores PIC. 5.3.6.- El papel de las interrupciones en la planificacin. Hasta el momento, no hemos mencionado a las interrupciones en relacin con el RTOS. Deben ser las RSIs otras tareas del RTOS?, como se hizo en la estructura de la figura 5.4. La respuesta es no. El empleo de las interrupciones es casi siempre para proporcionar el tick de reloj, a travs de la interrupcin del temporizador. Ms all de esto, las RSIs generalmente son utilizadas para suministro de informacin urgente a las tareas o al planificador. La interrupcin puede, por ejemplo, configurarse para sealar un determinado evento que se ha producido, liberando por tanto una tarea de un estado de bloqueado (Figura 5.7). Las RSIs en s mismas no son empleadas normalmente como tareas.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 14/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.4.- El desarrollo de las tareas.

Una vez establecido el concepto de tarea y la forma en que se planifican, vamos a examinar ahora la manera en que estn escritas. 5.4.1.- La definicin de las tareas. Es una exigencia inicial e interesante al programador elegir qu actividades del sistema se definirn como tareas. El nmero de tareas creadas no debe ser grande. Ms tareas en general, implican ms complejidad de programacin, y para cada conmutacin de tarea se necesita tiempo y memoria. Un punto de partida til es considerar cuales son los plazos y, a continuacin, asignar una tareas por cada plazo. Un conjunto de actividades que estn estrechamente relacionadas en el tiempo son susceptibles de servir a un solo plazo, por lo que deben agruparse en una nica tarea. Un conjunto de actividades que estn estrechamente relacionadas en su funcin y realicen un intercambio de gran cantidad de datos tambin deberan agruparse en una nica tarea. Por ejemplo, en la bsqueda de la luz el programa del robot, el bucle principal en una etapa lee los tres sensores y, a continuacin, hace algunos clculos y, luego, establece la velocidad del motor. Tambin enva los datos peridicamente a la pantalla. En cualquier momento, los sensores de obstculo pueden activarse. Cuntas tareas debe haber? Las actividades centrales estn estrechamente relacionadas en el tiempo y en su funcin, y comparten datos. La escritura a la pantalla puede ser una tarea, que se produce con menos frecuencia que las dems y es de baja prioridad. Como la lectura de los datos de los sensores LDRs proporciona directamente los clculos del motor y el control del motor, todas estas actividades podran agruparse en una nica tarea. Alternativamente, la lectura del sensor LDR puede ser separada en su propia tarea. Por ltimo, la respuesta del sensor de obstculo podra ser asignada como una nueva tarea. 5.4.2.- Escritura de las tareas y establecimiento de prioridades. Las tareas deben escribirse como si se ejecutaran continuamente, como programas semi-autnomos y auto contenidos, a pesar de que pueden ser interrumpidos por el planificador. No pueden llamar a una seccin de cdigo de otra tarea, pero pueden tener acceso a cdigo comn, por ejemplo a las libreras de C. Las tareas pueden depender de los servicios prestados por otras tareas y puede ser necesario sincronizarlas con otras tareas. En todos los casos menos en el ms simple, el RTOS permite al programador establecer prioridades. En el caso de tener prioridad esttica, las prioridades son fijas. En el caso de prioridades dinmicas, las prioridades se puede cambiar a medida que el programa se ejecuta.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 15/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Una forma de ver las prioridades es considerar como de importante es una tarea para el funcionamiento y buen comportamiento del sistema, su usuario y el entorno. Las prioridades pueden entonces asignarse: Mxima prioridad: las tareas esenciales para la supervivencia del sistema. Media prioridad: las tareas esenciales para la correcta operacin del sistema. Baja prioridad: las tareas necesarias para la adecuada operacin del sistema. Estas tareas pueden ser de vez en cuando descartadas o bien un retraso en su conclusin podra ser aceptable.

5.5.- La proteccin de los Datos y recursos - el semforo.

Varias tareas pueden necesitar acceder al mismo recurso compartido. Este podra ser hardware (incluyendo memoria o perifrico) o un mdulo de software comn. Esto requiere cierta atencin. Un mtodo para tratar esto es el semforo. Se asigna un semforo a cada recurso compartido, el cual se utiliza para indicar si est en uso. En un semforo binario, la primera tarea que necesita usar el recurso se encuentra el semforo en un estado VERDE y cambiar el estado a ROJO antes de comenzar a utilizar el recurso. Cualquier otra tarea que necesite utilizar el mismo recurso pasar al estado de bloqueada (Figura 5.7). Cuando la primera tarea ha completado el acceso al recurso, cambia el semforo de nuevo a VERDE. Esto lleva al concepto de exclusin mutua, cuando una tarea est accediendo al recurso, todas las dems estn excluidas. El semforo contador es empleado para un conjunto de recursos idnticos, por ejemplo, un grupo de impresoras. Ahora, el semforo est inicialmente puesto al nmero de unidades del recurso. A medida que cada tarea utiliza una de las unidades, se produce un decremento del semforo en una unidad, incrementando de nuevo al final de su uso. Por lo tanto, el semforo contador contiene el nmero de unidades que estn disponibles para su uso. El poner un semforo en ROJO provoca como efecto que otra tarea acabe bloqueada, los semforos pueden utilizarse como un medio de proporcionar sincronizacin en el tiempo y sealizacin entre las distintas tareas. Una tarea puede bloquear a otra mediante el establecimiento de un semforo y se puede liberar en un momento de su eleccin en la puesta a cero del semforo. Recordemos a la tarea de alta prioridad que se mencion en la Seccin 5.3.4. Mediante el uso de un semforo, una tarea de prioridad baja puede darle la vuelta a los papeles y convertirse en la de ms prioridad. Si una tarea de baja prioridad establece un semforo para un recurso que necesita la tarea de alta prioridad, la tarea de baja prioridad puede dejar bloqueada a la de alta prioridad. Esto lleva a una peligrosa condicin conocida como inversin de prioridades.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 16/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.6.- El Sistema Operativo Salvo.

Todos los conceptos introducidos sobre el RTOS (sistema operativo de tiempo real) hasta ahora formar un punto de vista terico a menos que lo podamos aplicar a un ejemplo real. Preferentemente, este debe ser uno que se puede ejecutar en un sistema empotra basado en PIC. Salvo est disponible comercialmente como un RTOS especialmente destinado a los pequeos sistemas empotrados, con una versin que funciona con el compilador Microchip C18. Lo mejor de todo, es que existe una versin libre Salvo LITE. Esto nos da la oportunidad de entrar en el difcil pero apasionante mundo de los RTOS, y sin demasiados problemas para escribir programas de ejemplo simples e ilustrativos.

5.7.- La idea principal - Salvo, un RTOS de ejemplo.

Salvo fue desarrollado originalmente en ensamblador, para el sistema de adquisicin de datos de un coche de carreras. Una vez que fue reconocida su aplicacin ms amplia, fue reescrito en C y adaptado para uso general. Su aplicacin objetivo es al pequeo sistema empotrado. Se dispone de versiones de Salvo para los principales compiladores de sistemas empotrados. Salvo est suministrado por Pumpkin Real Time Software Inc. 5.7.1.- Caractersticas bsicas de Salvo. Salvo puede ejecutar mltiples tareas con prioridad y trabaja con una planificador cooperativo. Esta es una de las claves de su baja demanda de memoria, como se comentaba en la seccin 5.3.5, la planificacin cooperativa es menos exigente en memoria. El nmero de tareas (en la versin completa) slo est limitado por la RAM disponible, mientras que se dispone de 16 niveles de prioridad. Las tareas tambin pueden compartir niveles de prioridad. Salvo soporta una serie de diferentes "acontecimientos", incluidos los semforos binarios y contadores, mensajes y colas de mensajes. El programador trabaja con el compilador de la forma habitual, pero incorpora los archivos Salvo cuando sea necesario. De esta forma, el programador debe de cumplir los requisitos del RTOS Salvo. El programa desarrollado por el programador es finalmente una combinacin de cdigo fuente original, ficheros cabecera de Salvo y del compilador y los ficheros de librera de Salvo y del compilador. El proceso de creacin del software y de los principales archivos se resume en la Figura 5.9. La salida es un archivo ejecutable, que se descarga en la memoria de programa del sistema.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 17/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Figura 4.9. Proceso de creacin de programas con Salvo.

5.7.2.- Versiones de Salvo y referencias. Hay una serie de versiones de Salvo disponibles. La versin ms completa es Salvo Pro, una versin altamente configurable y con todas las posibilidades. La versin gratuita de Salvo, llamada Salvo Lite, contiene un subconjunto de la funcionalidad de Salvo. Salvo Lite se puede descargar desde el sitio web: http://www.pumpkininc.com/ . Se debe seleccionar la versin que coincide con el compilador en uso, en nuestro caso el compilador Microchip C18. Salvo Lite permite tres tareas y cinco eventos. Esto parece muy poco, pero de hecho resulta til y permite crear avanzados programas. Salvo, viene con un largo pero legible manual de usuario. Este est escrito para dar soporte a todas las versiones de Salvo, hasta Salvo Pro. Para el principiante, con el objetivo de utilizar Salvo Lite, algunos captulos pueden ser enormes. Sin embargo, tiene buena informacin y captulos introductorios. 5.7.3.- Configuracin de la aplicacin Salvo. Una de las principales caractersticas de Salvo es que es altamente configurable. Por lo tanto, es importante tener una idea desde el principio de cmo se lleva a cabo esta configuracin. Esta seccin introduce algunas de las caractersticas esenciales de los ficheros de Salvo y de su configuracin, y dar lugar a una mejor comprensin del proceso de creacin de programas mostrado en la Figura 5.9.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 18/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

5.7.3.1.- Programacin de aplicaciones Salvo - construir la librera. Diferentes bibliotecas estn disponibles para su uso, cada una con un conjunto distinto de caractersticas. Para una aplicacin dada, debe elegirse la biblioteca ms adecuada. Una vez hecho esto, los servicios de la librera son fijos. El cdigo fuente del usuario, hace llamadas a las funciones de Salvo que figuran en la librera elegida. Aparte de los archivos de biblioteca, fuente y de cabecera algunos otros deben ser incorporados, como se ve en la Figura 5.9. Los ms importantes son los siguientes: salvo.h. Este es el principal archivo de cabecera de Salvo y debe incluirse en cualquier archivo fuente que utiliza los servicios de Salvo. No debe ser modificado por el usuario. Este archivo a su vez incluye salvocfg.h. mem.c. Se trata de un gran archivo, que se suministra con Salvo. Posee objetos globales, que definen las caractersticas de los elementos utilizados, como tareas, semforos, etc. No debe ser modificado por el usuario, aunque el contenido de salvocfg.h modifica su comportamiento. salvocfg.h. Este archivo, escrito por el usuario, determina gran parte de la configuracin del sistema para la aplicacin. Establece ciertos elementos clave, como las libreras que se van a utilizar, y cmo sern muchas de las tareas y eventos. Se ofrecen ms detalles en la seccin 5.10.4.

5.7.3.2.- Las libreras de Salvo Existen diferentes conjuntos de libreras para cada compilador y para distintas versiones del compilador. Estas soportan varios modelos de memoria y diferentes combinaciones de caractersticas. Una de las habilidades para la configuracin de una aplicacin Salvo es la seleccin de la libreras que tiene las mnimas caractersticas necesarias, y nada ms.

Figura 4.10 Nombre de la librera Salvo, para el compilador C18.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 19/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Figura 4.11 Servicios disponibles para cada configuracin de librera.

Salvo Lite se proporciona con un conjunto de libreras gratuitas. Estas son como las libreras estndar, pero tienen una capacidad limitada. La codificacin utilizada para el compilador de C18 se muestra en la Figura 5.10. La ltima letra del nombre de la librera indica la configuracin, que se define en la Figura 5.11. La librera Sfc18sfa.lib, por ejemplo, tiene todas las caractersticas, excepto time-outs. Esto hace que comparativamente sea una gran biblioteca. Si slo se necesitan la multi-tarea en una aplicacin, sera mejor utilizar una biblioteca con la letra 'm' de configuracin. Esto dara lugar a una codificacin ms eficiente y menor uso de memoria.

Figura 4.12.- Carpetas creadas por Salvo Lite.

5.7.4.- Escritura de programas con Salvo. Esta seccin da una introduccin a la programacin con el RTOS Salvo, antes nos fijamos en un primer programa de ejemplo en la seccin que sigue. 5.7.4.1.- Inicializacin y planificacin. Varias caractersticas del RTOS Salvo estn contenidas dentro de sus funciones en C, que se encuentra en las libreras de Salvo. Parte de la habilidad de programacin con Salvo radica en conocer estas funciones y entender lo que hacen. Algunos ejemplos, exactamente los que se utilizarn en nuestro primer programa de ejemplo, estn en la Figura 5.13.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 20/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

En la figura aparece el nombre de la funcin o servicio, un resumen de su accin y los parmetros (si los hubiera) que necesita. El contenido de la tabla se explica varias veces en las prximas pginas, no preocuparse si todos los detalles no son inmediatamente evidentes. Funcin / Servicio OSInit() Accin y parmetro(s) Inicializa el sistema operativo, incluyendo estructuras de datos, puntero y contadores. Debe ser llamado antes de cual El planificador de Salvo. En cada llamada escoge la siguiente tarea a ejecutar (de las elegibles). La multitarea puede ocurrir cuando se llama de forma repetida. No tiene parmetros Retorno incondicional al planificador (1) Etiqueta de cambio de contexto, definida mediante _OSLabel() Crea una tarea y la inicia (la hace eligible). (1) Puntero a la direccin de comienzo de la tarea Normalmente el nombre de la tarea (2) Puntero al TCB (Bloque de control de la Tarea) (3) Prioridad un nmero de 0 (ms alta) a 15 (ms baja) Hace elegible una tarea detenida. (1) Puntero al TCB de la tarea Define una etiqueta nica necesaria para cada cambio de contexto (1) Nombre de la etiqueta Define un puntero a un bloque de control especfico, en este caso al bloque de control de la tarea. (1) Un entero de 1 a OSTASKS, donde OSTASKS aparece en el fichero salvocfg.h y especifica el nmero de tareas
Figura 4.13.- Servicios del ncleo de Salvo.

OSSched()

OS_Yield()*

OSCreateTask(,,)

OSStartTask() _OSLabel()

OSTCBP()

Algunas de las funciones que aparecen pueden causar un cambio de contexto; de este modo se aplica la planificacin cooperativa. Todas las funciones de Salvo que puede llamar el usuario tienen el prefijo SO o OS_ . Esta ltima se utiliza si el servicio incluye un cambio de contexto condicional o incondicional. Para habilitar e inicializar el RTOS debe llamarse a la funcin OSInit() antes que cualquier otra funcin de Salvo. Las tareas pueden ser creadas a continuacin con una llamada a OSCreateTask(), asegurndonos que todos los argumentos estn bien especificados. El programador est contenido dentro de la funcin OSSched(). En cada llamada, esta funcin hace tres cosas, que se enumeran a continuacin: Se selecciona y ejecuta la tarea ms elegible (es decir, la que tiene ms alta prioridad). Las tareas con la misma prioridad se ejecutan de forma "round robin.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 21/22

INFORMTICA INDUSTRIAL II

Introduccin a multitarea y STR

Procesa la cola de eventos, si se estn empleando eventos. Recordemos, los eventos incluyen semforos y mensajes. Como resultado de esto, ciertas tareas pueden llegar a ser elegibles para su ejecucin. Se procesa la cola de retardo. Los retardos en Salvo son un importante medio de control para marcar el momento en el que se ejecuta una tarea. Una vez ms, una tarea que puede llegar a ser elegible para su ejecucin.

5.7.4.2.- Escribiendo las tareas en Salvo. En Salvo cada tarea se escribe como una funcin C. Hay otros requisitos importantes, especficos de Salvo. Estos se resumen a continuacin: Todas las funciones estn inicialmente en estado "destruidas". Las tareas deben ser creadas con la funcin de Salvo OSCreateTask (). Pueden crearse en cualquier lugar del programa. En la prctica, la mayora son creadas al principio de la funcin principal. Las tareas estn generalmente constituidas por una inicializacin opcional, seguida por un bucle infinito, que debe contener al menos un cambio de contexto. El cambio de contexto puede producirse por una llamada a la funcin OS_Yield (), aunque existen otras funciones que tambin causan cambio de contexto. Con esta (o equivalente) llamada, la tarea renuncia a tener el control de la CPU y le pasa el control de nuevo al planificador. Esta es la base de la planificacin cooperativa utilizada por Salvo. Las tareas no pueden tener ningn parmetro. Las tareas utilizan variables estticas (static), por lo tanto, los datos no se modifican cuando la tarea no se est ejecutando. Las variables de tipo auto se pueden utilizar si no es necesario que se mantengan los datos tras un cambio de contexto.

Las caractersticas operativas de una tarea estn contenidas dentro de su bloque de control de tarea (TCB). Este es un bloque de memoria asignada de forma nica a la tarea, que contiene (entre otras cosas) la direccin de inicio de la tarea, su estado y su prioridad. Las tareas, en general, siguen el diagrama de estado de la Figura 5-7, con interpretaciones especificas de Salvo para cada Estado.

Dept. Ing. Electrnica, Sistemas Informticos y Automtica

Pg. 22/22