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.

[参考译文] CC3351:CC3351 低功耗模式/企业级开启 MCU

Guru**** 2752855 points

Other Parts Discussed in Thread: CC3351, CC3551E

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1612283/cc3351-cc3351-low-power-modes-enterprise-on-mcu

器件型号: CC3351
主题: CC3551E 中讨论的其他器件

我们已实施 8.1 RTOS 端口并已进行测试。

CC3351 数据表第 6.18 节给出了 330uA 的睡眠消耗数据。 我们可以使用 RTOS 版本 8.1 中的 Wlan_Stop 方法重现关断图 (10uA)。 更改 PS 或 PM 模式并不能为我们提供这个数字。 空闲大约为 13mA。 客户端发现 SPI 上的 5 秒启动时间过高、需要的时间更短。 睡眠模式是否可以避免每次唤醒都重新加载固件? RTOS 端口似乎不包含用于激活此睡眠模式的命令、并且所有 PS/PM 模式(两种模式均为 0-2)均不能实现此电流(与网络断开连接)。 我们注意到 Linux 低功耗模式执行与 RTOS 固件相同的操作、即发送“STOP"命令“命令、然后在恢复时下载固件、并使用可选的电源移除。  什么状态描述了睡眠消耗以及它是如何激活的? 我们在 CC3351 BP 上测量 1V8 电源轨。

或者、客户端在将来建议我们可以考虑从 SPI 移植到 SDIO(如果这是缩短引导时间的唯一方法)。 1b 20MHz SPI -> 4b 50MHz SDIO 建议在数据传输期间改善系数 10(我们知道,将有开销等待模块完成,例如处理固件数据包)。 我们假设 SPI 命令集在目标上以并行 SDIO 模式运行、即不使用 CMD 线路传输命令。 如果是这样、这将减少命令以及有效载荷数据(例如固件)的传输时间。 请确认。

在安全性方面、RTOS 固件支持密码安全性、而不是证书、而不是 PMF。 两者都是由客户端请求的。 Linux 端口支持两者。 在我们考虑将特性从 Linux 移植到 RTOS 之前、这是否应该起作用、即是否向 RTOS 和 Linux 端口提供了相同的固件和命令集? 如果我们从 Linux 移植证书传输和激活、是否需要相同的命令集在 RTOS 上有效?

TIA。

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

    您好、Peter:

    睡眠模式是否可以避免我们每次唤醒时都重新加载 FW?

    如果您需要绝对较低的功耗、那么是的、关断电流消耗最低、随后需要在每次启动时进行固件下载。

    CC3351 数据表第 6.18 节给出了 330uA 的睡眠消耗数据。 我们可以使用 RTOS 版本 8.1 中的 Wlan_Stop 方法重现关断图 (10uA)。 更改 PS 或 PM 模式并不能为我们提供这个数字。 空闲约为 13mA

    让我再看看这一点。 我需要查看 MCU RTOS SDK 是否支持睡眠模式以实现这种电流消耗。

    如果这样做、则会缩短命令以及有效载荷数据(例如 FW)的传输时间。 请确认。

    是的、当然可以。 使用 4b SDIO 肯定会增加从主机 MCU 返回到 cc3351 的数据和吞吐量。

    这两项均由客户端请求。

    我们正在开发 PMF 支持、尤其是 WPA3。 因此它还没有、但将在下一个版本 (R9) 中提供。 您在帖子的标题中提到您正在寻找企业安全。 您是否仍需要这样做? “不是证书“是什么意思?

    是否为 RTOS 和 Linux 端口提供了相同的固件和命令集? I [/报价]

    编号 这些是不同的固件和驱动程序。 请勿直接将 Linux 移植到 RTOS。 在 RTOS 中、您仍然可以使用 SDIO。  

    如果您有另一个使用 SDIO 的 MCU、并且希望设计电路板以使用 SDIO 与 cc33xx 器件的通信、则需要实现您自己的 SDIO 层。 SDK 提供了一个名为“dio_adap.h"和“和“bus_sdio.c"的“的 SDIO 文件。 您需要根据器件上使用的 SDIO 总线实现这些文件、以启用通信。 我们提供了接头、但需要完成 SDIO 编程/实现层。

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

    谢谢 Sabeh。

    关于安全性、客户端已请求 RADIUS 支持各种身份验证方法、包括 EAP-TLS、EAP-TTLS 和 WPA3 企业版。 我们预计本周将制定测试计划。 为了确保证书安全、似乎没有直接的方法将证书加载到构建中、但我们仍在阅读网络终端演示。

    您是否有 R9 的大致目标日期? 我们知道在发布之前没有日期是最终的、因此不会让您接受。

    FYI 此客户端使用 Zephyr、它部分支持以下部分内容: https://docs.zephyrproject.org/latest/connectivity/networking/api/wifi_credentials.html 

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

    您好、Peter、

    您计划运行基于 Zephyr 的哪个 MCU? 您能说明一下吗?

    cc33xx 的 MCU+ SDK 解决方案不支持企业连接。 但是、cc35xx 系列器件支持 Zephyr、cc35xx 系列器件也支持 Zephyr。  您是否希望此器件结合使用主机 MCU 和 WiFi? 我想象单芯片解决方案比双芯片更低的成本、甚至更低的功耗。

    您可以在以下位置阅读有关 cc35xx 系列器件的更多信息: https://www.ti.com/product/CC3551E 

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

    客户端已请求 STM32U575。

    RTOS SDK 提到 EapMethod、但没有定义 EapMethod。 wifi host_driver.lib 中是否采用二进制提供的形式? 如果是、我们没有具体的实施细节。

    我相信客户(英国)已获悉 CC3551E 将于 2026 年第 4 季度上市。 客户希望本月 2026 年 2 月为产品布置开发板。 “支持即将到来“对于这项工作来说可能还不够。 是否有计划的 MCU R9 发行日期?

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

    您好、Peter、

    我不确定 您提到的 Q4 2026 日期是什么、因为 cc3551E 已推出。 此器件已在 202 年第 4 季度公开发布 5. 您可以在上面的链接中看到“活动“标记。

    由于目前正在开发的 R9 版本、我们还没有发布日期、因此我只能假设我们将在第一季度或第二季度初公开发布内容、因为我们正在解决问题并添加功能。 请注意、许多客户需要 R9 支持、因此我们的首要任务是尽快与客户分享。

    但是、我想与您澄清的是企业支持。 这是否是您和您的客户的严格要求? 它目前无法正常工作、可能也不会出现在下一个版本中、同时还增加了 WPA3-PMF 支持。 如果企业是硬性要求、我建议评估 cc3551E 设备。

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

    谢谢 Sabeh。 企业支持是此客户端的硬性要求。