I have been looking into FreeRTOs for a bit now and am really liking it. I come from high level applicaiton coding (OO programming), so the idea of using multiple independant tasks all managed by a central scheduler sounds way better than one large infinite-loop-main-function program (from a code architecture POV). I still though have had some issues trying to understand something. The documentation says that the RTOS tick frequency should range from 100Hz to 1KHz. Any more than that and the task switching overhead becomes non-insignificant, and the individual time slices for each task running at the same priority become smaller (kind of like "thrashing" if I remember my CompSci courses correctly). So that means that the smallest amount of time that we can periodically do something is between 1msec and 10msec. So the question is, what if we have to service a device every msec? Then we’d have to increase our tick frequency to 1KHz and then every tick, the task for that device would execute, effectively starving out the other tasks. If we’re running on a 96Mhz chip (we’re using a STR911), then a task that happens every 1msec shouldn’t effectively hog the whole processor. But I don’t want to really increase my tick rate to like 1MHz because of the aforementioned issues with doing that. Now I know I could handle this task in a hardware interrupt (i.e. configure one of the TIMER peripherals for every 1KHz and handle it right there), but that would mean I have a "task" (i.e. a chunk of firmware algorithm) running outside of the RTOS scheduler…which seems to kind of defeat the purpose? Has anyone run into this before? What is the way you go about handling really frequent items with this RTOS? Thanks for the info and the newbie help :) - Matt

My application is a syringe pump running on an STR750 (60 MHz).  There are about a dozen or so tasks, each independently running a part of the system.  There are also a number of interrupts, and each has a task in the scheduler that manages it.  Communication between the interrupt and associated task is handled by semaphores and/or queues.  The entire system is pretty much interrupt driven so a task gets woken up when an interrupt comes in and, after processing the data, goes back to sleep again.  Otherwise, there’s no task running all the time except for the idle task.  Each task has a different priority so there’s really no task switching on a timer tick unless a function hung off the timer hook (running at 1 msec) needs a task awakened (which is rather rare).  Task switching nearly always happens in an interrupt. I also have a couple of functions hung off the RTOS timer task because they need a constant time base and I’ve used up all the other timers for other things.  The functions do very little to nothing at all in order to keep the overhead down. I even rewrote the IRQ handler to store the task state in the TCB instead of the stack to speed things up.  But that’s another story… IMO, you should always have an interrupt handled by a task.  The interrupt does the absolute minimum it has to and then wakes its parent task to handle the rest. I also have a VERY frequent interrupt that occurs at a rate of up to 150 usec.  I use the fast interrupt (FIQ) for this.  Since it interrupts other interrupts, it’s not allowed to do any FreeRTOS calls.  Communication is done through byte flags instead.  The task is not time intensive so it checks the flag status every 100 msec (it could easily be faster). I hope this helps.  In fact, I hope it’s even remotely on the subject.  Sometimes I get off on a tangent and ramble on…