寻找实时嵌入式软件开发解决方案

2022-06-21

寻找实时嵌入式软件开发解决方案

了解典型嵌入式实时操作系统(RTOS)应用程序的常见问题和潜在解决方案，以及标准化和可重用性问题以及在应用程序中移植RTOS代码的示例。

嵌入式处理器已经发展成为复杂而强大的设备，通常可以在一个小的物理封装中满足各种要求。随着应用程序变得越来越复杂，工程师必须跟上步伐，以应对由此导致的软件复杂性增加。在工业应用中，该软件通常运行多年（如果不是几十年的话），并且在其整个生命周期内管理嵌入式应用并非易事。

在实践中，一些重要的问题会影响所有重要的软件项目，无论它们是否依赖于RTOS。此类问题的示例包括在应用程序的整个生命周期内管理构建系统、可移植性注意事项、日志记录和shell机制。在下面的图1中，您可以看到一个带有可定制组件集的示例RTOS。

图 1.示例RTOS中的可定制组件集。 

本文介绍了RTOS的常见问题和任务。然后，在检查Zephyr OS在示例应用程序中的作用之前，它分析了嵌入式软件开发系统对标准化和可重用性的需求。 

耗时的RTOS挑战

几乎每个重要的软件项目都需要一个可靠的构建系统，无论项目是否包含实时组件。在应用程序的整个生命周期（可能跨越多年）中维护这样的构建系统并不是一项简单的任务。包含的组件和外部库中看似微小的更新和更改会很快导致耗时的错误搜寻，从而占用开发人员的时间。 

软件和模块更新

如果没有存储库管理工具，开发人员不仅必须检查主RTOS内核的更新，而且还必须追踪项目中使用的每个外部模块的每一个变化。但是，必须记住，某些模块依赖（或基于）外部库和模块，开发人员随后也必须对其进行跟踪。这些子模块中缺少更新可能会破坏构建在模块之上的组件，从而导致耗时的错误搜索。管理这些依赖链并非易事，存储库或依赖管理工具为工程师节省了大量时间，他们可以专注于实现嵌入式应用程序。  

跨平台移植

将项目从一个设备移植到另一个设备会很快成为一个复杂而冗长的过程。即使工程师决定使用来自同一制造商的不同设备，该过程也可能涉及许多耗时的重新配置任务。一些修复和实现可能在一个系统上工作，而在使用其他硬件时它们不能按预期运行。

此类问题的原因可能是：

不同的内存布局

硬件地址的变化

不同的硬件功能

不同的驱动接口

以将值写入系统中的闪存的程序为例。在他们最初的设计中，工程师使用了一个包含片上闪存和闪存控制器的微控制器单元(MCU)。然而，由于供应短缺，设计团队将设计切换到另一个没有内置闪存和外部闪存模块的MCU。由于该软件包含用于访问片上闪存的硬件特定代码，因此团队无法在不重新设计代码库的重要部分的情况下轻松地将应用程序移植到新的 MCU平台。 

这个问题会很快导致不同设备的多个相似代码库，从而导致更严重的问题，例如，在实施影响所有代码库的错误修复时。图书馆组织和配置管理进一步增加了这种重新配置任务的复杂性。 

状态和错误记录

通常，更复杂的项目需要一些日志机制来输出调试和状态消息，或者需要一个外壳来让开发人员和外部系统与实现的软件进行交互。然而，这些设施并不总是RTOS的一部分，开发人员必须实施它们或将以前实施的解决方案移植到他们当前的项目中。自定义实现还必须确保线程安全，因此必须在将它们包含在软件的生产版本中之前进行广泛的评估和测试。

常见的RTOS解决方案

鉴于上述问题和任务，许多传统RTOS提供实时调度程序、同步支持和内存管理功能。下面，我们将检查几个流行的选项（FreeRTOS、Azure RTOS和Zephyr OS）及其潜在的优缺点。

自由实时操作系统

FreeRTOS 最初是一个简单的实时内核，提供线程、同步和内存分配机制。该项目的轻量级特性使其对各种嵌入式应用程序具有吸引力。截至本文发表时，该项目由亚马逊维护。开发人员专注于添加额外的云服务集成，例如对 Amazon IoT 核心和其他 AWS 服务的支持。MIT 许可证确保 FreeRTOS 保持免费。 

此外，轻量级核心调度程序易于集成到项目中，并且该操作系统仍然是当今最流行的 RTOS 之一。但是，与ThreadX不同，FreeRTOS 并非设计用于安全关键系统。对于此类系统，工程师将不得不依赖使用名为SafeRTOS的商业许可产品。

Azure 实时操作系统

Microsoft Azure RTOS，以前称为ThreadX，是FreeRTOS的替代品。总体而言，Azure RTOS 提供了比FreeRTOS更好的硬实时功能，并且还符合各种安全相关标准。但是，这些选项都无法有效解决一些首要问题。

一个问题是FreeRTOS和Azure OS是如何被塑造未来的大公司收购的。由于亚马逊和微软提供专有的云服务，它们可能会让开发人员轻松连接到他们的特定云服务。但是，这些公司可以尝试让开发人员更麻烦地集成不同的云服务。  

和风操作系统

相比之下，Zephyr OS 是 RTOS 领域中一个相对较新的项目，旨在解决上述问题。它引入了标准化部件，开发人员可以在跨各种受支持平台的多个项目中使用这些部件，而无需重新配置工作。Zephyr OS 是一个社区管理的开源项目，提供独立于供应商的解决方案，工程师无需支付许可费即可使用。由于该项目的这种独立于供应商和开源的性质，单个公司不太可能显着决定 Zephyr OS 与其他产品和服务的集成程度。图 2 显示了 Zephyr OS 的框图。

图 2. Zephyr OS 结构框图。 

Zephyr OS 的公开可用源代码和广泛的在线文档还确保嵌入式工程师可以了解他们做出关键决策所需的所有有关 Zephyr 的详细信息，而无需对任何源文件进行逆向工程。此外，与完全闭源解决方案相比，由许多开发人员管理的开源项目通常具有更好的安全实施。此外，几乎任何开发人员和公司都可以添加对新架构和硬件的支持。  

示例解决方案——Zephyr 项目

Zephyr项目（图 3）具有多个离散块，可用于简化构建过程并通过标准化组件链接不同的库。 

图 3. Zephyr项目的主要功能。

一般来说，Zephyr构建系统让工程师可以自由选择他们想要如何实现特定选项以及他们想要使用哪些内置设施。虽然SDK包含许多有利的功能，但其中大部分是完全可选的。工程师可以自由地在他们的项目中使用它们，或者按照他们一贯的做法来实现功能。 

内置外设和驱动程序接口是这种方法的另一个例子。标准化的应用程序编程接口(API) 允许工程师将大量代码重新用于标准通信选项，例如I2C和串行外围接口(SPI)。通用异步收发器(UART) 驱动程序可确保内置日志记录工具开箱即用。  

Zephyr包管理器

Zephyr的内置包管理器（称为 West）从公共或私有存储库中提取外部包，并启动应用程序的整个构建过程。它还负责刷新MCU，并可以进一步生成物料清单(BOM)。

此外，Zephyr将不属于Zephyr核心的代码保存在单独的外部存储库中。这些外部存储库包括可重用的IoT应用程序构建块，例如：

供应商HAL

文件系统实现

公共库（如OpenAMP和OpenThread）

此外，West 还可以管理私有存储库中保存的其他外部库和代码。这些外部组件和第三方库有自己的发布时间表和CI/CD工具使用，完全独立于Zephyr。Zephyr中的这个元工具确保开发人员不必考虑如何在项目中包含外部库。此外，团队可以专注于构建他们的嵌入式应用程序，而不是跟踪添加到Zephyr项目的所有外部第三方和官方软件模块的更改和依赖关系。在后台，West使用CMake来管理构建过程。 

