不向き

ここしばらくCMOSカメラは停滞中で、現在LPC2368に寄り道中。



２年ほど前に製作した、MMlpc2368を使ったボードです。しばらく使わないまま転がっていたのですが、コネクタを追加して実用に供することにしました。ボード上には照度センサがあるので、明るさで電灯の制御をおこなうことにして、下側のピンヘッダに外部電源ならびにSSRを接続します。以前はCdsで明るさをみて制御するものを使っていたのですが、経年劣化により調子が悪くなったので交換することにしました。空いていた右側部分にはWT32を搭載しました。

WT32を追加することで、Bluetooth経由での設定変更が可能となります。「設定」といってもどの程度暗くなったら点灯させるかとか、消灯の時刻の設定くらいしかありませんけど。SPPしか使わないので、WT32のような高級品を使わずとも安物で充分に間に合うのですが、なにしろ手元には大量のWCA-009の在庫が眠っていますので、これを使います。

WT32のシリアルはLPC2368のUSARTにつながっています。そのため、Bluetooth経由でのフラッシュ書き換えも可能となるだろうということで、試してみたのですが。。。。

結果としてできることはできるのですが、かなり遅い。直結した場合に比べて10倍近い時間がかかっているのではないでしょうか。無線化にともなう遅延とオーバヘッドにより、遅くなることは覚悟してはいましたが、もう少しなんとかならないものかと思い、調整できそうな項目がないかと調べてみました。幸いiWRAPではRFCOMMで使用するMTUサイズを設定できるようになっているので、これを試してみることにします。SET BT MTUコマンドでディフォルトのMTUサイズを設定しておき、接続時にはこれを使って相手とネゴを行うようです。LPC2368のISPでのダウロード時のデータレコードのサイズは60バイト程度のようですので、その近辺の数字が相性良さそうに思われますが、まずはMTU設定が有効に機能するかを調べてみるために、300で試してみました。



MTUを300に設定してある状態で、Mac OS XからSPPで接続し、その状態でlistコマンドを使って接続状態を確認してみたのですが、MTUは667になってしまっています。SET BT MTUの設定はあくまでもディフォルト値なので、実際にはMac側が667を使うことを要求して、この値を使うことになったのではないかと推測されます。

改めてLPC2368のISPの仕様を調べてみると、45バイト分のデータを受信する度毎に応答を返しているようです。ホスト側では頻繁に応答待ちが発生してしまうため、応答遅延の大きい無線環境では、これが積み重なることで転送速度が大きく低減してしまいます。一度にできるだけ多くのデータを送るとか、ウインドウ制御を持った転送プロトコルを使うとかしないと、速度向上は望めそうもありませんね。

このような経緯で、結局ISPでのダウンロード速度向上は成らず。それでも、ケーブル無しでコンソール接続できるのはかなり気持ちいいです。