每次我开始一个新项目，我都觉得自己是从零开始。但在现代体系下，我很少会从注册表开始，一步步往上爬。相反，我从 SDK 或供应商 IDE 中的一堆预构建示例开始。这些通常与硅供应商提供的特定硬件绑定，并与开发板上的外围设备绑定。它很适合评估，但随后我需要开始将东西分层放在一起，以构建一个更大的系统。这就是为什么我对学习Zephyr3感到如此兴奋;它是一个跨平台的实时操作系统和生态系统。我可以针对一堆不同的连接方法和处理芯片组使用相同的基础代码。我也可以很容易地重新定位我以后想要制作的定制硬件。
那么，如果我从一个已经内置了一堆示例的项目库开始，我可以在其中插入我的业务逻辑和特定于外设的功能呢?这时就需要一个好的模板了!
目标设计要求
在我的工作中，大多数时候，我都是在创建特定应用设计来解决某个行业中的问题。一个例子可能是资产跟踪器，它也可以插入汽车上的ODB-II端口，并读出可用的诊断信息，例如车速。保险公司希望通过这样做来降低订户的保险费率。设计的核心是读取一堆传感器，然后将这些读数发布到互联网上。如果我想控制这个设备，我也会想把数据从云端推送回设备。
开源参考设计模板
这些天我开始的方式是从一个开源参考设计模板构建在 Zephyr 之上。事实上，这个模板最近才刚刚开源。它内置了所有设备到云、云到设备和双向 api，所以我可以直接开始开发我关心的部分。这个模板中最重要的功能是 Over-the-Air，这意味着我可以在设计的第一天访问远程固件更新。如果在我的固件设计中有一件事是肯定的，那就是当设备还在我的工作台上时，我不会在第一个版本上就把事情做好 
我的正常流程是从app_work.c 文件开始。我经常使用Zephyr传感器子系统与连接到我的目标处理器的设备进行通信。Golioth空气质量监测器(AQM)参考设计在中，这包括一系列环境传感器。值得注意的是 Sensirion AG的sps30， Bosch的bme280和Sensirion AG的scd41
如果这些传感器在 Zephyr 的树上，那么练习就变得更容易了。它变成了 Zephyr 内的几行 API 调用，用于从传感器提取数据。RTOS 实际上从可用特征列表中返回一个格式化的数据类型。Zephyr 生态系统开始实施一些标准化，甚至在传感器领域的供应商之间也是如此，这真是太棒了。我只想让传感器做的就是给我大气压或者温度。
然后，我将读取的数据格式化后发送到 LightDB Stream，这是一个在设备和云之间同步的时间序列数据库。Zephyr 帮助抽象了与云的大部分连接，在我的情况下，我经常在 nRF9160 上使用蜂窝连接。然后，Golioth Zephyr SDK 负责与云上端点的连接和协商。在我看来，同样的温度或压力数据会在云上“显示”出来。数据可以从 REST API 中提取出来，显示在仪表板上或发送到定制的应用。基本上，它可以帮助我将读取的数据传递给我的软件团队，他们想用这些数据做其他事情。这就是上面提到的空气质量例子中的仪表盘
一旦我的传感器数据开始传输，我就开始深入研究可能与我的设计相关的其他功能。我可以使用Golioth设置服务将设置 推到字段，并在app_settings.c 中设置设备上的处理代码。或者我可以在设备上创建定制函数(远程过程调用)，该设备在app_rpc.c 中运行一些子例程，然后在云上触发这些函数(包括传递变量)。每当我需要更新设备端代码以获得这些新功能时，我都可以使用Over-the-Air更新服务。
针对不同的硬件
Zephyr 的优势是针对不同的硬件;我们通过针对Aludel平台(我们创建的自定义平台)和 nRF9160-DK 在开源模板中利用了这一点。这是在 Zephyr 项目的 boards 目录中完成的。
我们的目标是我们自己的定制平台，因为我们希望将数据传递到Ostentus盖板上的eInk显示屏。但我们也希望用户能够尝试模板和后续设计。这为蜂窝物联网应用创建了一个很好的起点，即使你想“从零开始”启动一个项目:挑选你的传感器，找出你需要从云端控制的功能，然后开始。我发现，那些想要在一天而不是一个月的时间内完成演示的工程师们真的会从这种方法中受益。
随着时间的推移维护
一个真正的好处是，随着模板的发展，你也可以将特定于应用的设计向前推进。由于在Golioth平台上或特定于基于zephyr的模板上有一个新特性可用，我可以将这些更改滚动到我的设计中。例如，我们增加了一种标准方式，可以将设备的固件版本报告到我们使用的标准屏幕上。一旦在模板上进行了更改，我就更新了我的具体设计，以便将该功能纳入其中。
这并非没有一些挑战。从模板开始工作，而不是说将子系统拼凑在一起，这意味着在升级旧设计时可能会出现合并冲突。我之前写过关于 Thingy91的文章，以及我们如何创建二进制文件来快速尝试蜂窝物联网的项目。我们经常谈论这个话题，并且认为说出这也是基于这个模板，需要向前推进。然而，在Zephyr中使用manifest的好处是，只要云端的api是相同的，代码就会无限地继续构建。Zephyr和子系统的版本是很重要的，这样未来的开发人员(甚至是“未来的你”)在开发项目时就可以成功地做好准备。
帮我搞定 Zephyr
如果你需要Zephyr的帮助，Golioth提供免费的 Zephyr培训。我们将介绍如何入门以及 devicetree, RTOS 使用，KConfig 等基础知识。你还将看到设备如何使用 Zephyr 和 Golioth 直接(轻松地)连接到云。