[参考译文] CC1312R：发出命令时具有5KBPS OAD 功能和较高的丢包率

您好！  

当您使用5kbps phy 时、无线数据包的传输时间非常高。 这会导致更多的冲突、尤其是在由多个节点组成的网络中。  

当您使用50kbps phy 时、您会看到显著的改进、因为传输时间减少了10倍。 从而减少发生碰撞的可能性。  

如果您使用的是跳频、则可以通过增加停留时间和间隔来进行测试。

在5kbps phy 中、由于低数据速率、加入时间通常也更慢。

SysCtrlSystemReset 是一个 driverlib 调用、几乎是对 AON_PMCTL 寄存器的寄存器写入、并在 while (1)内结束；如果您说失败、您会观察到什么？

Unknown 说：

SysCtrlSystemReset ();重置函数,但有时重置可能失败。

此致、

SID

您好、sid：
1.调用 SysCtrlSystemReset ()函数后,我发现传感器设备的 UART 不再输出日志,并且启动的 LED 灯没有正常闪烁(默认的 LED 灯在传感器启动后会闪烁三次,我处于 Sensor_init (_macTaskId )状态; 函数附近输出一些启动日志)、
2.我在论坛上看到有人使用 HAL_SYSTEM-RESET()函数进行重置,而且从未失败过。 您能告诉我这个函数应该介绍 h 文件是什么吗？
此致

您好、sid：
我是这样理解的：
1.5kbps 适合远距离设备较少但对数据传输速率要求较低的场景
2.50kbps 适合大量短距离设备和高数据传输速率要求的应用场景
请问上述理解是否可行？
那么、5Kbps 与50Kbps 之间的通信距离和功耗之间的近似差异是什么？
您能否为我提供5k 和50k bps 的测试报告？ 我会仔细比较并选择一个适合我们的应用场景的选项、

此致

Unknown 说：

。 我在论坛上观察到有人正在使用 HAL_SYSTEM-RESET ()函数进行重置,它从未失败过。 您能告诉我此函数应引入什么 h 文件吗？

您好！

请您分享此主题。 因为我在 sdk\source\ti\ci154stack\apps\coprocessor\mt\mt_sys.c 中找到了一个定义。

这只是重新定义 SysCtrlSystemReset()

/*! Reset by using DriverLib supplied function */
#define HAL_SYSTEM_RESET() SysCtrlSystemReset()

此致、

SID

您好，sid M ü；

下面是原始的网址、但是由 e2echine 论坛提供、可能需要翻译为以下内容：

https://e2echina.ti.com/support/wireless-connectivity/sub-1-ghz/f/sub-1-ghz-forum/800134/cc1310-cc1310-sysctrlsystemreset/2938261?tisearch=e2e-sitesearch&keymatch=SysCtrlSystemReset#2938261

我会将译文张贴如下：
在 CC1310中、使用 SysCtrlSystemReset 重新启动后、指示灯未亮起。 为了避免 HIB 模式、当 TCK 电缆直接连接到 VDD 电源时、指示灯不亮。 尝试多种方法失败，无法成功重新启动。
请让专家帮助进行分析。 电路图和元件是根据官方网站设计的。
这可能是由多种因素导致的、以下是解决此类问题的一些方法：
在重新启动之前和之后尝试打印日志信息，以确认 SysCtrlSystemReset 确实导致系统重新启动。
确保在重新启动后正确配置用于指示灯的 GPIO 引脚。 有时、在系统复位后、引脚的状态可能会被重置、可能需要初始化和配置这些引脚。
尝试将 SysCtrlSystemReset 替换为 HAL_SYSTEM-RESET()，它相当于硬件复位。 如果您可以重置电路板上的硬件、还可以使用 SysCtrlSystemReset
如果上述软件方法无法解决问题、则不能排除硬件故障的可能性。 检查 CC1310芯片及相关电路是否物理损坏或接触不良。
此外、如果此问题与启动时停止有关、请参阅以下文章。 如果没有 JTAG 连接和外部电源，SysCtrlSystemReset()应该工作正常。
https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/798229

