PIC One Second algoritma iz rimskega Black

[BlackOps]

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.

hvala še enkrat

 

[xorcise]

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): Code:

movlw      .158;              // allow 2 cycle compensation for Timer0 reload and restart
addwf      TMR0,F;            // ready to go
bcf        INTCON, TMR0IF;

 

[Mike, K8LH]

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)...