当使用实时操作系统(RTOS)时，嵌入式开发人员可以在更高的抽象级别上工作，类似于从汇编语言编程到c语言的转变。在这一更高的级别上工作可以更容易地设计复杂的应用程序，但是尽管RTOS降低了应用程序源代码的复杂性，但它并没有降低应用程序本身的固有复杂性。这会使应用程序难以验证和调试。

　　使基于RTOS的开发比编写裸机超级循环应用更困难的是，RTOS任务不是孤立的实体，它们具有可能以意想不到的方式延迟任务执行的依赖性。微妙的编码选择会导致最终产品中难以捉摸的错误或性能问题。当作为一个系统一起执行时，一组看似简单的RTOS任务可能导致惊人复杂的运行时行为;可能有无数的执行场景不可能被测试或代码审查完全覆盖。

　　多任务处理，但控制更少

　　开发人员面临的挑战是，当开发沿着抽象的阶梯向上发展时，调试工具却没有跟上。虽然标准调试工具仍然主要关注断点和单步执行源代码，但可视化跟踪诊断让开发人员能够在系统级别全面了解应用程序的行为。

　　RTOS的主要工作是提供多任务处理，几个任务可以并行执行以实现一个共同的目标。基于RTOS的应用程序的嵌入式开发人员可以保留对任务优先级等参数的一些控制，这反过来支持确定性的实时行为，但他们失去了对更精细细节的控制。例如，程序流在源代码中不再明显，因为操作系统决定在任何给定时刻执行哪个任务。

　　使用RTOS和可视跟踪诊断，开发人员可以在这个更高的抽象级别上工作，并捕获他们的应用程序的定时和同步方面，这是传统调试器根本无法看到的。

　　我们已经确定了这种类型的五个常见实时应用程序错误。

　　l CPU资源匮乏

　　l 振动

　　l 优先级反转

　　l 僵局

　　l 内存泄漏

　　这些只是五个最常见的RTOS开发错误，但代码中可能隐藏着无数其他错误。你可以尝试通过调试来猜测自己的方式，尝试一件又一件的事情来让应用程序正常运行。但要解决这个问题，你需要了解导致它的软件事件的具体顺序，包括应用程序和RTOS之间的交互。传统的调试工具无法提供这种见解。在嵌入式开发中，RTOS跟踪可视化可以被认为是应用程序内部的慢动作视频，它提供了RTOS应用程序按设计运行的信心，是检测和纠正错误的最快方法。