marumonのブログ一覧

今日は、時間掛けてXC32の最適化の具合を試してみました。というのも、以前PIC32MX220F032Bにbluetooth乗せようといろいろやっていたとき、確かもう少しで32kに収まりそう。なんてやっていたのに、USB Host - Mass Storage - Thumb Drive Data Loggerがぜんぜんサイズでかいのはちょっとおかしいと思うのですね。

で、何でサイズでかくなるのかと言うと、XC32 v1.11だと Pro Compiler option (mips16 mode) ignored due to an invalid license　となぜかevaluation licenseでもmips16のオプションが効かないからですね。

と言うわけで、知り合いに頼んでv1.10を借りてコンパイルしてみると、やはりこちらのバージョンでは、mips16通ります。出来上がったサイズは、mips16 Os で32kをちょっと超える程度でした。さらに、FSconfig.hをいじって、file serach と dir と realtimestamp　をやめてみると、、、


見事32kに収まりました。一応uartも少し入っているので、ロガーとして何とか使えるように出来そうです。

さらに今度はmips16はなし、Osだけでコンパイルすると


やはり、32kの壁を越えてしまいました。そりゃそうでしょう。mips16は単純に32bit命令を16bitに置き換えるんですから、コードサイズは半分、、、とは行かなくても小さくなるはずです。それを使えないのは、やはりつらい。さらに、free licenseで許される　O1だと


