View previous topic :: View next topic |
Author |
Message |
Guest
|
Timer roll over |
Posted: Tue Mar 03, 2009 8:41 am |
|
|
Hi
I use a linear rotary encoder to measure some length.
The encoder running on a belt. If the belt is moving the encoder is too.
The encoder is connected to Timer0, and inc++ on every rising edge.
If I read Timer0 and save it, then after some time I do it again.
Ex1:
Code: | oldtmp=get_timer0();
//some time after…
tmp=get_timer0(); |
oldtmp can now be 10 and tmp can be 50. easy part. Diff is 40.
But if oldtmp is 250, and tmp is 10 then I pass the roll over(timer overflow -> start from 0 again...).
Code: | if (tmp<tmpold){
res=(0x100-tmpold)+tmp;
}
else {
res=tmp-tmpold;
} |
Is there a easy way to do that? |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue Mar 03, 2009 10:06 am |
|
|
Your thinking too complicated. If res is an unsigned int8, it will always give a correct result, without special processing of overflows. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Tue Mar 03, 2009 10:36 am |
|
|
Hmmm..
Timer0 is used as 16 bit and res, tmp, tmpold is all 16 bit too.
My ex. is only 8bit because I think it's the same, if not please help me out.
When you say I think complicated what did you mean?
I'm little confused? |
|
![](templates/subSilver/images/spacer.gif) |
Fusillade
Joined: 02 Aug 2007 Posts: 31
|
|
Posted: Tue Mar 03, 2009 10:38 am |
|
|
FvM wrote: | Your thinking too complicated. If res is an unsigned int8, it will always give a correct result, without special processing of overflows. |
Correct, as long as you never expect that your result will be greater than 255. If you think your value ever may exceed 255, you might consider the following
- Create an int16 value (I called mine overflow).
- Generate an timer 0 overflow interrupt which will increment the int16 value by 0x100.
Code: |
overflow = 0;
oldtmp=get_timer0();
//some time after…
tmp=get_timer0();
res=tmp + (overflow-tmpold);
|
Note: This code does not take into account the fact that the overflow value may change between the time timer0 has been read a second time and the result is calculated. Additional code is necessary to check for those conditions depending on your application. _________________ New:
Compiler Version: 5.078
IDE Version: MPLAB X V4.15
Devices: PIC18LF****
Old:
Compiler Version: 4.121
IDE Version: MPLAB IDE V8.63
Devices: PIC18LF**** |
|
![](templates/subSilver/images/spacer.gif) |
Fusillade
Joined: 02 Aug 2007 Posts: 31
|
|
Posted: Tue Mar 03, 2009 10:50 am |
|
|
Anonymous wrote: | Hmmm..
Timer0 is used as 16 bit and res, tmp, tmpold is all 16 bit too.
My ex. is only 8bit because I think it's the same, if not please help me out.
When you say I think complicated what did you mean?
I'm little confused? |
You were only making it complicated (meaning: unnecessary calculations) if you know for sure that you will sample timer 0 before timer 0 has had the opportunity to complete one full counter cycle.
His response still holds true for a 16-bit timer as well when using unsigned int16 values.
Ex:
oldtmp = 0xFF00
tmp = 0x0280
res = tmp - oldtmp
res = 0x0280 - 0xFF00
res = 0xFFFF0380
but since you are storing to an unsigned int16:
res = 0x0380
which is the correct answer so there is no need to check for overflow. _________________ New:
Compiler Version: 5.078
IDE Version: MPLAB X V4.15
Devices: PIC18LF****
Old:
Compiler Version: 4.121
IDE Version: MPLAB IDE V8.63
Devices: PIC18LF**** |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Tue Mar 03, 2009 12:38 pm |
|
|
Thanks:-) |
|
![](templates/subSilver/images/spacer.gif) |
|