Realizar acciones paralelas en un pic

No precisamente... pero de que programa hablamos? del control de hilos o del programa que te interesa hacer compartido.

de cual programa hablas? del que quieres hacer o del que va a controlar los tiempos entre programas o hilos.

El assembler no es complicado. Simplemente, que C te evita escribir mas codigo.
Cada uno tiene sus bondades y sus limitantes. Todo depende.
 
Última edición:
gracias amigos ahora estoy un poco mas tranquilo.. eclipse al ver el codigo que pusiste me doy cuenta que debo si o si aprender c en algun momento...

Sera muy complicado que la cuenta que realice se visualice en unos displays por ejemplo? creo que no, solo habra que tener cuidado con el tiempo que toman las instrucciones para visualizar en los displays cierto??
Lo mejor es usar C18, para que hagas proyectos de verdad, y puedas usar los programas con otros compiladores.

Tambien.......

No entiendo por que mencionan algoritmos, otros micros. Si sammaael lo único que quiere es leer un teclado y mostrar los datos. Cosas básicas.

Además hilos o thread por lo general se habla en lenguajes de programación que se ejecutan en sistemas operativos, y aquí en este tema de este blog se pregunta algo elemental.

No confundir con cosas que no vienen al tema.
 
Última edición:
Precisamente lo que samael pregunto en un inicio, es ejecutar dos tareas simultaneas... a eso se le llaman hilos. Si solo tienes un nucleo, entonces requieres hilos. Nadie ha metido cosas fuera de tema.
 
Quisiera saber si es posible ( y de ser asi como hacerlo) realizar dos instrucciones o acciones en forma paralela en un pic cualquiera sea este. Por ejemplo mientras se escanea un teclado, paralelamente a esto, el pic realice otras tareas como puede ser controlar leds o displays.
Gracias Saludos amigos
En la pregunta hay algunas cosas importantes, teclado, display y lo mas importante PIC.

Con respecto a lo del C18, es un compilador que te permite escribir los programas en C a demas que permite insertar lineas de codigo en assembler. Y permite generar un codigo optimizado es decir que tu archivo .hex va ha tener un menor tamaño al generado por otros compiladores. Aparte que usando este compilador podras migrar facilmente tu programa a otros compiladores como el C30 o GCC, que son compiladores para escribir codigo para dsPIC y AVRs.
 
No tengo un tutorial... simplemente un dia se me ocurrio la idea e hice el administradorsillo de hilos.
Es muy simple, pero hay que tener practica con el stack.
 
si te pegaas una de "esas" explicaciones y ayudas a todos los neofitos en esto de los pic seria bueno sino cuando tengas tiempo de suguro lo haces de todas formmas gracias
 
Hace un tiempo hice un kernel multi-tasking para ejecutarse sobre MS-DOS, en realidad no es tan dificil, solo que como comenta antiworldx se necesita práctica con el stack para realizar la rutina de cambio de contexto.

El kernel esta escrito un 90% en lenguaje C, por lo tanto puede ser portado a diferentes arquitecturas con relativa facilidad. La unica parte dificil de portar es la ya mencionada rutina de cambio de contexto... ya que depende mucho del lenguaje ASM y de la arquitectura destino...
 
Contexto se refiere, a que cada aplicacion use sus registros y pila como si solo tuviera el microcontrolador para el solo.

Te platico que no es algo simple, vas a tener que ponerte a leer un buen rato y no te desesperes.
 
Efectivamente... cuando el PIC atiende una interrupcion no detiene la ejecucion de los otros modulos... a menos que se lo ordenes....
al aplicar una interupcion se detiene automaticamente lo que esta asiendo guardando la direccion actual y dirigiendose a la posicion 04 de la memoria, una vez que vuelve de la interupcion continua con la rutina principal, 1 ms no es mucha velocidad,mira si el pic trabaja con un cristal de 4 Mhz, cada instruccion se demora 1us. puedes ejecutar 999 lineas de comando y luego scanear por decirte un ejemplo basico puedes escanear 10 perifericos y si uno se activa puedes dar para realizar alguna rutina 100 instrucciones y todavia la velocidad de scaneo por cada periferico es menor a 1 ms.

