AUTOSAR Dictionary: CANドライバーのメールボックス構成テクノロジーの重要なポイントを完全に分析
序文
まず最初に、いくつか小さな質問をさせていただきたいと思います。
- CAN ドライバーのキーワードは AUTOSAR フレームワークで定義されていますか? いつも迷って迷っている人はいませんか？
- 低レベルのエラーを防ぐために、CAN ドライバーのメールボックス構成プロセス中に注意を払う価値のある重要な構成パラメーターは何ですか?
- CAN 駆動メールボックスの 3 種類の送信バッファ、送信 FIFO、および送信キューの違いは何ですか?
今日は、これらの質問を調べて答えてみましょう。誰もが理解しやすいように、この記事のトピックの概要は次のとおりです。
文章
日々の開発プロジェクトで頻繁に遭遇する重要なドライバー モジュールとして、AUTOSAR 組織には、CAN ドライバーの非常に包括的かつ正確な実装要件と関連キーワード パラメーターの定義があります。
開発プロセス中に人々がこれらのモジュールのキーワードの定義を常に無視したり混同したりすることがよくあり、その結果、コミュニケーションプロセス中に双方の間で多くの誤解が生じ、開発プロセス中に多くの不要な間違いやバグが発生します。 Xiao T の記事では、日常業務での CAN ドライバーの開発に役立つように、AUTOSAR フレームワークの CAN ドライバーの非常に重要なキーワードの説明と理解しにくい基本概念を誰もが理解できるように導きます。
Xiao T は今後も AUTOSAR 辞書コラムを更新し続けます。この辞書は、AUTOSAR フレームワークの下で理解するのが難しい、または混同しやすい基本的な概念と関連する重要な知識ポイントを説明します。誰もがギャップを確認し、ギャップを埋めるのに役立ちます。 AUTOSAR ソフトウェア開発に基づいて、このコラムに注目して転送していただければ幸いです。
CANドライバーのキーワード定義
Xiao T は、AUTOSAR CAN ドライバー標準ドキュメントを研究し、それを自身の実際の経験と組み合わせることで、次の表に示すように CAN ドライバー モジュールのキーワード定義を整理しました。
CAN ドライバーのメールボックスのキー構成パラメーター
基盤となる MCAL CAN ドライバーの構成プロセスでは、混同しやすい主要な構成パラメーターが常に多く存在します。これらのパラメーターが正しく構成されていない場合、場合によっては不可解な問題やバグが発生することがあります。そのため、そのような問題のリスクを軽減するために、 , Xiao T は、自身の実際の経験を組み合わせて、CAN ドライバーの主要な構成パラメーターの定義と関連する注意事項を学びました。
ハードウェアオブジェクト
上の表で説明したように、ハードウェア オブジェクトは CAN L-PDU バッファであり、1 つの CAN ID メッセージのみを保存するために使用されます。これは、CAN コントローラ ハードウェアであるメールボックスとよく呼ばれるものとして理解できるでしょう。物理的なバッファ スペース送受信用の CAN ID メッセージを保存するために使用されます。CAN ID メッセージには、当然、CAN ID、DLC、およびデータの 3 つの部分が含まれます。
HOH、HTH、HRH の違いと関連性
HOH、HTH、HRH の違いをよりよく理解するために、Xiao T は次の表に示すように 3 つの違いと関連性を整理しました。
CanHwObjectCount
AUTOSAR 公式ドキュメントの定義によれば、このパラメータはハードウェア オブジェクト内の番号を表しますが、このパラメータのオブジェクトは HOH、つまり HRH または HTH であることに注意してください。このパラメータは、FIFO メカニズムが機能するかどうかを示します。 HOH 用に構成されています。数値が 1 の場合、データをキャッシュする FIFO はありません。1 より大きい場合、FIFO データ キャッシュ メカニズムが HOH 用に構成されています。このキャッシュ メカニズムは、重要なデータの損失を防ぐために非常に重要です。 CAN によって送受信されるメッセージ。
次の図は、HOH の CanHwObjectCount の構成を示しています。
- 上の図 1 に示すように、HOH は送信型 HOHであることがわかり、そのままHTHとして理解できます。すると、 HTH に定義されているパラメータCanHwObjectCountの値は 1 となり、FIFO 機構がないことを意味します。データが頻繁に送受信される場合、新しいデータが時間内に送信されない可能性があることを意味します。
- 上の図 2 に示すように、HOH は受信タイプ HOHであることがわかるため、 HRHとして直接理解できます。次に、HRH は、パラメータCanHwObjectCount を値 2 で定義し、FIFO メカニズムがあることを示します。深さ 2。データの送信または受信が比較的頻繁で、重要なデータの損失を防ぐために少なくとも深さ 2 の FIFO バッファ スペースがある場合。
フル CAN とベーシック CAN
MCAL CAN ドライバーの完全 CAN および基本 CAN は、 CanObejctTypeを通じて定義できるHOH の型パラメーターを変更するために使用されます。
フル CAN: 一般に、それに対応するハードウェア オブジェクトが 1 つだけ存在し、フル CAN タイプのハードウェア オブジェクトが特定の CAN ID メッセージにバインドされていることを意味します。
基本 CAN: 一般に、それに対応する 1 つ以上のハードウェア オブジェクトがあり、基本 CAN タイプのハードウェア オブジェクトが非特定の CAN ID メッセージまたは特定の範囲内の CAN ID メッセージにバインドされていることを示します。
予防：
- Basic Can タイプ HOH の場合、一般に、基礎となる無関係な CAN メッセージ データを受信するか、特定の範囲内のメッセージを受信するようにハードウェア フィルターを構成することをお勧めします。これにより、不必要なハードウェア割り込みが削減され、CPU 負荷がある程度軽減されます。
- ハードウェア リソースが十分であり、新しいデータが古いデータを上書きする可能性があるシナリオをあまり考慮する必要がない場合は、一般に HOH を FULL CAN タイプとして構成することをお勧めします。
- HOH の構成プロセスでは、通常、最初に FULL CAN タイプの HOH を構成し、最後に Basic CAN タイプの HOH を構成する必要があります。そうしないと、生成されたコードでの Maibox の使用時に混乱が生じやすくなります。
推奨される構成プラン
Xiao T は、実際の経験に基づいて、次の表に示すように、ソフトウェア開発プロセスにおける 4 つの一般的なメッセージ タイプ (アプリケーション メッセージ、ネットワーク管理メッセージ、診断メッセージ、およびXcp メッセージを送受信するためのメールボックス構成スキーム) を要約しました。
推奨される構成スキームは次のように要約されます。
- 診断メッセージは重要なメッセージであるため、損失も送信も許されず、厳密なタイミング関係があるため、送信と受信の両方に基本 CAN+FIFO を設定することをお勧めします。
- Xcp メッセージの送受信は特定の ID を持つメッセージであるため、送受信の両方に Full CAN+Buffer を設定することをお勧めします。
- メールボックスのハードウェアが十分であることを前提として、アプリケーション メッセージの送受信はフル CAN+バッファで構成することが望ましいですが、ハードウェア リソースが不十分な場合は、基本 CAN+FIFO 構成を使用することをお勧めします。
- ネットワーク管理メッセージの受信は、一般に一定範囲のメッセージとなるため、Basic CAN+Bufferでの受信設定を推奨しますが、送信時はIDが決まっているため、Full Can+Bufferでの設定を推奨します。
- すべてのメッセージの送受信の構成が完了したら、構成されているすべての HOH 内の CanHwObjectCount によって送受信されるメールボックスの合計数が、チップのマニュアルで指定されている送信メールボックスと受信メールボックスのハードウェア リソースの合計を超えないようにしてください。 ;
CANドライバーハードウェアバッファタイプ
上記の CAN ドライバーの推奨事項を理解した後、CAN L-PDU の保存に使用されるバッファーが缶コントローラーのハードウェア リソース内でどのように定義されているかをさらに調査する必要があります。
一般的に、市場で主流の CAN コントローラのハードウェア リソースは、送信と受信に応じて次のタイプのバッファに分類できます。
- 送信ハードウェア バッファ タイプ: Tx バッファ、Tx FIFO、Tx キュー。
- 受信ハードウェア バッファ タイプ Rx バッファ、Rx FIFO。
次に、各ハードウェア バッファ タイプについて個別に説明します。
送信バッファ
Tx バッファは専用 Tx バッファとも呼ばれます。このバッファは特定の CAN ID にバインドされます。送信の優先順位は完全に CAN ID によって決まります。CAN ID が小さいほど、優先順位は高くなります。高い優先順位が最初に送信されます。
一般に、Tx バッファは、HOH の CanObjectType タイプをフル CAN モードに設定します。
送信FIFO
前述の FIFO メカニズムは、実際にはハードウェアの下部で 2 つのタイプに分けることができます。1 つは送信 FIFO で、もう 1 つは送信キューです。これは、どちらもそれ自体がキャッシュ スペースであるためです。
名前が示すように、Tx FIFO はCAN ID の優先順位を無視して「先入れ先出し」方式で送信します。一般に、優先順位の逆転を防ぐために、FIFO モードの使用は推奨されません。
送信キュー
FIFO メカニズムの一種である Tx Queue は、新しいメッセージ送信要求が順番に配置されるという点で Tx FIFO 自体とは異なりますが、送信時には、最初に高優先度で送信するという原則に従って、Tx Buffer メカニズムと同じです。つまり、CAN ID が小さいほど優先度が高く、送信する必要がある同じ CAN ID を持つメッセージが複数ある場合は、番号の小さいバッファ ID が最初に送信されます。
ほとんどの場合、上記の単一送信モードに加えて、上記の組み合わせモードが存在しますが、組み合わせモードで特に注意が必要なのは、送信メッセージの優先順位の決定です。
送信バッファ + 送信 FIFO モード
上の図からわかるように、各送信の優先順位は次のように決定されます。
- 専用送信バッファ内の最小の CAN ID を取り出してリクエストを送信します。
- Tx FIFO 内の最も古い CAN ID を取り出してリクエストを送信します。
- 上記のTx BufferとTx FIFOからそれぞれ取り出したCAN ID送信リクエストを比較し、CAN IDが小さい方の送信リクエストを先に送信します。
送信バッファ + 送信キュー モード
上の図からわかるように、各送信の優先順位は次のように決定されます。
- 専用送信バッファ内の最小の CAN ID を取り出してリクエストを送信します。
- Tx キュー内の最小の CAN ID を取り出してリクエストを送信します。
- 上記のTx BufferとTx Queueからそれぞれ取り出したCAN ID送信リクエストを比較し、小さい方のCAN IDを先に送信します。
受信バッファ
Rx バッファは Tx バッファと同じです。通常、特定の CAN ID にバインドされます。一般に、Rx バッファはフル CAN モードとして HOH の CanObjectType タイプで構成されます。古いデータ CPU がこの時点で処理を完了していない場合は、時刻、新しいデータは処理されません。
受信 FIFO
Rx FIFO は通常、「先入れ先出し」方式で CAN メッセージを受信して処理します。一般的に、2 つの Rx FIFO があり、1 つは Rx FIFO0 で、他の 2 つは Rx FIFO1 です。これは実際の状況に応じて選択されます。 . .
同時に、Rx FIFO がフルの場合、次の 2 つの処理方法があります。
- ブロッキング モード: FIFO がいっぱいの場合、データ処理が完了した後にのみ新しいデータを入力できることを示します。通常はこの方法が推奨されます。
- 上書きモード: FIFO がいっぱいの場合、新しいデータが最も古いデータを上書きできることを示します。上書きを使用する場合は、データの取得および受信時にデータの一貫性の問題がないことを確認する必要があります。
さらに刺激的な内容については、公式アカウント「ADASとECUについての私の意見！」にも注目してください。