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

[参考译文] CC1100：CC1100勘误表中建议的变通办法，以阅读TXBYTES不适用于RIOT OS

admin
Guru**** 2468610 points
Other Parts Discussed in Thread: CC1100, CC1101, CC2650STK

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/637852/cc1100-suggested-workaround-in-errata-of-cc1100-to-read-txbytes-doesn-t-work-in-riot-os

部件号：CC1100
主题中讨论的其他部件： CC1101， CC2650STK

您好，

使用CC1100作为收发器的MSBA2板[3]上的RIOT OS [1]无法读取TXBYTES状态寄存器。 根据CC1100 [5]的数据表中引用的勘误表文档[4]，此寄存器应读出两次，直到两个值相同为止。 遗憾的是，对于当前版本的RIOT OS [6]，此操作失败，因为两个读取都不会导致读取相同的值。 因此，循环永远旋转。 因此，操作系统在启动时挂起。 是否有任何解决方法可以使解决方法正常工作？

此致，
Marian

[1]： https://riot-os.org/
[2]： https://github.com/RIOT-OS/RIOT/
[3]： https://github.com/RIOT-OS/RIOT/wiki/Board%3A-MSBA2
[4]： http://www.ti.com/lit/er/swrz012d/swrz012d.pdf
[5]： http://www.ti.com/lit/ds/symlink/cc1100.pdf
[6]： https://github.com/RIOT-OS/RIOT/issues/6857

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

    Marian，

    我们对该操作系统的了解不多，但您提到的勘误表很少发生，而您写的是它始终发生。 因此，我认为它们是另一个错误，我猜是主机MCU SPI端口的配置错误。 发生的典型配置错误是，主机MCU被配置为在上升沿采样，而CC11x器件在SPI时钟的下降沿采样。 我建议使用示波器，并根据两个器件的数据表验证SPI通信是否正确。

    此致，

    /TA

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

    非常感谢您的回复。

    遗憾的是，由于缺少设备，我无法确认SPI通信是问题的根源。 然而，这是迄今为止对这些问题最合理的解释。 此外，该问题是由于承诺对防暴的SPI实施进行重大重构而引起的。

    该文档说明：

    在RX模式下，当GDOx_INV=0时，CC1100会在下降沿上设置数据。
    在TX模式下，当GDOx_INV=0时，CC1100在串行时钟上升沿采样数据。

    而RIOT驱动程序将SPI配置为上升边缘模式。 我没有硬件背景，无法理解上述两句话。 有人能不能改述CC1100在哪些情况下期望在下降边缘传输？ 驾驶员如何指示它保持在上升边缘模式？

    非常感谢！

    此致，

    Marian

  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我在MSBA2板上找不到太多信息。 这是开放源代码，您必须自己制作主板还是自己制作主板？ 换一个说法，为什么主板使用CC1100，而不是CC1101？ CC1100已成为NRND一段时间。

    "
    在RX模式下，当GDOx_INV=0时，CC1100会在下降沿上设置数据。
    在TX模式下，当GDOx_INV=0时，CC1100在串行时钟上升沿采样数据。
    "
    这与SPI接口无关，而是用于同步串行模式，如果使用FIFO，则不使用同步串行模式。 有关SPI接口的详细信息，请参阅《用户指南》中的第10章。

    您是否只是TXBYTES有读取问题？ 您是否已验证SPI接口是否可以读取/写入其他寄存器？

    为什么您首先进行轮询而不是中断驱动？
  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好，

    MSBA2板 由柏林自由大学的博士设计。 它相当旧，我假设CC1101当时不可用。 它的后续产品 MSB-IoT板使用CC1101。 因为我的博士主管是Fu Berlin的教授，所以他得到了一堆板。

    我目前正在尝试为学生恢复这些板，以便他们可以学习嵌入式C编程。 两个模块对CC1100/CC1101收1101收发器使用相同的驱动器。 有趣的是，读取TXBYTES寄存器的问题仅存在于MSBA2 (CC1100，CPU=lpc2387)上，而不存在于MSB-IoT (CC1101，CPU=stm32f415rg)上。

    我不知道为什么轮询比中断驱动的操作更受欢迎，而且驱动程序的作者目前不在。 我目前无法选择重写驱动程序而不进行轮询，因为我没有时间这样做。 目前我甚至没有关于芯片或防暴驱动器框架的必要知识，因为我是这个主题的新知识。 因此，仅收集所需的知识就需要几周时间...

    因此，我很乐意快速解决问题。

    >这与SPI接口无关，而是用于同步串行模式，如果使用FIFO，则不使用同步串行模式。

    有问题的代码是 

    执行｛
