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

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

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #30 en: 08 de Febrero de 2007, 16:05:39 »
Me agrada que les haya gustado el ejemplo.

Pero si creen que el ejemplo anterior es fuerte, esperen aver lo que pienso preparar para la próxima entrega ya que solamente hemos arañado la superficie de las portencialidades de los SO.

Bueno amigos espero que le den buen uso a lo que aprendan de los RTOS y recuerden que todo lo que ya conozco al respeco y todo lo que aprenda espero compartirlo con Uds, y en respuesta solo quiero que estudien y se preparen bien para que compartan.

La próxima entrega tal vez demore uno o dos días más porque las cosas ya se están complicando y tengo que ver de que forma las enfoco para que todo mundo me entienda.

Pronto nos introduciremos en el tema de cómo eliminar el PIC-egoísmo, es decir, estudiaremos como ceder el procesador cuando no nos hace falta, y como recuperarlo en el momento apropiado. Esto lleva un poco de teoría, así que a lijar los platinos y a limpiar las bujías que hay que "quemar" bastante para sacar jugo al RTOS

Hasta muy pronto Reinier

Desconectado MGLSOFT

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 7820
Re: Sistemas operativos en PIC
« Respuesta #31 en: 08 de Febrero de 2007, 16:36:40 »
Esperaremos ansiosos!!
Ya me apunte al hilo, porque entre Darukur y tu me han despertado la curiosidad!!! :D :D :D
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado vicent

  • Colaborador
  • PIC16
  • *****
  • Mensajes: 144
    • Web de Vicent
Re: Sistemas operativos en PIC
« Respuesta #32 en: 08 de Febrero de 2007, 19:55:53 »
En la carrera, hemos estudiado un SO desde el diseño a la implementación, el KMOS, y la verdad es que es algo muy potente si se usa adecuadamente.
Me parece que para los PICs puede ser un adelanto grande según para que cosas.

Lo veo muy interesante, lástima no tener tiempo para investigar tantas cosas como me gustaría.

Un saludo. Au.

Desconectado Y@el

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 415
Re: Sistemas operativos en PIC
« Respuesta #33 en: 08 de Febrero de 2007, 20:23:31 »
Hola amigos, acabo de encontrar este link interesante
h**p://www.avaxhome.ru/ebooks/vahvus-silberschatz-espanol.html

saludos,

Yoel

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #34 en: 09 de Febrero de 2007, 18:20:56 »
Controlando la ejecución de las tareas
Hola, en la pasada entrega sobre programación con el RTOS de CCS vimos como es que el planificador programaba la ejecución de las tareas que estaban activas para ser ejecutadas. Pero como es lógico en todo momento las tareas no tienen por que encontrarse en condiciones de ser ejecutadas, a veces hace falta poner a “dormir” una tarea y “despertarla” cuando hace falta que se ejecute.
Para lograr este objetivo el RTOS de CCS nos ofrece dos funciones RTOS_DISABLE( ) y RTOS_ENABLE( )

Al crear una tarea el RTOS la marca como activa (enable), y cuando comienza a ejecutarse el planificador de tareas la pondrá en la cola de ejecución para ejecutarla cuando le llega su turno. Sin embargo en muchas ocasiones notaremos que no hace falta ejecutar la tarea hasta que se cumplan ciertas condiciones.

Este es un mecanismo simple, que sin el uso del RTOS controlaríamos mediante una bandera (flag), y la implementación de una función a la cual llamaremos si se cumple la condición de su ejecución.

Hasta el momento el RTOS no nos ofrece ninguna ventaja respecto al método tradicional, sin embargo combinemos esta característica con lo aprendido en el ejemplo de la entrega anterior y comprobaremos que si hay ventajas, y por cierto nada despreciables.

La ventaja principal con respecto al método tradicional consiste en que usted hace la consulta para comprobar si hay que ejecutar la función, sin embargo ahora solamente le dice al RTOS, habilita a la tarea tal y ponla a ejecutarse cuando le corresponda y se olvida de todos los problemas asociados respecto al tema de cuando le corresponde ejecutarse la tarea y demás. ¿Alguien se acuerda de los molestos temporizadores, banderas, registros y Dios sabe cuantos engendros de control de ejecución condicional para una función estándar?

