RTOS实现亚毫秒定时分辨率的新方法

你在使用实时操作系统（RTOS）时是否发现无法将任务调度或延迟精度降到毫秒以下？你可能不得不在RTOS之外编写大量应用代码。虽然这种方式可行，但这会让你怀疑应用程序是否满足其截止期限，是否可维护和可扩展。RTOS不应该能够管理整个应用程序的时间吗，不管这个时间是一秒还是一微秒？

对于嵌入式系统领域的开发和管理人员来说，平衡时间精度和能源效率可能是一项持续的斗争。随着应用的发展，无论是在汽车、物联网、医疗设备还是工业自动化领域，对精确定时控制的需求都在增长。虽然传统的RTOS解决方案在管理实时任务方面很有效，但在这两个关键领域往往存在不足。

首先，传统RTOS有精度限制。基于滴答的系统不能提供超出滴答（Tick）间隔（如1毫秒）的时间粒度。这种限制影响了执行超精细定时操作的能力，例如精密传感器读数或先进机器人的高分辨率控制。事实上，如果不仔细，你甚至可能任务时序中注入抖动，从而破坏系统的实时性能！

其次，基于滴答的RTOS能效低！即使没有任务调度，周期系统滴答中断也会使CPU保持活动状态，从而导致能源浪费，这在电池供电和低功耗设备中尤为严重。虽然一些RTOS试图通过引入tickless省电模式来克服这个缺陷，但这些解决方案更多的是权宜之计，而不是完整的功能。

这些限制迫使开发人员采用效率低下的解决方案，例如轮询硬件计时器或使用特定于目标的技术来实现更高的分辨率和更低的功耗，这种方法使开发过程复杂化，降低了软件的可移植性和可维护性。

本文中，我们将探索一种新的机制来精确地调度低于一毫秒的任务，这种机制可以提高应用程序的实时性能，同时提高能效，其好处来自于利用周期精度定时的新RTOS实现。

传统的RTOS使用周期性的系统滴答来跟踪时间和调度任务。例如，大多数RTOS，如FreeRTOS、Zephyr和embOS-Base，默认使用1毫秒的滴答间隔。这个间隔依赖于每毫秒产生一次中断的计时器。所有时间相关的操作（任务延迟、超时和软件计时器）都与滴答对齐。如果我们使用SEGGER SystemView这样的工具来记录和分析应用程序的运行时行为，将看到类似图1所示的内容。

图1：使用周期滴答来跟踪系统时间的传统RTOS

如果调查当今的RTOS市场，你会发现SEGGER的embOS-Ultra是唯一支持基于周期调度的RTOS。因此，我们将关注embOS-Ultra如何通过引入周期分辨率定时来解决精度和效率方面的挑战，以及这种创新方法如何改善应用。

让我们来分析一下embOS-Ultra是如何在不增加不必要复杂性的情况下解决精度和效率问题。

通过单次计时器提高能效

通过移除周期滴答，embOS-Ultra显著降低了CPU负载。即使没有待处理的工作，传统的RTOS也会在每个滴答唤醒CPU，这种行为增加了功耗，因为CPU必须保存其当前状态，处理中断，并恢复其状态，这些不必要的CPU周期消耗了能量。

embOS-Ultra的单次计时器仅在特定事件发生时唤醒CPU，使系统长时间处于低功耗状态。这一特性对于低功耗和电池供电的应用尤其有利，例如可穿戴设备或远程物联网传感器，在这些应用中，节省的每一点能量都将延长运行时间。然而，即使是连接到恒定电源的设备也可以通过降低其整体能量配置和减少对电网的需求而受益。

在许多微控制器架构中，计时器可以配置为各种模式。EmbOS-Ultra利用定时器计数到零或到指定值的模式，在需要时触发中断。这种灵活性使开发人员能够精确地控制时间事件，而不依赖于周期滴答。正如想象的那样，允许计时器自由计数用于调度，比计数为零后重置更有好处。

维护系统的长期稳定性

你可能会认为，虽然使用单个计时器来提供高分辨率、亚毫秒级的调度听起来很棒，但丢失系统滴答将破坏应用程序。好消息是它不会，embOS-Ultra使用两个硬件计时器。一个计时器用于长期连续运行而不产生中断。第二个计时器，即我们在前一节中讨论的单次计时器，用于任务调度。