res1 = SPI_TRANSFER_REG(Dev->params.SPI, SPI_CS_UNDEF,
(地址| CC110X_read_burst)，CC110X_NOBYTE)；
res2 = SPI_TRANSFER_REG(Dev->params.SPI, SPI_CS_UNDEF,
(地址| CC110X_READ_STREAD)，CC110X_NOBYTE)；
} while (res1！= res2)；

    其中res1和res2连续返回不同的值。 因此，此处只执行SPI通信。

    此致，

    Marian

  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您是否只能使用MSB-IoT电路板？

    这听起来像是SPI问题，而不是芯片问题(或可能是组合问题)。 您是否已尝试监控此环路中的SPI接口以详细查看发生的情况？
  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好，

    非常感谢您的回复。 虽然我没有逻辑分析器，但我也坚信这是SPI问题。 我添加了一些调试信息，并通过发送SNOP命令探测器来获取状态字节来跟踪芯片的状态。 从芯片接收到的所有数据根本没有意义，例如，我始终获得14个字节的FIFO可用性，即使在STX命令探测之后，状态仍保持RX。 我注意到驱动程序在通信基元级别锁定SPI接口-因此SPI总线上的互斥锁多次，例如用于发送数据包。 通过对SPI-API进行主要重构，这些锁将启用SPI总线，而释放锁将禁用SPI总线以节省电源。 我相信如此频繁地打开和打开SPI可能会导致问题。 无论如何，这不是一件恰当的事情：发送三个命令探测器时，SPI总线应在...之间保持启用状态。

    我只能使用MSB-IoT主板。 但是，驾驶员在该处也无法正常工作-仅出现不同的症状。 我假设一个主板解决问题将同时解决这两个主板。 由于这个星球上只剩下16块MSB-IoT板，所有板都在我的办公室，所以我首先从MSB-A2开始。 但也许我也是他们的最后一个用户...

    也许我会在下一个中期休息时重写整个驱动程序。 至少我会以这种方式学到很多东西。 或者，我们可以分配一些资金购买更新的，使用更广泛的硬件，以便其他防暴用户可以协作编写和维护驱动程序。

    此致，

    Marian

    附注：我将此问题标记为“已关闭”，因为我现在几乎可以确定它与防暴相关，而不是与CC1100/CC1101收1101收发器相关。

  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    出于好奇，要求必须是运行Rios操作系统的主板？
  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是的，要么是这样，要么是我必须向它报告骚乱。 我的博士主管是RIOT的作者之一，所以他自然有兴趣获得他的博士学生;-)

    但是，尽管RIOT仍有一些粗糙的边缘(如维护不善的CC1100/CC1101驱动1101驱动程序)，但它确实是物联网的有趣操作系统。 例如，由于POSIX合规性，我只需对RIOT进行少量修改就可以运行我的大多数代码。 因此，我非常期待与RIOT合作。
  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我看到在将Rios迁移到 github.com/.../Board:-CC2538DK 和 github.com/.../Board:-CC2650STK上已经做了一些工作 ，您是否考虑尝试让它在CC13xx或CC26xx Launchpad上运行？ 这将为您提供一个相对便宜且灵活的平台。
  • 0
    TI__Guru**** 2468610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    感谢提示。 事实上，我的大学在他的办公室里有一些CC2650STK，但没有时间去处理这些问题。 也许现在是让他们仔细观察的好时机。 特别是紧凑，有一个真正吸引人和有力的外壳，使他们成为学生借出这些东西的理想之地:-)

    另外，对802.15 4和BLE的支持也很好。 当然，我们的学生永远不会在应用程序层下面的OSI层上工作，因此实际技术并不重要。 但是，使用最先进的技术可以很好地推动这些技术的发展。