satto.v11のブログ一覧

昔作った「自作サイドミラー自動格納」をほしいって人がいて作ってあげようと考えている。でも、この基板を作ったのは4年前でほんと電子回路をかじり始めたころで基板が醜い…w

ならばってことで昔からやってみたかった「プリント基板」を作ってみることにした。基板を作るっていっても自作するわけじゃなくてメーカーに作ってもらう。
いろいろネットを徘徊してみると個人でもうまくやれば発注できるみたい…。

プリント基板を作ってもらうにはメーカーへガーバーデータを送らなけりゃなんない。

今回から電子回路作成のソフトとしてオープンソースの「KiCAD」を使ってみることにした。
このソフトは回路エディタとして「eeschema」。フットプリントエディタ（実際部品のCADデータ）として「cvpcb」。レイアウトプログラムとして「pcbnew」。ガーバービュアの「gerbview」のそれぞれのソフトが含まれていて回路作成のとっかかりからガーバーデータ出力まで作れてしまいます。これらのプロジェクトを統合しているソフトが「KiCAD」です。


対応OSはWindows版・Mac版・Linux版があるみたいです。
「KiCAD」は最近月刊誌の「トランジスタ技術」でよく特集されています。先月ちょうど特集があったのでちょっと立ち読みをさせてもらって一通りの操作方法をマスターしてきました…w

プリント基盤を作るメーカーへ送る「ガーバー」というデータは「印刷データ」とか「穴位置データ」とか「レジスタデータ」がありプリント基板を作ってもらうには必要なデータとなります。

プリント基板を作ってくれるメーカーはたくさんあって日本にも何社かあります。
日本のメーカーは企業向けなのか、製作費はとてつもなく高いです…。
今回は海外のメーカーを使って作製してみました。

今回使ったメーカーは「PCBWay」って会社で作ってもらおうと思います。
http://www.pcbway.com/

中国の会社です。注文はWEB上で行って、データもサイトにアップロードする形で注文していきます。
注文は大きさで単価が決まるみたいなので、一つの基板に複数の回路を描いてあとから切って使おうと目論んでます。

今回は、昔作った比較的簡単なスクラム用回路「ワンショットハザード」と「サイドミラー自動格納」とモンキー用として「ウィンカーポジション灯＆ハザード」
と「アナログCDI」の4つの回路を1つの基板に入るように設計してみました。

昔のデータを引っ張り出してきてKiCADへ移植作業をしていきガーバーデータを作成していきます。
出来上がったガーバーデータは各社指定の拡張子に変更してzipして注文時にWEBへアップロードしてやります。メーカーサイトは中国語でなくすべて英語なので淡々と進めることができます。
データをアップロードしてデータ内容がおかしい時にはメールで問い合わせが入ってくるらしいのですが、今回はなかったので大丈夫だったのでしょう…。


最低発注数は5枚以上となっており、写真の2層基板90mmX95mmを5枚発注して$10でした。作製場所は香港らしく送料は普通郵便で$13となっています。送料のほうが高い…。

しかし、日本の企業にお願いするとこれの10倍の値段となります。

注文後は、WEB上で制作過程が随時更新されていきます。約3日で制作は終わってました。そこから発送に1週間要してますので、10日ちょっとには手元に到着してました。


出来栄えとしては…。キレイ…ちょっと感動もんです。
今回は基板色を青にしてみました。

注文した5枚の基板で合計20個の回路が作れるので…。1枚当たり120円程度…。
思っていたよりコスパはいいのではないでしょうか。

早速、クルマ用の「ワンショットハザード」と「サイドミラー自動格納」回路を組んでみました。

これが「ワンショットハザード」の昔の回路。
ウィンカーレバーを「チョン」と操作すると3回点滅します。レーンチェンジに便利。また添えつけのボタンでサンキューハザード（3回ハザード点滅）が実行できます。

そんで…。これが今回作製したプリント基板回路。すっきりしてます♪


次に、「サイドミラー自動格納」回路。ユニバーサル基板の切れ端で作ったので醜い容貌です。4年前に作ったのですが今まで壊れることなく現役でした。
「エンジンをきれてて」「ドアロックを操作する」の2つの動作が重なると自動的にドアミラーが格納します。「ACC電源が立ち上がる」と自動的にドアミラーが開きます。

これが新作の基板回路です。ちょっと大きくなりましたが。キレイです♪


上記の2つを車に取り付けテストをしてみました。
問題なく今まで通りの動きをしてくれます。成功みたいです♪
残りの2つの回路も作ってみたいけど「アナログCDI」のほうは配線を突っ込む穴が小さすぎた…。やり直しですな…。またいつか作り直します。

これで、ほしいって言ってくれた人にもドヤ顔で渡せます。

長らくの夢だったプリント基板をとりあえず作ることができました。
今回は初めての経験だったので簡単な回路しか作ってません。
もうちょっと勉強をして今まで作ってきたお気に入りの回路を「プリント基板化」しようかな…。

前回「 Audi TTのOBD2で遊んでみた（その１）」の続きです。

今回はもう一台の遊び車マツダスクラムで作ったカーモニターがTTでもあればな〜って動機で作り始めています。
TTではOBD２の「CAN信号」を使って値を取得しようとしています。

前作のスクラムのシステムはECUからくるダイレクトの電気信号を使っていたので、例えば「タコメーター」であれば「回転数」に応じた電気信号のパルス数をマイコンで時間当りの回数を数えて回転数としていたし、「アクセル開度」であればECUからくる信号の電圧をアナログ変換で数値化してから開度としていました。
それぞれ、パルスの回数・アナログ変換などをマイコンで行っていたのでマイコンでは複雑で重たい処理をさせています。
また、配線については表示するデータの本数だけいるのでECUからは数本の配線を回路に通しており、配線が乱雑になりがちでした。どちらかといえば、マイコンの性能に左右される回路でした…。

