Interrupts - Updating timers inside the ISR - PIC micro
Interrupts - Updating timers inside the ISR - PIC micro
(OP)
Micro 18F452 - Working in assembler.
I plan to derive timing for two simultaneous processes using:
a) CCP1 in compare mode against TMR1 that generates a clock which should exhibit NO jitter due to TMR0 interrupt occurrence (see below). This clock has no 50% duty cycle so CCPR1L and CCPR1H should be alternatively loaded with different values.
b) TMR0 (16-bit mode) overflow interrupt to get a time base, of namely 5 ms. Interference from interrupt in a) is acceptable since the time base is used in debouncing, LEDs and display routines but no clocks.
My questions:
1 - What is the best way to ensure that CCP1 compare interrupt is always served on the spot, with priority over TMR0 interrupt?
a) Making it "high" priority and TMR0 "low" priority, or both with same priority but checking the CCPI interrupt first in a sole ISR servicing them?
Seen reccomended quite often to stay away of priorities if at all possible but never a reason was given!!
2 - For "reloading" the value of TMR0 I've seen reccomended "adding" a value to current one in TMR0 registers insted of "loading" one, every time the ISR takes charge to start the new counting period.
Besides that "loading" instead of "adding" affects the prescaler if assigned, is any other reason to consider? Found that told many times in the Microchip forum but never actually explained.
Thanks for any help.
I plan to derive timing for two simultaneous processes using:
a) CCP1 in compare mode against TMR1 that generates a clock which should exhibit NO jitter due to TMR0 interrupt occurrence (see below). This clock has no 50% duty cycle so CCPR1L and CCPR1H should be alternatively loaded with different values.
b) TMR0 (16-bit mode) overflow interrupt to get a time base, of namely 5 ms. Interference from interrupt in a) is acceptable since the time base is used in debouncing, LEDs and display routines but no clocks.
My questions:
1 - What is the best way to ensure that CCP1 compare interrupt is always served on the spot, with priority over TMR0 interrupt?
a) Making it "high" priority and TMR0 "low" priority, or both with same priority but checking the CCPI interrupt first in a sole ISR servicing them?
Seen reccomended quite often to stay away of priorities if at all possible but never a reason was given!!
2 - For "reloading" the value of TMR0 I've seen reccomended "adding" a value to current one in TMR0 registers insted of "loading" one, every time the ISR takes charge to start the new counting period.
Besides that "loading" instead of "adding" affects the prescaler if assigned, is any other reason to consider? Found that told many times in the Microchip forum but never actually explained.
Thanks for any help.
Agustín Tomás





RE: Interrupts - Updating timers inside the ISR - PIC micro
Please specify the timing of both processes.
"NO jitter" is impossible -- please specify it, too.
----------------------------
Please read FAQ240-1032
My WEB: <http://geocities.com/nbucska/>
RE: Interrupts - Updating timers inside the ISR - PIC micro
Clock at the pin RC2 (CCP1 output) from 120 to 6000 Hz with a duty cycle that could be between 40 to 60%.
Xtal: 4 MHz
Are these values relevant to my questions? Sorry but I am asking for a conceptual reply.
Why not zero jitter? I believe that if CCP1 has priority ensured over TMR0 nothing should make it to wait for jumping into its own ISR. I may be wrong, so please elaborate.
A preciate your help and time!
Agustín Tomás
RE: Interrupts - Updating timers inside the ISR - PIC micro
The good part is, you'll eventually understand the why.
The bad part is, whatever bit them will also bite you.
Different people learn in different ways.
Mike Halloran
Pembroke Pines, FL, USA
RE: Interrupts - Updating timers inside the ISR - PIC micro
Is it your reply intended for this thread?
Agustín Tomás
RE: Interrupts - Updating timers inside the ISR - PIC micro
Have you tried your method?
Personally I would just run a 1ms counter as I have done many times before. When it goes off just service your most important function first. At 4Mhz you have about 1 million instructions between interrupts.
Keith Cress
Flamin Systems, Inc.- http://www.flaminsystems.com
RE: Interrupts - Updating timers inside the ISR - PIC micro
$,000,000 * .001 = 1000 ; you are 1000 times off -- but
basically right. Of course, the cpu may need several clk-s for one instruction.
Agustin:
How much jitter can you tolerate ?
----------------------------
Please read FAQ240-1032
My WEB: <http://geocities.com/nbucska/>
RE: Interrupts - Updating timers inside the ISR - PIC micro
Your reply made me realize that the jitter DO exists for the interruption but NO for the RC2 pin (clock output) toggling every time CCP1 matches TMR1. What makes the first part of my question, useless.
Let's now concentrate on the priority treatment of this.
Thanks for your help.
Agustín Tomás
RE: Interrupts - Updating timers inside the ISR - PIC micro
By "adding" to the value (remmeber this is "decreasing" the time it will take to re-reach the 0xfff to 0x0000 we have taken into account the "residual" time that it takes for the processor to finally get around to reseting the counter.
In other words, we have kept track of how long since the interrupt it's been because the timer is continuing to work. By adding to this value, we are really decreasing the time before the next interrupt by the EXACT (without taking funnies with the prescaller into account) amount of time that it took for the processor to finally "reset" the count value.
Hope this helps.
Cheers,
Rich S.
RE: Interrupts - Updating timers inside the ISR - PIC micro
Dan - Owner

http://www.Hi-TecDesigns.com
RE: Interrupts - Updating timers inside the ISR - PIC micro
Agustín Tomás
RE: Interrupts - Updating timers inside the ISR - PIC micro
Robert Scott
Real-Time Specialties
Embedded Systems Consulting