借用 Linux

Zephyr SDK借鉴了Linux的一些概念，其中两个是Kconfig和设备树。

在Zephyr中，Kconfig 提供了一种将库链接到项目的简单方法，而无需确切知道要使用哪些源文件和构建宏。Zephyr SDK 包括一个简单的Linux设备树实现，它允许开发人员记录系统中存在哪些硬件。然而，与Linux中的动态设备树（图 4）相比，Zephyr使用它们更像是在编译时描述硬件的数据结构。

图 4.此图比较了本示例中使用的两个评估板的设备树。突出显示的部分显示了两个文件之间的差异。标记该标签是因为 littlefs（本示例中使用的文件系统）需要它。 

此描述保持静态，在运行时不会更改。 

Zephyr的示例用例

让我们仔细看看两个示例用例——每个用例都利用MCU的GPIO来控制某些引脚的状态——以说明这些功能是如何从实际在该领域工作的设计人员的角度结合在一起的。

跨MCU平台移植

在第一个示例中，使用LPC55S69 MCU 的原始电路板为工业 I/O 面板应用提供了足够数量的可用GPIO引脚。然而，该设计的后续迭代采用了S32K118 MCU（来自另一个硬件系列，具有相当数量的可用 I/O引脚）。

这种新设计包含更多的外部组件，并且MCU没有提供足够的可访问GPIO引脚。因此，工程师添加了一个SPI-to-GPIO扩展器来弥补缺少的通道，并且他们需要在两个项目之间共享尽可能多的源代码。 

使用Zephyr已包含的驱动程序（允许SPI到GPIO转换器在系统中显示为常规MCU GPIO引脚），开发人员无需更改源代码。相反，他们只需要为较新的电路板设计更新设备树。这让设计人员可以避免需要多个代码库、对源代码进行复杂的调整以及冗长的回归测试和移植过程。这个例子进一步强调了工程师应该依靠久经考验的简单实现而不是快速修复和黑客来维护应用程序的可靠性和安全性。

跨不同封装和引脚的移植

尽管Zephyr是非常特定于电路板的，但开发人员不需要为每个系列的自定义电路板编写新的设备树源文件。换句话说，开发人员可以利用评估套件来测试他们想要在产品中使用的 MCU，例如LPC55S69。对于原型，他们可以使用 制造商（在本例中为 NXP）提供的LPC55S69-EVK和DST。这可以在图 5 中显示。 

图 5.工程师只需对Zephyr设备树结构和pinmux.c文件进行细微调整，即可将应用程序从 EVK 移植到使用不同封装中相同芯片的定制板上。

一旦开发人员验证代码在评估套件上工作，他们只需要为他们的特定定制板创建一个定制设备树覆盖(DTO)。覆盖文件描述了定制板的特定硬件，以便Zephyr构建系统可以连接它。 

将RTOS推向新的高度

本文研究了使用传统嵌入式RTOS所特有的几个总体问题。首先，在其整个生命周期内管理软件产品并非易事。问题始于维护和更新第三方和官方外部库。开发人员通常必须跟踪对这些库所做的更新。更新那些引用的库总是有风险的，因为这样做可能会导致无效或损坏的依赖关系和版本不兼容。 

安全问题和潜在漏洞几乎困扰着所有大型软件系统，实时操作系统也不例外。即使是已建立的协议和产品，即使经过多年的可靠运行，也可能会受到损害。然而，闭源和专有软件产品面临更大的风险，因为更少的开发人员可以检查代码并测试可能的安全缺陷。

Zephyr等开源系统为开发人员提供了一种可访问的方式，以确保他们的设计从头开始实现标准化和可重用性。在此处了解如何使用恩智浦 MCU充分利用您的RTOS解决方案。