[参考译文] CC1352P：缩短 CC1352P 传输持续时间

admin

Other Parts Discussed in Thread: ENERGYTRACE

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1006783/cc1352p-reducing-cc1352p-transmission-duration

器件型号：CC1352P
主题中讨论的其他器件：ENERGYTRACE

我使用的是示例程序- CC1352P-2 LaunchPad/TI Drivers/rfPacketTx/CCS Compiler/rfPacketTx。

rf_EventMask terminationReason = rf_runCmd (rfHandle、(rf_Op*)&rf_cmdPropTx、rf_PriorityNormal、NULL、0)；

传输数据包、该方法在 TI 驱动程序中实现。此方法需要大约15ms 的时间来传输60字节@ 450MHz、GFSK 25kHz DEV、128kbps 数据速率和10ms 的时间来传输60字节@ 450MHz、GFSK 25kHz DEV、200kbps 数据速率、最大可能值。

此外、RF_runCmd 方法会进行阻断。是否有任何方法可以更快地执行 RF_runCmd？是否有其他方法可用于加快该过程？

4 年多前

0 admin 4 年多前

TI__Guru**** 2603895 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

首先、如果您在433MHz 频带下运行、则需要使用 P4 LP 而不是 P2 LP (针对868MHz 进行了优化)。

以128kbps 的速率传输有效载荷为60字节的数据包需要(4 + 4 + 1 + 60 + 2)*8/128000 = 4.44ms，这一次可以通过使用 energyTrace 并查看当前配置文件来验证。

不确定在得到15ms 时是如何测量时间的。

执行 RF_runCmd 会阻止、并且在发送数据包之前不会返回。您可以将其替换为 rf_postCmd()，它将在不等待命令完成的情况下返回。

Siri

0 admin 4 年多前

TI__Guru**** 2603895 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

仅为了测试、我使用 P2。我们的最终硬件遵循 P4。我们知道 P2未针对433MHz 进行优化。

2.在 RF_runCmd ()之前，我将 GPIO 设置为低电平，在执行此命令之后，我将相同的 GPIO 设置为高电平。我将使用示波器测量低-高脉冲。此命令所花费的时间超过10ms。

3.我们使用 RF_runCmd()作为阻塞语句。我们对它很满意、但它应该更快。

0 admin 4 年多前

TI__Guru**** 2603895 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

遗憾的是、您无法应用魔术设置来加快 RF_runCmd (或其他命令)的速度。

我唯一能想到的是、您可以使用编译器的优化设置。

如果您没有时间等待阻塞呼叫、我不理解为什么您不能改用 RF_postCmd。

您还可以使用命令的启动触发器来确保在给定的时间执行命令。

Siri

低于 1GHz（参考译文帖）

低于 1GHz（参考译文帖）(Read Only)

[参考译文] CC1352P：缩短 CC1352P 传输持续时间