• 状态 Resolved
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 0 订户
  • 视图 261 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] LAUNCHCC3220MODASF：LAUNCHCC3220MODASF

admin
Guru**** 2589280 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/677766/launchcc3220modasf-launchcc3220modasf

器件型号：LAUNCHCC3220MODASF

我正在使用 RAW 模式套接字(L1原始模式)在项目中进行一些数据交换。

SL_Send 似乎没有立即开始传输、并且需要一些任意时间来传输传递给它的数据包。

  1. 导致这种情况的原因是什么？   
  2. 我可以避免它并确保 sl_Send 更可预测(更直接)的数据包传输吗？  

--

谢谢、此致、

Neeraj Sallh

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

    1.发送数据包之间有多长时间的延迟？
    2.是阻塞还是非阻塞？
    3.您以何种速率发送数据包？

    此致、
    查尔斯·奥
  • 0
    TI__Guru**** 2589280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Charles、

    1. 一个节点就像测试仪一样、希望另一个节点将原始数据包回送至测试仪。
    2. 测试仪节点发送一个数据包、在接收到响应时发送另一个数据包。  这发生在循环中。
    3. 往返时间为24ms。  而如果考虑到所选速率为11Mbps、数据包大小为1500字节这一事实、则需要大约3ms (一侧为1.2ms * 2 +每个节点的一些处理裕度)。
    4. 3ms 和24ms 之间的差异很大。
    5. sl_Recv 调用是非阻塞式的。

    --

    此致、

    Neeraj Sallh

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

    对此进行的任何更新。

    同时、我在阅读原始套接字的编程人员手册时发现了一些信息。

    下面我会根据这一点提出问题。  这些还有助于满足我的射频 Tx 和 SL_Send 调用之间的立即/固定延迟要求。

    1。

    对于我在调用 sl_Send 后对射频上的即时/固定延迟 Tx 的要求、用于原始套接字的如下套接字选项"sl_SO_PHY_TX_TIMEOUT"是否会有所帮助？

    编程手册"swru455d.pdf"中提到的代码为：

          _u32超时= 0；

          RET = SL_SetSockOpt (radioTool_rawSocketdesc、SL_SOL_PHY_OPT、SL_SO_PHY_TX_TIMEOUT、&TIMEOUT、sizeof (TIMEOUT))；

          IF (RET)

          ｛

            返回-1；

          ｝

    2.

    此选项的用途是什么？  本文档未说明其用途。  禁用 CCA 覆盖时、它是否适用于原始套接字模式？

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

    sl_send()不会立即发送数据包的原因是，API 仅将数据包传输到网络处理器(NWP)，并请求 NWP 在提供的套接字上发送数据包。 NWP 是运行 RTOS 的 MCU、因此存在延迟、因为它可以执行一些其他操作或执行一些上下文切换等。

    sl_SO_PHY_TX_TIMEOUT 选项可用于设置使用 sl_send ()和 RAW 套接字时允许的延迟上限、但这无助于消除 sl_send ()延迟的固有可变性。 这是因为、如果 NWP 无法及时发送数据包、该选项所做的就是让它返回超时错误。 它不会以其他方式改变其行为。

    我希望这有助于消除您可能对 sl_send()和原始套接字造成的任何混淆。 如果您有任何疑问、请告诉我。

    此致、
    Michael
  • 0
    TI__Guru**** 2589280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    感谢 Michael 如此清楚地解释。

    虽然这种响应完全回答了推理部分和对这一事实的捕获、即为什么处于原始模式的数据包不会立即传输、但我的问题仍然是、我无法在原始模式下立即强制数据包输出。

    在原始模式下、是否有某种方法可以实现此目的？
  • 0
    TI__Guru**** 2589280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Neeraj、您好！

    由于我在上一篇文章中提到的原因，很遗憾无法保证 NWP 立即发送使用 sl_Send()传输的数据包。

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

    谢谢 Michael。

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

    您好、Michael、

    1。

    我知道 NWP 是一个 MCU、可能还在做一些其他事情、这可能会导致数据包通过无线电实际获取 TX 的时间发生变化。

    但是、我的应用程序不会触发任何网络、甚至与加密相关的事件。 Wi-Fi 模式也不是、而是原始模式、即 Wi-Fi 协议和 CCA 算法的可变性也不存在。

    因此、NWP 在 SL_Send 为其提供的数据包 TX 之外可能还会做些什么？ 如果应用程序可以避免触发此类活动、可能是我们可以通过无线电获得更好的可预测数据包 TX。

    2.

    套接字选项"sl_SO_PHY_TX_TIMEOUT"是否用于"阻塞"套接字、因此在套接字打开/配置为非阻塞时不有用？

    或者、选择此选项"sl_SO_PHY_TX_TIMEOUT"是否会使"非阻塞"套接字甚至成为 sl_Send 器件的"阻塞"套接字？

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

    即使在 RAW 模式下打开套接字、NWP 也可能正在处理某些中断、或者在执行 sl_Send()时处于其他繁忙状态。 您不能避免这种延迟行为，并且没有机制强制 NWP 使 sl_Send()以高于其当前使用的优先级执行。

    至于 SL_SO_PHY_TX_TIMEOUT 选项、该套接字选项稍有不同、因为它在 NWP 端设置了超时、而不是主机端设置了超时、就像常规 RX 超时选项那样。 由于 sl_Send()无法阻止，因此如果套接字被配置为阻塞还是非阻塞实际上无关紧要。 我必须进行一些测试以检查并了解当 sl_Send ()超时时 NWP 信号如何发送到主机处理器，但为了与您的情况相关，使用 sl_SO_PHY_TX_TIMEOUT 可能不会帮助您使您看到的延迟保持一致。 它只能防止大于 sl_SO_PHY_TX_TIMEOUT 设置的过长延迟。

    此致、
    Michael