This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Best structure for multiple devices on one interrupt?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]