PDA

View Full Version : Reading Timer1 value



DynamoBen
- 18th June 2006, 01:59
I have a project where I need read and compare the current Timer1 value to a constant.
In the datasheet there is a note stating

"...the user should keep in mind that reading the 16-bit timer in two 8-bit values itself, poses certain problems, since the timer may overflow between the reads"

I plan to use the following to read the time on the clock into a single word variable. That max. value should not get to the point where the timer would overflow:

period.lowbyte = TMR1L ; Store the Timer1 value in period variable
period.highbyte = TMR1H

Has anyone ever run into a problem reading Timer1 and not getting an accurate/true value? Is it possible to just use TMR1 instead of the above example?

SteveB
- 18th June 2006, 03:24
DynamoBen,
Not a direct answer to your question, but food for thought:

Depending on which PIC your using, Timer1 may have a 16-bit read/write option. Simple put, if enabled, when you read TMR1L, TMR1H is buffered, so that no errors are introduced due to the delay between reading the two registers.


I have a project where I need read and compare the current Timer1 value to a constant.

You also might want to check out CCP-compare mode. It sounds like a possible solution for you to try.


Steve

DynamoBen
- 18th June 2006, 04:19
CCP is not an option for what I'm doing. However the info on read/write is interesting. I'm using the 16F88.

Darrel Taylor
- 18th June 2006, 04:37
Hiya Ben,

This might help too.
http://www.picbasic.co.uk/forum/showthread.php?t=3891#VAR
<br>

SteveB
- 18th June 2006, 05:07
CCP is not an option for what I'm doing. However the info on read/write is interesting. I'm using the 16F88.

Then the 16-bit read is not an option either. I am pretty sure it is only available on the 18F models. Oh Well.

Steve

L_Gaminde
- 19th June 2006, 00:14
Is there a timer2 in this chip and is it 8 bit then only one read is necessary

DynamoBen
- 19th June 2006, 03:27
8bit isn't an option, I need 16bit.

paul borgmeier
- 19th June 2006, 08:27
In the datasheet there is a note stating "...the user should keep in mind that reading the 16-bit timer in two 8-bit values itself, poses certain problems, since the timer may overflow between the reads"

... That (DynamoBen's) max. value should not get to the point where the timer would overflow:

You not only need to worry about the timer overflowing from $FFFF to $0000 but from $xxFF to $x(x+1)00. IF you read the lowbyte and then the lowbyte overflows before you read the high byte, you will get the wrong answer. If you cannot stop the timer in your application, try something like this


X var BYTE ' in addition to your variables

period.highbyte = TMR1H
period.lowbyte = TMR1L
X = TMR1H – period.highbyte
If X = 0 then Continue
period.highbyte = TMR1H
period.lowbyte = TMR1L
Continue:

to ensure you get the correct time. (If at all an option, I would stop timer before reading and then your issue goes away.) Although you did not mention it, you should stop the timer before you write to it per a recommendation from Microchip.

Paul Borgmeier
Salt Lake City, Utah
USA

DynamoBen
- 19th June 2006, 16:21
Perfect, that was the info I was looking for. I will try to stop the clock before any read/write.

Thanks!