我想问一下我的上述猜测是否正确吗?
1、测试发现以5kbps 的速率发出命令、丢包率相对比较高、但50kbps 的丢包率已经比较低了。 50kbps 和5kbps 之间的区别是什么？ 在我们的场景中、收集器将会与大量传感器(可能为100个)相连接、那么这两个 BPS 之间的功耗和通信距离有何差异？
在测试过程中、我们发现5kbps 很难满足我们对访问100个节点和执行即时消息(如 OAD 功能)的要求

2.我在以下路径中找到了 HAL_system-reset()函数定义
C：\ ti \ simplink_cc13xx_cc26xx_sdk_7_10：02：23 \ source \ ti \ ti154stack \ hal\ platform \ hal_mcu。 h

此致，

发杯

您好，sid：

您是否发现了任何问题？

我进行了另一个测试,发现在 main 函数的 appTaskFxn 任务中重新启动 SysCtrlSystemReset()是正常的。

但在成功加载后复位到 BIM 会失败、但当我手动断开电源并再次通电时、我可以发现传感器已加载新固件。 这样做的原因是什么？ 期待您的回复

我在未连接下载程序的情况下对其进行了测试,并在成功加载后尝试在 SysCtrlSystemReset()上添加 Task_sleep (500);即使延迟500ms 也无法成功重新启动

此致，

发杯

您好、sid：

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/623362/rtos-cc2640r2f-reboot-with-sysctrlsystemreset

在下面的帖子中,还提到使用 HAL_system-reset()函数而不是原始的 RESET 函数

所有 HAL_SYSTEM_RESET ()函数似乎都与 CC1310相关。

请您重新解释一下。

Unknown 说：

我在未连接下载程序的情况下对其进行了测试，并尝试在成功加载后在 SysCtrlSystemReset()上添加 Task_sleep (500)；即使延迟为500ms

您好：

我的意思是,当 SysCtrlSystemReset()函数无法重新启动时,我没有到 JTAG 的链接
不过,在我今天的测试中,我在 SysCtrlSystemReset()函数之前添加了大约1秒的延迟,它可以正常复位。 似乎我仍然需要多次测试才能得出结论。

现在困扰我的是通信距离问题。 我在地下车库的环境中进行了测试
1、5kbps 的通信距离可以达到400米左右
2、50kbps 的通信距离仅能达到100米左右
这种通信距离是否正常？ 是否有方法对其进行优化？

此致，

发杯

尊敬的 Faker：

距离估算器提供不同 PHY 范围的估计值、Excel 工作簿的第二页提供了范围调试检查列表。  

请仔细阅读、了解范围问题和技巧。

https://www.ti.com/tool/RF-RANGE-ESTIMATOR

RF 范围估算器中还提供了应用手册链接、此应用手册在本例中非常有用。  

https://www.ti.com/lit/an/swra479a/swra479a.pdf

此致、
SID

您好、sid：
感谢您的答复。 我们已经解决了通信距离问题,但不幸的是,我试图在 SysCtrlSystemReset()加载成功之前延迟1秒。 但是、在多次测试之后、仍然出现重新启动失败。 您能帮助我找到失败的原因吗？

此致，

发杯

您好、sid：
感谢您的答复。 我将在进行大量测试后返回给大家、

此致，

发杯

您好、sid：

AON_PMCTL_RESETCTL_SYSRESET_BITN)= 1；

仍会有重新启动失败的情况。 您能否再次帮助我找到解决此重启问题的方法？

此致，

发杯

尊敬的 Faker：

在一个简单的单线程应用程序中、这似乎效果很好。 您是否确定寄存器写入实际正在进行、然后在寄存器写入后没有进行复位？

此致、
SID