« 2009年10月 | トップページ | 2009年12月 »

2009年11月の3件の記事

2009年11月21日 (土)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 出来上がったソースコードは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モジュールがソケットに載って背が高くなっているのであまり目立たないが、これは、もうちょっと考えないとケースに入らなくなりそうだ。Ab212527

 ハードもこれで独立したので、いよいよ自宅の全体の電力量の測定に入る。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近い電力が流れている。就寝中に動くのは冷蔵庫だけかと思ったら、これは何だ。思い当たったのが、ウオシュレットの便座のヒーターである。これだこれに違いない。節電モードになっているが、こんなに頻繁に動いているとは思わなかった。Photo_3

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

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

| | コメント (0) | トラックバック (0)

2009年11月14日 (土)

Xbee電力ロガーで台所の電力消費を測る

Photo 珍しい学園祭を見る機会があって横須賀まで足を伸ばした。防衛大学校の開校祭である。学生の観閲行進の上空を先輩がパイロットをしているブルーインパルスが飛び、ヘリからパラシュートで空挺隊員が校庭に到着する。午後からは、救急車の待機する評判の棒倒し競技が行われ、学生たちがチームに分かれて豪快な肉弾戦を展開する。日頃、電子工作という趣味にはまって、自己完結型の予定調和の世界にいる者にとっては、想像もつかない強烈な刺激である。理屈ぬきに面白かった。Photo_2

LPCMプレーヤー2台目以降の制作(11/07/09)
 そんなこともあって、電子工作はちょっと一休みである。XbeeロガーもSDカードへのデータ書き込みが無事成功して少し気が抜けた。それでも細かい工作を少しづつやっている。LPCMプレーヤー2号機は予定の3台が無事完成して、それぞれの嫁入り先に旅立って行った。花嫁の父親の気分である。請われて行ったのだから喜ばなければならないのだが、やはり寂しさが残る。まだ受注残が3台ある。プリント基板をまた4台発注して1台は自分に残しておこうか。

 プリント基板の部品の半田付けは2時間で出来る。無機質の部品を集めて命あるものに換える喜びをこれだけでも十分味わえる。この世界の創造主は自分である。何度作っても興奮する。ただ、半田付けは楽で良いのだが、問題は電池基板の制作とバネの固定だ。接点バネが十分に電池接点に当たるよう入念に固定しないと、ケースを強く押さえたりしたとき接触不良を起こす。幸い今度の版は充電機能をつけたので、電池の着脱を殆どしないですむのだが、もう少し弾性の強い接点バネ(燐青銅線)が欲しいところだ。

 次の版のプリント基板を考えようと久しぶりにEAGLEを開いて整理しているうち、この前の公開直前に発生したEAGLEの不具合の原因がわかった。オペアンプが2台出現してどうしても消せなかったのだが、EAGLEの不具合ではなく、自分のオペミスであることがわかった。前のオペアンプを削除したとき、一緒に電源線を消去していなかったのでパッケージとして残っていたのである。EAGLEさんごめんなさい。

 前の電源線を消去し、新たに電源線を定義して、ボードファイルは完全になった。次の版はベタアースに挑戦してみようかと考えている。実は前の版でも、ブログでコメントを貰って少しやりかけたのだが、アナログとデジタルの分離がうまく行かず断念した。まあ、今のままでも特にノイズなどの不具合はなく、線が混み合っているのでベタアースの効果はあまりないかもしれない。

Xbeeは雑音に弱い(11/09/09)
 Xbeeの電力ロガーの方である。ログをとる親機はバラックのままで実装が何も進んでいないが、それでも、少しづつセンサーの子機を外に出して、家庭内の電気機器の測定を始めている。

 色々な場所に置いているうち、子機をワイヤレス電話機の充電機の横に置くと交信不能になることがわかった。ちょっと離せばOKになる。これはどうしたことだ。子機は送信するだけなのに雑音源の近くで交信不能になるのは解せない。APIフレーム受信の親機からのACKを子機が受け取れないのかも知れない。Xbeeは結構ノイズに気を遣う必要がありそうだ。

 TVの待機電力がどの程度か調べようと、シ○○プの液晶TVを測ってみた。動作時は150W程度、待機にしても何と50W以上消費している。時間が経てば下がるのかと10分以上そのままにしたが変わらない。それでは主電源を切ってみた。えー、変わらない。これは大変だ。コンセントから電源コードを抜いたら、「カチッ」というリレーの音とともに、電力は殆ど0になった。このTVはもう4年近く使っている。恐らく故障だと思うが、えらいものを発見してしまった。

 この現象は、SDカード書き込みが出来る前に発見し、とんでもない話だと思っていたが、SDカードに書き込ませた結果、待機モードになってから30分後、電力が0になることが判明した。後処理と冷却に時間をかけているらしい。それにしても人騒がせなTVだ。Ab132433

