Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Interrupt within interrupt

Status
Not open for further replies.

electronicsman

Full Member level 5
Joined
May 4, 2012
Messages
291
Helped
11
Reputation
22
Reaction score
12
Trophy points
1,298
Activity points
3,737
I have following questions about interrupts.
1. Whether interrupt will happen in other interrupt?
2. Suppose i configure a timer interrupt for 1ms. Apart from this let us assume i have interrupts for ADC, timer2, CAN etc. Will i always get 1ms interrupt? In case if i write big logic in any of the interrupts then am i going to miss the 1ms interrupt?
3. How to make my system more predictable with so many interrupts and functions? Very confused. I am referring to dspic controllers. Please advise.
 

1. Whether interrupt will happen in other interrupt?
while handling an interrupt, another interrupt may occur
2. Suppose i configure a timer interrupt for 1ms. Apart from this let us assume i have interrupts for ADC, timer2, CAN etc. Will i always get 1ms interrupt? In case if i write big logic in any of the interrupts then am i going to miss the 1ms interrupt?
in general rule, disable interrupt while handling another interrupt if it is not that critical.
3. How to make my system more predictable with so many interrupts and functions? Very confused. I am referring to dspic controllers. Please advise.
check point above
 
Hi,

1. Whether interrupt will happen in other interrupt?
An interrupt may be requested at any time.
But whether it is (immediately) processed or not depends on:
* microcontroller
* software

In case if i write big logic in any of the interrupts
ISRs should be short in time. If possible just set a flag in the ISR then process the data in MAIN.

***
for example:
An UART_read interrupt usually is criticle in time. If you don´t run the ISR wihtin a specified time, then you may loose data.
Therefore you should enable the interrupt. BUT it should be very short in time. Just read the recived byte, push it in a softwae FIFO and set a flag.
This takes only a couple of microseconds... then leave the ISR immediately.

But poll the flag in MAIN, and if set process the FIFO data and clear the flag.

****

Klaus
 
dsPIC has vectored interrupts with multiple priority levels. If you allow a particular interrupt to be interrupted by a higher priority interrupt ("interrupt nesting") is up to your decision. Review the respective chapter in family reference manual.
 
The general principle in a broad way: (modern interrupts work in a complex way)

You will need a interrupt controller; that will vectorize 10 (or so) pins with different priorities. The output of the controller will connect to the interrupt pin of the microprocessor.

Everytime microprocessor gets an interrupt, it disables interrupt and goes into an interrupt service routine. You should enable interrupt at the earliest.

Interrupt controller maintains a table of interrupts with different priorities; an interrupt with a lower priority cannot interrupt an ISR currently running with a higher priority (may be silently ignored or a negative acknowledgement may be sent)

ISRs are just like normal subroutines by you are advised to do only essential work; there is a different return from the ISR.

Timer interrupt is handled internally (it has the highest priority)- but nesting interrupts can become really messy- if the table space overflows your microprocessor may hang.

Many of the interrupts you mention are handled internally in a user transparent way (like the timer interrupt) and you need not worry too much in your program.

But you should not try to include any time intensive work in the ISR.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top