Retardos paralelos a ejecución del programa

Hola,

Me gustaría saber si existe forma de programar retardos, pero que dichos retardos no paren la ejecución del programa (como sucede con los retardos que se valen del ciclo de instrucción) sino que solo avise cuando se ha cumplido el tiempo preestablecido, como una interrupción.

Esto lo busco más que nada, por que deseo estar leyendo un canal del conversor AD constantemente (lo cual me quita tiempo) pero por otro lado deseo estar mandando pulsos por 4 salidas del puerto b con cierta frecuencia. Y no se me ocurre como hacer que convivan ambas tareas en un solo PIC.

Estoy con el PIC16f877 a 20 Mhz

Saludos,
 
hola alejandro,

no se si le sirva esta respuesta y si estoy mal que alguien me lo diga, pero, por que no intenta con alguno de los timers?, estos van contando sin necesidad de usar tu programa, y pues, ellos generan interrupciones, solo es cuestion de configurar los prescalers y postcalers (timer2) para la frecuencia deseada, y sacrificaria unos cuantos microsegundos mientras manda los pulsos, y vuelves de la interrupcion al principal para sguir leyendo el canal analoo, eso es lo que se me ocurre a mi, no se si le sea util o ya lo habia pensado, cuidese...
 
Hola,

De hecho no había pensado en los timers, y si, por supuesto que me es de mucha utilidad la idea, la única vez que use el timer fue para poner el PWM, y nunca más, de modo que no tengo al momento claras nociones de cómo usarlos correctamente.

Me pongo a estudiar el tema, no obstante si saben de alguna guía para el uso de los timers me vendría muy bien.

Saludos leo_programer, ELCHAVO.
 
Timer + interrupcion es la solucion (en verso, jaja!!). Yo no programo PIC´s pero supongo que en esto sera igual a cualquier micro. Deberias setear el timer con el tiempo que necesitas y habilitar la interrupcion por dicho timer, al producir el overflow el hilo de ejecucion se pasa a la rutina de servicio de la INT.

saludos
 
No tiene TMR0 ? el 877?, usar la interrupcion por desborde de un timer es lo mejor y mas sencillo. Es muy util, ya que si temporiza, tambien cuenta!!!.

Saludos
 
alejandro_oo ese pic tiene muchas opciones que al parecer no estás usando.

Si quieres, puedes usar el módulo CCP que dispara al A/D una vez terminada la comparación y lo hace una y otra vez. Se utiliza para hacer conversiones periódicas del A/D.

Le habilitas la interrupción y cada X microsegundos tendrás posibilidad de volver a disparar el A/D.



Saludos
 
Mamu, maunix, hola. Pues si, me veo con que este PIC tiene multitud de funciones extra, que me pueden venir muy bien. Eso que mencionas me suena muy interesante, o sea que más bien la conversión AD puede quedarme paralela a la ejecución mediante interrupciones ¿?

Ahora la conversión AD la estoy haciendo al hilo del programa. Pero puede eso que mencionas programarse también C, ahora que lo estoy practicando ¿?.

Saludos,
 
alejandro_oo dijo:
Mamu, maunix, hola. Pues si, me veo con que este PIC tiene multitud de funciones extra, que me pueden venir muy bien. Eso que mencionas me suena muy interesante, o sea que más bien la conversión AD puede quedarme paralela a la ejecución mediante interrupciones ¿?
Si


alejandro_oo dijo:
Ahora la conversión AD la estoy haciendo al hilo del programa. Pero puede eso que mencionas programarse también C, ahora que lo estoy practicando ¿?.

Por supuesto, es una característica del PIC no del compilador o del ensamblador. Tu lenguaje cualquiera sea debiera ser posibilitarte programar los módulos del PIC, sino no le veo el sentido a usar un compilador :)

Saludos
 
Claro maunix, sabes lo preguntaba más que otra cosa por que he sabido –de oídas- que el CCS y en general los compiladores C para PIC, no siempre puede uno desarrollar todo el repertorio de funcionalidades del PIC. Digo que para esto uno puede hacer uso de trozos ASM donde sea necesario, pero en si por eso era mi duda.

Saludos y gracias :D
 
alejandro_oo dijo:
Claro maunix, sabes lo preguntaba más que otra cosa por que he sabido –de oídas- que el CCS y en general los compiladores C para PIC, no siempre puede uno desarrollar todo el repertorio de funcionalidades del PIC. Digo que para esto uno puede hacer uso de trozos ASM donde sea necesario, pero en si por eso era mi duda.

