動かし始める

やりかけだったカメラの配線をようやくとほぼ終了。まだスイッチの類いを付けていないのですが、後回しにすることにして順次動作確認を進めていくことにします。





まずは、LCDの動作を確認。基本的にはこれまでと同じパーツを同じようにつないでいるだけですが、今回はLCDのバックライトを落とすFETスイッチを付けておきました。続いてOV7670のレジスタが読めるところまで確認。画像の方はFIFOを操作するコードを書かないといけないので、次はこのステップです。

過去24時間

SCP1000による気圧/気温とS9705による照度データの24時間分グラフ表示が採れたので、晒しておきます。週間記録も採取中なので、こちらは来週が楽しみです。ソフトに若干のバグ修正を加えたものの、グラフ表示処理に関しては前回の記事から変わっていません。単に、データの数と内容が変わっただけですが、データの内容に応じて各軸のスケールと目盛りが変化していることが確認できます。




朝方、日の出とともに明るくなるのを追いかけるように気温が上昇し、8時前にピークとなっています。窓際にセンサーを置いてあるため、このような傾向を捉え易いのですが、それにしても温度上がり過ぎ。ケース内の温度が上昇するペースに、放熱が追いついていないのです。確認してみると、ACアダプタが結構な熱を持っています。アダプタをひっくり返して配置したために、アダプタがケースの底面を暖めてしまい、ちゃんと放熱できていません。通気用の穴を増やすとともに、アダプタの放熱を改善する必要ありです。

気温と気圧はline chartで描画していますが、照度はarea chartで対数軸をとって表示しています。深夜1:30にSSRの制御によりACアウトレットにつないであるランプの照明が切断されると、センサへ入る光がなくなります。その結果、照度が1ルクス(10⁰ルクス)を下回り、夜明けまでのあいだエリア表示の山が下向きになっています。

Chart APIからVisualization APIへ

２年前に気圧/温度記録を採った時には、Google Chart APIを使ってグラフ画像を生成していました。今回、SPIフラッシュへのログ記録機能を追加するのに伴い、週間や年間のグラフ描画もできるようにしようと考えChart APIの資料にアクセスしたところ、今ではGoogle Visualization APIが拡張されてグラフ描画に簡単に利用できるようになっており、Google Chart Toolsと言えばVisualization APIを指すようになっていることを知りました。旧Google Chartは、Google Image Chatと呼ばれて区別されているようです。

機能的にも優れものなので、この機会にVisualization APIを利用するように書き換えてみました。LPC2368で動作するWebサーバは、対応するページが参照されると、SPIフラッシュ上の気温/気圧データを読み出し、それをVisualization APIを使って表記するHTMLページを出力するわけです。

どんなに便利になったかを示すために、実際の出力例を示して対比してみることにしましょう。まず、Google Image Chartを使った旧出力例。画像しか残ってなくて、HTMLソースが手元に無いのが残念ですが。。

• Image ChartではグラフデータをURLの一部に埋め込んでやる必要があります。URLの文字列長が制限されることから、大量のデータをわたすことができません。文字列長を節約するために独自のエンコーディングを用いたりしています。
• データの要素数や値の範囲に合わせてX軸やY軸の値の範囲や、目盛り間隔を明示的に指定してやらないときれいなグラフになりません。文字数を節約するエンコーディングを使う場合には、スケーリング処理も自分でやらななくてはならなくなります。
• エンコーディング手法によって文字数節約すれば、どうしたって可読性は失われます。ふつうは人間が読むものではないわけですが、エンコーディングする処理は必要になります。

次は、Google Visualization APIを使った今回の出力画像例。本来であれば24時間分相当のグラフを表示するのですが、ログを採り始めたのが昨夜のため途中までのデータしか表示していません。



スッキリしたグラフが生成されていますが、ほとんどGoogleさんにおまかせで描いています。

• X軸に時刻をとって、Y軸の左側に気温、右側に気圧をとることはもちろん明示的に指定していますが、それぞれの目盛りの範囲や間隔は指定していません。実際のデータの内容に応じてVisualization APIがよろしくとり計らってくれています。素晴らしい!!
• 照度データは値のダイナミックレンジが広いので、対数スケールで表示しています。以前は自分でスケーリングをおこなっていたのですが、Visualization APIでは照度の軸は対数スケールでよろしく!と指定してやればいいだけ。素晴らしい!!
• Visualization APIではJavascriptが用いられており、イベントの処理も可能です。グラフ上のデータにマウスを移動するだけで、着目するデータの値を表示してくれますが、これもすべてGoogleさんのライブラリが処理してくれているので、使う側としては何の指定も必要無し。素晴らしい!!
• グラフのデータは、Javascript変数へ与える値としてスクリプトで渡せます。URLのように長さの制限を気にする必要も無く、可読可能な数値あるいは文字列データをそのまま渡すことができます。テキスト表現のデータの前と後ろにグラフ形式によって定まるスクリプトやHTMLのヘッダーを付け足してやるだけで、グラフが描けます。これならJavascriptの知識が無くても、コピペするだけの処理で済みます。素晴らしい!!

上の画像をクリックすると、実際のHTMLファイルを開くことができますので、マウス移動によるデータの読み取り動作を確認したり、ソースを参照することができます。

おおむね希望したグラフを描くことができてご満悦ではありますが、まだわからないことが一点残っています。照度の軸のタイトルと目盛りを気圧の横に並べて表示したいと思ったのですが、これがうまくいきません。気圧と重なって表示されてしまい、両者を並べて表示するにはどのように指定すればいいのかがわかりません。ご存知の方がいらっしゃいましたら、ご教示願います。