Xbee子機(センサー)のケース実装と冷蔵庫の測定(11/12/09)
 TVの消費電力を測っていた子機の仮のケースは、LPCMプレーヤー1号機に使ったこれまた秋月で¥100のプラスティックケースである。防滴仕様にするつもりなので、一応スイッチ、コネクタはすべてパネル固定にし、ケースは密閉する必要がある。ただ、Xbeeの電波が心配だ。このあいだケースに入れて電波が出ることを確かめているが、プラスティックといえども減衰はするはずだ。実際に場所を替えて調べてみた。全く変わらない。まあ、この周波数帯では殆ど無視できる量のようだ。

 久しぶりに秋葉原に出て、パネル付けの部品を調達する。CTセンサーのコネクタとコードは、DCアダプターのものを流用する。出力はmVオーダーだが少々ケーブルを延ばしても影響はなかった。ケースは、結局、このあいだのLPCMプレーヤー2号機で傷が付いてとりかえたケースを再利用することにした。既に上部に3つも穴が空いているので防滴にならないが、そのうち2つにスイッチとコネクターを付ける。もうひとつの穴は、LEDにするか、蓋をしてやるつもりだ。Ab132431

 出来上がったので、冷蔵庫の電力測定にとりかかる。四六時中動かしている電気機器の中の最大の大物であることが最初に選んだ理由である。最初、冷蔵庫単独で測ろうと思ったが、コンセントが奥にあって簡単に引き出すことが出来ない。仕方がないので、分電盤の台所のブレーカーで測ることにした。ケースが小さいのでセンサーは棚の隅に簡単に置くことが出来る。

Ab132432  ワイヤレスなので機器のセットアップに気を遣う必要がない。電源を入れるだけである。あとは10秒に一回データを親機に送り出す。子機の電源はリチウムバッテリーで1回の充電で連続300時間以上(10秒に1回、消費電流50mAで600ms稼動)、測定できるはずで、電源の入り切りも鷹揚になる。夜の10時ごろから次の日の午前11時ごろまで動かして、150Kバイトほどのファイルが無事にSDカードに出来た。これをPCに持ち込み、グラフにした結果は、図の通りである。

 ロガーで集めたデータをこのグラフにするのは至極簡単である。X軸を時分表示にするのにはもうちょっと手間がかかるが、項目数だけならExcelのファイル読み込みで、ファイル形式をテキストファイルにし、項目区切りを「スペース」にして取り込み、グラフにする列を選ぶだけである。この程度のグラフならあっというまに完成する。いや便利な時代になったものだ。Ws000000

 意外なことが、このグラフで判明した。まず2本の突出した短時間の高電力消費は、電子レンジ(夜が私の夜食、朝は娘の朝食)なのだが、分電盤には、電子レンジ専用のブレーカーがあるのに、そのコンセントを使っていないと言うことが始めてこれでわかった。 それに、室温20度近くでは、冷蔵庫は80%近く動きっぱなしになっていること、また、食洗機が夜11時頃動いているが、予想したほどの電力消費ではないこと(100W程度、300Wは使うと思っていた)、さらに、深夜に電力が0にならないのは、ガスオーブンの時刻表示で、これだけでも10W以上を消費していることなどである。

 いや、これは面白い。たった12時間の測定で色々なことがわかった。これは楽しみになってきた。親機を本格的に実装すれば、実用としてかなり使えそうである。

| | コメント (0) | トラックバック (0)

2009年11月 5日 (木)

Xbee電力ロガーデータのSDカード書き込み成功

 無線チップXbeeを使ったワイヤレス電力ロガーが、遂にデータをSDカードに書き込むところまで動くようになった。センサーは電流しか測っていないのでおおよその電力測定ではあるが(市販のエコワットレベル)、これで長期にわたる電気機器の電力消費を心置きなく調べることが出来る。

電力量の測定は、レーザープリンターの電源をネットを使って遠隔制御した(2008/4/9 「LAN電源制御成功」の記事)とき、プリンターの正味の電力が知りたくてCT(current transformer)電流センサーを買って以来の懸案で、Xbeeを通信販売の送料コストを下げるために買って、期せずしてプロジェクトにはずみがついた。

これまで、省電力化したセンサー部のXbee子機のハード開発と、親機のソフト開発を段階的に進め、ついに子機で収集した電力データを親機がSDカードに書き込んでログをとるところまで実現した。このあいだ(10/26記事)のステップにわけた手順では、5の「自動的にファイルに書き出す」に相当する。

親機はXbeeがまだブレッドボードに乗ったままだし、ソフトもぐちゃぐちゃでまだとても公開できるレベルではないが、とにかく電源を入れればファイルを自動的に作り、測定時刻(年月日時分秒)の記録と同時に電力量をSDカードにテキストデータで記録していく。

子機もこれから密閉ケースに実装しなればならないが、この9月から始めたXbee電力ロガープロジェクトはこれでひとつ大きな山場を越えた。以下はそのレポートである。

リチウム電池を使った子機の実装(10/30/09)Xbee
 昨日までに親機は、Xbee子機が送信したAPIフレームの内容をPCのUARTに表示するソフトがやっとのことで出来上がり、開発の先行きが見えてきた。一方、子機は、実用化に向けて最後の懸案が残っている。電源をどうするかである。現在は単3乾電池2つが電源で、このままでは基準電圧が不安定で正確な測定値を得ることが出来ない。

 正確さを言い出せばきりがないが、せめて3端子レギュレーターで定電圧化してやりたい。XbeeはVccが3.3Vなので、レギュレーターのために乾電池なら3つ以上必要だが、最近おなじみのリチウム電池ならひとつですむ(3.7V)。Olimexで作ったXbeeのピッチ変換基板の中にレギュレーターがつけられるか検討する。

 うーむ少し窮屈だが何とか入りそうだ。使っていないXbeeの2つあるピンの一方のパターンを切ってランドに流用したりして、最終的には小さな電源スイッチまでつけることが出来た。頻繁に電源を入り切りする機械ではないが、コネクターの抜き差しは、逆差しが怖いので、スイッチはあったほうが安心だ。

 リチウム電池は、LPCMプレーヤーのために、いくつか予備が買ってある。電池フォルダーも作り慣れてきた。このあいだ作った充電基板で使用したCDケースのコーナーを利用したフォルダーを作る。2つともなかなかうまくできた。

 問題はケースである。実は、リニアPCMプレーヤーのケースにこの2つはぴったり入るのだが(もともとがXbee基板はプレーヤー基板の1/2で、電池もプレーヤー用)、防滴仕様にするためのスイッチやコネクターをケースにつける余裕がない。このままでは、ケースに隙間が出来てしまう。特にコネクターは簡単に抜けないようソケットタイプにしたのでケースの上にはみ出す。どうもうまくいかない。とりあえずは名刺ケースに入れるだけで、ケースの実装は、もう少しじっくり検討することにする。

SDカードに作るログファイルの考え方(10/31/09)
 親機のソフト開発は、前の記事に書いたようにステップを細かく6つにわけて進めている。これまでにステップ2(APIフレームを表示する)まで実現した。APIフレームの中味が項目ごとに表示されて、XbeeのADCデータがぐっと身近になったような気がする。次のステップはいよいよ本格的なロガーとなる3(SDカードにデータを記録する)である。

 実際の開発の前に、ログファイルのレコードフォーマットをどうしておくか考える。昔のようにメモリや、記録装置が高価だった頃は、データをバイナリで持ち、タイムスタンプなども連続データの頭だけにしておくなど、記録容量を少なくする工夫をし、ソフトでそれを展開していたが、今はそんなことをする必要は全くない。PCのUARTに出すためにも、蓄積データはテキストデータ以外考えられない。

 今度のロガーのファイル設計もこの方針でいく。データとしては大きく重複するが、単位レコードにすべてキャラクターベースでタイムスタンプを重複して持ち、電力データを記録することにする。10秒に一回記録して1 日分とっても300Kバイト以下である。いまの記録メディアや、PCにとってはゴミのような量である。

 ファイルの管理は、年月日を自動的にファイル名にして、同じ日のログは、そのファイルに追記し、日ごとにファイルとして管理することにする。これならファイルを開けなくても中のデータが何かすぐわかる。セッションごとにファイルを作っていくと、あとの管理が大変だ。親機を複数動かす時は、ユニークな親機の番号をつければ良い。

 以上のような考え方でログファイルの仕様を次のように決めた。

ファイル名:処理系での混乱を避けるため頭にアルファベット1文字(W)をつけて、年月日2文字づつを連ねたファイル名とする。

  (例)    W091105.TXT  (2009年11月5日のデータ)

ファイル属性: テキストファイル レコード長32バイト(固定)
ファイルレコードフォーマット:

1111 09/11/05 22:25:08 0033    (セパレーターはブランク。末尾\r\a)
|              |             |       |-----------  電力データ(当面ADC値)
|              |             |----------------- 時:分:秒
|              | ------------------------- 年(西暦2桁)/月/日
|----------------------------------- センサー子機のアドレス(16進)

データ量見積もり:
  1レコード32バイト(SDカードのセクター512バイトに合わせる)
                            1時間に360レコード(10秒インタバルとして)11.25Kバイト
                            1日で270Kバイト。

RTCはすぐ出たがストリング関数がまた不調(11/3/09)
 仕様が決まったのでいよいよソフト実装である。SDカードの書き込みは例によってChaNさんのFatFSを活用させてもらうことにする。まずは、年月日などのRTCデータである。

 ChaNさんのFatFSには当然RTC(リアルタイマークロック)がついている。RTCチップとのインターフェースはI2Cだ。このI2CドライバーはこのあいだのミニLCDのライブラリに流用させてもらった。今の親機のプログラムは、このFatFSのデモプログラムがそっくり動くようになっているので、RTCを実装するのは単に数ステートメントを持ってくるだけである。

 UARTに時刻を表示する開発は5分もかからなかった。簡単に動いた。時刻の校正は、このデモプログラムのコードを利用すれば良い。ソフトウエア資産の有りがたさをかみしめる。こういうソフトはまさしく全員で共有するべき資産と言える。その意味でソフトウエアを著作権と同じ法律で縛る今のコンピューターの世界は不幸というより他はない。国民経済的に見れば、同じようなソフトを別々に独立して開発するのは人間の脳という資産を実に無駄に浪費していることになる。

 余談はさておき、前の記事の開発ステップ4は予想通り簡単に先に実現した。次はいよいよログデータの書き込みである。今度はファイル名をRTCから自動的に作らなければいけない。このFatFSでの書き込みは、LEDマトリックスの電光掲示板を作ったとき、フォントデータの変換ファイルを作るとき使った経験がある。そのときのソースを参考にコーディングして行く。

 このときはFatFSのストリング関数がどうしても動かず、原始関数のf_writeを使った覚えがある。こんどはどうするか迷ったが、時刻データなど変換するデータが多かったため、書式付のストリング関数fprintf(新版ではf_printf)を使ってみた。この関数を使えば、ファイルの書き込みが数ステップですむのが魅力だ。

 しかし、案の定と言うか、やっぱりここでもストリング関数はエラーを出して動かない。仕方がない。この前やったのと同じように、単純な書き込み関数f_writeで、バッファーにひとつひとつ書式変換したデータを移すコードに書き直す。結構手間がかかる。

ついにログデータの書き込みに成功(11/4/09)
 しかし、f_writeで書き換えたプログラムもうまく動いてくれなかった。無効なファイルオブジェクトだというエラーを吐き出して無常にも先に進まない。何度もソースを確かめる。前と全く同じような書き方をしているのに動かない。おかしい。無効なファイルオブジェクトということは、オープンして設定したオブジェクトアドレス(オープンは正常終了している)が誰かに汚されてしまっているのだろうか。確かにファイルをオープンしてから、実際にファイルを書き込むまでの間の処理が長い。

 試しに、オープンの直後、ファイルに何か書いてみる。おおー、書けた。やっぱり、どこかでデータを潰しているやつがいる。誰だ。誰だ。ソースをさらに注意深く追いかける。あ、見つけた。ループの最初のマウントコマンドだ。ソースがやっつけ仕事のため、ログ開始を設定するところと、ファイルに書き出すところは別ルーチンにし、メインループでまわしている。そのループの最初でファイルをマウントすれば、折角オープンしたファイルはすべてご破算になってファイルオブジェクトは初期化される。Xbeeconsole

 はっはっは、またお馬鹿なミスだ。マウントコマンドをメインループからはずし、めでたく子機からのデータはタイムスタンプとともにSDカードに記録された。同じ日の測定はデータが追記される仕様である。テストする。おやあ、データサイズが増えていないぞ。中味を見てみる。いけない。最初のデータをつぶして書き込んでいる。このFatFSは既存ファイルをオープンすれば追記するのではなかったのか。

 ウェブのマニュアルを調べる。あ、駄目だ。追記ではなくて最初から書き込む仕様になっている。おや、追記の方法が書いてある。f_lseekを使ってファイルポインターを最終にしておけば良いということだ。やってみる。よーし、データは見事に追記された。

 いやあ素晴らしい。出来上がったファイルをSDカードごとPCに移し、PCのエディターで開いてみる。うむ、全く問題ないテキストファイルが出来ている。ソースコードはデバッグを繰り返して、スパゲッティ状態になっておりこれから大幅な改修が必要だが、とにかくSDカードに測定データをログすることに成功した。Xbeelogdata

 残念ながら、ストリング関数は、この状態でも動かなかった。ChaNさんのコードだ。バグがあるとは考えられない。何かこちらのミスだろう。まあ、今の状態で動くのだから無理することはない。

 9月からはじめたXbeeワイヤレス電力ロガーも完成に近づいてきた。子機のケース実装が終わったら、気になる我が家の電子機器の待機電力量を片っ端から測ってみてやろう。

| | コメント (0) | トラックバック (0)

« 2009年10月 | トップページ | 2009年12月 »