[参考译文] CC1101：CC1101芯片状态...

您好！

首先、感谢您的快速响应。

peng lee 说：

IOCFG0的默认配置(复位值)为0x3F。 这意味着 S CLK_XOSC/192在 GDO0引脚上输出。

您是对的- 我使用的术语不是很正确。
这是典型设置 IOCFG0D = 0x06。

peng lee 说：

您没有说明您正在使用哪些设置(是否已启用校准，

我从一个 TI 示例开始、下载为"swrc021f.zip"、更明确的是使用"FREQ_868_CC1101"设置的"链接"示例。
作为参考、此示例位于  swrc021f.zip\C51\examples\Chipcon\srcf04\CCxx00\ex_link 中。
目前、我正在将这些设置与我自己通过 SmartRF Sdudio 生成的其他设置进行比较。

我 已经将代码的相关部分移植到了我的 MCU、即 Cortex M (STM32)、因此它肯定是不同的。

此时、我可以看到我的 CC1101寄存器设置生效了、所以我会重新读回这些设置进行 检查。
通过使用无限的 TX 环路和 SDR 应用、我可以看到会在868MHz 下发生一些实际传输。

具有两个相同的设置、我使用一个作为发送方、并尝试与另一个一起接收。
我可以在 调用接收函数时看到发送器报告了 Rx 模式、但还无法成功接收任何数据包。
地址设置为0、 关闭地址检查。 数据包长度设置为可变长度模式。

我仍在处理数据表、我想并没有得到每个细节。
目前我想知道 FIFOTHR 设置的情况、在本例中它是0x07。 我正在尝试发送32字节的数据包。

例如、ME 运行时寄存器转储。 我学到了 一个难以读回的方法,一个单字节读的 PARTNUM 寄存器...

配置寄存器--
29 2E 06 07 D3 91 FF 04
05 00 00 0C 00 21 62 76
2D 3B 13 22 F8 62 07 30.
18 1D 1C C7 00 B0 87 6B
F8 B6 10 EA 2A 00 1F 41.
00 59 7F 3F 88 31 09 00

状态寄存器--
-- 0F 4F 3F 1F 2 F 0F 0F
0f 0F 0F 0F 0F 0f 81 00

关于 FIFOTHR、您用它做什么？

如果您将代码基于  ex_link、则不使用阈值。

使用 CC1101时、可以写入用来发送和接收数据包的最简单的代码如下：

1) 1)按照 数据表中的第19.1.2节进行手动复位

2) 2)在 SmartRF Studio 中为推荐的某个 PHY 写入建议的寄存器

  等等

// Address Config = No address check 
// Base Frequency = 867.999939 
// CRC Autoflush = false 
// CRC Enable = true 
// Carrier Frequency = 867.999939 
// Channel Number = 0 
// Channel Spacing = 199.951172 
// Data Format = Normal mode 
// Data Rate = 249.939 
// Deviation = 126.953125 
// Device Address = 0 
// Manchester Enable = false 
// Modulated = true 
// Modulation Format = GFSK 
// PA Ramping = false 
// Packet Length = 255 
// Packet Length Mode = Variable packet length mode. Packet length configured by the first byte after sync word 
// Preamble Count = 4 
// RX Filter BW = 541.666667 
// Sync Word Qualifier Mode = 30/32 sync word bits detected 
// TX Power = 0 
// Whitening = false 
// PA table 
#define PA_TABLE {0x50,0x00,0x00,0x00,0x00,0x00,0x00,0x00}

static const registerSetting_t preferredSettings[]= 
{
  {CC1101_IOCFG0,      0x06},
  {CC1101_PKTCTRL0,    0x05},
  {CC1101_FSCTRL1,     0x0C},
  {CC1101_FREQ2,       0x21},
  {CC1101_FREQ1,       0x62},
  {CC1101_FREQ0,       0x76},
  {CC1101_MDMCFG4,     0x2D},
  {CC1101_MDMCFG3,     0x3B},
  {CC1101_MDMCFG2,     0x13},
  {CC1101_DEVIATN,     0x62},
  {CC1101_MCSM0,       0x18},
  {CC1101_FOCCFG,      0x1D},
  {CC1101_BSCFG,       0x1C},
  {CC1101_AGCCTRL2,    0xC7},
  {CC1101_AGCCTRL1,    0x00},
  {CC1101_AGCCTRL0,    0xB0},
  {CC1101_WORCTRL,     0xFB},
  {CC1101_FREND1,      0xB6},
  {CC1101_FSCAL3,      0xEA},
  {CC1101_FSCAL2,      0x2A},
  {CC1101_FSCAL1,      0x00},
  {CC1101_FSCAL0,      0x1F},
  {CC1101_TEST0,       0x09},
};

发送：

3) 3)在 TX 板上、将长度字节(32)+ 32个有效载荷字节写入 TXFIFO

4)选通 STX

接收：

3)频闪灯 SRX

如果监视电路板、则会看到 RX 和 RX 电路板上的 GDO0均有效和无效。

如果 RX 板上的此引脚上未发生任何情况、则意味着无线电没有接收到数据包。

