Interrupt End?

E

econjack

Well-known member
We have all heard: "Interrupt Service Routines (ISR) should be as short as possible." Why? I don't honestly know why?

I think it's because all other interrupts are blocked until that ISR completes. Does this mean that interrupts are enabled when the ISR goes out of scope? Does it make any difference if the current ISR is the only ISR in the project? How do I know when the code in the ISR is too long? How does it manifest itself when the ISR is too long, especially when it's the only interrupt?

This isn't a pure academic question. In my current project, one ISR is almost 2 pages of source code and I want to discuss it with the author, but I can't find an objective way to tell him why its too long other than saying it looks too long. (The project has other interrupts.) I think that the ISR is a blocking routine is a "good enough" explanation, but if some knows a better way to explain it, I'm all ears.

Thanks!
 
Interrupts/exceptions have individual priority levels. When an exception is in progress it blocks all other exceptions of lower or equal priority. Whether a long ISR is a problem or not depends on what priority it has versus any other ISR that may need to run at the same time...
 
econjack said:
I think it's because all other interrupts are blocked until that ISR completes. Does this mean that interrupts are enabled when the ISR goes out of scope? Does it make any difference if the current ISR is the only ISR in the project? How do I know when the code in the ISR is too long? How does it manifest itself when the ISR is too long, especially when it's the only interrupt?
Click to expand...
Agree with jmarsh.

In addition, saying it is the only ISR really depends on what if anything you are using in the core code.

For example: There is a timer interrupt that is used for SYSTICK... used for things like millis()...
There are interrupts to handle USB communications
Interrupts to handle Hardware Serial ports.
Probably for SD Cards
...
 
econjack said:
I think that the ISR is a blocking routine is a "good enough" explanation, but if some knows a better way to explain it, I'm all ears.
Click to expand...
figure out the interrupt level and check if more important task are processed at higher interrupt level. Interrupt level processing requires considerations of all other tasks. Also, ANY interrupt level processing will block main setup() and loop() functions.
Having said that interrupt level processing is IMHO an elegant way of running multiple tasks. They even lead to cooperative multi-tasking. Take for example the audio library, it sun completely hidden in the background.
 
Oh, also all the "fast' pin interrupts share one hardware interrupt so one long pin ISR will block all of the other pins. You have to switch the pins over to "slow" mode if you want to give them individual priorities.
 
Interrupts vary between processors. Some disable all interrupts while servicing an interrupt (MSP430 for example) others allow higher priority interrupts to horn in. It all depends. Since interrupts are for things that happen infrequently (usually) or need to be serviced quickly, it is always best to do only what needs to be done. As quickly as possible so the CPU can get back to its regular work.

I recall looking at some code for a blinking thing years ago that only got anything done at all outside of an ISR because the CPU always executed at least one instruction after returning from an interrupt before servicing the next. Not a good way to do things.
 
You must log in or register to reply here.
Back
Top