1
\$\begingroup\$

I am trying to understand interrupts in embedded systems. Please correct me where I am wrong. Below is my understanding.

This could help me and other who are trying to understand interrupts.

  1. Interrupts are the signals generated by a peripheral to request the microprocessor to perform a task. When an interrupt occurs, the CPU executes the current running instruction then stores the necessary stack pointer and program counter (PC) information somewhere in RAM allocated for the current function.

  2. The PC is now vectored to the corresponding interrupt vector table index to execute ISR routine.

  3. All interrupts are assigned individual enable bits which must be written logic one together with the global interrupt enable bit in the status register in order to enable the interrupt.

  4. When an interrupt occurs, its interrupt flag is set and the corresponding ISR routine reads this flag inside them. For some peripherals these can be automatically cleared by reading the interrupt flag bit and data register while for some peripherals we need to explicitly write a logic one to clear the interrupt flag bit.

  5. If the corresponding interrupt flag bit is not cleared it cannot interrupt corresponding events again (for example, when interrupt A occurred and its interrupt flag is set until and unless you clear the interrupt flag the processor will not be notified about the next event from A,) make sure to read the necessary register before clearing them. Am I correct?

  6. When an interrupt occurs, inside its ISR routine we can disable interrupt either by setting individual interrupt enable bit to zero or by setting global interrupt bit to zero. Doing this is not advised because this hinders nested interrupts from occurring thus some information will be lost.

  7. When nested interrupts are enabled, a low priority can be preempted by a high priority interrupt.The ISR routine of the low priority interrupt will saved and high priority will get executed. If both are of same priority the interrupt with lowest sub-priority will be executed. Who assigns this sub-priority?

  8. Maskable interrupts are the ones where we can disable the interrupt by writing instruction like setting the "Interrupt Enable" bit to zero.

  9. Vectored interrupts are the ones where we already know the address to jump for the ISR, like the interrupt vector table with address and priority, for example the SPI, I2C, UART interrupt, timer.

  10. What are non-vectored interrupts? I know that that we do not have a predefined address, but what is that suppose to mean? Can someone please give an example?

\$\endgroup\$
3
  • 3
    \$\begingroup\$ PIC16 uCs (at least the older ones) are a well known examples of devices having non-vectored interrupts. All interrupts share the same vector, thus end up in the same ISR function. The software needs to poll flags to determine which interrupt has occurred. \$\endgroup\$
    – Tagli
    May 29 at 10:52
  • \$\begingroup\$ @Tagli ish. Depending on the PIC, there can be more than one vector based on priority. I'm not sure if the PIC16 has this, but the PIC18 (for example) does \$\endgroup\$
    – Reinderien
    May 29 at 14:54
  • \$\begingroup\$ If you want your brain twisted in knots, see the DEC 21064 (Alpha) method of handling interrupts. It doesn't well-fit your descriptions. While instructions before the interrupting one are completed, the state changes caused by instructions after the interrupted one are not dealt with by the hardware. That's left to the interrupt routine to cope with. It's a serious pain to wrap your mind around. Bottom line? There's so many ways interrupts are managed in hardware, that it is very difficult to arrive at a one-size-fits-all definition. \$\endgroup\$
    – jonk
    May 30 at 7:38
2
\$\begingroup\$

What you have written is correct in itself, but I'm not sure what purpose it serves.

It's at too low a level to understand when you need to use interrupts or what they do for you. You can't see the wood for the trees.

However it's too high level and not detailed enough to implement interrupts on any particular machine, as they will have different specific addresses for their vectors, or bit numbers for their masks, so you have to dig down into the detailed documentation for any particular target to use them. It's almost meaningless to talk about them until you're trying to program a particular machine

At the simplest level, interrupts allow a computer or controller to respond in real time to a particular event happening.

Without interrupts, a computer would poll the various inputs, and depending on how fast the poll loop was, and how long it took to service another event, you could wait a long time to have your event serviced. If all your service routines are short, if all your events are tolerant of that wait before service, then there is no need for interrupts.

A common simple model I often implement in microcontrollers is to think of it as two machines, a real time machine, and a background machine, sharing a chip. I then have a fast(ish) interrupt running, every 1 ms or 10 us or so, which does what has to be done now, for instance load a peripheral register or read an ADC. I then have a background process that handles complicated but slower things like parsing incoming messages or writing files to SD card.

That's very simple. For more complicated systems you will need finer control. Whether interrupts can interrupt other interrupt routines depends on their importance and running time, which is an application specific thing. The mask bits, ISR flags etc, are just resources that enable you to control what can interrupt what and when. Whether interrupts have to generate the response in 10 clock cycles or 1000 affects whether you must use a vectored interrupt, or can wait for a non-vectored one to find out why it's been invoked, and it is again very application specific.

\$\endgroup\$
3
  • \$\begingroup\$ That's the same model I tend to use. \$\endgroup\$
    – Ian Bland
    May 29 at 11:52
  • \$\begingroup\$ I disagree. The OP's explanation is correct and useful and provides an insight into how the chip is actually handling things, what's physically going on. \$\endgroup\$ May 30 at 8:38
  • \$\begingroup\$ Your model might be a valid method of thinking about your problems in your way, but provides no insight atall into the workings. You could have 27 interrupts all prioritized and running together, or you could just have an MCU that does nothing except run code on a single interrupt. \$\endgroup\$ May 30 at 8:41
1
\$\begingroup\$

Your understanding is generally correct. You have mentioned a few things that are device-specific to an extent, such as writing 1s and 0s to enable and disable interrupts, since some architectures work slightly differently, and not all processors allow nested interrupts.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.