ISR to thread

[Steve Holle]

That's exactly what I was looking for.  I think I need an event task 
because I need to read from a queue and send data out in synchronization 
with receiving.

Thanks for the help.

At 06:08 PM 12/20/2004, Ian Caddy wrote:
>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
>
>Steve Holle
>Link Communications, Inc.
>1035 Cerise Rd.
>Billings, MT  59101
>sholle at link-comm.com