PIC マイクロ コントローラと Linux コンピュータで RS-485 プロトコルをプログラミングしています。私は当初、CRC8 を使用して着信データをチェックすることを考えていましたが、これはプロセッサを集中的に使用するタスクになるようです。
代わりに、より単純な PEC アルゴリズムを考えていました。おそらく、すべての着信バイトをシードで XOR して、CRC の非常に単純な単一ステップの実装を作成します。
このようなアルゴリズムを使用すると、どのような欠点がありますか?
PIC マイクロ コントローラと Linux コンピュータで RS-485 プロトコルをプログラミングしています。私は当初、CRC8 を使用して着信データをチェックすることを考えていましたが、これはプロセッサを集中的に使用するタスクになるようです。
代わりに、より単純な PEC アルゴリズムを考えていました。おそらく、すべての着信バイトをシードで XOR して、CRC の非常に単純な単一ステップの実装を作成します。
このようなアルゴリズムを使用すると、どのような欠点がありますか?
PEC 値を生成するためのテーブル ルックアップ方式は、確かに高速です。4 バイト パケットに対して 80 MHz で動作する PIC32 での私のテストでは、テーブル メソッドでは 2.8us が必要でしたが、アルゴリズム メソッドでは 11.5us が必要でした。メモリ要件は、速度のコストを示しています。テーブル メソッドには 348 バイトが必要ですが、アルゴリズム メソッドには 216 バイトが必要です。したがって、メモリが不足している場合は、ここに示すアルゴリズム アプローチを検討してください。(BYTE は unsigned char です)
/* bit_crc8 FUNCTION DESCRIPTION ************************************
* SYNTAX: BYTE bit_crc8( BYTE *data, BYTE len);
* KEYWORDS: PEC, CRC, error checking
* DESCRIPTION: Returns the PEC for an array of bytes. This method does
* not use a lookup table
* PARAMETER 1: BYTE pointer to data array
* PARAMETER 2: BYTE - Number of bytes in array
* RETURN VALUE: BYTE - PEC value
* NOTES: SMBus limits the number of bytes in the packet to 256
* Primitive polynomial is set by the definition of PEC.
* END DESCRIPTION **********************************************************/
BYTE bit_crc8( BYTE *data, BYTE len)
{
#define PEC 0x07 // Implements Polynomial X^8 + X^2 + X^1 +1
BYTE crc = 0;
BYTE loop, b8;
while (len--)
{
crc ^= *data++;
for(loop=0; loop <8; loop++)
{
b8 = crc & 0x80; /* Test for MSB set to 1 */
crc <<= 1; /* Left shift CRC */
if(b8)
{
crc ^= PEC; /* Divide by PEC if bit 8 was set */
}
}
}
return crc;
}