CRC16 modbus計算爲長數據包返回錯誤值

我正在通過串行端口連接到設備。設備以大端模式將CRC16標籤附加到數據包的末尾。在軟件方面，檢查CRC碼是這樣的：CRC16 modbus計算爲長數據包返回錯誤值

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。

來源

2016-04-28 sorush-r

我不知道QByteArray類型是什麼，但我敢打賭，它是一個數組，簽名的字符。因此，當一個字節的高位爲1時，該符號位在轉換爲整數時被擴展，整數在crc ^= (quint16)buf[pos];處被全部排除在CRC之外。因此，當您訪問0xdf時，crc與0xffdf排斥，而不是預期的0xdf。

所以問題不在於長度，而在於設置高位的可能性。

您需要提供無符號字節或修復轉換，或者在排除CRC之前對結果字節執行& 0xff。

來源

2016-04-28 17:10:34

來自Qt sources：'typedef unsigned short quint16'儘管事實上'QByteArray'持有'char's它應該工作。問題是''crc^=（quint16）buf [pos]'中的quint16'轉換，應該是'quint8' –

啊，實際上，quint16的符號無關緊要，因爲損壞已經是一次了已簽名的字符將轉換爲更大的類型。 '（quint8）'在它被轉換爲更大類型之前使它無符號。 –

CRC16 modbus計算爲長數據包返回錯誤值

回答

相關問題