Why should interrupts be short?
I'm currently using STM32 and it has a feature of prioritizing interrupts.
Because of that, I don't see any difference between these two options:
Why should we keep them short? Is it because of caching? Small stack? Or something else? Why can't we just create the whole system on interrupts and make the main loop sleep?
Any ideas?
Not only is there no reason you can't do that. An event driven system is not uncommon. BUT. On many architectures if you are in one interrupt you cannot have another, so even a low-priority interrupt can in some systems prevent a higher priority interrupt from happening, so the general rule is to get in and out fast. Often a design approach is the interrupt comes in and does some handling, but leaves a task for the kernel or foreground task to finish, more seen with operating systems.
I believe the Cortex-M can nest interrupts, so if one comes in on top of another it gets handled. Most of the chip is not related to ARM, so there isn't any reason why the chip vendor can't put an interrupt handler in front of the Cortex-M and/or a priority handler, in addition to whatever is in the arm end of things.
Nevertheless, an interrupt-driven design needs to be designed. As with any other design, you need to do your system engineering. You need to know every possible interrupt (under normal situations, undefined instruction, etc are fatal) and how often they occur. Many will be regular periods.
You also need to know how long each interrupt takes, and schedule this such that you can ensure that all interrupts will be handled in an amount of time that meets your specification. For example, a timer-based interrupt event for something takes 50 ms to handle normally, but there is one non-periodic random interrupt that takes 20 ms. Is 70 ms tolerable for either of these? Does the chip/core have a priority solution? If not, have you laid out your interrupt priorities such that you can meet timing on everything?
At the end of the day, there is little difference between all interrupts and some interrupts and some foreground with respect to the design and timing of the interrupts; you have the same problem.
So the general rule is make interrupts lean and mean and fast, but the reality is do your system engineering and know how much time you have for each or groups of them combined. It must take less than x amount of time.
Re-entrancy is/becomes a major headache the more your ISRs are complex. The wikipedia entry has a pretty succinct description of a re-entrant ISR:
A reentrant interrupt handler is an interrupt handler that re-enables interrupts early in the interrupt handler. This may reduce interrupt latency.[6] In general, while programming interrupt service routines, it is recommended to re-enable interrupts as soon as possible in the interrupt handler. This practice helps to avoid losing interrupts.[7]
Assuming you're not writing a general purpose OS where re-entrancy might very well be unavoidable, you have to keep in mind the added complexity of having re-entrancy in your custom bespoke controller code might just not be worth the perceived ease of writing lazy long runninng ISRs.
Here's an example:
malloc that you have implemented. malloc call, you get interrupted by a higher priority thread: it calls malloc tooOk, you'll say, I'll put a spin lock on malloc, then all you need to do is repeat the above condition to the spinlock_aquire primitive you've created: is it re-entrant?
I should point out here that just slapping locks on things and calling it a day is a recipe for priority inversion based deadlocks. It's not that simple.
The poor man's solution to all these problems is to keep your ISRs short. For instance, in the NT kernel, a long time ago (haven't kept up to date), any IRQL above the bottom two most weren't allowed to even look at paged memory. This was because paging was handled by an interrupt...
So choice becomes: implement a basic queuing mechanism and have your ISRs dispatch work units, or make your ISRs behave freely but ensure you have an extremely robust environment that will not choke on weird issues (e.g. priority inversion).
If your task at hand is super simple, like turning on a light in your arduino controlled drone, then by all means go ahead. But if you want to avoid engineering headaches later on as your code gets more complex, you really should avoid the perceived benefit of giving yourself no constraints at all with an ISR.
* clarification: scenario b cannot occur at face value since the higher priority ISR will always execute and complete before the lower priority one. However, the code-path taken by either one can be swapped. So in the malloc routine itself, if there is any access to a global data structure, that code can be interrupted in any possible combination of ways.
Further to this point, it should be stated that the re-entrancy requirement for any function is for its entire call tree. This becomes very difficult to ensure if you end up using third party libraries.
Also note: to address a comment from @user253751, re-entrancy isn't solved by merely wrapping things in a lock. Rather, re-entrancy has a set of requirements that are well understood. Here are some relatively trivial code examples that illustrate the matter.
It can be seen, by looking at this that writing a re-entant malloc or resource acquisition function becomes very difficult.
For a general purpose computer, keeping the interrupt handler short permits normal processing to be reasonably deterministic which may or may not be an issue depending on application.
In a hard real time embedded process (where determinism is of critical importance) this makes a lot of sense.
I implemented a very precise tilt sensor (2 axis) where the sensor drive was controlled by timers and the main loop was in sleep mode until the counter fired the interrupt to update which axis was being driven; the external ADC I was using was also controlled by a (different) timer to minimise acquisition jitter for the averaged samples (which can cause havoc in a sampled data system).
To maintain the ability to do some calculations in a very narrow time window, the interrupt handlers needed to be fast (take the interrupt, do the minimum required and exit).
In other applications, all the interesting stuff can happen in the interrupt handlers (as was the case when I was involved with a video on demand system with up to 2000 simultaneous streams available).
There is no 'one size fits all' answer for interrupt handlers and is application dependent, although as noted nested interrupts can get messy particularly if two handlers need to share a single resource (which can lead to data corruption if not dealt with properly and in a multitasking system can also lead to priority inversion).
What approach one takes to interrupt handlers is application dependent, but a first approach of 'keep them simple and fast' is always a good starting point.
I've dealt with this sort of thing a lot on a previous project, and here are a few things I've dealt with (often learned the hard way). Some of the details can vary based on your chip architecture and how close you're running to bare metal, but the general ideas still apply.
Thankfully, all of these problems have the same simple solution. Your interrupt handler should store the necessary information about the interrupt, clear and re-enable the interrupt, then signal some other piece of code to do the actual work. That's easy enough to do on most platforms that there's really not much benefit in trying to cram all your work into the ISR itself.
Because interrupts prevent other interrupts from running. Keep them short basically just means do no more than you need to in the interrupt.
one big interrupt with very low priority and the other interrupt
This requires nested interrupts (to allow interrupts to interrupt each other) which can get messy. Not all processes can be safely interrupted.
I can be a conscious design decision to move your workload into interrupts alone.
But a lot of care and safeguards must be taken to ensure deadlines and stack will not be exceeded.
An NVIC is basically a very crude scheduler. The tasks will run as priority set, when triggered by a timer, software or other source.
In an ARM Cortex M3 you have fine control over priorities and nesting. In an ATMega or 8051 you do not.
If you look at what you are doing thread-wise with this model, you'll have:
You're already 3 levels deep, this means at least 3 stackframes!
With the priority grouping you can limit nesting to a few levels. But this might costs you deadlines.
With an preemptive RTOS you'll have finer control and not as much nested interrupts and less risk of blowing the stack. And often included performance metrics.
And obviously all the side-effects of asynchronous shared data and re-entrancy. Since in an ISR you cannot wait for some resource to become available. You'll block all equal and lower priority threads from running at all. Unless only higher priority threads use it.
Lot's of implicit constraints!
If you can fit your software design to operate within the constraints of this model, often combined with the superloop model for tasks that do not carry a hard deadline, then yes, it is a valid design.
If properly documented for your team to understand as well.
For real-time applications, predictable timing is often more important than performance. External interrupts will have unpredictable timing, so the longer they get, and more impact they will have on the overall timing of your system. Note that I'm talking about high-priority interrupts here: having a long low-priority interrupt is not a problem, as long as it doesn't affect the time-critical stuff (but mind the re-entrancy problem mentioned in another answer).
I have seen several projects which were struggling to get consistent IO timing despite the CPU load being reasonably low. Replacing longer ISRs by polling or reducing them to a simple "copy byte / set flag" handlers and doing the rest in periodic tasks was the only way to get that timing under control, at the expense of some extra CPU load.
The concept of interrupts essentially allows you to do two things: the normal stuff that you would ordinarily do, and immediate stuff that needs to be handled when some event happens.
You don't need to do things that way, but if you don't, you're not taking real advantage of the interrupt structure. Your code will probably be harder to understand, maintain, and debug.
Something about your suggested architectures reminds me of RTOS's, though.
Can't comment yet, so I'll post it here:
It was mentioned by some that one could carefully design an interrupt based scheduling system on a hardware that supports interrupting interrupts.
I'd like to add: On the Cortex-M, that would seem silly, though - as it has dedicated facilities to support context switching for non-interrupt based "threads", in other words, instead of going to the head ache to design a working all-interrupt system, might as well use something like FreeRTOS?
The big difference between a main loop and interrupts is scheduling.
A main loop works like a fifo system. Step by step it processes what is asked of it. It is linear, so memory consumption is rather deterministic and if you ask the main loop to do more than it can handle, each task will still be done, but just slower. It is also rather easy to debug.
Interrupts, when issued, interrupt the main loop. Thus the main loop is paused, which can cause timing issues if the main loop is paused for too long.
If a second interrupt is issued while the first is still running, there are two ways a processor can handle that. Which way is determined by the processor, but some processors let the programmer choose. Either the processor can reject other interrupts while one is being handled, or it can interrupt the last interrupt, put it on the stack, execute the new interrupt and then return to the last interrupt.
The first option is rather simple, but it could result in interrupts getting lost, because the interrupt condition is no longer valid by the time the first interrupt finishes it's execution. Also, that way lower-priority interrupts can hinder the execution of higher-priority interrupts.
The other option allows for higher-priority interrupts to interrupt lower-priority interrupts and also interrupts cannot get lost. But that's at the cost of introducing concurrency-related issues even on a single-thread system. Also this makes memory consumption non-deterministic, since a lot of interrupt executions being pushed on the stack increases the memory consumption by quite a lot.
I had this issue once when programming an application that handles IR signals on an ATMega328p. My interrupt routine was too long and slow and if two IR senders would send a signal at the same time to the ATMega (which should result in just an unrecognisable signal) the interrupt execution of the first signal flank was not finished before the next signal came in, which caused that interrupt execution to be pushed on the stack. This was repeated until both IR senders stopped sending. Until then the stack had hundreds interrupt executions stacked onto it, which caused a stack overflow. Now, the ATMega328p has no stack overflow prevention so it just continued spilling into the heap area and completely corrupted the whole memory.
Ideally you want to do as little as possible via interrupts. It is a lot easier debugging a loop than having interrupts jump in seemingly at random. The fewer the better.
