The problem may not be in the measurement technique.
More than likely, it's due to two things. The first being ON INTERRUPT. Since it waits until the current Line of code has finished before it branches to the interrupt handler, you never know when the interrupt will actually be handled. If a Long Running statement like SEROUT is in progress when an interrupt occurs, it may be several milliseconds before it gets to the handler.
The second problem comes from just Loading the required "Count" into the timer on each interrupt. This causes it to lose however many cycles it took to get to the handler.
If you ADD the "Count" to the current timer value, it can compensate for the lost time. The way it works is ... Once the timer overflows from 65535 and creates an interrupt, the timers value is now 0, and the timer is still running. Once it finally gets to the interrupt handler, the timer value shows exactly how long it took to get there. So now, if you add "Count" to the timers value (plus the time it actually took to add it), you'll have accounted for everything, and Time will count normaly.
Using the ADD technique with ON INTERRUPT will definately help. But, I would suggest moving to ASM interrupts if you need to keep Long Term time accuracy, or Short term precision.
HTH,
Darrel
P.S. Since you mentioned it. Melanie's Olympic Timer shows one way to do the ADD thing. See the SetTimer routine.
Bookmarks