我想编写一个需要一些 RTOS API 的模块,例如 Mbox 和任务创建 API!
我正在尝试使用结构化代码,为此我正在查看一些库,例如 "lwip" 。在“lwip”中有一个名为 Sys-arch.c 的文件,据我所知,它是 RTOS API 的抽象层!但在我的端口中,它包含 cmsis_os.h 并使用了该 API。为什么他们这样做而不是直接使用 cmsis_os ?
我应该有一个新的操作系统层以便拥有可移植代码还是 CMSIS_OS 就足够了?
这个答案非常基于意见。
以我的经验,在你的操作系统访问周围使用函数/定义总是一个好主意。如果您使用 CMSIS_OS 或您自己的层并没有太大的不同,那么如果您使用自己的,那么您有更多的工作,尤其是移植和测试对于多个操作系统来说变得非常麻烦。
CMSIS_OS 将您绑定到 Cortex-M 系统,但是由于它们也以非常常见的方式实现了您将在您的层中实现的内容,因此稍后从 CMSIS_OS 移植到您自己的层相当简单。如果您直接在代码中使用对特定操作系统的直接调用,这并不是那么简单,但如果您只依赖标准功能(看看 CMSIS_OS 什么是 RTOS 的常见功能)并且不使用特殊功能,这也是可能的您的操作系统的功能。
为什么他们这样做而不是直接使用 cmsis_os ?
因为:
这个想法是从任何RTOS 中抽象 API。如果您的目标没有使用 CMSIS RTOS,那么无论如何您都必须编写一个移植层。
CMSIS RTOS API 是 ARM Cortex-M 特定的,而 lwip 不是。
我应该有一个新的操作系统层以便拥有可移植代码还是 CMSIS_OS 就足够了?
CMSIS 仅在您只针对 ARM Cortex-M 时就足够了,并且您可能需要使用的任何 RTOS 都有一个 CMSIS 层。CMSIS 是可移植性抽象,但可能不是可用性抽象。您可以选择通过 CMSIS 实现您自己的更简单的抽象,该抽象也可以移植到其他目标。
lwIP 的结构很好,因此只要您的 RTOS API 支持其语义要求,那么您所要做的就是使 sys_arch.c 适应您的 OS API,然后就完成了。通过使用 CMSIS_OS API 抽象来制作 sys_arch.c,这意味着您可以使用任何符合 CMSIS OS API 的操作系统,而无需更改 sys_arch.c 的端口。这是一个额外的间接层,只有您可以决定是否值得。如果您不打算在下面使用不同的 RTOS,那么没有理由不拥有特定于单个 RTOS 的 sys_arch.c。
无论如何,lwIP RTOS 要求相当适中。大约有十几个功能,但实际上只涉及具有某些特征的邮箱和信号量。