This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Best structure for multiple devices on one interrupt?
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Brett Delmage <Brett dot Delmage at twobikes dot ottawa dot on dot ca>
- Cc: ECOS mailing list <ecos-discuss at ecos dot sourceware dot org>
- Date: Thu, 06 Jul 2006 04:54:07 -0600
- Subject: Re: [ECOS] Best structure for multiple devices on one interrupt?
- References: <Pine.LNX.4.63.0607052052220.32662@pannier.canbike.ca>
Brett Delmage wrote:
I am running eCos on the LPC2xxx ARM, that has 3 external interrupt pins.
There are 17 devices that can generate interrupts, at rates ranging from
once every 2 ms (with a max allowed service time of 1 ms) to infrequently:
every few seconds or maybe hours or days, when active.
Most of these interrupts exist so that the CPU can maximally sleep to save
power and be woken up when something happens, instead of polling when
there will be little activity. (the high rate interrupt will often not be
active.)
I am wondering about the optimal way to set up the interrupt servicing.
Most of these interrupts come in on one external interrupt pin (EINT0);
two high-frequency ones and power-down request come in on the other input
(EINT2), such that these might receive higher priority or treated as an
FIQ instead of an IRQ -- at a later date. Mixing IRQs and FIQs on an ARM
seems problematic, so I will avoid this for now.
To determine the source of the external interrupt, bit flags in an
external register can be read. Nothing unusual here.
As per the NOTE in section 3.2.3 of the ECOS User Manual, would it be best
to have a single ISR triggerred by the external interrupt, which would
explictly post the correct device-specific DSR after examining the
interrupt status register? e.g. by calling cyg_interrupt_post_dsr
As I understand this, that way, the specific device interrupt can be
masked immediately, allowing other devices to interrupt. Also, If the ISR
examines the interrupt status bits in priority order, then DSRs can be
posted in priority order.
Does this approach make sense, and are there any caveats ?
Are there any examples of this in the repository that I could look at?
I'd extend the notion of HAL interrupts on the platform to explicitly
list all 17 sources. Presumably, each source can be individually
tested/enabled/disabled in various platform registers. Then it's just
a matter of extending the variant routines (in hal/arm/lpc2xxx/var) to
recognize them.
A framework for this exists on the iPAQ platform (sa11x0 ARM variant).
There are no details, but you can see how it can be done.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss