几十年前，嵌入式行业将重心从汇编转移到了C编程。更快的处理器和更好的编译器允许提高抽象层次，以提高嵌入式开发效率和质量。

我们现在正处于固件开发技术的新的重大转变之中。实时操作系统(RTOSes)的广泛使用代表了第三代嵌入式软件开发。RTOSes引入了一个新的抽象层次，支持更复杂的应用程序，但也不是没有复杂性。

RTOS是一种用于嵌入式和物联网应用的快速、确定性操作系统。这些操作系统通常非常小，因此适合在微控制器(MCU)中使用。RTOS的主要工作是提供多线程，从而允许将软件功能分成多个“并行”程序，这些程序被称为“任务”RTOS通过快速切换正在执行的任务来制造并行执行的假象。与通用操作系统不同，RTOS让开发人员能够完全控制多线程，因此支持确定性的实时行为。

使用RTOS有很多好处，但它本身并不是一个解决方案，而且会带来新的挑战。许多开发商已经一头扎进了RTOS的设计中，但往往没有完全意识到其中的含义；他们使用的开发工具对基于RTOS的开发没有适当的支持；由于这个原因，在嵌入式开发中，他们可能在调试和验证方面遇到了很大的困难。

RTOS趋势
RTOS自20世纪80年代初就已经存在，但是由于多种原因，它们变得越来越普遍。嵌入式应用变得越来越复杂、互联和事件驱动，使用高级外设和中间件堆栈，所有这些都需要并行管理。使用RTOS大大简化了这一过程。使用RTOS的替代方法是使用自定义状态和逻辑自己实现某种执行控制。对于更复杂的应用程序，这往往会变得复杂，容易出错，并且难以维护。通过使用RTOS，你将执行控制委托给高度优化的RTOS内核，该内核已经过全面的测试并在使用中得到验证。

虽然使用RTOS意味着较小的处理开销，但基于RTOS的设计通常比传统的超级循环设计更有效。这是因为RTOS任务可以在不浪费处理器时间的情况下等待激活事件，并且由于较短的ISR(中断服务例程)和抢先调度，响应时间可以更快。此外，今天的MCU通常具有快速的32位内核和大量的闪存和RAM内存，使RTOS足迹不再是一个问题。

在嵌入式开发中，免费提供的开源实时操作系统越来越受欢迎，这使得基于RTOS的设计更容易获得，并创建了大型用户社区——一种作为正反馈循环的“临界质量”。RTOS不再像10-15年前那样被大肆宣传，而是被广泛用于各种嵌入式应用中。倡导基于RTOS的设计的不仅仅是RTOS的商业供应商；现在，许多MCU厂商的软件开发套件中都包含了RTOS。

尽管RTOS并不是解决所有问题的“灵丹妙药”，而且可能不适合某些系统，但实时操作系统的日益使用无疑是当今的一个主要趋势，而且可能会继续下去。

使用RTOS的挑战
那么是什么让RTOS如此特别，可以被称为固件设计中的第三代呢？RTOS是一个非常特殊的软件组件，因为它控制了程序的执行，并以任务的形式带来了新的抽象层次。当使用RTOS时，程序的控制流从源代码中不再明显，因为RTOS决定在任何给定时刻执行哪个任务。这是一个根本性的变化，类似于从汇编到C编程的转变，因为它允许使用更高的抽象来提高生产率，但也意味着对细节的控制更少。

这是一把双刃剑。它可以使设计复杂的应用程序变得更加容易，但是这些应用程序随后可能会变得难以验证和调试。虽然RTOS可以降低应用程序源代码的复杂性，但它不会降低应用程序本身固有的复杂性。当作为一个系统一起执行时，一组看似简单的RTOS任务可能导致惊人复杂的运行时行为。

如前所述，RTOS本身并不是一个解决方案，对于不小心的人来说还有很多陷阱。嵌入式开发人员需要确定任务如何使用RTOS服务进行交互和共享数据。此外，开发人员需要决定重要的RTOS参数，如任务优先级(相对紧急程度)，这些参数可能远非显而易见。即使你已经根据基于RTOS的设计的最佳实践编写了所有代码，系统的其他部分(内部或第三方组件)也可能运行在相同的RTOS环境中，但可能不遵循相同的原则。

使基于RTOS的设计变得困难的根本问题是RTOS任务不是孤立的实体。任务之间至少有一种依赖关系——它们共享的处理器时间。使用固定优先级抢先调度，较高优先级的任务可以在几乎任何时间点醒来并接管执行，从而延迟较低优先级任务的执行，直到所有较高优先级的任务都已完成。

其他类型的共享资源(如全局数据或硬件外设)也会导致任务之间的依赖性，因为必要的同步可能会阻止任务在需要时执行。如果设计不正确，这可能会导致不可预测的延迟，与任务优先级无关。

当高优先级任务(任务H)试图访问当前正被较低优先级任务(任务L)使用的共享资源(例如通信接口)时，可能发生优先级反转。通常，任务H会被阻塞一小段时间，直到任务L返回共享资源。如果此时一个中等优先级的任务(任务M)恰好抢占了任务L，就会发生优先级反转。任务H的阻塞变得更长，这都是因为一个不相关的任务具有更低的调度优先级。在NASA探路者的例子中，这导致看门狗定时器超时并重置系统。

