2017-09-10 47 views
1

已經在我寫的基於dallas crc8應用於1-Wire的crc計算器上做了一些測試,它使用了0x8c poly。我正在測試它在一個15字節的字符串上添加1位,2位和3位錯誤(還向crc本身添加了位錯誤)。粘貼的實現無法識別2,2位錯誤和9,3位錯誤...支持驗證C CRC8實現

static inline uint8_t roll(char input_byte, uint8_t crc) { 
    for(uint8_t i = 8; i; i--, input_byte >>= 1) { 
    uint8_t result = (crc^input_byte) & 0x01; 
    crc >>= 1; 
    if(result) crc ^= 0x8C; 
    } 
return crc; 
}; 


static inline uint8_t compute(const uint8_t *input_byte, uint16_t length) { 
    uint8_t crc = 0; 
    for(uint16_t b = 0; b < length; b++) 
    crc = roll(input_byte[b], crc); 
    return crc; 
}; 

擺弄的代碼我注意到,除去& 0X01造成任何值的數據具有精度巨大的增益(試圖與不同類型的串的):

static inline uint8_t roll(char input_byte, uint8_t crc) { 
    for(uint8_t i = 8; i; i--, input_byte >>= 1) { 
    uint8_t result = crc^input_byte; 
    crc >>= 1; 
    if(result) crc ^= 0x8C; 
    } 
return crc; 
}; 


static inline uint8_t compute(const uint8_t *input_byte, uint16_t length) { 
    uint8_t crc = 0; 
    for(uint16_t b = 0; b < length; b++) 
    crc = roll(input_byte[b], crc); 
    return crc; 
}; 

與所述所張貼修改我沒有得到任何1,2或3位錯誤用總是100%準確度我需要爲0-15字符或0-120bits

範圍

有人可以幫我嗎?瞭解這裏發生的事情?

+0

請注意,'char'和'uint8_t' **是不同的類型**。一個是'char',另一個是**,如果它存在** unsigned ** ** char。這個算法需要**無符號**字符的可移植性 - >'uint8_t input_byte'- –

+0

也,你測試*所有* 1位錯誤? –

+0

謝謝你的類型建議Antii我會修復:)在這一點上,我認爲我的測試已經破裂。 –

回答

0

我認爲您的測試方法存在缺陷。根據我的測試,原始實現檢測到所有的1位,2位和3位錯誤,以及4位錯誤的99.2%。您提出的替代方案几乎總會生成完全相同的結果(0xf7)。這是預計的,因爲crc^input_byte幾乎總是非零。

因此,你的實現是等價(大部分時間):

static inline uint8_t compute(const uint8_t *input_byte, uint16_t length) { 
    uint8_t crc = 0; 
    for (int i = 0; i < 15; i++) { 
     for (int j = 0; j < 8; j++) { 
      crc >>= 1; 
      crc ^= 0x8C; 
     } 
    } 
    return crc; 
} 

這的確產生價值0xf7

我相信你測試中的缺陷是它假定crc匹配是一件好事。相反,如果原始字符串上的crc與注入位錯誤後的crc相同,那很糟糕(crc生成器未檢測到錯誤)。

+0

我可以請你在這裏張貼你已經執行過的測試嗎? –