Elapsed Timer findings

[Ioannis]

Oh dear! So ... simple...

Ioannis

[Tabsoft]

Art,

Wow, that seems complicated, glad it was you figuring it out.

I took what you posted and looked at DT's Elapsed.bas.
I believe the formula that Darrel used to calculate the Timer preload value can be calculated a little easier.

First a couple of statements.
1. One thing to point out first is that if OSC = 40Mhz he sets the Timer Prescale to 2.
Otherwise the Prescale is set to 1.

2. He is indeed allowing for 8 Instruction Cycles to accommodate setting the Timer value.


The formula to set the Timer1 Preload value is the following:
Tpl = ((2^Tb)-1)-(It/(1/(Fosc/4)*Ps)-Tric)

Where:
Tpl = Timer Preload value
Fosc = OSC Frequency
It = Target Interrupt Time
Ps = Prescale value
Tb = Timer Bits (8 or 16)
Tric = Timer Reload Instruction Cycles


Here are the computation for 4,8,10,20 and 40 Mhz

4Mhz:
Tpl = ((2^Tb)-1)-(It/(1/(Fosc/4)*Ps)-Tric)
Tpl = ((2^16)-1)-(.01/(1/(4,000,000/4)*1)-8) = 55,543 (0xd8f)

8Mhz:
Tpl = ((2^Tb)-1)-(It/(1/(Fosc/4)*Ps)-Tric)
Tpl = ((2^16)-1)-(.01/(1/(8,000,000/4)*1)-8) = 45,543 (0xb1e7)

10Mhz:
Tpl = ((2^Tb)-1)-(It/(1/(Fosc/4)*Ps)-Tric)
Tpl = ((2^16)-1)-(.01/(1/(10,000,000/4)*1)-8) = 40,543 (0x9e5f)

20Mhz:
Tpl = ((2^Tb)-1)-(It/(1/(Fosc/4)*Ps)-Tric)
Tpl = ((2^16)-1)-(.01/(1/(20,000,000/4)*1)-8) = 15,543 (0x3cb7)

40Mhz:
Tpl = ((2^Tb)-1)-(It/(1/(Fosc/4)*Ps)-Tric)
Tpl = ((2^16)-1)-(.01/(1/(40,000,000/4)*2)-8) = 15,543 (0x3cb7)

Cheers.

[Art]

Of course it can be simpler I didn’t know if Ioannis’ comment is sarcastic or not
It is very simple once you realise it’s incremented to overflow, so the number itself has no meaning.

Ok, mine is so old there’s no 40MHz definition in it!

it doesn’t hurt to see this number: 49992. It’s how many instructions you have after the timer interrupt
that will be free from further interrupt if you’re doing something on TicksChanged rather than SecondsChanged.
So I have learned to Read/Write I2C, Write LCD, etc in that time.

Next time I do any LED clock I’d like to try a centi and millisecond display HH:MM:SS:cc:mm!

[Ioannis]

No offense, but I was a bit sarcastic

@Tabsoft: Nice, a complete tutorial!

Ioannis

[Art]

No offence taken, it is rather simple. I have to admit though, I’ve looked at it another time and given up.

I have an idea, but will probably stray off what this thread is for, so will start my own later.

[Tabsoft]

Art,

Regarding your remark...

"Next time I do any LED clock I’d like to try a centi and millisecond display HH:MM:SS:cc:mm!"

You can certainly do this with very few changes to DT's Elapsed_INT file, as I am positive you already know.

I have already done this once before for a project that I needed to display sub-second time.

I had created an ElapedDemo program and modified Darrel's original "Elapsed_INT.bas" file appropriately.

I also took the time to continue to modify the file to incorporate some of the changes he did for his DT_INT-18.bas file for v1.2.
He did away with hard coded TimerConst values for the different OSC values and replaced it with a compile-time calculation instead.
He also did away with the TIMER1 prescaler and implemented a SW postscaler instead for frequencies above 20MHz.

All very cool ideas. Sure do miss DT and his wisdom.

Plus, I added a change of convenience that others might find useful to quickly change the interrupt period at compile time.

I will comment the changes, clean up the code and give it a good test.
Once I am done, maybe tomorrow or the next day, I will post it all here in a zip file.

Cheers.

[HenrikOlsson]

Hi,
That sounds cool! Tweaking, adapting, improving and sharing is great but, and this is my personal opinion, please please please, when you do re-post any of Darrels files which has been changed, for whatever reason, PLEASE make sure to name it so that it's easily differentiated from the original file(s). If you change it, please document the changes and do not re-upload it with its original name, for example Elapsed_INT-18.bas. Doing so will eventually create a nightmare....

/Henrik.

[Tabsoft]

No worries Henrik.

My upcoming post already has the differentiations you suggested implemented.

Secondly, since the information is not necessarily Darrel's original work but rather a derivative, I was planning on posting it on the Code Examples forum in a new thread to keep it separate from this thread.

[Art]

I can certainly do what I’m talking about, but still also interested in anything you come up with.
Timer driven (rather than event driven) pic programs are a rather new fad for me.

The calculation I posted, the reverse of which is:

$FFFF - (((20 / 4) * 10000) - 8) = $3CB7

Would blow out a word variable if you tried to calc the value for 40MHz!
I was doing it with a desktop calculator in scientific mode right up to subtracting from $FFFF to look for any decimal places..
There will be trouble if you use a crystal that is not an even MHz increment.
Some crystals with decimal places would be fine, but PBP wouldn’t know if you introduced resolution error into the real time keeping.
I think seeing decimal places is fine right up until the final value $3CB7 is that correct?
You would not want to see decimal places int he final value.