现代嵌入式系统已经成为复杂的计算设备，需要Linux或实时操作系统(RTOS)来帮助嵌入式开发人员管理其实时约束。对于RTOS用户来说，开发人员需要做出一个有趣的设计决策;你应该将RTOS从应用程序中抽象出来还是解耦?

　　不抽象RTOS的理由

　　对于上面的问题，一个流行的答案是团队不要抽象他们的RTOS。相反，RTOS成为整个应用程序的核心组件。将应用程序与RTOS紧密耦合有很多好处。

　　首先，大多数抽象层都是为了满足最低标准的特性而编写的。这意味着如果你使用一个抽象层，并且只想遵循它所提供的特性，你可能会失去RTOS的一些功能。每台RTOS都有独特的功能，旨在应对特定细分市场的挑战。虽然你会发现创建任务、队列等标准功能，但你可能不会发现内存保护单元的抽象、与Arm TrustZone的集成或其他功能。

　　接下来，你可能会发现使用抽象层会降低系统性能。今天的编译器一般足够好，可以进行适当的优化;但是，额外的调用和设置可能会占用额外的时钟周期和内存。

　　最后，调试和故障排除会变得更加复杂。如果你通过抽象层与RTOS进行交互，并且出现了问题，那么你将被从细节中抽象出来。直接使用RTOS可以为嵌入式开发人员提供更好的工具和更大的可见性来解决问题。

　　抽象你的RTOS的理由

　　今天开发的许多嵌入式应用程序都是在这样的期望下创建的，即在十年或更长的时间内，核心代码将会生成多种产品。产品在领域中活跃的时间也差不多，开发人员在设计和实现他们的系统时必须考虑到变化。RTOS解决方案来来去去。支持时好时坏。如果你想让你的代码经受住时间的考验，你的应用程序不能写得对你的RTOS有很强的依赖性。RTOS必须被抽象化。抽象RTOS有很多好处。

　　首先，抽象层使得在短时间内更改RTOS解决方案变得更加容易。你可能会问，“我为什么要改变我的RTOS?”，更好的解决方案可能会出现，或者RTOS在所需的应用领域可能会出现问题。也许嵌入式开发开发人员的流失会导致团队不具备特定RTOS的经验，所以改变是不可避免的。有了抽象层，你可以通过对单个文件进行更改来更改RTOS，而不是更新代码库中的几乎每个模块。

　　接下来，我们可以从另一个角度来看前面的原因。抽象层将你的应用程序从RTOS中分离出来。消除应用程序对RTOS的依赖使你的代码更具可重用性和可移植性。我们都听说过可靠的原则，其中之一就是利用依赖倒置原则。你应该希望依赖于接口，这样你就可以打破耦合。

　　最后，RTOS的抽象层可以简化与RTOS的交互。抽象层通常包含许多RTOSs支持的标准特性的子集。例如，CMSIS-RTOSsv2提供了一个抽象层，芯片供应商通常使用它来支持多个RTOS。如果你检查CMSIS-RTOSv2中包含的子集，以及几个常见RTOS(如FreeRTOS、AzureRTOS和泽法)的API集，你会发现它们的API包含一些共同的元素，但却完全不同。简化的抽象使得开发人员更容易以一种通用的方式与各种RTOS进行交互。

　　结论

　　你应该抽象你的RTOS吗?看情况!每个项目和每个嵌入式开发团队都有不同的目标和需求，用来满足客户的需求。我建议当你开始下一个项目时，仔细考虑你是否真的希望你的应用程序与你的RTOS紧密耦合。你可能会发现这是一个令人愉快的解决方案，或者你可能会发现是时候使用操作系统抽象层(OSAL)并使你的代码更加可移植和可重用了。