Chip Weller wrote:

> One word of caution, whenever you write to the TMR0 the prescaler is
> cleared.  This does result in a more accurate single time until
> overflow, but if you are trying to also keep track of longer term time
> you will lose on average 1/2 of the prescaler ticks per write.

  It obviously makes the most sense to choose crystal frequencies which
correspond to a power-of-two multiple of the desired timing interval so
that TMR0 does not need to be written at all.

  If you *must* however set the timer up to a different count, this will
normally be done in an interrupt service routine.  As such, it will
happen a certain number of cycles into that routine on each occasion, so
the prescale value at the point of timer load should be known to within
one cycle.

  The error comes from the posibility of interrupting in the first half
of a PC modifying instruction and waiting for such an instruction to
complete.  The error is not "on average 1/2 of the prescaler ticks per
write" but "an occasional prescaler tick per interrupt".

  If however, you reload the counter after polling for overflow (having
performed a "background" procedure or sequence thereof *guaranteed* to
take less than the timeout period,) then you must take into account the
(absolutely constant) number of instructions between the poll and the
timer write, but there will be no error.
--
  Cheers,
        Paul B.