EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

ARM Interrupts

Started by Andrew Blackburn July 14, 2006
Hi there

Looking at several processors at the moment but ARM7 and Coldfire in 
particular.  I like the popularity of ARM and associated tools, but cant get 
over the fact that the interrupt structure within them (only two priority 
levels) is pants.  Coldfire has 7 or 8 nestable levels.

I would appreciate anyones view on this.

Cheers

Andrew


Andrew Blackburn wrote:
> Hi there > > Looking at several processors at the moment but ARM7 and Coldfire in > particular. I like the popularity of ARM and associated tools, but cant get > over the fact that the interrupt structure within them (only two priority > levels) is pants. Coldfire has 7 or 8 nestable levels. > > I would appreciate anyones view on this.
Please remember thet the ARM is a processor core only. It is usually embedded as part of a larger chip containing a bunch of necessary peripherals, including an interrupt controller. For examples, get the data for Atmel AT91 series chips. The need for several nested interrupt levels usually comes from an attempt to avoid a thread scheduler or attempt to do wrong things in the interrupt service. -- Tauno Voipio tauno voipio (at) iki fi
On Fri, 14 Jul 2006 20:04:18 GMT, "Andrew Blackburn"
<an.blackburn2@ntlworld.com> wrote:

>Hi there > >Looking at several processors at the moment but ARM7 and Coldfire in >particular. I like the popularity of ARM and associated tools, but cant get >over the fact that the interrupt structure within them (only two priority >levels) is pants. Coldfire has 7 or 8 nestable levels. > >I would appreciate anyones view on this.
Look on the freescale site for some app notes on the MAC7xxx series MCUs. There is an app note explaining how to do nested interrupts with the ARM. Their ARM controllers, as has most of their other families, a very capable interrupt controller. Regards Anton Erasmus
> Looking at several processors at the moment but ARM7 and Coldfire in > particular. I like the popularity of ARM and associated tools, but cant > get over the fact that the interrupt structure within them (only two > priority levels) is pants. Coldfire has 7 or 8 nestable levels. > > I would appreciate anyones view on this.
The ARM7 itself is only a processor core and does not include an interrupt controller. Most (all?) devices using the core have an external interrupt controller that is priorities to some level. There are also some good app notes on nesting interrupts. If you download some of the Atmel sample programs for their SAM7 series then you can see the interrupt entry and exit code they use. The Cortex-M3 on the other had has an integrated interrupt controller which is fully featured. Regards, Richard. http://www.FreeRTOS.org *Now for ARM Cortex-M3!*
>The need for several nested interrupt levels usually >comes from an attempt to avoid a thread scheduler or >attempt to do wrong things in the interrupt service.
No, it comes from trying to use a processor to do real-time things. Why are you saying he is trying to avoid using a scheduler? Maybe he is trying to do something useful in the real world like count pulses from a flow meter. Man, what has happened to "embedded" engineering? It is like handling interrupts is some kind of foreign thing. Lou
Mr. C wrote:
>>The need for several nested interrupt levels usually >>comes from an attempt to avoid a thread scheduler or >>attempt to do wrong things in the interrupt service. > > > No, it comes from trying to use a processor to do real-time things. > Why are you saying he is trying to avoid using a scheduler? Maybe he > is trying to do something useful in the real world like count pulses > from a flow meter. Man, what has happened to "embedded" engineering? > It is like handling interrupts is some kind of foreign thing. > > Lou
I've been handling hard real-time with single level interrupts for over 40 years now. The trick is to in the interrupt service only handle the immediate attention to the interrupt request line and leave the data processing to a high-priority thread triggered by the interrupt handler. To have the threads, you need a scheduler (or at least a context switcher). Interrupt handling is OK, but you have to get you of it ASAP, to not block the other interrupts for a too long time. All the multi-level interrupt constructions I've seen actually attempt to do operations belonging to the peripheral handling threads in the interrupt routines. This gives little or no advantage to a construction with the handlers in the associated threads. A single-level interrupt system is simpler in the hardware, and that matters pretty often in embedded systems. -- Tauno Voipio tauno voipio (at) iki fi
Tauno Voipio wrote:

> Mr. C wrote: > >>> The need for several nested interrupt levels usually >>> comes from an attempt to avoid a thread scheduler or >>> attempt to do wrong things in the interrupt service. >> >> >> >> No, it comes from trying to use a processor to do real-time things. >> Why are you saying he is trying to avoid using a scheduler? Maybe he >> is trying to do something useful in the real world like count pulses >> from a flow meter. Man, what has happened to "embedded" engineering? >> It is like handling interrupts is some kind of foreign thing. >> >> Lou > > > I've been handling hard real-time with single level interrupts > for over 40 years now.
That's impressive - what processor were you using in 1966 ? :) -jg
Jim Granville wrote:
> Tauno Voipio wrote: > >> Mr. C wrote: >> >>>> The need for several nested interrupt levels usually >>>> comes from an attempt to avoid a thread scheduler or >>>> attempt to do wrong things in the interrupt service. >>> >>> No, it comes from trying to use a processor to do real-time things. >>> Why are you saying he is trying to avoid using a scheduler? Maybe he >>> is trying to do something useful in the real world like count pulses >>> from a flow meter. Man, what has happened to "embedded" engineering? >>> It is like handling interrupts is some kind of foreign thing. >>> >> >> I've been handling hard real-time with single level interrupts >> for over 40 years now. > > > That's impressive - what processor were you using in 1966 ? :)
The first one was an IBM 1710, an IBM 1620 with an interrupt line. The second one was built at the Helsinki University of Technology, called Reflac. It had a built-in 4 level interrupt system, and it was built for hard real-time. Of course, the times were remarkably longer than what we are considering now. About 1/3 of Reflac was soldered by me. -- Tauno Voipio tauno voipio (at) iki fi
Andrew Blackburn <an.blackburn2@ntlworld.com> wrote:
> Hi there > > Looking at several processors at the moment but ARM7 and Coldfire in > particular. I like the popularity of ARM and associated tools, but cant get > over the fact that the interrupt structure within them (only two priority > levels) is pants. Coldfire has 7 or 8 nestable levels. > > I would appreciate anyones view on this.
Most ARM implementations include third-party interrupt controllers that give prioritisation (or at least arbitration). Very few designs actually *need* multi-level interrupts -- IMHO they encourage the development of sloppy code, running things that should really be task bodies at above user level. The job of an ISR is to service the interrupt source and get back down to user level for real work to be done ASAP. Unfortunately, baroque interrupt controllers feature on too many CPUs these days, and "because it's there", fully exploiting them becomes a tick-list feature for RTOSes. I've seen designs where the customer demanded a complex multi-level nested interrupt scheme in the OS, then when it turned out to be slow (duuuuh, surprise!) managed to design everything elegantly using only single-level interrupts. A plethora of priorities isn't an excuse for abandoning good design. pete -- pete@fenelon.com "That is enigmatic. That is textbook enigmatic..." - Dr Who "There's no room for enigmas in built-up areas." - N Blackwell
Pete Fenelon wrote:
> > Very few designs actually *need* multi-level interrupts -- IMHO they > encourage the development of sloppy code, running things that should > really be task bodies at above user level. The job of an ISR is to > service the interrupt source and get back down to user level for real > work to be done ASAP. > > Unfortunately, baroque interrupt controllers feature on too many CPUs > these days, and "because it's there", fully exploiting them becomes a > tick-list feature for RTOSes. > > I've seen designs where the customer demanded a complex multi-level > nested interrupt scheme in the OS, then when it turned out to be slow > (duuuuh, surprise!) managed to design everything elegantly using only > single-level interrupts. > > A plethora of priorities isn't an excuse for abandoning good design. >
If i'm reading this correctly, not sure I agree with all of that. Coming from a time in micro design where you had only wire or irq and nmi, the problem is that you can execute a page of code just to get to the device that caused the interrupt, which is not very helpfull. The good designs, imho, are the ones that have fully vectored interrupts and priority levels that can be assigned to the different on and off chip peripherals via a register bitmap, in a user preferred order. This provides the best response time and allows high priority devices like scheduling timers to be set to a higher priority than serial drivers etc. It's also good for code modularity... Chris -- Greenfield Designs Ltd ----------------------------------------------------------- Embedded Systems & Electronics: Research Design Development Oxford. England. (44) 1865 750 681

The 2024 Embedded Online Conference