De forma similar a como se le dice al planificador que la tarea tal debe ser ejecutada, podemos avisarle para que no la ejecute.

Veamos esto con un ejemplo:
Tenemos una aplicación en la que hemos colocado tres LEDs uno rojo en RB0, uno verde en RB1 y otro amarillo en RB2. Vamos a encender y apagar los LEDs con una frecuencia determinada y a intervalos regulares según el siguiente esquema:
Led Rojo parpadea con una frecuencia de 250ms por un período de 5s, el resto apagado
Led Verde parpadea con una frecuencia de 350ms por un período de 10s, el resto apagado
Led Amarillo parpadea con una frecuencia de 450ms por un período de 15s, el resto apagado
Todos los LED parpadean, cada uno con su frecuencia correspondiente durante 5s
Comezamos por el LED rojo nuevamente y repetimos el ciclo

Programa

La solución que les propongo es la siguiente:
3 tareas para controlar el parpadeo de cada LED y el tiempo que se ejecutan
1 tarea para controlar el tiempo en que todos los LEDs parpadean.

Tenemos un total de 4 tareas en la aplicación y el control de la ejecución será el siguiente:
Al inicio solamente la tarea LED_R estará habilitada, una vez que LED_R ha concluido inicia la tarea LED_V y se autodeshabilita.
Cuando LED_V concluye habilita LED_A y se autodeshabilita.
Cuando LED_V concluye habilita LEDS y se autodeshabilita.
Cuando LEDS se inicia por primera vez habilita LED_R, LED_V y LED_A cuando le toca de nuevo el turno se autodeshabilita y deshabilita a LED_V y LED_A
Veamos el código:
Código: C++
  1. #include "D:\Documentos\Projects\RTOS\RTOS.h"
  2. #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=9)
  3. //Como el reloj de este micro se ha puesto a correr con 20MHz el Timer0 no tiene
  4. //mayor resolución que 10ms, es por eso que el tiempo mínimo de ejecución es de 10ms
  5. #use RTOS(timer=0, minor_cycle=10ms)
  6.  
  7. int1 iB0, iB1, iB2;
  8. int1 iLEDS = 0;
  9. int8 iCountR = 0;
  10. int8 iCountV = 0;
  11. int8 iCountA = 0;
  12. int8 iCount  = 0;
  13.  
  14. #task (rate=10ms, max=10ms)
  15. void Task_Disabler();
  16.  
  17. #task (rate=250ms, max=10ms)
  18. void LED_R();
  19.  
  20. #task (rate=350ms, max=10ms)
  21. void LED_V();
  22.  
  23. #task (rate=450ms, max=10ms)
  24. void LED_A();
  25.  
  26. #task (rate=5s, max=10ms)
  27. void LEDS();
  28.  
  29. void main()
  30. {
  31.    setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
  32.    rtos_run();
  33.  
  34. }
  35.  
  36. //esta es una función truculenta porque las tareas no pueden crearse deshabilitadas
  37. //y no se pueden deshabilitar hasta que el RTOS esté funcionando. Lo considero una
  38. //deficiencia sustancial de este RTOS
  39. void Task_Disabler()
  40. {
  41.  rtos_disable(LED_V);
  42.  rtos_disable(LED_A);
  43.  rtos_disable(LEDS);
  44.  rtos_disable(Task_Disabler);
  45. }
  46.  
  47.  
  48. //cada tarea tiene un contador para llevar la cantidad de veces que se pasa por la
  49. //función y cuando se cumple el tiempo establecido entonces habilita y deshabilita
  50. //las tareas correspondientes
  51. void LED_R()
  52. {
  53.  
  54.   iB0 = !iB0;
  55.   output_bit( PIN_B0,  iB0);
  56.   if (iCountR++==20)
  57.      {
  58.        iCountR = 0;
  59.        rtos_disable(LED_R);
  60.        rtos_enable(LED_V);
  61.      }
  62. }
  63.  
  64.  
  65. void LED_V()
  66. {
  67.   iB1 = !iB1;
  68.   output_bit( PIN_B1,  iB1);
  69.   if (iCountV++==27)
  70.      {
  71.        iCountV = 0;
  72.        rtos_disable(LED_V);
  73.        rtos_enable(LED_A);
  74.      }
  75. }
  76.  
  77. void LED_A()
  78. {
  79.   iB2 = !iB2;
  80.   output_bit( PIN_B2,  iB2);
  81.   if (iCountA++==33)
  82.      {
  83.        iCountA = 0;
  84.        rtos_disable(LED_A);
  85.        rtos_enable(LEDS);
  86.      }
  87. }
  88.  
  89.  
  90. void LEDS()
  91. {
  92.   if(!iLEDS)
  93.    {
  94.      rtos_enable(LED_R);
  95.      rtos_enable(LED_V);
  96.      rtos_enable(LED_A);
  97.      iLEDS = 1;
  98.    }
  99.      else
  100.       {
  101.        rtos_disable(LED_V);  //Hay que habilitar y deshabilitar explícitamente
  102.        rtos_disable(LED_A);  //cada tarea sobre todo LED_R que debe continuar
  103.        rtos_disable(LEDS);   //ejecutándose otros 5 segundos más
  104.        rtos_enable(LED_R);
  105.        iCountR = 0;
  106.        iCountV = 0;
  107.        iCountA = 0;
  108.        iLEDS = 0;
  109.       }
  110. }
  111.  
  112.  
  113.  


