Расчет CRC16 modbus возвращает неверное значение для длинных пакетов данных

Я подключаюсь к устройству через последовательный порт. Устройство добавляет тег 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;
}

Я скопировал код из этого вопроса.

Он отлично работает для небольших пакетов. Например, с помощью этой функции при проверке 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.


c++ qt crc crc16
person sorush-r    schedule 28.04.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я не знаю, что это за тип QByteArray, но держу пари, что это массив символов со знаком. В результате, когда старший бит байта равен единице, этот знаковый бит расширяется при преобразовании в целое число, которое все становится исключающим ИЛИ в ваш CRC в crc ^= (quint16)buf[pos];. Итак, когда вы добрались до 0xdf, crc было исключено-ИЛИ с 0xffdf вместо предполагаемого 0xdf.

Таким образом, проблема не в длине, а скорее в вероятности наличия байта с установленным старшим битом.

Вам необходимо предоставить беззнаковые байты, или исправить преобразование, или сделать & 0xff для результирующего байта перед исключающим ИЛИ с CRC.

person Mark Adler    schedule 28.04.2016
comment
из источников Qt: typedef unsigned short quint16 несмотря на то, что QByteArray содержит chars, он должен работать. Проблема заключалась в quint16 преобразовании в crc ^= (quint16)buf[pos], которое должно быть quint8 - person sorush-r; 28.04.2016
comment
Ах, верно, на самом деле подпись quint16 не имеет значения, поскольку повреждение уже равно единице, когда знаковый символ конвертируется в более крупный тип. (quint8) делает его беззнаковым перед преобразованием в более крупный тип. - person Mark Adler; 28.04.2016