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?

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.

 

 

Continue reading on EmbeddedStories blog