[ECOS] Implementing callback from driver to application

[ECOS] Implementing callback from driver to application

[Mike Sweeney]

I have a custom device driver that needs to invoke a callback function
that is registered by the user's application. I have a 3 level
interrupt service mechanism within my device driver: an ISR, a DSR,
and an interrupt service thread. Basically in my interrupt service
thread I invoke the callback function. This is not a great design
because I don't want to be blocked in my interrupt service thread for
an unknown amount of time. I may have multiple application callbacks
to invoke depending on the device status.

I'm looking for some input on how best to tackle this within eCos. My
design requires the kernel so I can use any sort of kernel services
and am not restricting myself to the driver API. Should my driver have
another dedicated thread that receives mailbox messages from my
interrupt service thread and then calls the callbacks from within its
own context? All ideas are appreciated.

Thanks.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Implementing callback from driver to application

[Gary Thomas]

Mike Sweeney wrote:
> I have a custom device driver that needs to invoke a callback function
> that is registered by the user's application. I have a 3 level
> interrupt service mechanism within my device driver: an ISR, a DSR,
> and an interrupt service thread. Basically in my interrupt service
> thread I invoke the callback function. This is not a great design
> because I don't want to be blocked in my interrupt service thread for
> an unknown amount of time. I may have multiple application callbacks
> to invoke depending on the device status.
> 
> I'm looking for some input on how best to tackle this within eCos. My
> design requires the kernel so I can use any sort of kernel services
> and am not restricting myself to the driver API. Should my driver have
> another dedicated thread that receives mailbox messages from my
> interrupt service thread and then calls the callbacks from within its
> own context? All ideas are appreciated.

Yes, this is the preferred method (threads are quite cheap).
Your driver thread can then call back into the user code, block,
etc, without affecting the rest of the system.

Note: a good usage example of this is the input processing
thread in the FreeBSD networking stack.

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

Re: [ECOS] Implementing callback from driver to application

[Mike Sweeney]

On 8/5/07, Gary Thomas <gary@mlbassoc.com> wrote:
> Mike Sweeney wrote:
> > I have a custom device driver that needs to invoke a callback function
> > that is registered by the user's application. I have a 3 level
> > interrupt service mechanism within my device driver: an ISR, a DSR,
> > and an interrupt service thread. Basically in my interrupt service
> > thread I invoke the callback function. This is not a great design
> > because I don't want to be blocked in my interrupt service thread for
> > an unknown amount of time. I may have multiple application callbacks
> > to invoke depending on the device status.
> >
> > I'm looking for some input on how best to tackle this within eCos. My
> > design requires the kernel so I can use any sort of kernel services
> > and am not restricting myself to the driver API. Should my driver have
> > another dedicated thread that receives mailbox messages from my
> > interrupt service thread and then calls the callbacks from within its
> > own context? All ideas are appreciated.
>
> Yes, this is the preferred method (threads are quite cheap).
> Your driver thread can then call back into the user code, block,
> etc, without affecting the rest of the system.
>
> Note: a good usage example of this is the input processing
> thread in the FreeBSD networking stack.
>

Thanks Gary. I'll check out the code you mentioned.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss