View previous topic :: View next topic |
Author |
Message |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
Interrupts |
Posted: Wed Feb 27, 2013 10:12 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Wed Feb 27, 2013 10:25 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Wed Feb 27, 2013 10:33 am |
|
|
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!! |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Wed Feb 27, 2013 10:57 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Wed Feb 27, 2013 11:18 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Wed Feb 27, 2013 11:35 am |
|
|
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........ |
|
![](templates/subSilver/images/spacer.gif) |
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Wed Feb 27, 2013 12:43 pm |
|
|
Gabriel wrote: | 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...
G. |
I don't think that is accurate - I believe it scans the bits for those set requesting an interrupt. The order it scans the bits determines what order the set bits get processed, NOT "sequentially in the order they arrived". There isn't a "stack" or FIFO of pending interrupts, instead a register with bits set for the appropriate requests.
mikey _________________ mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Wed Feb 27, 2013 12:49 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Wed Feb 27, 2013 12:52 pm |
|
|
@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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Wed Feb 27, 2013 4:02 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Wed Feb 27, 2013 8:32 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|