With a free-running timer IRQ you should have no latency.
Latency is a delay during which a new value is loaded to
the timer by the user. eg you want an IRQ period shorter
than the full 00 to FF. Roman and Bob Ammerman have
done some work on error-free timing, you can find it in the
archives or at the Piclist site.

With a free-running timer it merely rolls over from FF to 00
and the IRQ period should be consistent and predictable

Using a 32,768Hz crystal -

Internal cycle time = 32768/4 = 8192Hz
Time for TMR0 to roll-over = 8192/256 = 32 IRQs per sec

You can use a pre-scaler to reduce the number of IRQs, eg
pre-scaler=16 (PS0=1, PS1=1, PS2=0) = 2Hz TMR0 IRQ

This is your 500ms

> I am not worried about it, as 5/32.768 is pretty damn good,

5/32.768 is bloody awful !!!! That's 16% error from a crystal that
is ppm stable

> but I was just wondering if I should expect better.

Oh yes, oh yes. I suspect that the problem is not with the timer
but with the routine that does the overall "variable X" timing. How
do you propose to get 0.768s when you have an IRQ that has a
resolution of 0.500s ?

You can count the whole seconds easily enough, but for that last
little bit you'll have to use s/w loops and count instruction cycles

You have fun, y'hear ;-)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads