田舎の組み込みプログラマーがわざわざ趣味でも色々開発してみようとあがく様を綴るブログです。
DMM.makeのクリエイターズマーケットに出品しています。

CAN仕様を読み解く(1)2015年09月04日

もしかしてだけど

理解力と記憶力がなさ過ぎるんじゃないの? としばしば思うことがあるので、自分なりにまとめノートを作ってみることにしました。
ネット環境があれば見られるようにブログに書いておきます。

CANはマルチマスターって言うじゃない?

しかも信号線1本(差動なので2本だけど)でどうやってんのってことでちょっとイメージ図を書いてみました。

CANバス通信イメージ

要は1本の紐を隙を見て揺すっているような感じなんだと思います。
紐が揺れている様は他のみんなが観察できるというわけで、相手を特定せずに送信でき、誰もがマスターになれるというわけですね。

ネェ マスター 揺すってやってよ なんつって。

通信はデータを要求して送ってもらうこともできますが、垂れ流しになっているのを必要なら見るというパターンが多いらしいです。

OBD-IIってなんじゃらほい

CANとOBD-IIの関係が長らく分からなかったんですが、ようやく分かってきた気がします。
CANのメッセージはメーカー毎に色々あって今更統一できないので、CANメッセージの一部を使って統一したやり取りを決めようってことなんだと思います。

詳しいことは有名なWikiの解説を見ていただくとして、これまた自分なりにまとめてみました。

OBD-II イメージ図

OBDではECUに対してデータを要求して送ってもらう手順を踏みます。
故障診断用の端末を接続してデータを吸い出すことが主目的のようですのでさもありなんですね。

CANではノードに特定のIDは必要ありませんが、OBDプロトコルではOBDでの問い合わせに対して返答を返すノードはIDを持つようです。
OBD対応ノードは8つまで存在可能で、IDの範囲は7e0〜7e7に決められています。
これはOBDのノードIDでもありCANのメッセージIDにもなっているわけですね。

データの要求はメッセージ7dfを発行することで全てのOBD対応ノードに対して行うことができます。
そして、要求されたPIDの処理を担当しているノードが返答するわけですね。

その際、自分のIDに8を足したものをメッセージIDとして返すようになっていますので、メッセージIDを見ればOBDの返答だと分かります。

メッセージの受信方法についてはCANコントローラーによりますので別の記事で。

いきなり勘違い2015年09月03日

思い込みとは恐ろしい物で

昨夜書いた記事は大間違いでしたので訂正します。

一応受信してみたら

昨夜はOBDコマンドを受ける相手が全くいない状態でしたので何度も再送していましたが、今度はR8Cマイコンで受信だけしてみました。

Mode01/PID01

R8Cが受信を行ってACKを返したので送信は1回で止まりました。
これで要求されたデータを返すことができればECUのふりができますが、そこはお試し程度にして早くCANモニターの開発に移りたいと思います。

Mode01/PID06

試しに違うPIDも送信してみました。

ちなみに1回目はPID01で2回目は06、モードは両方とも01です。
画像の緑の部分がデータで、順に[有効バイト数]、[Mode]、[PID]となっています。

ということで、これで勘違いは正せたと思います。