前言

2023年Zephyr开发者大会（ZDS）于6月27日至30日在捷克布拉格隆重举行。与以往两次不同，本次ZDS由Zephyr项目规划和管理，并作为首届嵌入式开源峰会（EOSS）的一部分进行。在这个令人期待已久的盛会中，全球Zephyr开发者们共同探讨了Zephyr实时操作系统（RTOS）的最新技术与发展趋势。作为一款开源、灵活和可扩展的嵌入式实时操作系统，Zephyr项目在2014年由英特尔发起，2016年作为Linux基金会项目正式面向公众启动，得到了全球范围内的广泛关注和采用。

ZDS 2023共70余个技术报告，涵盖了使用指导与展示、新功能与技术、架构修改与操作系统、多核异构与虚拟化、模拟器、测试、工业流程与代码管理、安全性、应用案例、工具与调试等丰富多样的内容。湖大嵌入式实验室的小伙伴们将对本次大会的所有技术报告进行逐一收集、整理与分享，尽最大努力为Zephyr开发者提供ZDS 2023技术报告的开发经验、实践成果以及解决方案的参考。

今天分享第61篇技术报告，由李江伟整理，题目为：

“对单一代码库重构的见解，使用Zephyr操作系统在不同硬件上运行”

作者简介

拥有以色列理工学院理学学士学位。拥有13年为医疗设备行业、电信行业和机器健康行业开发硬件物联网设备的经验。目前在Augury - 领先的数字机器健康行业管理一个物联网开发人员团队。

以色列理工学院生物技术和食品工程理学学士。在该行业担任工艺工程师 9 年，去年担任 TPM（全面绩效管理）协调员。5年前转向软件编程。在嵌入式项目公司工作了 3 年，前一年半在 Augury 工作。

单一代码库 - 它是什么、不是什么以及适合什么场景？

假设您的设备组合存在一些硬件差异，但具有相似的一般功能，因此您必须为每个设备或设备组合管理单独的代码库存储库。假设您对其中一些代码库不满意，但由于旧的架构、缺乏兼容性等原因，重新设计、重构和更新它们会太乏味，甚至可能实现不了。Augury在nrf52840 SOC（片上系统）上使用 zephyr RTOS（实时操作系统）构建了新一代设备的代码库，并且我们的旧设备在 nrf52832 SOC 上运行，并使用旧版本nrf SDK 11.0构建了裸机代码库。我们的设备的电路板设计和组件存在一些硬件差异，但我们的所有设备都需要执行相同的通用功能。

因此，当我们想到单一代码库 (SCB) 的概念时，我们想到的是一种代码架构，该架构将使应用程序代码部分与其运行的硬件无关。我们选择使用 Zephyr RTOS 来实现这一点，它使用设备树模块来描述硬件、绑定机制和 API 层来实现应用程序的硬件抽象。

现在，如果您正在阅读本文并思考，嘿，这确实符合我的需求，您首先需要确保它对于您的情况确实可行，例如：

我们必须确保我们在世界各地部署的设备可以使用新的代码库 OTA（无线）进行更新。这不是一件显而易见的事情，因为我们的新代码库具有不同的内存布局和引导加载机制。与我们的新设备相比，我们的旧设备的 RAM 大小为其 1/4，CPU 闪存大小为其 1/2。新器件采用 Nand 闪存，而旧器件采用 Nor 闪存，写入速度较慢，并且可以进行页编程（写入操作），缓冲区大小是 Nand 的 1/8（意味着写入迭代是新一代器件的 8 倍）。

这些有关 RAM、闪存大小、性能等硬件限制的问题，必须考虑风险。如果有疑问，最好先从 POC（概念验证）开始，在该解决方案一开始不起作用时发现问题，消除风险，而不是经过了几个月的工作。

我们如何在Augury中做到这一点?——路线图和架构

如前所述，我们制定路线图的议程是首先应对风险并尽快证明该项目是可行的。

根据本指南，我们从 POC 开始，证明我们可以将新代码库 DFU（设备固件更新）OTA 到基于旧代码的设备。下一阶段是开始为旧设备构建SCB，这个阶段也是由优先处理风险的方法驱动的。与裸机代码库相比，Zephyr OS（操作系统）有大量开销。因此，首先我们将 zephyr 应用程序配置为在旧设备硬件上没有任何传感器或功能的情况下运行。接下来是功能性。我们的设备进行许多操作，但最重要的是能够以非常高的采样率对传感器进行采样，同时将收集到的数据流式传输到外部闪存。这些步骤存在风险主要是因为旧设备上的 RAM 短缺（64k 字节与新设备上的 256k 字节）以及外部闪存最大写入缓冲区大小和性能差异。

一旦我们到达这里，我们就有信心我们的设备可以工作并可以继续完成应用程序。前面提到的 POC 采取了一些不属于我们常规 OTA DFU 场景的步骤。POC 和部署阶段有很多内容，希望很快会在后续博客中进行详细描述。

如前所述，RAM 大小是一个需要解决的严重问题，涉及所有 zephyr 操作系统开销以及最初编写时未考虑 RAM 限制的应用程序。一种减少堆栈使用的解决方案是在需要时分配缓冲区，而不是始终将所有缓冲区保留在堆栈上。我们可以使用这种方法，因为我们的 BLE 数据传输操作和采样以及流式传输到闪存操作不会同时发生。这两个操作都需要相对较大的缓冲区。因此，我们创建了自己的分配内存“池”，该内存“池”小于所有所需缓冲区大小的总和，并在需要时从中分配缓冲区。

一个传感器的采样过程必须以高精度的采样频率进行。我们使用 Pickscope 来分析我们正在运行的流程。在不深入细节的情况下，我们发现我们可以通过在调用更高级别的应用程序来处理它之前收集多个样本来减少高优先级采样线程的运行时间，而不是为每个单独的样本调用它们（以非常高的频率）。这为闪存命令较低优先级线程操作的发生释放了一些 CPU 时间。

• 可以，但应该？通用性与性能、项目时间框架

您可以重新设计以使其发挥作用，也可以重新设计以使其良好且通用。但通用性是有代价的，无论是添加条件或接口以及对函数的函数调用等可能影响性能和空间，还是良好的重新设计需要更长的时间来考虑所有事情，向后兼容和向前准备。另一方面，当能够轻松配置、修改、删除或添加功能时，通用性可以增加很多价值。

对于我们来说，性能决定一切。当性能不是问题时，问题就变成了重新设计需要花费多少时间，考虑到这个时间受到要重新设计的流程的混乱程度的影响。

当决定不重新设计时，作为同时解决方案，我们有时使用“#ifdefs”根据配置的板包含或排除代码部分。这显然更容易，但它并不是真正的通用代码，因为您实际上在同一个地方保存了多个代码，尽管只会编译相关部分，但这实际上不是目标和正确的方法，而是时间范围和必要性的妥协。

我的建议 - 专注于项目目标和范围 - 在代码中徘徊时，您可能会看到诸如未使用的函数或变量、在不同模块上执行相同基本操作的函数、不必要的暴露模块、面条式代码等之类的东西。你在公园里散步，捡起路上看到的垃圾。最后，您将拥有一个干净而美丽的公园，但这段步行将花费您比您计划的更长的时间。请记住，任何重新设计都有可能意外地弄乱一些有效的东西，特别是如果您已经看到“垃圾”。然而，组织和封装得更好的代码更容易维护和调试。因此，由您决定您希望重新设计事物的时间和规模。

• 不能/不想

当重新设计某些东西迫使你在没有计划的地方做出改变时。节点和边缘设备之间的 BLE 通信已定义命令和数据包结构。如果我们改变一个尺寸，我们也必须调整另一侧。我们选择避免边缘设备端的更改，这将迫使我们在节点端甚至云中进行重大更改。这种限制有时很困难，因为它迫使设计维持一些不太好的设计和工作流程。

预结论 - 对此类项目的一些个人和高层观点

在从事 SCB 工作或对不断开发的代码库进行任何重新架构时，您可能会体验到不断追逐的感觉。在代码库中完成的每个新功能、错误修复或其他添加或修改，如果最初设计时不是为了支持所有设备而不仅仅是新设备，那么这只是稍后必须对齐（=重新设计）的另一件事 。为了解决这个问题，您应该为项目定义一些终点。我们决定旧产品必须至少完成以前所做的一切。然而，这并不容易做到，因为我们还希望与开发代码库保持一致，以避免以后处理太多冲突。

调整你的团队成员，不要忘记再次调整他们。我们还使用 CircleCI 添加了对所有板的构建过程的验证，这是保持所有产品开发之间的一致性的好方法。在组织层面，你应该想到SCB存在后的那一天。如果不同的团队各自开发不同的产品，并且每个团队都有自己特定于产品的 KPI（关键绩效指标），那么作为 SCB 维护代码可能会变得困难，因为每个团队最终将主要关心其产品的开发和代码 如果团队的议程未能设法保持 SCB 的状态，一段时间后可能会再次划分为多个代码库。

结论——SCB 旅程结束时我们得到了什么

在本文中，我们总结了路线图的第一步：我们有一个应用程序在具有相同代码库的所有板上运行，并且我们在一个存储库中管理它（部署完成后，我们可以处理旧的代码库存储库）。我们从新一代产品中获得了额外的功能，现在也可以在旧产品上使用，这是一个巨大的胜利。 其中一些新功能是边缘计算，可以减少我们发送的数据量，从而使我们能够减少 OTA 传输量和电池消耗。 我们还在新一代产品的代码中发现了一些错误和瓶颈，以使其应用程序在我们所有的主板上运行良好，因此SCB工作的副产品也是新一代产品性能的改进。

最后，展望未来，每一项新功能都将首先被考虑适用于我们所有的传感产品，而不仅仅是新产品，这对于 Augury 作为机器健康服务提供商来说是一个巨大的胜利，部署了超过 60k 的“老”一代产品。