Cuando corran y simulen el ejemplo verán que a veces los LEDs se quedan encendidos o apagados indistintamente, este es un problema del programa, ya que lo deseable sería que los LEDs se quedaran apagados cuando termina la función. Sin embargo lo he dejado así porque en el futuro vamos a ver cómo podemos hacer esto con las propias funciones del RTOS.

Como la vez anterior, les dejo de tarea hacerlo sin RTOS para ver como les queda, a mi llevó menos de dos horas elaborar el texto y escribir el código. Me imagino que sin RTOS me tardaría más de un día completo, consumiría un montón de páginas de explicación y otro montón para el código.

Este es un m'etodo simple, pero hay otros mucho más elaborados que iremos viendo poco a poco. La próxima entrega será yield() vs delay(), vamos a ver el método de las esperas eficientes.

Chao amigos y que lo disfruten.
« Última modificación: 09 de Mayo de 2007, 13:21:58 por reiniertl »

Desconectado LABmouse

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3574
    • Juntos es mejor
Re: Sistemas operativos en PIC
« Respuesta #35 en: 09 de Febrero de 2007, 21:17:19 »
 :-/ :-/ QUE BUENA INICIATIVA   :-/ :-/ Muchas felicitaciones por compartir tus conocimentos con nosotros.

Gracias!!!!

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17615
    • MicroPIC
Re: Sistemas operativos en PIC
« Respuesta #36 en: 10 de Febrero de 2007, 03:30:12 »
Reiniertl, he modificado tu post para aplicar "Geshi" al código, lo cual facilita su lectura. Ánimo con tu curso.
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado aitopes

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5102
    • uControl
Re: Sistemas operativos en PIC
« Respuesta #37 en: 10 de Febrero de 2007, 08:53:28 »
¡Epa! Esos son colores nuevos?
Yo estaba acostumbrado al codigo en gris.....Esto esta mejor.

Por cierto, muy interesante tu aporte, Reiniertl!
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 Y@el

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 415
Re: Sistemas operativos en PIC
« Respuesta #38 en: 12 de Febrero de 2007, 23:58:51 »
Reiniert,

Gracias por hacer esto de la manera mas entendible posible.

Has hecho que por fin le ponga ganas a la programacion en C....

Por cierto estuve buscando informacion y encontre esta web, que esta muy interesante: http://www.dea.icai.upco.es/daniel/asignaturas/TiempoReal/

Saludos,

Yoel
« Última modificación: 13 de Febrero de 2007, 11:33:58 por Yoel_Ocmin »

Desconectado togarha

  • PIC12
  • **
  • Mensajes: 87
Re: Sistemas operativos en PIC
« Respuesta #39 en: 13 de Febrero de 2007, 05:01:33 »
Muy interesante el tema, me apunto a seguirlo...


Desconectado Milo

  • PIC16
  • ***
  • Mensajes: 101
Re: Sistemas operativos en PIC
« Respuesta #40 en: 13 de Febrero de 2007, 07:37:14 »

