This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC2340R5:BlueJoule-GATT 连接基准测试-- CC2340R5 与 nRF52832 与 nRF54L15

Guru**** 2943400 points

Other Parts Discussed in Thread: CC2340R5, CC2540

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1654768/cc2340r5-bluejoule-gatt-connection-benchmark----cc2340r5-vs-nrf52832-vs-nrf54l15

器件型号: CC2340R5
主题: CC2540 中讨论的其他器件

去年首次公布的 BlueJoule 广告基准的基础上,我目前正在研究家庭中的下一个基准——包括一个简单的基于 GATT 的连接交易…  与以往一样,该基准的重点是 能源效率

在开发过程中,您可以在 Bluejoule-GATT GitHub 存储库中了解更多有关此基准的信息。

在过去的一周中、我完成了一个到 CC2340R5...的 BlueJoule-GATT 外设端代码的“端口“  作为这项工作的一部分、我在 SImpleLink SDK Zephyr 的 TI 分支下实现了所需的外设功能--让我先看看后者…

此外、我还移植了一个 EM•Script 平台编写的非常小(~8K 代码)BLE 外设堆栈、与同一硬件平台上的传统 BLE 堆栈相比、该堆栈在能效方面有了显著提高

您将在 本报告中找到有关 CC2340R5 结果的详细信息 底线: Zephyr 的表现远远超过了 SimpleLink…

我将把它留给读者在一个并排比较与一些北欧设备得出他们自己的结论..  在某种程度上,一个到 CC27xx 系列的端口是有秩序的——虽然除了更快的 CPU 之外,我不确定无线电功耗是否会更好???

TI 持续发挥作用的一个领域是其超低功耗深度睡眠模式、在该模式下、我将在 保留所有 SRAM 的情况下测量到~500nA 的电流...  北欧在这一点上甚至没有接近!!!!

如果您有任何疑问/意见/顾虑、请随时直接与我联系

[BIOS] bob

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

    您好!

    您使用 SimpleLink SDK 看到的结果并不正常、因为您应该能够在广播或连接间隔之间进入待机状态。 您能说明一下如何将基准测试软件移植到 SimpleLink SDK 吗? 您是否使用 UART 等外设?

    当使用 basic_ble 工程时、连接间隔为 30ms、延迟为 0、我能够在两次连接事件之间进入待机状态。

    我最好的做法是您有一个 UART 等外设在连接期间仍处于打开状态的外设会阻止您进入待机状态。

    此致、
    Lea

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

    BlueJoule-GATT 基准测试规定(固定)中心应使用 7.5ms 的连接间隔且延迟为 0、这是 BLE5...中允许的最短时间

    我不使用 UART、并已删除所有这些菜单内容以尽可能减少我的内存占用量

    在任何情况下、“让 UART“开启都不会导致功率底值如此高...

    我的亮点(基于过去 TI BLE 栈在 2011 年回到原始 CC2540 的经验)是、连接事件之间的死区时间仅为~5ms、堆栈进入“空闲模式“、需要更少的进入/离开开销...  但这只是一个猜测:-)

    我在 Zephyr 上看到显著改善的结果表明、使用 CC2340R5 处理 7.5ms 连接是可能的:

    但接下来我们看一下使用仅消耗 8K 代码的专用 BLE 外设堆栈可能实现的效果:

    每个连接事件的指令要少得多--而且我只使用 Tx 和 Rx 命令和通用 PBE 补丁、所以我在自己的代码中处理 IFS 定时  无法让 BLE5 PBE 补丁为我工作、因此我回到了更原始的地方

    我的下一个实验--完全从 SRAM 运行我的专用 BLE 外设堆栈、这不仅缩短了执行时间、而且进一步提高了能效 (闪存/缓存关闭)…

    请继续关注…

    [BIOS] bob

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

    发布了另一份  关于 CC2340R5 的报告、这次深入研究了单个连接事件、以便将 Zephyr BLE 与基于  EM•脚本 平台的高度专业化外设实现进行比较...

    Zephyr BLE 消耗超过两倍的能量、在 150us IFS ...内交换入站/出站数据包后、由活动 CPU 产生大约 1ms 的额外“协议处理“  曲线该部分下的面积可能大于 RX/TX 本身

    后一个捕获还表明 EM•Script 实现在为下一个连接事件安排唤醒时间时过于保守----等待(假设)另外 250us 甚至会进一步降低此处消耗的 13uJ 能量……

    上面提到的报告还探讨了从 SRAM 执行代码与闪存/缓存...的影响  除了缩短有效执行时间外、还可以降低能耗----因为闪存/高速缓存基本上处于断电状态  不用说, 8K EM•脚本图像与 163K Zephyr 使这种优化成为可能..  FWIW、仅将 Zephyr 所需的 30K 数据存储器装入入门级 CC23xx 器件的 SRAM 已经是一项挑战...

    敬请期待更多…

    [BIOS] bob