Group Actions
Engagement
  • Author Author: squadMCU
  • Date Created: Date Created
  • Views 577 views
  • Likes 1 like
  • Comments 1 comment
Related
Recommended

More playing around with RTOS, to task or not to task

squadMCU

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

  • I built many a embedded system without a "standard" operating system.  I found that unless you have a large quantity of threads operating in a non determanistic fashion, you can usually get by with a very simple approach using flags and calls.  Part of my "roll your own" approach was dictated by the entire lack of available OS when I began building embedded systems.

     

    When OS options became available, we mostly had to deal with the limitations impossed by the OS rather than the benefits provided by the OS.  Even for production systems, most commercial OS just did not provide enough value added to make it worth using them, not to mention that most wanted a license fee, or as I called it, an extortion fee.

     

    To work out scheduling issues, I developed a simulation that let me model a system and its OS to assess if it could handle the realtime requirements of a given application.  It provided data similar to Rate Monotonic Analysis, but it let you see the more subtle dynamic interactions between multiple processors in either a distributed or parallel environment.

     

    Bottom line, keep it simple.

     

    This does not mean I would dismiss a commercial OS from your project, but for most hobbiest and small projects, they are a lot more overkill than you need.

    As long as you stay focussed upon the data flow and processing requirements of each thread, you can build a very complex multitasking system without incurring onerous delays that some standard OS forces on your implementation to keep your application "portable."

     

    Thanks,

    DAB