现在是使用标准RTOS API的时间了吗？

与嵌入式MCU一起使用的RTOS的名单很长，其中大多数都有自己的专有功能以及独特的API。有些API很好，有些则不太好。实际上，好的和不太好的RTOS API之间的差异相当小——大多数RTOS API都有其专用的功能。回顾过去30多年，我开始意识到私有的RTOS API已经并将继续对嵌入式开发和我们的整个行业产生负面的影响。

首先，私有的RTOS API代表了应用程序固件的锁定，使用私有的RTOS API编写的代码必须修改才能移植到不同的RTOS。更糟糕的是，移植到另一个RTOS所需的修改可能令人生畏。一些RTOS供应商添加了一个适应层，试图支持其他API。然而，这个解决方案并不理想，因为它就像在圆孔中安装一个方形钉子。更不用说额外适配层大大增加了RTOS的开销和复杂性，它还可能导致错误。

无论如何，无法轻松迁移应用程序代码可能会严重限制产品的演变。例如，如果一个应用程序依赖于RTOS XYZ，并且它不支持最新和最高性能的处理器，应用程序要么需要修改其代码库以移植到另一个RTOS，要么等到RTOS XYZ添加支持，要么就放弃。同样，将基于RTOS XYZ的应用程序迁移到嵌入式Linux（另一个非常常见的情况）是困难的，因为嵌入式Linux中的多线程是基于POSIX pthreads API的。标准的RTOS API将有助于消除锁定，从而使嵌入式应用程序更加便携，并增强其未来的演变。

私有的RTOS API也需要经过培训才能上手，大多数首次使用RTOS的开发人员必须花大量时间学习私有的RTOS API。即使是使用FreeRTOS或微软的Azure RTOS （ThreadX）的嵌入式开发人员——两者都是流行的嵌入式RTOS，每个都有自己的专有API，它们在开发人员总数中所占比例相当小。这里的重点是，私有的RTOS API需要学习，这花费了公司的时间和金钱。行业标准的RTOS API将减少培训，从而节省资金，并提高设备制造商产品上市时间。

另一个问题是，一些设备制造商的产品系列横跨MCU和MPU处理器，通常具有不同的功能和价格特点，他们基于MPU的产品经常使用某种类型的嵌入式Linux。对于这些公司来说，由于私有的RTOS API，必须维护单独的开发团队（和代码库）既困难又昂贵。使用标准的RTOS API，应用程序代码可以在基于MPU和MCU的项目之间实时共享，从而改善从编码、测试到产品发布的整个开发过程。

标准RTOS API应该是什么？

在我们更进一步讨论之前，我们应该感谢ARM。他们多年前在嵌入式行业发现了这个问题，甚至试图用CMSIS-RTOS API解决这个问题。不幸的是，CMSIS RTOS API最终是另一个专有的RTOS API。

回到标准的RTOS API应该是什么这个问题，有趣的是，答案多年来一直摆在我们面前：标准的RTOS API应该是行业标准POSIX pthread API，它已经是每个嵌入式Linux发行版以及每个大学计算机科学课程的一部分。由于嵌入式Linux占嵌入式设计的70%，因此很容易认为POSIX pthread API已经是嵌入式系统中的RTOS API标准，也是大多数开发人员已经熟悉的标准。

此外，POSIX pthread API已经在UNIX/Linux系统上测试了30多年。将硬实时功能与这个工业标准API融合，承诺嵌入式开发人员一个两全其美的方案。我们的行业只需要各种RTOS提供商原生态的采用它。将嵌入式行业统一在POSIX pthread API标准上，将消除技术的锁定，加速嵌入式产品演变。减少培训，并立即实现MCU和MPU级设备之间的代码共享和迁移——所有这些都将推动嵌入式行业向前迈出的重要一步。

作者：Bill Lamie

在商业RTOS领域工作了30多年——他先是创建了Accelerated Technology（被西门子收购），然后是Express Logic（被微软收购）。Bill是Nucleus和ThreadX的唯一作者。Bill的最新努力是PX5，在那里你可以找到他的最新产品——PX5 RTOS！

审核编辑：汤梓红