Electronic – Software timers using hardware interrupt

On the PICs with two 32KHz timers (TMR1 and TMR3) my recommendation would be to use one of the timers 'free-running' (never write to it) and use the other to generate wakeup events. If you only have one timer available, getting reliable operation without cumulative errors is going to be very difficult. Different part revisions have different behaviors when it comes to writing timer 1, and so an approach that would work with one revision may be broken by a future revision. What would have been nice would have been if Microchip had allowed the timer to switch between synchronous and asynchronous modes without losing a count (simple to do: instead of using a multiplexer to switch between sync and async mode, add asynchronous set/clear to the synchronizing latch, and when in async mode use those to force the output to follow the input). None of their parts are, so far as I know, documented as doing any such thing. Consequently, I would expect that switching between synchronous and async mode may randomly gain or lose a count.

I tested your code in MPLab Sim and on real hardware, getting the expected results in both cases (4 minutes with perlight = a*61 and time set to '2 minutes'). Perhaps your problem is caused by some code you haven't shown us, or you have a hardware issue. However I can see some things that might affect the timing:-

1. You are incrementing the 16 bit variable intr in the ISR, then comparing it to perlight in your main code. The 16F628 can only compare 8 bits at a time, and an interrupt can occur at any time, so intr could change in the middle of the comparison and corrupt the result. To prevent this possibility you should disable interrupts whenever intr is accessed from the main code.

2. After the timing session finishes your timer interrupt keeps going, and you don't reset intr before starting another timing session. This causes subsequent timing sessions to be up to 4 seconds short. At the beginning of each timing session you should disable interrupts, reset the timer hardware, reset intr to zero, then re-enable interrupts to start counting.

3. You are clearing TMR0 in the ISR. This is not necessary because the timer automatically wraps to zero when it overflows. However any write to TMR0 also resets the prescaler, losing the cycles it counted between the timer overflow and write to TMR0. Letting the timer run free allows it to keep consistent time even if interrupt latency changes.

4. With a 4MHz clock and 1:256 prescaler you cannot get an accurate 2 second time delay because 2/0.065536 is not an integer. However you can get very close by changing the prescaler to 128 and using a `perlight' multiplier of 61, which equates to 1.998848 seconds (128*256*61). For best timing accuracy you should use a crystal or ceramic resonator rather than the internal oscillator (which can be out by several percent).