Saludos y gracias :D

A veces los compiladores no generan el código más óptimo pero eso de que no pueden desarrollar todo el repertorio de funcionalidades de un pic... mmm, no es cierto en lo absoluto.

Me gustaría que dieras un ejemplo donde te hayan dicho que eso es así para analizarlo en tal caso.

Al usar un compilador uno pierde control sobre ciertas cosas y debe ser así , sino para qué tener un compilador. Referido a perder el control, hablo de que por ejemplo algunos direccionamientos indirectos y/o registros no se pueden usar porque entrarían en conflicto con el funcionamiento del compilador en sí. De todas formas los módulos y puertos del pic se pueden usar perfectamente.

Saludos
 
maunix dijo:
A veces los compiladores no generan el código más óptimo pero eso de que no pueden desarrollar todo el repertorio de funcionalidades de un pic... mmm, no es cierto en lo absoluto.

Te agradezco que me dejes eso en claro. Eso tambien habia leido que el codigo generado en C es mucho mas lento que el ASM. Supongo que esto se debe a que en el ASM uno mismo va poniendo cada cosa en su lugar optimizado y en C el mismo compilador nos aleja de esa parte para ahorrar trabajo, como un "front", si no -como dices- de que cosa serviria tenerlo.

maunix dijo:
Me gustaría que dieras un ejemplo donde te hayan dicho que eso es así para analizarlo en tal caso.

Que bueno que me pides eso, mira hace como un año (o menos), lei en una revista de temas de electronica (y otras cosas), que habia un IDE que te permitia programar los PICs en un lenguaje mucho mas amigable y digerible que el ASM, sobre todo para quienes tenemos mas experiencia con el tema de la programacion en general que con los PICs en si, en este caso se trataba del basic.

Pues bien, para no hacerla larga, me puse a investigar al respecto con personas cercanas al tema y ellos me comentaron del compilador C para PIC, y junto con eso me dijeron que aun con aquel compilador uno no se podia olvidar del ASM, debido a que el compilador no me dejaria en tanta libertad de configuracion como ASM. En concreto se refirieron a la configuracion de los modulos PWM que algunos PICs integran, ya que segun ellos resultaba mucho mas versatil programarlos en ASM, por que las opciones de configuracion que ofrece el C para esta tarea son limitadas, eso fue lo que me comentaron, de ahi deje unos meses el tema (en general la electronica) y pues ahora estoy retomando todo esto.

Te comento que ahora con el compilador ya me ha tocado el manejo de los modulos PWM de mi 16f877 y hasta ahora no he tenido problema, asi que no podria precisar la razon por la que ellos tenian esa impresion. ¿No se si tu sepas algo al respecto?

maunix dijo:
Al usar un compilador uno pierde control sobre ciertas cosas y debe ser así , sino para qué tener un compilador. Referido a perder el control, hablo de que por ejemplo algunos direccionamientos indirectos y/o registros no se pueden usar porque entrarían en conflicto con el funcionamiento del compilador en sí. De todas formas los módulos y puertos del pic se pueden usar perfectamente.

Yo he sentido hasta ahora puras ventajas al usar C, salvo el detalle de la optimización. Y además cualquier constante que no tienes en el .h de un PIC determinado, solo vas la agregas y listo, o modificas las existentes a tu antojo. Lo unico es que no se si en alguna parte se pueda uno encontrar la referencia tecnica de todas las funciones prefabricadas del CCS, pues no me la he encontrado y a veces es util para despejar dudas.

Saludos,
 
alejandro_oo dijo:
Eso tambien habia leido que el codigo generado en C es mucho mas lento que el ASM.

Desde mi punto de vista, esto es cierto siempre y cuando seas un master del ASM... por que si no lo eres, lo mas seguro es que tu programa sera peor que el generado por un compilador de C que tiene funciones que ya han sido muuy optimizadas...
 
Eso si que ni que, y sabes otra cosa que me he dado cuenta, también yo tenia por cierto el mito de que el *.HEX generado por el CCS seria muchísimo mas grande que el generado directo por *.ASM, y veo que es algo exagerado decir eso, puesto que lo que he me ha tocado trabajar con CCS no me sucede (al menos no marcadamente)

Por otro lado comentarles que ya estoy trabajando con el timer por interrupciones y si, era justo algo así lo que necesitaba. Todavía no logro un ajuste muy preciso de los tiempos de disparo, pero ahí la llevo.

Saludos,
 
Atrás
Arriba