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

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

0

Решение

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

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

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

2

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector