RTOS para PIC GNU

[Darukur]

Gente les comento mi inquietud.
Hace un tiempo que trabajo con RTOS (Sistema operativo en tiempo Real),en especial el SALVO RTOS para PIC12/16/18.
Como ahora trabajo con los micros DSPIC y PIC24 aparecio la necesidad de conseguir la version para PIC24.
Como no consigo el RTOS SALVO para PIC24/DSPIC (no me sobran 800 dolares empece a desarrollar un sistema operativo basado en el concepto del SALVO (no se usa STACK para el context switch, se utilizan labels con punteros a programa).
La verdad es que estoy conforme con los resultados y queria compartir con ustedes lo que hice para que los ayude en sus proyectos, ya que sirve para cualquier micro PIC (PIC16/PIC18/PIC24 y DSPIC) que tenga manejo de interrupciones y al menos 8 niveles de stack por hardware.
El asunto es que quiero que me ayuden con el tema de la licencia GNU, esto es que cualquiera que lo use o modifique aporte tambien.


Les paso un TXT con una descripcion, el que usa salvo vera que las funciones son similares pero el motor es otra cosa, solo usa un archivo .c y un .h y es muy simple.

[Darukur]

Por lo visto a nadie le interesa el tema 
Lamento haber moletado con esto.
Saludos

[Duende_Azul]

NO creo que moleste a nadie, mas bien creo que nadie sabe de GNU, si no ya alguien hubiera dicho algo...

[maunix]

NO creo que moleste a nadie, mas bien creo que nadie sabe de GNU, si no ya alguien hubiera dicho algo...

Duende_Azul ¿Porqué opinas que nadie sabe de GNU? Me interesa saber tu respuesta.

Creo que la propuesta de Darukur es interesante y a algún usuario le puede interesar. 

Darukur, para que no sientas que tu tema no es interesante, te comento que en mi caso aún no he necesitado de un RTOS, he hecho aplicaciones en tiempo real pero las he resuelto con mis propias rutinas sin necesitar de un sistema operativo para ello.

En mi caso no respondí porque para qué responder "no, no lo usaré por ahora".... , suena medio feo ¿no? A modo de evitar sumar números de posts con respuestas de ese tipo, prefiero no postear cuando considero que no aporto nada fructífero al tema.  A pesar de no usarlo o tener planeado usarlo en el corto plazo considero que la propuesta técnica es ¡¡super interesante!!

Usar un sistema operativo RTOS da versatilidad y lo considero muy útil sobre todo cuando se trabaja en equipo con varios desarrolladores los cuales no tienen porqué saber en detalle cómo funciona el pic o el microcontrolador del que se trate.

Así mismo , depende la aplicación, suelen tener algunas limitaciones.   Lo de "Real" no termina siéndolo tanto y hay ciertas demoras que pudieran hacer fracasar una comunicación y/o interfaz de control si no se cumplen.  Recuerdo haber leído un artículo que versaba sobre los linux RTOS para PC, donde les cuesta atender una interrupción en menos de 1mseg a pesar de contrar con un micro funcionando a 3GHz, debido a la gran cantidad de cosas que hace una pc (este sería un extremo).

Volviendo al tema , creo que es muy interesante tu propuesta desde lo técnico, de ahí a que junte muchos adeptos, solo el tiempo lo dirá.

Tal vez encarando el proyecto GNU de otra forma, con algún pequeño sitio web donde empieces a comentar del tema puedas lograr varios adeptos a la causa que incluso prueben el sistema operativo bajo diferentes condiciones interfaces de hardware/software. 

En mi caso como trabajo solo (al menos a la hora de hacer el firmware) , y tengo unas cuantas cosas ya medio cocinadas y que responden bastante velozmente con lo cual no necesito un RTOS para organizar mis softwares, pero ojo, repito, no digo que no sea necesario y hasta super útil!.

Te deseo lo mejor en tu proyecto y si creo que puedo aportar algo realmente útil a la causa, no dudes en que lo haré.

Saludos

[Duende_Azul]

Maunix, por lo general cuando se propone algo en el foro, los que tienen idea sobre el tema de inmediato opinan al respecto (eso me ancanta de este foro)  como nadie respondio supuse (por eso escribi "creo") que nadie estaba enterado sobre el asunto...   

[Nocturno]

No te puedo ayudar con lo de la licencia GNU porque no tengo ni idea, pero me ha llamado la atención lo que estás haciendo.
¿Para qué sirve?, ¿para hacer compatibles los programas entre distintos micros?, ¿para facilitar el desarrollo de aplicaciones en equipos de trabajo?

[maunix]

Maunix, por lo general cuando se propone algo en el foro, los que tienen idea sobre el tema de inmediato opinan al respecto (eso me ancanta de este foro)  como nadie respondio supuse (por eso escribi "creo") que nadie estaba enterado sobre el asunto...   

OK punto aclarado, el tema es que como regla general también es cierto que en el foro uno responde cuando puede y quiere.  Por eso esto es un foro de mutua ayuda y no un lugar donde nos pagan para que se responda de inmediato.

Puede que alguien sepa del tema y no quiera aportar o bien no tenga tiempo o bien esté en otra cosa o bien no haya podido leer el post.  Hay un post de Diego (RedPic) que muy artística y jocosamente su punto de vista de porqué no responde a todos y todo el tiempo. 

Es eso nomás, lo que yo quería puntualizar.  No siempre que no haya respuesta significa que alguien no sepa del tema.

Saludos 

[Darukur]

No te puedo ayudar con lo de la licencia GNU porque no tengo ni idea, pero me ha llamado la atención lo que estás haciendo.
¿Para qué sirve?, ¿para hacer compatibles los programas entre distintos micros?, ¿para facilitar el desarrollo de aplicaciones en equipos de trabajo?

Un RTOS te sirve desde un punto de vista "muy aereo" para poder resolver de una manera "lineal y legible" tu programa y dejar al sistema el manejo de las alinealidades.
Por ejemplo, si tuvieses que realizar al mismo tiempo dos tareas que llevan muchas etapas encadenadas, que ademas utilizan un recurso compartido (por ejemplo la USART), tendrias dos opciones:
-Realizar una tarea hasta que concluya y luego realiza la otra.
-Realizar maquinas de estados complejas para poder realizar las etapas de ambas tareas sin desatender ninguna de las dos.

Con un sistema operativo estos problemas no existen ya que uno realiza el codigo de dicha tarea como si fuese la unica tarea a correr.
Hasta las demoras son mas faciles de realizar y no dejan oscioso al micro (contra las demoras por soft).

Un ejemplito:

Código: [Seleccionar]

---------------------------------------------------------------------------
PROGRAMA PPAL:
---------------------------------------------------------------------------

int main (void)
{TIMER_INIT();LMOS_INIT();
 LMOS_CREATE_TASK(TAREA_1,TAREA_1_PTR,0); //Creo tarea 1 con prioridad 0 (la mas alta)
 LMOS_CREATE_TASK(TAREA_2,TAREA_2_PTR,1); //Creo tarea 2 con prioridad 1
 while (1)
{LMOS_SCHEDULER();
}
 return 0;
}

---------------------------------------------------------------------------
TAREAS
---------------------------------------------------------------------------
void TAREA_1 (void)
{for (;;)
   {   asm("nop");
asm("nop");
asm("nop");
LMOS_YIELD(TAREA_1_1);//Devuelve el procesador al scheluder
asm("nop");
asm("nop");
asm("nop");
LMOS_YIELD(TAREA_1_2);
asm("nop");
asm("nop");
LMOS_DELAY(1,TAREA_1_3);//Demora por "1" tick del sistema y devuelve el procesador al scheluder
   }
}

void TAREA_2 (void)
{for (;;)
   {asm("nop");
asm("nop");
asm("nop");
LMOS_YIELD(TAREA_2_1);
asm("nop");
asm("nop");
asm("nop");
LMOS_YIELD(TAREA_2_2);
asm("nop");
   }
}

---------------------------------------------------------------------------
Reloj del OS
---------------------------------------------------------------------------

void TIMER_INIT (void)
{CLKDIV=0B0000100001000011 ;//FCY=Fosc/2=Fin/2*(M/(N1*N2))=.5*((10^6*64)/(5*4))=16MIPS,PLLPOST=01=out/4,PLLPRE=11=in/5
 PLLFBD=62;//M=64-2=PLLDIV*64
 OpenTimer1(T1_ON&T1_IDLE_STOP&T1_GATE_OFF&T1_PS_1_1&T1_SYNC_EXT_OFF&T1_SOURCE_INT,16000);//
 ConfigIntTimer1(T1_INT_PRIOR_3&T1_INT_ON); //Int habilitada Prioridad 3
}

void _ISR _T1Interrupt (void) // Interrupción de Timer cada 1 mseg
{IFS0bits.T1IF=0;LMOS_TIMER();}
Aca el OS ejecutara por pasos (los que se indiquen con LMOS_YIELD) las tareas dependiendo de la prioridad.

[Darukur]

Otro ejemplo separado con el uso de semaforos en un OS:

Código: [Seleccionar]

/*
void TAREA_1 (void)
{static unsigned int T1_INT1;
 for (;;)
   {LMOS_WAIT_SEM(SEMAFORO_1_PTR,100,TAREA_1_1);//Espero evento por 100 ticks
if (!LMOS_TIMED_OUT())                                        //Si se recibio el evento antes del timeout
{T1_INT1++;
if (USART_TX_FIFO_LOAD(0,"tick\x0D",0)==0)
{USART_TX_FIFO_SEND(0);
LMOS_WAIT_SEM(USART_TX_1_EV_PTR,0,TAREA_1_2);//Espero evento por siempre
USART_TX_FIFO_RELEASE(0);
LED_2=!LED_2;
LMOS_SIGNAL_SEM(SEMAFORO_2_PTR);//Evento para despertar a otra tarea.
}
}
   }
}

void TAREA_2 (void)//Esta tarea solo genera una demora de 1 segundo y genera un evento
{for (;;)
   {LED=!LED;
     LMOS_DELAY(1000,TAREA_2_1);
     LMOS_SIGNAL_SEM(SEMAFORO_1_PTR);
   }
}

Se pueden tener multiples tareas activas y solo la que se este ejecutando momentaneamente consume tiempo de micro.
Tanto las demoras como las esperas a evento no consumen procesador sobre la tarea.

En este ejemplo una tarea solo genera una demora de 1 segundo y activa un semaforo para despertar otra tarea.
La otra tarea espera dicho evento (por un periodo de tiempo) y utiliza un recurso (la USART).
Cuando la USART termine debe avisar con el uso de semaforos para que la tarea 2 continue.
Como se puede ver el codigo es lineal pero la tarea realizada no.

Disculpen si no soy muy claro, estos dos post los arme "al vuelo".
Si quieren vean el PDF de SALVO rtos que tiene buena documentacion acerca de que es y como se usa un RTOS.
Saludos

Si quieren algun ejemplo mas claro pueden exponer un caso resuelto con "C" estandar y como se resolveria con un RTOS.

[maunix]

Darukur creo que es claro tu post, al menos desde mi punto de vista.

Yo soy de los que usan un timer y máquinas de estados 

Los retardos no me son complicados porque precisamente tengo un timer patrón (el que controla mis tareas) que dirije la cosa y me permite también configurar retardos si ese fuera mi deseo, sin interrumpir/demorar las tareas de las otras máquinas de estados.

De todas formas, coincido contigo en que lo más configurable/ajustable/rápido para desarrollar es la utilización de un Sistema Operativo, sobre todo pensando en trabajar en grupo!

Y aprovecho la oportunidad para felicitarte por tu esfuerzo.

[Nocturno]

Pues yo sin embargo no me entero. Pero no te esfuerces, miraré ese PDF que recomiendas sobre Salvo y espero pillarle el aire a esto del Sistema Operativo.

[Darukur]

Maunix, si ya estas canchero con un modo de trabajo, tal vez no tiene mucho que ofrecerte un RTOS, pero bien vale una miradilla.
Lo que te ofrece un RTOS es solucionar sistemas embebidos complejos de manera eficiente, y mas que nada de manera deterministica (hace siempre lo mismo sin depender de otros factores).
Por ejemplo, donde trabajo desarrolle un AVL que usa un RTOS y se debio alterar el funcionamiento de un "servicio".
Como el servicio estaba encapsulado dentro de una sola tarea, puedo estar seguro que los cambios realizados solo van a afectar el entorno de la misma y no otras tareas (como pasa en programas clasicos en C, con uso de variables globales, etc).
En dicho AVL tengo mas de 20 servicios corriendo, compartiendo memoria (como un recurso) y perifericos varios (I2C, USART, timers, etc) y lo desarrolla eficientemente.
No digo que no se puediese haber hecho con C solamente, solo que hubiese sido mas largo el proyecto, menos legible y mas dificil de mantener.

Un RTOS es a C como C es a assembler. Es una evolucion natural, solo cuando es necesario.

Saludos y gracias por su interes.

[Darukur]

Nocturno, como para clarificar mi pobre explicacion, si simularas el ejemplo con las 2 tareas (el primero), verias que se ejecuta la tarea 1 hasta el 1er "yield", si la tarea 2 fuese de la misma prioridad ejecutaria codigo hasta su primer yield.
Despues volveria a la tarea 1 y ejecutaria despues del primer yield hasta el segundo y asi consecutibamente.
COmo la tarea 1 tiene mas prioridad que la 2, se ejecutara hasta que el delay la "duerma" por 1 tick de reloj (1000 ciclos de Tins), dandole oportunidad a ejecutar a la tarea 2 de manera progresiva.
El hecho de los "yields" o "delays" son llamadas al OS, ya que este es un sistema operativo cooperativo (es la tarea la que devuelve el procesador), en contraposicion a un OS preemptivo (como LINUX o WINDOWS) que el mismo OS se encarga de dividir una tarea en "pedazos" ejecutados secuencialmente.

Aca deje el manual del SALVO 3.2.3 h**p://www.megaupload.com/?d=6BB27QNR
Los ** para evitar bots.

[maunix]

Maunix, si ya estas canchero con un modo de trabajo, tal vez no tiene mucho que ofrecerte un RTOS, pero bien vale una miradilla.

Claro que vale la pena la miradilla, por favor a no pensar que pienso otra cosa, si las felicitaciones son porque realmente me parece algo muy útil solo que justo ahora no lo estoy necesitando pero sí le echaré un buen vistazo cuando me lleguen los dsPIC que me pedí de sample

Por ejemplo, donde trabajo desarrolle un AVL que usa un RTOS y se debio alterar el funcionamiento de un "servicio".
Como el servicio estaba encapsulado dentro de una sola tarea, puedo estar seguro que los cambios realizados solo van a afectar el entorno de la misma y no otras tareas (como pasa en programas clasicos en C, con uso de variables globales, etc).
En dicho AVL tengo mas de 20 servicios corriendo, compartiendo memoria (como un recurso) y perifericos varios (I2C, USART, timers, etc) y lo desarrolla eficientemente.

Puedes contarme sobre a que llamas un AVL? Y me interesaría hables más acerca de este proyecto, si no te incomoda.  Soy un curioso de las cosas 'diferentes' a las que yo hago cotidianamente.

No digo que no se puediese haber hecho con C solamente, solo que hubiese sido mas largo el proyecto, menos legible y mas difícil de mantener.

Coincido, por eso aclare que un OS sirve muchísimo para trabajar en equipo al punto que se hace casi una necesidad más que un lujo.

Un RTOS es a C como C es a assembler. Es una evolucion natural, solo cuando es necesario.

Me gustó esta frase.


PD: el link no lo puedo acceder porque me dice que ya estan todos los cupos llenos para Argentina  y que debo intentar más tarde

Bueno, intentaré mas tarde. 

[Darukur]

AVL Significa Automatic Vehicle Localization.
El equipo toma datos varios del coche:
-Posicion satelital.
-Altura c/r al mar.
-Velocidad por GPS (aerea) y por odometro.
-Sensores
-Estados del equipo
-Niveles de señal de GSM
-ETC

Y los envia a un servidor SMS (si se usa modalidad SMS) o por dos sockets TCP (si se configuro internet) la informacion del mismo, hasta con historicos almacenados en la memoria del equipo.
Tambien se le puede solicitar info y configurarlo, es mas o menos lo mismo que otros equipos de AVL.

Te paso el mismo PDF (DEL SALVO) pero de rapidshare : h**p://rapidshare.com/files/12902417/SalvoUserManual.pdf.html