> B.t.w, *if* one can find a setup where you get a usable "timing"
> while letting the timer fre-run (that is, without ever re-loading
> the timer value), it is often easier to get a consistent overall
> timing in the application without having to bother about specific
> adjustments for some extra instructions here and there. This can
> sometimes need a carefull selection of the crystal frequency. And
> that is also why there are all those "odd" crystal values... :-)

If the ISR hasn't got any tests (btfsc, bz etc) then repeatability will
be OK. Each execution of the ISR will be exactly the same. And if
it did have any branch instructions it's usually not too much trouble
to write the code to be isochronous, even at the expense of making
it a little longer, as it's all deducted from the re-load value anyway

Crystal selection generally means thinking about what various timings
are needed in the whole program.

For example, if you chose 20.0000MHz, that can give you good
resolution timing in microseconds. But it might be lousy for a UART

If you chose 19.6608MHz, that's better for the UART but not so
good for some timing periods. 1s is easy enough, but not 1ms

Richard's requirement appears to be whole seconds, which can
be done with any crystal, one way or another. If I had a choice
of two crystals, I'd probably chose the hex one and let the timer
free-run. At around 4MHz I'd have a go with a 4.096. Even as
low as 3.6864 if code speed isn't an issue for other functions

Joe

Joe
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.