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.

[参考译文] CC1352R:具有 Contiki 网络堆栈的 DMM 处于传播模式中、并采用 TI BLE5

Guru**** 2442090 points
Other Parts Discussed in Thread: CC1352R, LAUNCHXL-CC1352R1

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

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1210060/cc1352r-dmm-with-contiki-network-stack-in-prop-mode-radio-and-ti-ble5

器件型号:CC1352R

您好!

我正在开发的器件的一个旧代码项目、该项目使用 Contiki OS、在平台 srf06-cc26xx 上移植其网状网络堆栈、并将无线电配置为 Sub-GHz 传播模式。 我需要将此解决方案移植到新版本的器件中、该器件使用 CC1352R MCU (基于 LAUNCHXL-CC1352R1的电路板)、以便将低于1GHz 的无线电与蓝牙完全结合使用、 并确保低于1GHz 解决方案的向后兼容性(新器件需要与 Contiki 兼容的网状网络中的旧器件配合使用)。

AFAIK、CC1352R 没有 Contiki 端口、该 MCU 只有 Contiki-NG 端口。 尽管如此、即使是这个也不使用 SimpleLink CC13xx 和 CC26xx SDK 中的 TI BLE5堆栈、(我认为)这是这些 MCU TI 系列上蓝牙应用的最佳选择。 另一方面、TI BLE5堆栈在技术上可针对不同的 RTOS 进行移植、但已经可用并且已经过测试、可以与 TI-RTOS 和 DMM 配合使用来管理并发堆栈使用。 但是、没有可用作 TI-RTOS 端口和与 DMM 集成的 Contiki 网状网络堆栈。

因此、似乎有两种可能的方法来实现这一目的:

  1. 将 CC1352R、TI BLE5堆栈和 DMM (或自己的类似实现)移植到基于 Contiki 的项目。
  2. 将 Contiki 网络堆栈移植到基于 TI-RTOS 的工程(甚至是整个 Contiki、其中将作为 TI-RTOS 线程运行)、并将其与 DMM 和 TI BLE5堆栈集成。

所以我的问题,至少现在,更像是要求一个一般性的建议:

  • 根据您的知识和经验、哪种方法似乎更有意义?
  • 或者、也许有其他更好的方法?
  • 还是我误解了某件事,对这个问题进行了实质性的重新定义?

还将欢迎一些进一步澄清这一问题的准则和文件。 我已经从 TI 和 Contiki 上阅读了很多、但其中一个很难"转换"到另一个、从而建立一个共同的基础来了解它们可能的交互以及它们模块和层之间的实际关系。

此致

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

    Kamil,

    我的第一个想法是"为什么不使用已经有 DMM、BLE 和 SUB1的堆栈"、我想您已经查看过 https://dev.ti.com/tirex/explore/node?node=A__ABVUW-4dkl5RLK0Zg3wDkA__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST ?

    正如你知道的,社区已经转移到 Contiki-NG 几年前,我认为不会有任何更多的贡献在旧 Contiki repo。 您是否有办法使用新固件升级旧器件、从而消除向后兼容性的要求? 如果是、您希望保留 Contiki 的哪些关键特性?

    如果您一直需要使用旧的 Contiki 堆栈、您确定真的需要 DMM 吗? 如果您使用 BIM https://dev.ti.com/tirex/explore/node?node=A__AORV2P9xKyaQCr.Dunw8Rg__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST 、实际上可以在 BLE 模式下启动、然后重新启动到 Contiki (跳转到运行 Contiki 的映像)。 然后、您可以使用设计上的某个按钮切换回 BLE、这将强制其返回 BLE 模式。 如果 BLE 仅用于配置或更新、则可以考虑使用。

    Erling

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

    尊敬的 Erling:

    您确定是否真的需要 DMM [/报价]

    BLE 实际上用于服务目的(配置和固件升级)、 但我仍然需要同时支持 BLE 和 Sub-GHz、因为器件上没有按钮(实际上也不能轻松地对器件进行物理访问)、所以两个无线电都需要始终"动态"-这就是使用 CC1352R 的原因、这提供了这样的机会。 因此、不能使用 BIM 交换图像。

    为什么不使用已具有 DMM、BLE 和 sub1的堆栈

    SimpleLink 提供了有关 DMM 使用的良好且非常有用的示例、我想将其作为框架和 BLE5集成的基础、但是也不可以选择 TI 15.4 Stack (或示例中提供的任何其他示例)、因为该协议栈需要与旧器件兼容、并且无法更改。 因此、需要 Contiki 网络堆栈、这些器件中已使用了这些堆栈。

    但是、不需要 Contiki 操作系统本身。 有些应用程序逻辑是使用 Contiki protothread 等编写的、但这可以重构为不受操作系统约束、并移植到 TI-RTOS 或任何其他 RTOS 中、这在这里不是一个大问题。 问题越多的是 Contiki 使用的网络堆栈、这是 Contiki 本身的一部分。 我只需要以与此堆栈兼容的方式使用低于1GHz 运行、因此从理论上讲、我不需要 Contiki、我只需要 Contiki 或类似 Contiki 的网络堆栈。 但它不能作为单独的模块提供(不是吗?)、并且它没有替代实现(或有替代实现?)、所以这就是我尝试解决从 Contiki 中移植 Contiki 网络堆栈的原因。 或者将剩下的东西从 Contiki 移植到 Contiki 中、但我倾向于前者。

    Kamil

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

    Kamil,

    我看到的另一种选择是继续在一个器件上使用 ContikiOS、然后添加一个廉价的 BLE 芯片、例如  适用于 BLE 的 CC2340 www.ti.com/.../cc2340.html。 然后、您将通过双无线电设置实现真正的并发性。 从软件角度来说也要轻松得多。

    如果您打算移植类似 Contiki 的网络堆栈、我会先从 TI-RTOS 和 DMM 示例开始、然后在其基础上添加堆栈。 这样、您就为经过良好测试的较低级别(驱动程序)建立了坚实且经过测试的基础、并且您无需执行"驱动程序级攻击"。