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: Serial channel sharing the same ISR


Sergei Gavrikov a Ãcrit :
On Thu, 1 Jul 2010, Nicolas FLAVEN wrote:

Sergei Gavrikov a Ãcrit :
On Wed, 30 Jun 2010, Nicolas FLAVEN wrote:

Hello,

I would like to know how i can setup x serial channel that share the
same interrupt vector.

My probleme is that my serial channel have to share the same interrupt
vector and I want that the ISR find which channel is interrupting but
if I use SERIAL_CHANNEL_USING_INTERRUPTS with the corresponding
DEVTAB_ENTRY this will overwrite the adresse of the ISR attache to the
vector and the data.

Should I care about it ? Is the " chain all interrupts together"
options the solution to allows for multiple ISR/DSR pairs to be
registered for the same interrupt vector.

Hi Nicolas,


Look at a comment in hal_arbiter.h (hal/common/*/include/hal_arbiter.h).
I hope you will get the idea.


Sergei


Hi


I understand that CYGIMP_KERNEL_INTERRUPTS_CHAIN and
CYGIMP_HAL_INTERRUPTS_CHAIN will produce ALL my ISR to be chain ON
vector. Is that right ? Does it depend of the target ( there it's an
lpc2294 ) ?

Nope. That's target independent code.


I don't really understand the arbiter process comment (looking at
mpc8xx example don't help me too): for me different source call
different isr.  In my case CYGNUM_HAL_INTERRUPT_EINT3 is the shared
vector, SERIAL_CHANNEL_USING_INTERRUPTS is used to attach 8
pc_serial_ISR through pc_serial_funs.  How can i make the difference
between the 8 channel to process the right data in  hal_call_isr ?

First way. You can use chained interrupts, i.e. to register more than one ISR with on the same vector (Note: that will be their concern to return HANDLED properly).

Second way is that arbiter. The arbiter can either fulfill interrupt
decoding to know the real interrupt source and call *needed* ISR or
iterate through out all those ISRs likes chaining ISRs handle itself.

As you see, in both cases you must have a way to decode ISR source.

Well, that's theory. I had not experience with it on real hardware.
Perhaps, someone will add/correct me.

Sergei
Thanks for the help I will investigate more

Nicolas

--
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]