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.
Thanks for the feedback! We have been investigating this at Freescale. At this time kernel isr cannot make mqx function calls. But we are very interested in a software interrupt feature that could be called from kernel isr and make mqx function calls/trigger the scheduler. So, fast entry into kernel isr to do something high priority, then secondary isr to trigger mqx actions.
I'm glad Freescale is looking at implementing this. It will be a great feature. Look at the RTX scheme as a model.
I will tell you that when I did this before under MQX 2.4 in consultation with Precise (calling them a "guerrilla semaphore"), indeed some MQX functions are safe to call within the kernel ISR, sem_post() for instance. No ill effects other than the scheduler does not run upon exit. Any manual invocation of a secondary non-kernel ISR within the kernel ISR rectifies this by forcing the scheduler to run. Should be very easy to implement in Cortex since a large part of the ISR handling tasks now occur in hardware.
In my point of view, I think the _event_set(), _lwsempost() are both safe when call in ISR chain. But one point should be noted is this situation depdend on the way INT_DISABLE has been implemented in psp (cpu specific). In most case, this function will disabled all the interrupt so that such function like _event_set, _lwsempost are ISR safe.
Regarding the request about user kernel isr function, I think this would be the impossible task to MQX supporting this offcially. Because MQX is not support not only for Kinetis, but also for many other arch: Coldfire, PPC, and some arch doesn't have soffware interrupts (like SWI in Kinetis).
Yes, I can see where this capability is PSP specific depending on how the implementation is done.
As stated before, the way RTX handles this in a generic fashion is to invoke the timer tick handler. So even in targets that don't support a generic SWI, certainly the timer interrupt is always available as this is a core service for the OS.
I don't know the details, but I suppose the RTX tick handler is smart enough to know the difference between a tick invoked by timer expiration and one invoked by other means, and that it's able to keep a proper time-base. Or perhaps it just handles aperiodic tick increments.
Anyway, it's a very compelling interrupt model, especially on Cortex, where interrupt handling with priorities is essentially handled in hardware. I think with some minimal effort MQX can accommodate this with the benefit of being able to provide extremely small interrupt latencies.