CAN-FD

仮想HILSと仮想ECUのXCPonCANFD対応の動作確認は結果としては失敗に終わった。 変数の精度向上はあまり性能向上にはつながらなかった。 しかしXCPonCANFDを直に見るのも珍しい体験なので、これはこれで将来に生かすって発想が大事。 失敗したからこそ意地でも糧になるものを拾うべし。

XCPonCANFD対応に於ける当初想定していた仮想HILS、仮想ECUの全体構成と実際の全体構成。 基本的には想定通りの修正。 PyXCPのCAN-FD対応が難航したのが想定外ってくらい。 論理構成としては変わらず。つまり基本的な動作は変わらないはず。 変数のサイズと精度が変わっているのでそれの効能を期待。

仮想HILS側の修正後のコード開示。 前回までの修正範囲と内容を反映したのみ。 tkinter、matplotlibのコードもあり、肥大化しているが、基本一直線のコード。 タイマハンドラで周期的に呼ばれるくらい。 いろいろな要素が絡んでるので、次回は全体構成の再確認。

指令値受取用バスの初期化変更。バス初期化の引数をFD用に変更するのみ。XCP DAQ受信部のレイアウト変更対応とLSB変更対応。xcp_canfdクラス作成時のテストコードと同じ対応。XCP STIM送信部のレイアウト変更対応とLSB変更対応。レイアウトはxcp_canfdクラス内で決めているのでLSB対応のみ。

仮想HILSのCAN-FD対応方針整理。 数としてはそこそこあるが、一個一個は1行修正のレベル。 importしているxcp_canをxcp_canfdに変更。 上記のクラス変更に伴い、XCPインスタンスの生成部分変更。 importのところでエイリアスを使うのもあり。

DAQリスナーCAN-FD対応版の動作確認を実施。 can.loggerのCAN-FDモードを並走さえて回線モニタを実施。 問題無くCAN-FDフレームが送出されていることを確認。 Bitrate_switchも有効になっている。 python-canの範疇では問題無しと判断できる。

DAQリスナーのCAN-FD対応の要否ついて説明。 CANのみ対応のインターフェースはCAN-FDフレームを検知すると「異常フレーム」と認識しエラーフレームをもってフレーム破壊を行う。 よって、CAN-FDフレームが流れるネットワークにCANのみ対応インターフェースは接続禁止。 DAQリスナーの修正は一撃。