前言
2023年Zephyr开发者大会（ZDS）于6月27日至30日在捷克布拉格隆重举行。与以往两次不同，本次ZDS由Zephyr项目规划和管理，并作为首届嵌入式开源峰会（EOSS）的一部分进行。在这个令人期待已久的盛会中，全球Zephyr开发者们共同探讨了Zephyr实时操作系统（RTOS）的最新技术与发展趋势。作为一款开源、灵活和可扩展的嵌入式实时操作系统，Zephyr项目在2014年由英特尔发起，2016年作为Linux基金会项目正式面向公众启动，得到了全球范围内的广泛关注和采用。
ZDS 2023共70余个技术报告，涵盖了使用指导与展示、新功能与技术、架构修改与操作系统、多核异构与虚拟化、模拟器、测试、工业流程与代码管理、安全性、应用案例、工具与调试等丰富多样的内容。湖大嵌入式实验室的小伙伴们将对本次大会的所有技术报告进行逐一收集、整理与分享，尽最大努力为Zephyr开发者提供ZDS 2023技术报告的开发经验、实践成果以及解决方案的参考。
今天分享第59篇技术报告，由王渊整理，题目为：
“基于RPC的灵活系统设计：在Zephyr中采用分布式计算”
作者简介
Yuval Peress，谷歌高级软件工程师，曾在Magic Leap中担任首席Android工程师，负责传输6 DoF信息以及手势检测系统构建。GoMeta首席Android工程师，负责开发AR应用程序、共享库以及身份安全验证和Redis通信协议。此外，他还是Chromium的EC硬件无关测试首席工程师，负责确保良好的仿真设备设计并改进测试框架以实现更好的单元测试和集成测试。
文章简介
Chromebook配备EC和单独的应用处理器（AP），许多AP（Intel和AMD）都配备了专用的传感器核心，我们希望使用移动传感器以降低EC的成本，但这该如何实现？对依赖性、测试和先前设计的破坏又该如何解决？
本文针对以上问题，从以下几个方面展开：
可移植设计
Pigweed Rpc和protobuffers
从开始到服务的转换
一个典型的例子
可移植性设计
chromium EC的任务
任务在哪里重要吗？通常来说，传感器可以在一个专门的核心，如Intel的ISH或AMD的SFH，PD（Power delivery）逻辑可以在PD芯片上。有了正确的设计，服务和客户端就不需要重写。
Pigweed RPCs and protobufs
Pigweed是一个工具/模块的集合，是一种高度调整的嵌入式应用，本次采用pw_rpc作为模块说明。以一个简单的服务举例，在异步情况下：
Set_val:传递一个int并将齐保存在服务中，在完成时返回一个状态。
Get_val:不传递参数，返回一个状态和当前值。
那么，我们该在什么时候使用这些数据流呢？当Pigweed使用服务器流进行日志记录（pw_log_rpc）时，客户端向服务（EC）发出请求并返回流，流上的每个消息都是日志消息，当数据生成时存在一些延时使用流的时候需要采用数据流进行记录。
Pw_rpc数据可视化：自定义客户端，自动注入特定于服务的信息，如服务和方法id。
将包路由到正确的通道的通用客户端。
将RPC帧写入目标，并可能添加另一层编码。
从开始到服务的过度
我能只用a.h文件吗？当然可以，但是Protobuffers更灵活（因为客户端和服务可以使用不同的语言），Protobuffers可以通过创建模拟客户端/服务来轻松测试，Protobuffers比结构体更容易扩展（支持多个版本）。原型文件迫使我们考虑API边界，API+文档提供了一个契约，限制我们的代码交互，使重构更容易管理，边界使编写测试更容易、更快捷。最后，也是最重要的，Protos被设计为可扩展的。
在使用这种方式的时候，会存在哪些问题呢？首先，随着新参数的增加，数据结构很难维护。同时，这个API还缺少很多功能：数据是如何发送的？有线格式是什么？在哪个线程上调用回调？我们可以取消一个请求吗？我们如何测试这个服务？
典型的例子
构建一个服务：
首先，设定Value值的需要
将值作为参数传递，并设定无返回值
设置Getvalue需求，不传递任何参数
返回一个值
服务实现头文件
服务实现
