Python

DAQパケット送信周期の精度が悪い理由を確認。 イベントチャンネルが15msになってる。 Sleepで10ms周期を作ろうとしているが、実際は15msになってる。 この部分はPC依存な面はある。 上記により小手先の回収ではどうにもならなそう。 一応対策も考えてるので次回確認予定。

XCP Basic PCシミュレーションの問題点は送信周期。 前回のCAN回線ログのDAQパケットだけを抽出し、それのタイムスタンプと元に現状の送信周期を算出。 10[ms]周期で送信されるべきところが15[ms]になっていた。 一応、原因は分かってはいるので、そこらへんを次回確認予定。

実際にSET_MTAとDOWNLOADを使ってRAM値書き換えを実施。 RAM値書き換え前にDAQを起動しておき、RAM値書き換えとDAQパケットの状況をCAN回線モニタして確認。 RAM値書き換えに合わせてDAQパケットの計測データが変化。 おおよそXCP Basicの挙動はOKだが、まだちょっと問題がある。

計測RAM値の変更方法はSET_MTAとDOWNLAOD。 SET_MTAとDOWNLOADの電文確認。 折角なので連続で投げて見る。 ただ、同じ値だと変化が分からない無いのでちょっと書き込みデータを変える。 さらにDAQパケット送出前に書き換えてしまう可能性もあるのでsleep関数を挟む。

START_STOP_SYNCHコマンドを投げて見た。 並行してcan.loggerでCAN回線モニタを実施。 DAQパケットの計測ができた。 タイムスタンプ有効設定をしていたため先頭の方にタイムスタンプが埋まっている。 タイムスタンプの後ろから計測データが続く。 今回は0値が取得されている。

DAQの開始方法は大きく2パターン。 DAQ list毎に個別開始。 開始可能状態にして複数のDAQ listを同時開始。 今回は後者で実施。 START_STOP_DAQ_LISTコマンドで個別開始/停止と開始可能状態の設定できる。 これでDAQの開始条件は揃った状態となる。

SET_DAQ_LIST_MODEコマンドでDAQの計測データ送信ポリシーを設定できる。 TIMESTAMP有無、使用するEvent channel、分周比など。 Event channelと実際の周期はECU側の実装依存。 今回は1:10ms、2:100ms、3:1msとなっている。

DAQ listの構造的な準備はできたので、実際にODT_ENTRYを更新していく。 更新するODT_ENTRYを参照するにはSET_DAQ_PTRを使用する。 実際にODT_ENTRYを更新するにはWRITE_DAQを使用する。 WRITE_DAQ実行後は参照するODT_ENTRYは自動的に一個後ろになる。

ALLOC_ODT_ENTRYは物理層の都合やODTのフォーマットによる制限がある。 CANの場合だとデータフィールド8byteが制限。 タイムスタンプ等が入ることで計測データを格納する範囲が少なくなる。 ALLOC_ODT_ENTRYを複数回投げてみた。 リソースが枯渇するまで生成は可能。

ALLOC_ODTを送信してみた。 ODT1個あたり4byteの管理領域のリソース割り当てがされる。 試しに5個ずつODTを生成してみた。 20個のODT生成時にエラー。 エラー理由はメモリ不足。 1ODTあたり8byteの送信バッファも必要なのでそれも含めてメモリ不足。 この点含めてリソース管理が必要。