Autor Tema: Sistemas operativos en PIC  (Leído 100788 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado aitopes

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5102
    • uControl
Re: Sistemas operativos en PIC
« Respuesta #90 en: 10 de Abril de 2007, 15:02:43 »
Hola amigos!

Reinier, hoy he actualizado el documento con el curso "pasado en limpio". Lo pueden descargar o consultar desde aqui:

http://www.ucontrol.com.ar/Articulos/sistemas_operativos_microcontroladores/sistema_operativo_microcontroladores_pic_rtos.htm

Saludos!
Si cualquier habilidad que aprende un niño será obsoleta antes de que la use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia:
La única habilidad competitiva a largo plazo es la habilidad para aprender
“. Seymour Papert

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Las condiciones de competencia
« Respuesta #91 en: 12 de Abril de 2007, 12:33:41 »
Las condiciones de competencia

Como introduje en los posts anteriores, las condiciones de competencia son uno de los problemas potenciales que se presentan en la programación con Sistemas Operativos, pero: ¿Qué es una condición de competencia?

Básicamente es una bronca entre procesos que termina con el cuelgue de nuestro sistema, pero esa no es una definición apropiada para este problema, una mas acertada sería esta: una condición de competencia es un fenómeno que se produce cuando uno o varios procesos compiten por uno o varios recursos produciendo el bloqueo en la ejecución de esos procesos, lo que a la postre termina con el cuelgue del sistema.

Entonces una condición de competencia es una de las pesadillas que un programador de aplicaciones que utiliza algún Sistema Operativo debe evitar si desea dormir tranquilamente. En mi post anterior puse un ejemplo en el cual se produce una condición de competencia, si se analiza con más detenimiento podemos darnos cuenta que es muy difícil definir bajo que condiciones se producirá una condición de competencia; sin embargo, como este es un tema investigado desde los años 60, un grupo de gente ya se ha ocupado de identificar bajo que condiciones un programa será robusto ante condiciones de competencia.

Para evitar una condición de competencia debemos establecer un conjunto de reglas que nos aseguren que no se producirá, adicionalmente, el Sistema Operativo debe ofrecer al programador un conjunto de herramientas de programación que le permitan poner en práctica estas reglas.

De hecho, a lo largo del curso en los ejemplos que he puesto, hemos estado evitando las condiciones de competencia, sólo que no se los dije para no complicar las cosas más de lo que ya eran en aquel entonces, pero es el momento de tocar este tema y aquí vamos.

La regla de oro para evitar las condiciones de competencia es garantizar el acceso seguro a recursos compartidos, es decir, debemos hacer coordinación y sincronización de procesos.

Para lograr implementar esta regla es que se inventaron las secciones críticas, pero el utilizar las herramientas de implementación de secciones críticas no asegura evitar una condición de competencia, ese es el caso del ejemplo de mi mensaje anterior.

Bien, si aún utilizando secciones críticas no se asegura evitar que se produzca una condición de competencia, ¿que podemos hacer para resolver el problema? Lo que podemos hacer es poner restricciones en la semántica de nuestro código que aseguren que el código es seguro, valga la redundancia.

El párrafo anterior nos pone otra vez en aprietos porque debemos preguntarnos ¿entonces cuales son esas restricciones semánticas? La respuesta a esa pregunta está dada en las siguientes cuatro reglas que debemos cumplir:

  • Dos o más procesos no pueden estar simultáneamente dentro
    de sus regiones críticas
  • No debe suponerse nada acerca de la velocidad o el orden de ejecución de los procesos
  • Ningún proceso que se ejecute fuera de su región crítica
    puede bloquear a otros procesos
  • Ningún proceso deberá tener que esperar indefinidamente
    para entrar a su región crítica

Como veremos en el futuro, hacer que nuestros programas cumplan con estas restricciones puede ser realmente doloroso, (al menos para nuestra cabeza), pero también veremos que ya algunos se rompieron la cabeza por nosotros y nos ofrecen soluciones tipo para la mayoría de los problemas a los que debemos enfrentarnos, estas soluciones se presentan con ejemplos bastante didácticos que perecen tonterías pero que podemos trasladar a problemas reales que son muy semejantes en su dinámica.

Ahora analicemos detalladamente cada una de las reglas semánticas que debe cumplir un programa libre de condiciones de competencia:


Dos o más procesos no pueden estar simultáneamente dentro
de sus regiones críticas


Cuando introduje las secciones críticas expliqué que su misión fundamental era evitar que más de un proceso accediera a un recurso compartido, esto implica que para ello debemos contar con algún mecanismo de protección y este mecanismo resultó ser el uso de semáforos, pero los semáforos por si solos no garantizan la ejecución segura, debemos pensar donde ponerlos y cuantos necesitamos para evitar que más de un proceso se meta en el código que manipula al recurso compartido.

En ocasiones se permite que más de un proceso acceda al recurso compartido para realizar lecturas pero cuando se hagan escrituras debemos impedir que más de un proceso esté dentro de la sección crítica, esta es una variación a la regla tal como la hemos definido, pero esta situación se da en muy contadas ocasiones así que no debemos preocuparnos mucho por esta variación.


No debe suponerse nada acerca de la velocidad o el orden de ejecución de los procesos

Este es un tema que podemos subestimar porque tradicionalmente programamos pensando que tenemos para nosotros todo el equipo de cómputo, pero cuando utilizamos Sistemas Operativos las condiciones cambian mucho porque cada proceso actúa como si todo el equipo de cómputo fuese suyo en el momento en que está ejecutándose, por lo que debemos proteger los recursos compartidos adecuadamente ante los cambios de contexto de los procesos.

Para ello existen, por supuesto, las secciones críticas; pero esta nueva regla le indica al programador que no puede soportar la semántica de su programa en suposiciones de carácter temporal o de orden de ejecución de los procesos y eso quedó claro en uno de los primeros ejemplos que puse en este cursillo.


Ningún proceso que se ejecute fuera de su región crítica
puede bloquear a otros procesos


Esta regla lo que define es que el bloqueo a otros procesos debe realizarse justo antes de entrar a la sección crítica, para evitar que otro proceso sea detenido cuando en realidad puede ejecutar código de forma segura, igualmente los procesos que hayan sido bloqueados cuando se entró en la sección crítica deben ser desbloquedaos al salir de esta.

Además al poner en práctica esta regla reducimos al máximo el tamaño del código dentro de la sección crítica y con ello maximizamos el uso de la CPU y minimizamos los tiempos de bloqueo, así que aunque parece simple de poner en práctica, veremos que no es tan simple lograr estos objetivos.

Ningún proceso deberá tener que esperar indefinidamente
para entrar a su región crítica


Ahora se trata de evitar que un proceso muera de inanición, es decir, que estando listo para ejecutarse y requiriendo que se ejecute, otro proceso mucho más rápido o prioritario bloquee a uno más lento, menos prioritario o ambas cosas a la vez, matándolo de hambre. Este problema puede ser muy solapado y por ello muy peligroso.

Normalmente los sistemas de planificación de procesos de los Sistemas Operativos implementan mecanismos que tratan de evitar el fenómeno de inanición, pero estos mecanismos no son infalibles y los programadores debemos estar pendientes de lo que hacemos para evitarlo.

Hasta aquí el post de hoy porque ya tengo dolor de cabeza y creo que es suficiente materia para provocarle el mismo problema a alguno de ustedes. En la próxima entrega comenzamos a ver problemas y programas para evitar las condiciones de competencia así que preparen los compiladores y el coco, tengan agua o hielo cerca para refrescarlo y no se asusten que esto es difícil pero no imposible.

Un saludo Reinier

Desconectado PICNGRADO

  • PIC10
  • *
  • Mensajes: 2
Re: Sistemas operativos en PIC
« Respuesta #92 en: 15 de Abril de 2007, 08:41:10 »
hOLA reiniertl:

   Acabo de encontrar toda esta información tuya sobre RTOS y me parece un trabajo increible. Aún tengo que leer todo lo que has escrito pero he encontrado cosas que se pueden matizar, por ejemplo cuando hablas de RTOS mail para pasar mensajes de una tarea a otra creo que se ha de tener en cuenta que si las variables que pasan son globales no hace falta el uso de las funciones de correo, solo en el caso de que las variables sean particulares es necesario el uso de las funciones correo (pruebalo con el ejemplo que has puesto y lo comprobarás). Una dificultad que encuentro con estas funciones es el uso de float, cuando se pasan int8 o int16 no hay problemas pero con float suele dar problemas ?¿¿¿.
  En fin, espero que siguas por este camino, intentaré apoyarte cuanto pueda.

saludos


Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #93 en: 16 de Abril de 2007, 09:57:58 »
Es cierto que al utilizar variables globales no necesitas el servicio de mensajes, pero la ventaja fundamental de utilizar mensajes es que puedes implementar esperas eficientes, evitando las esperas ocupadas.

Una variable global no te permitirá saber cuando esta ha cambiado de valor a no ser que utilices una bandera, claro este método de tener una variable global y otra variable global de bandera es una solución eficaz, pero no eficiente si utilizas un RTOS.

Por ejemplo el paso de mensajes te permite hacer un RTOS_Wait(RTOS_Message_Poll()); que es una espera eficiente, y eso sólo con una línea. Es decir, si no hay mensajes le dices al RTOS, me voy a dormir, despiértame cuando llegue un mensaje, ahora piensa en implementar esto con variables globales, estoy seguro de que se puede, pero me parece que no va a quedar muy elegante. Este es sólo un criterio, es derecho de todo programador y diseñador hacer lo crea más idoneo.

Por otro lado, este RTOS no permite pasar variables de cualquier clase como mensajes, solamente bytes, es decir un int8 o un char, si tienes un float tendrás que pasarlo por partes descomponiéndolo en sus respectivos bytes y donde lo recibas puedes recomponerlo, también puedes poner el dato en una variable global y entonces pasar como mensaje algún tipo de comando para indicar que el dato cambió, si el resultado es válido, etc. Eso siempre queda como tarea del programador, yo solo doy algunas pistas el resto tienen que pensarlo ustedes.

Por supuesto estoy abierto a todo tipo de discusión y aclaración de dudas o preguntas, si me he equivocado en algo también estoy en la mejor disposición de corregir mis errores, espero haberte sido de ayuda y muchas gracias por los elogios.

Un saludo Reinier

PD: de hecho para la cantidad de lecturas que tiene este hilo me parece que genera muy poca controversia, no sé a lo mejor es que mis amigos no se atreven a preguntar o simplemente leen este hilo para adquirir cultura general. En realidad me gustaría que fuese un poco más movido, al menos de parte de los lectores.


Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17651
    • MicroPIC
Re: Sistemas operativos en PIC
« Respuesta #94 en: 16 de Abril de 2007, 11:10:19 »
Supongo que siempre se podra enviar un mensaje con un puntero al float...
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #95 en: 16 de Abril de 2007, 11:18:40 »
Siempre que el puntero sea de 8 bits, es posible, si el puntero es de 16 bits (cosa frecuente) entonces tienes que madar dos bytes independientes y reconstruir el dato, recuerda que un puntero no es más que una variable que guarda una dirección y rara vez son de 8 bits, ya con la dirección puedes direccionar la variable.

Pero es una buena idea, todo depende de la aplicación y lo que desees hacer.

Un saludo Nocturno, siempre andas por este hilo, gracias por el interés.

Un saludo a todos Uds. Reinier

Desconectado PICNGRADO

  • PIC10
  • *
  • Mensajes: 2
Re: Sistemas operativos en PIC
« Respuesta #96 en: 16 de Abril de 2007, 16:48:55 »
¡Ojo! SI se pueden pasan int16 sin problemas, por ejemplo el valor de una adquisición AD. Lo que no permite (por lo que he utilizado) es el uso directo de float (el manual de CCS no aporta mucha más información sobre esta función de mail).

  Efectivamente es más elegante el uso de la función de mail pero es conveniente utilizarla sólo en el caso de que se necesite esperar la variable o un cambio en ella; pero en caso de tener que leer la varible "por narices" es más "económico" leerla directamente ¡se ahorra código y en las tareas la reducción de código es fundamental!.

saludos





Desconectado jorgevert

  • Moderadores
  • PIC10
  • *****
  • Mensajes: 30
Re: Sistemas operativos en PIC
« Respuesta #97 en: 18 de Abril de 2007, 20:31:01 »
estuve revisando este hilo sobre el tema de sistemas operativos en los pic con el ccs y tengo un problema con la simulacion de las tareas. La teoria dice, que a cada tarea se le da un tiempo maximo de ejecucion y que si esta tarea no termina de ser ejecutada. El cpu sale del la tarea que esta ejecutando y sigue con las siguiente tarea que tenga asignada.
tengo un ejemplo donde eso no ocurre. 

#include <18F452.h>
#include <MATH.H>
#fuses XT,NOWDT,PROTECT,NOLVP,PUT,NOBROWNOUT
#use delay(clock=4000000)
#use fixed_io(C_outputs=PIN_C0, PIN_C1,PIN_C2, PIN_C3,PIN_C4, PIN_C5,PIN_C6)
#use rs232(BAUD=9600, BITS=8, PARITY=N, XMIT=PIN_C6, RCV=PIN_C7)
#use RTOS(timer=0, minor_cycle=10ms) //temporizador Timer0, tiempo mínimo de ejecución de cada tarea 10ms

#task(rate=100ms,max=10ms)   //Ejecutar cada 1 segundo y consumir como máximo 10ms
void Tarea1();

#task(rate=200ms,max=10ms)    //Ejecutar cada 2 segundos y consumir como máximo 10ms
void Tarea2();

#task(rate=300ms,max=10ms) //Ejecutar cada 3 segundo y consumir como máximo 10ms
void Tarea3();


//Implementación de las tareas
void Tarea1()
{
   output_b(0x01);
   delay_ms(200);
   printf("t1\r");
}


void Tarea2()
{
   printf("t2\r");
}

void Tarea3()
{
   printf("t3\r");
}

void main()
{

   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
   rtos_run();    //A partir de aquí comenzará la ejecución de las tareas
}

aqui tengo 3 tareas cada una con un tiempo maximo de ejecucion de 10ms sin embargo en la tarea1 inserte un delay de 200ms y cuando el cpu atiene esta tarea ejecuta los 200ms y el printf sin respetar el tiempo maximo de 10ms. Alguien me puede explicar a que se debe eso.

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #98 en: 19 de Abril de 2007, 08:18:59 »
Se debe sencillamente a que este RTOS es cooperativo o non preentive, eso significa que si la tarea no cede el procesador antes de que se cumpla el tiempo de slice, en tu caso 10ms, esta continuará ejecutándose y el RTOS no podrá quitarle el procesador a la tarea.

Las razones por las cuales este RTOS es así pueden ser muchas, pero la más importante a mi juicio, es que en la mayoría de los PICs la pila no puede ser leía, así que para hacer una cabio de contexto, no se puede saber por donde se está ejecutando tu programa, tampoco se puede meter ni sacar un contador de programas en la pila (no hay PUSH ni POP) y por lo tanto el RTOS no puede simplemente hacer un cambio de contexto seguro, otras razones pueden ser el tamaño  del RTOS, su simplicidad, etc.

Ahora, con el RTOS de CCS, no puedes esperar a que él tome el control del procesador como puede ocurrir con otros RTOS, como el FreeRTOS (este tiene puertos para los PICs más avanzados donde la pila puede ser leída para obtener los contadores de programa y oder hacer cambio de contexto), el cual es configurable y puede actuar como cooperativo o de tiempo compartido, aquí debes simplemente devolver el procesador cuando no lo necesites, o creas que ya has consumido demasiado tiempo, es tu responsabilidad como programador pensar en esos asuntos.

Sistemas operativos como este hay un montón, así que no se preocupen por el tema de los SO cooperativos, por ejemplo Windows fue cooperativo hasta una de las primeras versiones de win95 y nunca ningún usuario se preocupó de eso.

Un saludo Reinier

Desconectado jorgevert

  • Moderadores
  • PIC10
  • *****
  • Mensajes: 30
Re: Sistemas operativos en PIC
« Respuesta #99 en: 19 de Abril de 2007, 20:04:17 »
no me percate que el ccs aplica un sistema del tipo cooperativo gracias por la ayuda.


Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #100 en: 11 de Mayo de 2007, 14:00:34 »

Luego de una condición de competencia producida entre la tarea Trabajo y la tarea Foro, en la cual la tarea trabajo casi mata de inanición a la tarea Foro, he venido con esta nueva entrega sobre el hilo sobre RTOS.


Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #101 en: 11 de Mayo de 2007, 14:05:53 »
Introducción a los procesos

Hasta el momento hemos visto ejemplos de programas utilizando RTOS y les he hablado de los problemas asociados a la programación con RTOS, pero hay un concepto que debemos aclarar antes de continuar, o de otro modo ustedes pueden llegar a confundirse y escribir programas que no funcionan correctamente.

Todo el tiempo han visto que he utilizado el término tarea o proceso para denotar un fragmento de código que hace “algo”, pero no han visto una definición formal sobre esos términos, así como tampoco una explicación de que es una tarea o proceso.

Las razones de la omisión, son más o menos las mismas que para el caso de los problemas asociados a la programación con RTOS. Normalmente estos temas son bastante tediosos de estudiar, programar utilizando SO no es una tarea fácil al principio, aunque una vez que se domina constituye una poderosa herramienta de trabajo que mejora la productividad y el desempeño de cualquier sistema.

Entonces con el objetivo de motivar en ustedes el interés por la programación con RTOS, decidí no proponerles una línea formal de aprendizaje como suele ocurrir en una escuela o libro sobre el tema, sino ir poniendo ejemplos de cómo utilizar un RTOS y luego introducir la parte pesada del asunto.

Hoy vamos a ver, con bastante detalle qué es un proceso o tarea, porque cuando comencemos a ver los ejemplos de coordinación y sincronización de procesos, necesitaremos tener bien claro que es un proceso, para poder comprender esos problemas-ejemplo de los que tanto les he hablado.

¿Cómo se consigue la multiprogramación?
La multitarea o multiprogramación es un proceso que intenta crear la ilusión de que la computadora está haciendo varias cosas al mismo tiempo. Pensemos en una PC, normalmente usted puede escribir un documento mientras escucha música, el programa de descargas baja algún archivo de INTERNET y el antivirus se encuentra activo.

Para lograr hacer cada una de las cosas anteriores, tenemos un conjunto de programas, uno por cada tarea, y cada programa “parece” que se ejecuta como si tuviese la computadora para él solo. En realidad cada programa se ejecuta durante un período corto de tiempo y luego el procesador es cedido a otro programa para que se ejecute durante un poco de tiempo, este mecanismo se conoce como multiprogramación (definición estilo UNIX) o multitarea (definición estilo Microsoft).

Si para una computadora tuviésemos una lista de los programas que está ejecutando y muestreáramos que está haciendo el procesador en un instante de tiempo cualquiera; comprobaríamos que en ese momento está ejecutando una instrucción de alguno de sus programas, pero nunca dos programas a la vez. Más aún, si ese procesador tuviese un pipeline suficientemente grande como para contener varias instrucciones en la cola de ejecución, notaríamos que todas las instrucciones son de un solo programa.

Ahora tomemos un período de tiempo, digamos un segundo, en ese tiempo el procesador debe cambiar de un programa a otro para que se ejecute un pedacito de cada uno y crear la ilusión de que el conjunto se ejecuta de forma concurrente, como si cada programa tuviese un procesador para él solo. Es posible que en ese tiempo el procesador haya cambiado muchas veces de programa, pero si el usuario o sistema conectado a él no nota que sus intereses se han afectado, el objetivo fundamental de la multiprogramación se ha cumplido: crear la ilusión de que el sistema de cómputo tiene varios procesadores, uno por cada programa en ejecución.

Hay sistemas con más de un procesador trabajando de conjunto para ejecutar instrucciones de varios programas, a ese método de ejecución de código en un sistema computacional se le conoce como paralelismo, mientras que a los sistemas con un solo procesador se les conoce como de ejecución seudo paralela.

Como los seres humanos somos muy malos siguiendo la pista a un sistema que cambia constantemente de un lugar a otro, y a veces eso nos trae problemas de cabeza, es que se ha inventado un modelo que permite programar código que pueda ser ejecutado de forma paralela o seudo paralela: el modelo de proceso.

El modelo de procesos:
Normalmente se considera que un proceso es un programa en ejecución. Sin embargo eso sería limitar el concepto de proceso al programa que se está ejecutando en el instante en que se mira a la CPU.

Más bien un proceso es un programa al que le ha sido asociado un conjunto de datos que crea una CPU virtual. Eventualmente el proceso irá a parar a la CPU, se ejecutará un poco de código y volverá a ser suspendido hasta que le toque nuevamente la CPU, pero cuando el proceso no se está ejecutando en el procesador, su conjunto de datos asociado mantiene el estado del proceso como si estuviese ejecutándose.

Con este modelo podemos seguir la pista a nuestros programas sin preocuparnos mucho por la forma en que la CPU conmuta o cambia de contexto de un proceso a otro, es como si tuviésemos a cada programa ejecutándose en su propia computadora.

Comprender este concepto es muy importante, porque a partir de ahora si un programa se convierte en proceso, además del código del programa (escrito por el programador), el SO le asignará un registro de control y estado, de modo que el proceso tenga su CPU virtual. Y usted como programador que utiliza las funcionalidades del SO para escribir su código, deberá conocer este detalle si quiere que sus código sea productivo y seguro.

Estados de proceso
Ya vimos que a cada programa que se promueve a proceso le es asignado un registro de control y estado. Este registro puede tener varios campos y cada campo puede tomar varios valores, muchas veces al programador no le interesan cuales son los campos de este registro y cuales sus valores porque son de uso interno del SO, pero hay un conjunto reducido de ellos que sí es necesario conocer.

Dentro de los campos del registro de proceso uno de los más importantes para el programador es el de estado del proceso. Este campo sirve para conocer en que situación está el proceso y permite determinar hacia que nuevo estado puede dirigirse éste.

Los estados que puede tomar un proceso son básicamente los siguientes:
  • En ejecución
  • Listo
  • Suspendido o bloqueado

En ejecución: corresponde al proceso que en el momento presente está ejecutando el procesador real el sistema.

Listo: el proceso está listo para ser ejecutado. Este estado permite que el SO pueda planificar al proceso para ser ejecutado en algún momento posterior.

Suspendido o bloqueado: los procesos van a parar a este estado porque deben esperar a que alguna condición lógica se cumpla para poder continuar ejecutándose, las condiciones pueden ser muchas: esperar por una E/S, a que transcurra algún tiempo, entre otras.

Además de los estados existen un conjunto de transiciones entre los diferentes estados:
  • Ejecución -> Suspendido o bloqueado
  • Ejecución -> Listo
  • Listo -> Ejecución
  • Bloqueado -> Listo

Ejecución -> Suspendido o bloqueado: ocurre cuando un proceso debe esperar por una condición lógica, en este caso como el proceso no puede continuar ejecutándose, lo más lógico es que el procesador se dedique a ejecutar otros procesos que estén listos para ejecutarse.

Ejecución -> Listo: ocurre en los sistemas de tiempo compartido (preentive), en el cual un proceso que estaba ejecutándose es interrumpido porque se terminó su tiempo (slice) de ejecución y debe esperar a que lo vuelvan a planificar para ejecutarse. En este caso el proceso no pasa al estado de bloqueado porque no existe nada que le impida continuar, excepto que el procesador real del sistema debe ejecutar otro proceso para que se cumpla el objetivo de la multiprogramación.

Listo -> Ejecución: a un proceso que estaba listo para ejecutarse le es cedido el procesador

Bloqueado -> Listo: la condición lógica que mantenía al proceso en este estado se ha cumplido y el proceso ya puede ser planificado para ejecutarse.

Ahora he introducido un nuevo elemento en el asunto: la planificación de procesos. Este es un tema importante, aunque a nosotros no nos interesa mucho, porque no diseñamos ningún SO sino que simplemente lo utilizamos.

El planificador de procesos es un componente del SO que básicamente se encarga de revisar la lista de procesos que están listos para ejecutarse y los pone en una cola de la que otro componente del SO, llamado despachador o dispatcher, los va tomando y poniéndolos en ejecución.

En un SO puede haber otros componentes encargados de la E/S, la comunicación entre procesos, etc. pero con lo que hemos visto es suficiente para seguir avanzando en nuestro curso.

Los procesos con el RTOS de CCS
Para el RTOS de CCS, los procesos se nombran tareas y es por eso que durante el curso he utilizado indistintamente el término tarea o proceso. Tal y como hemos visto hasta hoy, cuando el RTOS crea una tarea le asigna un registro mediante el cual el RTOS puede controlar la ejecución de la tarea y conocer su estado. Para el programador esta información no está disponible porque realmente no debe acceder directamente a ella, pero como veremos un poco más adelante si se trabaja con esto registros, por supuesto, a través de las funciones que ofrece el propio RTOS.

Para comprender esto mejor veamos cada una de las funciones y directivas del RTOS y el impacto que cada una tiene sobre las tareas:

#TASK:
Con esta directiva simplemente le decimos al compilador que la función que viene a continuación será una tarea. En el momento de la compilación le será creado el registro de control y estado y se marcará como lista, si la tarea tiene cola se reserva memoria para la cola.

Una tarea no será tenida en cuenta como si fuese una función, por lo tanto no podrá llamar a una “función tipo tarea” como lo hace con cualquier otra función, las tareas son como programas completamente independientes que tienen asociado un registro de control y estado como si tuviese su propio procesador.

Tampoco debe implementarse una tarea como si fuese una función tipo main(), ya que la tarea ejecutará el código desde que comienza hasta que termina, se marca con el estado listo y luego el procesador es cedido al RTOS para que el despachador ponga otra tarea en ejecución. Si la tarea se mantiene en el estado listo, entonces cuando le toque nuevamente su turno en la cola de despachos volverá a ser ejecutada desde el principio, como si hubiese un lazo infinito. Hágase la idea que en vez de un main() con un lazo infinito, tenemos tantos main() como tareas hayamos definido, que se ejecutan de acuerdo a un plan de ejecución.

RTOS_AWAIT( ) y RTOS_WAIT( ):
Estas dos funciones permiten pasar a una tarea del estado en ejecución al estado bloqueado si las condiciones lógicas que permiten continuar ejecutando código no se cumplen y permanecerán en el estado bloqueado hasta que el RTOS detecte que puede continuar ejecutándose las pase al estado listo. Nunca el programador puede pasar una tarea del estado bloqueado a listo, esto es asunto del RTOS.

RTOS_DISABLE( )
Permite al programador, que desde otra tarea, se cambie el estado de una tarea de listo para deshabilitada (un estado nuevo de este RTOS), es necesario utilizar la función RTOS_ENABLE( ) para volver a conmutar del estado deshabilitada al estado anterior en que se encontraba la tarea. Una tarea no puede auto deshabilitarse, este cambio debe hacerse desde una tarea diferente.

RTOS_YIELD( ):
Cede el procesador explícitamente y pasa del estado en ejecución al estado listo. La otra forma en que con este RTOS se hace esa transición es cuando se termina el código de la tarea. Cuando le vuelva a corresponder el turno de ejecución a esta tarea, el despachador la volverá poner en ejecución en la línea posterior al yield().

Uff, bueno, hasta aquí por hoy, creo que es más que suficiente. Espero que las condiciones de competencia no vuelvan a afectar a la tarea Foro y pueda escribirles pronto.
El próximo tema será: El problema del productor-consumidor, uno de los más famosos problemas tipo de la programación con SO.

Un saludo: Reinier
« Última modificación: 11 de Mayo de 2007, 16:25:06 por reiniertl »

Desconectado PICpegaso

  • PIC16
  • ***
  • Mensajes: 124
Re: Sistemas operativos en PIC
« Respuesta #102 en: 16 de Mayo de 2007, 03:52:48 »
Vaya... y yo que ingresaba a la pagina para manejar el ADC,
has logrado captar mi atención,
Gracias Reinier
  :-)

  :-/ esta de lujo :lol:
Fabiancho

Cuando se tiene un buen POR QUÉ, siempre se encuentra el CÓMO

Desconectado barral

  • PIC10
  • *
  • Mensajes: 37
Re: Sistemas operativos en PIC
« Respuesta #103 en: 18 de Mayo de 2007, 08:27:14 »
La verdad es que este hilo es genial... yo lo sigo desde el principio. Además la parte teórica me refresca la memoria de mis clases de sistemas informáticos de tiempo real...

Desconectado carlosmaid

  • PIC10
  • *
  • Mensajes: 13
    • MSX Hardware Argentina
Re: Sistemas operativos en PIC
« Respuesta #104 en: 28 de Octubre de 2007, 21:56:00 »
Mas que excelente toda la informacion!!

Ahora, veo que ya hace algunos meses no se postea mas data nueva :-( una lastima porque es de primera mano.


 

anything