バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はXCP BasicとPyXCPによるRAM書き換えのオーバーヘッドを検討した。
15msはPythonのスレッド周りのオーバヘッド。
残り15msはSET_MTAとDOWNLOADの2回のコマンド発行が原因のようだ。
前者はそもそもPython以外で実現するなどの対策はがあり得るが、
後者はRAMの書き換え方を変えればなんとかなるかも？
登場人物
博識フクロウのフクさん
イラスト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
SET_MTAとDOWNLOAD以外のRAM書き換え方法
SET_MTAとDOWNLOAD以外で効率的なRAM書き換え方法があるような言い方してたけど、結局なんなの？
それはSTIMだ。
あ！
なんか聞き覚えがある！
あれ？
でもSTIMってXCP Basicでは未対応機能じゃなかったっけ？
確かここでそんな話をしていたし、
とりあえずスループットの問題は一旦無視するようなことも言ってたな。
(チッ。覚えてやがったか。)
STIMについてはここでも若干触れてたかな。
STIM対応方法について
太郎くんの言う通り、STIMはXCP Basicでは未対応機能だ。
というわけで対応方法としては以下2通りだ。
- XCP Basicを改造してSTIM対応。
- XCP Basic以外のSTIM対応しているXCPスレーブIPを探す。
ちょっとどっちもイバラの道な気がする・・・。
そうだね。
前者もDAQ listという機構は使いまわせるが、STIMに由来する特殊な仕様は多い。
よって一筋縄ではいかないだろう。
というわけでまずは後者を探してみるってことになるかな。
そう簡単に見つかるのかなー。
まぁ世の中は広い。
XCPというニッチなプロトコルにも対応したPyXCPもあったんだ。
実はXCP Basicとは違うXCPスレーブIPがあってもおかしくはない。
って、ことはまだ当てが無いってことなんだな・・・。
まぁググればきっと出てくるでしょ！
そこまでGoogleが万能な気はしないなぁ。
とくにニッチな領域だと途端に無力化すること多いし。
それは同感。
とりあえず、次回までに何かしら探してくる。
よろしくー。
ソースコードとか
PyXCP関連の実験はここで一旦終了。
よって、使用したコードをJupyterNotebook形式でGithubに上げておく。
まとめ
まとめだよ。
- SET_MTAとDOWNLOAD以外のRAM書き換え方法はSTIM
- しかし、XCP BasicはSTIMは未対応。
- XCP Basicに対してSTIM拡張をするかXCP Basic以外のXCPスレーブIPを探すか。
- とりあえず後者の線でやってみる。
- 見つからなかったら諦めてSET_MTAとDOWNLOADで頑張る方向で。
バックナンバーはこちら。
コメント