像日程安排和共享资源这样的任务依赖性受时间的影响；例如执行时间和输入时间。这种定时属性在源代码中是不可见的，并且往往会根据系统状态和情况而变化。在嵌入式开发中，这使得仅仅从源代码来预测基于RTOS的系统的实时行为几乎是不可能的。取决于许多因素，任务可能执行得比预期的慢，有随机的意外延迟，或者根本不执行。即使系统看起来像在实验室中预期的那样运行，也可能有无数其他执行场景在时间上有或多或少的显著差异，其中一些可能会导致问题。在最糟糕的情况下，系统通过了测试，但是对于你的客户来说，系统会在随机的情况下崩溃。这样的问题在系统级测试中很容易被忽略。此外，除非你能够获得与问题相关的详细诊断信息，否则重现它们进行分析可能是一场噩梦。

调试基于RTOS的系统
想在开发的时候在同一个抽象层次上进行调试是很自然的。当嵌入式行业从汇编转向C编程时，调试工具很快就提供了源代码级别的调试，从而使C代码视角成为正常的调试视角。然而，调试工具并没有响应RTOS的趋势而发展到任何显著的程度。一些调试器已经更新了“RTOS感知”功能，允许你在调试时检查RTOS对象(如任务和信号量)的状态。但这些是“第二代”源代码级调试器的增量改进，严格关注源代码和运行/暂停/单步调试。仅使用传统的源代码级调试器来调试基于RTOS的系统相当于在用c编程时使用汇编级调试器。

要完全理解基于RTOS的系统的运行时行为，你需要在RTOS级别观察实时行为的能力；即具有RTOS感知的跟踪工具。在嵌入式开发中，这是对传统调试工具的补充，提供了RTOS级别的时间线，极大地方便了调试、验证和性能优化。传统调试器很像显微镜，用于检查任务中的详细执行，而跟踪更像实时执行的慢动作视频。

有两种类型的跟踪，目的略有不同：硬件生成的和软件生成的。硬件生成的跟踪在源代码或汇编级别提供了详细的执行跟踪，但很少或没有RTOS意识。为了记录高速数据流，在处理器和板上都需要先进的跟踪硬件和合适的跟踪支持。这种跟踪往往会在较低的抽象级别产生大量数据，这可能难以理解，并且仅限于处理器中实现的跟踪功能。硬件生成的跟踪主要用于覆盖率分析和特别棘手问题的调试，在这种情况下需要指令级跟踪。

软件生成的跟踪意味着将跟踪代码片段添加到目标软件中，目的是记录RTOS中的重要事件，也可以选择记录应用程序代码中的重要事件。你通常不需要自己插入RTOS跟踪代码，因为这通常是由RTOS或工具供应商提供的。使用软件跟踪，任何软件事件都可以被记录，包括任何相关数据，基本上可以在任何处理器上记录。缺点是跟踪代码的开销，但现代32位MCU上的RTOS级跟踪只需要处理器时间的百分之几，因为需要记录的数据相对较少，并且跟踪的事件不是很频繁。这使得使用通用调试接口或其他接口(如USB或TCP/IP)连续传输数据成为可能。低数据速率也允许跟踪RAM缓冲器。仅仅几千字节就足以获得最近事件的像样的跟踪。这样，追踪也可以在实验室之外使用；例如在现场测试或部署操作期间。

可视化对于理解痕迹至关重要。在嵌入式开发中，许多嵌入式系统都有或多或少的循环行为，因此大多数跟踪数据都是“正常”行为的无关重复。有趣的部分通常是异常，但是如果你不知道具体要找什么，它们可能很难找到。然而，假设数据被正确可视化，人脑在识别视觉模式和异常方面是非凡的。

虽然一些工具可以将RTOS轨迹显示为经典的甘特图，但是这种可视化不适合在同一视图中显示其他事件；例如API调用或用户登录。但是，垂直执行跟踪可以使用指向图形执行跟踪的文本标签来显示此类事件。此外，仅仅显示执行跟踪是非常有限的，因为可以从RTOS跟踪中获得更多的信息。例如，任务和ISR的交互可以表示为依赖图，还可以显示关注其他相关RTOS对象(如信号量、队列和互斥体)的跟踪视图。

结论
RTOS趋势在嵌入式行业非常明显，这是有充分理由的。由于日益复杂和互联的应用程序，越来越多的开发人员依赖RTOS。此外，随着开发商被领先的解决方案所吸引，RTOS市场正在整合。

RTOS可以被视为第三代固件开发，因为多线程带来了更高层次的抽象和对执行的更少细节控制。这有很大的缺陷，需要在RTOS级别提供更好的调试支持。然而，通用的调试工具并没有响应RTOS的趋势而得到显著的发展；相反，它们通常只提供对传统调试器概念的增量改进。

通过更好地了解基于RTOS的系统的实时执行，可以简化这些系统的调试。这需要RTOS级别的跟踪，其中可视化对于理解数据至关重要。在嵌入式开发中，一些工具可以将RTOS轨迹显示为水平甘特图，但这并不理想。更复杂的可视化是可能的和可用的，针对RTOS跟踪进行了优化，这使得理解运行时系统、发现重要问题和验证解决方案变得更加容易。