Archive for the ‘RTOS Multithreading’ Category

Idling along, (or what to do in the idle task)

Sunday, April 14th, 2013 Nigel Jones

If you are using an RTOS in your latest design then no doubt you have an idle task. (Most of the time, the idle task is explicit and is the user task with the lowest priority; sometimes it’s built into the RTOS). It’s been my experience that the idle task is an interesting beast. On the one hand it is what gets executed when there’s nothing else to do, and thus inherently contains nothing directly related the product. On the other hand it’s this wonderful resource that you can exploit to do all sorts of interesting things to improve your product without having to worry too much about it impacting the running of your product.

With that being said, here are some suggestions for what your idle task can do, starting with one thing it shouldn’t do.

Do Nothing

If your idle task consists of a do-nothing loop, then you are almost certainly missing an opportunity. Hopefully the suggestions below will serve to spark your creative juices.


In any RTOS based design, the idle task should play a role in the overall watchdog supervisor. Without going into a treatise on watchdog design, suffice it to say if the idle task isn’t being run frequently then you’ve got a problem. Thus if the idle task doesn’t feature in your watchdog supervisor then you are doing something wrong. Note that if the idle task is featured in your watchdog, then it doesn’t necessarily mean you are doing it right either!

Power Save

For power constrained systems, the idle task is usually the place to put the microprocessor to sleep and / or indulge in other power saving strategies. I often find that my idle tasks consist of some of the features described here, plus power save. In other words, the idle task takes care of some housekeeping and then takes a nap.

Load calculation

Used in conjunction with hardware timers and the task switch hook function, it’s normally possible to construct a system that gives a decent indication of both overall CPU load and also the CPU utilization of each of the tasks. The idle task isn’t a bad place to do all the calculations. I find this a very useful diagnostic aid as I’m developing a system. Once you are done using it as a development aid, with a bit more work it can be modified to be part of your overall watchdog strategy, in that it can provide useful information about how tasks are (mis)behaving.

Flash Check

Just about every embedded system I’ve looked at in the last decade or two performs a CRC check on program memory on start up. However, if you are designing a system that is safety critical and / or expected to run a long time between power cycles, then you should seriously consider running a Flash CRC check in the idle task. Because no writing of memory is involved and one is instead reading memory that is supposed to be constant, there are are no real race-conditions to worry about and thus there’s no need to be entering critical sections to perform the reads. Of course if you are using an MMU or MPU then things might get a little more challenging. Naturally such a challenge is nothing for a reader of your ability! [As an aside, one of my electrical engineering professors used to say to me, “Nigel, this is nothing for a man of your ability!” One is of course simultaneously flattered, irritated and motivated. I’ve never forgotten it.]

RAM Check

This is of the course the evil twin to the Flash check. However this time you need to perform both reads and writes from locations that are being used by higher priority tasks and interrupts. You can of course only do this safely by executing a suitable lock / unlock procedure on each RAM location. Now doing this in the idle task could seriously change your system’s response time, so you need to think very seriously about how to structure such a test. A good starting point is to do just one locked read / write per idle task invocation. Of course if that results in a 10 year RAM test on your system, then you’ll need to rethink the strategy.

If you have other good ideas for idle task work then please leave them in the comments.

Knowledge versus Understanding

Wednesday, October 11th, 2006 Nigel Jones

Every month or two a ‘Technical Recruiter’ from one of the larger placement companies calls me up to see if I’m available for work. Most of the time I’m not, and so the conversation terminates quite quickly. However, once in a while I am available, and so the inevitable request for an updated resume is made. After sending an updated resume, the ‘Technical Recruiter’ calls back to discuss what you have to offer.

Well, for the first time in several years I recently went through this rigmarole. The conversation with the recruiter was both illuminating and yet rather depressing. To paraphrase, the conversation went like this:

Recruiter: “What RTOS experience do you have?”

Me: “VxWorks, MicroC/OSII, Embedded Linux, various bespoke systems”

Recruiter: “No others? ”

Me: “Isn’t it more important that someone understands the benefits and limitations of an RTOS rather than knowing the particular API of a specific RTOS?”

Recruiter: After a long pause. “Our clients like someone that can hit the ground running.”

I see two possibilities here.
1. The ‘technical recruiter’ has no technical knowledge and is nothing more than a matcher of acronyms and buzz words.
2. His clients really are saying to him, we need someone with experience of XYZ RTOS.

If it’s the latter, then it appears that knowledge is a more highly prized commodity than understanding. Personally, given the choice between someone that knows an RTOS API and someone that really understands priority inversion, can discuss the pros and cons of RMA as a scheduling algorithm, and can explain the implications of making an RTOS call from within an ISR, then I’d take the latter any day. Of course, one might claim that an experienced user of XYZ RTOS should be aware of these sorts of issues. However, in my experience, large swathes of the folks out there using an RTOS really don’t have a clue about what it’s doing for them – and what it’s costing them.

Thus my point is this. Next time you are looking for help, think about what you’d like the person to understand – as well as what they should know. I suspect you’ll end up with better help.