explica lo que haces y te ayudamos para tener una mejor idea.
y en assembler queda perfecto.

leyendo mas tu explicacion, si quieres controlar un teclado y unos led no necesitas para nada hacer rutinas en paralelo, la frecuencia es muy poca, para tu caso poner una instruccion bajo la otra para efectos practicos de lo que tu quieres realizar, tu veras los resultados en forma simultanea. a menos que seas capaz de pulsar en un segundo un millon de veces un boton o ser capaz de ver un millon de cosas en un segundo, y si aun asi eres capaz utiliza un crystal de 20 Mhz, y tienes 0.2 us por cada instruccion .
 
Última edición:
Además hilos o thread por lo general se habla en lenguajes de programación que se ejecutan en sistemas operativos, y aquí en este tema de este blog se pregunta algo elemental.
No confundir con cosas que no vienen al tema.

Creo que vas a tener que revisar un poco la tecnología actual, por que el RTOS del CCS ejecuta una suerte de hilos (solo que los llama Tasks) sobre cualquier PIC, con arraque y duración perfectamente definidos y sin tener que pelear con el stack ni con nada...solo con el problema que debe solucionar.

Y nadie confunde con nada...excepto quizás vos. La tecnología de procesamiento concurrente es exactamente la misma en un micro poderoso o en un microcontrolador, con o sin MMU...así que el concepto es COMPLETAMENTE APLICABLE...y más aún si ni siquiera tenés que pensar vos el código de task scheduling...
 
Maestro obi wan... ilustrame! (es en serio)

Puedes explicar un poco mas ese asunto con los pics por favor? Yo hice mi propio administrador de tareas para AVR´s que es una plantilla donde estan definidos servicios y cosas que uso. Pero al parecer esto ya es un compilador ya hecho para hacerlo por si solo. Entiendo bien?
 
Maestro obi wan... ilustrame! (es en serio)

:eek: :eek: :eek:

Puedes explicar un poco mas ese asunto con los pics por favor? Yo hice mi propio administrador de tareas para AVR´s que es una plantilla donde estan definidos servicios y cosas que uso. Pero al parecer esto ya es un compilador ya hecho para hacerlo por si solo. Entiendo bien?

El compilador CCS para el lenguaje C, entre las varias cosas que ofrece, trae la posibilidad de estructurar el código en tareas, que no son mas que funciones sin parámetros y que no retornan nada (void), así que vos estructurás tus programa en tareas separadas usando este tipo de declaarciones y precedés a cada una con una directiva #task con algunos parámetros que definen cada cuanto tiempo se ejecutan, cuanto es la maxima duración que puede permitírsele tener y con cual timer se controla la ejecución.

Luego tenés que preceder el main() con una directiva #use rtos que le indica al compilador que debe incluir el código de un micro sistema operativo de tiempo real que incluye el dispatcher que se encarga de ejecutar las tasks bajo los parámetros especificados.

La ventaja de este método es que no tenés que luchar con las interrupciones ni nada. Solo especificás los parámetros de ejecución temporal en la directiva #task y ya estás hecho: el RTOS las ejecuta por vos.

El único problema es que el scheduler no es preemptivo, sino cooperativo y un mal diseño de una tarea puede palmar la ejecución del scheduler...pero esta cosas se arreglan fácilmente.

Donde trabajo se está usando esta técnica para gestionar la ejecución de controladores PID para control de motores eléctricos, mas la comunicaciones en bus CAN, mas la odometría y lectura de los GPS en un cuatriciclo automatizado, mas otra parva de cosas enlazando como 8 PICs...y anda sin ningún problema....aunque a veces hay que usar interrupciones cuando esto no dá para más...
 
Última edición:
O sea, que el CCS incluye un RTOS ya escrito? "No te acostarás sin saber una cosa más".

Yo también hice un RTOS para AVR (Mega128 con GCC y portado a Mega1281 con IAR), y las rutinas más importantes las escribí en ensamblador, no en C. Me basé en el fantástico documento explicado anteriormente. Muy muy instructivo y altamente recomendable como ejercicio a los programadores más avanzados.

