RTOS如何使用及如何选择

　　遵循一些简单的步骤，您将做出正确的 RTOS 选择

　　RTOS 由内核和中间件组成。需要中间件来高效可靠地执行某些功能。如果它满足这些要求，它就没有什么进一步的后果了。然而，内核是嵌入式设计的核心。它极大地影响了设计的完成方式，并且是嵌入式程序员与之交互最多的内容。因此，将“内核”称为“RTOS”已成为行业惯例。我在这里坚持这种做法。

　　选择 RTOS 的一个问题是它通常在项目开始时完成，在系统设计完成甚至开始之前。那时，人们对需要哪些 RTOS 功能知之甚少。鉴于没有理由不这样做，许多程序员倾向于选择简单、低成本或免费的 RTOS，然后接受其局限性。这显然是一种非最佳方法，它可能会浪费人月的努力和最终系统的延迟交付。

　　我提供了一种不同的方法来选择 RTOS，我的方法具有许多您认为不需要的功能。这需要了解这些功能是如何工作的，然后确定它们是否对您的应用程序有用。除非您实际尝试，否则您如何决定哪些功能对您有用？让我们首先消除一些关于简单 RTOS 的常见误解。然后我们可以讨论如何同时创建系统设计并为其选择 RTOS，而不会过早地锁定到错误的 RTOS。

　　内存使用

　　通常，用于 RTOS 的主要 RAM 用于任务使用的堆栈。如果 RTOS 没有为中断提供系统堆栈，那么每个任务的堆栈必须足够大以处理总 ISR 堆栈要求。如果允许中断嵌套，最坏情况下的 ISR 堆栈加载可能会向每个任务的堆栈添加数百个字节。如果有大约 20 个任务，这很容易增加 5 到 10 KB 的 RAM。简单的 RTOS 通常有这个问题。一些 RTOS 甚至允许在任务之间共享堆栈。

　　ROM使用

　　现代链接器忽略了未使用的 RTOS 功能。因此，它们不会增加 ROM 占用空间。缺少（即，需要但不存在）RTOS 功能怎么办？它们必须在应用程序代码中创建。这不仅需要时间和金钱，而且由于进度压力，这些功能的实现效率可能低于 RTOS，甚至可能由不同的程序员多次实现，或者可能是不可靠的紧急工作。因此，一个简单的 RTOS 实际上可能比高级 RTOS 需要更多的 RAM 和 ROM，这可能会给项目带来更多问题。

　　表现

　　毫无疑问，更少的代码运行得更快。因此，执行错误检查并提供多种功能的 RTOS 服务将比简单 RTOS 的精简等效服务慢。但是，您的 RTOS 需要多少性能？与嵌入式系统中执行的其他处理相比，RTOS 调用和任务切换并不常见。编写良好的 RTOS（不是 GPOS）可以在“低端”50 MHz Cortex-M3 处理器上实现每秒 50，000 次任务切换。你需要多少？随着过去十年处理器性能的巨大进步，重要的衡量标准已经从原始 RTOS 性能转变为它提供的服务的实用性以及它为快速开发可靠系统提供了多少帮助。

　　调试功能和错误管理

　　每个人都知道调试代码比创建代码花费的时间更多，而且项目通常由于顽固的错误而延迟。然而，我们应该做些什么来限制这种未来的痛苦？简单的 RTOS 通常不会提供比 C 库 - zilch 更多的帮助。如果你想要理智和美好的家庭生活，这是你应该注意的事情。

　　三维问题

　　选择 RTOS 是一个三个维度的问题：大小、性能和特性。这些特性共同定义了您的系统所在的嵌入式空间。除此之外，还有许可证和价格维度，但我们将把这些留给业务类型。在这里，我们将专注于我们都感觉更舒服的技术空间。