ATMEL Studio 6

先日、発表されたATMEL Studio 6をインストールしてみました。ATMELの場合、これまでAVR向けにはAVR Studioを提供していましたが、SAM向けにはIDEは提供していなかったので、わたしはCrossWorksを使用しています。しかし、今回は試しにATMEL Studio 6をインストールしてみることにしました。そのワケは、

1. 以前は、ATMELが提供するサンプルや、ライブラリを自由にダウンロードできたのが、いつの間にか登録が必要となり、追加やアップデートがある度にユーザ情報の入力を強制されるようになった。ATMEL Studio 6を使えば、同環境の中からサンプルやライブラリにアクセスして入手可能なので、手間が省ける。
2. AVR StudioだけでなくQTouch Studioの機能も統合された。
3. シュミレーターの機能も備わっている。

実際の開発にはCrossWorksを使うにしても これらの利点は見逃せないので、インストールして使ってみるべきだと判断。

さて、実際にフタを開けてみると。。

1. シュミレーター機能が用意されているのはAVRだけで、SAM用には用意されていない。orz
2. ボードテンプレートを使って新しいプロジェクトを作ろうとしたが、デバイスタイプとしてSAM3Sを選択できない。Unknown Deviceと記されているデバイスがいくつかあるので、そのどれかがSAM3Sに相当するらしいのだが。。C言語プロジェクトとして、ウィザードを開いてデバイスとしてSAM3Sを指定するとエラーで終了してしまう。
3. QTouchプロジェクトを作ろうとしても、デバイスとしてSAM3Sを選択できない。

というような調子で、ことごとく期待を裏切ってくれました。まだβ段階であるとはいえ、ARM関連のサポートが手薄になっているような印象を受けました。





正式リリースまでは使う気が失せましたが、サンプルとヘッダファイルだけは後で確認しておこうかな。

何重もの窓の中

MMlpc2368を使ったプロジェクトの機能を充実させようとしているところなのですが、その作業環境をまずなんとか改善したくなりました。もともと、このプロジェクトは２年近く前に作成したソフトがベースになっています。ところが、その開発環境を含んだノートPC (Let's Note)は、昨年突然LCDの不調をきたしてしまいました。不具合が生じたのはLCDだけなので外部ディスプレイを接続すれば使えるのですが、日頃コタツに入ってテレビ見ながらノートPCを使うという作業スタイルのわたしには、場所を移動するのも面倒なことです。

そこで、どうやって作業しているのかというと、、




MBA上のParallelsで、Windows 7を使っていますので、ここからリモート・デスクトップ接続で、別の部屋に置いたLet's NoteのWindows XPにつないでいます。Let'sではVMwareでUbuntuを走らせており、実際の開発環境はその中に入っています。既存の資源にリモートアクセスすることで、確かに楽はできるのですが、さすがにレスポンス遅れを感じることがあり使用感はいまいち。おまけに、時々リモート・デスクトップ接続がどういうわけか落ちて、自動再接続に数秒から20秒程度待たされるという事象が発生します。

接続落ちにはさすがに苛立ちを感じるので、Let's Noteの仮想マシン関連ファイルを一式、Windows 7にコピーしてきました。そして新たにWindows 7上に VMWare Playerをインストールしたのですが。。。




走ってくれません。時間かけてコピーしたのに。。Parallelsの中でVMWare走らせようというところに無理があるんでしょうかね？

三寒四温

MMlpc2368ボードを箱入れして、2, 3日連続運転。赤線が気温、緑は気圧。青は、明るさの変化です。雨が降って気圧が下がってくる様子がはっきりとわかります。室温も前日に比べて低くなっているのですが、箱の中はちょっと温度が高めになっているようです。通気用の穴の数、大きさともに増やしてやった方が良いようです。




SSRの動作確認もとれましたが、上記のグラフの機能は２年前から変更無し。RAM内に蓄えたデータからグラフを生成しているため、24時間分のデータしか表示できません。三寒四温の様子を見るためには、やはり1週間にわたっての変化の様子を見たいところです。MMlpc2368ボードには16Mbitだか32MbitだかのData Flashが搭載されているので、かなりの量のログを記録することが可能です。久しぶりにボードとソフトをいじったこの機会に、長期記録する機能だけでも追加しておこうかと思っています。今やっておかないと、もうこのボードをいじることは無いような予感がするので。

箱入れ

ダイソーで買った箱にLPC2368ボードを入れてみました。



電源には1年くらい前に秋月で特価品として売られていたスイッチング電源(Powerboy)を使用。適当な電源ケーブル/コネクタの持ちあわせが無かったので、ジャンパーケーブルを流用してつなぎましたが、電源の極性を間違えてカットしてしまったために、GNDが短すぎ。後ほど、コネクタを含めて修正する必要ありです。

電源のそばで裏返しになっているのは、SSR. 窓際において、暗くなったらスタンドの電灯のON、その後アラームで設定した時刻になったらOFFというのが我が家での利用パターンです。ACアウトレットが、ACコードの下側についており、配置が逆さまになっていますが、これはネコさまのいたずら防止対策です。ACプラグの根元をかじりたがる危険なヤツが在住しておりますので。下がACプラグの方が、いたずらしにくいでしょう。たぶん。

先週動作確認したWT32は、ひとまず取り外してあります。ソフトの修正が一段落ついたら、また搭載することにします。

不向き

ここしばらく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でのダウンロード速度向上は成らず。それでも、ケーブル無しでコンソール接続できるのはかなり気持ちいいです。