プリウスの後付けオートクルーズ表示装置を作ってみた（その２・製作編）

プリウスのフロント・ディスプレイ・コーション・エリアにも、光りはしないものの、よく見ると「CLUSE」の表示がうっすらと用意されているのがわかる。手作業による追加によってオート・クルーズがONになっても、「CLUSE」下の高輝度LEDがないので光らないだけ。

かといって、ダッシュボードまでをばらしてディスプレイ基板を取り出して、LED＋抵抗＋ダイオードを追加するかと言われれれば、やればできるが、そこまでしたくないｗｗ


ハンダ付けまでしなくとも、ディスプレイをGグレード品と交換する手もあるが、費用がかかる上にトータルの作業がはんぱなく大変だ。すでに純正ナビの追加作業で何度となくフロント・ダッシュボード周りを外したりつけたりを繰り返したので、そこまでしてディスプレー基板を交換する意味は、少なくとも俺にはなかった。

（いっつあんさんは、すごい。よくここまでばらしたもの。写真勝手にりんくさせてもらいましたｗ）


というわけで、前置きがずいぶんと長くなったが、プリウスのフロント・ディスプレイにはオート・クルーズ（CLUSE）の表示は出ないものの、この機能がON/OFFなのか、クルーズ走行中かどうかの情報は、CAN（Controller Area Network、ほんとはCar Area Netwaork）データとして常に車内をかけめぐっているはずである。

具体的には、１９９５年以降の日本車ではまず装備されるようになったODB2コネクターに、CAN-HとCAN-Lの差動信号が出ているので、そこから情報を得る事にする。


できあがった回路がこれ。


製作したモニターの機能としては、クルーズ機能ONで緑LED（LED１）がON、クルーズ走行ONで赤LED（LED2）がON（Gグレード標準？）、水温が７0度℃超えでLED（LED3）がONという設定だ。水温７0度℃で橙LEDがONにした理由は、プリウスの場合、水温が燃費に関わってくるキーポイントであり、その境目がこのあたりの水温だから。


ところで、CAN通信には、ノイズが充満する車内で高速通信を可能にする規格なので、当然差動信号を使う。高インピーダンス入力の測定器などで使われているツイストペア・ケーブル＋シールドでラインを構成し、専用のトランシーバ（TX、RX）インターフェースが必要。

とはいえ、現実には適当にツイストさせたペアケーブルを簡単にシールドする程度の処理でも、エラーが出るような事はない（ようだ）。数ｃｍ程度なら、シールドも不要だと思う。そもそも、CANではツイストペアだけで、シールドは不要な規格らしい。

実際のプリウスCAN通信系は全部ツイストペアケーブル＋シールドされているので、それにならって本機でもツイストペア＋シールド線としている。

ただ、俺も一度はまったが、現在のCANは車を制御する要（かなめ）である。この通信が切れてデータ授受が不安定になったり、信号がきちんとターミネートされず反射波が増えて通信不能などになると、車のマスターコーションが点灯して、走行不能になる可能性が大きい（非ハイブリッド車でも）。実際俺も走行不能を経験したので、何も勉強せずにCAN周りを触るべきではない。

このMPU（PIC）とCANラインとのインターフェースとして入手が容易なのが、CAN専用のMCP2551で８ピン。その差動信号をシリアルに変換してMPUとの通信を担うのがMCP2515（１８ピン）だが、いずれも自作が楽なDIPタイプを使った。

CANに流れるデータを見るため、最初はもっとI/Oの多いPICを使ってLCDをつないだ上で流れるデータを見たが、必要なデータ（クルーズ関連データとラジエータ水温データ）を確認したあとは、LCDは不要なので、必要データをLEDに表示させるだけならば、１８ピンでも十分の結論になった（８ピンではたぶん無理）。１８ピン（16F716では現実にはI/O数が１４ピンくらいに減る）でもI/Oが余るので、実際は16F1シリーズなどの１４ピンのPIC（実質のI/Oが１０ピン程度）でもいいだろう。

細かい事をいうと、MCP2515の２ピンがMPU側から見て、OUTPUTピンとしてソフトウェア的にプログラム可能なので、I/Oが少ないPICでは利用しない手はない（CAN側からの受信バッファオーバーフロー割り込みができなくなるが。。。）。


MPUには、手持ちで以前からたくさんあったPIC16F716（昔、一個８０円で買ったｗ）を使った。２ｋWのプログラムエリアしかないが、十分だった。おそらく、レガシーPIC、16F84Aでもいいだろう。

現状、２ｋWのプログラム・エリアのうちその1/2強がFF（空白）だ。ちなみに、RAMエリアは1/2の余裕がある。つまり大それた処理はしてないってことｗｗ


PICとMCP2515間は４線SPIで通信する。SPIハードウェアを持つPICなら、もっと高速にかつプログラムエリアを消費せずに実現可能だろうが、ソフトウェアSPIでもまったく問題ない。ただクロックには注意が必要。MCP2515のクロックで、CANスピードが制限されるからである。MPU側のクロックも制限を受けるような気がする。最終的にはMCP2515とMPUのクロックを同一にして、PIC側からＭＣＰ２５１５に供給するようにした。

恥ずかしいが、基板裏側も公開しちゃおうｗ


そのほかには、物理的にODB2コネクターにアクセスするために、コネクタとピンを入手する必要がある。以前はあまりなかったが、今ではかなり安価に入手が可能。当方も数年前、大量にODB２コネクタだけを買ったが、いま探すとどっか行ってしまったようで、行方不明状態であるｗ

なお、PICプログラム上では、この16F716がCANノードとして、リッスン・オンリー・モードで受信専用として動くようにしており（プリウスCAN側への送信はできない）、車の走行自体には極力、影響を与えないようにしている。

もっとも、必要があれば、MPU側からCANに対して要求を送信して、データ取得orプリウスへの強制的動作要求も可能だ。解析してないが、キーロック時にサイドミラー閉動作などもCAN経由で可能なのかも。マイコンのプログラム一つで、いろいろと遊べるのがいいところ。

ただし、走行中にCANのエラーで走行不能になった経験があるので、くどいようですが、くれぐれもみなさん、CAN周りをいじくるときにはご注意を。

要のプログラムですが、ご要望があれば、PIC16F716のHEXファイルは後日、公開します。