[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