由于 Silicon Labs 停止使用 SL-Thread 堆栈，我们正在考虑将新设备迁移到 OT，以便在已经基于 EFR32 的系统中使用新设备。
该设备将是一个相对简单的电源供电 FTD（想想“范围扩展器”）。
我正在尝试估计工作量，特别是我有点担心 OTA 固件更新。 查看 GitHub 存储库中的 EFR 目录，我看到： 没有 Gecko 引导加载程序的痕迹。这是否意味着我们应该使用从 SL SDK 构建的常规 Gecko 引导加载程序？或者是否有我缺少的特定于 OT 的引导加载程序？ 没有 OTA 协议的痕迹（在 SL'Thread 中曾经有一个 TFTP 实现和一个点点实现） 是否有计划提供特定于 OpenThread 的 OTA 方法？还是官方建议使用 GeckoBootloader 并实现自己的传输协议？
提前致谢， 马特奥
【问题讨论】：
标签： openthread
OpenThread 技术负责人Jonathan Hui 在Google Group 中回复。
引用他的话：“OpenThread 项目的主要目标是实现 Thread 协议。鉴于 Thread 是一种网络层技术，它没有为 OTA 指定协议。同样，OpenThread 项目不包括引导加载程序和OTA 在其范围内。”
【讨论】：
我在 efr32 系列微控制器方面拥有丰富的经验，顺便说一下，我还尝试将我们的 Silicon Labs Thread 实现移植到 OpenThread。所以我想我可以在这里帮助你......
如果您只需要一个有源（假设不休眠）全线程设备，这可能不是什么大问题。您可以从命令行（在 Linux 或适用于 Linux 的 Windows 子系统中）构建演示项目，只需更改其中一个演示项目即可满足您的需求。
如果您需要一个用于高级调试功能或一般可用性的 IDE 构建，这将是一个更大的挑战。
不过，引导加载程序可能有点问题。 OpenThread 仅旨在实现 Thread 协议，并且是通用的，因此可以在无数应用程序中使用。你不会在那里看到任何 Gecko Bootloader 的东西，或者任何与此相关的引导加载器的东西。
Gecko 引导加载程序本质上是一个在微控制器复位后运行的应用程序，它在外部闪存或内部闪存中查找 Gecko 引导加载程序映像 (.gbl)。如果它找到一个图像，它将覆盖现有的应用程序并启动它。如果它没有找到图像，它将跳转到应用程序。所以你的引导加载程序挑战是 2 倍。
1) 应用程序必须将 .gbl 映像放入 Gecko 引导加载程序期望的内存位置。据我所知，没有标准的方法来解决这个问题，这取决于应用程序。例如，我的应用程序反复轮询 CoAP 端点以获取 .gbl 图像的块以放入外部闪存（这是我的引导加载程序期望图像的位置）。然后当它获得整个图像时，它会重新启动。
注意事项：如果您需要将现有的基于 Silicon Labs Thread 堆栈的项目迁移到 OpenThread 项目，那么您就是一个项目的野兽。 Silicon Labs 线程堆栈集成了一个简单的非基于 rtos 的调度程序和睡眠功能。 OpenThread，甚至是 efr32 演示项目，都不包含这些。由于 Silicon Labs Thread 堆栈是闭源的，这使得这变得更加困难。我现在正在尝试这样做，这非常不愉快。我不希望它在我更坏的敌人身上。
【讨论】：