前言
2023年Zephyr开发者大会（ZDS）于6月27日至30日在捷克布拉格隆重举行。与以往两次不同，本次ZDS由Zephyr项目规划和管理，并作为首届嵌入式开源峰会（EOSS）的一部分进行。在这个令人期待已久的盛会中，全球Zephyr开发者们共同探讨了Zephyr实时操作系统（RTOS）的最新技术与发展趋势。作为一款开源、灵活和可扩展的嵌入式实时操作系统，Zephyr项目在2014年由英特尔发起，2016年作为Linux基金会项目正式面向公众启动，得到了全球范围内的广泛关注和采用。
ZDS 2023共70余个技术报告，涵盖了使用指导与展示、新功能与技术、架构修改与操作系统、多核异构与虚拟化、模拟器、测试、工业流程与代码管理、安全性、应用案例、工具与调试等丰富多样的内容。湖大嵌入式实验室的小伙伴们将对本次大会的所有技术报告进行逐一收集、整理与分享，尽最大努力为Zephyr开发者提供ZDS 2023技术报告的开发经验、实践成果以及解决方案的参考。
今天分享第58篇技术报告，由梅傲凌、温浩整理，题目为：
“我是如何爱上Zephyr的？——一个系统架构师的故事”
作者简介
Tobias Kästner博士是一名训练有素的物理学家，目前在德国UL Method Park担任工程师。在这个职位上，他一直在为众多医疗设备开发系统和软件架构，以支持世界各地的客户。自从他在 2000 年代初第一次接触Linux 以来，他一直在寻求通过尽可能利用开源技术来制造更好的产品。他目前的任务是将自由和开放源码软件一劳永逸地带入医疗设备。
Stephan Linz是一名具有项目经理和系统开发人员背景的高级嵌入式软件工程师，他在基于现代32位和64位微型计算机架构的嵌入式系统的硬件和软件开发领域拥有多年的经验。
文章简介
本文介绍了作者对Zephyr深深迷恋的原因：传统的开发方式面临着时间长、变体管理难、软件架构复杂等问题，而具备高度灵活性和创新性的Zephyr成为了这些问题的解决方案，为开发者提供了全新的思维方式，塑造了嵌入式设备开发的未来。
收集需求
选择处理器并为软件团队获取评估套件：一旦明确了产品的需求，接下来是选择适当的处理器（芯片）来满足这些需求。然后，为软件团队提供一个评估套件，这是一个包含所选处理器的硬件和软件工具的集合，以便软件团队可以开始开发。
设计硬件并制作少量硬件原型：在选择了处理器后，硬件团队开始设计产品的硬件部分。然后，制作少量硬件原型，通常不超过5个，以进行初步测试和验证。
将当前固件移植到原型硬件：在硬件原型准备就绪后，将当前的固件（软件）移植到这些原型硬件上，以验证硬件和软件的基本兼容性。
在原型硬件上完成固件设计：一旦硬件和软件基本兼容，团队就可以在原型硬件上完成软件（固件）的设计。这可能包括调优、优化和适应特定硬件的代码。
交付产品：最后，完成了固件设计并验证了硬件和软件的集成后，就可以开始生产并交付最终的嵌入式产品。
假设需求不会变化
假设只需要两个硬件版本
假设固件开发人员可以使用 ECAD 文件
忽略调试 LED
只允许端口转发策略的固件
使用长寿命功能分支
硬件和软件开发之间的死锁
系统架构设计：系统架构包含软硬件接口，结构设计和行为，在产品开发中，系统架构是关键的，因为它涉及到整个系统的设计和组织。这包括定义软件和硬件之间的接口、系统的整体结构，以及系统的行为。一个良好设计的系统架构有助于确保系统的稳定性、性能和可扩展性。
知识架构：在整个团队中，每个成员都应该了解系统的大局，而不仅仅是局限于自己的领域。这有助于确保团队成员之间的共享理解，并促使更好的合作和协作。
协作架构：在产品开发中，不同的专业领域之间需要紧密合作，不同团队成员的输出如何成为另一个团队成员的输入，例如硬件工程师和软件工程师之间。一个良好设计的协作架构有助于确保信息流畅、任务协同，以便团队能够高效地推进工作。
敏捷性硬件开发
这样做的好处：
一个原理图，多种形式：一个共同的硬件原理图，实际的硬件设计可以采用多种不同的方式来实现，这取决于具体的需求、技术选择和设计团队的决策。
调整硬件和软件开发开发速度保持一致。确保在整个产品开发过程中硬件和软件的进展是协调的，避免其中一个方面的进度过快或过慢，从而提高整体的开发效率。
加可重用性并保持硬件设计的灵活性，在硬件设计中要寻找机会以增加组件和模块的可重用性，同时保持设计的灵活性。可重用的设计元素可以降低开发的复杂性，同时提高效率，因为它们可以在不同的项目中被重复使用。
较简单的设计更容易快速实现。
Zephyr中的变体管理
软件架构：
将现有的体系结构直接映射到 Zephyr中：服务和模块核心逻辑成为子系统、重用现有设计模式如可迭代部分来实现自定义扩展点、KConfig 用于特性切换和通过设备树实现硬件抽象经历了几次迭代。
将架构中的所有模块、服务的通用结构、不同编译单元的核心逻辑和编绑定关系映射到源代码。
Cmake集成：
Zephyr CMake扩展极大地简化了Kconfig集成，以便有条件地选择应该构建的内容。
Kconfig的模版: 模板有助于为每个模块提供一致的CONFIG_ keys,提供模板嵌套功能，且模块绑定的启用取决于通过 Kconfig 启用的服务。
Zephyr中的设备树的发展
第一阶段的设备树：在设备树的第一阶段中，有一个简单但错误的映射，但这足够作为开始。子系统之间的绑定主要通过设备树中的别名、Zephyr 操作系统中的 "user" 部分，以及设备树中的 "chosen" 节点来实现。
第二阶段的设备树：在设备树的发展中，由于硬件版本的变化，Zephyr采用了更为复杂的抽象和映射方法，引入了硬件模块（shields）以及覆盖层的概念，以便更灵活地应对不同的硬件配置和版本。
第三阶段的设备树：第三阶段的设备树发展基于之前的开发中，硬件模块（shields）仍然紧密耦合于核心板（core board），但在这一阶段，引入了外设连接器作为一个抽象概念，类似于 Arduino 板上的连接器模型。这种抽象提高了模块间的独立性，使得硬件模块不再直接依赖于底层板的特定细节，而是依赖于更通用、更灵活的外设连接器。
第四阶段的设备树：第四阶段的设备树发展中，引入了一个“routing”板和一个新的硬件模块 x_nucleo_nexus，以满足将 Nucleo 连接器映射到外设板连接器的需求。同时，通过引入抽象接口 prph_IF 和 morpho_IF，以及虚拟硬件模块 x_nucleo_144，增加了设备树的灵活性和可扩展性。这些改进使得硬件模块之间的连接和映射更为通用和可配置。
Zephyr在设备树的开发取得的成就
实现了硬件和软件之间实现了一对一的映射关系，通过设备树实现了硬件和软件配置的对应关系。这意味着设备树成功地描述了硬件的结构和组件，并且软件能够直观地映射到相应的硬件配置上。
在源代码中没有暴露电路图的详细细节。这也意味着开发人员在软件开发过程中不需要关注硬件电路图的具体细节，通过设备树进行抽象，使得软件和硬件的关系更为清晰。
系统级配置在构建软件系统时能够透明地映射到软件构建系统。系统级配置通过设备树的形式能够直接影响软件构建的过程，使得整个系统配置更为直观和灵活。
实现了“开闭原则”（Open/Closed Principle）。通过设备树的配置，系统能够轻松地适应新的硬件配置，而不需要修改现有的源代码。
Zephyr最令人心动的地方
在应用控制器和实时控制器之间出于数据传输的可靠性、安全性或性能的考虑必须使用私有以太网链接进行通信。基于私有以太网链路的，原来的应用控制是不可能实现的，因为涉及到两个不同的以太网接口，作为替代方案，选择了 Raspberry Pi 4，但它只提供了一个以太网接口。
而在Zephyr中已经内置了或提供了所有所需的功能或组件，可能包括与网络和USB通信相关的驱动和协议栈，通过添加少量的配置代码，可以实现系统从原先的连接方式切换到通过USB进行以太网连接。切换到USB进行以太网连接后，系统的高层协议（TCP、MQTT、MQTT-RPC）以及应用层不需要额外的修改或适应，它们能够立即适应新的连接方式并正常运行。