Una vez tiener el kernel del RTOS y algo de práctica en usarlo, la cosa se vuelve mucho más fácil de programar, pero hace falta RAM, y a ser posible, más parámetros de control (tick de sistema, prioridades, espacio de pilas - stack, etc).

De hecho, una de las 'ventajas' de los AVR se convierte en desventaja cuando se usa un RTOS, y es que salvar 32 registros acumuladores hace que el tiempo de conmutación de tarea sea largo. Claro que el hecho de tener la pila en HW en lugar de RAM tampoco simplifica mucho las cosas que digamos.

Por cierto, un dispatcher no es un sistema operativo ni tiene porqué usarse en tal. De hecho, los dispatchers se usan bastante para programas que no necesitan mucha velocidad de reacción ni multitarea para sustituir a los (más pesados) sistemas operativos ya que son más sencillos y necesitan menos recursos.

Por cierto, hay varios tipos de sistemas operativos para microcontroladores, cuya principal y única misión es facilitar la multitarea: los cooperativos y los preventivos. Los primeros son más ligeros y necesitan menos stack, pero no son realmente tiempo real, y necesitan la cooperación del programador, a cambio, se pueden usar más facilmente en micros 'pequeños'. Los preventivos son más complejos y necesitan más recursos, pero son más seguros. Por eso se usan en los sistemas de automoción, y son la principal baza de los ARM, pues éstos están muy pensados para ser usados con RTOSes, tal y como se puede deducir de su arquitectura interna, especialmente de los Cortex M3.
 
O sea, que el CCS incluye un RTOS ya escrito? "No te acostarás sin saber una cosa más".

Así es...ya viene listo y el compilador se encarga de armar todo para preparar la ejecución del dispatcher con la función rtos_run().
Hay muchas funciones adicionales que te permiten comunicar las tareas mediante mensajes, liberar el control al scheduler con un yield(), habilitar y deshabilitar tareas para su ejecución, etc, etc...en fin, todo el soporte necesario para multitarea...cooperativo pero multitarea al fin....y sin transpirar nada ;)
 
¿Lleva también ventanas de control de estado de tareas, traza, control de gasto de pila, etc. al estilo PowerPAC de IAR? Interesante cuando menos.

No tiene tanto....pero puede llevar algunas estadísticas de ejecución. Te paso lo que dice el help:
Help CCS dijo:
Syntax:
#use rtos (options)

Elements:
options are separated by comma and may be:
timer=X
Where x is 0-4 specifying the timer used by the RTOS.
minor_cycle=time
Where time is a number followed by s, ms, us, ns. This is the longest time any task will run. Each task's execution rate must be a multiple of this time. The compiler can calculate this if it is not specified.
statistics
Maintain min, max, and total time used by each task.

Purpose:
This directive tells the compiler which timer on the PIC to use for
monitoring and when to grant control to a task. Changes to the specified timer's prescaler will effect the rate at which tasks are executed.

This directive can also be used to specify the longest time that a task will ever take to execute with the minor_cycle option. This simply forces all task execution rates to be a multiple of the minor_cycle before the project will compile successfully. If the this option is not specified the
compiler will use a minor_cycle value that is the smallest possible
factor of the execution rates of the RTOS tasks.

If the statistics option is specified then the compiler will keep track of
the minimum processor time taken by one execution of each task, the maximum processor time taken by one execution of each task, and the total processor time used by each task.
 
Por cierto, hay varios tipos de sistemas operativos para microcontroladores, cuya principal y única misión es facilitar la multitarea: los cooperativos y los preventivos. Los primeros son más ligeros y necesitan menos stack, pero no son realmente tiempo real, y necesitan la cooperación del programador, a cambio, se pueden usar más facilmente en micros 'pequeños'. Los preventivos son más complejos y necesitan más recursos, pero son más seguros. Por eso se usan en los sistemas de automoción, y son la principal baza de los ARM, pues éstos están muy pensados para ser usados con RTOSes, tal y como se puede deducir de su arquitectura interna, especialmente de los Cortex M3.

No me parece la traducción mas de preemptive a preventivos ... tal vez pudiese quedar mucho mejor : prioritarios... aunque también la he escuchado traducida como expulsivos..
 
Atrás
Arriba