組み込み製品アプリケーションでは、多くの場合、保存または送信中にシステムデータの整合性を処理する必要があります。
いわゆる整合性とは、ライフサイクルにおけるデータの正確性と一貫性を指します。これらのデータは、EEPROM / FLASHに保存されるか、通信プロトコルに基づいて送信される可能性があり、外部干渉、プログラムエラー、またはシステムへの侵入によって破壊される可能性があります。これらのデータを使用前に確認しないと、製品機能が無効になる場合があります。一部の特定の領域では、ユーザーの所有物を危険にさらす可能性があり、深刻な場合には生命の安全さえも危険にさらす可能性があります。
この記事では、より広く使用されている周期的冗長性チェックテクノロジと、STM32での特定の経験について説明します。
いわゆる周期的冗長性チェック（CRC：周期的冗長性チェック）はエラー検出アルゴリズムであり、通常、元のデータの予期しない変更を検出するために通信プロトコルまたはストレージデバイスで使用されます。あるアルゴリズムに従って有用なデータを計算し、特徴値を抽出し、それを有用なデータに添付することと簡単に理解できます。アプリケーションでは、特定のアルゴリズムに従って有用なデータを抽出し、特徴値を事前に保存された特徴値と比較します。等しい場合は検証に合格し、そうでない場合は検証に失敗して、データが異常であるかどうかを識別します。
データの整合性（データの整合性）を検証する理由
データは、保存および送信中に変更される場合があります。データ通信アプリケーションのシナリオを例にとると、一般的なエラーにはおおよそ2つの障害モードがあります。
シングルビットエラー：図に示すように、1つのデータビットのみにエラーがあります。
バーストエラー：図に示すように、2つ以上のデータビットのコードストリームにエラーがあります。
なぜこれらのビットエラーが発生するのでしょうか？電子システム通信の場合、物理層、リンク層、通信媒体などが含まれます。物理層は、主に特定のコーデック原理を使用して元のバイナリデータを変調し、変調された信号を送信回路を介して送信媒体に送信します。受信側は、受信回路を使用して情報を受信および復調し、バイナリコードストリームに復元します。このプロセスでは、媒体が干渉される可能性があり、受信回路、送信回路、変調回路、および復調回路はすべて、何らかの干渉の理由により機能しなくなり、ビットエラーが発生する可能性があります。このとき、飛行制御システムの特定の制御コマンド、車両システムのCANメッセージデータなど、データの正確性を保証する適切なメカニズムがない場合、システムはこれらのエラーデータを直接使用して制御対象（モーターなど）を制御します。 、エンジンなど）、深刻な場合、それは生命と財産の計り知れない災害を引き起こします。
ストレージシステムのデータについても同じことが言えます。一般的に、システムの電源がオンになると、一部のキャリブレーションデータなどのシステムパラメータが物理ストレージメディアからロードされます。メディアの一部が損傷したり、ソフトウェアのバグによってデータの整合性テストなしでデータが誤って処理されたりした場合、そのようなデータはシステム制御に直接適用され、セキュリティリスクも発生します。
したがって、データ整合性テストの重要性は自明です。単純なXORチェック、CRCサイクリック冗長性チェック、FECフォワードエラー修正アルゴリズムなど、多くの一般的なデータ整合性アルゴリズムがあります。周期的冗長性チェックは、組み込みシステムで広く使用されており、通信プロトコルの定式化、データストレージ、および圧縮と解凍のアルゴリズムで広く使用されています。
Cyclic Redundancy Checkは、アルゴリズムの原則としてバイナリ分割を使用し、強力なエラー検出メカニズムを備えています。バイナリ分割用の少量のハードウェアロジック回路を使用することで実現できます。ソフトウェアコードの実装に関しては、ルックアップテーブル方式とシフト計算の2つのアイデアと戦略があります。ルックアップ方式は時間にスペースを使用し、シフト計算方式はスペースに時間を使用します。
周期的冗長性チェックとは何ですか？
サイクリック冗長性チェックのコア数学アルゴリズムの原則は、サイクリックコードに基づいています。サイクリックコードは、元のデータの情報を増やさないことに基づいて情報を拡張し、その冗長特性を非常に少ないストレージコストで保存します。このアルゴリズムは、1961年にW.ウェズリーピーターソンによって発明されました。
ここでのnビットのバイナリデータは、効果的な情報のロードです。（送信または保存される有用な情報である可能性があります）
mビット冗長性コードはCRCアルゴリズムに従って計算されます。つまり、CRCチェック多項式とCRCアルゴリズムに従って、以前の有効なデータから特性冗長性コードが抽出されます。これが冗長性の真の意味です。
実際に送信または保存されるのは、n + mビットのバイナリデータです。
概念は次のとおりです。polynomialCRCチェックアルゴリズムでは、polynomialは次のように理解および表現できます。
その本質はマルチベースの数学的表現であり、ここではバイナリであるため、Xは2です。
基本的なアルゴリズム処理プロセスは次のとおりです。
送信される有効なデータがバイナリ多項式M（x）であり、チェック多項式P（x）が送信者と受信者によって合意され、両者がそれを知っていると仮定すると、いくつかの多項式と関連する処理手順の意味は次のとおりです。
受信者は、データを受信した後、CRCチェックを実行します。残りは0で、チェックに合格します。
実際、CRCの本質は、冗長コードを取得するためのバイナリ多項式除算の計算プロセスであり、ソフトウェアのルックアップ方法、シフト計算方法、または純粋なハードウェア論理回路の実装に関係なく、本質は同じです。CPU時間がほとんどかからないため、デジタル論理回路にシフト計算を使用する方が有利です。
一般的なCRCチェック多項式
一般的なCRCチェック多項式演算子は何ですか？
さまざまなチェック多項式の複雑さに加えて、アプリケーションの観点からの違いは何ですか？アプリケーションの観点からは、主にエラー診断率に反映されます。CRC-16およびCRC-CCITTのエラー検出効果を見てください。
シングルビットおよびダブルビットエラーを完全に検出できます
奇数ビットエラー
16ビット長および16未満のバーストエラーを検出できます
99.997％の確率で17ビット以上の長さのエラーを検出できます
異なるチェック多項式演算子を選択すると、ビットエラー診断の成功率が異なり、もちろんその計算オーバーヘッドも異なります。信頼できるIEC規格を確認しましょう。下の図は「IEC61508-7」から抜粋したものです。
上記から、CRC-8は99.6％のビットエラー確率を診断できるのに対し、CRC-16は99.998％のビットエラー確率に増加することがわかります。
注：IEC61508は、国際電気技術委員会の機能安全基準（電気/電子/プログラム可能な電子安全関連システムの機能安全）です。
技術の開発以来、さまざまな業界で多数の異なるチェック多項式ジェネレータが使用されてきました。以下は、参考のためにwikipediaのスクリーンショットです。
STM32CRCハードウェア周辺機器
次の図に示すように、STM32にはCRC-32ハードウェア計算ユニットが組み込まれており、イーサネットパケットチェックコードの計算に適用できる固定多項式0x4C11DB7（16進表現）を実現します。
すべてのSTM32製品にはCRCペリフェラルがあり、CRC計算のハードウェアサポートを提供して、アプリケーションコードのストレージスペースを節約します。CRCチェック値を使用して、送信中のデータの正確性を検証したり、保存中のデータの整合性をチェックしたりできます。IEC60335では、CRC検証を通じてFLASHの整合性をチェックすることも認められています。FLASH整合性チェックの適用では、FLASH全体（最後にCRC値を保存したバイトを除く）のCRCチェック値を事前に計算し、FLASHの最後に配置する必要があります。プログラムの起動または実行の過程で、同じ方法を使用してFLASH全体のCRCチェック値を再計算し、それをFLASHの最後のアドレススペースに格納されているCRC値と比較します。
EWARMは、v5.5以降、STM32チップのCRC計算をサポートしています。FLASH全体のCRCチェック値を計算し、それをFLASHの最後に保存するプロセスは、IARで完了することができます。EWARMのCRC計算パラメータを設定することにより、CRC計算はFLASHスペース全体で自動的に実行され、計算結果は内部FLASHスペースの最後に配置されます。
あなたは、これの適用価値は何であるかと尋ねるかもしれません。例として、MCUプログラムベースのアップグレードを取り上げます。コードアップグレードプロセス中に、ブートローダーアップグレードインターフェイスによって渡されたバイナリプログラムファイルが検証されていない場合、アップグレードプロセス中に発生したコードエラーを時間内に見つけることができません。逆に、元のコードにチェックコードが追加されている場合、アップグレードプログラムは、アップグレードファイルを受け取った後にチェック計算を実行し、アップグレードするファイルの最後にあるチェックコードと比較します。一致しない場合、アップグレードは中止されるため、変更されません。無効な、または潜在的に安全なコードがチップに書き込まれます。
リンクファイルを変更し、FLASHでチェックサムの保存場所を指定し、リンクファイルに次のステートメントを追加します。
place at end of ROM_region { ro p .checksum };
このステートメントは、CRC値をFLASHスペースの最後に配置することを指定します。これは、アプリケーションコードの終わりではなく、FLASHスペース全体の終わりです。このように、CRC値の位置は固定されており、コードサイズによって変化することはありません。
[チェックサム]ページのパラメーターを構成します
IARチェックサムページの説明（v6.4以降）
IARのチェックサムページは2つの部分に分かれています。
赤で囲まれた部分：FLASHで計算する必要のあるCRCの範囲と空きバイトの充填値を定義します。
チェックサム計算パラメータの設定部分：チェックサムサイズ：チェックサムのサイズ（バイト数）を選択します
。配置：チェックサムの配置を指定します。空白のままにすると、デフォルトは2バイトの配置になります。アルゴリズム：チェックサムのアルゴリズムを選択します
補数：補数計算を実行するかどうか。「現状のまま」を選択することは、補数計算を実行しないことを意味します。
ビット順序：ビット出力の順序。MSBが最初で、各バイトの上位ビットが最初になります。LSBが最初で、各バイトの下位ビットが最初です。
ワード内のバイト順序を逆にする：入力データの場合、ワード内の各バイトの順序を逆にします。
初期値：チェックサムによって計算された初期値
チェックサムユニットサイズ：反復用のユニットサイズを8ビット、16ビット、32ビットのいずれかで選択します。
STM32CRCペリフェラルがデフォルト構成を使用する場合のIAR構成
STM32CRC周辺構成：
POLY = 0x4C11DB7（CRC32）
Initial_Crc = 0Xffffffff
入力/出力データは反転されません
入力データ：0x08000000〜0x0801FFFB。（最後の4バイトは、計算されたCRC値を入力するために使用されます）
実験中、「アライメント」は計算されたCRC値に影響を与えないようであることがわかりました。ただし、「ワード内のバイト順序を逆にする」と「チェックサムユニットのサイズ」の構成には一定の関係があります。後者が32ビットを選択した場合、前者をチェックすることはできません。後者が8ビットを選択した場合、「ワード内のバイト順序を逆にする」をチェックする必要があります。次の図を参照して設定することもできます。
IAR v6.4より前のバージョンの場合、「チェックサムユニットサイズ」オプションはありません。参照構成は次のとおりです。
コードの書き方は？
上記のように、このアプリケーションを使用してFlashのデータを検証できます。参照コードは次のとおりです。
/*-1- 配置CRC外设 */
CrcHandle.Instance = CRC;
/* 默认二进制多项式使能 */
CrcHandle.Init.DefaultPolynomialUse = DEFAULT_POLYNOMIAL_ENABLE;
/* 默认初值设置 */
CrcHandle.Init.DefaultInitValueUse = DEFAULT_INIT_VALUE_ENABLE;
/* 输入数据不反转 */
CrcHandle.Init.InputDataInversionMode = CRC_INPUTDATA_INVERSION_NONE;
/* 输出数据不反转 */
CrcHandle.Init.OutputDataInversionMode = CRC_OUTPUTDATA_INVERSION_DISABLED;
/* 输入数据基本单元长度为32bit */
CrcHandle.InputDataFormat = CRC_INPUTDATA_FORMAT_WORDS;
if (HAL_CRC_Init(&CrcHandle) != HAL_OK)
{
/* 初始化错误 */
Error_Handler();
}
pdata = (uint32_t*)ROM_START;
/*##-2- 调用HAL库利用硬件CRC外设对ROM区计算CRC-32校验码*/
uwCRCValue = HAL_CRC_Calculate(&CrcHandle, pdata, ROM_SIZEinWORDS);
概要
CRCアプリケーションの場合、多項式演算子に基づいた純粋なソフトウェアソリューションを作成することもできます。インターネット上には多くの既製のコードがあります。基本的な考え方は、ルックアップテーブル方式とシフト計算方式に他なりません。違いは、1つは計算効率と引き換えにストレージスペースを犠牲にし、もう1つはストレージスペースを節約するために計算時間を犠牲にすることです。選択方法については、一般にアプリケーションシナリオに基づいて、設計されたシステムを包括的に検討することに基づいています。
CRCアルゴリズムを使用して、ブロックデータの冗長コードを計算します。一部の記事や標準では、この冗長コードを署名と呼んでいます。実際のアプリケーションでは、有効なデータを計算して取得したチェックコードを、保存済みのチェックコードと比較し、等しい場合は合格、そうでない場合は不合格となります。もちろん、元のデータと保存されているチェックコードをチェックアルゴリズムに渡すこともできます。結果が0の場合、チェックは合格です。それ以外の場合は失敗します。
データ通信の場合、通常、有効なデータチェックコードがメッセージの最後に追加され、受信者は受信したメッセージのデータの整合性を検証します。
1.埋め込まれた視点から、人工知能に対する「解釈可能性」の影響を分析します。
2. [MCU]登録、標準ライブラリ、HALライブラリ、LLライブラリ、非常に多くのライブラリ！どのように私に選ぶように頼みますか？
3. Linuxで組み込みプロジェクトを開発するには、いくつのステップがありますか？
4.プログラム自体はどのようにしてそのサイズを認識しますか？これは、鶏が卵を産むのか、卵が鶏を産むのかという問題です！
5.国内の統合開発環境は、国内のRISC-Vがチップ技術における外国の巨人の独占を打破するのに役立ちます
6.組み込み開発を行う場合、LCDディスプレイをどのように実現しますか？
免責事項：この記事はオンラインで複製されており、著作権は元の作者に帰属します。作品の著作権問題に関与されている場合は、お問い合わせください。ご提供いただいた著作権証明書に基づいて著作権を確認し、作者の報酬を支払うか、コンテンツを削除します。