Interrupts - Updating timers inside the ISR - PIC micro 1

[atferrari]

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.


Agustín Tomás

 

[nbucska]

Let's call the processes P1 and P2.

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/>

 

[atferrari]

Time base: 5 ms.

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

 

[MikeHalloran]

At least two people have told you not to do things a certain way. It appears that you intend to go ahead and do them anyway, because your respondents didn't explain why you shouldn't.

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

 

[atferrari]

Hola Mike,

Is it your reply intended for this thread?

Agustín Tomás

 

[itsmoked]

You will always have 'jitter' because an interrupt of any kind does not always occur during the same place in the T-States.

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

 

[nbucska]

Keith:
$,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/>

 

[atferrari]

Hola Keit,

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

 

[richs]

As to your second question, the adding provides a "usefull" feature of taking some of the latency out of the timer reset. As you are aware, the timer will interrupt as it transistions from 0xffff to 0x0000. At that point, the timer will generate an interrupt by setting it's IF flag. Now, assuming that the processor is busy doing something else (like it's already in the interrupt service routine), the timer will continue to uptick from 0x0000.

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.

 

[MacGyverS2000]

If memory serves, the PIC has up to 1 clock cycle of jitter when it comes to interrupts based upon the current instruction being executed. Again, if memory serves, if it's executing a goto, an interrupt may happen immediately or be delayed by a cycle depending upon where in the 2-cycle goto the processor was at... can't remember what other 2-cycle instructions exist (not at my desk). The same will happen if you're branching to the interrupt routine for TMR0 and a CCP1 interrupt is fired. That being said, your requirement for zero jitter just fell out of the window.



Dan - Owner

http://www.Hi-TecDesigns.com

 

[atferrari]

Dan, please reread my last posting (5 Apr). Already cleared that the 1st aprt of mye question was nonsense.

Agustín Tomás

 

[tunelabguy]

There are two things that happen when a CCP1 compare event occurs. One is that you can have an output pin change state. This effect has no jitter and happens exactly when the compare event happens. The second thing that a compare event can do is cause an interrupt. This may be delayed if interrupts are disabled. If you are worried about jitter in your CCP1 output pin, you have nothing to worry about since the interrupt service routine is not setting that output. The output is set automatically by the hardware with no jitter. All you have to do is make sure the interrupt code is able to set up the conditions for the next compare event before it occurs.

Robert Scott
Real-Time Specialties
Embedded Systems Consulting