2023年Zephyr开发者大会（ZDS）于6月27日至30日在捷克布拉格隆重举行。与以往两次不同，本次ZDS由Zephyr项目规划和管理，并作为首届嵌入式开源峰会（EOSS）的一部分进行。在这个令人期待已久的盛会中，全球Zephyr开发者们共同探讨了Zephyr实时操作系统（RTOS）的最新技术与发展趋势。作为一款开源、灵活和可扩展的嵌入式实时操作系统，Zephyr项目在2014年由英特尔发起，2016年作为Linux基金会项目正式面向公众启动，得到了全球范围内的广泛关注和采用。
ZDS 2023共70余个技术报告，涵盖了使用指导与展示、新功能与技术、架构修改与操作系统、多核异构与虚拟化、模拟器、测试、工业流程与代码管理、安全性、应用案例、工具与调试等丰富多样的内容。湖大嵌入式实验室的小伙伴们将对本次大会的所有技术报告进行逐一收集、整理与分享，尽最大努力为Zephyr开发者提供ZDS 2023技术报告的开发经验、实践成果以及解决方案的参考。
今天分享第6篇技术报告，题目为：
“Oniro在Zephyr应用中的经验与教训”
Stefan Schmidt在开源软件社区持续贡献了17年。17年来，他参与了不同项目和Linux生态系统中各个层面的工作，包括引导加载程序、内核构建系统以及用户界面开发等。在与Yocto项目合并的过程中，他担任OpenEmbedded技术指导委员会的成员，帮助将2.6内核移植到一些早期的智能手机上，并担任启蒙基金会图书馆的发布经理。他也是Linux IEEE 802.15.4子系统的共同维护者，已经从事此项工作长达10年。作为一名自由职业者和三星开源团队的长期成员，他最近加入了华为新成立的开源技术中心，担任首席解决方案架构师。此外，Stefan经常在开源相关会议上发表演讲。
Oniro是Eclipse基金会的一个项目， 旨在打造一款分布式开源操作系统平台，在此平台上消费者的任何品牌、制造、型号的设备都保持高度的互联性。而兼容这些设备也就意味着要兼容除了Linux内核这种广泛使用的内核，还得包括像Zephyr和LiteOS这样的实时操作系统（RTOS）的内核和广泛的嵌入式操作系统环境，而Oniro在2023年推出了垂直解决方案（vertical solution）开源操作系统—OpenHarmony
OpenHarmony是一个由中国OpenAtom基金会主导和开发的开源操作系统，是鸿蒙系统开源的基础。OpenHarmony由linux和LiteOS做支撑，有着小巧和支持众多标准的特点，并且已取得Apache 2.0授权，可以让开发者轻易的将代码转入和转出。在标准化方面，OpenHarmony支持来自108个制造商的274款认证产品。下图为OpenHarmony的架构图。
● meta-zephyr
在此案例中，开发团队使用 meta-zephyr 进行 Yocto/OE 中的 bitbake 构建时，存在一些统一开发工作流程的问题：
1. 分层中混合了不同功能的问题：原先的meta-zephyr将机器支持、发行策略等混合在一层，导致分层结构不够清晰和模块化。
2. 仅支持少数机器：与Zephyr实际支持的机型相比，原先的meta-zephyr层仅支持了少数机型。
1. 将meta-zephyr分为两个层：meta-zephyr-bsp和meta-zephyr-core。通过这种分离，将机器支持与其他内容分开管理，提高了可维护性和灵活性。
2. 使用"$ bitbake generate-zephyr-machines"命令，通过一些CMake技巧从west板上自动生成机器定义。生成的机器需要经过手动验证、测试，并在CI中进行添加。
3. 在使用meta-zephyr进行构建时，会受到可用机器的限制。尽管存在一些额外的步骤来统一开发流程，但对于我们来说，这些额外的努力是值得的。
4. 通过分离层、生成机器、添加应用和示例配方等方式，对meta-zephyr进行了改进。共有约68个补丁（patches）被提交到meta-zephyr的上游。
● Connectivity and Graphics
在这个案例中，开发团队使用了Arduino Nano 33 BLE、Nitrogen 96等硬件，并在Zephyr上开发项目。除了核心功能外，他们还使用了OpenThread、CoAP和LVGL等子系统来支持特定的功能需求。
在开发过程中，他们面临了以下问题：
1. OpenThread Spinel协议的版本不匹配（与Linux主机之间）。
2. 使用的LVGL版本过旧，无法按预期工作（LVGL同时在Linux和Zephyr上使用）。
解决方案：
1. 切换到更新的Zephyr版本解决了一些OpenThread的问题。
2. 提升LVGL版本并对上游的LVGL模块进行改进和升级。
3. LVGL子系统的更新引起了上游的改进。
4. 在需要的地方进行了一些较小的修复（例如，在分区表中进行持久存储）。
5. 需要协调OpenThread的协议版本匹配以进行更新。
6. 将大约20个补丁（patches）上游到Zephyr项目，以促进改进被合并到主线代码中。
通过上述解决方案，团队成功解决了问题，并改进了他们的开发流程。通过切换到更新的Zephyr版本，解决了部分OpenThread问题。通过提升LVGL版本并进行上游改进，满足了他们的需求。此外，通过提交补丁到Zephyr项目，他们对Zephyr社区作出了贡献，并帮助改进了整个生态系统
● Zephyr and Linux Code Sharing
本案例，涉及到在Linux和Zephyr之间共享代码库的使用，其中EDDIE项目在两者之上运行。该项目是基于C++的，使用了CoAP、JSON和OpenThread。
在这个案例中，他们面临了以下问题：
1. Linux和Zephyr提供了不同的CoAP API（libcoap vs native）。
2. OpenThread的配置接口存在问题。
1. 在理想的情况下，通过代码复制和抽象来实现重复使用。由于Linux和Zephyr提供了不同的CoAP API，他们可能需要编写适配器或抽象层来处理两个平台之间的差异。
2. 同样，对于OpenThread的配置接口，他们也可以通过抽象来解决其问题。
这个案例中的使用情况可能是一种较为特殊的情况，因为它涉及将项目分割为同时在Linux和Zephyr上运行的部分。这种分割项目并在不同平台上共享代码库的需求可能不是非常常见。在一些特定的场景下，将项目拆分为不同的平台可能是出于性能、资源限制或功能定制的目的。
然而，与之类似的场景也可能存在，其中开发人员需要在不同的操作系统或嵌入式平台上进行开发，并且需要共享一部分通用的代码。在这种情况下，开发人员通常会遇到特定平台之间的差异和限制，需要通过编写抽象层或适配器来处理这些差异并使代码可重用。
总体而言，为不同平台共享代码库并处理平台之间的差异是一项具有挑战性的任务。对于 Zephyr 项目来说，完全的抽象层可能超出了其范围，因为它主要集中于为嵌入式系统提供开发和运行时环境。然而，开发人员可以通过合理的代码设计和组织来实现尽可能的代码复用，并且必要时可以编写适配器或抽象层来处理特定平台的差异。
● Blueprints (doorlock & CATS)
在此案例中涉及传感器、执行器、无线通信和图形等方面的蓝图。使用了键盘、OpenThread、CoAP、LVGL和图形资源。
在这个案例中，他们面临了以下问题：
1. 演示硬件的启动时间较长。
2. SRAM（256 KB）和 Flash（1 MB）的大小限制导致特性集受限。
1. 由于存在广泛的驱动支持，可以较为轻松的选择到合适的硬件组件。
2. 将早期原型从Zephyr切换到Linux操作系统。这个决策可能是因为在Linux中能够更好地支持门锁系统的需求。这样可以利用Linux的功能和驱动程序库，并实现对马达驱动器、键盘、OpenThread、CoAP和应用逻辑的支持。
3. 上下文感知触摸屏（Context Aware TouchScreen）从Zephyr切换到Linux。这意味着针对触摸屏的应用逻辑在Linux中实现，以利用其更丰富的图形功能和页面切换的能力。
4. 针对具有不同页面和图形资源的图形应用程序，存在闪存空间耗尽的问题。为解决这个问题，可以尝试优化和压缩图形资源，考虑动态加载和卸载页面，或者增加闪存容量以适应应用的需求。
5. 即使没有OpenThread子系统，也存在闪存空间不足的问题。这意味着闪存存储器的大小限制对于应用的特性集来说仍然是一个挑战。在这种情况下，可以考虑进行进一步的闪存空间优化，例如减少不必要的应用组件或功能，并评估是否有其他方式可以实现所需的功能。
这个实际案例涉及知识产权(IP)合规流程。他们的IP合规流程不仅限于生成软件构建物清单(SBOM)，还包括对构建物的源代码进行手动审核。在他们的Zephyr目标构建中，发现了以下问题：
1. 二进制文件的许可证情况不明确(NXP、espressif HAL)。
2. LVGL模块中有专有字体。
3. mcuboot 和 nios2f 的许可证不明确，可能是专有的或开源的。
1. IP审计团队准备了潜在问题清单。
2. 在项目中进一步分析，并将问题提交为Zephyr的上游工单。
以下是已解决的问题：
工单链接：
https://github.com/zephyrproject-rtos/zephyr/issues/46954
问题2（lvgl模块）已解决
工单链接：
https://github.com/zephyrproject-rtos/zephyr/issues/48111
以下问题仍然是开放的（或已关闭但可能是过时的）：
工单链接：
https://github.com/mcu-tools/mcuboot/issues/1490
工单链接：
https://github.com/zephyrproject-rtos/zephyr/issues/51317
这个案例中的问题主要涉及到软件使用的许可证合规性。通过手动审核源代码，他们发现了一些模糊的许可证情况和不明确的许可证声明。为了解决这些问题，他们的IP审计团队准备了问题清单，并将问题提升到Zephyr项目上游，以便进行解决。
当前的重点和路线图如下：
1. 2023年重点增强OpenHarmony作为垂直解决方案。OpenHarmony是一个开源分布式操作系统，旨在提供统一的操作系统解决方案，适用于各种设备。在2023年，团队将专注于进一步加强OpenHarmony作为垂直解决方案的能力。
2. 应用程序框架和生态系统增强。团队将专注于提升OpenHarmony的应用程序框架和生态系统。这可能包括与流行的应用程序框架和技术如ReactNative和Flutter的集成，以提供更广泛的应用程序开发选项。
3. IDE工具增强。开发人员工具是提高开发效率和质量的关键因素。团队将致力于提供更强大、易用和集成的IDE工具，以支持开发人员在OpenHarmony平台上的开发。
4. 系统分析和优化。团队将专注于系统级别的分析和优化工作，以提高OpenHarmony的性能、效率和稳定性。这可能涉及到性能分析工具和技术的开发，以帮助开发人员识别和解决性能瓶颈和优化机会。
5. 在安全关键领域使用Rust。为了增强OpenHarmony的安全性，团队将采用Rust编程语言在安全关键领域进行开发。特别是在Web引擎等安全关键组件上，使用Rust可以提供更高的内存安全性和代码可靠性
OpenHarmony与zephyr：
1. 在与Zephyr的结合方面，OpenHarmony希望通过一个外部的Zephyr模块将两个系统进行连接。这种连接可以使得OpenHarmony和Zephyr能够共同协作，实现更广泛的平台支持。
2. OpenHarmony已经具备了实时操作系统（RTOS）的支持，其中包括LiteOS。这意味着OpenHarmony已经有了支持RTOS的能力，并且可以在此基础上进一步扩展平台的支持。
3. 实现OpenHarmony与Zephyr的结合需要进行KAL（内核抽象层）和HDF（硬件驱动框架）的移植工作。这些工作涉及到将两个系统进行整合和适配，以确保它们能够无缝地协同工作。
