問題タブ [crc16]

私が行っている作業では、データ行と共に CRC16 チェックサムを格納する必要があります。最近、sun.misc.CRC16 のパフォーマンスが、実行中のコードの主要なボトルネックの 1 つであることを発見しました。

検索の結果、ルックアップ テーブルを使用して CRC16 を実装すると、求めていたパフォーマンスが向上することがわかりましたが、さまざまな標準が存在することもわかりました。ユーザーが実際に何を望んでいるかについて何らかの回答を得ようとするのには時間がかかる可能性が高いため、それまでの間、sun.misc.CRC16 をルックアップ テーブルの機能と同等のものに置き換えたいと考えています。ただし、クラス自体で見つけることができる唯一の実際のドキュメント/ソースは、実際には詳しく説明されていません。少なくとも、CRC の理解はまだ十分ではありません。

C# を使用して CRC-16 を生成しようとしています。私が RS232 に使用しているハードウェアでは、入力文字列が HEX である必要があります。以下のスクリーンショットは、正しい変換を示しています。テストのために、8000 を 0xC061 にする必要がありますが、CRC-16 を生成する C# メソッドは、任意の HEX 文字列を変換できる必要があります。

Nito.KitchenSink.CRC を使ってみた

8000が入力されたときに8009を生成する以下も試しました-

このリンクを参照して 、文字列またはバイト配列の CRC32 を 計算する CRC32 の代わりに CRC16 を計算するためにコードを修正しましたが、間違った結果が得られました。

上記のリンクに関連する可能性のある説明を拡張して提供するために、文字列データの CRC16 チェックサムを取得するための PHP の関数を次に示します。

リフレクションを追加したくない場合は、関数 crc16() の次の行を置き換えます。

Refin = True に置き換えます。

Refin = False の場合:

Refout を置換 = True:

Refout = False の場合 (この行全体を削除します):

以下のようなJava CRC16関数があり、4桁の英数字の結果を返す必要があります。ただし、3 文字の英数字しか返さない場合もあります。なんで？私はこの CRC を CRC を計算する C アプリケーションとクロス比較しています。通常は同じ CRC ですが、JAVA が例外を発生させる 3 文字の結果を返すことがあります。なんで？

特定の出力に一致する Maxim CRC-16 アルゴリズムの作成に問題があります。以下に、プログラムを作成するために使用したリソースをリストしました。

• マキシムのアプリケーションノート 27
• サニティフリーの CRC-16 計算
• Julia CRC 計算 (Andrew Cooke 著)
• CRC-16 ルックアップ テーブル (C)
• C の別の CRC ルックアップ テーブル
• CRCウィキページ

上記の参照を使用して、ビットごとのアプローチとルックアップ テーブルのアプローチの両方を使用して CRC-16 を計算する簡単なプログラムを作成しました。ビットごとのアプローチを以下に示します

以下は、CRC-16 計算のルックアップ テーブル バージョンです。

これらの式を使用して、8 ビットの 16 進数の配列を計算し、CRC-16 チェックサム値を計算できます。コードはエラーなしでコンパイルおよび実行されます。

これらの計算の正確性を検証しようとすると、問題が発生します。私の目標は、CRC-16 をこのシステムと同じように機能させることです。つまり、別のシステムで使用されている CRC-16 計算をエミュレートするシステムを作成したいと考えています。

以下は、元のシステムの CRC-16 計算機に送信されるメッセージの説明です。

「この CRC は、最初に CRC ジェネレーターをクリアし、次に Write Scratchpad コマンドのコマンド コード (0Fh)、ターゲット アドレス (TA1 および TA2)、およびすべてのデータ バイトをシフトインすることにより、CRC-16 多項式を使用して生成されます...データは、スクラッチパッドの先頭からスクラッチパッドに書き込まれます。」

これにより、次の入力を使用します。

元のシステムでは、CRC-16 は として0x4E2A出力されます。これは、ルックアップ テーブルまたはビットごとの CRC-16 の出力ではありません。実際、ルックアップ テーブル計算機からの CRC-16 出力は、ビットごとの計算機からの CRC-16 出力と一致しません。この計算に使用するテーブルは、CRC-16 を計算する際の他のアプローチと同じ方法で計算されていない可能性が高いため、これは大きな驚きではありません。

TL;DR: 最終的に、CRC-16 を計算して、与えられた入力を送信したときに元のシステムが与える出力と一致するようにしたいのです。また、CRC-16ルックアップテーブルを作成して、ビットごとのアプローチに一致させる方法についても学びたいと思っています(入力として8ビット数値の配列も使用します)。アドバイスをいただければ幸いです。

CRCMOD ライブラリを使用して Python 3.4 でコードを作成し、CCITT CRC16 チェックを取得するのに問題があります。

それは私の文字列です：

スペクトされた crc 値は1d7f です

私のコード:

戻り値: 7d67

私は何を間違っていますか？

IEEE 802.3 から引用

数学的には、特定の MAC フレームに対応する CRC 値は、次の手順で定義されます。

a) フレームの最初の 32 ビットが補完されます。
b) 次に、保護されたフィールドの n ビットは、次数 n – 1 の多項式 M(x) の係数であると見なされます。 MAC クライアント データ フィールド (存在する場合はパッド フィールド) の最後のビットは、
x0項に対応します。31.
d) R(x) の係数は、32 ビットのシーケンスと見なされます。
e) ビット シーケンスが補完され、その結果が CRC になります。

https://www.kernel.org/doc/Documentation/crc32.txt

この方法で書かれたビッグエンディアン CRC は、次のようにコーディングされます。

パートc) M(x) に x^32 を掛けたものはどこですか? どの数値にも 32 個のゼロが追加されているのがわかりません。

また、次のコードは意味がありません。コードと数学は実際には一致しません。

CRC-32 実装の違いを評価し 、

これらの実装は何をしていますか? それらのどれも、元の手順に実際には似ていません。

これを最後まで読んだ後でも、まだ意味がありません: http://www.relisoft.com/science/crcmath.html