Interrupción en TMR0 afectada por interrupción RB0

caballeros. estoy realizando un proyecto para controlar la velocidad durante determinados intervalos de un motor ac de 1000W con un pic16f876a. esta casi todo listo. la simulacion anda de full, pero al conectar todo, y empezar a hacer las pruebas. cuando le conecto el sensor que le indica al pic las rmp actuales del motor. afecta el temporizador tmr0 que me esta contando los segundos que leva encendido el motor, y ya no me cuenta un segundo sino mas o menos 1.3 segundos...pero cuando le desconecto el sensor. el conteo vuelve a la normalidad.
mi pregunta es. acaso la interrupcion por rb0 está afectando el conteo y desbordamiento del tmr0? o no se, hay otra explicacion para esto?
por favor de verdad necesito solucionar esto, tengo que entregar ese trabajo el martes :D
les agradezco su colaboracion
 
¿Estas programando en C?, si no es así, y utilizas el lenguaje en ASM puedes utilizar el TMR1 para realizar el conteo y administrar bien los recursos del PIC. Saludos
 
si, mira estoy programando en c ccs, el problema es que tengo todos los timer ocupados. el 0 lo uso para generar un pwm sincronizado con la señal de 60hz de la linea, el tmr1 para medir la frecuencia a la que gira el motor y averiguar su rmp. ¬¬, y creo que me equivoque en la pregunta inicial por que el tmr2 es el que tengo configurado para tomar el tiempo en segundos y minutos como temporizador.... lo raro es que cuando la señal de entrada en el tmr0 es baja. no afecta la precisión del tmr2, pero cuando sube a 60 hz uff ya no me cuenta un segundo sino 1.4 segundos..y obviamente me descuadra todo el tiempo, por ejemplo si queria que el motor gire a 3600 rpm durante 1 min ya no va a ser 1 min sino 1min y 24 seg...a que se puede deber esto no tengo idea alguna??
gracias
 
bueno, al parecer todo era por que dentro de la interrupcion que tenia usaba un delay mayor a la duracion de la interrupcion, o eso fue lo que pude entender. el caso es que la interrupcion era cada 8333 us y en el momento en que le metia un delay cercano a 8000 empezaba a dañarse todo. a fin de cuentas solo tuve que hacer el retrazo a 6000 us
 
Que bien que lo has corregido... esos problemas como provocan dolores de cabeza. Es por eso que tiene sus ventajas programar en ASM, creo que es mas fácilmente saber donde están los problemas de lógica.
Saludos
 
Atrás
Arriba