TODOPIC
Microcontroladores PIC => RTOS => Mensaje iniciado por: Darukur en 17 de Enero de 2007, 11:58:27
-
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.
-
Por lo visto a nadie le interesa el tema :(
Lamento haber moletado con esto.
Saludos
-
NO creo que moleste a nadie, mas bien creo que nadie sabe de GNU, si no ya alguien hubiera dicho algo...
-
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
-
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... :P
-
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, 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... :P
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 :)
-
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:
---------------------------------------------------------------------------
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.
-
Otro ejemplo separado con el uso de semaforos en un OS:
/*
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.
-
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 :lol: :lol:
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.
-
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.
-
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.
-
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, 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. :-)
-
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
-
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
Ah, muy bien. Interesante aplicación! tamibén he hecho algunas cositas con celulares.
Por cierto, he bajado el manual del rapidshare, ni bien tenga un tiempo le echaré un vistazo.
:)
-
La verdad es que he seguido el Hilo y me parece muy bueno el uso de RTOs!!
Alguno de ustedes sabe si realmente funciona el uso de RTOs que trae el CCS en la version 4.XXX ??? :lol: :lol: :lol:
Si anda me gustaria empezar a utilizarlo.
-
Ya he echado un vistazo al PDF y más o menos me voy enterando.
Creo que el sistema es bueno pero sólo se aprovecha realmente con aplicaciones realmente complejas. ¿Tienes algún ejemplo de aplicación desarrollada con este sistema?
No estoy pidiendo que lo publiques, sólo que lo enuncies para hacerme una idea de su complejidad.
Gracias
-
En el hilo de Reproductor de Mp3 con DSPIC postee un driver de MMC mas sistema de archivos hecho con el RTOS Salvo
-
Pues lo he revisado entero y veo que hablas de él, pero no veo el link.
De todas formas, me hago cargo de la complejidad del sistema.
-
Nocturno, esta casi al final del post:
http://www.todopic.com.ar/foros/index.php?topic=14639.60
Bueno aca subo el codigo de la MMC-FAT16...
Le agregue un LEEME.TXT explicadno que lo subo solo con fines educacionales, si van a querer hacer plata con eso por favor avisen y repartan lol.
Esta Hecho en PICC18 + SALVO RTOS 3.2.3
Sino directamente el enlace:
h**p://www.todopic.com.ar/foros/index.php?action=dlattach;topic=14639.0;attach=2897
-
Es díficil poner una línea entre lo que es educacional vs lo que es GNU vs lo que es para fines comerciales.
Lo ético sería , como hacen muchos que desarrollan GNU, dar soporte luego. La ganancia está en el soporte y no en el código en sí.
La filosofía GNU es complicada, desde muchos puntos de vista. Se complica sobre todo en países como Argentina, donde los ingresos no permiten que uno se dedique a desarrollar códigos para hacer free. No hay universidades que paguen buenos sueldos y permitan a gente con mentalidad GNU desarrollar aplicaciones libres para por ejemplo, empresas que quieran montar código propietario usando software libre.
Es un tema de difícil solución y que da para un hermoso debate.
En cuanto a que si alguien lo usa para fines comerciales y te avise... ahí solo entra la 'confianza' en la gente del foro. Tal vez moviéndolo a E.T.E. podríase minimizar al máximo el problema.
Por cierto Darukur, ¿de dónde sos?
-
según la wikipedia (http://es.wikipedia.org/wiki/GNU) el GNU es un concepto que tiende sobre una alternativa del UNIX pero libre(corrijanme si me equivoco), creo que el término correcto es GNU GPL (http://es.wikipedia.org/wiki/GPL) que significa licencia pública general.
yo de RTOS conozco solo el concepto, me gustaría implementarlo en un proyecto que estoy haciendo, pero no estoy seguro si funcionará, ya que dicho proyecto trata de procesar voz a 8 khz y guardar dichos datos, habría que determinar los retardos involucrados, en este caso sería bajo el compilador CCS.
una pregunta Darukur ¿ese SALVO RTOS es para correr sobre C de Hitech solamente?
Salu2
Pedro
-
Bien, ya lo he descargado. Se ve completamente distinto el código a lo que estoy acostumbrado.
A ver si a ratos lo voy analizando despacito.
-
Bien, ya lo he descargado. Se ve completamente distinto el código a lo que estoy acostumbrado.
A ver si a ratos lo voy analizando despacito.
Qué bueno Manolo, espero nos comentes tus avances.
Realmente me interesa pero últimamente tengo menos tiempo libre que que Pamela Anderson para responder mails.
-
Por cierto Darukur, ¿de dónde sos?
Soy Argentino, nacido en Cordoba que vivio 19 años en Necochea y por ahora voy 11 años en Mar del Plata, y si se me raya el moño :) en cualquier momento me voy a laburar a Comodoro Rivadavia...
-
una pregunta Darukur ¿ese SALVO RTOS es para correr sobre C de Hitech solamente?
SALVO RTOS hace porting para casi todas las plataformas (Microchip PIC/DSPIC, ARM7/9, MSP430, AVR, TEXAS, etc)
Lo que seguro vas a conseguir si googleas es el Salvo RTOS for PIC 3.2.3 que anda para PIC (no DSPIC y PIC24), MSP430, y AVR.
EL RTOS que hice yo sirve para cualquier micro PIC con al menos unos niveles de stack e interrupciones, para que funcione en otros micros hay que revisar la rutina que hace el "yield".
Obviamente para micros potentes no es la mejor implementacion, de seguro podes usar el FREERTOS que es tanto preemptivo como cooperativo.
PD: Me alegro de el interes que se ha levantado por los sistemas operativos, les agradezco!
-
Yo de RTOS conozco solo el concepto, me gustaría implementarlo en un proyecto que estoy haciendo, pero no estoy seguro si funcionará, ya que dicho proyecto trata de procesar voz a 8 khz y guardar dichos datos, habría que determinar los retardos involucrados, en este caso sería bajo el compilador CCS.
Te comento PalitroqueZ que la latencia de un RTOS de estas caracteristicas es totalmente dependiente de: Vos!
EL "Scheluder" busca la tarea de mas alta prioridad que este en condiciones de correr (que sea su turno).
Una vez llamada la tarea, la duracion de un "slice" de la misma depende del mismo programador (uno mismo ubica el "Yield" para entregar el procesador al "scheluder" donde uno quiere).
Los programas en interrupciones se siguen realizando de la misma manera que siempre solo que se utilizan eventos propios del RTOS para informar resultados (los semaforos).
Las demoras o esperas que uno le pide al RTOS en una tarea no generan latencia ni consumo de micro ya que no se queda en dicho lugar esperando su resolucion, lo realiza el RTOS de manera eficiente.
Es mas, es mucho mas probable que responda mucho mas rapido un RTOS que un programa en C clasico, a menos que en tu programa agregues cuando queres volver a atender dicho proceso ademas del evento, sino estarias entrando innecesariamente un monton de veces a una tarea que no lo requiere, consumiendo tiempo util.
EJ programas C clasico no optimizado y optimizado (solo ejecuta y analiza cuando debe):
Caso 1:
while (1) //Superloop de tareas
{ejecutatarea1();//Cada vez que pasa por aca la ejecuta
ejecutatarea2();//Cada vez que pasa por aca la ejecuta
ejecutatarea3();//Cada vez que pasa por aca la ejecuta
}
Caso 2:
while (1) //Superloop de tareas
{if (tarea_1_enable&&tarea_1_timeout){ejecutatarea1();}//Solo cuando esta habilitada ejecuta
if (tarea_2_enable&&tarea_1_timeout){ejecutatarea2();}//Solo cuando esta habilitada ejecuta
if (tarea_3_enable&&tarea_1_timeout){ejecutatarea3();}//Solo cuando esta habilitada ejecuta
}
-
una pregunta Darukur ¿ese SALVO RTOS es para correr sobre C de Hitech solamente?
SALVO RTOS hace porting para casi todas las plataformas (Microchip PIC/DSPIC, ARM7/9, MSP430, AVR, TEXAS, etc)
Lo que seguro vas a conseguir si googleas es el Salvo RTOS for PIC 3.2.3 que anda para PIC (no DSPIC y PIC24), MSP430, y AVR.
EL RTOS que hice yo sirve para cualquier micro PIC con al menos unos niveles de stack e interrupciones, para que funcione en otros micros hay que revisar la rutina que hace el "yield".
Obviamente para micros potentes no es la mejor implementacion, de seguro podes usar el FREERTOS que es tanto preemptivo como cooperativo.
PD: Me alegro de el interes que se ha levantado por los sistemas operativos, les agradezco!
Creo que es un tema que nació para quedarse solo que el nicho de aplicación no será tan amplio.
Si uno se fija en los micros de 32 bits , todos tienden a usar un OS. Se hace todo menos tedioso. :)
Hace tiempo había pegado un vistazo al uClinux por ejemplo, que se usa para micros más potentes (por eso no lo usé ya que no tenía ninguno de los micros soportados, jeje).
PD: me sonabas con acento argentino pero quería que lo digas vos, tal vez le erraba jeje.
-
Tono argentino, si. Cordobes no :( , lo perdi hace años, no voy tan seguido a Cordoba ahora.
Saludos coprovinciano!
-
Tono argentino, si. Cordobes no :( , lo perdi hace años, no voy tan seguido a Cordoba ahora.
Saludos coprovinciano!
Este país marea... yo soy Pampeano en Córdoba, tampoco tengo acento :? :?
Es más , mi señora se me ríe porque ni siquiera me sale imitar el acento cordobés, a pesar de mis 14 años en esta hermosa provincia.
-
Darukur, veo que FreeRTOS ya soporta PIC24
http://www.freertos.org/
-
Si lo vi nocturno, pero como hay dos ramas mas del mismo producto (SafeRTOS y FreeRtos Pro), con lo que te da de pensar si el FreeRtos standard tendra algunos problemas.
El RTOS que hice yo anda bien para PIC24, es mas lo hice porque no tenia RTOS SALVO para PIC24 y no queria meterme en FreeRTOS hasta estar seguro.
Si quieren lo subo.
Saludos
-
Marce, te doy ánimos para seguir con tu RTOS. Si contrato alguna conexión de internet y me libero un poco de las cargas horarias del trabajo empiezo a darte una mano, así continuamos la tradición de compartir conocimientos como hacíamos en Mar del Plata.
Saludos desde Atucha.
Martín
PD: Por fin pude agarrar una PC con internet un rato.
-
Gracias Tincho, ya dentro de poco lo posteare al codigo del LMOS con algunos ejemplitos.
Vos me ayudaras con lo de las licencias.
Salute
-
Bueno Marce, acordate que estuve preparando la charla de licencias para la conferencia de CafeLUG que al final no pude ir por falta de tiempo. Voy a ver si lo leo de nuevo para refrescar los tipos de licencias.
Salutes.
Martín
-
Darukur y Zaphyrus, hay una lista de correos que se llama gnupic.
En ella se tratan temas sobre software libre para los pics. Softwares de la talla de gpsim, gpasm, ktechlab, pikdev, piklab
Puntualmente hace poco tiempo, están aunando esfuerzos para hacer un producto conjunto de todos estos, algo que competiría por ejemplo con Proteus pero con 0 costo para el desarrollador.
El ejemplo en concreto es que a veces cuando uno desarrolla algo solo o con poca gente, es común que por razones laborales, personales o de diversa índole el proyecto quede varado, desatendido y por ende la gente que venga como "usuario del producto" termine perdiendo interés en su uso.
Este ejemplo de arriba, es realmente una cosa genial y se están organizando para sacar lo mejor de cada producto en uno solo. Es probable que unir una buena idea + conocimientos a un proyecto ya vigente podría ser un aporte muy enriquecedor y que la comunidad toda se vea beneficiada por contar con gente inspirada, idónea y en cantidad, todos aportando a un mismo proyecto.
Tal vez unirse al proyecto freertos no sea mala idea, para aportar ideas, pruebas, conocimientos y hacer un Sistema Operativo mucho más potente, versátil y eficiente. Es solo una sugerencia y habría que ver si los de ahí están dispouestos a abrirse a nuevas ideas y aportes.
-
Hola:
He visto este hilo y me interesa mucho el tema. La idea de utilizar un SO en mis aplicaciones me vino desde que comencé a trabajar en mi tesis de ingeniería, en aquel tiempo, no sabía que existían cosas como el RTOS de CCS y la verdad pasé bastante trabajo para lograr que el programote de mi tarea funcionase bien y en los tiempos requeridos. De hecho tuve que complicarme bastante con los temporizadores para que me interrumpieran a intervalos regulares y gestionar unos contadores para ejecutar funciones y ..... complicado.
Me gusta que alguno de ustedes comiencen a trabajar con esta potencialidad que ofrecen algunas herramientas o compiladores, y no es para menos. En el futuro cercano tengo que hacer una aplicación bastante complicada en el trabajo y no me caben dudas que utilizar un SO para meterlo en mi flamante PIC18F8722 y además de eso tener que controlar a todos los compañeros que están bajo mi tutela será todo un reto, por eso pienso que utilizar un RTOS para eso es una buena idea.
Podemos debatir mucho acerca de si es o no viable utilizar un RTOS en los PICS. Yo particularmente pienso que al igual que para una tarea determinada utilizamos el microcontrolador adecuado (a m i no se me ocurre utilizar el 18F8722 para apagar y encender un bombillo) es igualmente útil y poderoso un RTOS para resolver problemas complicados o trabajosos, donde varias cosas deben ser atendidas de forma "simultánea" y que en definitiva cuando la aplicación corra lo haga en "tiempo real".
Y si además hay un esfuerzo importante para producir un entorno de desarrollo basado en GNU, de modo que las cosas nos cuesten menos dinero y tengamos a un montón de personas que como en este foro colaboran para ayudarse así mismos y a los demás, entonces creo que me sumo a Uds. en la campaña de los RTOS para PIC
-
Buenisimo reiniertl, gracias por tu interes!
Dentro de poco lo subo al RTOS que hice asi lo prueban.
Saludos
-
La verdad es que he seguido el Hilo y me parece muy bueno el uso de RTOs!!
Alguno de ustedes sabe si realmente funciona el uso de RTOs que trae el CCS en la version 4.XXX ??? :lol: :lol: :lol:
Si anda me gustaria empezar a utilizarlo.
Nadie me contesto esta pregunta.
Debo suponer que no funciona ??? :shock: :shock: :shock:
-
La verdad es que he seguido el Hilo y me parece muy bueno el uso de RTOs!!
Alguno de ustedes sabe si realmente funciona el uso de RTOs que trae el CCS en la version 4.XXX ??? :lol: :lol: :lol:
Si anda me gustaria empezar a utilizarlo.
Nadie me contesto esta pregunta.
Debo suponer que no funciona ??? :shock: :shock: :shock:
Tal vez debas suponer que nadie lo probó , por eso (en mi caso) no te he respondido antes.
-
Disculpa MGLSOFT, no conteste ya que al no conocerlo esperaba a alguien que si lo haya probado.
Sera cuestion de hacerse un poco de tiempo y mirarlo.
Saludos
-
Yo no lo he probado tampoco. Pero en la ayuda de la versión 3.249 aparecen unos ejemplos que supongo que si los copias y simulas deben funcionar.
En este caso los ejemplos están en en la sección "Example programs", lo primero que aparece es una lista de los programas de ejemplo, pero al final aparecen unos programas escritos en C, leete los encabezados y te los topas.
Como tienes otra versión puede que los ejemplos estén en algunos de los ficheros con que viene el compilador, pero en algún lugar seguro que están. Yo tendría que cacharrearlos un poco para ver como funcionan porque algunos están hechos para trabajar con las tarjetas de desarrollo de CCS y todavía no las tengo en la mano, por lo que tendría que hacer algunas modificaciones.
De todas formas voy a tirarle y a pensar en toda la sarta de cosas que mi profe de SO me ha sonado en los últimos días a ver si pongo algún tipo de información general sobre el funcionamiento de los SO, para que los neófitos vayan aprendiendo y también aporten, que falta hace.
-
Bueno, gente aca subo el RTOS que desarrolle, el ejemplo es para un PIC24HJ256 (para simular con el MPLAB SIM).
Las tareas que corren no hacen nada (puro NOP) pero lo importante es ver como el OS gestiona los pasos de ejecucion del codigo.
Despues realizare lo mismo para PIC16/18, no son muchos los cambios.
Agradezco sus comentarios!
PD:Editado, bajar la ultima version
-
La verdad es que he seguido el Hilo y me parece muy bueno el uso de RTOs!!
Alguno de ustedes sabe si realmente funciona el uso de RTOs que trae el CCS en la version 4.XXX ??? :lol: :lol: :lol:
Si anda me gustaria empezar a utilizarlo.
Nadie me contesto esta pregunta.
Debo suponer que no funciona ??? :shock: :shock: :shock:
Tal vez debas suponer que nadie lo probó , por eso (en mi caso) no te he respondido antes.
he probado los ejemplos que trae el PCWH, sobre todo el ejemplo "ex_rtos_demo_5_yield" que luce mas sencillo, envia un contador incrementado al puerto serial, pero me apena decir que no entiendo mucho lo que hace, hay que estudiarse los conceptos involucrados al RTOS, por ejemplo la función rtos_yield ( ); que viene siendo el evento yield
hay otra "función" que existe, se llama #task(rate=500ms,max=100ms,queue=2), ¿tendrá que ver esto con la latencia de una tarea?
la confusión que tengo con el rtos es que estoy acostumbrado al ensamblador o al C, creo que esto se llamaría programación lineal y entonces cuando veo un código en RTOS veo esos saltos y esas ejecuciones que son nuevas para mi :shock:
Salu2
Pedro
-
Hola amigos, cumlpiendo con mi promesa de involucrarme en la programación con Sistemas Operativos (SO) en los PIC, he abierto un hilo nuevo, con un nombre más llamativo, para que compartamos nuestros conocimientos al respecto.
Lo que pretendo en primer lugar es ir poniendo información para que los foreros que no conocen nada sobre el tema de los SO aprendan un poco como es su dinámica, y por supuesto, también código, que vendrá con el tiempo, para poder aplicaciones con esta poderosa herramienta.
el link es el siguiente: Sistemas operativos en PIC (http://www.todopic.com.ar/foros/index.php?topic=15876.0)
Recomiendo que este hilo quede como está hasta ahora para no saturar el otro que más bien es una especie de curso introductorio en el tema. Espero que les sea de utilidad.
-
Espero sus respuestas acerca del RTOS que subi!!!
Tambien saber quien lo esta probando.
Saludos.
-
Yo tengo ganas Darukur, pero me falta tiempo. No obstante, me habéis despertado el gusanillo y tendré que satisfacerlo cuando pueda.
-
Hola, yo probe los ejemplos del CCS los compilé y simulé en PROTEUS y funcionaron bien. Los probé tb con el PIC16F877 y todo bien.
Saludos
-
Gente aca subo una version actualizada del RTOS, ahora en la configuracion se elige el tipo de compilador.
Esta el anterior para C30 (PIC24) y el mismo ejemplo para PICC18 de Hitech.
Si quieren algun ejemplo concreto de utilizacion pongan sugerencias.
Espero sus comentarios
-
Ya estuve "cacharreando" el RTOS de CCS y creo que para empezar está bien, sin embargo me fui al link de FreeRTOS y me parece que es mejor opción en muchos sentidos que el RTOS de CCS, entre otras cosas, porque tienes acceso al código fuente y podemos además de utilizar el RTOS, optimizar FreeRTOS para nosotros mismos.
Estuve viendo el SALVO y me parece un propuesta interesante, aunque el código es un poco "verboso" (difícil de entender), gracias a Darukur por tus aportes en el desarrollo de RTOS.
Sin embargo quisiera que alguien me dijera donde consigo una versión del compilador GCC para PIC's, si es que existe. El código de FreeRTOS para PIC's está escrito con GCC, pero no dicen donde se puede obtener. Además mi intención futura con la idea de los SO para PIC's es que utilicemos, siempre que se pueda, software bajo licencias GNU. Las ventajas al respecto no hay que explicarlas pero puedo enumerar algunas: acceso al código fuente, menor o cero costos en licencias y una comunidad colaborando para mejorar constantemente los productos on conocimiento de que se hace y por qué.
Entonces, espero sus respuestas.
-
Hola, yo probe los ejemplos del CCS los compilé y simulé en PROTEUS y funcionaron bien. Los probé tb con el PIC16F877 y todo bien. Si mal no recuerdo el RTOS le aumentaba cerca de 800 palabras de programa al codigo.
Saludos
Podras subir los ejemplos que simulaste y que version de CCS tienes??
A mi no me anduvieron en la simulacion... :? :? :? :?
-
Maunix las herramientas de GNUPic las he investigado pero están medias abandonadas para las nuevas arquitecturas. Gpsim, gpasm, ktechlab, pikdev, piklab las he usado y probado pero están a años luz de el entorno de Microchip (eso sí hay que darle tiempo).
Si queres algo com el Proteus dale una mirada a gEDA.
Saludos.
-
Sin embargo quisiera que alguien me dijera donde consigo una versión del compilador GCC para PIC's, si es que existe. El código de FreeRTOS para PIC's está escrito con GCC, pero no dicen donde se puede obtener. Además mi intención futura con la idea de los SO para PIC's es que utilicemos, siempre que se pueda, software bajo licencias GNU. Las ventajas al respecto no hay que explicarlas pero puedo enumerar algunas: acceso al código fuente, menor o cero costos en licencias y una comunidad colaborando para mejorar constantemente los productos on conocimiento de que se hace y por qué.
No hay un puerto del GCC para los PICs, de hecho es bastante difícil que lo haya. Según la lista de correos gnupic, Scott Dattalo menciona que no es imposible pero sí tiene su complejidad.
Si quieres usar algo GNU para pics que compile en C, por cierto podrías probar el SDCC que tiene puerto para los PICs.
SDCC (http://sdcc.sourceforge.net/)
Scott Dattalo es todo un hacendoso en esto de tools gnu para pics! Autor del gpsim, gpasm y del puerto SDCC para pics.
De por sí, una persona para admirar, no solo por sus conocimientos sino por su humildad.
-
Le agregue al RTOS un servicio de contabilizacion del porcentaje de uso de micro por tarea.
Funciona muy bien, pero como queria que consumiera poco no tiene en cuenta el consumo de procesador propio del RTOS.
Lo que hace es "pegarle" ese pequeño porcentaje a cada tarea.
Igual se puede apagar y no consume, y cuando esta habilitado solo consume la consulta (que es muy poco).
Saludos
Prueben poniendole codigo a las tareas y vean.
-
No hay un puerto del GCC para los PICs, de hecho es bastante difícil que lo haya. Según la lista de correos gnupic, Scott Dattalo menciona que no es imposible pero sí tiene su complejidad.
Si quieres usar algo GNU para pics que compile en C, por cierto podrías probar el SDCC que tiene puerto para los PICs.
...
Maunix ¿que significa cuando hablas de la existencia de puertos para un compilador? :(
-
Gracias Maunix por el enlace al compilador.
-
Bueno, no pude con mi genio y ahora se puede configurar que contabilice aparte el consumo del scheluder (tambien configurable)
Ahora en vez de tener 33% de micro por cada tarea (son las 3 iguales) se tiene 27%, que es el valor real (el scheluder se come 19% del micro).
A no asustarse con esto:
El asunto es que las 3 tareas tienen NADA de codigo (contra el codigo del scheluder) y estan siempre haciendo YIELD (osea que quieren el procesador cuanto antes nuevamente).
Si las tareas tuviesen mas codigo antes de hacer yield (al menos unas cuantas instrucciones) ya se llevarian mayor porcentaje de micro estadisticamente.
Otro factor es que el scheluder obviamente se comporta como el proceso "idle" de windows, alguien se tiene que consumir el tiempo libre del micro. EJ: con las tres tareas dormidas el consumo del scheluder es 100%.
PD:
Agregue LMOS_EXAMPLE_2_04.ZIP que hace referencia a esto, las 3 tareas son iguales pero consumen mucho micro por yield (un bucle asesino de 10000 iteraciones ANTI RTOS :D ), ahora con este ejemplo se ve que el scheluder consume de 0 a 1 y las 3 tareas 33 %.
-
Maunix ¿que significa cuando hablas de la existencia de puertos para un compilador? :(
Por puertos se conoce comunmente cuando un compilador puede compilar código que tendrá como destino otro microprocesador/microcontrolador.
Por ejemplo el SDCC tiene puertos para micros 8051, PICs, Zilog Z80 , Motorola hc08 y otros.
:)
-
He descargado tus interesantes ejemplos Darukur y les he echado un vistazo por encima.
Estoy pillando conceptos poco y poco; ya sé qué es el Scheduler, para qué sirve el evento Yield, y la mecánica de crear tareas. Pero hay un concepto que no pillo: ¿qué son y para qué sirven los semáforos?
-
Es como un flag o evento de disparo, de la misma manera que los flags de interrupciones, pero con posibilidad de acumulamiento de eventos y hasta envio de mensajes entre tareas.
Una tarea puede pedir la ejecucion de cierto proceso a otra (o a un periferico) y debe quedarse esperando al "semaforo" que utiliza el otro proceso como indicador de resolucion de tarea.
De esta manera dicha tarea se "duerme" hasta que se active el semaforo por parte del otro proceso o se venza el tiempo (si es que se puso timeout).
-
una sugerencia sería explicar/agrupar los conceptos basicos asociados al RTOS. por ejemplo:
Scheduler??
Yield??
semáforos??
task??
poll??
message??
Hola, yo probe los ejemplos del CCS los compilé y simulé en PROTEUS y funcionaron bien. Los probé tb con el PIC16F877 y todo bien. Si mal no recuerdo el RTOS le aumentaba cerca de 800 palabras de programa al codigo.
Saludos
Podras subir los ejemplos que simulaste y que version de CCS tienes??
A mi no me anduvieron en la simulacion... :? :? :? :?
en el adjunto está un ejemplo montado en proteus, usa un 18F452 y el virtual terminal, se puede seguir la simulación paso a paso usando el .cof
pero se allí no paso :?
-
Hola MGLSOFT, yo utilizo la version 3.245 y en cuanto a la simulacion el circuito no es mas que el PIC con los leds conectados en los pines segun esta definido en el codigo o con un LCD segun sea el ejemplo.
Bueno algunas definiciones muy generales:
Scheduler (Planificador): Es la parte del RTOS que se encarga de decidir que tareas va ejecutar el MICRO de acuerdo a como esté implementado éste, si es cooperativo, apropiativo u opera en esquema round robbin, por prioridades, etc.
Task (Tarea): Cuando se hace uso de RTOS, el programa se lo divide en pequeñas secciones de codigo llamadas taks que realizan todas las funciones del sistema, es decir, encender un led, enviar datos el LCD, leer el puerto X, etc.
Yield: Es una función del sistema operativo que devuelve el control del micro al planificador de manera incondicional.
Espero les sirva,
Saludos
-
Si, ya lo baje al ejemplo y curiosamente anda aqui.. :shock: :shock: :shock: :shock: :shock:
Lo otro curioso es que compile el ejemplo de CCS y tambien anda!! :? :? :?
Pero a mi no me anduvo, asi que vere que hice mal!!! :mrgreen: :mrgreen: :mrgreen:
-
Les comento las caracteristicas del Sistema Operativo que desarrolle (LMOS):
Sistema operativo:
-Cooperativo.
-Sin uso de stack*
-Manejo de multiples eventos con timeouts
-Manejo de retardos
-Manejo de prioridades:
Ejecuta la tarea activa de mas alta prioridad, a tareas con la misma prioridad realiza Round Robin.
32 niveles, 0=La mas alta prioridad
-Contabilizacion de uso de CPU por tarea.
-Soporta PIC24, PIC18 y PIC16 a traves de configuracion
Llamadas al OS:
LMOS_INIT() Inicializa el sistema operativo
LMOS_SCHEDULER() Manejador de tareas, se ubica en el prog ppal en un superloop luego de las inicializaciones.
LMOS_GET_TICKS() En el caso de estar activado LMOS_DEF_ENABLE_SYS_TICK entrega el tick actual del sistema
LMOS_TIMER() Llamada al tick del sistema, se ubica en la interrupcion de reloj.
LMOS_CREATE_TASK() Crea la tarea en tiempo de ejecucion y la pone en estado "elegible"
LMOS_DESTROY() Destruye la tarea actual y retorna al scheluder
LMOS_DESTROY_TASK() Destruye la tarea indicada
LMOS_STOP() Detiene la tarea actual y retorna al scheluder
LMOS_YIELD() Genera un context switch en la tarea de donde se lo llamo y retorna al scheluder
LMOS_GET_TASK_STATE() Entrega el estado actual de la tarea solicitada
LMOS_CHANGE_PRIO() Cambia la prioridad de la tarea actual
LMOS_CHANGE_TASK_PRIO() Cambia la prioridad de la tarea seleccionada
LMOS_DELAY() Genera la demora seleccionada y genera un context switch en la tarea de donde se lo llamo y retorna al scheluder.
LMOS_INIT_SEMAPHORE() Inicializa el semaforo seleccionado
LMOS_SIGNAL_SEM() Activa el semaforo seleccionado
LMOS_WAIT_SEM() Espera al semaforo seleccionado por un periodo seleccionado (0=por siempre) y genera un context switch en la tarea de donde se lo llamo y retorna al scheluder.
LMOS_TIMED_OUT() Consulta al OS si el semaforo elegido por la tarea fue activado.
LMOS_CPU_USAGE() Entrega el porcentaje usado de micro por la tarea seleccionada en el momento con una actualizacion dependiente de LMOS_DEF_N_CPU_TOT_TICK
LMOS_CPU_USAGE_CURRENT() Entrega el porcentaje usado de micro por la tarea actual en el momento con una actualizacion dependiente de LMOS_DEF_N_CPU_TOT_TICK
LMOS_CPU_USAGE_SCHED() Entrega el porcentaje usado de micro por el Scheduler en el momento con una actualizacion dependiente de LMOS_DEF_N_CPU_TOT_TICK
LMOS_GET_TASK_TICK() Entrega cantidad de ticks al momento, haciendo la diferencia entre tomas de dicha funcion se sabe el tiempo de proceso por cada contexto
En mi pagina (que esta re verde) :mrgreen: voy a subir el codigo mas actualizado.
Saludos
-
Les comento que he estado viendo las funciones que ofrece el LMOS y me parece que está fortísimo ese RTOS, que nace gracias a un amigo del foro. En el hilo que estoy llevando sobre RTOS (Sistemas Operativos en PICSistemas Operativos en PIC (http://www.todopic.com.ar/foros/index.php?topic=15876.0)) estamos utilizando el de CCS.
Sin embargo creo que la oferta de Darukur es muy interesante y productiva por muchas razones, simplemente no lo estoy utilizando porque ese RTOS está en fase de desarrollo y como el de CCS es más simple es muy bueno para comenzar a dar los primeros pasos. Así que después de CCS, me muevo para los RTOS GNU como el del amigo Darukur.
En la medida en que vaya poniendo los documentos del curso iré haciendo una comparación del RTOS de CCS con respecto a LMOS, para que vean que interesante está LMOS. Lástima que no sea un SO de tiempo compartido, pero creo que eso se puede mejorar en el futuro.
Saludos Reinier
-
Darukur:
realmente es un trabajo muy interesante el tuyo!!
Has logrado interesarme en el tema!!
Gracias y adelante con el tema!!, yo poco puedo aportar pero ire aprendiendo de la mano de los ahora aportan. :mrgreen: :mrgreen: :mrgreen:
-
Lástima que no sea un SO de tiempo compartido, pero creo que eso se puede mejorar en el futuro.
No creo que lo haga preemptivo al LMOS ya que sino no seria para todos los PICS y compiladores (no se puede hacer manejo de stack por soft).
Mas que nada que dejaria de ser "Light" (L ight M icrocontroller O perating S ystem) :mrgreen:
La idea de este RTOS es que tenga todas las funcionalidades basicas sin que se engorde en codigo, RAM o en latencia para el codigo de usuario.
Para esas necesidades hay RTOS muy buenos como el uCOS-II, el CMX y el FreeRTOS.
Despues habria que armar ejemplos simples para usar el LMOS.
-
Darukur, dices que es compatible con PIC16, PIC18 y PIC24. ¿No es compatible también con dsPIC30 y dsPIC33 o es que no has podido probarlo?
-
Darukur, dices que es compatible con PIC16, PIC18 y PIC24. ¿No es compatible también con dsPIC30 y dsPIC33 o es que no has podido probarlo?
La compatibilidad es por compilador, PICC PICC18 de Hitech y C30 de Microchip lo probe.
Si funciona para DSPIC.
EL asunto sobre C30 es que no funca el nivel 3 de optimizacion (hasta "s" funciona bien), intente un directiva de assembler pura (para q pegue todo el codigo) pero no le doy a la tecla con el ASM para C30.
#define LMOS_YIELD(LY_TASK_NAME) asm volatile( "MOV _" #LY_TASK_NAME ", W0 \n" \
"MOV W0, _TCP_GLOBAL \n" \
"RETURN \n" \
"_" #LY_TASK_NAME ":" )
no me entiende el label dinamico "LY_TASK_NAME"
En definitiva: usalo tranquilo en PIC16 y 18 y en PIC24/DSPIC tene en cuenta no usar el ultimo nivel de optimizacion (el 3) ya que no hace lo debido (se ahorra codigo el sonzo) :D
Salute
-
Ya comprendí tu idea Darukur, es cierto lo que dices sobre la lectura de la pila, aunque tengo entendido que en los PIC 18 si puede leerse la pila aunque no se tiene control sobre ella (nada de PUSH o POP).
El no poder leer la pila es una de las razones que impide hacer un RTOS de tiempo compartido para PIC16, ya que al no poder leer la pila no puede hacerse el cambio de contexto entre tareas, de eso ya hablaré un poco en el cursillo sobre RTOS.
Saludos reiniertl.
Ahora me voy a poner a escribir la próxima entrega.
-
Darukur, vas como una tromba. Que apacionante es el mundo de los sistemas operativos lástima que no pueda dar una mano, el laburo me mata con el horario. Eso de levantarme a las 6 de la matina y volver a las 19hs no es para mí.
Felicidades Marce y dale para adelante, espero tener internet y una PC lo más rápido posible para participar.
Saludos gente, realmente extraño el foro.
Martín
-
Gente que no decaiga!
Cuando pueda pondre algun ejemplo paso a paso de utilizacion del RTOS LMOS.
Estamos viendo con reiniertl de realizar una documentacion amigable y ejemplos.
Saludos
Como siempre sus consultas son bien aceptadas.
-
Aquí estoy apoyando a Darukur con su LMOS, vamos a ver si ponemos un buen material a disposición de todos y además Darukur ya está valorando la posibilidad de migrar el código de su LMOS para el compilador CCS, y adiós al RTOS de CCS, que no es una maravilla.
Ahora, este material nos va a tomar algún tiempo hacerlo, porque tenemos pensado poner ejemplos prácticos y desarrollar algunas funciones específicas para RTOS.
Para los ejemplos tal vez lo lógico es que tomemos algunos proyectos desarollados en el foro y los llevemos a RTOS. En cuanto a las funciones la idea es hacer algunas funciones estándard de E/S alternativas a otras, como por ejemplo las de CCS que trabajan, casi todas por encuesta: printf(), getch(), entre otras. Así que también habrá trabajo para ustedes, ya que todo no podemos hacerlo Darukur y yo solitos.
La convocatoria está abierta
Saludos Reinier
-
Será un placer colaborar en lo que mi escaso tiempo y conocimientos me permitan.
-
Yo tambien intentare colaborar con lo que mis conocimientos me permitan.
-
Temas a definir:
Compilador: CCS quieren?
Microcontrolador base: PIC18F252?
Ejemplos: por perifericos, por aplicacion o por recursos del RTOS?
Saludos
-
No estaría mal CCS, porque es lo que casi todos utilizan en este foro, llegaríamos a más gente, y más también se beneficiarán de los RTOS. De todos modos que los foreros decidan, no vaya a ser que hagamos trabajo por gusto.
Con lo de microcontrolador base a que te refieres? Es para optimizar el RTOS o acaso para diseñar un .h que debamos incluir después en los proyectos. Si es para los .h me parece muy bien y podemos dejarle gran parte de ese trabajo a los voluntarios, que cada cual vaya haciendo el .h del PIC que más le guste o utilice. Pero para ello hay que hacer un conjunto de reglas, que la cosa no sea un desorden total. Respecto a esto pásame un mensaje privado.
Creo que lo mejor es que pongamos ejemplos sencillos de cada recurso, para mostrar como se utiliza (parecido al cursillo que llevo), este es un método muy didáctico, aunque los programs sean de poca o nunguna utilidad. Después un ejemplo más completo con una aplicación "útil" y por último agún proyecto más "serio", que podemos tomar del foro.
También hay que hacer funciones alternativas a las tradicionales, que no utilizan RTOS y buscar la forma de incluir el uso de interrupciones en esas funciones. Ese es un aspecto que debemos analizar. Porque si nos quedamos atendiendo todas las cosas por encuesta, el RTOS no podrá mostrar todo su poder.
Reinier
-
El micro a usar lo digo para que sea general a todos los ejemplos y que usemos siempre lo mismo para la configuracion de los perifericos del mismo.
PD:Ayer encontre una cosita en el RTOS LMOS relacionado a la funcionalidad de medicion de uso de micro por el scheluder combinado a una optimizacion del scheluder, perdia ticks para la contabiliacion de delays.
Si no usabas la optimizacion o el uso de medicion de uso de micro del scheluder no habia problema.
Aca subo la ultima version corregida.
-
Darukur, reiniertl...
Genial por su idea...y me sumo en lo que de mis posibilidades..... La verdad es un tema apasionante...en lo q respecta a RTOS soy nuevo...por lo q de pronto mis aportes seran excaso....pero con su ayudas y la de todos los del foro primero podre aprender para luego dar mis conocimiento...
Y para un futuro no muy lejano propongo un tema en el cual podre dar mi granito de arena...el cual es desarrollar el CANOpen el cual es un protocolo de Aplicación destinado al Bus CAN....aprovechando las facilidades q otorga el RTOS...
Desde ya mis mas sinceros deseos q sigan adelante....fuerzas muchachos!!
-
Temas a definir:
Compilador: CCS quieren?
Microcontrolador base: PIC18F252?
Ejemplos: por perifericos, por aplicacion o por recursos del RTOS?
Saludos
mi opinión es que empiecen con el CCS, no lo digo para crear dependencia de este compilador, pero por estos lares veo que se usa mucho, después mas adelante se podría usar con otros compiladores.
Salu2
Pedro
-
Ya me estoy instalando el CCS en mi maquina y probare que tal.
Por lo pronto CREO que deberia andar ya que el desarrollo no tiene cosas dependientes del compilador, solo usa unas directivas de assembler que andan tanto en C18/C30 y PICC/PIC18 y DSPICC.
Saludos.
PD: estoy realmente entusiasmado por su interes!!!
-
Vamos todavía con el LMOS!!! Creo que con el tiempo y con la ayuda del foro vamos a sacar una buena alternativa al SalvoRTOS. Espero que me pongan internet en casa y empiezo con las pruebas.
Estoy contento por el entusiasmo que hay en el tema.
Darukur, espero que una vez que esté todo listo sigamos con el reproductor de MP3.
Saludos.
-
Bueno, les comento.
Yo estoy usando el LMOS para un desarrollo en donde trabajo. Uso el PIC24 y el C30.
De desarrollar encontre el siguiente Issue.
Las variables generadas en estructuras de menos de 8 bits, deben utilizar la expresion "volatile" en su registro madre, por ejemplo:
struct {volatile unsigned int ACK:1,STATUS:3,DONE:1;
}MIRegistro;
Esto es porque el compilador C30 genera una copia local del registro (por ejemplo STATUS) por motivos de optimizacion y al hacer context switch dicha info no se actualiza o se corrompe si no se utiliza dicha directiva.
Obiamente para la utilizacion de variables locales a la tarea solamente, si se debe mantener el valor entre context switch, la variable debe ser static (esto es asi en cualquier RTOS).
Saludos
-
Estoy empezando el porting del RTOS para el CSS (uso la version 4.013), hasta el momento estoy renegando como un marrano!!
Por lo visto no es ANSI C ya que hay un monton de cosas que no las toma, por ej:
-asm("nop") : No lo tiene, solo el #ASM #ENDASM. Esto no es problema, ya que defino una macro para asm() y listo.
-Problemas con el manejo de estructuras.
-Problemas con el manejo de punteros a funcion.
-No tiene un include<pic18.h> general de manera de que detectando del MPLAB el dispositivo usado incluya el .h del dispo utilizado.
En fin, sigo en carrera. Cualquier novedad la reporto.
Salute
Hay mas! A menos que sea yo que no lo encuentre, no encuentro la posibilidad del uso directo de los registros porque ODIO usar esas funciones tipo CONFIG_TIMER(BAUD,etc) ya que FALLAN.
No encuentro por ejemplo como activar las interrupciones generales tipo "GIE=1". En fin ME NOT LIKE IT CCS :(
-
si Darukur, tendras que aprender la sintaxis del CCS y la forma en que organiza las configuraciones de los SFR. yo por ejemplo este fué el primer compilador de C con el que me topé, así que cierto dia me dispuse a probar el hitech y... estaba mas perdío que enano en procesión :(.. como te podras imaginar hay que dedicarle un tiempito a cada programa.
Salu2
Pedro
-
Si, con lo peor que me tope hasta ahora es:
¿Como hago para utilizar multiples archivos ".C" en el proyecto, de la manera en que se utiliza en Hitech PICC/PIC18DSPIC y Microchip C18/C30 o como en cualquier compilador ANSI?
Me encontre con cosas como "El CCS requiere que por cada .C haya un void main (void)" o que desde un ".C" se llame a los otros ".C".
Esto limita mucho las posibilidades de realizar desarrollos como el LMOS sobre CCS...
Asi que cualquier ayuda es bienvenida, si pueden pasar un proyecto completo en MPLAB+CCS que use multiples .C bienvenido!!
Marcelo
-
¿No te vale con hacer un "include" a los distintos .C?
-
Si anda todo es bienvenido, si podes adjuntar un ej lo miro.
Saludos
-
Pues lo dije demasiado rápido sin haberlo mirado, no vale un "include" al .C
Lo que yo hago en mi proyecto es agrupar las funciones en ficheros .H y dejar sólo un .C donde pongo los correspondientes "include" a los .H
A mí me funciona bien así.
-
Si antes realizaba eso pero no permite modularidad en el proyecto, ya que el .C almacena una porcion de codigo (componente) y el .H es la publicacion hacia afuera de dicho codigo (funciones, variables, definiciones y macros).
Trabajar con un solo .C complica a los compiladores en su tarea de la ubicacion optima del programa-datos en los bancos de memoria ROM del micro.
Intenten hacer un solo .C en compiladores de Hitech o Microchip y veran que no superan la capacidad de un solo banco (el 18F252 tiene 2 bancos de 8Kwords y con un solo .C llegas max a 50% de codigo que son 8Kwords)
Saludos
-
:-/! Que padre esta todo esto de verdad ¡ ,esta muy interesante esto del RTOS hace tiempo ya habia tenido contacto con el SALVO
pero no entendi nada asi que lo abandone pero en la practica te encuentras con muchos programas que no son tan simples de manejar de la manera "normal" , y ahora que se ve el gran potencial del "RTOS" gracias por compartir sus conocimientos con los que menos sabemos sobre ese tema ,ya estuve haciendo algunos ejemplos del ccs , y esto a todo dar,hice uno muy sencillo que enviaba datos por el serial ,escribia en la lcd,encendia dos leds en un puerto mientras sacaba un contador por el puerto b. usando un pic 16f877a a 20 mhz. gracias y sigan asi.
-
Zaphyrus acordate de pasarme la directiva de compilador para el C30 de manera de parchear el problema que tengo en la "optimizacion no deseada"
Salute y felicitaciones por tu adquisicion "interneteril".
Ahora no apagues mas la maquina, es mas hacete la pagina!
Marcelo
-
Darukur, no me acuerdo bien que era lo que precisabas sobre el C30 pero acá está la info para investigarla (la información es para el Atmel AVR pero de todas forma es el mismo compilador GCC):
La directiva __atribute__() con los atributos "signal" y "naked". Creo que necesitas usar el atributo "naked" para evitar que el compilador escriba código para la entrada o salida en la función o interrupción:
Signal:
The '__attribute__ ( ( signal ) )' directive on the function prototype informs the compiler that the function is an ISR and results in two important changes in the compiler output.
1. The 'signal' attribute ensures that every processor register that gets modified during the ISR is restored to its original value when the ISR exits. This is required as the compiler cannot make any assumptions as to when the interrupt will execute, and therefore cannot optimize which processor registers require saving and which don't.
2. The 'signal' attribute also forces a 'return from interrupt' instruction (RETI) to be used in place of the 'return' instruction (RET) that would otherwise be used. The AVR microcontroller disables interrupts upon entering an ISR and the RETI instruction is required to re-enable them on exiting.
Naked:
The 'naked' attribute prevents the compiler generating any function entry or exit code. Now compiling the code results in much simpler output
Enlaces:
Signal (http://www.freertos.org/implementation/a00012.html)
Naked (http://www.freertos.org/implementation/a00013.html)
Saludos.
-
Gracias tincho lo analizo
Marcelo
-
Q gran tema! :-/
Espero hablar de lo mismo puesto q ayer me tope con un ejemplo del RTOS que es este:
/////////////////////////////////////////////////////////////////////////
//// ex_rtos_demo_5_yield.C
//// This file demonstrates how to use the real time operating
//// rtos_yield function.
///////////////////////////////////////////////////////////////////
#include <18F452.h>
#use delay(clock=4000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#use rtos(timer=0,minor_cycle=100ms)
#task(rate=1000ms,max=100ms,queue=2)
void The_first_rtos_task ( );
#task(rate=500ms,max=100ms,queue=2)
void The_second_rtos_task ( );
void The_first_rtos_task ( ) {
int count=0;
// rtos_yield allows the user to break out of a task at a given point
// and return to the same ponit when the task comes back into context
while(TRUE){
count++;
rtos_msg_send(The_second_rtos_task,count);
rtos_yield ( );
}
}
void The_second_rtos_task ( ) {
if(rtos_msg_poll( ))
{
printf("count is : %i\n\r",rtos_msg_read ( ));
}
}
void main ( ) {
rtos_run();
}
Y bueno me intereso mucho el tipo de contador q hacia, siendo ya un segundero. El asunto es que intentando comprenderlo viendo cada ejemplo q trae el CCS y pues llege a hacer esto:
#include <18F452.h>
#use delay(clock=4000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#use rtos(timer=0,minor_cycle=100ms)
#task(rate=1000ms,max=100ms,queue=2)
void The_first_rtos_task ( );
void The_first_rtos_task ( )
{
long segundos=0,minutos=0,horas=0;
// rtos_yield allows the user to break out of a task at a given point
// and return to the same ponit when the task comes back into context
while(TRUE)
{
if(segundos>=59)
{segundos=0;
if(minutos>=59)
{minutos=0;horas++;}
else
{minutos++;}
}
else
{segundos++;}
rtos_yield();
printf("%lu:%lu:%lu\n\r",horas,minutos,segundos);
}
}
void main ( )
{
rtos_run();
}
Esto mantiene las horas, minutos, segundos. Aqui lo escencial es el rtos_yield() q produce los retardos pero nose a base de que.
Quisiera saber si es estamos hablando de lo mismo en lo que es el RTOS porque recien ayer me e involucrado con esto. Y dejando la PC prendida toda la noche comprove q se retraso unos 4 segundos (quiza haya sido culpa del reloj con q probe, no estoy seguro), ahora estoy probando con el de la PC y esta todo bien por ahora.
Que fabuloso tema, justo andaba buscando algo parecid a esto. Espero aprender mucho del RTOS yaq se ve muy interesante.
salu2 8) 8) 8)
-
Vamos por partes, como Jack
Lo primero, la idea de usar un RTOS es que te ahorres el tener que comprender cómo es que está hecho, más bien debes preocuparte por aprender bien cómo utilizarlo. Para ello visita mi hilo "Sistemas Operativo en PIC". Allí encontrarás unas cuantas respuestas a tus dudas.
Lo segundo, un RTOS, no es la mejor variante para implementar un reloj preciso, para ello es mejor que combines tu programa, que te ha quedado bien, con algún reloj serio, como los relojes calenadrios DSxxx que, ya por estos lares han explicado muy bien.
Mezclando ambas cosas tendrás dos cosas buenas: La precisión que aporte el RTC y el uso eficiente de tu PIC al emplear el RTOS.
Un saludo Reinier
-
Si e escuchado hablar de los DSxxx, es mas, ya e pedido algunos q ya deben estar por llegar. Lo q sucede esq quisiera hacer este "reloj" sin usar los DSxxx; e probado con delay_ms y fue un desastre, y creo q el RTOS se acerca a ello solo que hay que echarle mas ganas pues es un avance lo q llevo echo.
Nose si el programa q hice estara bien puesto que se a retrasado 1 segundo (sin seguridad) yaq modifique mucho el codigo. Haber si alguien le echa una ojeada. :D Vamos q recien me entero ayer en la noche sobre la existencia del RTOS :-)
salu2 8) 8) 8)
-
La exactitud de los retardos o relojes que implementes con un microcontrolador dependen mucho de las rutinas de interrupción que atienden dicho servicio.
Aunque uses un delay de RTOS o inclusive un Real time clock (movido por tu timer), si tu rutina de interrupcion de timer no se atiende en tiempo y forma, se produciran errores acumulativos.
Yo lo que hago, aunque ajuste segun las relaciones del timer, es realizar pequeñas correcciones por intervalos de tiempo.
Por ej: Si se que el reloj adelanta 10uS cada 1 segundo, lo que hago es agregar dicha correcion por cada segundo.
Esto sirve solo si el error es solo dependiente de la misma interrupcion de reloj, si tu micro no tiene suficiente tiempo para atender las diferentes interrupciones el error no se podra corregir por su naturaleza asincrona.
En microcontroladores como los DSPIC y PIC los relojes son mucho mas faciles de configurar y mas precisos ya que manejan mas opciones en sus PRE y POST SCALERS. Directamente configuras cada cuantos clocks queres que interrumpa.
Saludos
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();}
-
Bien, si quieres hacerlo sólo con RTOS, digamos que para aprender está muy bien, pero te advierto que la idea del RTOS no es la mejor opción para eso porque hay muchas cosas que atentan contra la precisión.
La más simple es que el RTOS de CCS es cooperativo, así que si por ejemplo tienes una tarea que cuenta, digamos decenas de segundos, debe ser atendida cada 10ms, bien. Pero que pasa si una tarea que escribe una trama por el puerto serie demora 11 ms en hacer su trabajo, nada que tendrás un error metido por esa tarea.
Por eso una buena opción es tener un RTC independiente del programa, un RTC hw, al que consultas la hora cada vez que lo necesitas, si tu programa se cuelga y el WD reinicia al uC, no hay problemas porque la hora está en un dispositivo externo, si no puedes consultarlo debidamente, tampoco hay problemas. Esa es la mejor opción para tener precisión.
Si quieres aprender a utilizar RTOS, es muy bueno hacer un reloj. De hecho es una de las mejores aplicaciones que puedes utilizar para llevarlo a cabo. Pero como consejo, te digo que no es una buena opción para hacer una aplicación que deba ser precisa y segura, debes ser muy cuidadoso con eso porque las cosas pueden no salirte bien.
Un saludo Reinier
-
Si entiendo, ya van 4 horas q e dejado prendido la pc conectada por rs232 y se a retrasado 2 segundos. :x
Creo q no me queda de otra mas q usar los DSxxx. :?
Porcierto nadie sabra como modificar ese codigo q puse para q sea exacto ??? Esq eso de quitarle cada segundo 10us o algo asi nose cmo hacerlo. Haber si alguien le da una ojeadita :-)
salu2 8) 8) 8) 8)
-
Tu codigo no lo vi pero puedo brindarte un ejemplo de correcion del timer mio en un proyecto.
Esta es la macro de atencion de interrupciones del timer
#define R_TIMER_0_REFRESH()\//Esta Macro se llama desde una sola area de código.
{if (TMR0IE&&TMR0IF)\
{TMR0=R_TMR0_C_1;\
if (++R_TIMER_VAR.LAP_MS_CNT>=R_TIMER_V_LAP_CORRECT_MAX)\
{TMR0=R_TMR0_C_2;R_TIMER_VAR.LAP_MS_CNT=0;}\// correccion de tiempo
if (R_TIMER_VAR.LAP_10_MS++==R_TIMER_V_LAP_10MS_MAX)\// Evento cada 10 mS
{OSTimer();R_TIMER_VAR.LAP_10_MS=0;\// Llamo al Tick de sistema
}\
TMR0IF=0;\
}\
}
Despues trabajas sobre las variables de ajuste:
//Constantes
#define R_TMR0_C_1 0xDA //D8:atrasa D9:atrasa DA:adelanta
#define R_TMR0_C_2 0xD9 //DA:adelanta D9:
//
#define R_TIMER_V_LAP_10MS_MAX 4
#define R_TIMER_V_LAP_CORRECT_MAX 3 //2:atrasa 3:atrasa 4:adelanta 8:adelanta
Como veras cuando haces los calculos de tu reloj siempre tenes un pequeño error acumulativo dependiente de tus opciones de cristal prescaler postcaler, valores de recarga de timer, etc.
Cuando empezas a trabajar con los valores ves por ej que si corres el valor de recarga del timer llega un punto que un valor arriba adelanta y un valor abajo retrasa.
Te quedas con la opcion que menos error produce y trabajas sobre las correcciones mas finas agregando o restando un fino dependiendo el caso.
Te comento que no sera lo mejor pero por ejemplo tengo un reloj en el auto hecho con un PIC 16F818 y lleva casi 2 años y no se ha corrido mas de lo que se me corre mi reloj de muñeca, ya llega un punto que juega el error del cristal.
Saludos
PD: Si queres precision podes optar por un RTC o incluso usar un timer del PIC dedicado con un XTAL de 32Khz externo.
-
Ey muchas gracias, aunq la verdad no lo entiendo muy bien. Aun asi lo tendre muy encuenta, enserio, se agradece. :-/
salu2 8) 8) 8)
-
Muy buen trabajo Darukur, me gustaría si puedes subir algún ejemplo para ver si lo puedo entender mejor...
Saludos
-
Hola, el thread mas actual de este tema (que esta bastante descontinuado) esta en sistemasembebidos (http://sistemasembebidos.com.ar/foro/index.php?topic=169.0).
Lo que si creo que en el mismo archivo comprimido hay un ejemplo sino lo vemos y publicamos.
Un saludo
-
Me fije y no tiene, pero aca (http://www.sistemasembebidos.com.ar/oldfmt/Contenido/LMOS_EXAMPLE_2_PICC18.ZIP) hay un ejemplo para PICC18.
Esta desactualizado seguramente porque no lo continue.