実はこっちの最適化は、あんまり変わらないと言うか、もともと32k超えちゃってるんで、もうどうでもいいかも(^^;;;

と言うわけで結論、mips16の最適化コンパイルライセンスが、使えなくなった XC32 v1.11の環境では、PIC32MX220F032BをUSBホスト関係で使うのは、かなり無理がある、と思います。せっかくクリスタル無しで使えるようになったのに～。

あと、pinguinoで使ってる、mips-gccだと、mips16も使えるはずですが、なんせ敷居が高すぎて、素人には使いづらい。素直にPIC32MX250F128Bに退避しておいて、どなたかが素人でもmips-gccを使えるようにしてくれる日を待つのが吉かと。というか、mplabxで使えるようにして欲しいな～。

昨日に引き続いて、PIC32で今度は、USBメモリに挑戦。まず、クリスタルありで、サンプルのUSB Host - Mass Storage - Thumb Drive Data Loggerをビルドして書き込む。電源を入れて4GBのUSBメモリを差し込むと、あっさり成功。昨日からなんかうまく行きすぎ。ならと、今度は100均で買ってきた、SDカードリーダーで、SDカードの読み書きさせると、、、さすがにうんとも言わない。USBに供給してるのはpickitからの3.3Vなので、パソコンのUSBから取った5VをUSBカードリーダーに供給して再度挑戦してみると、これまた成功。どうしたんだ、オレ。

さらに、これまた100均のmicroSDカードリーダーと、確か千石で買った99円だったかのカードリーダも動く。クリスタルありなら、問題ない。

さて、ファーム的には問題ないので、懸案の内蔵FRCで動くかどうかだけど、配線変えてコンフィグを変えて、とやると、これまたあっさり動いた。ホストの方がUSBのタイミング的には、厳しいのかゆるいのかわからないけど、これで昨日のデバイス側と合わせて、PIC32のUSBは内蔵FRCで動かせる、と言っていいと思われ。

で、昨日はPIC32MX220B032Bが、デバイス側としてが動いたので、こっちも試そうとしたら、コンパイル後のコードサイズが大きすぎ（64K近くある）。そういえば、コンパイラの60日ライセンス切れで、最適化が効かなくなっているわけで、とmicrochipのサイトを覗くと新しいXC32があったのでそれを試す。が、あんまり小さくならない。しかも、新しいバージョンはmips16のオプションが、無料ではなく最初から有料になってるっぽい。

pinguinoのコンパイラならmips16やら最適化オプション使えるそうで、落としてみたけど、mplabxはツールチェーンとして認識しないので、コマンドラインでmakeしないといけないようで、使い方がいまいちわからん。

うー、ようやくはまってきたかも、と考えながら、そういえば、SDカードならSPIでも読めたっけと、MDD File Systemのマニュアル見たら、PIC32だと、SDの読み書きするだけでコードサイズが32k超えそう＝PIC32MX220B032Bでは無理。

まあ、今のところ、PIC32MX250B128Bが10個もあるから、無理せずこれで、USB使ってればいいか、と言うことで、本日のお勉強終わり。

220円と安いUSBホスト機能付きのPIC32MX220F032Bだけど、せっかく安いのにPIC24FJ64GB002と違って、内蔵FRCではUSBを動かせない残念な仕様。クリスタルつけてコンデンサを2つ、となると、120円かかる気がするので、せっかくの安さが台無しに。

で、何とかできないか、と作戦を練っていたら、ふと覗いたmicrochipのフォーラムに　no crystal usb なんて、まんまそのままのトピックが。なるほど、REFCLKOを使えばいいのか。オレはPBCLKをCLKOから出して、ECに入力して、、、と考えていたけど、おしかった(^^;; 。投稿主はわざわざFRCチューンのパラメータを変えて、クロックを遅くしたり早くしても、ちゃんと動くよ、なんてテスト済み。すばらしい。でも、コードは載ってないのよね。

と言うわけで、試してみようとしたけど、調べてみると、PIC32MX220F032Bでは、REFCLKOは独立したPINではなく、PPSの管轄。
となると、、、最初に何らかのクロックで立ち上げて、REFCLKOやPPSを設定して、それからクロックを切り替えて、走らせてやらないといけない。
というわけで、クロックの切り替えをまずテスト。CSECMDとCSDCMDの違いを始めてわかった。 FRCで立ち上げた後、そのクロックをREFCLKOに出して、ECPLLに切り替え。切り替え後もFRCは動き続けて、REFCLKOにクロックを出し続けてる模様。
次に、クリスタルを使って、CDCシリアルがちゃんと動くことを確認。
いよいよ、内蔵FRCに切り替えて、CDCシリアルが、、、動きました。結構さくっと動いた(^^)/

もちろん、同じようにPIC32MX250F128Bでもいけるはず。これで、USB工作捗るぞ～

ちなみに、コードはつぎのとおり
PPSOutput(3, RPA4, REFCLKO)としているので、RA4とCLKIを配線する必要あり。（あと電源とかレギュレータのコンデンサとかもね）

// DEVCFG2
#pragma config FPLLIDIV = DIV_1
#pragma config FPLLMUL = MUL_20
#pragma config UPLLIDIV = DIV_1
#pragma config UPLLEN = ON
#pragma config FPLLODIV = DIV_2

// DEVCFG1
#pragma config FNOSC = FRC
#pragma config FSOSCEN = OFF
#pragma config IESO = OFF
#pragma config POSCMOD = EC
#pragma config OSCIOFNC = ON
#pragma config FPBDIV = DIV_1
#pragma config FCKSM = CSECMD

int main(void)　{

mSysUnlockOpLock( {PPSOutput(3, RPA4, REFCLKO);});

　　OSCREFConfig(OSC_REFOCON_FRC,
　OSC_REFOCON_OE | OSC_REFOCON_ON, 1);

mSysUnlockOpLock(
{OSCCONbits.NOSC = 3; //ECPLL
OSCCONbits.OSWEN = 1;}
);

while(OSCCONbits.COSC != 3) ;　　//念のため入れてみた
SYSTEMConfigPerformance(40000000);

　　// これで、システム40MHz　USB48MHz できあがり
}

オレのGPS暦というか、年がばれそうだけど、使ってきたヨット用航海計器はロランCからだったりして、というか、1級取ったとき試験の船に積んであったのは、ロランAだったようなだし、あとSATNAVなんてのもあったりして、まあ、それだけ長いことこの手の計器を見て使ってきたけど、ヨットレースで使える、特にインショアのソーセージで使えるやつって、ひとつも無かった。と断言できる。（もちろんオフショアでは、十分役に立ちます）


どうして使えないか。

理由は簡単。最近のクルーザーレースは、上下レースだと、ほぼレース前に本部艇には、マークまでの距離方位を表示してくれる。たとえば、上マークが10度1.2Mだとして、その地点を目的地に設定すればいいだけなので、簡単そうに見えるが、これが出来ない。
なぜなら、現在地から何度何マイルという目的地の設定方法がないのだ。これが出来れば苦労は無いが、出来ない。仕方が無いから、プロッタにカーソルキーを出して、そのカーソルまでの距離方位はわかるから、そのカーソルを目的の距離方位の場所に設定する、と言う方法もあるが、基点となる現在地、つまり船の位置を下マークにとどめておかなければならない。現実的に、下マークで止まってもらうのは、ほぼ無理でしょ？
もちろん、下マークを目的地に設定しておいて、下マークまでの距離方位を出しておく、と言う使い方もあるけど、どちらかと言うと、実際のレースでは、下マークより上マークまでの距離方位が欲しいわけで、あまり実用的ではない。


BlueNavigatorなら、かんたん

スタート前コミッティが下マークを打ったら、まずそのポジションを取りに行く。船を出来るだけマークに近づけてもらって、ボタンをタップして、下マークの位置を記憶させる。あとは、本部艇に出ている距離方位を入力してやると、上マークの位置を計算して、上マークまでの距離方位を表示してくれる。
さらに、レース中、下マークが変更になった場合は、上マークを回った後、新しい距離方位を入力してやれば、これまた自動的に下マークまでの距離方位を計算してくれる。もちろん、上マークが変更になっても同様。


あと、2分ぐらいしかレグ無いよー

そして、圧倒的に便利と言うか、専用アプリならではなのが、レイラインまでの距離を計算して、そのレイラインまでの所要時間を現在の速度から計算してくれること。たとえば、スターボで伸ばしてるとき、反対は10分ぐらい、こっちのレグは後2分ぐらいしか残ってない、なんてことがわかる。
もちろん、現在のスタンドアロン版では、反対タックの角度を計算してくれないので、その時々の角度を入力してやらないといけないし、そもそも、その反対タックの角度は長年の経験といい加減さで入力するわけで、当たるも八卦、当たらぬも八卦ともいえるが、大雑把でもいいから、残り時間わかった方が便利と思う。


ハイクアウトしながら、ナビゲーション

使っている端末はIS04という、防水端末。もちろん手のひらサイズ。当然のことながら、チャートテーブルの前に座ったり、GPSを覗き込んだり、といった面倒なこと無しに、ハイクアウトしながら、「あと、2分ぐらいしかレグ無いよー」と、言ったり出来る。これ重要！
しかも、アクションでなんかするときは、ポケットに端末押し込んで、おっけ。

そういえば、コミッティが下マーク打って位置取りに行ったとき、SLEDとSWINGの大型艇が、相次いでマークに来て、それと思しき人がタブレット端末操作してたけど、たぶんマークの位置取りに来てるように見えた。向こうはアフターガードで専任だろうけど、中小型艇では、そうそう無職というわけにも行かないので、何かしらの仕事が割り当てられるけど、そういう場合は、ああいう大きなタブレットはかえって邪魔だと思うな。何でも大きけりゃ、ではなく、スマホは中小型艇のサイズにあった端末だと言える。それに、IS04なら中古で5000円もしないので、万が一液晶割ったり落としたりしても、ダメージ少ないし。


電池の持ちは良好

今回の3日間のレースは、毎日3レースが予定されていた。1レース1時間半として、4,5時間は電池が持ってもらわないといけないわけで、そのために用意したのは、端末2台（電池はそれぞれ1個）＋予備電池1個。つまり電池的には3個用意して、毎レース交換しても大丈夫なようにしてみた。（というかレース中はたぶん交換できるような時間が取れないと思う）

とりあえず今回は、ディスプレイが生きている間だけGPSを動かして、画面が無いときはGPSを止める、という省エネモードで運用してみた。この場合GPSは、ホットスタートとなるようで、電源ボタンを押してたいていは1秒ほどでポジションフィックス、たまに10秒ほどかかる、といった具合。常時画面を見続けているわけでもないのと、目の前にマークがあれば、必要ない（特に下マークへ向かっているときは）ので、意外と使っている時間は短いのかもしれない。そのため、朝満充電しておけば電池は一日の間交換しないで良かった。

どちらかというと、電池大食いのandroid端末は、こういう使い方にして、航跡等は別途長時間記録できるドングルなどを用意するのが良い模様。


KYC専用かな？？？

調子はなかなか良いとはいえ、現在の仕様では、下マークを基準に上マークの位置を予測するわけで、これは、専用のマークボートとスタッフがいるKYCだからこそ、できる業ともいえる。KYCでは、ホントどんぴしゃの位置にちゃんとマークがあるからこそ、こういうアプリが成り立つともいえる。これが他のところのレースだと、本当に「おおよそ」の距離方位になることもあると思うので、他所でも使えるかは、実は？？？なのだ。
まあ、オレの場合はほぼKYCでしかレースしないから、これで十分なんだけどね。

最後に画面とメニューを見てもらうと、どんな感じがわかるかな？

さて、電話機能が復活して一段落、やはり開発には普段使っている端末を使っていては良くない、と言うことで、予備機を使って開発することにした。最初からそうしていれば良かった。予備機は面倒なのでroot取ってないし、となるとgpsも普通に使えたわけだし。


精度試験

とりあえずスマホのgpsの精度はどうなんだろうか？実験してみることにする。まずわかっているのは、データのアップデートは１秒ごとということ。これは以前よりオートクルーズの表示端末としても対地速度を計測するためgpsを使っていたので知っていた。最近では5Hzとか10Hzとかのデータを取れるGPSモジュールもあるけど、ヨットの場合はそれほどスピードが速くないので、毎秒のアップデートで問題ない。
とりあえず、ログを取れるようにして、COG（対地移動方位）を表示するようにして自転車で走ってみると、やはり道をまっすぐ走っていてもCOGは結構ふらつく。また、SOG(対地速度)も一定スピードで走ってみても、ふらつくようだ。つまり、測位の精度があんまり良くない感じ。船に積んでいるGPSでも、COGやSOGは（船がどうしても揺れるので）まったく一定、と言うわけには行かないが、そのレベルとは明らかに違うふらつき方が見える。
一方ログを地図に投影してみると、まあまあ、道沿いに走っている。たまに左右に道を外れるとかはあるが、測位がきちんと出来ているときもかなり多い。


ヨットレースで必要な精度

と言うことで、ちゃんと誤差1,2メートルで測位できている時もあれば、10メートルから20メートルずれているときもある、と言うのがスマホのGPSと言うか持っているIS04のGPSの精度のようだ。もちろん端末によったり機種によって違うだろうが、とりあえず、持っている端末の精度はその位のようだ。
で、それがヨットレースではどうなるか、だけど、20メートルって約2,3艇身なわけで、主に遠くにあるマークがどの方向にあるか、を計算したいわけだから、それぐらいの誤差ならぜんぜん問題にならない。
もう少し精度が悪ければ、船のGPSのNMEA出力を拾ってbluetoothで飛ばす必要もあるかと思っていたけど、とりあえずはスマホ単体でおっけのようだし、いよいよ実装あるのみ。


レース中にアップデート

なんとかレース前日には、アプリがとりあえず動くようになってきたけどが、いかんせん実践不足、テスト不足、そもそも、マークへの距離方位を計算させているのが正しいのか、それすらよくわからない。レース前に船のGPSとで、マークを入力して、大体の位置があっている、と言う最低限のテストはしたけどが、後はレース中に修正していくしかない。
案の定初日は、下マークへの距離方位が正しく出ない、という根本的なバグが判明。とりあえず1上までは、距離方位が出るので、1上番長、とオーナーから命名されてしまいました。

それでも、ミニノートを船内に持ち込んで、レースの合間に修正したり、帰ってきてから修正したりで、3日目には最低限の機能だけとはいえ、ほぼ満足に動きだすようになりました。


続く