Question

我通过串口连接设备。设备在big-endian模式下将CRC16标记附加到数据包的末尾。在软件方面，检查CRC的代码是这样的：

bool Protocol::checkCRC(const QByteArray &buf) {
    if(buf.size()<3){
        return false;
    }
    int len = buf.size()-2; // Exclude CRC token
    quint16 crc = 0xFFFF;
    quint16 claim = static_cast<uchar>(buf.at(buf.size()-1));
    claim*=0x100;
    claim+=static_cast<uchar>(buf.at(buf.size()-2));

    for (int pos = 0; pos < len; pos++)
    {
        crc ^= (quint16)buf[pos];         // XOR byte into LSB of crc
        for (int i = 8; i != 0; i--) {    // Loop over each bit
            if ((crc & 0x0001) != 0) {    // If the LSB is set
                crc >>= 1;                // Shift right and XOR 0xA001
                crc ^= 0xA001;
            }
            else                          // Else LSB is not set
                crc >>= 1;                // Just shift right
        }
    }
    return crc==claim;
}

我从this question复制了代码。

适用于小数据包。例如，使用此函数在CRC16检查中传递以下数据包：

0x04, 0x10, 0x00, 0x3d, 0xc1

报告的CRC为0xC13D，函数也计算0xC13D。但对于大数据包（在我的情况下为53字节），该函数无法计算正确的CRC：

0x34, 0x02, 0x02, 0x08, 0x14, 0x00, 0x00, 0x00,
0x00, 0x00, 0x10, 0x0a, 0xdf, 0x07, 0x0a, 0x39, 
0x1b, 0x02, 0x02, 0x79, 0x61, 0xbf, 0x34, 0xdd, 
0x0b, 0x83, 0x0f, 0x10, 0x03, 0x1b, 0x11, 0x02, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0xfc, 0x98

报告的CRC为0x98FC，但计算值为0xDFC4。

Answer 1

我不知道QByteArray类型是什么，但我会打赌它是签名字符的数组。因此，当一个字节的高位为1时，该符号位在转换为整数时会被扩展，该整数在crc ^= (quint16)buf[pos];处被排除在您的CRC中。因此，当您到达0xdf时，crc与0xffdf取代，而不是预期的0xdf。

所以问题不在于长度，而在于设置高位的字节的可能性。

您需要提供无符号字节，或修复转换，或者在与CRC进行异或之前对结果字节执行& 0xff。

CRC16 modbus计算为长数据包返回错误值

1 个答案: