SOLVED - How to calculate Timer preload

[Ioannis]

What are the 10000 and 8 stand for in the equation?

Ioannis

[Demon]

I couldn't tell you. See Art's thread above.

[tumbleweed]

What are the 10000 and 8 stand for in the equation?

The 10000 comes from the fact that the intr code is assuming a 100Hz interrupt (MHz -> 100Hz = 10000),
and the 8 is an attempt to compensate for the number of instruction cycles it takes to reload the timer.

Demon -
How long of a time period are you looking to measure?
If you can live with 65536 counts (the 16-bit timer count) then you can just drop all the interrupt code, let the timer free-run, and just subtract two unsigned timer values... something like this:

start_time = readtimer()
'code you wish to time is here
elapsed_time = readtimer() - start_time

[tumbleweed]

If you let the timer free-run, then at 32MHz using FOSC/4 as the timer clock and 1:1 prescaler you can count up to 8192us (8ms) with 125ns/count.
Setting the prescaler to 1:8 extends this to 8x8192 = 65536us (roughly 65ms), but your resolution drops to 8x125ns = 1us

[Demon]

Tumbleweed, that's the thing. I'm still at the research phase; trying to determine what Henrik calls velocity sensing.

Next challenge: Velocity sensing, ie a way to detect that the user wants the value to change by a lot and not have to turn the knob 600 turns. Getting that just right seems to be tricky, even the big boys don't always... (I've never tried).

I can flick the rotary encoder at 3.5msec from low-low to high-high, but still need to determine that cut-off speed.

https://www.picbasic.co.uk/forum/sho...000#post156000


And then it hit me as I'm typing this post. I can use the logic probe in real-time to find that sweet spot, instead of writing code to display that on LCD (or xmit via HSEROUT). And that's where things get crazy cause all that extra code and I/O would definitely throw off my readings.

Can't see the forest for the trees...