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