Interrupts

[Gabriel]

hey guys,

If i have 2 interrupts (lets say TMR1 and RDA) happen at the same time or while one ISR is being executed:

What happens to the other one?
Does my code enter the ISR for the "late" interrupt after the other ISR is done?
Or do is simply miss it completely?


Order or precise timing is not relevant to me...

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[asmboy]

based on lst file my belief is that the 2nd
INTR called during an int service works like this:

current int completes,
that INT unstacks
it's INDIV int flag clears
then
2nd ,overlapped int loads stack and executes
when it is done
global int is reset too

last item is where i am not sure in real time

[asmallri]

From your title I assume your question is with respect to the PIC16 family. The PIC16 family architecture is a relatively primitive, dated architecture. It features a single interrupt level therefore once inside the interrupt handler the PIC cannot be interrupted by another interrupt event. (Not strictly true, it is possible through poor programming to enable interrupts inside the interrupt handler). Instead the interrupt handler runs to completion. When it exists from the handler, if another interrupt is pending then the PIC will again pass control to the interrupt handler.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Gabriel]

Hey guys thanks for your replies.

so i understand that there is a "INT pending list" (note the " signs)

interrupts will handle/happen sequentially in the order they arrived FIFO style...

thats... good news for me...

yes, I only deal with 16F series....

Thanks
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[RF_Developer]

On the 16s there is only one interrupt. The global interrupt handler has to check all the possible interrupt flags to see which caused the interrupt. The handler should loop round, calling your interrupt routines one by one, until all the peripheral interrupt flags are clear. The 18s are similar except that there is more than one interrupt, but NOT one for every device as there is on some other processors.

So any device that raises its interrupt flag while interrupts are disabled, such as when the global ISR or our ISRs are running, will get serviced when interrupts are next enabled.

If ISRs should be short enough so that the processor can service with an interrupt before the next one occurs on the same device, or on another device that cannot wait until the ISR executes. If not, then interrupts can be lost.

With multiple interrupt sources, it is not generally easy to guarantee interrupt latency. The latency could be the normal interrupt latency, which is the hardware and the time taken for the global handler to do its thing, PLUS the longest execution time of any other ISR. Just think what might happen with a serial receive ISR, which is triggered with characters every 100us, while some other ISR takes 250us to run....

Generally though, provided you keep ISRs as short as practical, and do only what's absolutely required - no delays other than a few cycles or us, no printing, no sendign to other devices, no waiting for something else to happen and so on - then for most devices, interrupts won't be held up for so long as to cause problems.

[asmboy]

its the damned variable latency of multiple INTS that makes me OFTEN use ONLY the RDA int - and go so far as to POLL times and other "interruptible" sources , when trying to deal safely with 115200 baud.
More ints in a 16F program is MORE chance for trouble IMHO........

[gpsmikey]

[Gabriel]

I really appreciate all your explanations.

My question arises from wanting to use TMR1 as:
"total seconds of run time over the lifetime of the product"....

1s int frequency .... that just ++ a 32 bit counter...

and have RDA work at the "the same time"... at 9600...


Looks like i just have to be smart about it but it "should work".

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Gabriel]

@gpsmikey: that make complete sense..

FIFO was not the right description... but i get the point.

thanks.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Ttelmah]

You don't even have to be terribly 'smart' to get this one working. This though is the key reason why you shouldn't 'loiter' in the interrupt handler. Even using a 4MHz clock, a 9600bps interrupt using a circular buffer will only take under 100 instructions to execute, and correspond then to a 'worst case' with data arriving continuously of just 96000 instructions/ second of chip execution (100 instructions, 960 times per second). Still less than 10% of the processor time.
The timer should be quicker (handling arrays, needed for data buffering, is quite slow on the PIC), simple counters, are conversely quick to run.

Best Wishes

[John P]

As I said in this thread just a few days ago:
http://www.ccsinfo.com/forum/viewtopic.php?t=49965

I really think the best way to deal with multiple interrupts is to have just one, a repeating timer, which stands in for the others by checking flags (the interrupts each do set a flag) and doing the work for them--obviously, with the minimum amount being done at interrupt level and the maximum in main(). If you have a UART, then use a timer rate that's somewhat faster than the minimum time for a single character, and you can be sure you'll never miss any.

There is a high overhead any time you service an interrupt, on account of all the registers that have to be saved and un-saved. Do that several times in succession for stacked interrupts, and you've incurred a major delay at unpredictable moments. Much better to know you can get in and out again at a fixed rate.