• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 286 视图
  • 用户 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.

[参考译文] cc8530：(和 CC85xx)有关一台主机的多个从机的问题

admin
Guru**** 2537260 points
Other Parts Discussed in Thread: CC8530

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

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/588440/cc8530-and-cc85xx-questions-about-multiple-slaves-with-one-host

器件型号：CC8530

你(们)好

我也已经阅读了 cc8530的数据表和用户手册、但我仍然有几个问题、希望有人可以回答。 我希望使用 cc8530在一台主机和多个从机之间同时连接音频通道和边数据通道。 但我需要了解一些详细信息、以便进行延迟计算。

  1. 和多个从器件。 如果两个从器件订阅相同的信道 ID、它们是否都必须破解音频？ 或者、它们是否都必须破解音频、否则会重新传输？ 如果音频被重新传输、那么对其进行攻击的从器件是否不会重放重新传输？
  2. 是否可以限制重试音频数据包？ 我们是否可以让它完全不重试(因此、从器件将具有静默周期)？
  3. 是否可以更改已静默的从设备取消配对之前的时间？ 它的默认值是多少？
  4. 和多个从器件进行通信。 我们如何将同一数据报广播到多个从站(我们是否使用特殊的"广播"地址)？ 通过广播、是否所有注册的从站都必须对数据包进行攻击(以便它不会停留并阻止 FIFO 和所有后续传输)？

我知道我在这里要求提供大量详细信息、但我需要了解系统如何处理广播以及单个从站何时超出范围(它如何影响仍然存在的从站)。

感谢您提供的任何信息！

Brian

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

    让我与 PPW 开发人员团队核实一下、并在复活节后再次与您联系。

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

    谢谢、我真的很感激。 我期待着阅读答案--它将真正有助于对这个项目进行最后分析。

    希望你已经(并且正在)过了一个愉快的假期。

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

    以下是我们的 PPW 专家的反馈：

    1.在每个时隙中，所有从机都会应答层环缓冲区中的所有音频片(=样本块)。 如果没有从所有连接的从器件接收到 ACK、则存在一个延迟周期(2个时隙)、我们可以忽略射频条件较差的从器件中缺少的 ACK。 这减少了几乎超出范围或刚刚断电的从器件的影响。 如果从机已经接收到音频片段、它将忽略它、只需重新播放它的 ACK 位。
    2.不可以，这是不可能的。 它自然受到切片传输窗口的限制(准备传输->传输太晚)。 在生成闪存映像(在闪存编程面板中)的同时运行 Microsoft DebugView、以查看最大尝试次数和平均容量。
    3.不可以，这不能更改。 它硬编码为128个时隙(例如、320ms、时间长度为2.5ms)。
    4.数据端通道不支持广播。

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

    感谢您的详细答复。 它清除了很多领域--我只有两个领域，我仍然不确定：

    在从器件不堆叠的情况下--这对传输有何影响：
    1A。 如果从设备停止堆叠(比如电池发生故障)、主设备会做什么？ 它在生成时是否会重试所有样本块通过 DebugView 报告的次数、直到它在128个时隙后取消对从器件的配对？
    1b。 重试机制是否不会影响下一层传输窗口？ 那么、在我们转到下一个切片传输窗口后、它会停止为上一个窗口重新传输？
    1c. 保压期如何工作？ 它是否阻碍了重新传输？ 这是否只发生在被认为处于传输限制的从属器件上？ 在2个时隙保持周期之后会发生什么情况？

    关于数据侧通道
    2A。 如果一个数据包没有被应答(被寻址的从器件)、并且被重试、那么重试次数是否会受到某种程度的限制？ 在128个时隙后、安静的从设备未配对或更早时间？
    2b. EHIF 表底部有关主机控制设置的文档指出、在命令之后可能需要10ms 的时间、然后才能准备好下一个命令。 发送数据报的命令是否正确？ 或者，我能否每2.5ms 时隙发送一个新的数据报，只要该数据报被寻址的从站连接？

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

    这里的简短故事是、不堆叠的从器件不会影响到其他从器件的音频流。

    2.可以填充数据端通道数据包的 FIFO，在这种情况下，它将阻止通信。 在特定时间段后不会自动刷新或丢弃数据包。 外部主机也无法从数据包中接收 ACK。 建议建立一个乒乓机制、在这个机制中、主器件向所有从器件发送一个数据包、然后等待一个特定的响应返回。 某种手动 ACK。

    此致、
    Fredrik