Saludos Reinertl,
Te felicito una vez mas por la exelente introducción que estas brindando a cerca de los RTOS.
Quiesiera que me aclares una duda referente al ejemplo q has mostrado en la sección de Insertar Cita
¡Interrupciones! ¡A MÍ!
Tengo entendido q utilizas 2 Pic 16F877 los cuales estan interconectados a traves de su respectiva interfaz serial (USART). Hasta ahi me queda todo claro...lo q no logro entender es si el 2do. Pic q hace de receptor de la cadena del otro y luego lo retransmite...hacia donde...? Es hacia el primero...? Puesto q el Pic solo posee una interfaz fisica ( el primer pic no posee una rutina para la recepcion, aunque entiendo q no habra colision simplemente la cadena retransmitida no tendrá un receptor.. )....la cual esta configuarada al principio....(directiva #use rs232(...)). Si quisieramos debugear en Hardware seria mas interesante retransmitirlo hacia la PC...obviamente a traves de otro puerto USART simulado por soft.
Desde ya gracias..y que siogas adelante, ya que el curso se esta volviendo cada vez mas interesante
Es que realmente se ejecuta cada 2 mseg!!No MGLSOFT, los 1.7ms son entre flancos ascendentes, ya tiene en cuenta los 300us :mrgreen:
1,7 mseg mas los 0,3 mseg dan los dos mseg que buscas!!! :mrgreen: :mrgreen:
¿Ese delay_us dentro de un RTOS no es un poco raro?. Desde la más profunda ignorancia, quizás si pones dos tareas, una que encienda el led y otra que lo apague...Del ejemplo donde provino la duda no tiene delays, son solo instrucciones y ocurre el mismo problema. :? Es que esto me desoriento! He visto ejemplos de RTOS en la ejecución de un control PID por ejemplo, donde la frecuencia de muestreo es critica, y no puede ser que varíe tanto! Para mi soy yo que estoy fallando en algo, sigo leyendo a ver que encuentro.
#task(rate=400ms,max=50ms)con un minor_cycle=50ms la función la llama en 350ms y con un minor_cycle=100 la función la llama a los 300ms :shock: para los 400ms siempre se completan. tenés razón suky no se cumplen los tiempos, en mi caso es peor porque trabajaba con funciones de tiempo mayores y se adelanta unos 50 ms. Hasta ahora no me había dado cuenta y estuve buscando alguna explicación y no encontré nada...Yo estaba en la misma tratando de encontrar alguna regla o como diablos establece los tiempos, modificaba minor_cycle, rate y el max, pero no le había encontrado explicación! También pensé que era el proteus que me estaba jugando una mala pasada, pero fijando un tiempo exacto en la tarea me di cuenta que eso no era! Al final parece que es problema de CCS! Voy a practicar algunas cositas mas y me cambio a otro RTOS :5]
Pero me puse el poncho detectivesco y descubrí que el rate se cumple pero lo que hace el RTOS es llamar a la función en rate-minor_cycle por ejemploCódigo: [Seleccionar]#task(rate=400ms,max=50ms)con un minor_cycle=50ms la función la llama en 350ms y con un minor_cycle=100 la función la llama a los 300ms :shock: para los 400ms siempre se completan.
Esto lo probe cargando el .cof y simulando paso a paso.
Ahora supuestamente en tu caso el retraso es de 0.3 [ms] yo esperaría que fuese de 1 [ms], pero le cambie el clock al micro(procesor clock frecuency) a 40 Mhz (un bolazoooo) y se cumplió la regla :x. No se que decirte, si lo que dije fue pura coincidencia o si el rtos del ccs trabaja así o el proteus nos está jugando una pasada. La cuestión es que estoy más perdido que "un piojo en la oreja" con este RTOS, encima tengo más preguntas sobre el ejercicio 3 y 4 :z)...
Creo que somos malos estudiantes :) (espero que el profe reiniertl no nos regañe) será mas saludable una vez terminado todos los ejercicios pasarse a algún otro RTOS. :5]
Saludos!
A ver si me eplico un poco con utede, poque eto que me enseñan me deja como indio que no etiende.:shock:
Yo nunca he tenido ese tipo de problemas, la razón no la se, quizá nunca me he preocupado demasiado de eso, cuando necesito temporizacoines precisas, combino el RTOS con TIMER, típicamente el TIMER1 + CCP y pongo en la ISR las cosas que no pueden depender de que al RTOS le de la gana de planificarme una tarea demasiado jodedora con los tiempos.
Pero si yo fuese ustedes ponía un minor_cycle 10 veces menor que el rate de la tarea más rápida, así me evito el jodido problema del aliasing, pero esta vez aplicado a la ejecución de las tareas.
Cambiarse de RTOS es buena idea, el FreeRTOS tiene soporte para PICs, pero es un poco más jodido de trabajar que el de CCS y se necesita del compilador de Microchip para programar con él.El lenguaje no seria problema, yo manejo C18 y además pasar de un C al otro no es tan complicado. Pero donde podremos conseguir material tal como has hecho tu con el de CCS. A mi me fue muy útil para entender este tema.
Please note that the segmented memory on the PIC18 makes it a less than ideal candidate for use with an RTOS.Vamo' a tener que romper la alcancía y comprar algo de la gama alta :mrgreen:.
Hola compañeros! Yo también estoy entusiasmado en aprender RTOS, comencé con el de CCS. Pero tengo una duda existencial :mrgreen: Yo declaro una tarea que se tiene que ejecutar cada 2ms por ejemplo:Código: CEs la única tarea, la cual solo enciende un led y lo apaga durante 300us. Ahora como es la única yo pensé que se tenia que ejecutar exactamente cada 2ms, pero simulándolo en proteus veo que el pulso de 300us es exacto y la tarea se ejecuta cada 1.7ms :?
Adjunto el código completo para ver si estoy declarando algo mal.
Esta duda surgió al realizar un cartel de leds (http://www.todopic.com.ar/foros/index.php?topic=25723.msg216626#msg216626) como primer ejercicio (maté 2 pájaros de un tiro, también es mi primer cartel). Logre sincronizar de manera correcta las tareas para realizar el refresco y también para provocar cambios en el mensaje sin que ocurran distorsiones, pero después se me dio por controlar lo tiempos de ejecución y ahí fue que me encontré con este problema :?
Muchas gracias!
Reiniertl, q RTOS preferis vos? Yo he sentido muy buenos comentarios de freeRTOS, pero cuando me dispuse a aprender, me parecio muy complicado :?Es para C de Microchip, y es conveniente usar el PIC de alta gamma, con un 18F es limitado por lo que he leído.
Ademas q es para c18 cierto? yo solo uso CCS... creo q es hora de migrar jeje
saludos!
Realice esta misma pregunta en el foro de CCS, en donde me dieron un link donde tenían los mismos problemas: RTOS tasks execution rates (http://www.ccsinfo.com/forum/viewtopic.php?t=29772)
Resulta ser un bug del compilador: :z)
- Para 4MHz y 8MHz funciona correctamente
- Para 15MHz el compilador calcula el rate de las tareas para 20MHz
- Para 20MHz funciona bien
- Para 32MHz el compilador calcula el rate de las tareas para 40MHz
- Para 40MHz funciona bien
- Para 48MHz el compilador calcula el rate de las tareas para 40MHz
:5]
El libro debe estar mal porque la cosa funciona de la siguiente manera:
Este RTOS no es una maravilla de RTOS, así que te impone restricciones en cuanto a lo que puede hacer una tarea:
Una tarea debe entrar en contexto de ejecución a frecuencia constante. Esto quiere decir que no puede ejecutarse ahora y luego dentro de 5ms, y después a los 20ms (hay RTOSes que permiten cosas como esta). El RTOS de CCS impone que la tarea se ejecute a período constante. Este es el valor de "rate" de tu tarea.
Pero las desgracias no acaban allí, esta restricción se transfiere a todo el sistema, así que también se impone que el RTOS debe tener un período mínimo que vendrá siendo como el tic del reloj del sistema. Esta técnica no es rara, muchos sistemas operativas imponen al programador declarar el tic del sistema. Que viene siendo algo así como que un pic de la familia de los 16 tiene un período de ejecución por instrucción de 1/4 del reloj del sistema.
Entonces, el parámetro que se declara como tic, del RTOS es "minor_cycle" y es por eso que las tareas podrán tener rates en valores enteros iguales al "minor_cycle" o en intervalos múltiplos enteros positivos de ese valor. Visto con un ejemplo:
Supongamos que declaramos un "minor_cycle" de 10ms; entonces podremos tener tareas con rates de 10ms, 20ms, 30ms....n*10ms.
El valor de "max" solamente sirve para decirle al RTOS cuanto es el tiempo máximo que esperamos debe consumir la tarea para ejecutarse, de este modo se pueden llevar las estadísticas de la tarea y saber si realmente la tarea consume menos o más tiempo del que se ha estimado. Este valor debe ser menos que el "minor_cycle", ya que se supone que otras tareas podrían necesitar el procesdor en cualquier valor múltiplo del "minor_cycle".
Saludos
Reinier
Entiendo perfectamente lo del rate. Pero justamente mi mayor problema es entender bien la definición de minor_cycle.
Si el rate tiene que ser igual o múltiplo de minor_cycle -que es lógico porque no puedo pretender ejecutar una tarea cada 20ms y que dicha tarea me lleve 30ms- entonces minor_cycle me está diciendo que ese es el tiempo máximo que me puede consumir la tarea y no el tiempo mínimo.
Perdón por mi dureza para entender.
Tengo una consulta con el FReeRTOS. En su pagina para los PIC18 dice: Please note that the segmented memory on the PIC18 makes it a less than ideal candidate for use with an RTOS.Hola jeremylf, el problema en si es la arquitectura del micro y del compilador, no de un micro especifico de la linea PIC18.
Esto lo dicen porque usan un 18F452 para la demo ?? Pues, ahora hay pic18 con mas rom y ram. Talves para estos PICs con mayor capacidad ese comentario ya no se aplique. O no tiene nada que ver?
Gracias
Otro tema, la demo de FreeRTOS con PIC18 es solo a fines de ejemplo, no vas a poder hacer realmente nada util con eso, de seguro te encontrarias en poco tiempo con algun funcionamiento erratico dificil de detectar.
Por lo que comentas, debo entender a que no podré hacer mucho con un PIC18 con esta FreeRTOS?