[参考译文] LPSTK-CC1352R：边界路由器问题

在我们的配置中、LPSTK cc1352r 通过 JTAG 和2条额外的 TX/RX 线连接到 LAUNCHXL-CC1352P、如下图所示

LaunchPad 通过 USB 电缆连接到 RPi。

上传 FTD_CLI 闪存时     、我可以使用连接 RPi 上的线程 CLI

sudo minicom -D /dev/ttyACM0 -b 115200

不幸  的是、如果我切换到 RCP 闪存、就像在上面做的那样、我在日志中遇到了问题、如上所述、并且 otbr-agent 在循环中重新启动。  

您好！

上传 FTD_CLI 闪存时     、我可以使用连接 RPi 上的线程 CLI

sudo minicom -D /dev/ttyACM0 -b 115200

这些连接对我来说看起来很好、这似乎确认它工作正常(可以通过串行成功地与 CLI 交互)。

引入了这些功能、即 TX 安全性和 TX 时序、以支持 CSL 功能(https://github.com/openthread/openthread/blame/961fd9ae955fc6992953224bc53a6d3644ba715d/src/lib/spinel/radio_spinel_impl.hpp#L375)。

这是您的用例是否需要的功能？
否则，您可以恢复到 ot-br-POSIX 的前 CSL 提交。

我们还提供了这种工具、这可能很有用： https://dev.ti.com/tirex/explore/node?node=ABSaAO-k3rswvnB7RdRtww__pTTHBmu__LATEST

谢谢、

Toby

Toby Pan

您的建议非常非常宝贵-谢谢。 因为我想帮助下面的其他人、请找到什么是最后的洗浴。
如何连接您在上述帖子中看到的 CC1352 ( LPSTK cc1352r 通过 JTAG 和2条额外的 TX/RX 线连接到 LAUNCHXL-CC1352P、如下图所示。 无需电池或外部电源-全部由 USB 供电)。

用于在 没有 CSL 的情况下为 CC1352制作闪存

安装 Docker

Docker 拉取 openthread /环境：最新
Docker 运行-it --rm openthread/environment bash
Git 克隆 github.com/.../ot-cc13x2-cc26x2.git
cd ot-cc13x2-cc26x2
Git 子模块更新--init
CD openthread
Git 重置31c7208ac87768f8fe7ad4c94d8e8b184bb0ee51
/script/bootstrap
/script/build -DTI_platform=cc1352

然后在边界路由器上，我建议编译 ot-br-POSIX，如下所示：

#如果您有先前的编译删除文件夹、并按照所述克隆新的 repo

rm -r ot-br-posix    

Git 克隆--RECURSIVE  https://github.com/openthread/ot-br-posix.git

Git 子模块更新--init --RECURSIVE

然后

若要在 Thread 1.1中使用 OTBR 、请在   下面的行中添加到 third_party/openthread/CMakeLists.txt

set(OT_THREAD_VERSION 1.1 CACHE STRING "Thread 1.1" FORCE)
cd oot-br-posix

./script/bootstrap 

BACKBONE_ROUTER=0infra_if_name=wlan0 ./script/setup

然后

在"检查/任务 "表单网站下： OpenThread 边界路由器构建和配置

在 otbr-agent中配置 RCP 设备的串行端口：

1. 通过检查确定 RCP 设备的串行端口名称 /dev：

   ls /dev/tty*

2. 将此附加到 /etc/default/otbr-agent。 例如，对于串行端口名称 ttyACM0：

   OTBR_AGENT_OPTS="-I wpan0 spinel+hdlc+uart:///dev/ttyACM0"

验证服务

验证是否已启用所有必需的服务：

sudo systemctl status

如果 setup 脚本成功，输出中将显示以下服务：

• avahi-daemon.service
• otbr-agent.service
• otbr-web.service

验证 RCP

验证 RCP 是否处于正确状态：

sudo ot-ctl state

ot-ctl 是 OTBR 提供的命令行实用程序。 它用于与 wpan0 otbr-agent  RCP 设计中绑定到的 Thread PAN 接口(默认值为)进行通信。

如果 RCP 成功运行并且节点不是 Thread 网络的成员、则输出应类似于以下内容：

禁用 

如果输出为 OpenThread daemon is not running，请使用以下方法进行故障排除：

1. 验证边界路由器是否有足够的电源(使用正确的外部交流适配器)。
2. 断开 RCP 板并将其重新连接到边界路由器平台。
3. 验证 RCP 串行设备是否存在。 例如，如果设备应连接到 /dev/ttyUSB0：

   ls /dev/tty*/dev/ttyUSB0

4. 使用重置 RCP sudo ot-ctl reset。

再次使用检查 RCP 状态  sudo ot-ctl state

然后、您可以按照所述配置您的线程

http://software-dl.ti.com/simplelink/esd/simplelink_cc26x2_sdk/2.10.00.44/exports/examples/rtos/CC26X2R1_LAUNCHXL/thread/cli_ftd/README.html

pi@raspberrypi：~$ sudo ot-ctl state
禁用
完成
pi@raspberrypi：~$ sudo ot-ctl reset
pi@raspberrypi：~$ sudo ot-ctl state
禁用
完成
pi@raspberrypi：~$ sudo ot-ctl channel 14
完成
pi@raspberrypi：~$ sudo ot-ctl panid 0xface
完成
pi@raspberrypi：~$ sudo ot-ctl ifconfig up
完成
pi@raspberrypi：~$ sudo ot-ctl 线程开始
完成
pi@raspberrypi：~$ sudo ot-ctl state
领导者
完成

----

因此、对于愿意在 RCP  架构中使用 Thread 1.1 和不支持 CSL 的 CC1352的人员、这是一个建议。

Toby Pan 您是否有任何建议、如何使其与上面提到的支持 CSL 的 Thread 1.2和 CC1352在硬件架构上协同工作？

在 openthread 中处理了一大部分 CSL。

此代码将调用一些(新)平台无线电功能(比较 CSL (例如 主分支)和非 CSL 之间的 radio.h 文件(请参阅) /source/third_party/openthread/include/openthread/platform/radio.h)。

总之、这些函数的实现必须存在于 TI 示例的 radio.c 中(例如 / /platform/radio.c)。

Toby Pan 感谢您的建议-但无论如何我需要向您提出更多问题。  我们正在进行一个项目、第一批应该有大约70000个单位配备传感器和边界路由器。 目前、我们更关注终端设备、因为最初计划将 Apple TV 机顶盒用作边界路由器。 无论如何、如果您可以推荐您认为具有 WiFi、ehternet 和 openthread 且具有成本效益的边界路由器的最佳平台。  我们希望使用一家供应商的硬件解决方案来避免任何不兼容的问题。 起初、我在考虑 TIDEP0084和 Beagle 3P-BBONE-AI。 您能否向我推荐哪种平台更适合大众市场(可能还有其他未提及的平台)？

您能否向我确认 CC1352能够支持具有 CSL 的 Thread 1.2？
CC1352是否有路线图、其中包含将支持哪些线程软件版本以及支持多长时间？

感谢您分享您各自用例的一些详细信息。

我确实认为、重点关注终端设备是有道理的、因为 Thread 的长期愿景倾向于使边界路由器与 Wi-Fi 路由器一样常见。
话虽如此、"长期"的时间轴未定义、可能与您项目的时间轴不匹配(此外、我无法评论 Apple 机顶盒启用 Thread 边界路由器的时间轴)。

虽然 TIDEP0084基于802.15.4 (类似于 Thread)、但该 TID 的上层为15.4-stack。 对于15.4 Linux 网关、我实际上会建议改为： https://www.ti.com/tool/TI-15.4-STACK-GATEWAY-LINUX-SDK

这是一种适用于传感器到云使用案例的有用设计、但它需要有网关(例如 BeagleBone + 15.4无线电)。
由于您的用例涉及楼宇中的许多传感器、因此15.4堆栈的低于1GHz 频段可以提高性能(用于覆盖范围和墙壁穿透)。 如果您对中间、中期/短期解决方案感兴趣、15.4堆栈 Linux 网关可能是一个不错的选择。

正如我之前提到的、Thread 1.2需要进一步开发；我目前没有这方面的时间表。 但这样说：
请注意、Thread 1.2向后兼容 Thread 1.1 (请参阅此处的常见问题解答部分 ：https://www.threadgroup.org/support#:~:text=Thread%201.2%20adds%20sophisticated%20new,%2Dscale%2C%20professionally%20managed%20network.&text=Devices%20and%20networks%20can%20be,of%20devices%20across%20multiple%20subnets。)