Xbeeワイヤレス電力ロガー親機のソース公開

　行楽の秋である。このところの休みは出かけることが多く、電子工作に余り時間がとれない。先週は、京都の山奥で高校の一泊旅行の同窓会があり、ひなびた茅葺きの田舎を堪能してきた。今年の紅葉は当たり年でなく、紅葉するまえに枯れる木が多かったようだが、それでも寒いところの色づきは平地より鮮やかなように見える。

　よせば良いのに、このあいだ作ったLPCMプレーヤーを持ち込んで、友人に自慢したら、注文者がまた何人かあらわれ、これで次のロットも完売した。納期は決めていないので気が楽である。

　それはとにかく電力ロガーがまだ完成していない。京都から帰ってきて旅装を解くのもそこそこに、残っている親機のソフト開発に熱中した。

擬似コーディングにこだわる(11/16/09)
　Xbeeの電力ロガーは半かけのセットながら、子機を分電盤に持ち込み長期の電力測定を始めている。実際に動かし始めると、必要な機能要件がいくつも出てくる（これが測定を早めに始めた理由でもある）。まず親機は、PCが動いていなくても電源を入れるだけでログを開始して欲しい。さらに、あとからPCとUARTでつないでも今までの計測は継続している必要がある。UARTでのコマンドをこなしながら、なおかつUARTには、現在の計測状況を乱れずに表示して欲しい。

　このためには、マルチタスクが動くような大幅な変更を加えなければならない。現在のソフトは、ChaNさんのFatFSのデモサンプルプログラムに急ごしらえのルーチンを追加して、無理やり動くようにしたコードなのでこのままではうまく動かない。

　マルチタスク構造にするには大変なので、割込みを使わず、フラグを使ったイベントドリブン構造にすることにした。割込みは、ChaNさんのUART下部関数が引き受ける。この前にこりて少しまともな擬似コーディングをする。APIフレームの受信は、今のところ10秒に一回なので、前のLPCMプレーヤーのように神経質になることはない。何度か書き換えた擬似コーディングのひとつを図にしてみた。

　擬似コーディングにこだわるのは、これがこれから少しまともなプログラムを書こうという人に役に立つのではないかと言う思いである。色々なブログを見ていると、結構プログラミングが苦手だと言う人が多い。組み込みコンピューターを使った電子工作の醍醐味は、ハードの工夫もさることながら、ソフトウエアを駆使して自分の欲しい機能を実現することなのだが、これが人のソースを使うだけでは折角の楽しみを半分しか味わっていないことになる。

　何故、みんなが苦手なのか大体想像がついている。いきなりソースコードを書き始めるからだ。昔々、この手の本を執筆したことがあり、これを詳しく話し出せば一冊の本になってしまうので、これ以上はしないが、"Hello World"の世界から、ちょっと実用的なプログラムを作るまでのレベルに到達するまでには越えなければならない山がいくつかある。大抵の人がそれを乗り越える前に挫折してしまうようだ。

　この山を乗り越えるコツの中で重要なひとつに、「ひとつづつロジックを確かめて完全に動くことが確認できるまでコーディングに入らないこと」がある。そのロジックを確かめる重要な道具がこの擬似コーディングである。昔から愛用している。これをさぼって難儀した話は、前々回あたりのこのブログの記事に詳しく出ている。

　ロジックをつめずにコーディングするとプログラムは何となく動くが大抵バグだらけで、まともに動かない。何とか動かそうとその場しのぎのステートメントを加えるが、これも大体うまくいかない。結局はデバッグに疲れ果てて投げ出すのがおちだ。

　擬似コーディングなら、何度でも紙の上でロジックを確かめられる。始めは極めて普通の日本語で、プログラムの動作を定義し（この図がそのあたりに近い）、納得したら、少しづつロジックを細かくしていく。最後は、実際の変数を使ってプログラムらしくする。ボールペンでなく、消しゴムで消せる鉛筆で書くのもコツのひとつだ。

　簡単なプログラムではその目的が理解できないかもしれないが、少し複雑になると効果がてきめんにあらわれる。是非みなさんも試していただければと思う。効能はバグの少ないプログラムが出来ることだ。自分の書いたプログラムが思ったとおりに動く喜びは何物にも替えがたい。開発が一段と楽しくなること請け合いだ。

　図の補足をしておこう。最初のブロックは、XbeeからのAPIフレームを受け取る部分である。ここは前の記事にも書いたように、1文字でもXbeeからのデータを受け取れば、フレームが終わるまで外にでず、フレームを読みきる。

　次は、処理するフレームがバッファーに入ったことをトリガーに、指定したスタイルで、データを表示するブロックである。この中で、ファイルに書き出す処理も含める。

　さらに次は、PCとのUART交信のブロックである。PCからのキー入力を監視し、入力された文字をバッファーに入れ、リターンキーによって、その処理を開始する。定期的にXbee子機からのデータを受け取らなければいけないので、リターンキーが来るまで、ここに留まることは出来ない。これが結構厄介である。結局、この擬似コーディングにあるように、コマンドを受け付けるプロンプトモードというモードを設定して、何とか形になった。

　これを設ける前は、ログメッセージの間に、コマンド入力や出力が散乱し、様にならない状態だった。このあたりの検討も擬似コーディングなら話が早い。

　最後は、短いがスリープに入るブロックである。sleepコマンドの位置は、よく考えて決めないと、おかしな動きをする原因になる。sleepはあらゆる割込みですべて解除されるからだ。

　プログラムは以上のブロックを、uart_test()などの関数でイベントが上がったかどうか、順番にチェックし、何もなければ一番下のsleepで止まる。XbeeやPCからのデータが来て割り込みが起きれば（割り込みは、両者とも下位の送受信ルーチンで起きる）、再び所定のイベントに応じて、ぐるぐる廻る。うむ、これで良さそうだ。

　こうして出来上がった擬似コーディングのブロックを少しづつ実際のステートメントにしていく。擬似コーディングは一覧性に富んでいるので、変数の定義やフラグの作り方にもとても参考になる。これがソースコードを相手に変数を作ると、どうしても行き当たりばったりになってしまい、無駄が出来たり考え落ちが出たりする。

　今度のソフトは、ブロック毎の機能は既に作ってあったプログラムと同じなので、そう細かい擬似コーディングまでは必要なかった。新設したフラグは、UART入力の途中を示すプロンプトフラグだけである。念入りに擬似コーディングをしたことで、すんなり親機は動き始めた。いちいちPCを立ち上げて端末プログラムを開き、親機にログ開始を指定しなくても、親機と子機の電源をいれるだけで、ただちにログを開始する。

　出来上がったソースコードは19Kバイト余り。残念ながら、フラッシュが小さくてMega168には移植できないが、Mega328なら余裕のサイズである。Mega128なら、このソースコードを一切変えずに動かすことが出来る。回路図は、ChaNさんのFatFSのデモプログラムと全く同じで、PE0とPE1のUART0をXbeeとの交信に使い、PD2とPD3のUART1をPCとのやりとりに使っているところが違うだけである。

Mega128はTQFPなので取り扱いが少し面倒だが、秋月では￥850で手に入るし、変換基板もサンハヤトでなければ、￥300近辺で手に入る。半田付けも0.8ミリピッチなのでそう難しくない。

ここにXbee電力ロガー親機のソースコードをAVRstudioのフォルダーにして公開します。Xbee子機のメンテナンス機能を含まない第一版ですが、参考になれば幸いです。

「Xbee128.zip」をダウンロード

深夜の意外な待機電力(11/20/09)
　親機のソフトは出来たが、ハードはXbeeがブレッドボードに刺さったままのバラックである。いくらなんでも、これでXbee電力ロガーの完成とは言いにくい。ケースはまだ考えていないが、ソースの公開にあわせて、CPU基板にXbeeを乗せる事にした。

　Xbee基板には、ブレッドボード用に下にピンが出ているので、これが干渉しないようにヘッダーピンを2重にしてCPU基板の上に2階建てにする。自作のRTC基板（ボタン電池が載っている）も、秋月のRTCモジュールがソケットに載って背が高くなっているのであまり目立たないが、これは、もうちょっと考えないとケースに入らなくなりそうだ。

　ハードもこれで独立したので、いよいよ自宅の全体の電力量の測定に入る。CTセンサーを各ブレーカーの配線から、主ブレーカーの中立点（我家はエアコンが200Vで赤、黒を使い、100Vが白、黒）の白に入れる。黒はエアコン電力も測定してしまうはずだ。

　現在の子機のCTセンサーの負荷抵抗は1KΩで、このままでは、10A以上流れるとADCの最大測定値3.3Vを越えてしまうが、とりあえず1KΩのままUARTをつなぎ様子をみる。小一時間動かしたが、電子レンジ、オーブントースターなどの大電力が同時に動かない限り、10Aを越すようなことはなさそうなので、就寝前、ロガーをつけっぱなしにして、このまま長期測定に入った。暗くなった部屋に、10秒ごとに、SDカードにデータを書き込む赤のLEDが瞬くのが頼もしい（syncさせてその都度書き込みしている）。

　次の朝起きた後、とるものもとりあえずPCルームに降りてロガーを確認する。良かった。ちゃんと赤のLEDが瞬いている。PCの電源を入れる。よし、ちゃんと記録をとっている。コマンドで、200Kバイトのファイルが出来ているのを確かめる。測定を継続し、昼過ぎ、測定を止めた。ほぼ20時間、断続的だが測定したことになる。

　エクセルでグラフにしてみた。予想もしないグラフがあらわれた。左側の0になっているところは、子機を止めて調整していたところなので（データは追記されている）、無視できるが、問題は、深夜の間歇的な大電流である。個別のデータまであたると、間隔にして30秒、20分間隔で400W近い電力が流れている。就寝中に動くのは冷蔵庫だけかと思ったら、これは何だ。思い当たったのが、ウオシュレットの便座のヒーターである。これだこれに違いない。節電モードになっているが、こんなに頻繁に動いているとは思わなかった。

　これを切るわけには行かない。深夜にトイレに入って冷たいのはいやなものだ。1時間に１分30 秒というと400×1.5/60 でちょうど10Wである。まあ、サーバーをつけっぱなしにすることを考えれば微々たるものだが。地球環境から言うとうーむ、どうなのか。

　明け方の大電力は、床暖房（ガスを使っている）と給湯装置の起動電力であろう。全体の待機電力が朝8 時前後が最も低く、深夜の方が少し多いというのが、まだ解せないが、これで我家の待機電力の状況はだいぶ明らかになった。これから各部のブレーカーで測っていけば、さらに詳しい状態がつかめる。うーむ、今度も実用的な電子工作になったぞ。