ARM Interrupts

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