On 8/5/07, Gary Thomas <[EMAIL PROTECTED]> 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
