New White Paper: What makes RTOS development so hard?

Nov 25, 2019 |

When using a real-time operating system (RTOS), embedded developers can work at a higher level of abstraction, similar to the shift from programming in assembly to C. Working at this higher level can make it easier to design complex applications, but while an RTOS reduces the complexity of the application source code, it does not reduce the inherent complexity of the application itself. That can make the application difficult to validate and debug.

What makes RTOS-based development more difficult than writing bare-metal super loop applications is that RTOS tasks are not isolated entities, they have dependencies that may delay task execution in unexpected ways. Subtle coding choices can result in elusive errors or performance issues in the final product. A set of seemingly simple RTOS tasks can result in surprisingly complex runtime behavior when executing together as a system; there can be countless execution scenarios that are impossible to fully cover by testing or code reviews.

Multitasking but less control

The challenge for developers is that when development moved up the abstraction ladder, debugging tools didn’t keep up. While standard debugging tools are still mostly focused on breakpoints and single stepping through source code, visual trace diagnostics gives developers full insight into the application’s behavior at system level.

The main job of an RTOS is to provide multitasking, where several tasks can execute in parallel to achieve a common goal. Developers of RTOS-based applications can retain some control over parameters such as task priorities, which in turn enables deterministic real-time behavior, but they lose control over the finer details. For instance, program flow is no longer apparent from the source code, since the operating system decides which task to execute at any given moment.

Jitter, Deadlock and friends

Using an RTOS and visual trace diagnostics, developers can work at this higher abstraction level and capture timing and synchronization aspects of their application that traditional debuggers simply cannot see.

We have identified five common real-time application bugs of this type.

  • CPU starvation
  • Jitter
  • Priority inversion
  • Deadlock
  • Memory leaks

Download our new white paper The Five Most Common RTOS Development Bugs—And How to Spot Them to read more about how Tracealyzer can assist you in finding and fixing these bugs.

And remember: bugs found in the lab are far cheaper to fix than bugs discovered in the field.