Y yo también. :-/
"En tanto que haya alguien que crea en una idea, la idea vive" Ortega y Gasset

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #41 en: 13 de Febrero de 2007, 15:15:41 »
Yield vs delay
¿Cuantas veces en nuestras aplicaciones tenemos que situar demoras para esperar la ocurrencia de un evento determinado? Por ejemplo, para eliminar rebotes en un teclado, esperar a que el conversor AD termine y quién sabe cuantas cosas más.
Normalmente estas demoras se hacen poniendo al procesador a decrementar contadores y dar saltos recursivos como si fuese un loco. Durante todo el tiempo de la demora, nuestro microcontrolador, estará ocupado en perder el tiempo, y es por eso que a este mecanismo se le llama espera ocupada.
Sin embargo un RTOS nos ofrece un conjunto de herramientas para eliminar este molesto inconveniente, el más sencillo de ellos es aquel que le permite a una tarea decirle al RTOS: ponme a dormir hasta que me toque de nuevo mi turno de ejecutarme. Para ese efecto el RTOS de CCS implementa la función rtos_yield().
Este mecanismo es muy bueno puesto que mientras la tarea “se duerme” nuestro microcontrolador puede dedicarse a realizar otras tareas útiles y hacer de la espera ocupada una espera eficiente. Para la tarea que está dormida esto no representa nada, a ella le da lo mismo ocupar al procesador en hacer nada que en hacer algo productivo, sin embargo no ocurre lo mismo para el resto de las tareas que están esperando que se les entregue el procesador.
Otro caso en que yield() nos puede ser útil es para entregar el procesador cuando nos hemos pasado de tiempo en la ejecución de alguna tarea. Ya sabemos que el RTOS de CCS es cooperativo, por lo que si una tarea consume más tiempo de la cuenta puede hacer que el sistema colapse, ya que hay que entregar explícitamente el procesador al RTOS para que se lo de a otra tarea.
Sin embargo con la función de las estadísticas habilitadas, podemos comprobar si alguna tarea se ha pasado de tiempo, y con ello implementar mecanismos adecuados para que la tarea en cuestión reajuste su dinámica y ceda el procesador oportunamente, para ello podemos auxiliarnos de la función rtos_overrun(). Esta función no tiene valor si se usa dentro de una tarea para comprobar si ella misma se ha pasado porque la actualización de las estadísticas se hace después de ceder el procesador, considero que esta es una de las debilidades de este RTOS, en ese sentido.
El uso de rtos_overrun(), debería poderse utilizar dentro de una misma tarea para comprobar si desde que me cedieron el procesador para ejecutar, me he pasado de tiempo o no y en consecuencia entregar el procesador al RTOS.
En el ejemplo que les traigo hoy vamos a emplear rtos_yield() para ceder el procesador y rtos_overrun() para conocer si una tarea se ha pasado de tiempo.
Sin embargo yield() no es una función realmente poderosa, al menos en este RTOS, porque pone a dormir a la tarea durante un período completo del valor rate, que especificamos al declarar la función como una tarea del RTOS, y eso en ocasiones no es lo que deseamos. Aún así es mejor que el procesador de nuestro PIC esté haciendo algo útil y no perdiendo el tiempo.
En las entregas futuras veremos otras funciones que nos ofrece este RTOS para hacer esperas más eficientes vinculadas al uso de recursos compartidos en nuestras aplicaciones. El uso eficiente del procesador, los recursos del sistema y la no linealidad en la ejecución de las tareas en un sistema que emplea SO, ha obligado a los diseñadores de SO a crear mecanismos para proteger los datos y hacer uso de esos recursos de forma ordenada y segura. Estos mecanismos se clasifican en dos grupos: La sincronización y la coordinación que comenzaremos a ver en la próxima entrega.
Ejemplo:
Implemente en un PIC16F877 una aplicación en la que se ejecuten tres tareas, con las siguientes características:
La tarea No. 1 Tendrá un contador el cual se incrementa en un lazo hasta que alcanza el valor de 1000. Cuando llegue a ese valor imprime el siguiente mensaje: “Tarea contadora completada” y además pone una bandera a 1, para indicar que ha concluido. Debe colocar en esta tarea código para que la tarea ceda el procesador en algún momento al RTOS. El tiempo máximo de ejecución de esta tarea es de 10ms y debe ejecutarse cada 30ms
La tarea No. 2 debe esperar a que la tarea No. 1 termine para enviar por el puerto serie un mensaje similar al de la tarea No. 1, sin embargo, esta tarea también enviará, por el puerto serie, un mensaje cada vez que le cede el procesador al RTOS. Esta debe ejecutarse en un tiempo de 10ms y debe ejecutarse cada 40ms
Por último, existe una tarea que se encarga de hacer parpadear un LED conectado en RB0, cada 100ms y enviar un menaje por el puerto serie en caso de que la Tarea 1 o la Tarea 2 se hayan pasado en algún momento de su tiempo de ejecución. El tiempo de procesador para esta tarea debe ser de 10ms
Código:
Código: C
  1. #include "D:\Documentos\Projects\RTOS\RTOS.h"
  2. #use rs232(baud=19200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=9)
  3. #use RTOS(timer=0, minor_cycle=10ms, statistics) //se utilizan las estadísticas
  4.                                                   //hace falta para usar rtos_overrun()
  5. int32 iT1Counter = 0;
  6. int1  bT1Flag = 0;
  7. int1  bLed = 0;
  8.  
  9. #task (rate=30ms, max=10ms)
  10. void Tarea1();
  11.  
  12. #task (rate=40ms, max=10ms)
  13. void tarea2();
  14.  
  15. #task (rate=100ms, max=10ms)
  16. void Tarea3();
  17.  
  18.  
  19. void main()
  20. {
  21.    setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
  22.    rtos_run();
  23.  
  24. }
  25.  
  26.  
  27. void Tarea1()
  28. {
  29.  bT1Flag = 0;
  30.  for(iT1Counter = 0; iT1Counter <= 1000; iT1Counter++)
  31.     { if(!(iT1Counter%100))  //mecanismo para ceder el procesador cada cierto tiempo
  32.           rtos_yield(); //cuando la tarea entra en contexto se comienza a ejecutar
  33.                         //la línea a continuación de esta
  34.     }
  35.  
  36.  printf("Tarea contadora completada\r");
  37.  bT1Flag = 1;
  38. }
  39.  
  40.  
  41. void tarea2()
  42. {
  43.   //Aunque esta tarea no tiene que preocuparse mucho por ceder el procesador
  44.   //porque no tiene lazos infinitos o algo parecido puse de ejemplo tambien a
  45.   //rtos yield
  46.  if(bT1Flag)
  47.     printf("Espera por Tarea1 concluida\r");
  48.      else
  49.       {
  50.         printf("dormir T2\r");
  51.         rtos_yield();
  52.       }
  53. }
  54.  
  55. void Tarea3()
  56. {
  57.   bLed = !bLed;
  58.   output_bit( PIN_B0, bLed);
  59.   if(rtos_overrun(Tarea1))  //Si las tareas se pasaron de su tiempo de ejecución
  60.                             //se envían los mensajes por el pto serie
  61.      printf("Tarea 1 overrun\r");
  62.   if(rtos_overrun(Tarea2))
  63.      printf("Tarea 2 overrun\r");
  64. }
  65.  
