So that means that TMR0 has to only roll over 6 times for mS to equal mS >= 10000 ?.
Then I wouldn't have thought that this would be very accurate over time?.
At first glance it may appear to be a very inaccurate method.. Keep in mind the difference is carried forward - which ensures no timing data is lost.
The oscillator/hardware could be configured to accommodate more-natural timing.. I think when I wrote that short guide I'd considered just that, although kept it at 20Mhz as most PIC new comers would probably be using that hardware by default.
So yes; after the first second, the mS counter (with a scale of 1000) would equal 11466. One second is deducted from the counter, leaving 1466. The next interrupt would add 1638, resulting with 3104, and so on (difference carried forward).
The overall result; at any one-second interval the program would be accurate to within 1.638mS. At large scale (and in the perfect world); the interrupt that occurred after 100 hours would be accurate to within 1.638mS (6000 perfect seconds, plus a possible 1.638mS lag).
This has been a good discussion; I've merged the topic with the comments for the TMR0 article.
Not sure I'm on the same page Burt - It is showing us a different result as well.. The Multi Calc has a setting for "Re-load cycles" which is a minimum of 1 cycle. You've also defined a pre-load setting (1). The overall result is 1.6332mS.
Reloading the timer is a common approach, however, I'm using the timer's overflow flag (and not re-loading the timer).
Re: Swordfish Code Snippet - TMR0
8 years 5 months ago #6888