　　单个 RTOS 无法很好地覆盖所有嵌入式空间。因此，您必须确定您的应用程序所在的位置才能很好地适应。最好的方法是从上到下开始设计您的应用程序。在另一篇文章圣诞树 RTOS中，我将这个过程比作装饰圣诞树。

　　挑选候选人

　　要开始选择过程，请查看 RTOS 供应商文献以找到具有大量有趣功能的候选者。然后，如果它为您喜欢的处理器提供评估套件，您就可以开始了。下载评估套件并让它在您的处理器的评估板上运行。希望这将是一个快速的过程。如果没有，请尝试另一个 RTOS 候选者。

　　入门

　　最好的开始方法是创建拟议系统的框图。接下来，将块与线程相关联（线程是 ISR、任务或其他执行路径）。这涉及对块进行分组或拆分。总体目标是将异步 *** 作放入单独的线程中，将中断驱动的 *** 作放入 ISR，并将高级 *** 作放入任务中。中间 *** 作可以放入回调函数或链接服务例程（LSR）中，这是一种更结构化的回调函数形式。

　　随着您的进步，框图将很快变得笨拙。当这种情况发生时，就是编写代码的好时机。这里的目标是创建骨架 ISR、任务和 LSR。这可以通过任何 RTOS 完成。只需使用 RTOS 服务来创建和控制 RTOS 对象。当您深入了解您需要哪些 RTOS 服务时，您可能希望比较每位 RTOS 候选人如何完成特定工作，并继续选择您最喜欢的工作。

　　放入延迟存根以模拟实际代码及其估计的延迟。还要放入最少的代码来模拟将数据加载到消息中并将它们发送到其他任务，以及模拟系统需要执行的其他 *** 作。使用信号量、互斥量等，实现顺序。延迟和模拟不需要准确开始。

　　随着你的进步，经常构建你的系统并使用调试器来了解它是如何工作的。你会经常感到惊讶！注意：单步执行很有用，但您需要在许多战略性位置设置断点以查看实际发生的情况。否则，在一个步骤期间，可能会发生中断，可能会运行多个任务，您会想知道这个或那个是如何神奇地发生的。多任务系统往往具有自己的生命，这可能不是您所期望的。意外可能会让您深入了解候选 RTOS，以更好地了解其工作原理或发现其实施中的缺陷。您可能需要考虑不同 RTOS 提供的替代方法。最好早点面对系统设计的惊喜，而不是在编写了大量代码并痛苦地调试之后。

　　这也是开始测量应用程序的关键时间的好时机，例如中断延迟、任务切换时间和开销，以及电源使用情况，以及对这个系统很重要的任何其他事情。当然，要获得准确的数字，您需要开始改进延迟和模拟。一个很好的副产品是估计的延迟和 RTOS 引起的结构为尚未编写的代码设置了界限。延迟可用于在实现之前确定需要优化代码的位置。如果最终代码在其边界内，它将适合系统。这为项目中的每个人提供了安全保障。

　　这有什么好？

　　这种方法的美妙之处在于，在早期你有一些实际运行的东西，其他人可以看到它运行，他们也可以运行它。此外，您还会收到反馈，以确定哪些结构最适合您需要做的事情，并在进行测量以确认您的决定时。然而，您实际上只在代码中投入了少量工作——如果有必要，大部分的思考和研究可以转移到不同的 RTOS 或不同的系统设计中。重点更多的是结构而不是功能。

　　许多项目把自己画到了一个角落，改变 RTOS 或系统设计不再是可行的选择；编写了太多代码以允许改变方向。无论好坏，该项目都被它选择的任何东西所困扰。这对豆类柜台和其他所有人来说都是个坏消息。

　　同时，沿着黄砖路继续前进，您将了解所选 RTOS 的工作原理、哪些功能对您有用、如何使用它们，以及它的调试和内核感知功能如何帮助您解决问题。然而，如果您需要，您也可以在离岸不远的地方涉水回到旱地并选择不同的 RTOS 或系统设计。

　　审核编辑：郭婷