这意味着没有复杂的算法在后台运行，试图确定自系统启动以来已经过了多少毫秒。诚实地说：我们大多数人都利用系统滴答来提供时间戳、计算过滤器和执行其他日常活动。如果从RTOS中删除它，我们的开发将变得更加困难。

添加第二个计时器似乎会增加系统的复杂性和能效，但事实并非如此。如今，大多数32位微控制器拥有多个计时器，而且与CPU相比，计数器使用的电流很少。使用第二计时器的权衡仍然确保我们最大限度地减少能耗，同时保持系统实时性能的长期稳定性。

了解了周期调度如何工作后，我们来研究一个示例。SEGGER的网站上提供了一个live comparison示例(https://www.segger.com/products/rtos/embos/editions/embos-ultra/#live-comparison)，模拟滴答调度和周期调度行为。我建议尝试一下，获得一些实际操作经验。

Live comparison示例允许你通过print语句查看每秒产生了多少次滴答。测试应用包含两个任务：一个201毫秒的任务和一个50毫秒的任务。基于滴答的调度器，每秒1000个节拍。如果使用基于周期的调度来模拟相同的应用程序，则每秒只能获得24 - 25个节拍。

遗憾的是，对于模拟程序，无法使用SystemView来记录和分析应用程序行为，因此，我使用live comparison示例运行在开发板上来分析周期调度。结果如图2所示：

图2：图1所示的相同应用程序的基于周期调度实现

迁移到新的RTOS带来的风险和复杂性，可能是开发人员和管理人员非常关心的问题。embOS-Ultra通过在提供扩展功能的同时保持与现有API兼容来解决这个问题。

首先，对使用embOS-Base或其他滴答RTOS API的应用程序，可以在embOS-Ultra中继续发挥预期的作用。embOS-Ultra中保留了基于毫秒的计时功能，确保已有代码无需修改。如果使用的是embOS-Base，则API直接兼容。如果使用其它RTOS，你可能会有一天左右的时间将RTOS调用更新为embOS-Ultra。

其次，对于需要更高精度的开发人员，embOS-Ultra引入了扩展的API，例如用于微秒延迟的OS_TASK_Delay_us()或用于周期调度的OS_TASK_Delay_Cycles()。这些函数与传统API调用共存，允许开发人员在不修改整个代码库的情况下逐步采用高级功能。

让我们来看一个例子。假设我们想每1,000,000个周期向终端发送一次打印“Hello World!”，我可能会用下面的语法创建一个名为Hello的RTOS任务：

OS_TASK_Delay_Cycles以周期方式指定了任务挂起操作的最小时间间隔，因此，当调用OS_TASK_Delay_Cycles时，如果系统周期计数为1,000,000，则100万周期的延迟将在系统周期计数为2,000,000时到期。

注意，作为开发人员，你可以控制单个周期所代表的时间间隔。它可以是单个CPU周期，也可以是更长的时间，这取决于你如何为使用的计时器配置时钟分频器。好消息是，SEGGER为各种微控制器提供了许多移植实现，所以你不必自己编写这些；只有当默认值不能满足需要时，才需要知道如何通过API来调整。

这种双重计时方法意味着工程师不必在传统实现和高精度之间做出选择，他们可以在同一应用中同时使用这两种方法。无论是从embOS-Base还是其他基于滴答的系统（如CMSIS-RTOS）迁移，开发人员都可以很方便的使用embOS-Ultra，因为必要的应用更改很小且简单。

基于周期的调度代表了一种技术进步，它解决了开发人员和管理人员在当今嵌入式系统中面临的核心挑战，在实现微秒精度的同时最大限度地提高能效。通过消除传统的系统滴答，并提供灵活的、基于周期的方法。

基于周期的调度为希望在没有复杂迁移风险的情况下提高系统的性能和能源配置的嵌入式专业人员提供了一种实用而先进的替代方案。你可以通过下列步骤了解更多关于周期调度的信息。

首先，查看embOS-Ultra RTOS手册(https://www.segger.com/downloads/embos/UM01076_embOS_Ultra.pdf)，它包含了许多示例，描述了高精度和周期调度如何工作。

最后，确认了更精确的计时和节能的好处后，即可在嵌入式系统采用基于周期计时功能了。

●专栏《嵌入式工具》

●专栏《嵌入式开发》

●专栏《Keil教程》

●嵌入式专栏精选教程