Delay calling IRQ handler ( CCP )

[rolox]

Hi,

i'm using CCP2 for measuring a short signal (some msec) with low frequency (some 100 Hz). It works as expected - but i noticed that it takes much longer than expected until the ISR is called.

After the Input signal rises, it takes about 3usec, until the ISR starts. this time increases up to 8usec, having more isr (serial, timer0) implemented
The pic runs with 32MHz, so the few instructions to save wreg etc should be done in <1usec.
When i enable the int_timer0 before leaving the ISR, this time is not constant and goes from about 1us to 10us :-(

Where does the other time get lost?


simple code which just generates a short as possible pulse in the ISR :

[temtronic]

hmm..
//enable_interrupts(INT_TIMER0);

You _must_ have an ISR with EVERY enabled interrupt !

Otherwise the PIC can (will) go into 'Lala Land' and crash or do 'weird' things.


Jay

[Ttelmah]

The key to the question though, is that you have to save a lot more than just the Wreg etc..

The interrupt handler has to test what interrupt is happening (you obviously want to use more than one, and if you do there has to be such a test), and also saves every register that might be changed in the handler. Typically about 30+ instructions.
You can code without this, but then you are going to have to go through the assembler, and verify exactly what registers are touched in the handler (will be more than you expect - remember an array access will touch the indirect addressing registers, any maths will affect the status, etc. etc..). How to do this is shown in ex_glint.c

[rolox]

ok ...adding an empty ISR for timer0 keeps the delay still constant - as it should be.
The explanation for that delay is understandable, and as long its quite constant, it doesn't matter when measuring pulsewidth....
I need to have a short interval for timer0 (around 100us) - and as soon as there is more than a few instructions in that timer0 ISR, the CCP2 ISR has no longer a constant delay regarding the input pulse (which is understandable in that way, that it might get longer in the case, the pic is in the timer0 ISR when the input pulse arrives: In that case it's clear that the CCP ISR can be executed only after the timer0 ISR has finished. But how could the delay be shorter than without timer0...?)
I understand its a matter of design: I need to convert a pulse width from 0...5ms into a corresponding PWM signal, and that should be done already during the pulse, to have the PWM "ready" right after the falling edge....thats why i have that sort timer0 interval to adapt PWM during pulse width.

[RF_Developer]

The time to enter an ISR is called interrupt latency. There is some related to hardware - the processor samples the interrupt line (internal or external) on at some point in its processing cycle. It then has to stall the pipeline save hardware context and start executing the code at the interrupt vector.

Then a global interrupt handler has to run as PICs don't have fully vectored interrupts. The global handler has to save code specific contexts, that varies with the user's code. Then it polls the enabled interrupt sources one by one to see which requires servicing, and calls the appropriate ISRs.

The global interrupt handler (normally provided by the compiler, but you can do your own if you really want, and know what you're doing!) is simple enough for a short program with only one interrupt source/ISR. When there are two sources/ISRs, the polling has to be done in some order. I have seen, somewhere but I can't remember where, a discussion of the default ordering of interrupt polling. If its not what you need, you can change it using the #priority directive. This is often thought of as only useful when two interrupts happen at once, but it controls the polling order - you don't your time critical ISR to be polled last, you want it polled first to reduce its latency.

When you have two ISRs, if one is empty, probably the complier doesn't call the ISR, it my simply clear the interrupt. Enabling the interrupt source inside the ISR should have no effect as global interrupts are still turned off (they are turned off by hardware and re-enabled as the last thing done by by the global interrupt handler, in fact as part of the return from interrupt instruction. DO NOT enable global interrupts in an ISR unless you know exactly what you're doing and you've made suitable firmware preparations.

If you have two, or more non-empty ISRs, then they cannot interrupt each other. If one is running when an interrupt occurs, it must run to completion before the other ISR can run. That means that with two or more ISRs, interrupt latency for any source can never be guaranteed to be constant. It will vary by at least the execution time of the other ISRs. That's one very good reason for NOT using delays or long execution time code such as floating point, eeprom or program memory writes and so on, in ISRs.

The only way to get consistent interrupt latency is to have just one ISR, anything else will give a lot of jitter. Of course, there will always be some jitter due to hardware constraints. This means that if timing is critical, interrupts and firmware in general, is not a good way of achieving it.

[Ttelmah]

The default ordering, is the order the handlers are declared. Very simple.

All of the comments of course 'change' if you switch 'up' a family or two.

The PIC18, does allow two hardware priorities (so one interrupt can interrupt another), but there are restrictions on this (INT_EXT is always high priority).

Then the PIC24, does have separate vectors for the separate interrupts.

[rolox]

Thanks at all - good explanations - think i got it. Changed design according to this and latency is now constant enough for my needs. Also results are good enough when my PWM is changed every 500us instead of every 100us.