On 01-Feb-02 Alan B. Pearce wrote:
>>Why stop the timer, btw?  Reads do not (read: should) affect the count.
>> Read the low byte into W, put it into another register, then get the
>>high byte - the counter can't go fast enough to increment the high byte
>>by the time it executes 3 instructions - and the interrupt latency could
>>even be accounted for...
>
> Oh yes it can !!
>
> Consider what happens when you read the low byte, which happens to be FF
>
> in the middle of the 3 instructions you talk about, an edge occurs that
> causes the counter to increment.
>
> What has happened to the total count as read in terms of what you think you
> actually read? I think you will find a difference of 256 in there somewhere.

If this was the only problem then I think it can be easily overcome.

H1 = Read High
L  = Read Low
H2 = Read High

if H1 != H2
{
        if L < 0x80   use  H2:L         ; rollover before reading L
        else          use  H1:L         ; rollover after reading L
}
else
        use H1:L


This detects the rollover of the High byte and the value of the low byte lets
you workout if the roll over happened before or after the read of the low byte.

I'm pretty sure this works, as I tried it out

BUT...

See my other post on this thread for info in the errata sheet as to why you
should NOT read the timer while it is running.

Peter

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