anonymous wrote on Friday, August 05, 2011:
This may be a stupid question, but the stupidest question is the one unasked; so here goes.
I’ve never used a preemptive system on an embedded controller before, and have been studying the FreeRTOS documentation with interest for most of the day.
I’ve repeatedly seen it claimed that “preemptive multitasking is rarely the best solution for a given problem on embedded controllers”. Which sounds reasonable to me; since preemptive multitasking is a general-purpose solution, it understandably requires additional CPU and memory overhead.
I’m quite familiar with writing code structured as co-routines (or state engines, protothreads, etc.) to support multiple “tasks” on systems without true preemptive tasks. I’ve already written my own co-routine scheduler that handles priorities, mutexes, blocking, etc. And I think that if written properly and specific to the problem at hand, co-routines can perform more efficiently than preemptive tasks.
However, I’m now facing a complex project on a constrained system (PIC24). It will require many simple, time-critical tasks at various priorities which are best implemented as co-routines for best performance. And it will also require two minimum priority tasks, which are way too complex to restructure as co-routines, but would be easily implemented as preemptable tasks.
But in FreeRTOS, co-routines are at a *lower* priority than preemptable tasks, which is the opposite of what I want. While I’m sure I could, with some effort, solve this by integrating another co-routine scheduler into FreeRTOS by setting it up as a high-priority task, I just can’t wrap my head around why FreeRTOS would be set up this way.
Why is FreeRTOS’ default implementation of a faster tasking solution (co-routines) seemingly crippled by placing it at a lower priority than a slower tasking solution (preemptive tasks)? I’m sure there’s something I’m missing, so any insight would be greatly appreciated.