一方、今回のOBD２での車両情報取りは、CAN通信用のコントローラーを別に設置しており通信はこいつが全て担ってくれています。例えば、「タコメーター」や「アクセル開度」などは車両のECUよりCAN通信を通じて数値としてデータが送信されてくるのでそのデータを換算すればいいだけで、マイコンでの特別な処理を行うことなく負担も少ないです。配線も据付のOBD2のコネクタへ差し込み「CAN High」と「CAN Low」の2本と電源だけで実現でき配線の乱雑さはありません。

前作品については、ここでちょっと詳しく書いています。回路・アプリともに、問題もなくまともに動いているので今でも愛用しています…。


さて…、前のブログでコントローラー(MCP2515)についてブログに書きました。コントローラーの説明だけで終わってしまったので今回は続きの「②CAN通信の処理・制御はマイコンで行う。」からです。

前述したように、マイコンで行う処理は負担が少なく「CANコントローラー」とSPI通信できて、iPhoneへデータを送るための「Bluetoothモジュール」とUART通信ができる程度のマイコンで良いと思います。データの横流しがマイコンの主な仕事です。

今回は、回路配線も少ないので14ピンの「PIC16F1705」をチョイスしました。

このマイコンは、小さいくせにとてもいろいろな機能が付いています。今一番使っているマイコンです。
今回のこいつの仕事は、コントローラ(MCP2515)との「SPI通信」とBluetoothモジュールとの「UART通信」だけです。

CAN通信で使っているコントローラ(MCP2515)とのSPI通信については、あらかじめMSSP機能として機能として付加されているマイコンが多いのですが、SPI通信はとても簡単な通信なので自分で実装したほうが柔軟性があったりします。今回のプログラムもマイコンの機能を使わずピンのHighとLowだけで通信を行いました。

SPI通信には「SCKピン」「CSピン」「SDOピン」「SDIピン」の4本で構成されています。
送信する機器を「マスター」、受信側を「スレーブ」と呼ばれています。
回路では全ての通信ピンをプルアップした状態で配線しています。

送信方法については、まず「CSピン」をLowにして通信開始の旨を伝えます。これは、「CSピン」がLowの間通信をしていることを意味します。送信データではビットのHighとLowを連続で「SDOピン」に送信してやります。受信データの場合は、「SDIピン」から受信します。「SCKピン」は機器間のタイミングを取る信号でSDO・SDIで送受信したタイミングでHighとLowを切り替えて機器間のタイミング取りを行います。

例えば…
CANコントローラ(MCP2515)には読み取りコマンド「0b00000011」があり、このコマンドとレジスタのアドレスをマイコン側から送るとすぐにそのレジスタの内容が送られてくる機能があります。
そのコードをCで表すと…。

unsigned char canRegRead(unsigned char adress) {
　　unsigned char cmdBuf[2];
　　unsigned char cmd;
　　unsigned char i, j;
　　unsigned char result;

　　cmdBuf[0] = 0b00000011;
　　cmdBuf[1] = adress;
　　
　　// 通信開始
　　CAN_SPI_CS = 0;
　　// コマンド＋アドレス送信(2バイト)
　　for( i = 0 ; i < 2 ; i++) {
　　　　cmd = cmdBuf[i];
　　　　for( j = ; j < 8 ; j ++ ) {
　　　　　　if( cmd & 0x80 )
　　　　　　　　CAN_SPI_SDO = 1;
　　　　　　else
　　　　　　　　CAN_SPI_SDO = 0;
　　　　　　cmd <<= 1;
　　　　　　CAN_SPI_SCK = 1;
　　　　　　CAN_SPI_SCK = 0;
　　　　}
　　}
　　// レジスタ内容を受信(1バイト)
　　result = 0;
　　for( i = 0 ; i < 8 ; i++) {
　　　　result <<= 1;
　　　　if( CAN_SPI_SDI )
　　　　　　result |= 1;
　　　　CAN_SPI_SCK = 1;
　　　　CAN_SPI_SCK = 0;
　　}
　　// 通信終了
　　CAN_SPI_CS = 1;

　　return result;
}

みたいな…。簡単なコードでSPI通信を実現しています。ちょっとCをかじっていれば読めるのではないでしょうか。
レジストリの書込みもこのコードの応用でコントローラとの交信ができてしまいます。
こうしたコードを使って、「マイコン」から「CANコントローラー」へ欲しい車体情報をSPIでリクエストしてデータをもらいます。


次は、取得したデータをBluetooth無線へ横流しする。「③データをBLEモジュールに送り、Bluetooth無線で送信を行う。」の部分。
もらった車両情報をUART通信を使って「Bluetoothモジュール」へ送信してやります。


今回はここで使ったBLEモジュールがバージョンアップされたものが発売されていたので購入して使ってみました。浅草ギ研製の「BLESerial2」です。
サイズが小さくなって回路サイズを圧迫しません。でも、3V電源になったため、今回のような5V電源を主体とする回路では別に3Vを用意しなくちゃなんないのでちょっと面倒…。
このモジュールへの入力ピンも3Vとなるのでマイコンからの入力信号電圧にも気をつかわなければなんない…。

でも、前作に比べ接続スピードが格段に早くなっており接続にストレスを全く感じません。
1個2,700円とちょっとお高いモジュールですが、この手の製品はあまりないのでこれがオススメかな…（？）

前述のように、マイコンとBluetoothモジュール間とはシリアル通信であるUART通信となります。
通信は「TXピン」と「RXピン」の2本の配線で実現できます。
今回は、マイコンにある標準の機能を使って通信を行っています。マイコンの設定については「SPBRG」「TX1STA」「RC1STA」「BAUD1CON」あたりのレジスタをいじる感じかな…。

このモジュールの仕組みはUART通信で外部からデータが受信されると即座にそのデータをBluetooth無線データで送信します。マイコンプログラムとしてはCAN通信で得たPID(車両の情報データの固有のID)を1バイト。その生データ2バイト分の合計3バイトをパケット通信のように小分けにして送信するように組んでいます。
0x0F：吸気温度を表すPID。0x003A：データ 58d。というようなデータを送信したい場合は「0x0F 0x003A」としてモジュールに送ってやり、Bluetooth無線上にこのデータを吐き出します。


ここまでが、作製した電気回路でやってることとなります。

最後に無線データをiPhoneアプリで取得して画面にデータ表示させてみます。「④Bluetooth無線のデータは自作iPhoneアプリにて受信し画面にデータを表示させる。」の部分で、アプリの開発となります。
Macの開発環境「Xcode」はこんなのです。


iPhoneアプリの開発はいつものように、Mac上のXcodeの統合開発環境を使用してSwift言語で作っています。
Swift言語も発表したてのときと比べ度重なるバージョンアップで使いやすい言語となっています。

今回もBluetoothを使用して回路と通信を行なうアプリなのでCocoa Touch内の「CoreBluetooth」というフレームワークを使用します。

ここで扱うBluetoothはBLEという規格に準拠した無線を指します。Bluetooth Low Energyの略で、省電力無線通信技術と訳されます。一昔まえまではBluetoothのプログラムを作ることは機器申請などもあり個人ではできるものではありませんでした。しかし、iOS6からはこの規格がiPhoneでも提供され、個人レベルでも気軽にBluetooth無線を利用したプログラムが作れるようになりました。

BLEでは機器側を「ペリフェラル」と呼ばれ今回は上の回路となります。ペリフェラルの情報を使って何らかの処理を行なう機器を「セントラル」と呼びiPhoneとなります。

BLE接続の手順としては、「ペリフェラル」は自分の存在を知らせるために「アドバタイズ」といって自分の提供できる情報を無線を使って発信します。「ペリフェラル」には一つ以上のデータを提供する「サービス」というものをもっており、「セントラル」は「アドバタイズ」されている「サービス」情報を読み取って自分の欲しい情報かを走査します。
その「ペリフェラル」が自分の欲しいデータ・機器であれば接続を確立し「サービス」データを受け取れるように処理をします。取得したデータをアプリ内で処理し画面表示させます。

BLEは接続までのプログラムの手順が複雑で理解に苦労しました。ネット上にもあまり情報もなく文献もあまりない状態です。アップルが発行している日本語プログラミングガイドだけが頼りでした…。
1年前くらいに必死に調べ上げ何とかライブラリを作り上げた経緯があります。現在は何作も使いまわしでこのライブラリを使っているのでバージョンアップを重ね、今は結構使えるライブラリが出来上がっていると思います。今の私の財産です…ｗ
今回もこのライブラリを使って基本プログラムは作成しています。


Mac環境で無料で手に入る開発統合環境の「Xcode」はとても優秀です。InterfaceBuilderというUI用のエディタを使用してアプリを作ると下手をすると1行もコードを書かずにアプリを作ることも可能です。
（結局、詰めていくとUIエディタを使用するよりもコードで書くほうが圧倒的に自由度が効くので私はすべてコードで「書く派」です）

今回、テスト用に作ったアプリはこんなのです。


今回はお試しとして、「エンジン負荷」「スロットル開度」「電圧計」「インテーク温度」「触媒温度」の5項目をOBD2よりデータを取得して表示しています。
画面表示についてはすべてCocoaTouchの標準のUIを使っているのでコード作成は簡単です。


ちなみに…
自分の車の「触媒温度」なんてみたことないけど…。すごく上がってるんですね。初めて知りました。要らないけど…ｗ

Bluetoothで得たデータはOBD2から得た情報をマイコンで横流しして送られてくる生データとなっています（何も計算していないデータ）。
演算能力としてはマイコンとiPhoneを比較すると圧倒的にiPhoneが長けているので計算はすべてiPhoneアプリ内で行ないます。かなり複雑な計算でもサラッとやってのけます。

長い間、グラフィックLCDやOLEDなどの表示デバイスを電気回路で使っていましたが、こんな風にiPhoneで表示させるほうが自由度・表現力が高くてメリットも多いです。表示して回路をデバッグするだけならLCDやOLEDのプログラムをするよりも手軽です。もう他の表示デバイスは全く使わなくなりました…。


ちょっとアプリ作成に力を入れればこんなグラフィカルな画面も作れます。
マツダスクラムでは「カーモニター」アプリとしてこんなのを作ったことがあります。


Audi TTもこんなのをイメージして作ろうとしていますが、今のところ一番表示してみたい「ブースト計」のデータが取得できない…。別の方法があるのか…？
そこを現在調査中。
何か名案が浮かんだら今ブレッドボードで組んでいる回路とアプリの作成にかかりたいと思います。

いつのことやら…。

先日よりTTのOBDⅡが吐き出すデータで遊んでいます。「自作・iPhone表示のOBD2メーターを作る【実験編】」

今回はOBDⅡの規格の中でもCAN通信のデータのやり取りで遊んでみました。
何とか理解ができてきたので備忘録です。
以下のCAN通信用のコントローラを解析中に、「みんカラ」の先人のブログなどが非常に役に立ちました。この先遊んでみたいと思う人のためにちょっとやり方を残しておきます。

でも、興味のない人には全く面白くない記事ですw

今回作るシステムの概要として…
①OBDⅡよりCAN通信によって車体のデータを吸い取る。
②CAN通信の処理・制御はマイコンで行う。
③データはBLEモジュールに送り、Bluetooth無線で送信を行う。
④Bluetooth無線のデータは自作iPhoneアプリにて受信し画面にデータを表示させる。

OBDⅡとは自動車の自己診断機能を表します。Wikiによるとヨーロッパでは2001年より、日本では2008年10月以降に製造された乗用車および小型トラックに搭載を義務付けられています。
この自己診断機能を使って車体情報データを取ってやろうという目論見です。
今回の実験は標準的に取得できる「モード01」の標準的に取得できるデータのみを考えています。もうちょっと踏み入れば色々なデータが取れそうですが、まずは簡単なところから…。

OBDⅡのコネクタはこんな形状です。

コネクタは16ピンで構成されており、CAN通信では6ピンの「CAN High」と14ピンの「CAN LOW」を使用します。
ちなみに16ピンの「バッテリー電源」は常時電源となり常にバッテリー電圧が付加されています。通電しっぱなので電子回路にはちょっと使いにくい電源です。
今回は「CAN High」と「CAN Low」の2本のみを使用してみます。


CAN通信の送受信されるデータは「アービトレーション」「コントロール」「データ」の大きく3つのフィールドに分かれています。

「アービトレーションフィールド」はデータの識別子IDです。標準フォーマットで11ビット分のフィールド値が設定でき、拡張フォーマットは29ビット分のフィールド値が設定できます。
「コントロールフィールド」にはデータフィールドの長さがバイト単位で入力されています。
「データフィールド」には送受信したいデータが入力されています。

車両の診断機能ではデータ要求に標準フォーマット「0x7E0」(=0b11111100000)の識別子IDとほしいデータを要求送信します。すると、「0x7E8」（=0b11111101000）の識別子IDと結果データが付いて返答として帰ってきます。
（※プログラム言語で書きなれているので「0b」は2進数・「0x」は16進数と理解ください…）

例として「エンジンの回転数」がデータとしてほしいとすると…
（※以下概要ですので厳密には違います）
0x7E0 8 02010C0000000000のデータをCAN通信上に流します。
「0x7E0」はデータ要求の標準識別子IDを表す「アービトレーションフィールド」。
「0x8」はデータの長さ（バイト単位）を表す「コントロールフィールド」。
それ以降の「02 01 0C 00 00 00 00 00」は「データフィールド」であり、「コントロールフィールド」で宣言した8バイト分のデータを送信しています。
「0x02」はデータに入っている個数をバイト単位で表します。
「0x01」はモードで「01：車両の制御状態を得る」を意味します。
「0x0C」は「エンジン回転数」を表すPID（パラメーターID）でほしいデータをここに入力し送信します。

するとCAN通信上に…
0x7E8 8 04410C1678000000のデータが返信されてきます。
「0x7E8」はデータ返答の標準識別子IDを表す「アービトレーションフィールド」。
「0x8」はデータの長さ（バイト単位）を表す「コントロールフィールド」。
それ以降の「04 01 0C 16 78 00 00 00」は「データフィールド」であり、「コントロールフィールド」で宣言した8バイト分のデータを送信してきます。
「0x04」はデータに入っている個数をバイト単位で表します。
「0x41」はサービスIDの返信データIDを表します。
「0x0C」は返答しているPID。
「0x16 78」はPIDの実データとなります。

最後の「0x16」と「0x78」がエンジン回転数を表すデータであり、次の計算式が成立します。(256*0x16+0x78)/4が成立して、10進数に直すと(256*22+120)/4 = 1438rpmという「エンジン回転数」が導き出されます。

これらのPID等の詳しい情報は、Wikiに詳しく記載されています。英語ですけど…。

上記の例は、CAN通信を簡略化して書きました。実際のCAN通信はもうちょっと複雑なことをやっています。しかし、以下のCAN用のコントローラーを使うとこのくらいの知識くらいあれば、後はコントローラー任せで通信できてしまいます。


今回実際にOBDⅡのCAN通信用に考えた回路は以下です。

大きく「CAN通信部分」「マイコンの制御部分」「Bluetooth通信モジュール」に分けられています。

まずは…
①OBDⅡよりCAN通信によって車体のデータを吸い取る。の部分として…。
CAN通信のIC部分にはCANコントローラ「MCP2515」とCANトランシーバ「MCP2551」を使用しています。

CANトランシーバの「MCP2551」は入力のCAN信号と出力のCAN信号のレベルを合わせてくれるもので実際には何をやっているのか今もわかっていません…ｗ
でも要るものらしいので回路に組み込んでいます。特に接続に難しい箇所はなく「RS」ピンをGNDに取り付けることを忘れないようにするくらいです。

実際のCAN通信はCANトランシーバ「MCP2515」のほうが肝となりここでCAN通信のすべてがコントロールされます。

このコントローラーのレジスタは以下のようにあって、このレジストリを設定しながらコントローラーの動きを決めていきます。


「CANCTRL」レジストリは、主に動作を設定するレジストリです。

「CNFx」の3つのレジストリはコンフィギュレーションで通信の速度やピン設定などを行ないます。

「CANINTE」「CANINTF」は割込み許可の設定や割込みフラグの監視に使用します。

コントローラには「フィルタ」「マスク」の設定ができて、受信されたデータにはIDを持っています。膨大な量のデータが受信された場合には、その処理にCPU（今回はマイコン）に負荷がかかってしまいます。それを避けるために「RXFx～」「RXMx～」の設定で受信したIDに関所を設け必要なものだけを処理に回すことができます。

大体ここまでのレジスタを初期化処理で設定しています。
MCP2515にはいくつかのコマンドを持っていてレジストリの読取・書込作業はマイコンよりSPI通信によってコマンドを実行していきます。

この、SPI通信とは同期式の通信でIC間の通信によく使用されています。今回使用のマイコン「PIC16F1705」にも標準でMSSPってSPIが搭載されているけど通信方法はいたって簡単なので自分でプログラミングしたほうが柔軟性が利いたりします。


SPI通信によるレジストリの書込みコマンドは「0b00000010」であり、その後にレジストリの「アドレス」と「データ」を続けて送信することで、その「アドレス」に指定した「データ」を書込むことができます。

例えば、「CANCTRL」のレジストリに「0b01000000」のデータを設定したいとすると…
SPI通信でマイコンからコマンド「0b00000010」を送信して、上記の表よりCANCTRLのアドレス「0b00001111」を送信。続けてデータの「0b01000000」でSPI通信を終わらせるとレジストリが書き換えられます。
要は、「0x02 0x0F 0x40」をSPIで送信する。理解できれば簡単です。
このように、レジストリに書込みを行ないながらコントローラMCP2515の設定をしていきます。


初期設定が終わったら、実際に通信を実行してみます。

コントローラーには動作モード設定があります。電源直後は「コンフィギュレーションモード」となっており、初期化を行なう際にはこのモードにする必要があります。
通常の通信動作にするときには「ノーマルモード」に変更する必要があります。
動作モード切替は「CANCTRL」(0x0F)の「REQOP」(5～7)にて変更を行ないます。「0b000」が「ノーマルモード」で「0b100」が「コンフィギュレーションモード」となっています。ビット変更については後述の「ビットモデファイ」が変更しやすいです(0x05 0x0F 0ｘE0 0x00をSPI送信で「ノーマルモード」）。

「ノーマルモード」に切り替えたら通信することが可能となります。
このコントローラは2つの受信バファ「RXB0」と「RXB1」を持ち3つの送信バファ「TXB0」「TXB1」「TXB2」を持っています。
表のRXBx～とTXBx～で表されているレジストリがそれです。
受信バッファはアドレス「0x60～0x6E」「0x70～0x7E」にあり、送信バッファは「0x30～0x3E」「0x40～0x4E」「0x50～0x5E」に位置します。
今回のプログラムでは1つずつの送受信バファのみを使いました。

先の例のように「エンジン回転数」のデータを取得するためにMCP2515を設定してみます。

まずはMCP2515よりほしいデータを要求送信をしてみます。
データ要求のID「0x7E0」を送るために、送信用の標準フォーマットIDを設定するレジストリである「TXB0SIDH」と「TXB0SIDL」を設定します。標準フォーマットは11ビットに対し使用するマイコンは8ビットマイコンであるのでレジストリが2つに分かれています。
「TXB0SIDH」の8ビットと「TXB0SIDL」の上位3ビットに「0x7E0」（=0b11111100 000）を設定するには「0x7E0」のIDを左に3ビットシフトして上位8ビット分の「0xFC」を「TXB0SIDH」書込み。残りの3ビット「0b000」を「TXB0SIDL」の上位詰め3ビットに書き込みます。
先のSPI通信のMCP2515書込みコマンド「0b00000010」を使ってマイコンより上記レジスタのアドレス「TXB0SIDH(0x31)」=0xFC・「TXB0SIDL(0x32)」=0x00にそれぞれのIDデータを書き込みます。
マイコンからSPIでMCP2515に向かって…
「0x02 0x31 0xFC」
「0x02 0x32 0x00」
と命令すればOK。

次に「データフィールド」の長さを設定します。対応するレジストリは「TBX0DLC」となります。CAN通信での送信バイト数は常に8バイトで設定しています。ちなみに、このレジストリには6ビット目に転送要求の種類を設定する「RTR」がありますが、送信データはデータフレームであるので常に「0」となり、「TBX0DLC」にはダイレクトにデータフィールドのバイト数を入力しても構いません。
なので、「TBX0DLC(0x35)」=0x08をこのレジストリに書込みます。
マイコンからSPIでMCP2515に向かって…
「0x02 0x35 0x08」
と命令すればOK。

最後に「データフィールド」の中身を設定します。「TXB0D0」～「TXB0D7」の8つのレジストリに送信するデータを直接入力します。レジストリのアドレスは0x36～0x3Dです。
例ではデータとして必要な3バイト分のデータを書込み、残りの不要な5バイト分を0x00で埋めて「0x02 0x01 0x0C 0x00 0x00 0x00 0x00 0x00」のデータをレジストリに書き込みます。
「0x02 0x36 0x02」
「0x02 0x37 0x01」
「0x02 0x38 0x0C」
「0x02 0x39 0x00」
「0x02 0x3A 0x00」
「0x02 0x3B 0x00」
「0x02 0x3C 0x00」
「0x02 0x3D 0x00」
を命令すればOK。

ここまで設定できれば実際に送信開始の命令を出してやります。「TXB0CTRL」(0x30)レジスタ「TXREQ」(3)の「メッセージ送信要求」のフラグを立ててあげれば送信が始まります。
あるアドレスのあるビットのみをいじる方法はやり方はいろいろあるけど「ビットモデファイ」ってコマンドを使うと1つの命令でこれが実現できます（前述の「CANCTRL」でも使用)。
コマンド「0x05」の後に「アドレス」・「マスク値」・「データ」を続けて送信します。
ここでは、アドレス0x30の3ビットを「1」にするので…
「0x05 0x30 0x08 0xFF」
を送信してやります。ちなみに同じところを「0」にしてあげたければ…
「0x05 0x30 0x08 0x00」
で実現できます。

以上のようにTXBのデータをロードして送信リクエスト「TXREQ」のフラグを立てればデータがCAN上に流れて行きます。

すると、「0x7E8」のIDと返信情報を持ったデータがCAN上へ流れて来ますのでそれを拾ってやります。

受信のバッファは「RXB0～」のみを今回は使用しました。
先の初期設定で行なった「フィルタ」「マスク」の設定を行なうと必要なIDだけを取り出すことができます。

受信のタイミングは「CANSTAT」(0x0E）レジスタの「ICOD」(1～3）が0b110になっているかポーリングして受信を確認できますが、今回は「INTピン割込み」を使って受信をMCP2515からマイコンに知らせてやります。

「RXB0～」のバッファがいっぱいになると（受信されると）MCP2515の「INT」ピンがLowレベルとなりそれをマイコンで割り込みをかけて受信を確認することができます。

先の「CANINTE」(0x2B)の「RX0IE」(0)のフラグを初期設定で立てていれば割り込みが行なわれます(「0x05 0x2B 0x01 0xFF」を初期設定で行なっておく）。
割込み確認後は「CANINTF」(0x2C)の「RX0IF」(0)にフラグが立っているのでソフトウェアリセットが必要です。（「0x05 0x2C 0x01 0x00」）

受信データは「RXB0SIDH」「RXB0SIDL」「RXB0DLC」「RXB0D0」～「RXB0D7」のアドレスに入ってきます。

「RXB0SIDH」「RXB0SIDL」「RXB0DLC」のアドレスについては初期設定の「フィルタ」「マスク」で「0x7E8」のみを受信する設定をしていれば、標準フォーマットID(0x7E8）と受信データ長8バイトが入ってきます。

実際の受信データについては、「RXB0D0」～「RXB0D7」(0x66～0x6D)にセーブされているので、このアドレスのデータをとってあげればデータ取得できます。

SPI通信のMCP2515読込みコマンド「0b00000011」を使います。コマンド「0b00000011」を送って、ほしいアドレスを送信するとすぐにそのデータがSPI通信上に流れてくるのでそれを拾ってやる感じです。
例えば、「RXB0D1」～「RXB0D4」のデータを取得してみます。
「0x03 0x66」をSPIに流すと…「0x04」（受信データのバイト数）
「0x03 0x67」をSPIに流すと…「0x41」（サービスIDを表す返信データID）
「0x03 0x68」をSPIに流すと…「0x0C」（エンジン回転数のPID）
「0x03 0x69」をSPIに流すと…「0x16」（エンジン回転数データ1）
「0x03 0x6A」をSPIに流すと…「0x78」（エンジン回転数データ2）
がそれぞれSPI上に流れてくるのでそれを取得して計算してやります。

以上のように、マイコンとMCP2515コントローラーとのSPI通信のやり取りでCAN通信のデータを送受信ができてしまいます。
コントローラーとの通信が理解できれば、実際のCANの細かい通信方法についてはあまり考える必要もなく簡単にCAN通信ができます。
説明下手だから文章じゃわからないか…ｗ



じゃ一体何のデータが取れるのか…？
取得できるデータ（PID)はWikiに詳しく記載されており、196種類のデータがあります。
でも、すべてのデータ取れるわけでもなく車両・メーカーによって異なります。

車両によりサポートされるデータは調査できるようになっています。
データ中のPID(パラメーターID)「0x00」「0x20」「0x40」「0x60」をそれぞれ指定してデータを取得するとサポートされるPIDの調査ができるようになっています。

例えば、「0x00」をPIDとしてデータを取得すると、4バイトのデータが帰ってきます。
私の年式のAudi TTの場合は、「0xBE 0x1F 0xA8 0x13」ってデータが返信されました。これを2進数に直すと…
「0b 1011 1110 0001 1111 1010 1000 0001 0011」
となります。
この数字は「1」がサポートされているPIDで「0」がサポートされていないPIDを表しています。
取得したPID（0x00）の次PID（0x01）からのサポートの有無を表す羅列です。「0x20」までのサポート状況を確認できます。


2009年式TTは、PID「0x00～0x20」まででは以下のデータが取れそうです。
「水温計」「エンジン回転数」「「車速」等々…。一般的な情報が並んでいます。

PID「0x21～0x40」までのデータはこんな感じ…。
「大気圧」がある。それ以外は欲しそうなデータはないか…。

PID「0x41～0x60」までのデータはこんな感じ…。
「電圧」が取れそう？　それ以外はちょっとわからない…。

「0x60」に1が立たなかったので「0x60」以降のPIDはサポートされていないみたいです。

ざっくり、見た感じ「あっこれ！」って情報は取得できないみたいです。
でも、取れる情報もわかったし、簡単にデータが取れそうなので何かのモニターは作ってみたいと思います。

コントローラの実装方法でえらく長文になったので、それ以降の「マイコン」関係・「Bluetoothモジュール」関係・「自作iPhoneアプリ」関係は、（その２）としてまた後日書こうと思います。

久しぶりに電子回路で遊んでみます。

「クルマとiPhoneをBluetoothでつなげてみた」で作った車用のモニター。

iPhone側のアプリを作った頃はまだ開発言語Swiftが発表されたばかりでiPhoneバージョンもiOS9になって色々とAPIなども変わってきた。
アプリ自体には特に困ってはないんだけど大分Swift言語にも慣れてきたしマイコンも変えたいしもう一度作り直してみる。


ってことで、今回はクルマ（スクラム）から送られてくるデータで使えるものはないかと色々探ってみます。

前回の「クルマとiPhoneをBluetoothでつなげてみた」で作った車用のモニターは、ECUの情報として「アクセル開度」「水温計」をもらって表示させていました。

加えて「ブースト計」の簡単な回路を使って過給圧を表示。「電圧計」・「位置情報」などなど。

今回はECUデータとして「車速信号」「エンジン回転数」が拾えそうなのでちょっと考察してみます。
自身の備忘録なので暇な方だけどうぞ…w


ちなみに、スクラム（エブリィ）のECUは運転席下エンジンルームの右側についています。

私のクルマではECUについているコネクタは図の「SP」が車速信号。「TA」がエンジン回転数となっていました。同じ年式でも微妙に位置が違ったり、コネクタ形状が違ったりと取り出す時には注意が必要です。


まずは「車速パルス」を拾って遊んでみます。
手元にあるハンディのオシロスコープに速度パルス信号を突っ込んで走ってみました。

メーター読み時速60kmの時の波形…

電圧7.5Vで24ミリ秒の波長。周波数では42Hzみたい。

続いてメーター読み時速80kmの時…

同じく電圧7.5Vで18ミリ秒の波長。周波数で56Hz。
ちょっとノイズが乗っているけど綺麗な波形が取れています。


クルマについている車速センサーが吐き出す信号は「JIS D5601」で決まっているモノらしいです。
「機械式スピードメータの速度指示機構は、駆動軸が637rpm（主として四輪自動車用）又は1400rpm（主として二、三輪自動車用）の回転をしたとき、60km/hを指示する割合とする。」
「電気式及び電子式スピードメータの速度指示機構は、原則として下式が成り立つように指示する割合とする。」

って難しく書かれていますが簡単に式に書くとこんな感じ
（車速パルス） ＝ （車速） X （N） X 637rpm ／ （60秒 X 60km/h）

車速パルスの単位はHz。車速はkm/h。
式中のNは「駆動軸１回転当たりの発生パルス数」となっており「4・8・16・20・25」のいずれかの値を取れ、とあります。
この値はスクラム（エブリィ）では詰めていくと「4」を取っていることがわかりました。すなわち駆動軸90°回転するごとに1パルス吐き出すってこと。

これらから上式をもっと簡単にすると「（車速） ＝ （車速パルス） ／ 0.708」ってことになる。

これを先ほどオシロで測定した波形で計算すると、メーター読み時速60kmでは「時速59.3km」。メーター読み時速80kmでは「時速79.1km」となるのでいい値として測定できそうなのがわかる。
なので、このパルスを測定して「速度メーター」が作れそう♪


続いて「エンジン回転数」を拾って遊んでみます。
同じようにエンジン回転数信号をオシロスコープに突っ込んで測定してます。

1000rpmのほぼアイドリング時の波形。

電圧12Vで41ミリ秒の波長。周波数では24Hzみたい。

続いて、走行中3000rpm弱ぐらいの波形。

同じく電圧12Vで16ミリ秒の波長。周波数で63Hz。
これも比較的綺麗な波形が取れそうです。

ここで最初は素直にエンジン回転軸1回転当たり1パルス吐き出しているのかな〜って思って計算してみました。
1000rpmの時が24Hz。すなわち1秒間に24パルス60秒で1440パルスなので1440rpmってことになる。50%くらいの誤差があるのでこれは単純にエンジン回転軸1回転当たりの信号ではなさそう。

だとしたら…。
プラグ点火のタイミングか？ってことで計算。
スクラム（エブリィ）は４サイクルエンジンの３気筒です。
４サイクルエンジンなので回転軸２回転で１回点火ということは720°で１回点火。
それが３気筒なので720°／3気筒で240°毎に点火していることになる。
ということは360°／240°＝1.5なので、点火間隔時間を1.5倍してやれば１回転のパルスが計算できる。
メーター読み1000rpmの時の波長の場合、1000ミリ秒／(41ミリ秒X1.5）X60＝975rpm
メーター読み3000rpm弱の時の波長の場合、1000ミリ秒／(16ミリ秒X1.5）X60＝2500rpm
となって近い値が計算できることがわかる。
この計算式でエンジン回転数「タコメーター」が作れそう♪


これらの考察であっているかどうか、ブレッドボードを使って簡単な回路を作って検証してみます。


この回路の流れとしては…。
ECUの「速度パルス」と「エンジン回転数」をマイコンに取り込んで、マイコン内でパルスの間隔時間を測定します。
測定した生データをUARTという通信規格にもとづき「SBDBT5V」というBluetoothモジュールへ送ってやります。
受信した「SBDBT5V」は生データをiPhoneへBluetoothの無線送信を使ってひたすら続けます。
受信したiPhoneはアプリによって「速度」「回転数」を計算しiPhone上に表示させてやります。

今回のECUからのデータは8Vや12Vの電圧の信号のようです。このままでは電圧が高すぎてマイコンには直接突っ込むことができません。トランジスタのスイッチングを使って5Vの信号に変えマイコンに取り込んでやります。

マイコンは、「PIC16F1705」を使いました。14ピンの小さなボディに機能が満載です。パルスの時間間隔はCCPの「キャプチャー」を使って測定しています。

Bluetoothモジュール「SBDBT5V」のBLE（Bluetooth Low Energy）という規格は、「近距離無線通信技術　Bluetoothの拡張仕様」でありBluetooth4.0て策定された規格です。この規格により個人でも、このように気軽に無線通信のプログラムが作れるようになりました。確かiPhone4Sから使える機能でiOS7あたりからアプリが作れたと思います。

「マイコン」で計算を行うのと「iPhone」とでは圧倒的にiPhoneの方が計算速度は速いです。なので、マイコンではデータのみを取ってやってそのデータをそのままiPhoneに送ります。そしてiPhoneアプリで細かい計算を行っています。


せっかくここまでデータを取って回路も作ったのでデバッグ用の簡単な「アプリ」を作りました。

何もない「速度」と「エンジン回転数」を表示するだけのアプリですw

開発言語は「Swift2.0」。iOSはバージョン9.1。開発統合環境はXcode7.1で今の最新の環境を使って開発しました。iPhoneは「6」です。
Swiftも2.0となり大分使いやすい言語になってきました。もうレガシー言語Objective-Cには戻れません…w

この手のアプリはBLEの接続部分のプログラムが複雑で面倒臭いです。一度ライブラリーを作ってしまえば、表示プログラムなんぞは1時間もあれば作れちゃいます。


実際にアプリを作って車に乗り込み使ってみました。

クルマについているメーターと照らし合わせても大きな違いもなく正常に「速度」「回転数」を指していると思います。

なので、上記の考察はあってる……多分。

通常の走行での表示は全く問題なしですが、強めにアクセルを踏み込むとおかしな値を示します。これはおそらくノイズを拾ってるんだと思う。時速250kmとか15,000rpmとか…。
回路側でこのノイズ除去処理を考えると色々面倒くさいので本番のソフトではある程度ノイズを無視するフィルターを作ってやります。


クルマとの接続は、もちろん無線で接続しているのでこんな風に配線無しで表示できてしまいます。
ちなみに、このBluetoothモジュールは送受信ができるので、今回はiPhoneへ送信だけですが、逆にiPhoneからの操作ってこともできます。遊び道具としては面白い。

また久々に凝ったアプリも作りたいしもう一度「カーモニター」アプリVer.3を作ってみます♪

久々のブログです。
マイコンを使って車やらバイクやらを色々いじり倒すことにまだはまっています。

マイコンはマイクロチップ社の「PIC」を使用しています。このマイコンはインターネットでの情報も多くて入手性もいいので愛用しています。世の中にはもっと性能の良いマイコンは存在しますが、環境がすでに揃っているのでなかなか移行するのは面倒くさいw

実際に自分でプログラムをしてマイコンに書き込むのは、「統合開発環境」を使ってプログラムをして「ライタ」を使ってフラッシュマイコンに書き込みます。

「ライタ」はマイクロチップ純正の「PICkit3」ってライタを愛用しています。

「統合開発環境」はこれもマイクロチップ社純正の「MPLAB IDE」を使用しています。
WindowsでもMACでもLinuxでも使えるようです。

現在パソコンに入っていて使用している統合開発環境MPLABのバージョンは「Ver.8.84」でかなり古いバージョンです。「MPLAB X」なる新しいバージョンが出ているのは知っていましたが、使用しているPICマイコンが古く特に問題はなかったのでバージョンアップすることなく使用していました。

が…。
今回最初の写真のマイコン「PIC16F1705」を使ってみたくなりました。
14ピンの小さなボディにPLL付きで32MHzのスピードと8kワードのプログラムメモリー、「CCP」や「PWM」「I2C」「SPI」などの基本的な機能はもちろんのこと「オペアンプ」が内蔵されていたりピン割付ができる「PPS」が使用可能であったり、「ZCD」「COG」「CLC」などちょっとよく分からない機能とかとにかく盛りだくさんの機能の付いているマイコンです。
この中で、グラフィックLCDなどのデバイスではメモリを多く使ってしまいます。8kワードのメモリは嬉しいところ。今まで使っていたマイコンは4kワードのものが多くグラフィックデータをメモリに確保してやってあとは残りすくないメモリでいかにプログラム容量を小さくするかとの戦いです。1ビットは血の一滴となりますw
あとは、「PPS」機能が付いているのも嬉しい。この機能は「CCP」や「I2C」「SPI」などのMSSPのピンを好きなピン番号へ割り当てられる機能で、例えばこの機能のないマイコンで自作で回路を作っているとマイコンによっては色々な場所へ各ピンが割振りられているので回路が乱雑になってしまいます。でも、この機能を使うと最短のピンへ割り振りができるので回路が小さくすることができます。

なので、ぜひこのマイコンを使ってみたい…。

でも…。
今使っている「Ver.8.84」では「PIC16F1705」は使えない…。比較的新しいマイコンなので古いバージョンでは対応していないらしい。
ってことで重い腰を上げて「統合開発環境」をバージョンアップしました。「MPLAB X IDE Ver.3.05」です。

このバージョンで、このマイコンは使えるようになると思います。

サクッとインストールして使ってみました。
まだ、深くは使っていませんが「Window」→「PIC Memory View」→「Configuration Bits」って機能がいいですね。これは、マイコンのハード側の設定するコンフィギュレーションですが、マイコンの機能が増えるとこの設定する項目が増える傾向にあります。今まではデータシートとにらめっこをしながら手打ちで入力していましたが、このバージョンからは各マイコンにあったコンフィグレーションの設定をマウスで選んでコピペで記述できるようになっています。
また、今まで作っている古いバージョンからの移行もメニューがありスムーズに行えそうです。

通常マイコンへの書き込み方法は、プログラミングをしてコンパイルを通して「統合開発環境」から「ライタ」を通じてマイコンに書き込みます。その際「ライタ」とマイコンの間に書き込み用の回路が必要です。これは自作で作れる簡単な回路です。書き込む際には当然マイコンには電源を供給しなければなりません。本当は別電源で3Vないし5Vを供給すべきなのですが、「ライタ」からも供給することができます。
自作の書き込み回路は書き込むだけの作業で手軽なので「ライタ」から電源を供給しています。

この電源のON/OFFの作業が新しいバージョンではソフト上で簡単にはできない…。
前バージョンでは、ツールバーにボタンがあったので気軽にON/OFFが可能でしたが、新バージョンでは5ステップのコマンドを切らなければON/OFFできない…。つかいずらい…。

ってことで、14ピン用の書き込み回路も追加しなければならないし「書き込み回路」も新作しました。


「PIC16F」ファミリーの現在主に使用している8ピン・14ピン・18ピン・28ピンがそれぞれ書き込みができるようにしました。回路側でON/OFFできるように電源スイッチを取り付けています。これで「統合開発環境」のソフト側でON/OFFする必要はありません。
この回路も中身は単純で「PICkit3」から出ている、電源供給の２本・MCLRピン１本・PGCとPGDのピンへそれぞれ１本づつ合計５本を配線してやるだけです。

こんな回路…。


これで、ターゲットの「PIC16F1705」が使えるようになったはず…。
とりあえずデータシートを読んで定番(？)のLEDピコピコ回路を作ってやってみました。
よく使っている16Fファミリーなので特にむすかしい所はなさそうです。

手元に、ヤフオクで買ったOLEDのSSD1306系のグラフィックLCDがあるので「SPI」通信でちょっと表示させてみました。

これも問題無し。
これだけの画像を表示させているだけのプログラムですが、まだまだメモリに余裕があります。
ピン割付の使用感もよい。

かなり面白そうなマイコンです。このくらいの大きさの高性能なPICを探していた。
このマイコンはピン数も少なくコンパクトに回路がまとまりそう♪

モンキーの進角付きCDIも手こずって頓挫しているし、中休みにこのマイコンを使って何か作ってみようかな〜。

現在妄想中…w