【TI 无线主题征集】+CC1101/CC1100之调试心得

平行电

【TI 无线主题征集】+CC1101/CC1100之调试心得 [复制链接]

之前做过TI的无线，还是因为那款Chronos-ez430，中间为了和小车匹配，买了一对CC1101的无线模块，在调试的时候也遇到了一些问题。
说道CC1101这些芯片，确实很强大，通过TI官方的smartrf软件可以生成需要的寄存器配置，但是不太好理解的就是加入了协议之后，做多点通信的调试。这个做了很久，最后因为选用的芯片RAM实在不大G2553，试着加入协议栈之后放不下，只能作罢，但是从网上找了一个简化版之后，修改参数之后可以使用。
说道这款芯片，最大的特点大概是对中断引脚的配置了。
#define         GDO0H        P1OUT|=BIT0;
#define         GDO2H        P1OUT|=BIT5;

以上两个引脚就是接收中断的反馈引脚了。提示是否接收到数据，接收到后置高。
#define CCxxx0_IOCFG2       0x00        // GDO2 output pin configuration
#define CCxxx0_IOCFG1       0x01        // GDO1 output pin configuration
#define CCxxx0_IOCFG0       0x02        // (P1IN&0X01)==0X01 output pin configuration

这里就是配置为输出中断为GDO0
while ((P1IN&0X01)==0X01)
        {
                delay(2);
                --i;
                if(i<1)
                   return 0;             
        }         
    if ((halSpiReadStatus(CCxxx0_RXBYTES) & BYTES_IN_RXFIFO)) //如果接的字节数不为0
        {
        packetLength = halSpiReadReg(CCxxx0_RXFIFO);//读出第一个字节，此字节为该帧数据长度
        if (packetLength <= *length)                 //如果所要的有效数据长度小于等于接收到的数据包的长度
                {
            halSpiReadBurstReg(CCxxx0_RXFIFO, rxBuffer, packetLength); //读出所有接收到的数据
            *length = packetLength;                                //把接收数据长度的修改为当前数据的长度

            // Read the 2 appended status bytes (status[0] = RSSI, status[1] = LQI)
            halSpiReadBurstReg(CCxxx0_RXFIFO, status, 2);         //读出CRC校验位
                        halSpiStrobe(CCxxx0_SFRX);                //清洗接收缓冲区
            return (status[1] & CRC_OK);                        //如果校验成功返回接收成功
        }
                 else
                {
            *length = packetLength;
            halSpiStrobe(CCxxx0_SFRX);                //清洗接收缓冲区
            return 0;
        }
    }
        else
        return 0;

这里就是判断是否接收到了数据，接收到了就再判断数据的长度是否正确。

前面的这几步可以把无线调通，但是距离和效果这就要靠硬件修改了。
加距离：首先要用好的天线，最好是带增益的，频段433MHz，接收和发射最好用一样的，曾经用两个不同的同一频段天线试了，效果没有同款的好。
天线的方向也影响接收的效果，最好是同一方向。
软件内部的增益设置，这个根据需要去配置，有功耗要求的就只能想想加个中继之类的了。
另外就是模块的板子了，淘宝很多都是抄板的结果，效果有好有坏，但是从搜集的资料看：
手表的范围不超过5m，我用的模块在100m，可穿墙，网上有人做到几公里。
CC1101.rar (569.46 KB, 下载次数: 27, 售价: 3 分芯积分)

2014-10-25 16:27 上传

点击文件名下载附件
售价: 3 分芯积分  [记录]

CC1101.rar (569.46 KB, 下载次数: 27, 售价: 3 分芯积分)

2014-10-25 16:27 上传

点击文件名下载附件
售价: 3 分芯积分  [记录]

平行电

补充一点，这个接收出现误码是很多因素造成的，如果有要求，只能软件加入滤波纠错之类的算法去优化了

提枪打大鸟

你好，我用的是 STC 51 加 STM32 的 U 做的 CC1101双向通信。从 STM32 发送出去的数据 STC 端能正确接收，从 STC 端发送出去的数据 STM32 也能正确接收。但是以上情况是在一方发送一方接收的情况下可行。我从 STM32 端发送命令，STC 端接收命令（正常），处理完之后回复给 STM32，但 STM32 端接收不到 STC 端的回复。我个人理解是在发送完之后没有进入接收模式，请问这种情况是什么原因？

平行电

提枪打大鸟 发表于 2015-12-17 17:54
你好，我用的是 STC 51 加 STM32 的 U 做的 CC1101双向通信。从 STM32 发送出去的数据 STC 端能正确接收， ...

可以做个交叉实验，接收再发送-》接收端RESET接收，RESET发送-》发送后接收，看看结果，确定问题发生的环节，再Debug确定细节

提枪打大鸟

平行电 发表于 2015-12-17 19:03
可以做个交叉实验，接收再发送-》接收端RESET接收，RESET发送-》发送后接收，看看结果，确定问题发生的环 ...

谢谢，不过我昨天下班的时候找到原因了，是在主机的接收函数上，由于没有初始化接收长度的那个变量，在我用的编译器中 RecvLength 只定义了，未初始化，默认值应该是 0. 接收函数中有做接收长度的比较。因为接收到的长度会比预计接收的 RecvLength 小，所以会丢弃数据包. 而我在做单独测试的时候因为是给定几个数据，接收的时候也就给定了长度，所以可以成功接收。不过我还是觉得有点牵强...不过这样做之后发现数据接收和发送也变得很稳定。
你的方法很值得考虑，我也一直在做交叉试验，不过我没考虑到 RST . 还是我考虑的不够。总之谢谢了，以后有问题还向你请教。谢谢了！

RobotHuBal

楼主，请教一个问题，我在调试CC1101时，每次操作SPI一次之后，然后就会死在while（MISO），这个到底是什么原因造成的，请指教，谢谢。