¿ Por que tendrias un 2do micro para ser de contador del 1ero ? Mejor no me lo respondas... Esto es peor que apretarselo contra la puerta.
ocurre que si este esta sumerjido bajo otra interrupcion, no atiende al void timer1
A no ser que poseas un micro con prioridades no vas a lograr eso JAMAS ( y darle prioridad al timer obviamente ), ademas una interrupcion debe ejecutarse rapidamente, si no lo hace provoca esos problemas y caeria en la categoria que esta mal programado. Pero el problema es que exigis que la prioridad sea de la interrupcion externa.
Y aca es donde tenes que decidir, si gastar 10us en la interrupcion del timer y demorar la externa o viceversa.
Si eso parece pero si este contador se desborda durante el delay() o otra interrupcion. Este sigue adelante de 0 a set_timer pero sin atender en el momento adecuado a todos los desbordamientos. De la manera en que e elavorado el 1º no puedo librarme del 2º es mejor que este se encarge aparte de los timer.
Si se desborda durante un delay deberia entrar a la interrupcion, si tenes un delay en una interrupcion entonces es un problema de mala programacion, si estas en otra interrupcion vas a tener que esperar para salir para poder entrar de nuevo a la interrupcion, y si,se va a pasar un par de microsegundos si usas el timer solo. Podes usar el modulo CCP para que esto no ocurra, es decir que si se retrasa 10us, esto no se traslade a la proxima interrupcion, si lo que intentas crear es una base de tiempo. Si ya tu interrupcion bloquea a tu timer/CCP por mas de 1 overflow, entonces esta mal programado.
El CCP en modo Compare,, la linea de tiempo seria asi, suponiendo que es de 10ms la interrupcion:
0us - Ocurre la igualdad, activa interrupcion, esta en otra interrupcion asi que no entra, le faltan 100us para salir de esa interrupcion
100us - Sale de la otra interrupcion, entra a la del CCP
10ms exactos - Se produce otra ves la interrupcion del CCP, esta ves no hay otra interrupcion en curso
20ms exactos - Se produce interrupcion del CCP, lamentablemente estaba en otra interrupcion y le faltaban 50us
20ms y 50us - Entra a la interrupcion del CCP
30ms exactos - Se produce la otra interrupcion del CCP.
Eso con el timer solo hubiera sido distintos, hubieras tenido algo asi:
0us - Ocurre overflow, activa interrupcion, esta en otra interrupcion asi que no entra, le faltan 100us para salir de esa interrupcion
100us - Sale de la otra interrupcion, entra a la del timer, y se carga de nuevo el timer
10ms y 100us - Se produce otra ves la interrupcion del timer, esta ves no hay otra interrupcion en curso
20ms y 100us - Se produce interrupcion del timer, lamentablemente estaba en otra interrupcion y le faltaban 50us
20ms y 150us - Entra a la interrupcion del timer y recarga
30ms y 150us - se produce la otra interrupcion del timer.
Como observaras se va acumulando el error. Mientras que usando el CCP no.
Ahora si necesitas que la reaccion sea exacta, entonces dedicalo a otro micro, pero me cuesta creer que necesites de algo tan complejo como eso. O mejor ir por una FPGA/CPLD
Pues si la interrupción del temporizador sucede cuando se está atendiendo a otra interrupción, deberías sumar el valor acumulado, ya que el temporizador sigue contando los pulsos de reloj después de desbordase.
Si necesita tanta precision como el dice eso no lo va a salvar, ya que tenes que tener en cuenta si posee preescaler eso no lo va a poder sumar o restar y siempre va a tener un error. Ademas es complicarse las cosas teniendo el CCP que te lo hace por vos mismo a las cosas.
En resumen, no se lo que busca el del timer, Si es que sea una base exacta de tiempo o tener la reaccion que apenas se produzca la interrupcion actuar. En paralelo no puede actuar a no ser que posea 2 nucleos o use una FPGA/CPLD.
