marumonのブログ一覧

週末の3日間行われたヨットレースに参加したとき、開発してきたスマートフォンを使ったナビゲーションが結構実用になったので、その開発記。


スタンドアロン版に急遽変更

ブログによると6/30には、計画始動となっているが、まず、bluetoothの開発優先だったので、結局B&Gとの接続部分はほとんど手付かずの状態だった。夏場を過ぎて、毎週末ヨットレースがあるようになったので、なかなか実際にB&Gとの接続試験を出来ないまま今回のレガッタ1週間前の先週末を迎えたのだが、折からの台風で日曜のレースはキャンセル。今日が最後のチャンスと日曜日、台風の中ハーバーで接続試験をやったのだが、これが動かない、どうしても動かない、なんで？？？状態。うー、B&Gのデータひらうのダメかー....
レースは来週に迫っているし、PICやらandroidやらのプログラムを1週間で仕上げるのは、ちょっと無理かなーというか、絶望的。そういうわけで、急遽B&Gのデータ取得はあきらめ、スマートフォン単体でGPSのみのナビに目標を変更したのでした。


さらに、はまる

で、週明けスマホのGPSを使おうといじっていたのだけど、なぜか衛星を拾わない。gpsstatusでもぜんぜん衛星が見えてこない。これまたなんで？？状態。
で、ふと気がついたのが、root化してカスタムカーネルに入れ替えていること。すっかり忘れてました。カスタムカーネルでテレビが使えないのは、知っていたけど、GPSが使えないと言う情報は聞いたことが無い。でも、確かにカスタムカーネルだと、ドライバが入っていないかも。
と言うわけで、gscriptに仕込んであった、ノーマルカーネルに焼き戻すスクリプトを走らせると、なんとなくエラーぽい表示が出た。あまり気にせず電源切ってリセットすると、、、
auロゴで止まったまま。いわゆる文鎮化。とほほ。


予備機にも、はまる

げげ、電話はいいとして、ネットにつながらないのは困るよなー。と、こういうときのために買っておいた予備機を取り出し、simカード差し替えて電源入れると、simカードを刺せとの表示。あれ？　入れそこなったかな、と入れなおしてみても、やっぱりだめ。これまた、これまたなんで？？状態。
ほんとどーして動かないのだ、と、simカードのコネクタ部分みると、、、、端子が一本折れてます。終了！　こんなところの端子がなぜ折れているのかまったく不明。


microSDカードにも、はまる

さて、予備機が役に立たないことが判明して、いよいよ困っただけど、使っているIS04の少しだけいいところは、文鎮化してもシステムアップデートすると、復活する可能性があるのだ。で、それにはmicroSDカードに、システムを書いておいて読み込ませればいいので、この前買っておいた8ギガのmicroSDカードにシステムを書き込んで、アップデートしようとすると、SDカードが読めない、と出てアップデートできないのだ。
オイオイ、それは無いだろうと、予備機の方で読み書きしてみるとちゃんと読める（予備機はsim端子が折れているだけで、android端末としての機能はちゃんとある）。念のためと、予備機でフォーマットして、microSDカードにシステムを書き込んで見たが、やはり読み込まない。システムの転送に約30分ほどかかるので、やり直すたび時間が過ぎていく。

いったいどうすればいいのだ。ということで、もしやと、普段使ってる16ギガのmicroSDカードで、やり直してみると、すんなりアップデート終了。メールやアドレスなどのデータもほぼ無傷。復活して良かったーだが、、、、なんで8ギガのmicroSDカードだとダメなの？？？microSDカードも相性ってあるのか？？？

---------------------------------------------------------
なんかぜんぜんナビの開発に進まないんですけど、、、、
というか、開発が大変というより、開発を始めるまでが大変だったと言うお話。

ということで続く。

さて、今日も今日とてはまりまくり。

PIC32のinterruptを使ってみようとしたら、PIC24とは結構違う。
特にUARTのハンドラは送受信兼用になるみたい。
で、よくわからないから、MICROCHIPのデバイスのページにあるサンプルコード　PIC32_UART_CodeExample　を取ってきて動かしてみると、これがまたおかしな挙動をする。

<pre>
void __ISR(_UART2_VECTOR, ipl2) IntUart2Handler(void)
{
// Is this an RX interrupt?
if(INTGetFlag(INT_SOURCE_UART_RX(UART2)))
{
PutCharacter('+');
// Clear the RX interrupt Flag
INTClearFlag(INT_SOURCE_UART_RX(UART2));

while (DataRdyUART2()) {
// Echo what we just received.
PutCharacter(UARTGetDataByte(UART2));
// Toggle LED to indicate UART activity
mPORTBToggleBits(BIT_5);　　　//ここだとトグルする
}
// Toggle LED to indicate UART activity
//mPORTBToggleBits(BIT_5); //←オリジナルのここではトグルしない
}

// We don't care about TX interrupt
if ( INTGetFlag(INT_SOURCE_UART_TX(UART2)) )
{
INTClearFlag(INT_SOURCE_UART_TX(UART2));
}
}
</pre>
割り込み部分をこうしてみた。。単純に受信したら、エコーバックするだけ。
でも、ビットはトグルしないし、エコーバックも変。
で、ちょっと改造して、上のようにして、12345とキーを打つと、、、

+1++2++3++4++5++6++7++8++9+

ね、　interruptが2度起こってる？？？？

はまりました。
サンプルコードがちゃんと動かない？？？
送信のエラッタは知ってるけど、受信のエラッタ無いよ。
どーなってるの？？

で、pic32 interrupts twice　で検索するとmicrochipのフォーラムに行き当たって、
結局

Family Reference Manual section 21.6.3
For UART1A, UART1B, UART2A, UART2B, UART3A, and UART3B modules, an interrupt will be generated while the interrupt condition specified by the RXISEL control bits is true. This means that to clear an interrupt for these modules, prior to clearing the corresponding UxRXIF flag, the user application must ensure that the interrupt condition specified by the URXISLE control bits is no longer true.

オイ、サンプルが間違ってんだろ！（怒）

ということで、
INTClearFlag(INT_SOURCE_UART_RX(UART2));
をルーチンの後ろに動かしたら、ちゃんと動いたけど、なんだかな～。
------------------------------------

うー、コードをインデントさせたいけど、<PRE>入れてもダメかー。
やはり、みんカラの限界かな～(--;

ちょっとpic開発にエンジンかかってまいりました。

hrdakinoriさんのpicへのlwbtの移植があるにもかかわらず、無謀にも独自に車輪の再発明をすべくがんばってきましたが、ようやく今日lwbt独自移植版でbluetooth通信に成功！うれしー。

さらにpbufのmalloc使用による毎回のメモリ確保をやめて、poolbuf使用にしたので効率アップ、というか、heap無しでよくなったのでメモリ効率が良くなるわけですが、実はほとんど意味が無い。。。

さらに、ターゲットマイコンもPIC24FJ64GB002からPIC32MX250F128Bへ変更。
PIC32MXは初めてだったので、かなり最初は苦労したけど、なんとか移行に成功したみたい。

さて、オレのページにも何人かの方がbluetoothの開発情報を求めていらっしゃるようですが、オレのようなアマチュアの方は、ターゲットをPIC24FからPIC32MX250F128Bへ変更されることを強く推奨しておきます。

そのメリットはずばり開発効率です。

--------------------------------------------------
HCI:R1 : 0E 05 01 55 0C 00 00

hci_event_input: Command Complete
Num_HCI_Command_Packets: 0x1
OCF == 0x55 OGF == 0x3
HCI_EVENT_CMD_COMPLETE
successful HCI_RESET.
phybusif_output
HCI:CMD: 56 0C 01 00
HCI:R1 : 0E 04 01 56 0C 00

hci_event_input: Command Complete
Num_HCI_Command_Packets: 0x1
OCF == 0x56 OGF == 0x3
HCI_EVENT_CMD_COMPLETE
successful HCI_RESET.
phybusif_output
HCI:CMD: 05 10 00
HCI:R1 : 0E 0B 01 05 10 00 36 01 40 0A 00 08 00
----------------------------------------------------

上記はbluetoothドングルとの最初のやり取りの一部です。

lwbtには、かなり親切で豊富なデバッグ出力が付いているのですが、PIC24FJ64GB002ではほとんど使えないのです。PIC24FJ64GB002のフラッシュは64kしかなく、USBスタックとbluetoothスタックを入れるとほぼ満杯で、デバッグオプションをオンに出来ないのです。

その点、PIC32MX250F128Bだと、128Kものフラッシュがあるので、デバッグをオンにしてコンパイルしても、余裕で収まります。つまり、usb+bluetoothにさらに何らかのアプリを乗せても十分すぎる余裕があります。もちろん32kものramも付いてます。

値段ですが、通販ベースだと、
共立エレショップでPIC24FJ64GB002は680円+送料120円　合計800円
かなり送料は勉強してるんですが、いかんせんチップの値段は高いですよね。

一方、chiponestopだと今日現在
PIC32MX250F128B-I/SP がチューブで 429円+送料450円　合計879円
1個だけ買うのになんか凄く送料高い気がするんですが、チューブでも一個から買えてしかも秋月価格に近いので、実はPIC24F買うのと100円も違いません。2個以上買うなら、PIC32MXの方が安くなりそうです。
chiponestopは、ものによっては結構高いし、安いチューブ品だと1個では売ってくれなかったりと、なかなか使いづらいのですけど、ことこのPIC32MX250F128Bに関しては、おすすめです。

---------------------------------------------------------------
一応わかっているPIC32のデメリット

MPLABXのシミュレータが使えない

今朝思いっきりはまったのですが、PIC32でシミュレータ使おうとしたんですけど、ローカル変数のwatchが出来ないようです。maicrochipのフォーラムも見てみましたが、どちらかというと初心者の人が使えないよー、と言ってるのに、上級者の人が、使えないけど、なんか文句あるの？？
って感じでした。出たばかりのver1.4に変更してみましたが、ダメそうですね。

内蔵FRCがUSBには使えない

PIC24FJ64GB002は、FRC使ってUSB接続できるのですが、PIC32MX250F128BはFRCからUSBPLLへの内部配線が無いのですねー。と言うわけで、今のところ外部にクリスタルが必要です。手持ちに何かあればいいのですが、お持ちで無い方は、クリスタルが無いと、PIC単体ではUSBには接続出来ないのでご注意を。
これは秋月の220円PICでもそうなので、クリスタル不要にしようと作戦も考えてあったのですが、今のところ成功していません。

そのため、使えるPINがかなり減る。

クリスタルの分２ピン減るのと、ポートリマップの仕組みが変わって、かなり制限がきつくなっています。まあ、全ピン使うような大掛かりなのって、あんまり思いつかないし、ピンが足りなくなったら、継ぎ足せばいいような気が。

---------------------------------------------------

秋月の220円という価格に釣られて始めたPIC32でしたが、やはりアマチュアはコストも大事だけど、簡単便利、も大事ですね。プロで個数出るなら、価格差も効いてくるでしょうが、数個しか使わないなら、多少高くても開発しやすい方がいいんだ。と思うわけですが、やはり、220円のPICにbluetooth乗せたいよねー(^^)

秋月で取り扱いが始まったことで一気に身近になってきたPIC32．これまではフラットパッケージで、アマチュアにはとっつきにくかったけど、DIP品、しかもUSB付きで220円（送料別）のPIC32MX220は、何気にbluetooth用のPIC24FJ64GB002の代わりになるのでは、の予感だけど、残念ながらフラッシュが32+3Kなので、今のところbluetoothスタックが入りきらない。

じゃあ、プログラムを削るのだー、とやりかけていたのだけど、前回のブログのとおり、PICKITでPIC32を認識しない、という事件に巻き込まれてしまったのだ。

認識しないのは石が悪いのか、PICKITが悪いのか、判別不能なので、新しいPIC32を買って試したいけど、、、と思っているうち、ふと、chiponestopを見てみると、PIC32MX250F128の取り扱いが始まっている。しかも、10個以上だと338円！
chiponestopにしては、珍しく安い！なんせ、PIC24FJ64GB002より安い。
というわけで、買ってしまいましたPIC32MX250F128。しかも10個も。そんなに買ってどーすんのよモードですが、いいのです。

で、それが送られてきたのが昨日。まずは、認識するかですが、、、ダメでした。

PICKITの方は、新しく買ってきたPIC24FやPIC30を読み書きできています。特にpic24fの方は、3.3V系なので、PIC32MXと同じで、電気系にはまず異常は考えられない。となると、、何でダメなの？？？



で、結論だけ書いていくと。。。

PICKIT3には2つのモードがあって、ベータ版のGUI単独モードと、MPLABから使うモードがあって、PICKIT2時代と同じやり方でいい、GUI単独モードで使っていたのだけど、このモードではPICKIT3はPIC32MX250を認識しない、というのが正解みたい。

MICROCHIPのフォーラム見ても、あんまり認識しないって大騒ぎになってないので、他の人はいけてるんだし、と思って、ふとモードを切り替えてMPLABX＋PICKIT3の組み合わせを試したところ、PIC32MXをちゃんと認識して書き込みもおっけのよう。
　　
GUIモード　では、PIC24Fはおっけ、PIC32MXはダメ。　　　
MPLABモード　では、両方ともおっけ。

そうかー、以前PIC32MXを試したときは、MPLABXから書き込んでいたのかも。で、次にPIC24Fに戻ったとき、GUIモードのベータ版に気が付いてそれに変更。今度はそのまま、またPIC32MXに戻すと認識しない。そういうわけだった、、のかな。

さらに、調べていくと、PICKIT2の方は、MICROCHIP公式にはPIC32MXに対応していないのだけど、PIC32PROGというのがgoogle codeにあって、それを使うとなんとPICKIT2でもPIC32MX250を読み書きできます。さらにうれしいことに、そのとき同時にPICKIT2のGUIを立ち上げていてもおっけです。つまり、PICKIT2のGUIのPOWERとMCLRがクリックで切り替えできるという、ブレッドボード使いにはうれしい機能がそのまま使えるのです。

このPIC32PROGは、PICKIT3でも、たぶん使えるはずですが、ベータ版のGUIモードにする必要があり、MPLABXと同時にというわけには行かないので、まだ実験してません。

ちなみに、
MPLABXでPICKIT3を使うときは、電源供給をコンフィグで設定してやら無いと、PICKIT3から給電しないので、書き込めない。
PIC32PROG.EXEをブラウザでは（trunk内にバイナリとしてありるので見えるのですが）落とせなくて、subversionのクライアントからダウンロードした。
なんてはまりもちゃんと経験しました(^^;;;

int main() {
_TRISB5 = 0;

while(1) {
DelayMs(500);
_RB5 = 1;
DelayMs(500);
_RB5 = 0;

}
}

さくっと書いてLチカ。こいつ動くぞ！(^^)

さて、先週末に柴っちさんにHUDを送ってもらったものの、先週末では動かすことが出来ずに、今週もちまちまいろいろ実験を繰り返したのですが、結果から先にいうと、ようやく、とりあえず動かすことが出来ました。ほっ(^^)

で、いよいよ構想1年、オレの野望をお話しするときがやってまいりました。その野望とは、OBD無限増しょQ計画！（一応予告編にあわせてみました）

柴っちさんがいろいろ試されたように、OBDに差し込んでデータを取る機器は並列運用が出来ません。フリードの場合は、OBD端子にはCANバスがきているのですが、これのOBD端子からのデータのやり取りは、リクエスト-レスポンスの方式をとります。そして、CANバスの仕様から、OBD端子から2つのリクエストを同時に出した場合、運が悪いとその2つのリクエストが合成され、違うデータに化けて、エンジンチェックランプを点灯させることがあるわけです。

というわけで、HUDの場合は、スピードは？　とか、冷却水温度は？　とかをＣＡＮバスを通じてECUにリクエストして、そのレスポンスをもらって表示するわけですが、ECUの代わりに、PICが相手をしてやって、データを送ってやれば、ECUやOBDとは関係無しに、HUDを動かすことが出来るわけで、タイトル写真は、そうやっておうちの中でHUDを表示させることが出来た、ということです。

さて、そうなると、今度は、他のOBDに差し込む計器も動作原理は同じはずですから、これまたPICに相手をさせれば、それらもHUDとは同時に動かすことが出来るようになるのです。

じゃあ、それら計器系に流すためのデータをECUから取ってくるのは、どうするかというと、当初はそれもPICにやらせるつもりでしたが、現時点では、やはり自作機器をOBDに繋ぐのは、まだ実験不足です。万が一、柴っちさんの奥様が乗られている時、エンジンチェックランプが点灯したら、、、
いや、それはmarumonさんが作ってくれた計器用の機械で、壊れるはずないんだけど、、、
もう、一人だけでも十分なのに、おかしな人がまた増えたのね！（怒）もうみんカラ禁止！
なんてことにならないように、実績のある、ELMドングル＋torqueコンビにデータ取得は任せて、PICはその通信を傍受してデータを入手して、各種OBD機器にデータを配信する。という計画です。


リクエストはTORQUEが担当しますから、その他のOBD関係の計器類は、TORQUEを走らせないと、データがないので動きません。つまり、必ずTORQUEを走らせる必要があるということです。そういうデメリットはあるものの、PICはあくまで、ELMとECUの通信を傍受するだけで、送信しないので、基本的には悪さは出来ません。TORQUE-ELMドングルが正常に働けば、ECUへの悪影響はないはずです。

どうでしょう？ご理解いただけましたでしょうか？
そして、ご協力していただけますか？(^^)