Como pueden observar, este ejemplo realmente no se corresponde con una aplicación que haga algo útil, sin embargo, me ha servido para ilustrar el uso de las funciones rtos_yield() y rtos_overrun() de la manera más sencilla que encontré. Las posibilidades de estas funciones están ahora en sus manos y en lo que sus cabezas puedan crear para ellas. Hay muchísimas aplicaciones en las que pueden ser útiles, sin embargo, ya el tema de los RTOS es bastante complicado como para meternos a hacer programas complejos que demuestren su uso.
El tiempo invertido para hacer el código y el texto, fue de 2:30 hrs, la decisión de que ejemplo utilizar me tomó más de un día.

Desconectado PalitroqueZ

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5434
    • Electrónica Didacta
Re: Sistemas operativos en PIC
« Respuesta #42 en: 15 de Febrero de 2007, 16:43:21 »
Hola reiniertl. ahora que hablas de la frase "cooperativo" voy a hacer una analogía con lo que sucede en el sistema operativo Windows:

Esto es un extracto del documento El Registro de Windows y temas relacionados 14.6 Multitarea real página 35
Código: [Seleccionar]
...
1 ) Intercambio de tareas.
2 ) Prioridad de las tareas.
El intercambio de tareas, es simplemente el guardar el estado de una tarea cuando
ha agotado su tiempo (sus quantums asignados), recuperar el estado de otra tarea
y cederle el control. Normalmente esto se puede realizar por el hardware de la CPU
(existe una instrucción especifica para ello, en "todas" las CPUs del mercado, incluidos
los mainframes). Pero Microsoft en vez de utilizar el mecanismo hardware,
lo hace por software, "a mano". Esto es muy costoso en ciclos de reloj, pero aparentemente,
Microsoft no se fiaba, al menos al principio, de la implementación de
este mecanismo en la CPU por parte de Intel.
Prioridad de las tareas, es simplemente un numero asignado a cada tarea, que indica
el numero de "quantums" que puede ejecutar antes de que el sistema operativo
tome control y le ceda el control a otra tarea.
Hay que hacer notar, que una tarea, puede "perder" el control, antes de agotar su
numero de quantums. Sí esa tarea hace una petición de entrada / salida a disco por
ejemplo, debido a que esa petición es muy costosa en tiempo (estamos hablando
de algunos milisegundos), mientras se ejecuta, evidentemente la CPU puede hacer
muchísimas mas cosas. Por tanto el sistema operativo toma el control y se lo cede
a otra tarea.

