1

I've been reading about the classical ARM 7 microcontroller. There are two types of interrupts: IRQ and FIQ. FIQ allowing faster interrupt handling and having a higher priority than IRQ.

It states that modern ARM versions have nested interrupts.

Does this actually mean that the ARM 7 can only handle 2 interrupts assigned to the MCU, for example 2 edge triggered interrupts from an external source, and no more?

Thanks in advance

Engineer999
  • 3,683
  • 6
  • 33
  • 71
  • [tag:irq], [tag:isr], [tag:interrupt], [tag:interrupt-handling] are all the same thing; I don't know why they are not synonyms. See: [What is the difference between fiq and IRQ](https://stackoverflow.com/questions/973933/what-is-the-difference-between-fiq-and-irq-interrupt-system). The FIQ is a completely separate structure used for a few different purposes. – artless noise Feb 22 '18 at 15:39
  • just like with any other processor including current arms you can multiplex one interrupt into as many as you bother to and have room to create logic for. Some form of interrupt controller is used to do this. – old_timer Feb 22 '18 at 15:39
  • The ARM7 was not initially/necessarily used/limited to MCUs. – old_timer Feb 22 '18 at 15:41
  • Look at the raspberry pi (ARM11 based) and see how many interrupts it has feeding the IRQ and FIQ lines...clearly more than 2. – old_timer Feb 22 '18 at 15:42
  • x86 had only one interrupt for a long time as did many other processors, interrupt control was done outside. (not counting NMI in the one interrupt) – old_timer Feb 22 '18 at 15:44
  • actually on the pi2 and 3 they continued to use the broadcom interrupt controller. – old_timer Feb 22 '18 at 15:51

1 Answers1

1

ARM7 would most likely have been used with a vectored interrupt controller - a component tightly coupled to the core, but not as tightly coupled as the modern interrupt controllers used or integrated with either Cortex-M (ARMv6-M, ARMv7-M and ARMv8-M) - which are integrated into the exception model, or the A-class interrupt controllers.

This older type of vectored interrupt controller would provide multiple inputs, with masking, and priority. It would raise an IRQ input to the core, and provide an address which the core could read as part of the common interrupt handler - this then branched to the exception specific handler. Note that at the architectural level, there would just be one IRQ interrupt - containing a hardware assisted jump table.

ARM7 also allowed a simpler interrupt architecture - the exact implementation being customised for the application. Most trivial (and maybe uncommon) would be to OR all of the interrupts together and require the interrupt handler to read the interrupt status of each peripheral to discover what is pending. This may seem very crude today, but it is still done to some extent - you might dedicate Rx and Tx interrupts for each I/O peripheral, yet combine all the error/overflow interrups for everything (since any of these mean game-over).

The trade-off between software and dedicated hardware handling of features is one example of how changing implementation costs can influence design decisions over time.

Sean Houlihane
  • 1,698
  • 16
  • 22
  • What I don't understand is, without a vectored interrupt controller, which is from my understanding something the ARM7 doesn't / didn't have, how do we handle multiple interrupts, more than 2 – Engineer999 Feb 23 '18 at 09:57
  • @Engineer999 Updated. – Sean Houlihane Feb 23 '18 at 10:06
  • Ok, so my understanding with ARM7 , the same vector is used for all IRQ interrupts. After receiving the interrupt, our ISR has to check hardware registers to see what actually caused the interrupt and then proceed? With a vectored interrupt controller, a dedicated vector is used for each interrupt? – Engineer999 Feb 23 '18 at 10:12
  • Does it also mean that on ARM7, the interrupt handler has to be reentrant? Thanks – Engineer999 Feb 23 '18 at 10:42
  • Yes, but I think even a vectored implementation in ARM7 shares a common handler (dedicated vector address input came later). Yes, you probably will find a reason to need a re-entrant handler. I remember this being non-obvious to implement, even for validation code. – Sean Houlihane Feb 23 '18 at 10:48
  • @Engineer999 The plus side of the common IRQ is you can opt to have or not have re-entrant handlers depending on whether you want complexity for lower IRQ latency on high priority interrupts. But the FIQ is another way to achieve this. In some case you have vectors on vectors. Ie, a USB IRQ might have several device IRQs read from the USB controller to get to an actually IRQ routine. – artless noise Jul 30 '19 at 22:26