如果您未收到任何信息、则可能是硬件出现问题。 你自己做了板,如果是,什么参考 您是否遵循了该设计。

Siri.

感谢您发送编修。

peng lee 说：

关于 FIFOTHR、您用它做什么？

如果您将代码基于  ex_link、则不使用阈值。

[/报价]

我想它没有真正的影响,至少我理解它。

peng lee 说：

使用 CC1101时、可以写入用来发送和接收数据包的最简单的代码如下：

1) 1)按照 数据表中的第19.1.2节进行手动复位

[/报价]

我要尝试一下。
如前所述、我曾看到 GDO0使用逻辑分析仪对 Tx 尝试进行置位。
我愚蠢地尝试它通过单步调试器之前...
到目前为止、我还无法 正确接收数据包。
我将使用您的建议设置进行尝试、并 通过 RTL-SDR 应用程序确认正确发送。

至于配置设置、我主要使用来自链路示例的设置、但 PKTCTRL0/PKTCTRL1 和 PKTLEN 值除外。
我已经使用 SmartRF Studio 创建了寄存器设置、但它们基本上是相同的。

我使用的硬件是商业电路板、接线由我自己完成。
指向 Shop AD for module 的链接(虽然不是英文) : www.makershop.de/.../
这些模块的广播频率为868MHz。
据我所知、信号频率不受 CC1101的限制、而可能受板上的频带滤波器的限制。  
 此板没有原理图。

尽管我从发送器芯片获得了合理的 SPI 响应、并看到石英振荡器(26.0MHz)与 SmartRF Studio 的默认 设置相匹配、并提到了链接示例设置。
作为天线、我焊接在大约6.5英寸(大约17厘米)的导线上。

PS：
检查 SmartRF Studio 寄存器设置时、我看到很多记录在案的寄存器缺失。
我假设这些值对频率、调制和 数据包设置没有实际影响、并将保留记录的默认值。

[/quote]

好的。 使用 SmartRF Studio 中的设置。 仅写入代码导出中显示的寄存器。 对于初始测试、不对  PKTCTRL0/PKTCTRL1 和 PKTLEN 寄存器执行任何操作(无需传输32字节的数据包)。

您从 Studio 获得的设置将无线电配置为可变数据包长度模式、这意味着您需要将数据包长度作为第一个字节写入 TXFIFO：

例如：32、Data1、Data、2、..... 、Data31、Data32 (总共33字节被写入 TXFIFO)

我不熟悉您正在使用的硬件、但我假设当它用于868MHz 时、它可以在整个频带(779 - 928MHz)中使用。

Siri.

如果我可以添加相关的跟进问题...

如果启用了可变大小数据包并且在 Tx 侧以适当的长度字节为前缀、则此长度字节为 不会 Rx 侧消耗的所有能量、对吧？
换句话说 、它留在 Rx FIFO 中、必须由 MCU 进行处理。
数据表明确指出地址字节(如果被启用)留在 Rx FIFO 中、以及两个可选附加的状态字节(CRC、LINK、RSSI)。
在 长度字节方面、文档没有那么明确。

我提出问题的原因是在调试过程中观察到的内容有点令人困惑。
我在发帖后继续进行调试、能够更深入地进行深入探讨。

我观察到、对于第一个 Rx 数据包、长度字节"丢失"。
RXFIFO 寄存器少报告一个字节、从 FIFO 读取的数据中实际上缺少长度字节。

该设置使用可变长度模式(PKTCTRL0 = 0x05、PKTCTRL1 = 0x0)和固定数量的具有已知内容的数据字节(长度字节、后跟32个字节、索引=值)。  Tx 设置每秒反复发送相同的数据包、并且 在我开始调试接收器之前已经运行了几分钟。

所有 后续的 Rx 数据包都延长了一个字节、并以预期的长度字节作为前缀。
 否则、两种情况下的数据包内容都是正确的。

这不是让我困扰很多、但在勘误表文档的数据表中找不到任何有关该行为的提示。

我的 接收代码几乎与 TI 示例中的代码相同。 函数名称、typedef 和注释大部分保留为原样：

uint8_t  PckReceive (BYTE *rxBuffer)
{
  UINT8 pcklen, bytes;

  halSpiStrobe (CC1101_SRX);

  // wait for GDO0 to toggle
  wait_GDO0_high ();
  wait_GDO0_low ();

  // this status register is safe to read since it will not be updated after
  // the packet has been received (See the CC1100 and 2500 Errata Note)
  bytes = (halSpiReadStatus (CC1101_RXBYTES) & BYTES_IN_RXFIFO);
  if (bytes == 0)
    return 0;

  // Read data from RX FIFO and store in rxBuffer
  if (bytes <= BUFFER_SIZE)
  {
    halSpiReadBurstReg (CC1101_RXFIFO, rxBuffer, bytes);
    return (bytes);
  }

  // ...else
  halSpiStrobe (CC1101_SIDLE);
  halSpiStrobe (CC1101_SFRX); // Flush RX FIFO
  return FALSE;
}