El sistema operativo, debe ser "listo". Debe jugar con las prioridades de tarea y variarlas
ligeramente. Es decir, a un programa que hace muchas entradas/salida, debido
a que está poco tiempo en memoria, el sistema operativo le debería subir la
prioridad. En cambio al revés, a un programa que chupa mucha CPU y no realiza
apenas entrada / salida, el sistema operativo debe bajarle la prioridad al objeto de
que no se apodere todo el tiempo de la CPU.
...

en este parrafo hablan que existen 2 tipos de multitareas: el cooperativo y el "Real", el cooperativo lo usaban los antiguos windows (3.1 y MSDOS) y el problema que tenian era precisamente que si su mensajeria fallaba, entonces comprometería al resto de las tareas por ejecutar.

después llegó el "Real" (que no es real en verdad :)) cuyo cambio se debió a que cada tarea actuaba independientemente de la otra, como una especie de maquina virtual, y que si alguna tarea fallaba, simplemente el SO la desechaba y no interfería con el resto de las tareas y SO en sí.

el gran problema que suscitó el Windows fué la llamada compatibilidad ascendente (justa pero dañina al mismo tiempo) era que ya para el windows 95 en adelante estos aceptaban los 2 tipos de tareas, y copiandome de una formula:  "está demostrado que si en hay un sistema seguro + sistema inseguro -> sistema inseguro".


el tema que estas hablando tiene cierta analogía con lo que expuse, pero logicamente que esto es mas reservado y esperemos no tener inconvenientes con las cooperaciones en un RTOS.

Salu2
Pedro

PD: disculpa la intromisión  8)

La propiedad privada es la mayor garantía de libertad.
Friedrich August von Hayek

Desconectado LABmouse

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3574
    • Juntos es mejor
Re: Sistemas operativos en PIC
« Respuesta #43 en: 15 de Febrero de 2007, 16:57:07 »
Bueno, pues yo los esta suguiendo de ladito, y pues pensaba demorarme mas en implementar este tipo de programacion, pero Gracias a un amigote YOEL, me ha convencido de trabajar con esto de los RTOS. Es por ello, que no se si sea conveniente preguntar en este mismo hilo, o creo uno nuevo solo para preguntas y pues dejar este solo para las clases que nos estas dando. jejeje  :-)

Nuevamente Gracias por tomar esta iniciativa de enseñarnos paso a paso esto de los RTOS.

Saludos!

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #44 en: 15 de Febrero de 2007, 18:55:43 »
Referente al tema de aprender sobre los RTOS (las cosas relacionadas con este cursillo), espero las preguntas por aqu'i, porque así me realimento para mejorar el contenido. Si lo que quieren es hablar de diseño de RTOS, es mejor que vayan al hilo del amigo Darukur.

Sobre lo que Palitroquez planteo respecto a lo de Windows, puedo hacer algunas aclaraciones más adelante, porque ese es el tema de mi trabajo de la asignatura de la maestría que me tiene muy ocupado y por lo cuál no he podido dedicarme a elaborar la próxima entrega del curso. Espero tenerla para el lunes

Chao


 

anything