[En-Nut-Discussion] interrupt context and API safety

William Baker bbaker at priefert.com
Fri Jan 27 18:22:03 CET 2006


I am attempting to use an async timer to awaken an OS level thread.  The 
async timer handler posts an event to the event queue using 
NutEventPost()...and that is probably a no-no.  All I know about API 
calls from an async timer handler is what the documentation states:

 > The callback function is executed in interrupt context at a very high 
priority. It
 > can call only a limited set of functions and must return as soon as 
possible.

Which makes sense, although exactly what is meant by "limited set of 
functions" is not well defined.  So I tried it, and my app works -- for 
a while.  As the app runs, one eventually sees the kind of memory 
corruption you would expect from async threads stepping on each other or 
random pointers.

The app has two time critical threads that need to kick off every 10ms 
to send data out the serial ports.  It also has threads that maintain 
active communication with an ethernet device, and provides 
setup/diagnostics/configuration via http threads.

Would it be sufficient to put a "disable-interrupt/enable-interrupt" 
around some OS functions to make them safe?  It seems like the 
disable/enable interrupt macros in AVRGCC have changed recently.

Ideas are welcome to either make the async timer work reliably or an 
alternate approach.

bbaker




More information about the En-Nut-Discussion mailing list