PIC One Second Algorithm from Roman Black

thanks, Mike, K8LH , VVV.
thank u xorcise but i dont use BASIC, anyway its ppl with same problem in BASIC will c ur code here.

one more thing is i removed NOP from ISR, then i have set up PRESCALER to 1:1. and changed both variables to .100 After all of these, i should have load .167 to TMR0 (using movlw, and movwf) it means that i was loosing .167 - .156 = 11 cycles! 3 for context saving, 1 for banksel, 2 for TMR0 writing.. but what the other 5 cycles wasted for?...

well, its ok anyway, for any exact application i will have just to experiment. thanks again

Instead of calculating all the deductions as you're doing, do as Mike and myself are recommending.

This is how it works. Timers are already "deducting" counts even though they are incrementing, or counting up. Think about it, you want 100 timer counts before the interrupt, so you do the math: 256-100=156. Your Timer0 load value is 156, not 100. So the timer is incrementing, but actually counting down from 100 to 0. This is an important point for you to get conceptually.

So the jump to the ISR occurs when Timer0=0, and the timer continues incrementing every cycle until it reaches your Timer0 reload. So, as an example, let's assume that 10 cycles have passed and you now reload Timer0 with 156 (-100), simply do this (as Mike showed above):


Out of experience and comments in the datasheets, Timer0 must have a 2 cycle compensation for reload and thus I use the 158 value instead of 156. Back to my example. Timer0 already has a count of 10 and we now just add our constant load value of 158 which now starts the Timer at 168. Note that now only 88 counts will now pass before the next interrupt. We have automatically compensated for "lost" timer cycles.... no extra calculations required.

In conclusion, simply adding the existing Timer0 value to your load value you have effectively deducted, and compensated for, counts toward the next interrupt. Adding timer counts pushed you closer to next interrupt. So, you don't have to calculate all those other cycles as you were doing.

Mike's example above is more practical since it uses 250 cycles, or 250us @ 4MHz. This gives you room to do other code between interrupts. Just use a counter to keep track of the interrupts and you know when an exact 1 second period has passed. Also, if you use -250, use -248 instead, for Timer0 reload compensation.

Hope that helps..

I wish I could have explained the concept that well... Thank you Sir...

Also note, as I mentioned earlier, that adding your reload value to TMR0 will automatically compensate for the 1 cycle "jitter" that may occur when the interrupt occurs during 1 cycle and 2 cycle instructions in your MAIN program (it takes 1 cycle longer to get to your interrupt routine when the interrupt occurs during a 2 cycle instruction in MAIN)...