>   This is an interesting ideea. But is not more easy to check only the
> tmr1if bit, to reset that bit and to increment the software counter every
> time after that ? What would be the benefit of reading the tmr1h register
> instead ? ( except when is important to know the whole value of TMR1...)

The assumption is that a period start event can happen at any time.  The
easiest way to measure period is with a CCP module that saves the value of
timer 1 at the time of the event.  The software doesn't find out about this
until after the timer 1 snapshot has already been taken.  The timer 1 state
must therefore always be ready for an event.  Checking TMR1IF leaves a gap
between the overflow and its handling.  If the handling is done by
interrupt, then you could make an assumption that very small capture values
with TMR1IF set happened after the wrap but before it was handled.

I like keeping the interrupts free for important time-critical stuff, so
usually handle timer 1 wraps in the foreground loop.  The code is a bit more
tricky, but at this point it's been used a number of times and is well
tested.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu