So back in November 2009 I posted an article about my starting to play around with RTOS to grow in my technical knowledge. I must confess something: I haven’t really played with MQX or others as much as I would have liked…at least not during 2010. But then something happened: Freescale’s Kinetis family of ARM microcontrollers was launched and now my worked has forced me (in a good way) to work with the MQX RTOS quite a lot more. It’s been great fun.
In my self-training of MQX I’ve run into basically two ways of doing things. One way is to subdivide all functions into tasks, using all sorts of RTOS goodies like semaphores, priorities and mutexes (is that the right plural? How about mutexii?). This way, as far as I understand RTOS, is the right way to do it, it’s elegant.
On the other hand, I’ve seen code were the author basically creates two or three tasks and then proceeds to manually do the application control manually i.e.: switch-case statements with binary flags and stuff. Almost as doing a bare metal application where the RTOS is only there for the drivers. Correct me if I’m wrong, but, doesn’t that beat the whole purpose of using an RTOS?
My intent is not to criticize whoever writes code that way, I’m mostly interested in considering the caveats of doing the code one or the other way. For example, I can imagine a situation in which going crazy with OS tasks could result in an overly complex system, so probably a balance between tasks and manual control makes most sense. On the other hand, an overly complex system would probably be more the result of improper RTOS usage rather than an RTOS having a chaotic nature (which makes sense, now that I’ve written and read that).
So what’s your take on RTOS software? Do you think all RTOS resources should be exploited as much as possible?
Hi,
I can’t agree with you any lesser. However, sometimes in medium sized projects, there may not be an opportunity for using all the aspects of a RTOS, rather, one may be sometimes using very less number of features of an RTOS. I used to refer such projects to something like “Door bell with a 16 bit microcontroller”.
I agree, many projects do not need an RTOS. My work for many years was precisely in those types of projects. In my previous company there was so much focus no not using an RTOS that we got to a point that the big project could have used an RTOS and even then we didn’t. Guess what? That code became a whole mess to maintain, the state machine became too complex.
On the other hand, using RTOS for every purpose is definitely not a good idea.
For small systems I favour cooperative multitasking with polled tasks. It’s deterministic and lightweight, ideal for constrained systems.
Pre-emptive multitasking with threads, while very powerful, can cause debug nightmares – with race conditions and unrepeatable bugs.
Give me a state machine anyday.