[En-Nut-Discussion] Realtime Nut/OS

[Harald Kipp]

Thiago A. Corrêa wrote:
> If we have both, then we will need to ensure that all of the Nut/OS
> API is reentrant, while having it as ( cooperative xor preemptive ) we
> could push the locking of the non-reentrant calls to the app code.

This could be done in steps to keep things as simple as possible in the
beginning. Using mutual exclusion semaphores is the most simple way to
make routines reentrant. On the other hand this also destroys real time
behavior. It doesn't make much sense to wake up a high priority thread
just to recognize, that a required resource is blocked by a low priority
thread. In that sense, the application developer knows better, when to
block which resource for exclusive access.

Right now NutPostEventFromIrq is actually the only call that is allowed
when running in interrupt context. This call is ready to be called from
real time threads as well. It allows to wake up cooperative threads.
Somehow this may allow to more easily implement delayed interrupt
handling, which had been proposed by Duane some time ago, if I remember
correctly.

A special set of critical kernel routines will be required for real time
threads. Some of them _must_ either make use of the existing routines by
handling mutual exclusion on entry/exit (e.g. heap management) or we
need to re-write the existing routines. Or we use different heaps.

> I hope I'm making some sense in here.
> Btw, FreeRTOS allows you to choose preemptive or cooperative, not both.

Yes, they started up with preemptive scheduling and later added
cooperative, which I watched with great interest.

Harald