I wish to create and use a number of MQX kernel interrupts (i.e. interrupts that do not run through the MQX interrupt sub-system by default) due to high frequency and low latency required in my application.
The ISR handlers will be writing to ring buffers and on occasion will need to signal another user MQX task directly or indirectly within these interrupts. Questions:
- Is it safe to call the standard OS safe ISR calls like _event_set(), _lwsempost(), etc with-in a kernel ISR to signal an event?
- Is there a "standard" or "supported" MQX way to invoke a secondary interrupt handler that would force the scheduler to run upon exiting the user defined kernel interrupt?
In the past I've done this type of thing on MQX2.4/ARM7 by invoking a SWI within my kernel interrupt. This had the side effect of forcing the scheduler to run.
The reason I bring this up is because it would be nice to be able to run an interrupt handling model similar to ARM's RTX. In RTX every user interrupt is a kernel interrupt. But it is up to the user ISR to explicitly call a function like _event_set_isr() or sempost_isr() when signaling is needed, with the only difference being that these isr OS functions force the tick handler to run once the first interrupt exits.
If you think about it, this explicit invocation of the schedule only when needed is extremely efficient and fast. You run the scheduler only when needed instead of every ISR. In principle this is easily achieved in MQX, but I'm just looking for a standardized methodology to do it that is officially supported by MQX.