嵌入式MCU使用的RTOS数量似乎无穷无尽，其中大多数都有自己专有的功能和独特的API。有些RTOS的API很好，有些就不那么好了。事实上，好的和不太好的RTOS API之间的差异很小——大多数RTOS API都可以。回顾过去的30多年，专有的RTOS API已经并将继续对嵌入式软件开发和整个嵌入式行业产生深远的负面影响。

首先，专有的RTOS API代表了应用固件的锁定。使用专有的RTOS API编写的代码必须进行更改，以便迁移到不同的RTOS。更糟糕的是，转向另一个RTOS所需的改变可能令人望而生畏。一些RTOS供应商已经添加了一个适配层，试图支持其他RTOS API。然而，这种解决方案并不理想，因为它经常试图将一个方钉安装在一个圆孔中。更不用说额外的层大大增加了RTOS的开销和复杂性，这又会导致错误。

在任何情况下，不能轻松地移植嵌入式应用程序代码都会严重限制产品的发展。例如，如果一个应用程序依赖于RTOS XYZ公司，并且它不支持最新和最好的处理器，应用程序开发人员要么需要修改代码库以转移到另一个RTOS，要么等到RTOS XYX公司增加支持，要么干脆放弃。类似地，将基于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处理器，通常具有不同的功能和价位。他们基于微处理器的产品经常使用一些嵌入式Linux。对于这些公司来说，因为专有的RTOS API而不得不维护独立的开发团队(和代码库)既困难又昂贵。有了标准的RTOS API，应用代码可以在基于微处理器和基于微控制器的项目之间即时共享，从而改进整个开发过程，从编码和测试到产品发布。

标准的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 APIs已经在UNIX/Linux系统上测试了30多年。将硬实时RTOS功能与此行业标准API相结合，使嵌入式开发人员能够两全其美。我们的行业只需要各种RTOS提供商在本地采用它。将嵌入式软件行业统一在POSIX pthread API标准上，将消除供应商锁定，加速嵌入式产品发展，减少培训，并立即实现MCU类和MPU类设备之间的代码共享和迁移——所有这些都代表着嵌入式行业向前迈进了一大步。