バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はxcp_canクラスをXCPonCANFD版に対応した、xcp_canfdクラスへ拡張対応した。
単体テストとしては問題無く動作し、
仮想ECU側のPID制御の性質も見て取れるような結果となった。
少なとも、XCPonCANの時の挙動と同一。
今回からはDAQリスナーのCAN-FD対応を始める。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
DAQリスナーのCAN-FD対応の要否について
今回からはDAQリスナーのCAN-FD対応ってことだけど、
具体的にはどうなるのかな？
python-can周りを修正すればOKな気はしてるけど。
そうだね。
しかも8byteで十分なデータ量だったので、特にデータフィールドのレイアウトも変えない。
じゃー、そもそもCAN-FD対応も要らないんじゃない？
まぁデータを送るという観点に於いては不要には見えるな。
そういう言い方をするってことは何か問題があるってことか・・・。
DAQリスナーをCAN-FD対応しなかった場合の問題点
CANとCAN-FDの関係はCAN-FDがCAN上位互換という位置づけになる。
つまり、以下が言える。
- CAN-FD対応のインタフェースはCANのフレームを認識できる。
- CANのみ対応のインターフェースはCAN-FDのフレームを認識できない。
うん。これはなんとなくわかる。
そして、問題になるのが後者。
どういう問題になるの？
CANのみ対応インターフェースがCAN-FDのフレームを検知すると、
「異常なフレーム」と認識して、即時エラーフレームを発行してCAN-FDフレームをぶっ壊す。
ぶっ壊すの？！
ぶっ壊す。
これは確かに問題だ・・・。
というわけで、CAN-FDフレームが流れる回線上に「CANのみ対応のインターフェース」を混ぜることは厳禁となるわけだ。
なるほど。
これがDAQリスナーをCAN-FD対応する理由になるのか。
DAQリスナーのCAN-FD対応
DAQリスナーのCAN-FD対応自体はシンプルで2か所書き換えるだけだな。
まぁ2つ目は送信するCANフレームをCAN-FDにしてるだけなので、対応しなくてもOKだけどね。
# バス接続
bus = can.interface.Bus(bustype='vector', channel='1', bitrate=500000)↓
# バス接続
bus = can.interface.Bus(bustype='vector', channel='1', bitrate=500000, fd=True, data_bitrate=2000000)send_msg = can.Message(arbitration_id=0x111, extended_id=0, data=[byts[0], byts[1], byts[2]])↓
send_msg = can.Message(arbitration_id=0x111, is_extended_id=0, data=[byts[0], byts[1], byts[2]],is_fd=True, bitrate_switch=True)一つ目の初期化でCAN-FD対応のインターフェースにして、
二つ目のメッセージ構築で送信フレームをCAN-FDにしてるのか。
正解。
いろいろややこしい話は出て来たけど、やることは恐ろしくシンプルだった。
次回は念のため挙動確認をしておこう。
まとめ
まとめだよ。
- DAQリスナーのCAN-FD対応の要否ついて説明。
- CANのみ対応のインターフェースはCAN-FDフレームを検知すると「異常フレーム」と認識しエラーフレームをもってフレーム破壊を行う。
- よって、CAN-FDフレームが流れるネットワークにCANのみ対応インターフェースは接続禁止。
- CANのみ対応のインターフェースはCAN-FDフレームを検知すると「異常フレーム」と認識しエラーフレームをもってフレーム破壊を行う。
- DAQリスナーの修正は一撃。
バックナンバーはこちら。
コメント