ISR to thread

[Ian Caddy]

Hi Steve,

It is hard to provide example code, as it really depends on your 
application.

It you have a task that is doing nothing other than waiting for the ISR 
to tell it to do something, then an event will probably be OK for you.

The thing to remember about events is that you can not queue them.  For 
example if your task is still processing the last event, and the ISR 
generates an event.  The task is still busy and the ISR generates 
another event.  When the task gets around to looking at the event again, 
there is only one.  For this reason, I do not really like events.

So, if your task might not be ready for your ISR, you would be better 
using message queues, with the ISR only sending messages of course... ;-)

In that way, you will be able to queue up multiple things for the 
processing task to look after if it got busy and the ISR could generate 
as many of them as required.

Then if your task is not doing anything else, just wait forever on a queue.

The ISR can then perform a queue send and can even put data in the 
message relavent to the processing.

So, an overall flow for a message queue would be:

processing_task()
{

    while_forever
       wait forever on rtems queue
          do_processing
}

ISR()
{
    remove_interrupt
    place data in message
    send message to processing task
}

I hope this helps.

Ian Caddy


Steve Holle wrote:
> I'm trying to move my ISR processing to a thread and am wondering what 
> the best way to accomplish that task is?
> Should I spawn another thread and block on an event?
> Would a signal be a good choice in this case?
> Does anyone have some sample code I could look at?
> 
> Thanks again.
> 
> Steve Holle
> Link Communications, Inc.
> 1035 Cerise Rd.
> Billings, MT  59101
> sholle at link-comm.com 
>