When Interrupts collide

[Hans Wedemeyer]

I have to do a project which requires two asynchronous signals to be accumulated with no lost counts.

Luckily the signals are not high frequency about 500mS and 100mS

Initially I'm planning to use EXT_INT for the slower signal and INT_TIMER1 for the slightly fast signal.

I anticipate there will be times when interrupts collide.

So I’m trying to figure out the best or preferred or correct way to ensure no counts are missed.


Is there a "sure fire way" to handle the situation when an interrupt collisions occurs ?

Is it OK to do code for the un-handled interrupt in the other ISR or is it best to handle it outside in main ?

Will this work ?


#BYTE PIR1 = 0XF9E
#BIT TMR1IF = PIR1.0

#byte INTCON = 0XFF2
#bit INT0IF = INTCON.1

int32 ExtCounter;
int32 T1Counter;

////////////////////////////////////////////////////////////////
//
#INT_EXT
EXT_isr()
{
ExtCounter++;

if (TMR1IF) // is set then INT_TIMER1 has not been handled
{
T1Counter++;
clear_Interrupt(INT_TIMER1);
}
}
////////////////////////////////////////////////////////////////
//
#INT_TIMER1
TIMER1_isr()
{
T1Counter++; // totalizer finer resolution is in the 16 bit counter registers

if (INT0IF) // is set then INT_EXT has not been handled
{
ExtCounter++;
clear_Interrupt(INT_EXT);
}
}

[Mark]

You wouldn't lose the interrupt. Instead you would just get back to back interrupts. You can use the #int_global to create a global interrupt handler and then check for the 2 interrupts inside of it. This would probably be the cleanest method.

[PCM programmer]

I did the same thing that you're doing, the code shown in this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=906

Using #int_global means you have to write your own interrupt dispatcher.
That seems like a more high risk approach.

[ckielstra]

I don't like the given examples where an interrupt handler also checks for another interrupt to be active. These examples will give the shortest response time possible, but reponse time was not mentioned as a requirement. Problem with the given examples is that they are more difficult in maintenance, for the current two interrupts it will do but imagine how more complicated it will become when a third interrupt will be added in a later stage.

I suggest to use the standard interrupt dispatcher. No simultaneous interrupts will be lost, they will be handled 'back to back' as Mark already mentioned. Only disadvantage is about an extra 100 instruction cycles overhead, but who cares for this very rare case at these low frequencies? The small but rare overhead you can save is not worth the added complexity of the given examples.

[Hans Wedemeyer]

[Mark]

[Hans Wedemeyer]

[Hans Wedemeyer]

[ckielstra]

[Ttelmah]

It is basically impossible to miss interrupts, _except_ if the total time taken in any handler, plus the time needed for the global handler code, is longer than the interval between any interrupt, or the input signal, does not last long enough. This varies with the PIC, and the interrupt involved. For example, the 'port changed' interrupt, must be held for four entire clock cycles, while the INT pin typically only needs 25nSec.
I have hundreds of systems, some of which have been servicing typically 15000000+ interrupts a day, from multiple sources, and have never seen even one missed (Usually 100 clock counts per second, plus about thirty received, and similar number of transmitted characters - both handled with interrupts, plus SPI comms, plus keypad operation).
The interrupt flag, is standard logic. A simple hardware flip flop. If this is not being triggered, it is because the signal does not meet the signal/timing requirements.

Best Wishes

[Hans Wedemeyer]

[Ttelmah]

The problem here, is that if there is a hardware problem in the PIC, no amount of fiddling with the code is going to help, unless (as with the NOP), it is not a problem with triggering the reset flag, but the actual code jump that is triggered. Hence 'being defensive', is really pointless.
Get a really good logic logging system, set a system up, and test it for real. You can program the logger to trigger on the interrupt event, and see if the handler does respond with total reliability or not. Even cruder, get a simple up/down counter module (the little LCD ones). Have the event that is meant to trigger the interrupt trigger the 'up' counter input, and have the handler toggle a pin on the down counter input. Leave it running for a day or two, and see if the counter is anything but 0/1. If it is, there is a problem, otherwise leave well alone, and get on with the other parts of the project...

Best Wishes

[Hans Wedemeyer]