Jeremy Leach
Senior Member
Here's some thoughts about using Timer1:
I've just trawled some old posts and Hippy's excellent discussion at <A href='http://www.hippy.freeserve.co.uk/picaxert.htm' Target=_Blank>External Web Link</a>
I'm thinking of using Timer1 in a far less complex way than making a software RTC. I want it just to determine the elapsed time of running code - and I think it could be very handy for this and surprised no-one else has got into this before (unless I've missed it in the archives).
I'm NOT any expert with this Timer1 business, and am only going with the info that Hippy has come up with. But it seems that with a Prescaler of 3 you get Timer1 overflowing at 524ms (clock 4MHz).
It strikes me that half a second is a lot of code execution time and this Timer could be very useful to make code cycle at a precise rate without using interrupts.
What I mean is:
<code><pre><font size=2 face='Courier'>
1. Set Timer to 0
2. Block of Code executes. This takes a
variable elapsed time because of branches,
different values being evaluated etc etc.
Lets say the elapsed time varies up to
ElapsedMax.
3. Read Timer and calculate the ElapsedTime.
4. Pause for a time equal to ElapsedMax -
ElapsedTime. (Probably use Pulseout to a
dummy pin to get a precise Pause).
5. Goto 1
</font></pre></code>
The calculation of the Pause duration at step 4 ensures that the overall execution time from step 2 to step 4 remains precisely constant.
As long as the ElapsedTime is less than 524ms then Timer1 won't overflow and will give the ElapsedTime reading. I suppose there is also scope for going a bit beyond 524ms too, because you might be able to deduce when overflow has occured and still calculate the ElapsedTime.
Now and again we get posts regarding bit-banging and generating low frequency PWM signals from code. This could possibly be one use of this technique to ensure precise output frequency.
RexLan and myself are using Pulsin to measure and display engine RPM. One thing we've noticed is that the display refresh rate increases as the RPM increases - because the Pulsin duration decreases. So this technique could also be used to fix the refresh rate.
Edited by - jeremy leach on 29/12/2006 07:48:57
I've just trawled some old posts and Hippy's excellent discussion at <A href='http://www.hippy.freeserve.co.uk/picaxert.htm' Target=_Blank>External Web Link</a>
I'm thinking of using Timer1 in a far less complex way than making a software RTC. I want it just to determine the elapsed time of running code - and I think it could be very handy for this and surprised no-one else has got into this before (unless I've missed it in the archives).
I'm NOT any expert with this Timer1 business, and am only going with the info that Hippy has come up with. But it seems that with a Prescaler of 3 you get Timer1 overflowing at 524ms (clock 4MHz).
It strikes me that half a second is a lot of code execution time and this Timer could be very useful to make code cycle at a precise rate without using interrupts.
What I mean is:
<code><pre><font size=2 face='Courier'>
1. Set Timer to 0
2. Block of Code executes. This takes a
variable elapsed time because of branches,
different values being evaluated etc etc.
Lets say the elapsed time varies up to
ElapsedMax.
3. Read Timer and calculate the ElapsedTime.
4. Pause for a time equal to ElapsedMax -
ElapsedTime. (Probably use Pulseout to a
dummy pin to get a precise Pause).
5. Goto 1
</font></pre></code>
The calculation of the Pause duration at step 4 ensures that the overall execution time from step 2 to step 4 remains precisely constant.
As long as the ElapsedTime is less than 524ms then Timer1 won't overflow and will give the ElapsedTime reading. I suppose there is also scope for going a bit beyond 524ms too, because you might be able to deduce when overflow has occured and still calculate the ElapsedTime.
Now and again we get posts regarding bit-banging and generating low frequency PWM signals from code. This could possibly be one use of this technique to ensure precise output frequency.
RexLan and myself are using Pulsin to measure and display engine RPM. One thing we've noticed is that the display refresh rate increases as the RPM increases - because the Pulsin duration decreases. So this technique could also be used to fix the refresh rate.
Edited by - jeremy leach on 29/12/2006 07:48:57