如果您使用 SmartRF Studio 中的建议设置、它们会使用可变数据包长度模式并附加2个状态字节。

这意味着如果从空 RXFIFO 开始、并且在数据包接收信号生效之前不检查 FIFO、则可以从 RXBYTES 寄存器中读取 NUM_RXBYTES。

如果长度字节为32、RXBYTES 将为35 (I length 字节(32)、32个有效载荷字节和2个状态字节)

如果您发送以下数据包：

0x20、DATA1、Data2、…、Data32、 CRC1、CRC0

您无法接收 DATA1、Data2、…、Data32、Status1、 STATUS0_、而 RXBYTES 为34

如果 RXBYTES 显示34、这意味着长度字节存在错误、并且 RXFIFO 中的第一个字节为31 (0x1F)。

如果您有使用推荐设置并从 RXBYTES 读取34个数据以及从 RXFIFO 中第一个字节读取32个数据的测试用例、请分享一个显示此情况的 SPI 图。

 Siri.

抱歉、

最近调试花了我一点时间。

我检查了发送的字节数和顺序、但似乎没有错误、因为我首先怀疑。
但是、我 在进入 Rx 模式之前添加了 Rx-FIFO 刷新、结果现在一直相同。
这意味着第一个数据包与随后的数据包没有什么不同。

对于发送33字节(32个数据字节+前缀大小)、我接收到34个字节。
相关设置为 PKTCTRL0 = 0x05、 PKTCTRL1 = 0x00 (CRC 启用、可变大小、无地址检查、无附加、无自动刷新)。
在一次总 存取中完成对发送数据包的写入和对接收 FIFO 的读取。

我在调试控制台上打印相关的值、它们看起来是这样的：

RXBYTES = 22
PCK 数据：
21 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F FF
RXBYTES = 22
PCK 数据：
21 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 8C.
RXBYTES = 22
PCK 数据：
21 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
联系我们93.

所有值均为十六进制。
RXBYTES 值是状态寄存器内容。
第一个数据字节是大小、这是我在发送例程中写入的值。
不确定 最后一个值是什么、我 禁用了 append_status 位。
由于 CRC 对于相同的数据是相同的、因此也不能是 CRC。

peng lee 说：

如果长度字节为32，RXBYTES 将为35 (I length 字节(32)、32个有效载荷字节和2个状态字节)

我对这种情况的解释是、在本例中我应该会得到33 (0x21)、即禁用附加。
或者这不正确吗?

我不确定我是否理解问题所在。

SYNC 后接收到的第一个字节为0x21 (33)、之后传输接下来的33个字节。 这意味着总共34个字节放置在 RX FIFO 中、这也是 RXBYTES 寄存器正确显示的内容(0x22 = 34)(无附加状态字节)

您是否声称正在向 TXFIFO 中写入除0x21以外的另一个长度字节？

如果您要与我分享您的 TX FIFO 写入和 STX 选通以及 RX 端 SPI 通信的 SPI 图(所有4条线)。

你好,不确定我是否理解这一点。。。  

我实际上会写入33个字节(0x21)-首先写入一个长度字节、然后写入32个(0x20)数据字节。
因此、我希望接收33个字节、而不是34个字节。
我不确定该额外字节(末尾)是什么。

我也不知道该怎么说。"
在紧接 TX 选通之前从发送器读回 TXBYTES 寄存器值时、我得到了0x21/33、这符合预期。
将发送器和接收器都设置为 固定的数据包长度(PKTCTRL0 = 0)、我得到了预期结果、32字节。

peng lee 说：

同步后接收的第一个字节(无线电)为0x21 (33)，在此之后将接下来的33个字节放在无线空间中。 这意味着总共有34个字节放置在 RX FIFO 中、这也是 RXBYTES 寄存器正确显示的内容(0x22 = 34)(无附加状态字节)

这一点我不能完全理解。
正如您 所说的、这似乎意味着长度字节本身 是  包括在长度值中。 因此、对于 后面的数据字节0x20、我必须给出值0x20、而不是0x21、对吧？
我曾经包括长度字节本身-这可能不正确。
解释了很多 -这种随机的最后一个字节可能不是填充字节或未写入 Tx FIFO 的内容。

因此、我认为问题在于我这边的数据表解释。
我可以设置逻辑分析仪会话、并提供 PulseView 结果文件或屏幕截图。
但我认为这 可能没有必要。

如果这确实正确、并且在计数中包含长度字节本身不正确、您可以将该线程标记为已解析。

非常感谢您的光临,为您带来的不便我们深表歉意! ；-)

如果要传输32个有效载荷字节、则长度字节应为32：

您应该向 TX FIFO 写入：

0x20, // Length

0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, 0x20 // 32 bytes of payload

该长度总共为33字节(1个长度字节+ 32个有效载荷字节)、TXBYTES 应为0x21

如果您要将0x21作为长度字节写入 TX FIFO、将32个字节以上、则 TX FIFO 将下溢、并且在 RX 端、您将接收34个字节(因为长度字节为0x21)、 并且您的最后一个字节将是噪声、因为这是发送器未发送的内容(已下溢)。

Siri.