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?