This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Virtual interrupts?
- From: Tom Schouten <tom at zwizwa dot be>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 12 Oct 2011 09:25:14 -0400
- Subject: [ECOS] Virtual interrupts?
Hello List,
I'm using an AT91SAM7's PIO IOC interrupts to receive interrupts from an
external source.
However, there are only 2 interrupt sources of the 32 in total that are
related to the PIOs:
#define CYGNUM_HAL_INTERRUPT_PIOA 2
#define CYGNUM_HAL_INTERRUPT_PIOB 3
Each one needs to handle 32 pins, so to use some of these pins as
interrupt input some decoding needs to be done (which pin + which edge?)
before control can be passed to another ISR/DSR.
From my limited knowledge it seems however that it is not possible to
"fake" an interrupt, i.e.
#define CYGNUM_HAL_INTERRUPT_VIRTUAL0 33
#define CYGNUM_HAL_INTERRUPT_VIRTUAL1 34
such that these 33 and 34 vectors can be used in
cyg_drv_interrupt_create() of some eCos driver.
The reason I'd like to do it this way is to not have to patch drivers
with an ad-hock trigger mechanism that relies on the GPIO pin decoding
mentioned above. I just want to pass one of the virtual interrupts to
the first argument of cyg_drv_interrupt_create().
My guess is that the suggested virtual interrupt approach above does not
work. If so then my question is: Is there a preferred way to do this?
The solution I use now is an ad-hoc mechanism that essentially calls a
driver's DSR from the DSR of the PIOA or PIOB DSRs but it requires
driver source modification. So I'm not asking "can it be done?" but
"can it be done in a clean way?".
Cheers,
Tom
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss