Most embedded systems use interrupts, which are typically triggered by some peripheral device. In a lot of interrupt tutorials/examples, it always says that ISR code must be kept short
Why Short Interrupt Service Routines Matter?
Why don't we just create the whole system on interrupts and make the main loop sleep?

No, most interrupts are NOT triggered by peripheral devices. That is just a capability of the MCU. Interrupts are the very life-blood and heart of timing and task processing in any operating system.

Short ISRs are directly related to the amount of time it takes to execute the code in the interrupt versus when that same interrupt is going to fire again. Obviously, you want to complete your task in the time given, and not run beyond it. If you run beyond your available time slice, that interrupts fires again, parking your code, starting the new iteration, and so on- this will consume the stack-frame and memory becuase your tasks aren't completing fast enough.

Most developers do NOT have experience working in interrupt driven systems. They are used to a linear progression of their code, and are not familiar with the additional coding aspects necessary to make code re-entrable, or prevent it from being re-entered in an interrupt-driven system so that things work homogeneously. If you aren't familiar with how to actually develop in such an environment, you can create logic errors in your code that you cannot figure out.

 

Of course you can put the processor to sleep if there is no task to perform.
That is what we do with battery powered embedded systems.
Think of your main loop as the lowest priority task. When the task is completed, go to sleep.

 

A technique I like to use is put the main loop to sleep while waiting for a hardware interrupt (be it an input, or a timer, etc) to happen. At the interrupt routine a flag is raised and the routine immediately returns to the main loop, where the flag is sorted and a call to the corresponding code takes place. This method allows me to decide exactly which routines take precedence and in which order. That way several interrupts can happen at the same time and the risk of code collision is eliminated.

After all of the flags have been tended to, then the main loop goes back to sleep.

 

Most embedded systems use interrupts, which are typically triggered by some peripheral device. In a lot of interrupt tutorials/examples, it always says that ISR code must be kept short
Why Short Interrupt Service Routines Matter?
Why don't we just create the whole system on interrupts and make the main loop sleep?

Each interrupt will store information on the stack.
If all programs are located in the interrupt routine and each interrupt routine creates an interrupt or look for one the stack will explode.

Picbuster

 

We built low power products that lived off a coin battery. The power level was so low that we did not have a on/off switch. The micro was in sleep mode most of the time. A timer ran and caused a wake up interrupt. On interrupt the micro would check if there was work to do and if not it returned from interrupt and shutdown the computer.

 

Low-end PIC processors only have one interrupt, and you have to check flags to decide which source the interrupt was triggered from. That causes problems in some ways, but excess use of the stack isn't an issue.

 

Low-end PICs have a tiny stack. I have used micros that have a stack as big as all RAM and then moved to 8-pin PICs. It took time to learn not to use the stack for storage.

 

Most embedded systems use interrupts, which are typically triggered by some peripheral device. In a lot of interrupt tutorials/examples, it always says that ISR code must be kept short
Why Short Interrupt Service Routines Matter?
Why don't we just create the whole system on interrupts and make the main loop sleep?

You could. It would be no different than calling a routine and sleeping there. You waste an interrupt though, and for some of the mention possibilities, uneedlessly expose yourself to unpredicted actions.

 

The issue with those PIC processors isn't about interrupts, but subroutines, which also use the stack. You'll only use one stack level with an interrupt, but subroutines are unlimited. You certainly wouldn't want to use them recursively, and in fact I don't think any compiler allows it.