Real-time Operating Systems (RTOS) are becoming a necessary component that most embedded software developers need to use in their applications. Developers who were once traditional bare-metal developers are starting to transition to using an RTOS as their microcontrollers move to 32-bit architectures and as their devices are starting to connect to the Internet. Whether you are just starting to use an RTOS or have been for years, there are several challenges that developers face when using an RTOS.
Challenge #1 – Deciding When to Use an RTOS
The first and foremost challenge that bare-metal developers face is deciding when to use an RTOS. The fact is, there is a lot that can be done by developers to emulate preemptive scheduling before needing to make the switch. So, what are a few key indicators that an RTOS is the right way to go? Below are several questions a developer should consider:
- Does the application include a connectivity stack such as USB, WiFi, TCP/IP, etc.?
- Will the systems time management be simplified by using an RTOS?
- Will application management and maintenance be improved if an RTOS is used?
- Is deterministic behavior needed?
- Do program tasks need the ability to preempt each other?
- Does the MCU have at least 32 kB of code space and 4 kB of RAM?
If the answer to most of these questions is yes, then odds are using an RTOS will help simplify application development.
Challenge #2 – Setting Task Priorities
Selecting task priorities can be a challenge. Which task should have the highest priority? The next highest? Can the tasks even be scheduled? These are the questions that often come into the minds of developers working with an RTOS. I’ve seen quite a few developers who simply appear to randomly assign priorities based on how important they feel the task is. Selecting priorities in this manner is a recipe for disaster. Developers should start by using rate monotonic scheduling to get a general feel for whether their periodic tasks can be scheduled successfully. RMS assumes that tasks are periodic and don’t interact with each other so it only serves as a starting point but can get developers 80% of the way to the finish line. After that, developers can use trace tools to observe how their system behaves and make fine tuned adjustments.
Challenge #3 – Debugging
Debugging an embedded system is a major challenge. Developers can spend anywhere from 20% - 80% of their development cycle debugging their application code with averages typically being around 40%. That is a lot of time spent debugging. Using an RTOS can complicate debugging. RTOSes can introduce problems such as priority inversion, dead-lock, and task jitter to name just a few. Developers who are new to using an RTOS probably don’t realize there are entirely new debugging techniques such as tracing that can be used to debug their system. These tools can record when tasks start and end execution and when events occur such as data being placed in a message queue or a mutex being locked. Tracing tools can even be used to verify that the application is executing as expected. Needless to say, debugging is a big issue that every development team is facing and needs to tackle.
Challenge #4 – Managing Memory
An important challenge for developers is managing memory. There are several layers to memory management when using an RTOS. First, developers may need to configure their RTOS to minimize code size if they are using a resource constrained device. Usually RTOS optimization will require adjusting the RTOS configuration file to disable features that use a lot of code space or RAM. Second, developers need to properly manage their RTOS objects and how they allocate memory in their system. Using the heap and byte pools can result in non-deterministic behavior along with memory fragmentation. Using the RTOS default stack size can result in using too much RAM, or worse, a stack overflow. These issues can be solved by performing a worst case stack analysis and by using block memory pools, but that doesn’t make the issues trivial.
Challenge #5 – The Learning Curve
Developers who are switching from bare-metal coding techniques into an RTOS environment often struggle with learning about RTOSes. There are a lot of great materials on the web and in books that give ideas about the major RTOS objects and how to use them, but having a theoretical knowledge of an RTOS application is one thing. Designing and implementing a real application and fighting through all the nuances and issues is another. Developers making the transition should pick up their favorite development kit, a port of the RTOS they are interested in, and then start designing something simple in order to stretch their legs and shrink the learning curve.
Whether you are new to using an RTOS or are a seasoned veteran, as developers we face very similar challenges when designing and implementing our RTOS-based applications. As system complexity increases, the need to be an expert at using an RTOS is going to be a requirement for every embedded software engineer.
ESC Minneapolis is Back!
The Embedded Systems Conference (ESC) is back in Minnesota and it’s bigger than ever. Over two days, Nov. 8-9, 2017, receive in-depth education geared to drive a year’s worth of work. Uncover software design innovation, hardware breakthroughs, fresh IoT trends, product demos, and more that will change how you spend time and money on your next project. Click here to learn more!
Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com/, and sign-up for his monthly Embedded Bytes Newsletter.