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

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

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だ。

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

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

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

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

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

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

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

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子機が送信したAPIフレームの内容をPCのUARTに表示するソフトがやっとのことで出来上がり、開発の先行きが見えてきた。一方、子機は、実用化に向けて最後の懸案が残っている。電源をどうするかである。現在は単3乾電池2つが電源で、このままでは基準電圧が不安定で正確な測定値を得ることが出来ない。

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

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

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

　問題はケースである。実は、リニアPCMプレーヤーのケースにこの２つはぴったり入るのだが（もともとが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で書き換えたプログラムもうまく動いてくれなかった。無効なファイルオブジェクトだというエラーを吐き出して無常にも先に進まない。何度もソースを確かめる。前と全く同じような書き方をしているのに動かない。おかしい。無効なファイルオブジェクトということは、オープンして設定したオブジェクトアドレス（オープンは正常終了している）が誰かに汚されてしまっているのだろうか。確かにファイルをオープンしてから、実際にファイルを書き込むまでの間の処理が長い。

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

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

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

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

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

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

Xbee電力ロガー親機のAPIフレーム表示に苦労する

プログラムは考えたようには動かない(10/27/09)
　プログラムは考えたようには動かない、書いたようにしか動かないというのは言い古されたプログラミングの格言だが、まさしくこれを地で行くデバッグだった。Xbeeの親機の開発第2 ステップ、APIフレームの表示にえらい時間を食ってしまった。

　たいした開発量でないからと、簡単なメモを書くくらいでコーディングに入ると大抵うまくいかないものである。今度もそうだった。Xbeeから送られたAPIフレームを一旦バッファーに溜めて、画面に人間が見てすぐわかるAPIデータを表示するのが第二ステップの目的である。

　前の第一ステップのPCのUART画面に同時にデータを表示するより構造的には、はるかに簡単だ。フレームが送り終わるのを待って、フレームフォーマットに従って、送信モジュールアドレスや、受信サンプル数、データを表示していく。造作のない話である。

　ところがこれがうまく動かないのである。コーディングを楽にするため、バッファーを文字配列にし、添字を使ってフレームからデータを抜き出すのだが、書式付の出力関数が思ったような数値を出してくれない。16進でだしたり、2バイトの整数で出したり、ビット表示だったりするので結構やっかいなのだが、出力されるのが、これが全くでたらめの値である。

　おかしいな。ChaNさんの書式付出力関数xprintfはprintfのサブセットで軽いので愛用させてもらっている。慣れているはずなのにどうしてだろう。あんまりおかしいので、元に戻って、送られてきたフレームを16進表示してみた。

　うひゃあ、これが全く似ても似つかぬAPIフレームが出力された。何だこれは。リセットしたり電源を入り切りすると、時々元の見慣れたAPIフレームが表示される時がある。何だ、何だ。ハードは何もいじっていないぞ。しかし、またすぐにおかしなデータに戻る。元のデータがこれでは、xprintfの書式どころではない。X-CTUを取り出してXbeeを確かめる。いや、何も問題ない。いつものデータを間違いなくはきだしている。

　Mega128のVccを3.3Vに落とした副作用だろうか。いや、もうひとつのファイルモニター機能は何事もなく動く、ハードの問題ではない。新しくUARTを追加したMega128のPE0,PE1ピンに何か特殊な機能があるのだろうか。いやデータシートには何もない。するとソフトか。コードを確かめる。間違いなく、Xbeeからの受信バッファーが空になるのを待ち、データ処理に入っている。暴走もしていない。データが入っているところもある。

　途方に暮れて、その日の開発はあきらめ寝床についた。次の日は仕事のない日で、朝寝坊して、うつらうつら昨夜のトラブルを思い出していた。このあいだは2つのUARTを同時に動かしたためバッファーをいくら大きくしても取りこぼした。今度はどうだ。今度は間違いがないように、受信バッファーをwhileループで監視し、空になるのを確かめて次のステップに行くようになっている。その間は別のUARTは動かしていない。

　ちょっと待て。UARTが1文字を読む時間は、いくら早くても数百マイクロ秒のオーダーだ(38.4kbpsでバイト当たり208μs)。これに対してCPUの処理速度は8Mhzで1ステップ0.125マイクロ秒。千倍以上のスピード差だ。ループの中に別のUARTが入っていないということは、このwhileループはUARTの早さに較べれば猛烈な速さで回転する。

あああ、これだ、これだ。このwhileループは下部のUART関数がデータをバッファーに入れている間に、あっという間にバッファーを読みつくし、余裕で抜けてしまう。そのあとはデータが読み込まれたものとして、まだ殆ど何も入っていないデータ処理バッファーを書き出す。これだ。これが目茶目茶なデータになる原因だ。

　やれやれ、わかってしまえば至極当然のことなのだが、思い込みというのは恐ろしい。最初のトラブルだったバッファーオーバーフローが頭に残っていて、UARTのデータはバッファーに溜まって行くばかりと考え、バッファーにデータが入っていることを前提にロジックを組んでいた。今度はある意味でのバッファーアンダーランである。疑ったMega128
さん、Xbeeのみなさんごめんなさい。みんなこんなソフトを書いた自分が悪いのです。

このあとも泥沼(10/29/09)
　飛び起きて、朝食をとるのももどかしく開発を再開した。しかし、このあとも苦戦が続いたのである。考えてみたら、APIフォーマットでADCデータが10秒ごと（現在の設定）に送られてくるが、データの終わりを判定する条件がない。データが来た時、バッファーに溜まるまで、少し待ち時間を入れれば良いのだろうが、こういう対症療法的なロジックは一番避けたいロジックである（巷にはこういうソフトが蔓延しているが）。これまでの経験からろくなことにはならない。とりあえずは良くてもたいてい後で破綻する。是が非でもしっかりとした終了条件が欲しい。robustness（堅牢さ）というやつである。

　データフレームには、普通、そのフレームの長さのデータが入っているものである。このAPIフレームにも勿論ある。これを使えば良いのだが、データを読み始めてから終了条件をダイナミック（読んでいる間）に設定する処理が必要だ。これを安全に確実に暴走しないよう、しっかり作るのは結構神経を遣う。もし、不幸にしてデータサイズが入らなくてもハングしない構造にしなければならない。色々考える。プログラムは最初考えていたよりずっと複雑なものになりそうである。

　それにバイト配列のデータから2バイト長のデータを連続して取り出すコードがなかなかスマートに書けない。アセンブラー育ちで、ポインターとキャストを完全に使いこなせていない。試行錯誤である。

uint16_t    * ptr;         //   2バイト整数のポインター
uint8_t   Array[80];   //    1バイト配列(データバッファー)

と定義しておいて、Array[nn]のところにある2バイト長のデータをprintfなどで10進数で表示したいときは、配列のアドレス表現&を使って、

　ptr = (uint16_t *) &Array[nn];

としてキャストし2バイト整数のポインターに替え、

   printf( "%u", *ptr );

で良い筈なのだが、どうしても1バイトずれてしまう。しかもうまく行くところと行かないところが出て益々混乱する。安易にコーディングを始めたことを後悔する。よほど最初から書き直そうかと考えたが、しかしもう遅すぎる。何とかするしかない。どうしても入らないところは、ひとつづつ入れて8ビットシフトし強引に2バイト整数にする。

　少しづつ手を入れては結果を確かめ、正しく表示されるデータを増やしていく。しかしチェックサムが最後まで残った。送られてきたデータとなかなか一致しない。配列番号、アドレス、チェックサムしないデータ数、このあたりの計算はいわゆる並木算で昔からいつも悩まされてきた。紙に何度も図を描いてチェックサムの始めと終わりのアドレスを確認する。無精して++を式の中に入れたりしているので余計厄介だ。

　悪戦苦闘、数時間。データフレームにあるチェックサム値と、プログラムで計算した値がぴったり一致した時は、思わず端末の前で一人で拍手をしてしまった。思うように動かない時は、何を好んでこんなことをやっているのか、自分の不甲斐なさに情けなくなるばかりだが、出来たとなると、この充実感が何ともたまらない。実に安上がりな娯楽だ。それにしてもこんな小さなプログラミングでも、ちゃんとした計画を立て、準備を十分にしないと痛い目にあうということを今さらのように学んだ。自戒、自戒である。

Xbeeワイヤレス電力ロガー親機（データログ）の開発

　Xbeeを使ったワイヤレス電力ロガーの制作は、省電力設計を取り入れた（スリープ機能）子機の開発がとりあえず一段落し、次の親機の開発を考える段階に来た。子機の電源の定電圧化をどうするかの課題は残っているが、これはケースや電池フォルダーなどの外装とからむのであとで考えることにする。

Xbee子機の仕様をまとめておく(10/23/09)
　親機の開発の前に、これまでいくつかの記事に分散して書いたXbee子機の仕様を、これから同じようなことをしようと考えている人や、近頃とみに忘れやすくなった自分のために（冗談ではなくて、このブログのバックナンバーが頼りのときがある）、ここでまとめてみた。

　今回のXbee子機は、AC100VのCT電流センサー（U_RD社製 CTL-10-CLS 秋葉原 東邦無線で入手　￥1600）のAC入力電流（負荷抵抗で電圧に変換）を20ピンのADC0に入れ、所定の時間間隔で、親機にデータを送り出す。当面インテリジェントな機能は持たない。電源を入れれば果てしなくデータを送り続ける。時間間隔や、測定サンプル数などの変更は、XbeeモジュールをPC側のユーティリティX-CTUで設定し差し替える。

　CTセンサーの出力はACなのでオペアンプ(LM358)で全波整流し、LPF（ローパスフィルター）で平滑化している。オペアンプの電源は、Xbeeモジュールの持つ、SLEEP/ACTIVEピン（13）をトリガーにトランジスター2つのドライバーで制御し省電力仕様とする（待機時50μA）。

　ADCの基準電圧は、XbeeモジュールのVccとし、Vccは3端子レギュレーターで定電圧化する。CTセンサーの負荷抵抗は、ICソケットで変更が可能なようにしてある。

　スリープから目覚めた時、同時に整流回路にも電源が入る。平滑化のため最初の安定しないサンプルは捨て、一定になった時の値を採用する。

　上記の仕様のためにデフォルトから変更したXbeeのパラメーターは以下ですべてである。ただし時間間隔などはテストのために適当に決めたもので本番時のものではない。X-CTUのコンフィギュレーション画面ですべて設定できる。なお、Xbeeのファームウエアのバージョンは販売元のサイトで最新バージョンに上げておくこと（現在時点で10C8)。市販されているXbeeモジュール(OEM版と呼ばれる一番安価なもの）のファームウエアはかなり古い。

ATDH=0000          16 bitアドレスの時は0
ATDL=1111            送付先（親）アドレス　0～FFFFまで任意。適当に1111と設定
ATMY=2222          自分のアドレス　親はこれをATDLに設定する

ATSP =3E8　1000×10ms   10秒間隔でADCデータを送る
ATST=12C     300×1ms     0.3秒　測定が終わってから少し余裕を持ってスリープに入
　　　　　　　　　　　　　　　　　　　　　　る。（コマンドを受け入れるため）
ATD0=2　　　ADC0(20)ピンをADC（=2）にする
ATIR=14       20×1ms      20ms間隔でADデータを収集
ATIT=20　　　　　　　　32回測定してからまとめて送信

　この設定で子機は順調にデータを出し始めた。 親機側のXbeeの設定はアドレスだけで他はいじらない。親機はまだX-CTUのターミナルモードで16進表示である。CTセンサーの電圧が指数カーブを描いて定常状態になる様子がはっきり記録された。この回路では、前のオシロで見たとおり200～250msで安定するようである。

　調子に乗って、横にあったレーザープリンターの電流消費量も測ってみた。数値はいきなり4A以上（ADC値で500以上）を示すが、一分程度の初期動作を終えるとこのあとは瞬間的に5Aを超える（恐らくヒーターの間歇作動）ときを除いて、白熱電球（40W)のスタンドなみの0.03A(ADC値で40）に下がる。印刷時はもっと流れるだろうが、この測定は出来たときのお楽しみに残しておく。

　ついでに子機の消費電流を念のため測定する。動作時 は、55mA少々、これはLEDをつけているためで、オペアンプの消費電流は1mA以下のはずだ。さあ、スリープ時はどうだ、よし、1mA以下を指した。レンジを換えてマイクロアンペアモードにする。ピッタリ50μAを指した。うむ、スペックどおりだ。これで10秒に1秒程度の動作で、一週間の連続運転が1000mAHのバッテリーで可能になる。

ワイヤレス電力ロガーの親機の開発に着手する(10/24/09)
　そろそろデータをログする親機の開発にとりかかろう。これまでに数々作った基板を納めたガラスの引き出しから、久しぶりに以前の電光掲示板のコントローラーに使ったMega128のCPU基板を取り出した。 こいつはこれから実装しなければならないRTCもSDカードもついており、今度の実験にはうってつけだ。実際の親機はこれほどのスペックは要らないし、Mega168クラスで十分なはずだが、わざわざブレッドボードでハードを組む手間が省けるのが有難い。

　今度の開発は、逐次開発方式でやろうと思っている。AVRを紹介するウェブで検索すれば必ずヒットするkumanさん（AVR試用記）が愛用されている方式だ。少しづつ組んでは、部分的なテストをし、確認しながら大きなシステムにしていくやりかたである。大型システムの開発では極く当たり前の方法だが、こういう電子工作でも効果があるとは思わなかった。実際にやってみるとこれが具合が良いのである。手戻りが少ない。つい横着してすべてを組んでから頭を抱えるということがない。

　このサイトの主は、恐らく70 を超えておられる方だと思うが、失礼ながら年に似合わぬ電子工作へのあくなき探究心と好奇心に大変感動し、AVRを始めたころはとても参考にさせてもらった。何しろ説明が丁寧で初心者には心強い。初心者というのは、何が重要で何がそうでないか常に不安にかられているものである。そのあたりを丁寧に調べ、克服していく過程が、とても力づけられた記憶がある。このブログを始めた動機もこのサイトに刺激されたところが大きい。

　今度の電力ロガーの親機も次のようなステップで少しづつ組み上げていくことにする。

1. PCでXbeeの親機とお話し(UART)し、その結果をPC側にすべて伝える。

2. Xbeeの出力メッセージは、APIフレームというデータフォーマットなので、これを解析し、フレームの内容をわかりやすく、PC側に出力する。

3. 必要なデータをSDカードのファイルに貯めて行く機能を開発し、あわせてSDカードのファイルの内容を表示する機能を開発する。

4. RTCを組み込み、データに時分秒を追加する機能を付加する。

5. 子機が送ってくるデータを自動的にファイルに書き出し、複数のファイルを管理する機能を作る。

6. 子機の設定がリモートから行えるようにする。

当面は2.のところまでと、4.を作りこみ、3. 以降の仕様は、得られたデータをどう役に立てるかを考えながら作っていく。5. がとりあえずの完成形。6.は面白そうだが次期バージョンだろう。とりあえずはX-CTUでこれは出来る。

UART２つを動かすのは難しい(10/25/09)
　親機（データログ）をテストするハードウエアは、自作したMega128のCPU基板である。SDカードスロットと、USB-UART、RTCがついている。ChaNさんのFatFSのMMC/SDカードデモプログラムが動く。この基板は、SDカードの漢字フォントを読んでLEDマトリックスに7ドット日本語を表示する電光掲示板のCPU基板として使っていた。この電光掲示板は本人の知らないうちに以前、Make-JAPANで紹介され、ここのブログのアクセス急増に寄与したことがある。

　それはとにかく、Xbee電力ロガーの親機はXbeeとPCをつなぐためUARTが2つ必要だ。もちろんMega128は2つ持っている。ただ、このCPU基板は5VベースでSDカードのために3.3Vのレギュレーターを使い、レベルシフターのICでつないでいる。Xbeeは3.3VがVccなので、TTL-UARTでつなぐときまたレベルシフトが必要になってしまう。面倒なので、Mega128のVccも3.3Vにする。問題なく動いた。レベルシフターが余計だが別に困らない。

　次の作業は、Mega128のもうひとつのUARTのピン出しである。半田付け数本で済んだ。これでXbee電力ロガーのテスト用の親機のハードの準備は終わりである。あっけない。

　次はいよいよソフトである。ChaNさんのデモプログラムをベースにモニター部分を残しXbeeとの会話の部分を追加する。Xbee親モジュールから受け取ったデータを単にPCへのUARTに送るだけである。擬似コーディングを書くまでもない。

　ChaNさんのモニタープログラムのUARTは読んでみると全部割込みベースで書かれていることがわかった。これは助かった。２つのUARTを同時に動かすのは、フロー制御なしだと、リングバッファーなどを使わないとデータをとりこぼす可能性が高い。

　既にあるUART関係のコードをそっくりコピーし、別の名前をつけてもうひとつのUARTをでっちあげる。とりあえずは、前に決めた手順の1が目標である。キャラクターコードでは送られている内容が見えないので、16進で出力することにする。これもありあわせのコードで間に合う。コーディングは数時間もかからなかった。動かしてみる。

　おお、動いた。フレームのヘッダーコードの0X7Eで行換えしているので、X-CTUより読みやすい。おやあ、データが途中で切れているぞ。バッファーサイズが小さすぎるのか。少しづつ増やすが改善されない。結局、Xbeeが送ってくるデータ量だけのバッファーサイズがないと、とりこぼすことがわかった。うーむ、何かおかしい。これはもう少し解析しなければ。

　夜も遅いので、作業を切り上げ風呂に入っているときに突然気が付いた。バイナリデータ1バイトを受け取って、16進キャラクターで送り出す。送信データ量は3倍になる（キャラクター2バイトとブランク）。UARTの速度は同じだ。あああ、何と言うお馬鹿な設計だ。フロー制御しなければバッファーは無尽蔵あってもたらない。2 車線が1車線になった道路のようなもので渋滞は際限なく広がるだけだ。

　木を見て森を見ずということわざと同じである。一生懸命、リングバッファーの仕様や、回線速度と処理速度を計算していたりしていたけれど、最も基本的なデータの流量の違いを見落としていた。いやあ、UART2つの設計というのは軽く考えていたけれど、そんな簡単なものではなかった。何らかのフロー制御を入力側（Xbee)でしない限り、今のたかだか100バイト程度のデータでも簡単にとりこぼしてしまう。

　しかし、考えてみれば幸いなことに今度の仕様はデータ量や、時間間隔が決まっている。XbeeにはRTSピンがついているのでフロー制御が出来るし、ちょっとやってみたい気もするが、当面はバッファーを最大フレームサイズにしておけば、フロー制御はしないですむ。それに次のステップはAPIフレームの処理だ。これは一旦バッファーにデータを取り込んでおく必要がある。当面はバッファーサイズを広げて対処することにする。

とにかくこれでステップ1はとりあえずクリアした。次はステップ2のAPIフレームの表示だ。

Xbeeワイヤレス電力ロガー子機（センサー）の実装

　リニアPCMプレーヤー2号機のプロジェクトはソースの公開で一区切りがつき、作業の中心はブレッドボードでテストしていたXbeeの子機（センサー部）の実装に移った。そのかたわら、あと2台作らなければならないプレーヤーの工作も続けている。いや忙しい。

Olimexの変換基板に作りこむ(10/18/09)
　Xbeeを使ったワイヤレス電力ロガーの省電力化は、スリープの状態を示す出力ピンがあることがわかって開発が順調に進み、ブレッドボード上の実験で上手く動くことが確認できた。AC電流センサーのAC出力電流（負荷抵抗を入れて電圧化）を整流（オペアンプ１つによる全波整流）し、バッファーを経由してXbeeのADコンバーター入力に入れる部分と、この動作をスリープ中は止め、アクティブな時だけ動かすトランジスタ2つを使ったソリッドステートリレーの部分である。XbeeのADCのデータ送出フォーマットもこのあいだ調べ、実際のデータが送られていることを確認している。

　データの受信をして、SDカードなどに蓄積する親機については、まだ何も設計していない。しかし、ここはそれほど省電力を考える必要がない。これがワイヤレスの良いところだ。親機はPCの近くに置いておけるからである。それにここはソフト開発が主な作業で、SDカードの操作も、RTC（リアルタイマークロック）も、これまでにすべて経験済みで殆ど不安はない。

　Olimexの変換基板は、本来はテスト用の基板のつもりだったが、子機の実装は、この基板だけで出来そうな感じなので、久しぶりにアートワークをやってこれまでの回路が納まるか調べてみた。その結果、ぎりぎり（抵抗を縦位置）だが何とか入りそうである。この基板と電池フォルダーだけでセンサー部分の子機を実装することにした。

　久しぶりの手配線である。これはこれで工夫の余地があって楽しい。しかし、小規模なのでBottomViewのアートワークをさぼり、TopViewのアートワークしかやらなかったため配線が混み合ってくると混乱し始める。

　大した配線量ではないので半田付けは数時間で終了したが、案の定、誤配線が続出した。写真を裏側から見ると全く違う景色になってしまうように、人間の頭脳は左右逆転に弱い。修正の手間を考えれば、不精せずにBottmViewのアートワークも作るべきだったと反省する。

　何とか出来上がったので、整流回路からテスト。動かない。やっぱりまだ間違いがあった。それを直してオシロで出力をチェックする。やっと出力に所定の電圧がでた。これでよしと念のため各部のピンの出力を確かめる。おやあ、整流直後の脈流が出ていないぞ。何だ、何だこれは。非常に短い、鋭いパルスが出ている。うーむ、一体これは何だ。発振か。ちゃんと直流電圧が出ているのにおかしい。

　ひとつづつ調べていくしかない。何となく閃いたので、脈流を平滑化しているコンデンサー(10μF )を試しにはずしてみる。おお、やっぱりこれだ。出力波形は元のお馴染みの全波の脈流に戻った。そうなのか、平滑用の大きなコンデンサーが入るためにオペアンプの出力ピンでは鋭いパルスになるのだ。これまでこの回路のオペアンプ出力をオシロで見たことがない。これで良いのだ。いやアナログは難しいものだ（このあと抵抗をはさみLPFにして大分ゆるいパルスになった）。

　このあいだウェブ探索で、こういうランダムな脈流をDCにするICがあることを発見したが（RMS-DC化IC LTC1966）、まあ、ここまでやることはあるまい。どうせ電流しか測っていない。

　ダーリントン接続したトランジスタ２つのソリッドステートリレーは幸い一発で動いた。LEDをテスト用につけて、いよいよ全体のテストに入る。これまでスリープを設定していた親機側のXbeeを子機に移し変え、元の子機のXbeeを親側にする。

　うむ、動いた。子機は5秒毎（テスト用の設定）にLEDが点き、親機にADデータを送り始めた。おやあ、数値が出ないぞ。時たま、所定の70程度（200mV)でるときもあるが、殆ど0だ。そうか、サンプリング開始が早すぎて、オペアンプが正常動作をする前にサンプリングしてしまうのだろう。オシロのスイープを遅くして立ち上がりを調べてみた。少なくとも200msecは待たないと定常状態にならないようだ。平滑回路の時定数を調整し、ピークが出ない2KΩと10μFに決める（これはもういちどブレッドボードに同じ回路を作り直して調整した）。この遅れは、Xbeeのコマンドで対応できるはずだ。

　子機のハードはだいたいこれで出来上がった。あとはケースの制作である。出来るなら防滴仕様にしたい。配電盤は洗濯室にある。電流センサーのケーブル接続もこれまでのピンヘッダーでなく、ちゃんとしたソケットにしてHeavy Dutyに備えてある。

　それに今は単3のバッテリーだが、ADCの基準電圧を一定にするため、リチウムバッテリーに替えて電圧を定電圧化する必要がある。いくらなんでも基準電圧が電池の電圧低下で下がっていくような測定では実用に耐えられない。

2号機の量産（と言っても2台だが）と接点基板（10/21/09)
　Xbee子機の作業をしながら、2号機の2台目以降の工作も少しづつ進めている。接着剤を使う作業なので、日数がかかる。部品を確認したらDACなどの周辺ICは既に台数分買ってあったが、メインのマイコン(Mega328P)のストックが切れていた。

　先週末、秋月に行って、噂の￥250のMega328Pを仕入れてきた。ステレオフォンジャックが足らなくなったので、買おうとしたら、店員が「こんなのもありますよ」と新しいフォンジャックを出してきた。おう、これは小さい。BeagleBoardについているフォンジャックに似ているがもっと小ぶりで、今使っているものの半分くらい小ささだ。次のロットはこれにしよう。

　部品はともかく、今度の2号機の工作の中で一番面倒な部分は、実はケースの中間に配置したリチウムバッテリーの接点基板である。部品はストロベリーリナックス、秋月、千石、鈴商と通販の利く定番ショップですべて揃うし、EAGLEのボードファイルを公開しているので、基板も同じものを作れるが、この接点基板だけは自作するしかない。接着剤でアクリルケースに固定する必要があるし、0.5ミリの燐青銅線（東急ハンズで入手。大手のDIY店にはあるだろう）で接点を作るのはちょっとした慣れが必要である。

　同じものをつくってみようと考えている人の参考になるかと思い、接点基板の寸法図を掲載しておく。図は正確な縮尺になっていないので気をつけていただきたい。少し大きめに作り、あとはやすりなどで現物に合わせて調整するのが間違いない。燐青銅線の接点は写真を参考に。この形がベストかわからないが、一応これまで5ヶ以上の接点を作ってきた中で一番具合の良かった形である。

接点基板の制作のコツをいくつかあげておこう。みなこれまでの苦労で得たノウハウでもある。

・接点基板は、燐青銅線の接点の自由な固定（半田付け）のため、両面汎用基板から切り出すことをおすすめする。何もないアクリル板などは接点の固定に苦労する。結構強い力がバネの固定部分にかかりネジなどで止めてもわずかづつ動いてバネが利かない。片面基板は止めた方が良 い。少し強く抑えると半田付けしたパッドが簡単に基板からはがれて失敗する。

・接着はエポキシ系の強力なもので一日以上おいて接着を完全にすること。接着面積が少ないので、瞬間接着剤（シアノクレート系）では強度不足になる。

・任天堂DS-Liteの電池の接点部形状は良く見ると、電池両側の位置固定の凸部以外に、プラスマイナスの接点の間に、微妙な形状をした仕切りの突起がある。これに合うよう忠実に基板に穴を開けると基板の強度が持たない。この突起はあらかじめナイフ等で半分くらい削っておき、それにあわせて穴をあける。

・燐青銅線の接点バネ作りのコツは、バネになる部分は出切る限り曲げないで作ることである。少しでも曲げて形を調整すると簡単に弾性を失ってバネにならなくなる。その意味で半田付けで位置が自由に調整できる両面基板から作るのがベストだと思う。

・現在のプリント基板では、接点基板の位置と、ミニLCDの10ピンのピンジャックとがちょうど重なる位置にある。あらかじめピンジャックの端子をニッパーで切り、裏面に出ない状況で半田付けしないと干渉する。

・任天堂DS-Liteの互換バッテリーは、ネット通販で容易に手に入れることが出来るが、製品によって形が微妙に異なり注意が必要である。位置決め用の凸部がなかったり、仕切りの突起の形が違ったりする。同じ製品でも個体差があるので現物合わせが必須である。

・電池に丈夫なテープ・リボンなどをつけておき、はずすときの方策を考えておくこと。今の形は一旦装てんしてしまうと、容易にはずせなくなる。リチウムイオン電池の外装を傷つけることは厳禁で、はずすときにドライバーなどを使うと傷つきやすい。とりはずすのに大苦労すること間違いない。

リニアPCMプレーヤー2号機のあとかたづけとソース公開

フューズビットを甘く見てはいけない(10/12/09)
　伊豆高原にある知人の別荘に誘われて2日間ほど留守をした。家に帰って自分が明らかな電子工作依存症になっていることを実感する。工作ルームに座り、目の前の細々とした電子部品や工具を手にすると、これまでの何となくもの足らない気分が解消されて不思議に落ち着いてしまう。困ったものである。

　それはさておき、久しぶりにウェブを覗いたら、驚いた。秋月電子が今プレーヤーに使っているAVRチップMega328Pを何と￥250 で売り出したという。今までの半額である。 Mega168はこのあいだまで￥400以上していたが、これにつられて￥230である。今人気のArduinoという開発ボードでAVRが売れ出したからだろう。この価格では他のショップも大変だ。

　我が家の部品箱を見たらMega328Pはストックが切れそうだ。これは早速買ってこなければなるまい。伊豆で、出来上がったばかりのプレーヤー2号機を自慢したら、また追加注文があって嬉しい悲鳴である。

　Olimexのプリント基板は、あと2枚で行き先が決まっている。こりゃあプリント基板も追加発注しなければならないか。まあ、それはともかく、この2号機はソースコードをまだ公開していない。パラレルのLCDをI2Cを使ったミニLCDにしただけだが、ミニLCDが持っているアイコンは全く使っていない。

　余り使えそうなアイコンがなかったこともあるが、少なくともポーズの時と演奏中の区別がつかないのは不便している。何かアイコンを表示するようにしてからソースを公開しようと考えていた。

　ストックの最後のまっさらのMega328Pをブレッドボードに入れて、フューズビットの設定から準備を始める。マニュアルに書き込んである所定のフューズビットをAVRspで定義する。フューズビットは、いつもChaNさんのAVRspをDOS窓で動かし設定している。原始的だけれど簡便で使いやすい。手馴れた作業である。(FL=11100111 FH=11110111)

　事もなく設定は終わった。続いてこれまでのファームを書き込み、動作確認する。おやあ、LCDのオープニングメッセージが出ない。このブレッドボードはXbeeなどのテストベンチと共用しているので、色々手が入っている。どこかがはずれたのかと、ジャンパーの接触を確かめるが、問題ない。AVRstudioのコンパイルメッセージもNO ERRORだ。ファームの書き込みも問題ない。

　やれやれ。少し日を空けるとこれだ。何が原因か勘が働かなくなる。しようがない、UARTを入れて中を見るのが一番早い。コメントアウトしたUARTのコードを復活させてコンパイルする。端末をつなぐ。あれれ、ここも動いていない。これはもっと基本的なところだ。オシロでミニLCDとのI2C接続を見ると47Hzのパルスが出ている。何だあ、これは？

　結局、原因はフューズビットだった。ハイビットのWDTON（ウォッチドッグタイマー：通常動作=1、常時動作=0）を0にしていた。ハイビットはこれまでいじる機会が少なく、今度はEEPROMを残しておくモードにするため設定したのだが、ひとつずれていたというお粗末である。WDTONを0にするとプログラムで何もしなければ、数msごとにリセットがかかる。これがI2Cでパルスが出た原因である。フューズビットをなめてはいけない。

ミニLCDのアイコンを動かすソースコードを公開(10/16/09)
　ソースコードの改修に入る。アイコンを表示するコードを本体に入れる。ついでに、てんこ盛りに入っていたデバッグ用のステートメントを整理する。コメントアウトされたデバッグ用のステートメントは不要なようで、意外に役立つもの（特に他人のソースを見るとき）だが、ちょっと多すぎる。

　適当なアイコンがなく迷ったが、演奏中断（ポーズ）は鍵マーク、連続演奏は上下矢印（連続するので）を選んでみた。この機能の追加は10ステップ以下ですんだので、一発で動いた。うむ、これまで演奏中断がわかりにくかったが、これで使いやすくなった。

　次は、EAGLEの修正である。このあいだステレオフォンジャックのフットプリントをノギスで慎重に測って正確にした（部品ライブラリは前回の記事のlbrファイルに追加して更新）。誤配線も直した。回路図は、EAGLEを使っていない人にもわかるようにPDFファイルにし画面キャプチャーでJPEGにした。

　ところが、意外なところで作業が頓挫する。回路図のオペアンプの名前が適当なディバイスを選んだので所定の型番になっていない。これを直そうと色々やったところ、基板ファイルと回路図ファイルの不整合が起きて、元へ戻らなくなった。幻のオペアンプがボードファイルに生じ、基板に２つもオペアンプが出来てしまったのである。

　基板エディターで削除しようとすると、回路図エディターで消せと怒られる。回路図エディターには、そもそも、そのオペアンプは削除されて図上にない。困った。部品名を替えるために、前のオペアンプを削除し、新しいディバイスとして別のディバイスをADDしたのだが（これが正しく入ったことは、新しいディバイスがratsnestで出現している）、前のディバイスのパッケージが残ってしまっている。

　配線が残っているからかと思ってオペアンプ周りの結線をripupしていっても駄目。ripupを続けたら、電源周りの関係ないところまでなくなってしまい青くなる。これは困った。公開しようとした基板（ボード）ファイルが目茶目茶になってしまった。

　EAGLEを調べている余裕はない。仕方がないので、型番が違うオペアンプになっているが、正しい（誤配線を修正、フォンジャック修正）、EAGLEのボードファイルと回路図ファイル、それにAVRstudioのソース一式をzipファイルとし、画面にはオペアンプを正しい型番にした回路図を掲示することとした。

　ついでに、SDカードリニアPCMプレーヤー2号機の仕様を以下にまとめてみた。
1号機に較べると小型化され、充電機能と演奏中断、連続演奏のアイコン表示が追加されている。

外形：　77×51×22ミリ（秋月 アクリルケース蝶番式[小] 117-TSS)

入力：　SDカード（SDHCサポート）のルートディレクトリ上のWAVファイル

再生可能ファイル：16/22.05/44.1khz モノーラル/ステレオ　リニアー8/16ビット

最大ファイル数：　255（カウンターを2バイトにすれば65535）

出力：　ヘッドフォンステレオミニジャック、ボリュームによる音量調整

操作：　スライド電源スイッチ、タクトスイッチ3ヶ（ファイルの前後選択と決定）

表示：　16字×2行　LCD(ストロベリーリナックス販売のミニLCDアイコン付き）

電源：　3.7Vリチウムバッテリー（任天堂DS-Lite 互換バッテリー）

充電：　USBミニBコネクターより、USBケーブルより充電（5Vなら何でもOK)
　　　　充電中はLEDが点灯し、満充電で消灯。充電中も使用可。

機能：

・通常演奏
ディレクトリの最初から、タクトスイッチでファイル名を前後スクロールさせて表示し、決定ボタンにより演奏開始。SDカード10個までの選択ファイルの位置を記憶し、カードを替えても常にその位置から表示（ファイルを書き換えると最初に戻る）。

・連続演奏
タクトスイッチの前後ボタンの同時押しにより、選択時のWAVファイルから連続再生し、ディレクトリの最後まで行くと最初に戻って演奏を続ける。中止は、再生中の決定ボタン長押し（1秒以上）。連続演奏時は「上下矢印」のアイコンが表示される。

・演奏中断
再生中に決定ボタン押下。再開は同じボタン押下。中断中は「錠前」のアイコン表示

・演奏中止
再生中に決定ボタン長押し(0.5秒以上）。ファイル表示は次のファイルに行く。

ここに、ソースコードの入ったAVRstudioのフォルダーmLPCM328V3と、EAGLEの基板図ファイル(.brd)、回路図ファイル(.sch)をひとまとめにしたzipファイルを置きます。いつものように、メインのファイル名は変わっていませんので注意してください。フォルダーの中には、デバッグ用のUART関係のファイルも入っています。コメントをはずして所定のソースファイル、ヘッダーファイルをAVRstudioにとりこめば、UARTの使用が可能になります。

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

リニアーPCMプレーヤー2号機ついに完成

プリント基板なのに動かない(10/7/09)
　Xbee子機のブレッドボードでのテストが一段落したので、本来のOlimexに発注したプリント基板、リニアーPCMプレーヤーの実装を始めた。主要な部品が納まるかどうかは既に確認してあるので、あとはパーツをハンダ付けするだけである。

　ハンダ付けだけなので、進行が早い。定石どおり、チップコンデンサー、DACチップなどの表面実装部品をまず最初にハンダ付けする。これがすめば、あとはDIP部品ばかりなので順番に余り気を使う必要がなくなる。これは楽だ。手配線の手間に較べたら雲泥の差だ。まるでプラモデルのように、どんどん捗る。

　リチウム充電の部分が先に組みあがったので、バッテリーをつけて最初の通電テスト。おお、LEDが点いて充電が始まった。いいぞ。誤配線はないようだ（当たり前か）。残りのハンダ付けを急ぐ。

　おやあ、レギュレーターにつける100μFの電解コンデンサーの背が高すぎるのではないか。オーディオ用の100μFより高い。ケースの余裕は、このオーディオ用がぎりぎりのはずだ。やっぱりそうだ。これではケースに当たってしまう。いやあ困った。スペックによれば、33μFくらいでも良さそうなのだが、手頃な背の低いやつが手持ちにない。残念、一気に組み上げようと思ったが、部品不足で止まってしまった。

　次の日の仕事の帰り、秋葉によって部品を調達し、台風の去った8日、残りの実装を一気に進めた。ケースの工作はまだ終わっていないが、基板部はすべて完成した。手に持って完成の余韻を楽しむ。1号機の半分近い大きさだ。手の中に入る。

　それにしてもよくここまで来たものだ。3ヶ月前、EAGLEを始めた頃は本当にこれでプリント基板が出来るのか、余りの道の遠さに途方に暮れたときもあったが、今、そのプリント基板の完成品はここに存在し、電源が入れられるのを待っている。満足感で暫く感慨にふける。

　さて、いよいよ通電テストである。いつもの緊張の一瞬である。果たして動くのかどうか。手配線に較べれば動く確率は遥かに高いが、それでも動くまでは安心できない。祈る気持ちで電源ON。おお、LCDにおなじみのスタート画面が出た。良いぞ。SDカードを入れて演奏ボタンを押す。

　おやあ、音がしない。ボリュムを上げても何の変化もない。LCDは動いているのでCPUは問題なく動いているようだ。それで音が出ないのはアナログか。しかし、プリント基板である。誤配線は考えられない。ハンダブリッジなど実装の時の失敗の公算が強い。

　ブリッジしていそうなところを隈なくルーペで探す。特に何もない。フラックス残滓が残って怪しいところをクリーナーできれいにしたりするが何の効果もなし。さきほどまでの元気はどこへやら、いきなり奈落の底に落ちた気分である。やれやれ。何が悪いんだろう。大げさな言い方になるが、人生が暗い（典型的な躁鬱質である）。

やっぱり間違えていた(10/8/09)
　まあ、これでそのままにならないところが躁鬱質である。気を取り直してトラブルシューティングを始める。まずどうやって原因究明していくか、気分を落ち着かせてじっくり方策を考える。当研究所にはオシロがある。こういうときのためのオシロだ。これで、それぞれのピンを見ていけば、どこが悪いかわかるはずだ。少なくともLCDの表示が出てデジタル部は完全に動いている。アナログの部分から見ていこう。

　まず、オペアンプの出力を調べる。何も出ていない。入力は、これも駄目。DACの出力は、これもゼロ。それではDACのデジタル入力は？あれえ、ちゃんとCPUからデジタル出力がある。そうかDACが動いていない。DACのBU9480Fが死んだか？クロックはどうだ。あっあっあ、BCLKが出ていない。ベースクロックが出ていなければDACは動かない。DACが原因ではない。

　ちょっと待て、BCLKは何でこんなCPUのピンから出ているのだ？あわてて元のAVRstudioのソースを確認する。何と馬鹿なことだ。DACのBCLKはSPIのマスタークロックが供給源のはずなのに全然別のピンから貰っている。これはどうしたことだ。うひゃあ、SPIのマスタークロックはもうひとつのクロックLRCKにつながっている。とんでもない間違いだ。BCLKとLRCKを取り違えている。

　あーあ、やってしまった。あれだけチェックしたのにどうして間違えたのだろう。やっぱりバグが残っていた。回路図から間違えている。EAGLEは間違えたとおりにボードを設計し、Olimexは忠実に基板を作ってくれた。

　よし、これが原因だ。これを直せば動くはずだ。希望の火が点った。こうなると俄然やる気が出てくる。配線図、ボード図を見ながら、一番良いジャンパー配線をあれこれ考える。LRCKの結線はビアを使っていたので、その前でパタンを切り、ビアとBCLKのCPUピンに直接UEW線でつなぐ。LRCKは、そのパタンのレジストをはがし、そこへ結線する。うまくいったぞ。

　再度、通電テスト。演奏ボタンを押す。ああ、良かった。音が出た。嬉しい。ケースの工作が残っているが、2号機の完成だ。手のひらにすっぽり入る大きさで、CD音質の音楽が聴ける。市販の携帯プレーヤーはこの大きさだと今は動画が出るレベルで問題にならないけれど、いずれはあのSTM32Primerで作ってやる（いけない。封印してあるのに）。

ケースは作り直し、EAGLEのライブラリを公開(10/9/09)
　残るはケースの工作である。ソフトパワースイッチはスペースがないので諦め（SDカードとLCDの電源制御が必要）、電源用の定番のスライドスイッチを基板の下側のスペースにいれ、タクトスイッチや、ボリューム、フォンジャックなどの穴を空ける。

　アクリルの穴あけは簡単だ。ルーターで凡そのサイズを切ってから、ナイフ、やすりで整形する。タクトスイッチの穴が結構難しい。正確な位置決めが難しいので小さめの穴をあけてナイフで広げていく。あ、いけない。仕上げのやすりをかけているとき誤って先端を外に滑らしアクリル面に傷がついてしまった。あーあ、いつもこれである。最後の最後で完成をあせって何か失敗をする。試作版とあって養生テープも張っていない。

　出来上がったので、セットしてみる。傷をつけた面は、自分の横着をあざ笑うかのように、LCDの表示面だ。やれやれ、折角の製品が台無しだ。何とも心が晴れない。どうせ娘に渡す機械だ。少々傷がついていても構わないようなものだが、そこは、それ職人の良心というものがある。

　一晩迷ったが、結局、上蓋だけでも作り直すことにした。このケースは予備を含めて沢山買ってある。何しろ￥100である。次の日、今度は養生テープをしっかり張り、切り欠き位置をきっちり測り直して、作業開始である。お手本があるので穴あけは簡単に済んだ。つけてみる。おお、新しいので蓋のストッパーもしっかり入り、見違えるようにLCDが綺麗に見える。上々の出来だ。これなら自信を持って人に渡せる。

　リニアーPCMプレーヤー2号機は、これで１台目が出来てプロジェクトは一段落した。ヒロセのSDカードスロット(DM1AA-SF 千石で￥210)、千石で売っている平型の2連ボリュウム(型番不明）のEAGLEライブラリーも自信を持って公開できる。

　ステレオフォンジャックについては、もういちど部品エディターで確認してみたら、似てはいるけれど各ピンの位置がすべて微妙に違っていることがわかった。これを現物に合わせることはそう簡単ではない。ソースコードも、ミニLCD用にアイコンを追加した修正版を計画中で、これの完成に併せて、2号機のEAGLEボードファイルと一緒に公開することにする。

ここに、EAGLEの部品ライブラリーファイル　Gataro_parts.lbrを置きます。ヒロセのSDカードスロットと、2連ボリュ-ム(DBL_POT)の２つの部品がはいっています。使う時は、schematic（回路）エディターで、library -> use.. で、このライブラリを開き、ADDコマンドから、上記部品を選んでください

確認の遅れていたステレオフォンジャック（秋月等で入手可能）のライブラリを追加しました。下のlbrファイルは3つの部品が入っています。

「Gataro_parts.lbr」をダウンロード

Olimexのプリント基板はXbeeを先に使う

Olimexから基板キター(9/29/09)
　前回のブログをアップして居間に戻ったら、郵便屋さんが「書き留めでーす」と訪ねてきた。今か今かと待ちかねていたOlimexからの基板の入った航空便だった。へー、日本では書き留め扱いするんだ。しかし、それにしても、「shipped」のメールはその前のブログ記事のアップの直後、今度もこのタイミング。奇妙な符合である。日数が数えやすい。12日で到着したことになる。

　記念すべき最初のブルガリアから基板到着便だ。封を切る前にあわててカメラを取り出し記念撮影する。中からは少し厚めのシュリンクラップにつつまれて基板5枚が出てきた。仕上げはどうだ。うむ、パッドがハンダ仕上げでなく、金フラッシュなので素晴らしく綺麗に見える。

　いやあ、たいしたもんだ。しかし、見ているうちに徐々に胸が高まってくる。果たして実際の部品が、この基板のパッドに正確に入るかどうかを、これから確かめねばならない。自作した部品ライブラリーが正確に出来たかどうか、公開に耐える品質なのかこれからはっきりする。スケール１の印刷で調べてはあるが不安は消えていない。

　まず、SDカードスロットを載せてみる。おお、空けてあった穴とスロットの突起がピッタリ入ってきっちりと納まった。接点も完全に合っている。うまいぞ。次は、平型の2連VR。うむ、こいつも所定の穴にぴたっと納まった。よーし、残るはステレオフォンジャックだ。ややや、こいつは入らない。標準のライブラリに同じものがあったので、余り念入りに確認していなかった。まずドリルサイズがジャックの端子の巾よりほんの少しだが小さい。それに端子の一つが0.2ミリほどずれている。

　マーフィーの法則ではないが、間の悪いことにずれているところはアクティブな端子のひとつだ。しかも配線パターンが部品側でハンダ付けで誤魔化せない。うーむ、困った。ドリルサイズが小さいのは、端子をやすりで細くして何とかなりそうだが、このずれは致命的な結果になる恐れがある。

　暫く思案したが、意を決して、このあいだ使ったアートナイフでドリル穴を少しづつ削りだした。削ったところのスルーホールの金属面は失われてしまうがこれは仕方がない。
アートナイフが結構良く切れるので、ほどなく端子が入るところまで削れた。ルーペでチェックする。まずい。反対側のパッドまで少し削れてしまった。これは大変だ。

　残りの不整合部は、端子をやすりで削り、少しづつジャックを入れていく。入った。恐る恐るテスターで問題の箇所の導通を調べる。良かった。ハンダ付けしなくても導通している。固定する前にハンダメッキすれば大丈夫だろう。胸を撫で下ろす。

　ここ以外は標準部品ライブラリそのままなので余り心配しなくて良い（はずだ）。でも念のため、USBジャックや、ICを確かめる。よし、みんなOKだ。いやあ良かった。部品を載せて本当に動くまで、まだドラマは終わらないが、LPCMプレーヤー2号機の制作は一山を越した。あとは半田付けだけである。

　もうひとつのプリント基板、Xbeeモジュールのピッチ変換基板である。こちらは、2ミリピッチを確かめるだけだ。くもの巣状のXbeeモジュールからソケットを抜いてテストする。苦もなくピッタリ納まる。思わず半田ごてに電気を入れて2つの変換基板のハンダ付けにとりかかってしまう。

　直近から言えば、こちらの基板の方がニーズが高い。バラック配線で苦労している。早速、親機側にブレッドボードに接続するための10ピンヘッダーと、リセットスイッチ、子機には電源と、ループバック用のジャンパーピンを取り付ける。机の上の実験環境はこれで見違えるようにきれいになった。よし、これから本格的なXbeeの実験にとりかかれる。

わかりにくいXbeeのAPIフレーム(9/30/09)
　机の上が片付いたので、本格的にXbeeのADCデータの解析を始めた。ADCデータが送信されるのは確認してあるが、中味はまだ何も調べていない。

　こいつが難儀した。何かわざと難しく書いてあるのではないかと勘ぐりたくなるほどマニュアルのADCデータフォーマットの説明が分かりにくい。わかりやすい英語なのだが、解説しているところが分散してしまっている。

　ADCデータのデータフォーマットはすぐわかった(12ページ）。しかし全体の記述がない。実は次のページ（13ページ）にAPI supportという見出しで、これが0x83（16ビットアドレスのとき）の識別子（後述）を持ち、詳しいフレームフォーマットは62ページを見よという説明があるのだが、このAPI supportという見出しそのものが誤解を招く。APIフレームや識別子そのものが良くわからないときはこのあたりは読み飛ばしてしまう。

　これは説明の順番が逆だろう。始めにADCデータはAPIフレームフォーマットと全く同じ様式であると説明し、そのあと、その識別子（identifier)は0x83で、その中味はこれこれ、と説明されればここまで迷うことなかったように思う。

フレームの構造そのものはそう難しくはない。

1バイト目　0x7E   APIフレームの先頭をあらわすデリミッター。固定。
2 　　　　　チェックサムを除いたデータフレームの長さ2バイト　MSB
3　　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　LSB

ここからがデータフレーム
4　　　　　APIフレーム識別子(identifier)　APIフレームの種類を規定

ここまでがAPIフレーム共通フォーマットで、このあとはAPIフレーム識別子によってそれぞれ異なるフォーマットを持つ。0x83で表わされる16ビットアドレスモジュールの送信I/Oデータは、

5　　　　　フレームを作った通信モジュールアドレス(16ビットアドレスのとき）で、 
6　　　　　64ビットアドレスのときは、5～6 でなく、5～12バイトとなる。
7　　　　　1バイトで表わされる受信電波強度(RSSI)　
8　　　　　オプションバイト(ブロードキャストフラグなど）

実は、この4バイトも、大部分のAPIフレームに共通のフォーマットなのだが、最初、このブロックを見落とし、解析に非常に手間取った。この4バイトのあとが、マニュアルの最初に出ているADCデータのフォーマットの部分である。

9　　　　I/Oデータのサンプル数（合計ではない。合計はサンプル数×ポート数）
10　　　　15ビット分のアクティブなI/OとADCポートの表示。アクティブなところ
11　　　　に1が立つ。　
　　　　　　| ?A5 A4 A3 A2 A1 A0 D8 | D7 D6 D5 D4 D3 D2 D1 D0 |
　　　　　 例えば、A0とD2 、D4をアクティブにしていると、0x02、0x14となる。
　　　　　　ここまでが、データヘッダーと呼ばれる部分。
12～　　　これ以降は2バイトづつのDIOデータとADCデータ（右詰10ビット）が
　　　　　　並ぶ。数は、アクティブなポート数でわかる。但し、DIOデータは必ず先頭で、ひとつしかなく、何らかのDIOをアクティブにしたときのみ付く。フォーマットは右詰のビットフィールドでDIOの状態を表わす。

　フレームの最後は必ず、4バイト目以降のすべてのバイトを足し上げた和の末尾1バイトを0xFFから引いたチェックサムバイトが付く。

　やれやれ。わかってみるとどうということもないフォーマットだが、このADCから出されるデータの解析にほぼ半日かかってしまった。I/Oデータフレームのフォーマットは12ページ、0x83の記述が13ページ、実際のフレーム全体の定義は62ページに分散して書かれているので理解しにくい。最初は0x83の識別子を持つAPIフレームをAPIを解説している章で捜し回って「ない、ない」と騒いでいた。まあ、根が慌て者の早飲み込みと言うだけなのだが。

Xbee子機の電源制御はもっと楽な方法があった(10/2/09)
　何事もやりだすと夢中になって止まらない性質（たち）である。やっとのことでAPIフレームの仕様がわかったので、その勢いが止まらない。本題のLPCMプレーヤー基板の実装はそっちのけで、XbeeのADCデータの解析に進んだ。

　まず、ADCの実際の値を調べる。電流センサーは仕掛けがかさばるので、簡単な手持ちの温度センサーICをテストに使う。最近、秋月が売り出した低電圧でも動く温度センサーLM60である。温度センサーというとLM35Dあたりが定番だが、このセンサーは電源電圧が最低でも4V以上必要で、最初に作った温度ロガーでは、ボタン電池を使って5Vを確保している。

　これに対してLM60の最低電圧は2.7Vからなので、Xbeeなどの3.3V機器には都合が良い。このあいだ使う予定もないのに買ってきてあった。このLM60を鼻歌交じりでXbeeのADCピンに接続し、温度出力を確かめる。こいつは、LM35Dと違って氷点下まで測れる優れもので、0Vが424mV、1 度あたりが6.25mVとなっている。

　ありゃあ、XbeeのADCデータが全く出ていない。電圧が0.6Vくらい出ている（温度26度程度）のはテスターで確かめてあるのに、10ビットのADCデータは3FF(1024)を指したままピクリとも動かない。何故だ。あ、あ、馬鹿だなあ。基準電圧ピンに何もつないでいない。Xbeeには基準電圧ピンのない機種もあるそうだが、この無印Xbeeは基準電圧を入れてやる必要がある。

　とりあえずVccにつないでめでたく数値は、600mV前後の値、200あたりを指すようになった。指でおさえれば着実に数値が上がる。定常状態でちょっと値がフラフラするのが気がかりだが、とりあえずADCの動作は確認できた。

　次は、AC電流センサーの出力を整流するオペアンプの電源制御である。これについては、このあいだ買ったインターフェースのXbeeの記事で願ってもない情報を見つけた。スリープ/アクティブの状況を表示するピン(13ピン)があったのだ。 負論理で、スリープの時がLow、アクティブのときがHighである。勿論、オリジナルのマニュアルのピンアサインにもちゃんと載っている。見落としていただけだ。なーんだ、これを使えば、面倒なリモートATコマンドで子機のI/Oピンをドライブする必要がない。リモートATコマンドも面白いが、これはあとにしよう。

　しかし、このピンで実際の電源制御をFETでやろうとして困った。FETのゲートに直接つなぐことができない。FETはゲートがLowでON、HighでOFFとなり、論理が逆だ。インバーターをつなぐ？うーむ、大げさになるな。何とか素子ひとつで順論理を実現するうまい方法はないか。

順論理のソリッドステートリレーを作る(10/4/09)
　ネットで色々調べたが、順論理の動きをする手頃なソリッドステートリレー回路が見当たらない。FETでなく、トランジスター（オープンコレクター）でも論理は反転してしまう。しかも、NPNトランジスターのオープンコレクターでは、負荷のマイナス側を切ることになり、電源制御のこの方法は前に何度かひどい目にあっている。

　モーターのような独立したディバイスなら問題ないが、LCDや、SDカードなど制御線が本体とつながっている機器は、Vccをグランド側で切ると、機器への電流が制御線を通じて流れ、おかしな動作をする。一番ひどかったのは、SDカードの電源をグランド側で切ったときだ。プラス側が生きているのでSPIを通じてMCUのMega168のI/Oピンに大量の電流が流れ、チップを壊してしまったことがある(8/31/2008 MMC(SDカード）をMega168で)。LCDの電源をグランド側で切ったときも、全体の消費電流が逆に倍増して、あわててバックライトの電源だけを切って、事なきを得た。

　この問題を以前、専門家（サーバーのハード設計者）に尋ねたことがある。答えは、素子の間をフォトカプラーなどで電気的に絶縁しない限り、こういう仕様外の結線では、何がおきるか全く保障されていないということだった。要するにそのときの結線状態の電気回路になるというのだ。この解析は素人の手に負える問題ではない。

　プラス側を切る電源制御も油断がならない。このあいだのH8では、SDカードの電源をFETを使ってプラス側で切ったが、このときはレベルシフター（H8が5V、SDカードが3.3V）経由のSPIを通じて、H8からSDカードに電流が流れ、Vccが上がって幽霊動作をしていたことがある。このお陰で配線間違いのバグに気づかず、H8でSDカードを動かすのに半年近くもかかった。

　それはさておき、整流用オペアンプの消費電流は１ｍA以下である。直接XbeeのI/Oピンで駆動できそうな気もするが、さすがにそれはやめておく。インバーターをどう実装するかをあれこれ考えるより、こういうものは一歩づつ、とにかく動かしていくのが一番だ。まずはXbeeのSLEEP/ONピンがスペック通り動いているかを確認しよう。ピンにLEDを付け、実際に点灯するか確かめる。あれえ、小さく点きっぱなしだ。電圧をテスターで測る。3.3Vと3V。なにい、ON/OFFの差が殆どない。しかもLEDに殆ど電流が流れないじゃないか。何か足らないものがあるのか。あ、あ、あ、ピンの位置を間違えている。馬鹿な話である。正しい13ピンに接続し、めでたくLEDはスリープの度に点灯と消灯を繰り返した。OKだ。

　次は、図の回路である。FETにオープンコレクターのトランジスタをつけた。オペアンプひとつの電源制御のために2つも素子を使うのも抵抗があるが、この際仕方がない。論理反転しているので点灯と消灯がちょうど逆になるはずである。あれえ、同時に消灯、点灯となる。何故だ。SLEEPで点灯したときは消灯し、動作状態のとき点灯しなければいけない。おかしい。あ、あ、あ、それで良いのだ。今日はどうかしている。FETが論理反転するので、わざわざ反転させて正論理にしていることをすっかり忘れていた。Xbeeのスリープ表示ピンは負論理でスリープ時は消灯だった。どうも慌て者の癖が直らない。

　とにかく、これで、省電力設計のXbeeセンサー開発は一歩進んだ。リモートATコマンドのハンドリングも面白そうだが、わざわざしかけを複雑にすることはない。この回路を使えば子機はコマンドを貰わずに独立して電源制御が出来る。

　出来上がった回路を良く見ていて、このFETをPNPトランジスターに替えれば、このあいだ作った検電器のダーリントン接続と全く同じになることに気が付いた。そうか、あの検電器は順論理のソリッドステートリレーだったのだ。ダーリントン接続の回路も早速試してみる。問題なく動いた。まあ、電源制御といっても数mAしか流れない。気楽なものだ。（回路は自己責任でご利用ください。全く自信はありません）

無線モジュールXbeeで(に)遊んでいる(遊ばれている)

　前の記事をアップした直後に、Olimexから例の一語メール「shipped」（発送したよ）を貰った。あれから10日以上経ったが、まだ基板は届いていない。ワイヤレス電力ロガーの通信手段となるXbeeシステムの本格的な開発は、基板が届いてからと思っていたのだが、待ちきれずバラックながら色々試している。Xbeeは思ったより手強い相手だ。

Xbeeのファームウエアを飛ばし肝を冷やす(9/21/09)
　どうもおかしい。ウェブでみんなが実験しているXbeeの機能と、マニュアルの記述やX-CTU（Xbeeの設定ユーティリティ）の設定内容とが一致しない。Xbeeのファームウエアのバージョンの差で機能に大きな差があるようだ。マニュアルの記述の何を信じて進めていけば良いのかわからなくなった。

　今度のワイヤレス電力ロガーでは、センサー側(子機）の構成は必要最小限に抑えるため、ADコンバーターはXbee内蔵のものを使うことにしている。ところがウェブサイトには、このADコンバーターを使っている例が少ない。殆どが、Xbeeを単なるUARTインタフェースの代わりに使っており、たまに見つかってもArduinoというAVRを使った今流行の開発モジュールのシールド（付加基板）の内部コマンドや、企業の開発キットの中で使われていて、具体的な設定方法が公開されていない。

　こうなるとマニュアルに頼るしかないのだが、肝心のADCやI/Oピンの設定コマンドは、マニュアル(v1.xCx版  2008/9/4）によれば、コマンド一覧表の中のXbeeProのみでしか出来ないところにある。無印のXbeeはどうするのだろう。実際にもX-CTUで該当するATコマンドを入れると、そんなコマンドは知らないとERRORが返ってくる。ええーそんな。無印のXbeeでは、このへんのピンは使えないの？まさか。ウェブサイトには無印Xbeeで、このADCピンを使った温度センサーの実験報告がある。どうやって設定したのだろう。

　バージョンの記述がまた混乱させる。マニュアルにはv1.x80とか、v1.xC1とあるが、手持ちのXbeeのX-CTUで出てくるファームウエアバージョン番号は、1084である。どう換算するんだろう。先の記事のリモートATコマンドもX-CTUでテストできると良いのだけれど、このプログラムのリモートコンフィギュレーション画面の中にはそれらしいものはない。X-CTUは最新のバージョンなのだが。

　先人のブログをさらに読み込む。うーむ、リモートATコマンド機能は、ずいぶん最近になって可能になった機能らしい。ファームウエアのアップグレードで出来るようになるらしいが、手持ちの無印Xbeeがその対象であるかどうかはわからない。

　やっぱり、Xbeeは販売元の開発キット（数万円する）を買って全体のバージョンを揃えてから動かすのが本筋のようだ。ばら売りされたXbeeチップだけを買って動かすことを想定していない。しかし、こちらはアマチュアである。とてもそんな余裕はない。

　これはどうも、設計に取り掛かる前に最新のファームウエアにしてみるのがまず先決のようだ。それから何が出来るか考えよう。hamayanさんのページを参考に、ファームウエアのアップデートを試みる。販売元のサイトから、最新ファームをダウンロードする。無印Xbeeの最新バージョンは10C8だった。そうか、わかったぞ。マニュアルのv1.xABというのは、10ABなのだ。

　指示通り、ファームウエアを更新した。基板が来ないのでジャンパーの空中配線でリセットしたりするのは結構神経を遣う。2つあるXbeeモジュールを切り替えてそれぞれのファームウエアを更新する。順調にアップグレードされた。調子に乗って、一方をAPIモードにし、ループバックさせて、親機のADCデータを子機のループバックで見ようと設定を色々いじる。

　そのうちに、親機のレスポンスが返らなくなった。どうもパラメーターを書き込むときに、マウスのホイールを動かしたため、入力窓のパラメーターが動き、違ったバージョンのファームウエアを書き込んでしまったようだ。入力窓に証拠が残っている。まずい。

　単独でもうんともすんとも言わなくなった。UARTが反応しないのでAPIモードのリセットもできない。買って最初のATコマンド投入のとき一度動かなくなったときがあったが、そのうち自然回復した。今度も、小一時間放置して電源入れ直すも状況は変わらず。

　ううう、ファームウエアの書き損じをやってしまったか。しかし、幸いなことにhamayanさんのページには、ファームウエアを書き損なったときの回復手順が出ている。手順を読む。何だと、電源を入れずにシリアルをつなぐだと？それにUSBではできないとある。

　状況は暗い。こちらは秋月のUSBモジュール経由のTTL UARTだ。それに電源を入れないでUARTが動くのか。半信半疑で、USB-UARTからの電源リード(+3.3V)を抜いて、言われるままX-CTUの手順を実行する。ややや、何か反応しているぞ。Xbeeの電源を入れる。おおお、プログラミングしはじめた。素晴らしい。

　やれやれ肝を冷やした。hamayanさんのお陰で、ファームを書き損なったXbeeは、前の状態に完全に復帰した。しかし電源を切ってもファームが書き込めるというのはどういうことなのだろう。理解を超えている。世の中まだまだわからないことだらけだ。

ADCが動かない(9/24/09)
　ファームウエアは、最新の10C8に上がった。X-CTUのコンフィギュレーション画面にも、これまでの1084にはなかった沢山の新しいコマンドが並ぶ。ADC、I/Oピンの設定も出来るようになった。まるで違う機械のようだ。

　しかし、Xbeeの設定はなかなか順調には進まない。こいつUARTだけの透過モードは至極簡単に動くのだけれど、少しインテリジェントなことをやろうとすると突然難しくなる。モジュールを設定するコマンドの数はマニュアルで数えると、何と69もある。

　しかも、Xbeeそのものの種類がやたらと多い。X-CTUのユーティリティで数えてみたら、選ぶべきハードウエアは十何種類、ファームウエアの種類も5種類近くあって、紛らわしいことおびただしい。

　基板が来れば、AVRか何かでXbeeのドライバーを作りAPIモードのテストをするつもりだが、それまでのとりあえずの策として、親機側のADCを動かし、ループバックでそのデータを返して、X-CTUで読むことにする。わざわざループバックにしているのは、子機の設定をテストの度に接続しなおして設定する手間を省くためである。

　しかし、これが言うことを聞かない。Xbee双方を非APIモードのまま、

　ATD0=2   (20ピンのポートをADコンバーターにする）
　ATSM=5  (サイクリックスリープモード、ピン起床あり)
　ATSP=C8 (2秒(200×10ms)ごとに目覚めてADデータを送る)

とすれば、2秒ごとに20ピンのADCデータを親機が子機へ送出し、子機はそれをそのまま親機に返してくるはずなのだが、全く反応はない。単なるループバックテスト（Range Test)は動くので、ハードの問題でなく、コマンド設定の問題である。

　ATIR（サンプリング間隔）とか、ATAS（スキャンアクティブ）とか、それらしいコマンドを片っ端から入れていくが、何の動きもなし。頭を抱える。他に動作を確認する機能もあるのだが（Association機能、LEDの点灯などで動作表示）、空中配線のXbeeチップはICプローブで蜂の巣状態になっており、下手にいじって壊してしまうのが怖い。これ以上、手を加えたくない。皮肉なことにLPCMプレーヤー基板より、Xbeeチップ変換基板の到着が待ち遠しくなって来た。

やっとADCが動いた。基本的なミス(9/26/09)
　珍しく長期のシルバーウィークが明けて、仕事の帰りの本屋で、インターフェース誌の最新号（11月号）を見つけた。お誂え向きに無線特集の号で、Xbeeも掲載されている。早速買い求める。

　記事の内容は、だいたい既知のことが多かったが、頭の中の情報の整理には役立った。全体の見通しが良くなり、落ち込んでいた意欲が復活した。リモートATコマンドによるX-CTUでのリモートモジュールの設定(p104)の説明も収穫だった。ここはマニュアルのないところで、これは助かる（まだ先の話だが）。

　しかし、目の前のXbeeを動かすヒントは見つからない。相変わらずADCが動き出さない。しようがない。ループバックテストは諦めて、子機に設定し直そうとX-CTUでパラメーターを見ていた時、ふと気になるパラメーターが目に付いた。Xbeeネットワークの役柄を決めるATCE(コーディネーターかエンドディバイスかを決めるパラメーター）である。

　現在は、1対1なので片側をコーディネーターにする必要はないが、1対Nに備えて、現在の親機のCEパラメーターは1（コーディネーター）になっている。もしかして、コーディネーターではI/O関係は動かないのかもしれない。だめもとで、これをエンドディバイス （ATCE=0)にしてみる。

　やった。こいつが原因だった。X-CTUのターミナル画面に、親機のADCデータが送信され、子機でループバックされたデータフレームが次々に戻ってくる。いやあ、やっと動いた。マニュアルのどこかには書いてあるのだろうが、こんな基本的なところまでは目が届かない。

　サイクリックスリープモードを解除してみる。立て続けにデータが送られ、見る見るうちにターミナル画面が一杯になっていく。やれやれこれで第一関門は突破した。次の課題はリモートATコマンドによる子機のI/Oドライブだ。

　それにしても、Olimexからはまだ品物が届かない。16日に発送したというのならもう10日が経つ。日本の連休は、外国の航空貨物の取り扱いには関係ないはずで、それにしては遅い。航空便ってそんなに日数のかかるものだったっけ。

Xbeeワイヤレス電力ロガー実装に向けての準備

　電子工作を始めてから最初に作ったプリント基板は、無事Olimexで発注が受理された。どんな基板が送られてくるか、期待と不安に胸が膨らむ。しかし、届くのはあと10日近くかかるだろう。それまで何もしないで待っていられる性格ではない。もともと貧乏性である。特に工作を始めてから輪をかけて手を動かしていないと落ち着かない性分になってしまった。Xbeeを使った電力ロガーの実装に向けて、あれこれ勉強と実験を続けている。

単電源のオペアンプ整流回路(9/11/09)
　電力ロガーのAC電流センサーの出力は当然ACで、XbeeのADコンバーターに入れるには整流してやらないといけない。出力はmVレベルなので、普通のダイオードでは出来ない。オペアンプを使った整流回路が必要だと、この前の記事で書いた。

　OlimexにはXbeeのチップ変換基板も発注してあるが、このあたりを先にブレッドボードで実装してしまおうと、ウェブを先生に整流回路を組み始めた。しかし前にも書いたように単電源のオペアンプで理想ダイオードになる適当な回路例がない。とりあえずは、ここのページのオペアンプ2つを使った全波整流回路（絶対値回路）の接地点をVccの中間電位に変更した回路（ウェブのここを参考）で試してみた。

　しかし、うまく動かないのである。出力がDCにならない。半波整流のような波形でマイナス側にも波形が出る。諸元を色々いじる。全く変化なし。そのうち入力も中位電位にするべきだと気づいて、ここも抵抗2つでプルアップするが、これも駄目。ウェブに載っている整流回路を手当たり次第に試してみるが、すべて単電源では動かないか、整流できない。

　ウェブをさらに検索する。ダイオードなしのオペアンプ2つで全波整流する回路が見つかったが、これは負電位の入力でも誤動作しない特別のオペアンプ（AD823)用で使えない。こちらは、秋月で買った1ヶ￥20の汎用オペアンプLM358で作るつもりだ。DigiKeyで調べたらこのアナログディバイスのオペアンプAD823は千円近くする。とんでもない話だ。

　両電源にするのも馬鹿馬鹿しい。半日あれこれ悩んで、このあいだのリズムキャプチャーで使った単電源オペアンプひとつの全波整流回路をだめもとで組んでみた。これはウェブの説明では、ダイオードの順電圧以下では整流しないとあったので諦めていたものである。確かにこのダイオードの位置では、逆方向は良くても、このダイオードの順方向のところは、整流しないはずだ。

　確認のつもりで、ブレッドボードに回路を組み、AC電流（CT)センサーに40Wの白熱スタンドをつける。150mV位の出力がでるが（オシロでP-P 300mV)、1V以下なので出力は出ないはずだ。

　うわー、オシロから脈流がはっきり出た。少し大小があるが立派なDCだ。コンデンサーで平滑してみる。見事、200mVの直流が得られた。何だ、何だ。今使っているダイオードは1N4148の普通の検波用ダイオードだ。順方向電圧降下は0.7Vもある。誰だ、順方向電圧以下は整流できないと言ったのは。ちゃんと出ているではないか。

　もっと少ない電流はと言うので、公称13Wの半田ごてを入 れる。センサーの出力はP-P 100mV、整流後は、50mVのDC出力が出た。立派なものだ。案ずるより生むが易しとはこのことだ。これでXbeeに入れるアナログ入力の回路の目処がたった。

　ついでにオペアンプの消費電流を測る。3.3VのVccで、0.3ｍAだった。FETで入り切りするのも微妙な電流だが、行き掛かり上、FETを出して、おさらいをする。ゲートをプルアップしておき、XbeeのポートをActiveLOWにしておけば、Xbeeがアクティブなときは、ON、スリープして、ポートがHiZになったときはOFFという勘定だが、これはもう少しデータシートを読み込む必要がある。

丈夫なXbee子機にするために(9/13/09)
　Xbeeシステムの詳細設計は、Olimexのピッチ変換基板が来てからと考えていたが、オペアンプの電源制御のために、もう少しつめておく必要が出てきた。考えてみたらスリープのとき、I/Oピンの状態が変わることは通常考えられない。何のためのI/Oピン、スリープということになる。何とか他の方法で電源制御が出来るようにならないものか。

　マニュアルをもう少し詳しく読み込んでみる。その結果、子機の設定を親機を通してできるリモートATコマンドというのがあることがわかった。Xbee単体はプログラマブルではないが、ATコマンドを沢山使えば、かなりインテリジェントな動作をさせることができる。

　これ、これ。スリープから目覚めた子機に所定のコマンド（I/Oピンの制御）を送ってやれば、ADコンバーターのオペアンプの電源を立ち上げることができそうだ。リモートATコマンドは、Xbee間の通信を、単なるUARTになる透過（トランスペアレント）モードでなく、APIモードにすることで送ることが出来る。APIモードのデータフレームの仕様は詳しく出ているので開発に不安はない。

　しかし、当初の仕様は、スリープモードから目覚めた子機は、一方的にデータを送り出すことにしてある。なるべく親と子供の間を独立させるためだ。親の指示がないと動けない、ひ弱な子機にしたくない。しかも親は子機の状態を気にせず、ただ、データを送ってくるのを待つだけにしたい。

　スリープモードのところをさらに詳しく調べる。すると有力な方法が見つかったのである。Xbeeのスリープモードは全部で4種類あり、消費電流の一番少ない、ハイバーネートモード(SMパラメーター=1)、消費電流は多いが立ち上がりの早い、ピンスリープモード(SM=2)、それに、タイマーで周期的にスリープするサイクリックスリープモード（SM=4、5)である。

　サイクリックスリープは、よく読むとスリープから目覚めた時、必ず親機（コーディネーターと呼んでいる）にポーリングをかけ、受信すべきデータがキューされていると、それを読みこむ。データがないとすぐにサイクリックスリープ（SPで決めた周期）に入る。受信データがあるときは起きたままとなり、スリープ休止時間 ST(Time before Sleep）パラメーターの設定した時間が来るまで起きている。

これまでサイクリックスリープ時間（SP)というのと、スリープ休止時間（ST）という２つのパラメーターが良く理解できなかったが、これで良くわかった。

これだ。このポーリングのタイミングでAPIモードのデータフレームを送れば、見事にオペアンプの電源をONにできそうだ。うまいぞ。

　しかも、親と子の通信は同期させる必要はない。親は送信データをバッファーにスタックしておくだけでよい。子機はキューされていたこのデータを受け取る。親は、このバッファーを常に監視して、なくなっていたら補給しておく。うむ、これで親子は自立して動ける。

　OFFはどうする。これは最初の子機の設定（ADコンバーター出力指定など）のコマンド列の最後にI/OポートをOFFにするコマンドを入れておく。うーむ、出来た。

まさしく机上のロジックだが、何かうまく行きそうな気がする。

100VACの検電器をつくる(9/16/09)
　電力ロガーは電流しか測らないことに決めた筈なのだが、実はまだ未練がある。電力測定用の専用ICを使えば文句なしに精密な電力量を記録できる。やってみたい。このチップADE7753はDigiKeyで￥500少々で手に入るが、これひとつに送料￥2000を払うわけには行かない。DigiKeyは発注額が￥7500を超えないと送料は無料にならない。

　ところが、DigiKeyに注文できる有力な電子機器が出てきたのである。このあいだまでさんざん遊んでいたARMプロセッサーのSTM32F103を使った開発キット、STM32Primer2である。128×160ドットのタッチパネル付液晶とそのコントローラ、マイクロSDスロットがついて￥6000台。魅力的なスペックだ。この開発キットは、最近は秋月電子でも売り出した。

これが何とDigiKeyでも買えるのだ。しかも日本で売られている価格より、ほんの少しだけだが安い（DigiKeyの商品番号497-8511-ND ￥6,188)。これを買えば、送料無料の￥7500を超える！

　一瞬、発注のボタンに指がかかったが、寸前に思いとどまった。これ以上、手を広げると何がなんだかわからなくなる。あまりにも色々なものに手を出しすぎだ。 収拾不能になってしまう。BeagleBoardだってそうだ。当ブログのアクセス数では今でもトップの話題だけど、あれから全く動かしていない。マイクロウェブサーバーにしようと思っているけれど他の事が忙しくで手がつかない。

　しかし、ADE7753を買える可能性は出てきた。こいつはAC電圧のアナログ部が絶縁されておらず、デジタルとグランドが共通なのでボードを分けるなどの配慮が必要だ。それにしても無闇に100VACを怖がっているのは能がない。買える時が来た時慌てないで済むよう100VACを自由に操作できる技術を身につけておこうとウェブであれこれ勉強する。

　要するに、AC100Vはテーブルタップを使ったり、工事業者が良い加減で極性を逆にしてしまったりして、ホット側がわからなくなるから危険なのだ。ホット側がいつでも検知できるのならば、そう心配する必要はない。

　ホット側から分圧抵抗で落とせば安全な電圧が得られる。テーブルタップを経由して極性がわからなくなっても、ホット側がわかる昔使った検電ドライバーのようなものがあれば、思わぬ事故の心配はなくなる。

　昔、真空管ラジオがトランスレス全盛だった頃は、この問題は日常的な問題だった。ネオン管をドライバーに入れた「検電ドライバー」というのを覚えている。ウェブで調べてみる。何だ何だ今でもあるんだ。沢山出てきた。強電関係では必須のツールのようだ。

　ただ、検電ドライバーは柄のところに金属面が出ていて、いくら絶縁されているとはいえ触るのは少し怖かったのを覚えている。もう少し進歩していないか、ウェブをさらに探す。

　すると、LEDとトランジスタを使った非接触の検電器の回路が見つかった。トランジスタを2段接続して増幅度を稼ぎ、数メガはあるだろう絶縁を通しての微小交流電流を検知して、LEDをつける装置のようだ。

　これだ。これを作ろう。早速、ストックしてあった、コンプリメンタリなトランジスタ（2SC1815 2SA1015)を取り出してブレッドボードに組んでみる。参考にする回路のVccは、9Vだが、こちらはボタン電池(CR2032)での実装を狙ってLED抵抗を下げた(2.2Kから330Ω）回路にする。

　動かしてみる。よし、ちゃんと動いた。消費電流を測る。点灯時で0.5mA、ついていないときは、1μA以下だ。ああ、これなら電源スイッチもいらない。ボタン電池が入るケースを探す。記念に貰ったいくつもあるネクタイバーのケースがちょっと大きいが、手頃な大きさのようだ。ここへ実装することにする。

　久しぶりの基板工作である。基板の固定はネジ止めでなくホットボンドにする予定だ。手を動かしてモノを作ることが楽しい。数時間で完成する。実装版も問題なく動いた。それにしても不思議だ。検電ドライバーのように金属に全く触らなくても、ちゃんとホット側でLEDが点灯する。

　ためしにテスターでホット側のAC電圧を測ってみる。プローブをホット側に差込むと、一方のプローブを浮かしても6V近く を指した。今度は浮いているプローブを恐る恐る手で触ると90Vを指した。電気が来ている感じは全くない。そうか電流が流れなくてもこんなに電圧がかかっているのだ。思わぬ実験の結果に少し感動する（くれぐれもホット側のプローブを触らないように。感電します）。

Olimex発注の合間にACの実験

Olimexに基板を発注した(9/05/09)
　電力ロガーの仕様を考えているうちに、9月も何日か過ぎてしまった。既に設計が完成しているLPCMプレーヤー2号機のプリント基板を早くOlimexに発注しなければならない。EAGLEによる設計は、本体と、Xbee用のピッチ変換基板ともほとんど完成している。あとは、160×100のパネルの分割指示をする面付け図と、発注仕様を伝えるREADME.TXTを作るのを残すだけとなっている。　

先達のウェブページを参考に、面付け図を作る。今作ろうとしている基板は本体が3 枚、ピッチ変換基板が2枚である。大きさに余裕があるので、基板の切り離しは、ディスクカッター（abrasive)を選ぶ。

　おやあ、ウェブの面付けの参考図と一枚当たりのサイズを求める計算式が一致しない。1枚を2枚にディスクカッターで切るときは、図は、2ミリづつ、4ミリののりしろをとっているが、サイズを求める式は、(n-1)*2で2ミリののりしろしかとっていない。

本家のOlimexのサイトをあたる。FAQに出ている式は先の計算式と全く同じだ。ところが、この図を参照という切り離しの絵では、一枚づつのりしろを作っている。うーむ、良くわからない。

　面付け図がおかしいというだけで作成を拒否されたと言う報告もあるが、わからないものは仕方がない。とりあえず2ミリのまま出すことにする。

　EAGLEの基板図(brdファイル）を念のため、もう一度点検する。不要なレイヤーを表示しているだけで拒否されると脅かされているので、DRCを何度もかけ、ドリルチェックをし、何度も表示レイヤーを見直す。

　あれ、SDカードの配線が少しおかしい。ややや、チップセレクトの線がCPUとつながっていないぞ。慌てて回路図(schematic)の方を確かめる。あれえ、回路図から間違っている。これはいけない。いくら基板図でDRCをかけてNo Errorにしても、回路図が間違っていたらお話にならない。

　泥縄に近いが、もう一度回路図を最初から点検する。その結果、USBジャックのピンアサインが逆になっていることを見つけた。それとミニLCDのI2Cの接続が逆になっている。まあ、これはソフトで解決できるにしても、事態は深刻だ。

　完全と思っていてもこれだけバグが出るのだから、まだ潜んでいる可能性がある。ICのピンアサインを中心にもういちどチェックし直しである。まるで、答えを全部書き終わった試験の残り時間で何度も検算し、同じ答えが出てきても確信が持てなくて益々不安が拡がる時に似ている。早くOlimexに送ってしまって、楽になりたい気持ちが募る。

　面付け図と、2つのbrdファイル、readme.txtをまとめてzipファイルにする。ウェブの古い別のOlimexの発注ガイドのサイトでは、readme.txtとzipファイルを別々に送れという指示があり混乱する。これは明らかに１つの間違いだ。readme.txtなどという汎用的な名前でファイルを送られたら受け取った方は大変だ。

　出来たzipファイルを念のためこちらで解凍し、正しくファイルが解凍されるのを確認したうえ、いよいよ送付である。「行けー」という掛け声とともに、送信ボタンを押す。何い、エラーで送れない。そんな馬鹿な。ブラウザーを動かしてみる。ありゃりゃ、ネットが不通だ。

　よりによって、このタイミングで回線が切れている。しかし、何もこんなタイミングで回線が切れることはないだろう。高ぶった気分が納まらない。どうしてやろうかと頭が激しく回転していた時、ウェブが復活した。数分の回線断だったようだ。

　メールを送り直す。今度は順調だ。zipファイルを添付したOlimexへのメールは無事、ブルガリアに向けて出発した。出した日は土曜なので受け付けられるのは、あさっての月曜だろう。今のところエラーメールで帰ってこないので、とりあえずOlimexのメールボックスには納まったようだ。

交流(AC)波形を調べる(9/6/09)
　発注データは送ってしまった。今さらもういちどEAGLEを動かして図面を見る気にはならない。誤りに気がついても間に合わない。気分が悪くなるだけである。手持ち無沙汰になったので、このあいだ思いついた実験をしてみることにした。

　考えてみたら、オシロがあるのだ。50Hzの交流など簡単に観測可能な環境を持っていることを忘れていた。電圧と電流をそれぞれ観測して、家庭内の機器が、どんな負荷か調べて見ようと思いたった。特にトランスを経由したあとの電圧を見てみたい。

　電圧の測定は直接100Vからとるのでなく、トランスを経由して絶縁すれば、危険な直接接続は避けることが出来る。しかし、トランスというのは誘導負荷のかたまりみたいなもので、これを経由して波形を見るのは本来意味がない。ただ、理論的には位相差は出ないことになっている（理想トランス）。これがどの程度なのか実際に見てみようというのである。

　こんなに絶縁にこだわるのは理由がある。家庭用の100V ACは漏電による感電事故に備えて必ず片側が地面に接地されている。筐体（接地してある）などにホット側が漏れ出せば直ちにブレーカーが飛び、接地側が漏れても漏電ブレーカーが動くようになっている。

　この結果、100Vを機器に引き込んで、うっかりプラグ（電極の大小で極性はわかるようになっているが）を逆に差してしまうと、機器のグランド側が地面に対して100Vの電位差を持つことになる。触れれば当然感電するし、繊細な電子部品など触れればあっという間にこわれるだろう。

　自作の、名刺ケースに入れたトランスのACアダプター(3、6V出力）で波形を見る。うーむ、少し歪んでいる。きれいな正弦波ではない。CTセンサーをはさむ。手持ちに10W以上消費できる抵抗がないので、とりあえず1Wほど流れるよう豆球（0.3A)の負荷をつける。おお、電流波形が出た。おや、このトランスの最大容量は0.16Aだ。これはいかん。焼けてしまう。

　トランスにCTセンサーが動くほどの電流は流せないことがわかった。待てよ。テーブルタップを使い、ひとつをトランス、もうひとつを別の機器に入れ測っても、その時点の電圧と電流が測れるのではないか。

　やってみた。見事に各種の機器の波形を見ることができた。トランスの電流電圧位相差は2次側が無負荷のときは180°になることがわかる。電圧（赤）はこの際無視して電流(黄）波形を見る。

　まず、手元の60Wの白熱灯スタンドを測定する。きれいな電流波形が出た。セラミックの半田ごても抵抗負荷なので正弦波である。次は、工作照明用の32Wの電球型蛍光灯 を使ったスポットライト。こいつは予想通り、派手なパルス波形が出た。調子に乗って、身のまわりの電気器具を片っ端から測り始める。スイッチング電源のDCアダプターも、完全なパルス波形だ（電流が少ないためオシロ波形はスケールが替わっている）。

　ドライヤーをモーターだけで測る。波形が半分削られたような電流波形になる。位相差はそう激しくない（力率が高い）。いやあ面白い。ただ、電圧は同じタップ上とはいえ、器具の負荷点で測っているのではないので、何ともいえない。

まだこだわっている(9/7/09)
　1週間ぶりに事務所に出る。メールを片付けた後、当面の仕事がないので、ウェブで非接触で100V電圧を測る手立てをあれこれ探した。まだ、こだわっている。日置という昔からある計測器メーカーが「世界初の非接触電圧計を売り出し」たという去年のニュースリリースを見つける。原理は詳しくわからないが、静電結合で双方の波形を測定し、その差を電圧とするらしい。そうか非接触で電圧を測ることは普通は出来ないのだ。少し安心する。

　しかし、よく考えてみれば、ADコンバーターの部分さえ独立させ、そこでデジタルにしてしまえば、あとはフォトカプラーが使える。基板を別にしてグランドを独立させれば、感電の心配はなくなる。あの電力測定用のIC ADE7753もアナログ部とデジタル部のグランドは共通なので、この方式をとる必要がある。

　絶縁型のADコンバーターがあればフォトカプラーも要らないのだがと、ウェブで検索してみたら、あったのである。前のICと同じ、アナログディバイス社のAD7400というADコンバータだ。アナログとデジタルの間が絶縁されている。3.5KV以上の耐圧だ。DigiKeyでも1個売りしてくれるが￥984と少し高い。

　やはり考えていることはみんな同じだった。しかし、波形のサンプリングや、二乗平均をとる演算などの手間を考えれば（面白そうだけど）、専用ICのADE7753を使うのが最も合理的のようだ。DigiKeyで1個￥495で買える。絶縁はボードを分けてフォトカプラーを使えば良い。50Hzの観測データだ。フォトカプラーは高速である必要はない。汎用品で十分だろう。

　DigiKeyで買いたいものが増えてきた。しかし、送料無料の￥7000にはまだまだ達しない。欲しいのは今のところ、イーサネットのPHYトランシーバーとこの電力測定ICだ。２つづつ買ったとしても￥2000少々にしかならない。

整流をオペアンプでやるか(9/8/09)
　Olimexからまだ返事は来ない。波形実験の次は、CTセンサーからのAC出力をDCにする方法を思案している。整流回路だ。一番簡単なダイオードをシリーズにつけた半波整流回路は今度は使えない。ダイオードはどんなものでも順方向電圧降下というのがあり、微小電圧は整流できない。電圧が高ければたいした問題でないが、こんどは数mVからDCにする必要がある。電圧降下が少ないといわれるショットキーダイオードでも0.3V、入手難といわれるゲルマニウムダイオードでも0.1V、これでは話にならない。

　やはりオペアンプで検波回路を組み、いわゆる理想ダイオード回路で、小電圧を整流する必要がある。しかしウェブに出ている回路は、スペクトルアナライザーなどに使う高周波の整流回路が殆どで、高速性が重視されており、50Hzなどという「ゆるい」対象向けの簡便な回路例がない。

　オペアンプの整流回路といえば、このあいだのリズムキャプチャーで使った、単電源オペアンプの全波整流回路があるが、これは、ダイオードの順方向電圧以上でしか整流しない。

それにオペアンプを使うとなると、今度は消費電流が心配である。Xbeeをタイマーで止めて50μA以下にしても、こちらがミリアンペアオーダーで流れるというのは嬉しくない。

　ダイオードの入力側にバイアス電圧をかけて、この区域をキャンセルし、ソフトで補正する方法も考えられるが、今度は、測定上限電圧が低くなってしまうし、バイアス電圧の変動が直接誤差になってしまう。難しいものだ。

となるとFETでオペアンプの電源制御か。やれやれおおごとになってしまった。

OlimexからPO用紙が届いた(9/8/09)
　先週の日曜日にメールでデータを送ったOlimexから待望の返事が届いた。営業日2日目である。注文の殺到しているだろう休み明けにしては早い。夜の9時に届いているから現地は午後2時ごろだ。1日半というところか。来たメールはウェブで報告されている通り、たったの4行である。

Hi
attached is your po form
Best regards
Tsvetan / Olimex

　噂のTsvetan（ツベタン？)君である。まあ、Best regards（どうぞよろしく）があるだけ良しとせねばなるまい。問題は、請求金額だ。どきどきしながら添付のPO用紙（Purchase Order form）ファイルを開く。良かった。追加料金はなかった。パネルの面付けはあれで合格したようだ。ドリル数が500を超えた追加料金3ユーロは織り込み済みである。Xbee基板を入れると、どうしてもドリル数が500を超え、どうせならと汎用基板のようにパッドを沢山つけて全部で800近くになっている。送料を含めて合計41.5ユーロ、約￥6000というところだろう。うーむ、Xbeeピッチ変換基板を日本で買って、4枚にした方が安かったか。

　それはともかく、早速クレジットカード情報を書き込んで発注書を完成させる。支払いがカードで出来、しかも、その情報をFAXで送らせるという用心深さが気に入っている。海外との通信販売で一番神経を遣うのがお金のやりとりだからだ。

　いよいよ国際FAXである。国際電話のかけ方を、ウェブで復習する。何、頭につける番号に沢山種類があるぞ。001だけじゃないんだ。マイライン契約のときはいらないだと？うーむ、そう言えば、あのマイラインってどうなったんだっけ。我が家の電話はだいぶ前から「ひかり電話」でこのあいだKDDIの「ひかりONE」に替えたばかりだがマイラインをどこにしていたのか全く思い出せない。

　いくら読んでも、良くわからないので、一番ポピュラーそうな001010を選ぶ。FAXにカード番号を書き込んだPOをセットした。Olimexへの電話番号を入れる。数回、短い通話音がしたあと、先方のFAXのネゴシエーショントーンが聞こえた。やった、つながった。
FAXが動き出す。無事POを送り終わった。1時間足らずで処理は終了した。

　次の日、Olimexからメールが届いた。例によって本文は

fax received

この一行だけである。まあ、これで用は済んでいる。POフォームを裏側にしてFAXしたのではないかと少し心配したが、これで安心だ。まさか白紙を受け取ってfax receivedとは書かないだろう。AirMailが結構日数を喰うみたいだが、今月中には届く予定だ。楽しみである。

Xbeeを使った電力ロガーの仕様を考える

気楽に作れる機械ではない(8/27/09)
　当面の目的は電力ロガーだと、前の記事で気安く書いた。Xbeeの通信テストが順調に済んだので、具体的な設計に向けて少し本格的に電力ロガーについてウェブで調べ始めた。ところが、電力ロガーというのは殆どが業務用であり、簡易なものはともかく少しまともなものを作ろうとするととんでもなく大変なことになると言うことがわかってきた。これをXbeeのターゲットにしてしまったことを後悔するが、今さら難しいからやめますというのも悔しい。プライドが許さない。それにAC電流センサーを買ってしまってある。

　電力ロガーを作ろうと思いついたきっかけは、前の記事に書いたとおりレーザープリンターの電力量を調べたくて電流センサーを買ったことから始まる。どうせなら我が家の電力消費量を時間帯別に把握したいと、この前の温度ロガーと同じような気楽な乗りで考えていた。しかし調べていくうち、交流（AC)の場合、正確な電力の測定というのは実は非常に難しいことがわかった。

　電力とは、電圧と電流の積であらわされる。ところが交流は電圧、電流とも、直流（DC)と違って一定ではない。波形が正弦波そのままなら、ピーク値から補正して（0.707)計算できるが、負荷がモーターや蛍光灯など、いわゆる誘導負荷と言われるものは、波形が大きく乱れるだけでなく、電圧と電流の位相差が出来る。つまり実際の電力は単純に電圧と電流をかけた量にならない。区間の平均の電圧と電流が測れても、平均電力はその積にならない。瞬間、瞬間の電圧、電流の積を積分しないと平均電力にならない。

　最近の家庭では、白熱灯、電熱器などのような単純な抵抗負荷は少なく、掃除機、洗濯機、冷蔵庫、クーラーなど、むしろモーター（誘導）負荷が多い。最近のPCのスイッチング電源も誘導負荷だ。この負荷の電力を正確に測定するには、電流だけでなく、電圧も同時に測り、しかも相当複雑な演算が必要だ。

　どこの家庭にもあるお馴染みの積算電力計は、このあたりはアナログで実にうまく測定している。電圧コイルと、電流コイルが円盤をはさんでおり、双方の積が円盤を回す駆動力になるようになっている。円盤の回転数が積算した電力になる。実に巧妙な仕掛けだ。あらためて感心する。

　それでも、ウェブで「Xbee　電力ロガー」などで検索をかけると、結構、電子工作として作った電力ロガーの例を見ることが出来る。なかでも、こちらと全く同じXbeeを使ったワイヤレス電力計をプロジェクトで作られた、Fenrirさんのサイトは実際にロガーを何台も作られて現実の家庭の電力を測定し、ちゃんとした結果まで出されている。素晴らしい。

　hamayanさんのサイト「UnderPower研究所」でも、Xbeeを使ったワイヤレスの電力測定の実験が行われている。ここのサイトは、当研究所が、何かやろうとすると必ずこのページに辿りつき、以前から何かとお世話になっている。ただ、どちらも、ちょっとプロ過ぎて参考にするには高度すぎる。

　Fenrirさんのページの中で、市販されている家庭用の簡易な電力ロガー、エコワットは、電流を測っているだけで、電圧が常に100Vで、電圧と電流の位相差がない（力率100%)と仮定して電力を計算していることが確認された。これに対して、hamayanさんの機械は、100VACの電圧、電流を真面目にマイコンのADCで数波形分サンプリングし、いわゆる実効電力をマイコンで計算している。Fenrirさんのところは、なんと電力測定専用のIC(アナログディバイスADE7753)を使っている。これはDigiKeyでも数百円で買えるICだ。驚いた。こんなものにもICがあるのだ。

　さて、困った。エコワットが電流だけしか測っていないのではという推測はあたっていたが、当初、エコワットを超えてもう少し精度の高い測定をしてやろうという野心は簡単に打ち砕かれた。電圧を測らないことにはどうにもならない。100Vの電力線に何かを接続しない限り電圧は測れない。

　上記のサイトにも触れられている通り、100VのACを相手にするには相当な覚悟が必要である。白状してしまえば、非接触型のCT(Current Transformer)電流センサーを買ったとき、これで100Vをいじらなくても電力が測れると思い込んだのが電力ロガー開発の動機でもある。今更、危険な100Vのハンドリングをしたくない。LANを使った電源制御では100Vを使ったが、フォトカプラーで分離した。今度は、アナログ入力なので分離するわけには行かない。下手な設計をすれば、コンセントの差し替えだけで感電する。トランスを使えば分離できるが、トランスそのもの位相差で何を測っているのかわからなくなる（理想トランスは位相差0だが）。

　電力測定用のICと言い、ADCで波形をサンプリングして実効電力を求めるロジックと言い、激しく工作心と好奇心を揺すぶられるのだが、安全に商用電源から電圧を取り出す方策が見当たらない。既知の抵抗を入れて、そこに流れる電流をCTセンサーで測れば、非接触で電圧が測れるが、大掛かり過ぎるし精度を上げるようとすると無駄な電力を食ってしまう。それに個別の電力ならともかく、配電盤をいじるわけにはいかない（このあたりの工事は資格が要る）。

　あれこれ思い悩んでいたが、冷静になって原点に戻ってみた。そもそも電力ロガーは、Xbeeのテストベンチのために選んだようなテーマである。ここにこだわって先に進めないのは本末転倒だ。電圧を測るのは止めることにする。この際は、涙を呑んで電流だけで電力を推定するエコワット方式でログをとることにする。

　まあ負け惜しみになるが、正確な電力量は料金を計算する積算電力計が厳密に測っている（はずだ）。今こちらが知りたいのは、テレビや録画機、パソコン、ウオシュレットなど最近やたらに増えた電子機器の待機電力と、プリンター、冷蔵庫などの間歇的な大電力だ。相対的な実態がわかれば目的を十分果たせると思う。

全体の仕様を決める(8/29/09)
　電力ロガー開発の大筋が決まった。電流だけしか測らないことにしたので、センサー側にXbee以外のICを載せる案はもう考えないことにする。センサーは将来複数個を、家の中にばらまいて個別の電力量を測定することを考えれば、なるべく簡単に、安価に作れるほうが都合が良い。

　問題は、子機のXbeeのADコンバーターに、手元にあるCT電流センサーを直接つないでちゃんと所定のデータが出るかどうか、オペアンプなどの増幅回路を追加しないで済むかどうかである。

　データシートを見直す。これによると、6チャンネルあるXbeeのADコンバーターは基準電圧が、2.08VからVcc(3.4V)まで、10ビットの分解能で、1ビットあたり3 ～5mVである。一方、手持ちのCT電流センサー（U_RD社製 CTL-10-CLS）はカタログによれば負荷抵抗を1KΩにすると、0.01A（10W)で4mV程度の出力があるので最小のところはこれで良い。

　しかし、最大電流の方は10A(1KW)で、Xbeeの基準電圧を越える3V以上になってしまう。ピークの電力量も知りたいので、最小測定電力はもう少し上げる必要（負荷抵抗をもっと下げる）があるかもしれない。まあ、これはいつでも調整できる。いずれにしてもオペアンプなどの追加回路は必要ないことは確認できた。

　次は親機側の設計である。どの程度の間隔で、どれくらい測定データを収録するのか、記録媒体は何にするのか、機械の操作をどこでやるのか、グラフ化などの処理をどうやってやるのか、決めなければならないことは山ほどある。

　少し大げさな言い方だが、こういう具体的な用途が決まっていないシステム開発というのは、自由な設計が出来るように見えて実は一番厄介である。好い加減な検討で仕様を決めて作ると必ずあとで色々なところで不満が出てシステムの手直しをさせられる。

　今までやったことのない新しい仕事にシステムを適用しようとする時が、だいたいこれにあてはまる。技術的な可能性に任せて色々な機能を用意しても、まず殆ど使われない。無駄になる機能が多い。要するにやってみないとわからないことが多すぎるからだ。昔のシステム開発時代の悪い思い出が頭をよぎる。

　ただ、長年の経験でこれを解決するノウハウはある。それはシステムの最終目的になるべく近いところで想像力を駆使して可能な限りの具体的なシナリオを作り、そこからシステム機能を決めていく方式である。逆から機能を絞る。

　この電力ロガーで言うなら、このロガーを使った自宅の電力測定で何か無駄な機器が動いていることがわかり、その使い方を変えて消費電力の削減に成功した、というようなことが起きると想定し、そのために必要な機能を洗い出す。

　そういう観点から行くと、1週間位つけっぱなしの測定期間は必要なように感じる。使用者は今のところ自分しかいないので、操作性は余り気にすることはない。しかし、ソフトを公開することを考えるなら、余り要素は増やしたくない。PC側にアプリケーションを持たず、通信端末からのデータのCUT&PASTEでEXCELに取り込む今までの方法で十分か。ただ、PCがなくてもスタンドアローンで親機は動いている必要はある。

　間歇的な電力も知りたいので、測定間隔はなるべく短くしたい。しかし、あまり短くするとデータ量が増えすぎて処理が大変になる。記録媒体はEEPROMでは少なすぎる。やはりSDカード位は必要だ。するとプラットホームはMega168クラスというところか。

　SDカードにグラフに必要なデータが収容できれば、SDカード経由でデータをPCに渡し、少し大きめのLCDで、間隔設定や、開始終了指示をする完全なスタンドアローン機器にすることも出来るが、これは、まあ先のバージョンの話だろう。今のところはUARTだけで良い。

　段々、仕様が具体的になってきた。最後の大きな課題がXbeeの省電力を含めた設計だ。

Xbeeの仕様を決める(9/2/09)
　Xbeeは通信を待つアイドル状態の消費電流が50mAと結構大喰らいである。間歇的に測定する場合は、その間は休止させておかないと電池の消耗が激しい。この機械が実用的な機械になるかどうかの大きな課題だ。今回のプロジェクトで当初から一番気になっていた仕様である。

　データシートを読み込む。それによると、親機側からの指示で、子機を立ち上げることは不可能であることがわかる。Xbeeのステートマシンはアイドルを経由して各ステイタス（通信、アイドル、スリープ）に遷移するので、スリープから通信ステイタスには直接移れない。タイマーを使ったスリープで節電するしかないようだ。

　親機側の省電力の要請は余り大きくない。PCの近くなのでDCアダプターが使える。しかし、将来のスタンドアローン機器を考えると、子機のスリープと同期して動かすことも考えておく必要があるだろう。

　親機と子機はなるべく独立した機能を持ち、それぞれが相手を気にしないで動くこと。それでいて子機の送ったデータを逃さないこと。いわゆるRobustness（堅牢）なシステムを目指して、あれこれ思い悩む。

　その結果、出来たのが次の仕様である。想定している部分もあるので、これで出来るかどうかは未知数のところがある。

センサー側（子機）

• 測定間隔：　10秒ごとのタイマーでADCを起動（間隔は親機から変更可能）
• 測定開始：　電源を入れるとただちに起動。
• 測定回数：　0.5秒間に100ms間隔で5回測り、親機へ送信する。
• 送信後の措置：　　直ちにスリープに入る
• Acknowledge（確認）：　親機が受け取ったかの確認はしない（送りっぱなし）

データログ側（親機）

• コマンドの指示により、受信待機
• 子機からのデータを受け取ったあと、100ms以上データが来なければ、1セッションとみなし、データの個数の平均を計算し、平均値をそのときのRTCデータとともに、SDカードに書き込む。
• 書き込んだ後は、ファイルをSYNCし、不測の電源断に備える。
• コマンドの指示により、ファイルクローズ

　使用のイメージは、センサー側の子機の電源を入れて、測定箇所に置き、親機も電源を入れてログを開始する。親機は、子機からのデータを待って、データ発信があれば子機識別情報と一緒に電流データを受け取ってログしていく。いつ受け取ったデータかは、親機のRTCで日付時分秒データを登録レコードにつける。

　PCへのデータ送りは基本はSDカード渡し。UART経由でもできるように、データダンプのコマンドがいる。考えられるコマンドは以下の通り（すべて実装するわけではない）。

1. 子機の設定変更コマンド　測定間隔などを設定した子機の初期化コマンドを子機に送る
2. 子機の状態表示コマンド　子機の状態、子機の設定パラメータを返す（要調査）
3. 測定開始（ファイルオープン）コマンド
4. 測定終了（ファイルクローズ）コマンド
5. RTC設定/表示コマンド
6. SDカードのファイル名表示
7. SDカードファイルの内容表示
8. 電源を入れてから記録したレコード数の表示

　結局、Xbeeを入れても、通常のUARTを使ったロガーと同じような形になった。将来的にはXbeeを複数台入れることを考えて1対1ではなく、1対Nの通信をしても大丈夫な構造にしておく必要がある。

　こんなことを考えるうち、9月を迎えた。Olimexへの注文の作業に切り替えて、こちらの方は少しお休みすることにする。

Xbeeをテストしてみた

　LPCMプレーヤー2号機のプリント基板の制作が一段落した。Olimexに発注するXbee用の2ミリピッチの変換基板も簡単に出来た。あとはメールでブルガリアにファイルを送る手順を残すだけとなった。手が空いたので、ストロベリーリナックスでミニLCDと一緒に買ってあったXbeeを実際に動かすテストをすることにした。

なぜXbeeなのか(8/20/09)
　2.4GHz帯の電波を利用して機器同士を無線ネットワークでつなぐXbeeは前々から関心があり、あれこれ調べていた。こいつはユニークな形をした通信モジュールチップで、チップ同士で自律的なネットワークを組めるのが最大の特徴だ。ハードはシリアル通信機能（最大250kbps）だけでなく6チャンネルのADコンバーターまでついており、このチップひとつでリモートセンサーを構成できる。インテリジェントなのでスリープ機能を利用した省電力設計も出来る。工作心（ごころ）を刺激するICチップだ。

　当研究所では、電力ロガーの通信手段にしようとして購入した。Xbeeの基本的な到達距離は野外の見通しのあるところで100m、見通しのない室内で30mと言われている（900Mhz帯を使うXbee-Proという上位チップは1500mだそうだ)。

　電力ロガーは1年前、商用電源制御をLANでやったとき、レーザープリンターの電力量を調べるため、AC電流センサーを買ったときから計画しているものである。環境問題は最近の流行りで、IT業界もグリーンITなどとお先棒を担ぐ人たちもいて、当研究所は実は苦々しく思っているのだが、表向きは無関心でいるわけにはいかない。その手前、自宅の消費電力量くらい正確に把握しておく必要がある。

　配電盤が台所の裏と言う水気の多いところなので、センサーだけをそこに置きデータの蓄積や制御は別のところでやろうと考えた。制御・記録ボードを置く階が違うのでXbeeで届くか心配だったが、無線LANを使うほどおおげさなものでもないし、ここはやはり最近評判のXbeeを試してみたい。

　電子工作は、何でも良いから目的のあるものを作ることにしている。工作のためだけの工作というのはやっぱり何か空しい。無理なこじつけでも良いから大義名分が必要だと思っている。Xbeeを動かすだけでは物足りない。変なところに美学がある。それに目的があると、その対象技術の理解はないときより遥かに高まる。要件を満たそうと工夫するからだ。さらに、苦労して自分の作ったものが少しでも人の役に立ったり、面白かったと言ってもらえれば、もうこれ以上の満足はない。人間と言うのはひとりで生きていけないのだ。

　先日、「秩父山中 花のあとさき　ムツばあさんのいない春」というNHKの番組を見て、えらく感動した。限界集落と呼ばれる過疎の秩父の山中でもう耕さなくなった段々畑に花の木を植え続けてこのあいだ亡くなった80才のおばあさんの淡々とした生活を記録しただけの番組なのだけど、おばあさんの顔が良い。誰かが花を見て喜んでくれることだけが目的なのだが、人生の生きがいなんてこんなものなのだろう。気持ちが純粋なのに心が洗われる。

Xbeeにも沢山の種類がある(8/23/09)
　それはとにかくXbeeである。ウェブには沢山の応用記事が出ている。Xbeeでラジコンをやったり、ペットにこれを乗せて所在確認をしたり、ロボットの操縦などに使ったり様々な応用例を見ることが出来る。

　しかし、こうした応用例は殆どが1対1の通信機能を使っているだけで、本来の、Xbee同士の通信ネットワークを構成する応用例が殆どない。Xbeeの最大の特徴であるネットワークの高度な機能とは大きな隔たりがある。その差が違いすぎてどうも良く理解できない。それにセンサーとしてのADコンバーターやデジタルI/Oの使い方が良くわからない。

　もういちど基本的なところから調べてみて、大きな思い違いがあることがわかった。世間で言われる多数のXbeeモジュールが会話し合ってネットワークを形成するシステムは、Zigbeeネットワークと呼ばれ、Xbeeハードウエアとは別のプロダクトであるということである。これには高いライセンス費用を払って、そのソフトを導入しなければならない。

　しかも、今市販されている一番安価なモジュールではZigbeeネットワークを構成できない。市販されているXbeeが何故OEM版と呼ばれているのか何となく理解できた。それでも最近のシリーズ2ではOKになったし、Zigbeeライセンスをとらなくてもメッシュ型のネットワークを組める独自のソフトウエアをいくつかの会社が発表しているようで、この世界も変動が激しいようである。

　今度のアプリケーションは、もちろんこんな大規模なシステムではなく、1対１の通信に使うだけなのだが、どうせ組み込むのなら、単なるシリアル通信の手段でなく、ネットワークと行かなくても、徹底した省電力仕様にするとか、操作性の良いロガーにするとか、何か工夫をしてみたい。調べたところでは、Xbeeの省電力機能は定期的なsleep機能しかなさそうだが、この機能だけでは管理が大変だ。センサー側をXbeeだけにするのでなく、RTCを組み込んだCPUチップを載せて全体を管理するという方法も考えられる。

　こうした仕様をあれこれ考えるのがまた楽しい。技術的可能性、自分の能力、要求仕様とのバランスを考えながら、少しづつ具体的にしていく。これが電子工作の醍醐味だ。

あっけなくループバックテストに成功(8/25/09)
　Xbeeの動作テストは変換基板が出来てからと考えていたが、具体的な設計を考え始めると気持ちが高まってきて待ちきれなくなり、バラックで2つのXbeeモジュールのセットを組み、ループバックテストをしてみることにした。 そもそも測ろうとしている台所の配電盤とPCルームとのあいだで通信が出来なければ話にならない。

　配線は至極簡単で、親側はブレッドボードのUSB-UARTモジュールに送信（DO)と受信（DI)線をつなぐだけ。子機はもっと簡単で送受信ピンをジャンパーするだけである。あとはそれぞれVccとGND、親側はUSB-UARTモジュール(秋月)から出ている3.3VがVccで、子機は名刺入れのケースに電池フォルダーに入れた単三電池2つがVccである。

　ATコマンドのインターフェースを持っているというので、TeraTermを立ち上げて、まず親機だけでテストする。昔懐かしい+++でコマンドモードに入るというモデムのATインターフェースだ。問題なく動いた。

　サイトの解説によれば、自分のところのアドレスを指定し、送信アドレスを相手のアドレスにすると、1対1の通信が成立すると言うので、一方を1111他方を2222としてそれぞれセットアップしようとした。

　+++の有効時間が短くコマンドを立て続けに入れていかないと、いちいち+++を入れる必要があって忙しい。ところがそのうち、+++に反応しなくなった。電源は入っているし、ターミナルもおかしくない。始めはもうこわれたのかと少し心配したが、どうもあまり何度も+++でコマンドモードにすると暫くお休みするという仕様があったような気がする。

　ターミナルモードのセットアップでは効率が悪いので、サイトの解説どおり、開発元からX-CTUというユーティリティをダウンロードする。最近は、このX-CTUの解説をしてくれているサイトがいくつかあるのでセットアップは容易である。自アドレスと送信相手アドレスをユーティリティで定義する。このユーティリティにはループバックテストをするアプリケーションも付いている。

まず、これでテスト開始。おおう、始まった、始まった。

　速度をデフォルトの9600bpsから38400kbpsに上げたが、全くエラーはない。調子に乗って居間に通ずる階段の上に持っていく。うむ、扉を閉めたせいか、200回に一回（99.5%)程度タイムアウトになる。さらに次の部屋へ。エラー率は変わらない。いよいよ居間を通り越して、目的の台所の裏の配電盤の横に置く。何だ、エラー率は逆に少なくなった（99.8% 500回に一回）。

　室内では見通し30mというが、木造建築の遮蔽物は電波を透過する様だ。配電盤との直線距離は天井と床板を通して、階段の上より短いからだ。

　調子に乗って、さらに階段を登り、2階にループバックモジュールを上げる。さすがにエラーが多くなる。それでも階段のすぐ上は下の階と見通しがあるので、96%ぐらいは行く。欲張って、更に奥の寝室まで測ってみる。ここからは天井、床板を2重に経由することになる。予測は当たって、ここで突然通信が切れた。電波が階段を通じて飛んでいくとしてその距離はそろそろ20ｍ近くになる。しかし予想以上の到達距離である。

　実験の結果は上々だ。通信距離の不安は全くなくなった。これからのアプリケーションが楽しみになってきた。課題は、電力ロガーのアプリケーション要件を満足させて、いかに省電力でXbeeを動かすかである。今考えている要件は、10秒に一回程度のサンプリング、親側からのロギング開始指示、終了指示、単三電池2本で一年以上、Xbee以外の部品点数を最小限にすること、などである。

　興味がつきない。当面の目的は電力ロガーだが、Xbeeを使いこなせるようになれば色々なことが出来そうで楽しい。今まで偉そうなことは言っているが、本当は役に立つことは二の次で、アマチュアの企画の最大の動機は「面白そう」なことである。

CADソフト EAGLEにはまる

　およそ2 週間ぶりのブログの書き込みである。お盆より一足早く一家で￥1000の高速を利用して車で関西に帰省し墓参りをしてきた。みんな行ったことがないというので帰りに足を伸ばして国宝の姫路城を見に行き東京へ戻ったら、姫路の近くの町で大水が出て沢山の人が亡くなられ、東名高速は帰ってきた次の日に地震で不通になった。間一髪で危機を逃れるアクションスターの気分である（家族は災害を残してきたと気にしているが）。

　そんなことで電子工作は少しお休みしていた。それでも帰ってきてから、またCADソフトにすっかりのめりこんでいた。前記事のタイトルは「EAGLEの落とし穴」で、こんどのタイトルは「EAGLEにはまる」である。ソフトや電子工作の世界で「はまる」というと、このあいだのように落とし穴やバグにつかまって中々問題が解決しないときに使うが、もうひとつの意味として「ゲームにはまる」というように夢中になる時にも使う。

　まさしく今度のEAGLEは2つの意味ではまっている。考えてみたら、これまで鉛筆と消しゴムで紙が真っ黒になるほど苦労して描いていたアートワークがPC上で自由に出来るのだ。下手なゲームよりよほど面白い。

　色々癖はあるが、まともに買えばスタンダードのライセンス版で10万円近くするCADソフトである。さすがに良く出来ている。エラーチェックを厳密にやってくれるのが安心である。Lite版ながら、非営利の目的なら無料で解放してくれるCadSoft社の太っ腹に感心する。事業用のLite版は49ドルである。安い（日本では少し高く1万円前後）。しかしこれは巧妙なマーケッティングである。学生に無料で使わせれば仕事に入った時このソフトの導入を提案する可能性は極めて高い。

　ソフトも使い慣れてくると、癖のある部分も、じゃじゃ馬を乗りこなして得意になるように、使いこなしている快感につながるから人間と言うのは不思議なものである。毎晩遅くまで奮闘した結果、やっとのことでLPCMプレーヤー2号機の基板は、Olimexに発注できるレベルに達した。以下はその作業記録である。

正確なスケールに感動する(8/13/09)
　お盆の帰省を挟んだ作業の結果、2号機の基板設計は予定したすべての部品を載せて配線率が100％になり、配線が終了した。 まだ自分で作った部品のサイズが正確かどうか最終的に確認する必要があるが、電源ソケット代わりのUSBミニジャック、電池とスイッチの接続に使うピンヘッダー、3端子レギュレーターなど残していた部品も全て載った。

　コツがだいぶわかってきた。最初から自動配線にしないことである。VccやGNDなど引き回しの多い配線やアナログ線など、重要な配線は手動で前にすませておく。このあと自動配線を指示すると、基板上下の配線をつなぐビアを開けながらコンピューターが勝手に配線してくれる。

　ここでもEAGLE特有の操作性が悩ませる。エラー状況のデータはエラーリストをクリアしただけでは更新されない。DRC(デザインルールチェック)ボタンで必ずもう一度チェック処理を最初からしなおす必要がある。考えてみたら当たり前のことなのだが、最初は何度配線の位置を変えても、エラーリストからエラーがなくならず頭を抱えていた。

　さらに部品の緒元は、部品を載せた後、変更できる部分と出来ない部分がある。容量や抵抗値は自由に変えられるし、シルク印刷の線の巾などはボードエディターで変更できるが、パッケージの形を変更するのは部品エディターまで戻る必要がある。パッケージデータを変えた後、updateコマンドで基板エディターのところまで変更してくれるのは嬉しいが、時々前のデータが残っていたり(tNameが2重になる）、ひとつのシンボルデータに何種類もパッケージがある部品（コンデンサーなど）は、変更した部品とは別の部品までパッケージが変わってしまったりして一筋縄ではいかない。

　抵抗をすべて縦置きにしてスペースを稼ぎ、コンデンサーをノギスで測りなおして正確な小さなパッケージデータにしたりして、部品をつめ、間を配線していく。基板の端やドリル穴の近くは配線禁止区域が思ったより広くなかなか許してもらえない。

　何とかNo Errorになったので、出来た基板を印刷する。スケールは１。実際の部品を印刷した実体図の上に載せてみる。おおお、正確だ。これは素晴らしい。表面実装のSDカードソケットとUSBミニジャックのピンがピタリと納まっている。感動ものである。2連ボリュウムのピッチ違いもこれで確認できた。部品エディターを開いて、ピッチを正確な2ミリピッチにする。ミリとmil(1/1000インチ）の換算がややこしい。印刷を切り抜いてケースに入れる。ちゃんとサイズが合っている。1号機と並べてみると、そのコンパクトさが実感できる。

　LCDパネルがケースと、さらにLCDのピンヘッダーが裏の電池フォルダーとぶつかることがわかった。細かく位置調整して、LCDパネルをボードに合わせる。少し位置を変えるだけであちこちがclearanceエラーになるのでそう簡単ではない。しかしEAGLEにだいぶ慣れてきて、変更が早くなった。ときどきripupコマンドが動きすぎて全部の配線をはがしてしまい、面食らうが、これもripupするところを慎重に選べば必要なところだけはがれてくれる。

  3回、ファイルをセーブしてスナップショットを作りながら、微調整する。ほぼ望みの配置と配線を終えた。それにしても、このアートワークは際限がない。やり始めると時間のたつのを完全に忘れて夢中になってしまう。配線も良く見ると自動配線は無駄が多い。電源やアナログの部分の結線は太くしたいし、ビアを少なくする方法が見つかることもある。見るたびに不満なところが出てくる。きりがない。

  最初はとんでもなく遠い道に見えたが、何とかなるものである。印刷した実体図を見て感慨にふける。2層でも結構な配線量だ(48×74ミリ  パッド数132　ドリル数156）。手配線では苦労しただろう。あとはOlimexへの注文のための処理を残すだけとなった。

最初はStopMaskエラーが900以上（8/17/09)
　出来た、出来たと得意になっていた鼻は、しかし次の作業ステップで簡単にへし折られた。Olimexに発注する制限事項をこのウェブサイト（ここは詳しくておすすめ）でチェックし、所定のレイヤーを指定したところ、何とStopMaskエラーというのが917個もあらわれたのである。

　レジストを塗らないハンダ面にシルク印刷をしているよというエラーなのだが、標準ライブラリの部品はほとんどが元からそうなっている。こちらで置いた部品名などがパッドにかぶっているところはむしろ少ない。部品ライブラリを全部直さなくてはならない。すぐに何とかなるものではない。気の遠くなる話だ。あわててウェブに助けを請う。

　ウェブには余り情報はなかったが、EAGLEのバージョン5からの問題なのだそうだ。単にシルク印刷がそこにされないだけで、Olimexがこれで発注を拒否したり追加料金をとったりすることはないように思われるが、確証はない。

　しかし、エラーがあるままOlimexに発注するのは何となく気分が悪い。幸い、Olimexは8月一杯休みをとるので発注できるのは9月になってからだ。ひとつひとつの部品ライブラリのシルク印刷の部分を直して行く必要があるが、時間はたっぷりある。それにこういう手仕事は嫌いではない。

　今日も真夏の炎天下でテニスをして体はばてているのだが、気がついてみると、PCの前で、コツコツ、部品をとりだしてはシルク印刷のレイヤーを分解してエラーを無くす作業をしている。 標準ライブラリに入っているパッケージの中には既にStopMaskエラーを考慮したシルク(tPlace)になっていてパッドを横切るラインはtDocuという別のレイヤーになっているパッケージがあったりして混乱する。どうも混在しているようだ。

　しかも部品ライブラリとOlimex指定ルールの実際の基板とではStopMaskの大きさが違うので部品エディターの段階では確認できない。ひとつ部品を更新しては、実際のボードエディターでエラーをチェックしていかなければならない。結構大変である。

　それでも、部品をとりかえてはDRC（デザインルールチェック）をかけ、少しづつでもエラーが少なくなっていくのを確認していくのは楽しみなものである。それに、この作業の過程でレイヤーの構造がかなり理解できた。tDocuとtPlaceの2つのレイヤーを持っている部品は、始めこれが何のためかさっぱりわからなかったのだが、この作業のおかげで完全にその目的が理解できた。

　要領がわかってくると作業のスピードは速くなる。　900あまりと言う気の遠くなるエラー数は、2日余りで100前後に減らすことが出来、今日（8/17)、遂に0になった。万歳！　これで安心してOlimexに基板制作を発注することが出来る。

　調子に乗って、このあいだからの懸案、Xbeeの2ミリピッチの変換基板もついでに作ってOlimexに発注することにする。160×100のOlimexの発注基板は、4分割して3枚をLPCMプレーヤー基板、残りの1枚を2分割して、Xbeeのピッチ変換基板2枚にする予定だ。

CADソフト EAGLEの落としあな

　この一週間、暇さえあればEAGLEと格闘していた。きのうやっと充電回路分を除いたLPCMプレーヤー2号機の自動配線のところまで進み、少し目鼻がついてきたので、忘れないうちにこれまでの作業記録を残しておくことにする。自動配線の達成率は最初50％を割っていたが、昨日の段階で83％まで上がった。いやそれにしてもプリント基板の道は遠い。

　この世界は、これまでとは、また全く違う世界である。ガーバーデータ、CAMプロセッサー、ネットリスト、ドリルデータなどという耳慣れない単語が続出する。熱心に説明されていることが何故重要なのか読んでいて理解できない。同じ電子工作の世界なのにまた右も左もわからない状態に放り込まれる。

　恐らく職業でこの世界に飛び込めば、どこかに特化し、これほど混乱することはないのかもしれないが、こちらはアマチュアである。AVRから始まってアナログオペアンプ、ARM、JTAG、FPGA、組み込みLinuxなど、興味に任せて色々なところに手を出しすぎている。好奇心の強さでは人に負けないつもりだが、同じ電子工作、組み込みコンピューターの世界と言ってもその余りの違いにただ驚くばかりである。

　プリント基板技術はこれらの世界のまさしく基盤を支えるものだけど、これはこれで世界が全く違うし、奥が深い（ネットでは精密加工や工作技術の人のサイトが多い）。今、世の中に溢れている携帯電話、パソコンなどの電子機器のプリント基板は16層が当たり前に使われていると言う。気の遠くなるような技術だが、アマチュアでも4層まで作る人がいる。こちらは2層で精一杯だが、それでも知らなければならないことが膨大にある。

　プリント基板の制作はAVRマイコンを触り始めたころから横目でちらちら眺めていたが、ChaNさんから教わったUEW線の手配線が思いのほか調子が良いので手を出す機会がなかった。しかし、手配線では同じものを複数作るのはきついし、師匠のように汎用基板上に0.5ミリピッチの表面実装ICをすべてUEW線で半田付けしてしまうと言うような芸術的レベルにはとても届かない。それに何と言ってもプリント基板に実装された電子機器は美しい。見ているだけでわくわくしてくる。

　先月、複数台の基板を作らなければならないことになって、ついに参考書を買ってCADソフトの定番EAGLEの勉強をし始めた。すでにいくつかCADソフトを使っていたので簡単そうに見えたが、実際の部品のライブラリを作り始めて早々に頓挫した。とんでもなく難しいのである。

　悪戦苦闘の結果、回路図から自動配線が出来るまでになった。作業的には少し一段落したので、ここでこれまでに経験したEAGLEの落とし穴とその解決法について整理しておくことにする。アマゾンで酷評されていた（自分はそれほどでもないと思うが）最初に買った参考書は、結局、落とし穴からの脱出には殆ど役に立たなかった。

　ただ、これから述べるEAGLEの落とし穴とは、あくまでもCADの素人がEAGLEを使うに当たって、はまりこんだ問題点であり、ソフトそのものの問題点ではないことをあらかじめお断りしておく。CADソフトの歴史は古く、多くの経験、実績によって現在の姿があるわけで、経験者から見れば、がた老AVR研究所のあげる問題点は的外れな指摘かもしれないからである。しかし、知らなければ、殆どの人がはまることになることは確信する。なお、対象はEAGLEの最新バージョン5.6.0の話である。

回路図の操作は簡単だが、部品エディターはとても癖があって難しい(7/30/09)
　EAGLEの中で部品は、回路図を作る時に使うシンボルデータと、その外観とピン配置を規定して、基板に部品を配置し、配線するときのためのパッケージデータ、それにこの2つを組み合わせたディバイスデータに分かれる。同じ仕様で外観だけ違う部品があるので、この構造はとても合理的だ。回路図で部品と部品をつなぐ配線操作も難しくない。部品を動かすと配線した線がちゃんとついてくる。フリーのCADソフトに較べれば確かにレベルが高い。ここまでは快調だった。

　部品データを収容するライブラリが用意されている。しかし、部品ライブラリが巨大で探すのが大変である。日本でおなじみの部品が中々見つからない。検索機能が用意されているが、正規表現的に厳密なのでなかなかヒットしない。（例えば、SOT23-5を検索するとき、両側に*をつけて *SOT23-5*としないと、SOT23-5を含むテキストにあたらない）。

　ここにない部品は、自分でこれまでのデータを組み合わせたりして作ることになるが、この部品エディターが難物なのである。エディターの操作性もあるが、一番の原因は、ライブラリの構造からくるものである。

・ライブラリからパーツを抜き出すことが難しい
　ライブラリはひとつのファイルで構成されているので、部品データはファイルとして物理的に分離できない。それぞれの部品データが物理的なファイルに分かれていれば、ライブラリの管理はとても楽になるが、それが出来ないため、一旦新しい空のライブラリを作った後、そこへデータをcopyする形をとらなければならない。そのとき、必ずターゲットのライブラリを部品（ライブラリ）エディターで開いておかないとcopyは出来ない。ここでまずはまる。

　新しい部品データを作るとき、いちから作ることは殆どない。既存のシンボルやパッケージデータを流用することが多い。しかし、あとで色々編集できるようにとディバイスデータの形で既存の部品を自分のライブラリに持ってくるとえらい目にあう。ディバイスデータについてくるシンボルデータは簡単に消去したり編集できないからだ。パッケージデータとつながってディバイスを形成しているため、ちょっと操作をするとすぐ文句を言われて先に進めない。第一、エディターは、ディバイスデータを開いた時はシンボルとパッケージのピン接続をする以外ほとんど何も出来ない。

　それではシンボルデータだけ持ってこようとすると、これが出来ない。EAGLEのコントロールパネルでライブラリを開きコピー（copy to library)できるのは、ディバイスデータと、パッケージデータだけなのである。

　既存のシンボルデータを複製して新しい部品のシンボルにするには、まず、既存のデータの入っているライブラリをエディターで開き、欲しいシンボルデータをペーストバッファーに入れた後、別のターゲットのライブラリでエディターを開き直し、newで新しい名前を定義して空のシンボルデータを作って、そこへペーストするという回りくどい方法をとる必要がある。

　この方法と下の操作をこのウェブで教えられて、始めて部品ライブラリの操作が自由に出来るようになった。それまでは全く手も足も出なかった。

・カット＆ペーストとはコピー＆ペーストのこと
　EAGLEの操作は、GUIと言っても少しコンセプトが古く、「オブジェクトを決める」「それに対する操作を選ぶ」「実行する」という順ではなく、コマンドアイコンを先にクリックして操作の種類を決めたあと、次にその対象を選ぶという、これまでのキャラクタディスプレイのコマンドフォーマットを踏襲した形になっている。

　慣れればそう問題ではないが、それより一番の問題は、カット＆ペーストである。EAGLEのコピーコマンドは、単に回路図上で同じオブジェクトを増やすだけで、ペーストバッファーにデータは入らない。ペーストバッファーに入れるためにはカットする必要がある。EAGLEではカットしても原データはなくならない。カット＆ペーストではなく、コピー＆ペーストである。これを知らなくて何度「ペーストバッファーが空だよ」と怒られたことか。

　ある部品のデータを別の部品に複製するには、まずコピーしたいシンボルまたはパッケージデータを開き、持って行きたい部分をグループ設定してから、その範囲内（ハイライトされる）で、カットコマンドを実行し（グループの上を一回クリックする。このとき画面は全く変化しない）、次にターゲットの部品を開き直し（前の画面はなくなる）、そこでペーストコマンドをクリック（実行）すると始めてさっきコピーした部品がカーソルとともに画面にあらわれる。部品エディターが複数のウィンドウを開けないためである。この操作は知っていなければ手品に近い操作である。

・簡単に消去が出来ない
　ディバイスデータは、シンボルデータとパッケージデータで構成されるので、前にも書いたようにディバイスデータを簡単に変更することはできない。シンボルデータだけを消すことは出来ない。一旦ディバイスを開き、回路図上のピン（シンボルデータ内）と実際のパッケージのピンとの対応を全て切らないとディバイスデータに使われているシンボルデータは消す（変更する）ことが出来ない。

　パッケージデータもディバイスデータとつながっているので消去しようとすると怒られる。パッケージは色々な部品（ディバイス）に使われているので、ライブラリを大きくすると大変である。しかも、ライブラリ上の部品データを消去するには、アイコンやメニューにコマンドがなくULPと言われるユーザープログラムをテキストコマンドエリアから入力する必要がある。恐らくEAGLEはテキストコマンドで操作するインターフェースから進化してきたCADなのだろう。その性格が色濃く残っている。

・位置決めが難しい
　オブジェクトの移動がグリッド単位でしかできない。グリッドを細かくすれば、その単位で移動できるが、今度はグリッドが細かくなりすぎて、これを数えるのが難しい。配線図のときは良いが、正確な位置決めが必要なパッケージデータの編集ではこれが非常にネックになる。さらに、一旦細かい位置で位置ぎめしてしまうとグリッドを大きくしたとき、大きくしたグリッド単位でしか動いてくれない（Altキーを押したまま動かすとある程度自由に動かせることがあとでわかった）。

　この問題の解決は、位置（mark)コマンドを活用することである。markコマンドで基準点にマークを置き、そのあとはメニューバーの下の情報エリアに表示される座標を読み取っていくと正確な位置にオブジェクトを置くことができる。もちろんそのときはグリッドを細かくしておかなければ望みのところには止まってくれない。

つながっているように見えても接続されていない(8/3/09)
　部品エディターにやっと慣れて、ライブラリにない部品の登録が進んだ。SDカードスロットや、2連の可変抵抗器、DAコンバータなどである。秋月などで売られている基板用ステレオフォンジャックは、標準ライブラリの中にたまたま同じものを見つけた。

　con-lumberg.lbrというライブラリにある1503_09という部品がそれで、外形はともかくフットプリント（基板上のピンの位置）が全く同じだったのでこれを使う。

　電池の充電回路部を除いた(入るかどうかわからないため）回路図が完成した。ミニLCDの部品データはピンヘッダーですませる。いよいよ基板配線である。ボードエディターを開く。おおお、ratsnestという黄色い空中配線でつながれた部品が画面の隅にひとかたまりになって並んだ。部品の移動は回路図エディターと全く同様の操作なので楽だ。部品を所定の位置に運ぶ、配線も同時に動いてくる。素晴らしい。おやあ、2連可変抵抗器の大きさが大分違うぞ。どうもmilとmmの換算を間違えたらしい。

　もう一度部品エディターまで戻って、実体をノギスで測り直し、正確な外形に修正する。ついでにSDカードスロットもヒロセのサイトから実体図のPDFを落とし測りなおす。EAGLEのすごいところは、変更した部品を回路図で更新すると、ボードエディターの外形まで替わっていることだ。何度も測りなおしたが、このへんは実際に基板を発注する時に、もう一度確認しておく必要があるだろう。部品ライブラリとしての公開は、ちゃんとした基板になってからでないと危ない。

　想定した基板サイズ（48×74ミリ）上に部品を載せていく。うーむ、少し厳しい。そうか抵抗やコンデンサーが実体より少し大きすぎるようだ（パッケージを良い加減に選んだ）。これを直せば入るかもしれない。それより気になるのは、ratsnestになっていない(未配線)部品が多いことである。念のためERCコマンドでエラーを見てみる。

　何と言うことだ、100近いエラーが出て、ratsnestのないところはすべてunconnectedになっている。EAGLEの鉄則は「基板エディターでは変えない。すべて回路図から修正する」なので、回路図エディターを確認する。ちゃんと配線されている。しかし、ネットを確認するコマンドを入れると、確かに色が変わらず配線されていない。拡大してみてもちゃんとピンと配線はつながっている。

　良くわからない。サイトによると「wireは使うなnetで配線せよ」とあるのでnetでつなぎなおすが変わらない。原因を考えあぐねていたとき、たまたまmoveコマンドで部品を移動させたとき、つながっていないところは配線が切れて離れることを発見した。これだ。

　接合は厳密に座標が合わないと実行されないようだ。それを試すのは、マウスで部品をつかんで動かしてみる。何度か動かしているうちに接合がされる。これは良い方法をみつけた。

　overlapしているという警告も、この方法で原因を見つけることができる。配線は終端でどうしても余分なクリックをして枝が出来ていることが多いが微小なのでなかなか見つけられない。これも部品を移動させると、その枝が拡大されて一目瞭然になる。拡大されたところで不要な枝を消去すると警告はなくなる。

　このノウハウを見つけてからは早かった。100近くあったエラーは、ピンの未配線や、Vccに違う名前（Vddなど）のピンを配線していることの警告だけになり、ratsnestもすべての部品に出るようになった。

　自動配線を試してみる。何回かコンピューターが試行錯誤したあと自動配線が終了する。うむ、達成率は83%とこれまでより格段に上がった。そりゃそうだ2割近い配線が未配線だったのだ。

2号機開発がなかなか進まない

　このところ電子工作以外のことに時間をとられたこともあるが、LPCMプレーヤーの2号機の開発は殆ど進展していない。気分が乗るときは夢中になるのだが、波がある。Olimexの休みの話を聞いて出鼻をくじかれたのと、EAGLEのパーツ作りが思うように行かず、ちょっとスランプ状態に入ったようだ。

　それでも、手を動かしていないと落ち着かない性分になってしまったので、2号機の実装に必要な機能のテストを少しづつやっている。

ソフトパワースイッチの落とし穴(7/23/09)
　擬似コーディングでソフトパワースイッチの骨格はできた。しかし、このときに使うsleepのパワーダウンモード（セーブモードよりもっと節電）を実際に動かしたことはまだ一度もない。がた老AVR研究所では、初期の頃の電池からDCアダプターを電源に使うようになって、節電に余り気を使わないようになっていた。これまで使っていたsleepはすべてアイドルモードである。正式に組み込む前にこのパワーダウンモードが動くか確かめておいたほうが良い。

　最近のAVRプロセッサーで名前の末尾がPで終わるチップは、Pがピコワットの頭文字であるように、これまで以上の省電力をうたっている。データシートを見てみるとMega168Pのパワーダウンモード時の消費電流は何と0.1μAである。ボタン電池あたりの自己放電電流の1/10である。これなら大威張りでソフトパワースイッチに出来るというものだ。

　ソフトパワースイッチを組み込む対象のLPCMプレーヤーはブレッドボード上に一式残っているが、いきなり入れて混乱するのを避け、実装は直近のミニLCDのテストプログラムで行うことにした。

　データシートには丁寧な解説があるし、そんなに難しい処理があるわけでもない。最初は気楽に考えて実装に入った。しかし、考えていたことを実際に動くようにすることはやっぱりそう簡単ではなかった。しかも大きな考え落ちを見つけて気分が重い。

　周辺のタイマーも全て止まっているパワーダウンモードからCPUが目覚めるのは外部割込みだけである。外部割込みは周波数カウンターや、初期のTinyなどで何度も経験済みだ。これまでのプログラムからコードをとりだし、レジスターをMega168用に取り替える。鼻歌交じりでブレッドボードにタクトスイッチをつける。ものの1時間もかからない。簡単に動くと思った。しかし、これが動かないのである。

　仕方がない。モニターにUARTメッセージを出すステートメントを入れて（いわゆるprintf)デバッグに入る。おやあ、スイッチを押しても割り込みルーチンに処理が来ていないぞ。割込みそのものが起きていない。データシートをもう一度見直す。やれやれ「データシートは穴が開くほど見よ」である。データシートに明記してあった。パワーダウンモードは確かに外部割込みでsleepから目覚めるが、目覚めるのは「外部割込みのレベル割込み」だけなのだ。こちらはスイッチの「立下り」を一生懸命待っていた。

　あわてて割込み条件を「Lowレベル」にする。と、今度は、スイッチが押されている間中割り込みが入り、長押しの時間を測るどころではない。うーむ、困った。まさしく考えたようにコンピューターは動かない。書いたようにしか動かない。

　これで良いのかどうかわからないが、割り込みが来れば、割り込み条件をただちにレベル割り込みから立下り割り込みに換え（このあとの制御に使うため）、割り込みリクエストをクリアし、次のパワーダウンsleepに入る前にもう一度レベル割込みに戻すコードを付け加える。よーし、2秒長押しで電源が入った。今度は電源断のルーチンだ。でもその前にどれくらいの消費電流になっているか調べてみよう。テスターを取り出す。

　まず実行時で6ｍA程度。電源をOFF/ONしパワーダウンモードにする。何い、パワーダウンしても3ｍA以上流れているぞ、LEDか？いやそんなものつけていない。LCDか。しまった。CPUはパワーダウンしてもLCDの電源は入ったままだ。これはいかん。こいつの電源もCPUで制御しないとソフトパワースイッチにならない。これは大きな考え落ちだ。

　それはとにかく、LCDをブレッドボードからはずす。何と、電流が変わらない。この電流はLCDではない。プルアップ抵抗？まさか。はずしてみる。変化なし。とすると、あとはPCとつないでいるISPケーブルしかない。このテストプログラムは、ISPを利用したUARTをモニターにしている。ええー、こんなところに電流が流れるの？PCの端末プログラムは動かしていない。

　電流の主はやっぱりISPケーブルだった。こいつをはずすと、150μAに激減した。LCDをはずすと0.4μA。やれやれやっとスペック（0.1μA)に近い消費電流に落ちた。あとはプルダウン抵抗を通してCPUやLCDに流れ込む電流だろう。ミニLCDの消費電流の150μAは優秀だけど、これを流しっぱなしにするわけにはいかない。

　LCDの電源をパワーダウンモードと同時に切る必要が出てきた。いくらCPUがμA以下でも、周辺機器に150μAも流れれば何にもならない。FETか何かで切る必要がある。しかし、今度の2号機はもうスペースがない。やっぱりスライドスイッチを使うのか。

　次の日、電源断のロジックも入れてソフトパワースイッチのテストプログラムは完動した。2号機にソフトパワースイッチを実装するかは微妙になってきた。周辺機器の電源制御は結構厄介で、下手な制御をすると、予期しないところに電流が流れて誤動作したり、ひどいときにはCPUそのものをこわしてしまったりする（どちらも経験済みだ）。スライドスイッチはケースの上蓋や、余裕のある半田面のケース側につけようと思えばつけられる。

　それに「でんし研」のTADさんからのコメントで、プリント基板発注のOlimexが8月一杯夏休みで注文を受け付けてくれないということがわかった。これは計画を大幅に作り直す必要がでてきた。流れはスライドスイッチを入れた手配線版を実装する方向に傾きつつある。

いつのまにか動いたミニLCD(7/24/09)
　2号機のLCDの換装のテストをした。ブレッドボードにあるLPCMプレーヤーから秋月の「超小型」LCDとDC-DCコンバータをはずし、さらに小さいストロベリーリナックスのミニLCDをセットする。ハードはいたって簡単。インタフェースはI2Cなので、これまでのパラレルのデータ4本、制御線3本、それに電源、グランド合わせて9本のケーブルに対して、信号線2本、電源も含めて4本をつなぐだけである。ずいぶんすっきりした。

　ソフトのほうは先に公開したミニLCDのライブラリを入れて、メインのLCD関数をミニLCDのものに換える。たいした手間ではない。テストに入る。全く反応なし。まあ、こういうのには慣れている。コードをもう一度見直す。どこも間違っていない。それでも動かない。段々頭に血が昇ってくる。いかん、いかん。落ち着いて最初から見直そう。

　基本的なところからチェック。電源は入っている。暴走はしていない。スイッチは反応して音楽は通常に演奏する。それではと、こういうときのためのUARTを復活させる。ありゃ、やっぱり初期化でエラーが出ている。ロジアナを持ち出す。いやちゃんとI2Cは動いている。

　こうなったらデバッグステートメントてんこもりだ。I2CのsendコマンドにUARTの出力をぶちこむ。盛大に送信データとリターンコードがPCに流れる。おやあ、正常終了だぞ。あ、画面が出ている。何も他に変えていない。UARTでI2Cコマンドのタイミングが遅くなったので動いたのか。デバグステートメントをはずしてみる。何と何と、正常に表示するではないか。原因がわからずに動いてしまった。気分が悪い。

　日を空けて原因究明にとりかかる。このライブラリは公開しているので責任がある。いつのまにか動くということは、また、いつのまにか動かなくなるということを意味する。放っておくわけにはいかない。自慢にもならないが、こういうときの粘着質には人には負けない自信がある。気分を落ち着けて、動くまでのひとつひとつの工程を思い出し、手順を戻してテストしていった。

　その結果、LCDのリセットピンを浮かしたまま、リセットをしないモードで動かすと、LCDが動かなくなることを確かめた。リセットをしないのなら、このピンは確実にHigh（Vcc直結)にしておく必要があるが、最初の頃は確かに何も接続していなかった。

　UARTを入れたりするデバッグの最中、リセットピンもついでに配線してリセットありでコンパイルした記憶がある。このときはUARTの初期化を間違えて端末にメッセージが出なかったため、すぐコンパイルし直したが、LCDの方は確認していなかった。

　恐らくこのときに動いたのだろう。リセットをするか、リセットピンをinactive(High)にしてどちらも動作することを確かめ問題は解決した。いやいや慌てることはデバッグの一番の敵である。

　ミニLCDの印象である。文字は小さいが視認性は悪くない。1行目のアイコン表示のところに何も表示されないので、少し間が抜けているが、アンテナや電池などのアイコンはどうも今回のプレーヤーには役に立ちそうにない。採用は見送ることにする。

scan_files( )の機能を落とす(7/27/09)
　機嫌よく、ブレッドボードの2号機用のLPCMプレーヤーを鳴らしてテストするうち、1枚のSDカードで暴走しシステムリセットがかかるようになった。TinyFatFSでは問題がなかったカードである。今度のFatFSのバージョンアップによる不具合であることは明らかだ。

　しかし、このカードで動かなくなる原因には心当たりがある。ディレクトリがあるカードである。現在のLPCMプレーヤーはルートディレクトリ上のWAVファイルしか演奏対象にせず、ディレクトリ以下のファイルは無視しているが、レジューム機能のときにSDカードを特定するため、ファイルサイズとファイル数をChaNさんのFatFSの内部関数scan_files( )を使ってサブディレクトリ下のファイルまで全部数え上げている。

　scan_files( )の仕様が変わったのだろうか。ディレクトリのアトリビュートにロングファイルネームのオプションが入ったのが気になる。ソースコードを調べる。全く変わっていない。UARTを入れてシステムリセットがかかる原因を調べていく。

　予想通り、scan_filesで暴走していることが確かめられた。UARTをさらに奥深く入れて検証する。おやあ、このディレクトリはさらに下にまだディレクトリを持っているぞ。あああ、わかった。スタック領域がSRAMを潰しているのが原因にちがいない。このscan_files(  )は自分で自分を呼ぶ、再帰構造になっており、これは大量のスタックデータを消費する。

　TinyFatFSからFatFSに上げてSRAMが残り少なくなっていた（90％）のが気になっていたが、やっぱり駄目だったか。試しに、このディレクトリの構造を一段少なくすると暴走しなくなった。これが原因であることは間違いない。

　ルートディレクトリのファイルしか見ていないのに、scan_files( )で全部のファイルを調べる必要はない。過剰品質である。しかし、見事な美しい作りなのでオリジナルを生かしたままにしておいたのが仇になった。泣く泣く、scan_files( )に手を入れて、ルートディレクトリだけのファイルを数えることにする。これでどんなに複雑なディレクトリ構造のカードでも暴走はしないはずである。

　2号機に向けてのソフト開発はこれで一段落したようだ。今回はソフトパワースイッチは実装を見送ることにする。残るは、手配線に着手するか、EAGLEをさらに攻めるかである。

　上記トラブルは、ディレクトリのないSDカードでは発生しません。もしディレクトリがあるSDカードで、ディレクトリの階層が深い（3段以上）ときは、メインファイル（SDPCM328V3.ｃ)の193行目にある、scan_files(char* path)の以下のステートメント４行をコメントアウトしてください。これでscan_filesはルート上のファイル、ディレクトリしか数えませんが実用上は全く問題ありません。

            if (finfo.fattrib & AM_DIR) {
                acc_dirs++;
//                *(path+i) = '/'; strcpy(path+i+1, &finfo.fname[0]);
//                res = scan_files(path);
//                *(path+i) = '\0';
//                if (res != FR_OK) break;
                                          } else { .........

（以上）

プリント基板の道は遠い

EAGLEのバージョンが古かった(7/18/09)
　プリント基板CADの勉強を参考書で始めている。    レイトレーシングで有名なフリーのPOV-Rayを使って3D CADも出来るようだ。素晴らしくきれいにレンダリングされた基板の写真が口絵にある(添付の画像は著作権のため本家のもの）。これはすごい。20年前なら一部の大企業が莫大な開発費用をかけ、大型機でやっとのことで実現してきたことが、こんなアマチュアの世界でも可能になった。良い時代になったものだ。

　今度のLPCMプレーヤーの回路図を入力し始める。これまでのCADとはユーザーインターフェースが違うが基本的なことは同じなので、そうまごつく事はない。moveで、ちゃんと結線を維持したまま移動できる。機能はフリーウエアのCADに較べると格段に高そうだ。ただ、回路図を入れただけで、自動配線までやらせるためには、これまでのように気楽に部品を設定し、そこをつなぐだけというわけにはいかない。部品の諸元を厳密に決めているライブラリがしっかり出来ていないとそこまで行き着けない。

　しかし、ウェブの解説ページにもあるように、EAGLEのライブラリはヨーロッパ主体で、日本のおなじみの部品が標準ライブラリに少ない。ウェブで検索してもなかなか適当なのが見つからない。ICはともかく、SDカードのソケット、基板用のステレオフォンジャック、平型の2連可変抵抗器などは、どうも全部自分で作るしかないようだ。

　メインのIC、Mega328(168)すらAtmelのライブラリに入っていない。おかしいな、これもないのかとウェブで探す。やっと見つけてインストールしてみたら、古いバージョンには入らないと怒られた。ええー、この参考書そんなに古いのか。去年(2008年）のはずだぞ。奥付をもう一度確かめる。しまった。初版は2004年で5年も前だ。去年と思ったのは第三版の発行日付だった。

　参考書のEAGLEのバージョンは4.11r2である。あわてて、ウェブで最新バージョンを確かめる。うわあ、5.60だ。違いすぎる。去年3版を出したのなら少しはこのあたりを補足しておいて欲しかった。良く確かめて参考書を買うんだった。後の祭り。

　進歩の早いこの世界では、参考書はよほど気をつけて買わないとこういうことが起きる。全体的な流れを掴むために参考書を使うのだが、こんなにバージョンが大きく変わってしまうと個々の細かい説明が違ってしまって結局それすら出来なくなる恐れがある。そうならないことを祈りたい。

　慌てて、製造元のCadSoftのサイトに行き、最新バージョン(25MBあまり）をダウンロードする。旧版を消し、インストールしなおす。Atmelのライブラリを見る。ちゃんとMegaの新シリーズ（Mega8系）のパーツが揃っていた。別のサイトからダウンロードしたMega168のパーツも無事認識された。

　配線は出来ても、自動レイアウト、自動配線(Autoroute)まで行くには、今度のLPCMプレーヤーにかなりなライブラリを自分で登録する必要がある。まだ相当時間がかかりそうだ。基板の発注は、これも定番のブルガリアのOlimex(この前のARM-USB-TINYインタフェースを買ったところ）に決めてあるが、発注して基板が送られてくるのまで2週間はかかるという。

　一方、EAGLEの勉強と並行して、ケースの工作の方は順調に進み、ケース上蓋とタクトスイッチ、LCDの間の高さ調整（タクトスイッチはリード線を延ばしてOK。LCDはピンソケットでぴったりOK）、基板取り付けポストの固定も済んだ。レイアウトをもう一度検討しなおし、右利きの人が片手で持って、音量調整と演奏ボタンが親指で楽に出来るようにした（自分は左利きだが）。部品を載せて全体を確かめる。うむ、何とか入った。汎用基板で作る準備は整った。

　今、迷っている。早く作りたいという気持ちと、ここで実装を始めれば、それに夢中になって、プリント基板の方が全く進まなくなる懸念とが交錯している。EAGLEの1枚のフリー基板で2セットとれるので（50×40 2枚)、3台作るなら1台足らない。手配線版が無駄になることはないと思うが、プリント基板制作を軌道に乗せる方が先だ。しかし、ケースにきれいに取り付けられたハンダ付けを待つブランクの汎用基板を見ていると誘惑に負けそうになる。

ソフトパワースイッチ検討と新版 LPCMプレーヤーのソース公開(7/21/09)
　ハードはさておき、2号機のソフトウエアの話である。このあいだFatFSを新しいバージョンに上げ、SDHCが読めるようにしたが、ソースコードを公開していなかった。忘れたのではなく、あの時点ではSDHCが動くかどうかを確認していなかったからである。

　BeagleBoardのために8GBのカードはあったが、Ubuntuのシステムが入っていたためこれでテストをするわけにはいかなかった。その後秋葉原に行ったときもう一枚8GBのSDカードを買ってきた(あきばおー￥1550)。ちゃんとしたブランド品のSanDiskだ。いつも不思議に思うのはSDカードの価格である。秋葉原、通販あたりと、家電量販店の価格の差が激しすぎる。数倍あることは珍しくない。保証の差だと言ってしまえばそれまでだが、これまで10枚以上SDカードを買って一度も不良品にあたったことはない。秋葉原でも2週間以内の初期不良には対応する。

　それはともかく、帰って早速テストしてみる。問題なく動作した。￥2000しないこんな小さな8GBカード一枚で、音楽CDが12枚近く入るのだ。良い時代というより、今までの常識が通用しない空恐ろしい時代になったともいえる。

　ソースの公開だが、実は先日、ブログのメールでソース公開の要請を受けた。これまで自分のソースコードが誰かの役に立っているという実感がなかったのだが、こういうメールを頂くと素直に嬉しい。ただ、こんどのLPCMプレーヤーのVccは3.3Vで、メーカーが保証する規格外の20Mhzのクロック（メーカーでは13.3Mhzまで)で動かしている。全く問題なく動いているとはいえ、規格外であることは間違いない。

　もし、遊び以外で使う時は、Vccを5Vに上げ、SDカードとの間はレベルシフターで接続することをお勧めする。まあ私のソースコードも無保証だから、あまり形式にこだわることはないのかもしれない。

　2号機向けのソフトは、これにミニLCDの実装と、スイッチの長押しで電源を入れるソフトパワースイッチの実装が残っている。これを含めてソースを公開しようと考えていたが、早めにこれだけで公開することにした。         

 AVRStudioのフォルダーになっています。最初のコンパイルで警告が出ますが無視して大丈夫です。

「SDPCM328V3.lzh」をダウンロード

　ソフトパワースイッチもちょっと難航している。自分なりの構想は出来ているのだが、他の人はどうしているのだろう。気になってウェブをあちこち探しているのだが、何処にもロジックを解説しているところがない。

　考えてみると、結構難しい。もし、どこかでハングして電源が切れなくなったら、バッテリーをはずすなどの作業をしなければ、あっというまに電池を消耗してしまう。特に今回は過放電に敏感なリチウム電池なので心配である。徹底したフェイルセーフにしておく必要がある。出来ればリセットをうまく使って、おかしくなれば即リセットし、最初のパワーセーブsleepに入れるようにしてやりたい。

　これまでのロジックを余りいじらず付加機能的に実現しておこうと、暇さえあればメモをとりながらロジックを考えていた。コードの視認性を高めるためには大きなループは避けたい。といってC言語ではロジックを関数として切り出すと、内部変数がグローバル化し、バグの原因になる。難しいものだ。しかし、結局は、今のメインのソースコードをそっくり関数に切り出した以下のような構造になってしまった。擬似コーディングなので細かいところの調整は必要だが、これで余り構造を変えず、しかも見やすいソフトパワースイッチのロジックの目処がついた。ウェブには、意外とこういう情報が少ない。参考になれば幸いである。

（以上）

LPCMプレーヤー2号機開発の道草

LPC2388のRTCバッテリーバックアップに挑戦する(7/12/09)
　思わぬ道草を食ってしまった。ストロベリーリナックスのミニ液晶表示装置を2種類のIICで動かすライブラリを開発して、ちょっと自慢したくなり、ショップの問い合わせフォームで報告したら、あのPICNICで有名な社長の落合正弘氏ご本人がすぐメールを返してくれた。ショップへのこうした連絡はなしのつぶてということが多い。誠実な態度に感激した。

　記事をアップしてからすぐ「ねむい」さんからコメントを貰い、ソフトIICのDDRの謎はいっぺんに解けた。冷静に考えれば、出力ポートを最初0にしておけば、ポートをハイインピーダンスの入力から出力に切り替えれば、そのポートは0になるというのは自然なことだ。　もっと早く気が付くべきだった。そのうえ、リリースしてからすぐバグを見つけてしまい、少しめげている。

　ソースコードを見ていただければわかるが、欲張ってスクロールしようと思ってコードを追加したらあまりにも遅い（クリアに1msかかる）ので元へ戻したあと、テストを十分していなかったのが原因である。くやしいので、クリアをやめてDDRAMにデータとブランクを書き込む手法もあとから試したが、これもあまりスクロールに見えない。2行程度では難しいようだ。余計落ち込む。

　こういうときは、手を動かしていやなことを忘れるに限る。前々からやろうとしていたARMのもうひとつの雑誌付録基板、LPC2388のバッテリーバックアップ配線に挑戦することにした。前の記事では、これはとても無理だと書いたが、このあいだChaNさんの掲示板にある動画で、ご本人が苦もなく、0.5ミリピッチで並ぶピンを切り、配線しているのを見てしまった。うわあ、出来るんだ。驚きと同時に勇気を奮い立たせてくれた。

　しかし、手持ちの道具では、あんな細いピンを切ることは不可能だ。市販の超極細ニッパの刃先は0.3ミリというから、これで切れるのかもしれないが、出来るか出来ないものに￥2000近く投資するのも何か馬鹿らしい。

　で、暫く様子を見ていたが、たまたまアートカッターというクラフトワークに使う極細のカッターがあるのをウェブで発見した。刃先の厚さが0.38ミリだと言う。これなら切れるかもしれない。値段も￥500から￥1000前後で手頃だ。他の用途にも使える。東急ハンズを覗いてみたら沢山あったので手頃なカッターを2本買ってみたが、すぐには取り掛からずにいた。

　ところが、さらに強力な武器が思わぬところから手に入ったのである。このところ持ち歩いているSDカードプレーヤーを久しぶりに訪れたなじみのパブで自慢したら、何を考えたかマスターが奥からLED照明つきのヘッドルーペを持ち出してきた。使ってくれと言う。先日亡くなった母が使っていて誰か使ってくれる人がいないか探していたのだそうだ。渡りに船とはこのことだ。有難く頂戴した。

　道具が揃った。ヘッドルーペをつける。少し重いが、3倍の拡大率で視点を自由に変えられるので、作業しやすい。カッターで少しづつVbatピンを削って切っていく。これがなかなか難しい。ニッパーならあっという間だろうが、隣のピンを痛めずに一つのピンだけを切るのは簡単ではない。しかし始めてしまったらもう切るしかない。切り屑が出てきて切れたか切れないかルーペを通しても良くわからない。別のピンを切っていたら最悪である。何度もピンを数えて確認する。

　隣のピンも何か傷んできたようだ。これはまずい。もうやめようかとあきらめかけた時、Vbatピンが浮き上がってきた。おおお、切れたようだ。切り屑を針と洗浄剤で掃除して、テスターで切れたことを確かめる。よし、大丈夫だ。隣も確かめる。OK。いやあ冷や汗をかいた。

　切断に較べたら、半田付けは気分的に楽だ。この前の1608のチップ部品のハンダ付けの経験が生きている。問題は線の引き回しだ。基板上にピンヘッダーを横置きしてボンドで固め、ここにVbatピンか ら引き出した0.2ミリのUEW線を配線する。

　ベース基板にCR2032のフォルダーを付け、やっとのことでLPC2388のバッテリーバックアップ配線は完成した。いや楽しかった。こういう細かい手作業はいやなことを忘れさせてくれる。テストは...2号機が出来るまでお預けにしておこう。

EAGLEの入門書を買ってきた(7/15/09)
　色々道草を食ってきたが、2号機開発の作業は遅々としているとは言え、少しづつ進んでいる。ソフトパワースイッチは、大体目処がついた。FatFSが丈夫になったので、ソフトがハングして、電源が切れなくなる可能性は少なくなったが、今のスイッチルーチンの構造は、スイッチが離されるまで外へ出ないので、この構造は変える必要がある。押している間に、LCDが動き始めたり、消えたりしないと、操作性が悪い。

　まあ、これはソフトの世界なのであとから何とでもなる。ミニLCDが動いたので、ソフトの懸案は大体片付いた。いよいよメイン基板の具体的な設計に入る。

　その前に、バッテリフォルダーの制作にかかる。エポキシ系の接着剤が強力なことがわかったので、1号機で苦労した電池接点基板は、ケースの三方に接着するだけで必要な強度はとれそうである。汎用基板をルーターのカッターで切り出し、やすりで削ってケースに合う電池接点基板を作る。

ここへ、燐青銅線の接点をつける。このあいだの充電基板で試した形状の接点が簡単で具合が良いので、同じ型にする。経験が生きている。簡単につけることが出来た。テスターで電圧を測る。うむ、軽く当てるだけで安定した電圧がとれている。快調である。これなら複数台をこなせそうだ。

　メイン基板のレイアウトをもういちどやりなおす。充電回路も組み込むのでさらに大変である。部品が全部乗せられるかどうもかも自信がない。しかし、今度のメイン基板は、横の電池と同じ高さなので、配線 側が7ミリ近く空いている。いざとなったら、抵抗などはこちら側に入れることができるのでなんとかなるだろう。

　それより大きな懸案は、配線である。汎用基板にUEW線で配線することにすっかり慣れてきており、これくらいの密度でも配線できる自信はあるが、同じものを複数作れるかというと、とてもその気力はない。今回のプレーヤーは少なくとも3台は同じものを作らなければならないことになりそうである（身内1台、ヘッドルーペを貰った店１台、会社1台）。

　となると、プリント配線である。しかしこれはこれまでの工作とは全く違う大変な作業だ。もとより感光基板から作ることは考えていない。大掛かりな道具立てが必要で、今要求されているような精度の基板が作れるようになるまでには、気の遠くなるような時間がかかるだろう。現実解としてはCADで設計図を描いて、外国に発注すると言うのが一番有力なコースである。

　今までに何度か、これをやってみたい気になったことがあるが、これはこれで相当な心構えと準備が必要なのでそう簡単に始められるものではない。

　しかし、機は熟してきたようである。CADの定番、EAGLEの勉強を始めることにした。これが道草になるのかどうかは議論のあるところだが、手配線でも出来ることをCADでやろうというのだから道草の内に入るだろう。とはいえ、これがアマチュアの強みである。誰に束縛されるわけでもない。自由に自分のやりたいことができる。

　ウェブには、沢山の経験記やノウハウが載っているが、ここはオーソドックスに全体を見渡せる勉強法にしよう。書店で、「プリント基板CAD EAGLE活用入門」(\2800)という参考書を買ってきた。読み始める。また新しい登山口に立った。頂上は見えないが、未知との出会いに心が躍る。

ストロベリーリナックスのミニLCDのライブラリ公開

(7/10/09)
　最近、売り出した低電圧で動くI2Cを使ったストロベリーリナックスの液晶ディスプレイのドライバーがやっと公開できるレベルに達した。このLCD、小さいが2行16文字が表示でき、低電圧(2.7Vまで）で動くのが嬉しい。昇圧用のDC-DCコンバーターなどが要らない。ただインタフェースがI2Cなので知らない人にはとっつきにくいだろう。

　今度公開するライブラリは、標準のTWI（I2CのことをAVRではこう呼ぶ。ライセンスの関係らしい)を持っているAVRチップ(Megaシリーズ)だけでなく、持っていないチップ（Tinyシリーズなど）でも、GPIO（普通のIOピン）を使って、簡単な関数呼び出しだけで文字、アイコンを、このミニLCDに自由に出すことが出来る。I2Cに関する知識は要らない。ライブラリだけならフラッシュサイズは1Kバイトそこそこで入る。

　ソフトウエアで実現するI2Cは当研究所では、ずっと前にTiny26でUSIインターフェースを使ったドライバー（マスター・スレーブとも）を完成させている。当初はこれを組み込んで、TWIとの二本立てと考えていたが、途中で気が変わった。USIインターフェースそのものがTinyシリーズでしか実装しておらず、しかもピンが固定されている。MegaシリーズでもI2Cを2チャンネル使いたい時もある。GPIOを使ったI2Cの方が汎用性が高い。

　それなら、このあいだのChaNさんのFatFSの中にあるAVR用のRTCドライバーである。この前FatFSを使った時、このソースを読み、I2Cインターフェースを実に軽妙にソフトで実現しているのに感動した覚えがある。

　このときはフラッシュサイズを縮めるためこのRTC.cをそのまま使わず、TWIに替えたので、実際にはこのコードは使ったことがない。ちょうど良い機会だ、これを使わせてもらおう。早速FatFSのライブラリのRTC.cから必要なコードを取り出し、#ifでソースを入れ込んでいく。

　気が抜けるくらい余りにも少ないコードでI2Cを実現している。1バイトを送信するだけなら、RTC.c全体の1/3くらいしかない。たいしたもんだ。これで本当に動くのか半信半疑でテストに入る。悪い予想があたってGPIOのI2Cはエラーを大量に吐き出してつながらなかった。

　オシロではそれらしい波形が見えたのに、ロジアナでは全く反応がない。実はこのコードにはもともとよく理解できないところがある。GPIOピンを上下にドライブするのに、DDRという入出力指定レジスターだけを叩いている。これがどうもよくわからない。

（オリジナル）
#define SCL_LOW()    DDRE |=    0x04        　/* SCL = LOW */
#define SCL_HIGH()    DDRE &=    0xFB        /* SCL = High-Z */
　（DDREはポートEのDDRレジスター、PE2(0x04）がSCL）

　ChaNさんが書いたコードだ。ぬかりがあるわけはない。どこかに何かを設定するとこれで動くのだろう。しかし、それが何なのか見つけられない。色々いじったが事態は全く好転しない。どうもおかしい。オシロで見えて、ロジアナで見えないというのが何か気になる。臭い。しかしこうなるとハードの問題で、これ以上はちょっと手が出せない。

　悩んだ挙句、強引だがこのDDRレジスター以外に、PORTもドライブするコードを入れてテストしてみた。
（変更したもの）
#define SCL_LOW() {mLCD_DDDR|=(1<<mLCD_SCL); mLCD_DPORT&=~(1<<mLCD_SCL);}while(0)    /* SCL = LOW */
#define SCL_HIGH() mLCD_DDDR &=  ~(1<<mLCD_SCL)    /* SCL = High-Z */
（mLCD_DPORTはSCLのポート番号、mLCD_SCLはSCLピン）

　スイッチを入れる。おおお、ロジアナにそれらしい波形が戻った。ちゃんとスタートコンディションを作っている。立派、立派。しかし、依然としてLCDは動かない。 でも、ここまで来れば光が見えてきた。

　printfメッセージを沢山出してコードを追う。どうもC言語のBOOL変数はわかりにくい。こちらはアセンブラー育ちなので、等しいとき、正常終了のときはリターンコード0という観念からぬけられない。C言語のTRUE=1　FALSE=0というのがどうにもなじめない。特にif文の中で式なしで使われると大混乱する。やっぱりいくつか勘違いが見つかり修正する。

　#ifを使って分離したTWIのコードとあわせてリターンコードを揃え、祈る気持ちで電源ON。やった。Welcome画面がLCDに出た。これでGPIOのI2CでもLCDが動いた。#defineを設定し直してTWIに戻してみる。動かない！今までの苦労は水の泡か。頭から血が引いていく。はっはっは、ハード接続を替えていなかった。ジャンパーコードを差し込みなおして問題なく稼動。慌ててはいけない。

　アイコンの表示と消去がちょっと難しかったけれど、このあとの開発は順調に進み、だいたいこれでミニLCDのライブラリは完成した。アイコンも関数ひとつで任意の絵柄を表示/消去できる。コントラストもコマンドで調整できる。そろそろ公開できるレベルのようだ。

　これで少しはストロベリーリナックスさんにも顔が立った。前回の記事で営業妨害で訴えられる心配もないだろう。このライブラリでLCDが沢山売れることを願っている。

以下に、AVRstudioのプロジェクトファイルの形でソースコードとヘッダーファイルを置きます。mLCD168はライブラリmLCD.cをテストするためのやっつけのモニターです。10以上を1文字で入力する時は、;、:、などを入れてください。詳しくはフォルダー内の、mLCD_readme.txtを見てください。

7/10に公開したソースコードにはgoposにバグがありました。以下のものは修正されたものです。コメントにあるような変更もしてあります。コードは80バイト近く減っています。前のmLCD.lzhをダウンロードした方はダウンロードしなおし、前のソースは破棄してください。

「mLCD168_712.lzh」をダウンロード

LPCMプレーヤー2号機の開発

アクセス急増の反動でもないが別の工作へ（6/30/09)
　BeagleBoardの記事を載せてからアクセスが急激に増えた。これまでは多くても精々一日に300アクセス程度だったのだが、このところ400を越える日が増えている。ページ単位のアクセスもBeagle関係が多い。みんなの関心が高いようだ。

　前にも書いたようにBeagleBoardはこれまで色々楽しんできた電子工作とは異質の世界である。ARMと言っても最近始めた、Cortex-M3とかLPC2388とは数ランク上のプロセッサーで、ハードは勿論のこと、ソフトもすでに素人がソースレベルで気楽にいじれる規模ではない。日本語表示が出来て次のステップは日本語入力機能なのだが、あまり気が進まない。日本語が入力できたからといって何か次の目的があるわけではない。それにソフトパッケージをダウンロードしてきました。インストールしました。動きました、だけでは何となく面白くない。

　まあ、BeagleBoardに関してはすべてこれしかやっていないので偉そうなことは言えない。しかし何か、こう、どきどきわくわくするところが欲しい。自分の創意、工夫が役に立って、既定の機能と違う動きをしたり、別の働きをするところが見たい。人間とは贅沢なものである。

　そんなこともあって、Beagleはちょっと横に置いて、このあいだのDS-Liteのバッテリーの充電基板を作ってみた。これは基板を作るだけが目的でなく、LPCMプレーヤー2号機を念頭に置いた、電池フォルダー制作の練習を兼ねている。もしプレーヤーを量産するとなったらより簡便な手順で電池フォルダーが作れないと効率が悪い。

　1号機で苦労したのが電池接点を支える天板の固定である。電池は接点にかなり強い力で接している必要がありその強度が問題になる。基板にピンヘッダーの接触ピンをハンダ付けし、それに基板をボンドで固定するという手の込んだ方法で天板の強度を確保しているが、ここはもっと簡単に作れるよう改善しておきたい。

　そこで思い当たったのが、CDケースである。スペースを節約するためCDケースは最近薄いケースを使うようになって、初期の頃の厚いケースがごろごろ余っている。このケースの高さが電池の高さとぴったり合うことを発見した。アクリルのケースを適当にルーターで切り取り、天板付のマザー基板にすることにした。ユニバーサル基板を小さく切ってボンドで接着して接点基板にし、配線用の基板を横に載せる。

　充電用のIC、LTC4054はこれまでの変換基板では大きすぎるので、サンハヤトの変換シール基板と秋月の8X8のミニ基板(10 ヶ￥100）を活用して実装した。このシール基板はサンハヤトの製品にしては、お買い得で一枚(￥770）に2４個のSOTチップ(一ヶあたり￥32、秋月のミニ基板をつけても￥42)をつけることが出来る。このシール基板は結構銅面が多く、データシートによる最小面積50平方mmを満足し、600 ｍA まで流せそうだ(外気35°C）。基板にジャンパーピンをつけて充電電流の実測が簡単に出来るようにし、充電電流を決める制御抵抗は用心のため半固定の可変抵抗にして調整できるようにする。

　うむ、なかなか具合の良い充電基板が出来た。充電も順調だ。しかしこのCDケースを応用した電池フォルダーは、プレーヤーの方のケースの高さが足らなくて、今度の2号機には使えないことがわかった。残念。充電機能も内蔵しようと当初考えていたが、これもDCアダプターが大きすぎて、とても入りそうにない。充電機能がないとなると、電池交換がすぐ出来るようにしなければならない。

ストロベリーリナックスから小さいLCDが送られてきたので部品あわせをしてみる。いやいや、これは、これまで以上に大変だ。しかし全く不可能と言うわけでもないので悩ましい。何とか納まりそうだが、やっぱり手配線では無理か。そろそろプリント配線に挑戦する時期に来ているのかもしれない。

FatFSのバージョンアップ(7/3/09)
　LPCMプレーヤー2号機のためのソフトウエアの整備もやり始めた。電源スイッチを入れる場所がないので、スイッチ長押しのソフトパワースイッチを実装する必要がある。ちょうど良い機会なので、これまでの不満なところや、2GB以上のSDカードのサポートをしようと考えた。

　ソフトパワースイッチは、データシートを確かめて驚いた。最も節電できるPowerDownモードだと、Mega88クラス（Mega328など）で1μA、Mega128クラスでも5μAしか流れない。電池の自己放電と言えば、多いほうのニッケル水銀電池では数百μA、少ないリチウム電池でも数μAというからこの消費電流は優秀なものだ。食わず嫌いをしていたようだ。2号機はソフトパワースイッチで決まりだ。

　もうひとつの現在のソフトの不満と言えば、SDカード読み取りの途中でエラーが起きると、そこでスタックしてしまい、電源のOFF/ONをしない限り正常に戻らないという不具合である。まあスイッチを入り切りすれば元へ戻るからそう目くじら立てることもないのだが、設計上はカードを読み直して復帰するはずなのにそれがうまく動いていない。

　これはソースリストをもういちど注意深く読んで不具合があちこちで見つかった。まずマウントは、FatFSではソフト的にしか行っていないので、下位ルーチンのdisk_initializeという関数を呼ぶ必要があった。そのほかのルーチンも初期化をさぼっていて変数がそのままになり元へ戻れないことがわかる（要するにserially reusableでなかった）。これらの修正の結果、プレーヤーはSDカードを途中で差し替えても、電池の瞬断で演奏が止まっても、何かスイッチを押すと最初の状態に戻って正しく動くようになった。

　うむ、大分丈夫になった。これでソフトパワースイッチの実装の環境に不安はない。いよいよ最後のTinyFatFSから、SDHCをサポートするFatFSのバージョンアップにとりかかる。

　ChaNさんのサイトから最新のFatFS（0.07c)をダウンロードさせてもらい移植を開始する。このファイルシステムは着実に進化を続けており、このあいだのバージョンでは遂にWindowsのロングファイルネームをサポートするようになっている。海外のサイトでもFatFSの導入例を時々見る。日本の組み込みOS、TOPPERSにも採用されている。こういうソフトを無償で気前良く提供し、なおかつ改良を怠らない姿勢には頭が下がるばかりである。

　おや、TinyFatFSはどこへ行った？　リリースノートを見る。ありゃあ、最新版の最初のバージョン(0.07a)ですでに標準のFatFSに吸収されてしまっている。えー、TinyFatFSは前から、FAT32をサポートしていたんだ。何だSDHCが使えるのか。知らなかった。身の不明を恥じる。それにしてもこのバージョン番号、未だに0.1以下にすることはないんじゃないでしょうか（こんなに進んでいるのに）。もう1以上を名乗って何の問題もないと思いますがね。

　フラッシュサイズはどうだ。うーん、少し大きくなっているようである。R/Oの最小サイズは、TinyFatFSの時の、2524バイトから、3824バイトに上がった。しかしこちらは今、32KBもあるMega328を使っているから全く問題はない。それにTinyFatFSはなくなったけれど、小さいチップ用のプチFatFSが用意されている。さすがやることにぬかりがない。

　I/Oディバイス依存のmmc.cは替えないで良いはずだが、まあ用心のため新しいmmc.cを入れてこちらの環境に合わせる。コンパイルする。いくつかの未定義エラーが出る。あれ、これもバージョンアップしたはずだがとソースを見ると標準のdiskio.hではなく、サンプルプログラムのSDカード用のdiskio.hが必要とわかる。　

　とりあえずコンパイルは通ったので動かしてみる。動かない。Welcome画面から先に進まない。やれやれ2行のLCDの表示だけではどうしようもない。デバッグ用のUARTを入れなおしてすこしづつ確かめていく。本当はテスト環境を作るべきなのだが、不精してプレーヤーにいきなりぶちこんだのが良くなかった。かえって手間がかかっている。

　ディスクの初期化はうまくいっているようだ。エラーは出ていない。しかしファイルの表示が出ない。あちこちにprintfを入れてデバッグする。ファイルサイズがおかしい。おやあ、ちゃんと動くSDカードがあるぞ。演奏も問題ない。これは困った。ハードも影響しているのか。

　あちこち調べまわった結果、やっと原因がわかった。不具合の原因は、ファイル名の小文字だった。LFN（ロングファイル名）をサポートしたので、ファイル名のupper case化がされていないのだ。WAVという拡張子を調べてそれ以外のファイルは再生の対象からはずしていた。正常に動いたSDカードはどういうわけか最初から大文字だった。

　wavという小文字の拡張子も再生リストに入れることにして解決。またしても大山鳴動ネズミ一匹的な騒動だった。フラッシュサイズはこれまでの13KBから1KBほど大きくなっているが、まあ問題ないレベルだ。速さはどうだろう。ロジアナを引っ張り出す。うーむ、速度も少し遅くなった。これまでより12%程度遅くなったか。ま、これも許容範囲だ。

ストロベリーリナックスの低電圧ミニLCDを動かす(7/5/09)
　最近売り出されたばかりの3Vで動く小さなLCDモジュールである。小さいけれど、生意気に2行16文字が表示できる。画面は最上行に携帯電話用らしいアイコンを表示する少し余計な機能があるが、今計画しているLPCMプレーヤー2号機にはぴったりの表示装置である。3Vの低電圧で動くのでDC-DCコンバータも不要だ。3ヶも買ってある。

　インターフェースは、パラレルでなくてI2C（AVRではTWI)である。I2Cは、がた老AVR研究所では発足以来すぐ、秋月のRTC(リアルタイマークロック）とのインターフェースや、Tiny26などI2CのないチップのUSIインターフェースでソフトI2C（マスター・スレーブ）を開発したりして経験を積んでおり実装には問題ない。ショップのページには、液晶コントローラのデータシートも、アプリケーションノートも、サンプルプログラムもダウンロードできるようになっていて、開発に不安はなさそうだ。

　FatFSのバージョンアップが一段落したので、2号機に向けての次のステップとして、早速動作確認をすることにした。さすがに現用のブレッドボードにあるLPCMプレーヤーを使うことは止め、別のブレッドボードに新しくCPUチップ（Mega168)を乗せて専用のテストベンチを作る。配線そのものはCPU周りを準備（ISPまわりとXtal)すればI2Cは2線インターフェースなのでプルアップ抵抗を入れて5分もかからない。

　しかし、ちゃんと動くまでには意外に時間がかかった。日曜日を丸々一日使ってしまった。負け惜しみを言うようだが、沢山あるように見えた資料が問題だった。まず、ショップの提供するデータシートが英語であることはともかく、パラレルとシリアルそれにI2Cの3種類のインタフェース共通のデータシートでとてもわかりづらい。I2Cの項の最初には「I2Cでは書き込みしかできない」と明記してあるのに、後半には、読み込みが出来ないと使えないBusyFlagの説明が出ていたりして混乱する。一般的なI2Cの説明と、このコントローラ特有のビットの説明が混ざっているので余計わかりにくい。

　日本語のアプリケーションノートも、どうも端折って書いてあってこれまた全貌がつかめない。I2Cについてある程度知識があれば類推が効くが、そうでないと理解するのに苦労するだろう。データシートからの引用のチャートは肝心のCOビットの説明文が省略されているので何のことか良くわからない。特にファンクションセットのあたりは省略が激しい。

　結局、データシートと、アプリケーションノート、それにソースコードの3つを同時に見て、それぞれ確認していかないと開発が進まない。各コマンドのあとには必ず30μs程度のwaitが必要なようで、I2Cとしてはシビアな環境ではない。しかもI2Cインターフェースの多いRTCとは違って読み込み処理はなく、一方的に書くだけだ。

　割り切って、スタートコンディション、マスター書き込み宣言、コマンド、データ、ストップコンディションというI2CシーケンスとLCDシーケンスの順番を単純に繰り返す手順を解説するだけで、LCDはとりあえず動くはずなのだが、そういう書き方ではなく色々な方法を紹介したりするものだから余計わかりにくくなっている。

　ソースコードがまた難物であった。余り悪口は言いたくないが、構造化言語であるCの文法を全く無視したアセンブラー的なコーディング（switch文にgotoと、returnが入ると訳がわからなくなる）で、読むのに大苦労である。こういう通信関係のエラーによる中断の多いプログラムは構造化しにくい処理の代表格だが、もうすこし整理の仕方があるだろう。それにこんなに綿密にエラー処理をしたりリトライしてもあまり意味がない。近接した液晶とCPUの間で一旦エラーが起きたら回復する可能性は殆どない。先の見通しがないときエラーで帰ってきても無意味である。

　これまでのI2Cを使ったプロジェクトからソースをとりつくろいUARTからLCDを操作するテストプログラムを作る。久しぶりのAVRの本格的な開発である。用心のため、xprintf(ChaNさんのFatFSについているもの)を沢山仕込み、デバッグに備える。

　動かしてみた。全く動かない。まあこういうのには慣れている。xprintfを初期化から入れて動きを確認していく。あれえ、最初からリセットしている。なんだなんだ。変数を表示するxprintfのところで暴走している。原因はわからないがとにかくxprintfがおかしい。デバッグのために入れたステートメントで暴走するなんて洒落にもならない。

　xprintfをやめ自前のUART出力関数などでデバッグを進める。おやあ、ちゃんと正常終了のフラグを出しているぞ。あっ、ifの中の論理が逆だ。これを正しく直す。おお、画面に何かが出た。なーんだ。I2Cは動いていたのだ。正常なのにエラー終了していた。

　そりゃそうだ。このへんのI2Cの関数はすべて動作確認済みだ。ただ、文字は出たが、表記が目茶目茶である。しかし、ここまでくれば大分近づいた。ソースコードを点検する。コマンドのビットが1ビットずれているのを発見する。

　これを修正し、めでたく低電圧ミニLCDは動くようになった。しかし、クリアや、コントラストの変更ができない。これはアプリケーションノートが端折ったところで、ファンクションセットに2種類あり、コマンドを出す前にはそれに応じたファンクションセットをしてからでないと動かないことがわかった。これを修正してUARTから自由にクリアとコントラストが調整できるようになる。

　日曜一日で何とか動くようになった。xprintfが動かなかった原因は次の日、事務所に行く途中で気がついた。xprintfの内部ルーチンのxitoaの行き先を指定するのを忘れていた。これでは暴走するはずである。情けない。

　ストロベリーリナックスさんには相当悪態をついたけれど、今回のソースコードはライブラリ化して近く公開し、少しでもこのディバイスが沢山の人に使われるようにしたいと思っている。こういうお洒落なディバイスをアマチュアに提供してくれるショップは大事にしないといけないし、オープンソースではこれまで沢山の人のお世話になっているのでせめてもの恩返しだ。

電子工作の次の方向が決まらない

　BeagleBoardへのUbuntu導入で時間をとられてしまったが、本来の電子工作を全くやってなかったわけではない。日にちは前後するがこの一週間の出来事を報告しておこう。

リチウム電池の充電実験をブレッドボードでする(6/19/09)
　このあいだ千石に行ったら、店が拡張されていて新装セールをやっていた。道路上のかごに任天堂のゲーム機（DS-Lite)の補充用リチウムバッテリーが山盛りにされ、￥480という安値で出ていた。最近、我が家でもこのゲーム機がはやっている。予備があれば喜ばれる。この前の携帯の余った電池より少し厚いが面積は小さい。3.7Vで1000mAhと容量も十分だ。PCMプレーヤーなどの電池に使えば、さらに小型化できる（6/24まだ少し残っていた）。

　もちろん純正品ではないが、純正品なら￥2000近くするバッテリーだ。思わず2つ買ってしまった。そういえば充電用のICのLTC4054もこのあいだここで買ったきり試していない。ちょうど良い機会なので、このバッテリーを充電してテストすることにした。

　あらためてLTC4054のデータシートをダウンロードし仔細に調べる。殆ど何もしないで完全な充電が出来そうだ。これは楽だ。ただ、チップが小さい。ピッチ変換基板にはベタアースなどない。700ｍAまで充電できるそうだが発熱が心配だ。データシートにちゃんと熱抵抗値がでていたので計算してみる。

　うむ、50mm平方(7mm四方）の金属接続面積で、接合点と表面の間の150°C/Wで計算してみても、400mAぐらいまで流して平気なようだ。安全のため200mAくらいから始めることにする。

　ブレッドボードで組む。ものの5 分もあれば組みあがる。実験を開始する。LEDが点き、充電が始まった。用心のため、テスターふたつをつけ、充電電流と電圧を測る。ついでに温度計をICの上にセロテープで固定し、温度も測る。制御抵抗を5KΩにしたら、180mAくらい流れた。この程度では、チップは殆ど熱をもたない。

　定電圧充電に入ってICが充電を終えるのに3時間余りもかかってしまった。10分ごとに測っていたのだが、電流がシャットダウンされる最後の瞬間を見逃す。サッカーのゴールシーンを見逃した感じだ。もう午前3時近い。慌てて床に就く。

いずれにしても、これで安全にリチウム電池を充電する基盤はととのった。これは楽しみである。注文を受けているLPCMプレーヤーに充電回路を内蔵すれば実用性はいっそう高まる。人にあげるのでなく自分のためにも2号機が作りたくなってきた。

秋月で買った小さなケースがこの電池にピッタリ(6/24/09)
　最近は仕事で事務所に出ても、仕事の合間は電子工作のことを考えていることが多い。充電ICが思いのほか順調に電池を充電することがわかったので、今までの電子工作のロードマップをあれこれ検討した。

　これまでのロードマップでは、次はARMのSTM32 でのSDカードアクセスだった。しかし、SDカードは既にAVRやH8で実現しているので新味は薄い。それにSDカードは手段で目的ではない。フォトフレームが最終目的だが、LPCMプレーヤーの演奏中の経過表示を適当なOSを入れて作ってみたい気もする。DACにひたすらデータを送り、バッファーのデータが少なくなればSDカードを読みに行き、そのかたわらLCDにデータを表示すると言うマルチタスクをOSなしで作るのは至難の業である。

　しかし、OSを入れるには準備が必要だ。それにSTマイクロのファームライブラリをV3に上げておきたい。あれやこれやでなかなか具体的な行方が定まらない。そんな日の仕事の帰り、秋月に寄ったら、これまでのLPCMプレーヤーに使ったケースよりさらに小さなケースを見つけた(アクリルケース蝶番式[小]　117-TSS 77x51x22)。

　ここまで小さくするのは無理だと思うが、￥100と安いので試しに買ってみた。家に帰って、先のDS-Liteの電池を入れてみる。何とこれがピッタリ入ってしまう。1ミリの狂いもない。それに前々から気になっていた、ここの（ストロベリーリナックス）の3Vで動く超小型LCD(￥700) の長さが、これがまた測ったようにきれいに入る（はずだ）。これはもうLPCMプレーヤーの2号機を作れと言う電子工作の神の天啓だ。作るしかない。

　はずみというのは恐ろしい。LCDを発注するときに、どうせ同じ送料ならと前から欲しいと思っていたXbeeチップ（￥2730 2ヶ）も一緒に注文してしまう。確かに1ヶだけではテストもできないし、２つというと￥5000以上になるのでためらっていたパーツである。これは前から計画している電力ロガーの無線通信手段になる。

　いやいやプロジェクトの方向が定まらなくなってきた。嬉しい悲鳴である。旅行はその時より計画しているときの方が楽しいと言う。電子工作も同じようなものだ。作り始めると苦しいことばかりだものね。

UbuntuがWindowsのファイルを壊したが何とか修復(6/25/09)
　ついでに、Linuxネタをひとつ。BeagleBoardの騒ぎの後、ふとPCのデスクトップを見ていて見かけないアイコンを発見した。アイコンの名前が000で特定のicoファイルのない裸のアイコンである。誰がこんなゴミを作った、と気楽に消そうとしたら、これが消えない。このPCは、このあいだ２つあるハードディスクのひとつをデフラグして、10GばかりのスペースをつくりUbuntu9.04のLinuxをインストールしたばかりである。

　これはおかしい。そういえば昨日、LinuxからこのCディスクを色々いじった。そのとき悪さをしたのだろうか。用事があったのでMy Documentを開く、あれれ、ここにも000のファイルがある。同じように消せない。Windowsでは全くこれを操作することが出来ない。

　顔が段々青ざめていく。これはまずい。バックアップは今年の始めにやって以来さぼっている。思い当たることは、Ubuntuのインストール以外考えられない。とるものもとりあえずWebで調べてみる。

　キーワードを「000 Ubuntu ファイルが消えない」で検索をかけたら、一発でそれらしいサイトにぶつかり、原因が判明した。やっぱりUbuntuの仕業だ。インストールのとき、すべてのパーティションに対してファイルチェックをするのだが、ファイルタイプvfat（Windowsファイル）に対してもLinuxのfsck（ファイルチェック）をかけてしまい、シフトJISの日本語名ファイル・フォルダーを不良として修復をかけてしまうのだ。被害にあうのは、FAT32のファイルだけで、NTFSでは起きない。「ポソ表構十申」などの日本語がファイル名に使われるとやられる。

　Ubuntu7.10のときの問題だというけれど、現実に9.04でも同じことが起きている。フォーラムをよく読む。良かった。Ubuntu上では、renameが可能だ。本体は消されていない。悪さをするのはインストールの時だけで、そのあとは大丈夫らしい。色々な修復方法が載っている。DOS窓で、dir c:\ /A- /S > HOGEHOGE.TXTとやってすべてのディレクトリ名をファイルに書き、000のファイル・ディレクトリを探せとある（同一フォルダー内では001,002と増えていく）。

　やってみた。15MBのテキストファイルが出来た。行数にして32万行。結構なサイズだ。指定の秀丸エディターはなかったので、Linux上で、grepをかける。いやあ昔を思い出す。数だけ示す-cでやると1582と出た。肩の力が抜ける。こりゃ人間の力では無理だ。少しlessなどで見てみる。ああこれはファイルサイズが XXX,000などの場合もヒットしているので実体はもっと少ない。

　' 000'でやってみる。うむ、158と出た。これが被害の数のようだ。これくらいなら何とかなる。日本語名のファイル、ディレクトリだけが被害を受けるのでWindowsそのものの動きには影響はなさそうだ。最初はWindowsの再インストールまで覚悟したが、それはしなくても大丈夫なようだ。良かった。

　実際の修復にとりかかる。自分のドキュメントはバックアップが不完全ながらあったので、それを見ながら、Ubuntu上で元へ戻せたが、困ったのは、Windows自体にある大量の日本語ファイルであった。Windowsのテーマファイルがごっそり000に変わっている（スポーツテーマなど）。少し直し始めたけれど、どうせ使わないテーマを元にもどす必要もない。結局、自分のファイルだけの回復作業でやめることにする。

　それでも30個近いファイル・ディレクトリの修復をさせられた。やれやれ、えらいところで時間をとられてしまった。デスクトップで発見の端緒となった000になったアイコンは、ソリティア.lnkだった。ははは。

　余り腹が立たないのは、何故だろう。まあ、Linuxびいきということもある。これが現実にファイルそのものを消していたらこんな笑い話ではすまないが、この程度の被害と言うことと、問題解決に当たっての、このオープンなところが何とも清々しい。かなり致命的な問題なのだが、みな感情的にならず寄ってたかってその修復に力を合わせている。これがオープンソースの良いところだ。それでもFAT32でWindowsを作り、そこへあとからUbuntu Linuxをインストールする人は要注意である。

BeagleBoardにUbuntu9.04をインストールする

日経Linuxの記事があてにならない(6/21/09)
　今月(7月号)の日経Linuxは、電源プラグに差すだけで動くLinuxサーバーや、BeagleBoardの新版（RevC)の紹介という組み込み系の特集である。なかでも最近リリースされたばかりのARM用のUbuntu 9.04 LinuxをBeagleBoardにインストールする記事は、当研究所がこれからやろうとしていたこととぴったり一致する。

　BeagleBoardは余技にすると言ったばかりなのだが、タイミングが良すぎた。これは買ってくるしかない。それに、この前のAngstromのインストールでは、knoppixで誤魔化したけれど、そろそろPCにもLinuxを入れておきたい。各種の最新Ubuntuディストリビューションの入ったDVDも付録についているというので、早速、購入してきた。

　通読すると、BeagleBoardへのUbuntu9.04のインストールは、SDカードのフォーマットから、最後の日本語フォントのインストールまで事細かに解説してある。とても簡単に見えた。BeagleBoardの当面の目標は日本語化だったが、Angstromの日本語化はそう簡単ではない（動かしたのはデモ版）。これならすぐ日本語が見られそうだと気楽に作業を始めた。

　ところが、これが一筋縄では行かなかった。雑誌の記事の通りやっても動かないのである。あとでわかったことだが、この雑誌の記事にはミスが多いのだそうだ。普通は、印刷された、しかも大手の出版社の活字情報は、Webの情報より信頼度が高いと思うのが常識なのだが、これが違ったのである。

　結果としては、インストールは成功し、BeagleBoardのブラウザーで日本語を表示できるところまで進んだ。この雑誌の記事の通りにやって動かないで困っている人がまだ沢山いると思うので、とりあえず経過だけでも紹介しておくことにする。

　まず、はまったのが、パーティションを切る、GPartedというソフトのインストールである。apt-get installを入れても一瞬のうちにエラーで帰ってくる。こちらは最近のLinux情勢にうとい。とくにDebian関係は全く経験がない。始め、apt-get updateをしないで、ない、ないと騒いでいた。

　これはGPartedでなく、gpartedで探したら一発で見つかる。やれやれUNIX関係は、大文字、小文字に厳密なので、こんなことではまる。コマンドは正確に記述して欲しい。

(誤) sudo apt-get install GParted    -----> （正) sudo apt-get install gparted

　しかもページを沢山使って説明したGPartedのやっていることは、単に、SDカードの残りの部分をext3で定義し、ここと頭の部分をそれぞれフォーマットするだけのためだった。これくらいなら、何故、fdiskとmkfsでやってしまわない。記事を良く読まなかった自分が悪いことを棚に上げて無駄な作業手順をやらされて腹の虫が納まらない。

　いよいよ付録DVDからrootfsイメージの展開である。記事の通りtarコマンドを入れる。おやあ、このコマンドのオペランドの順がおかしいなあ、最近は順序が変わったのかしら。入力する。やっぱりシンタックスがおかしいと、はねられる。

（誤)
$ tar /media/cdrom/article/toku3/ xvzpf armel-rootfs-lxde-200905161138.tar -C /mnt/
  (傍線　筆者）

（正)
$sudo tar xvzpf   /media/cdrom/article/toku3/armel-rootfs-lxde-200905161138.tar -C /mnt/

　何と、tarコマンドのオプションが入出力引数の中間に入っているまま印刷記事になっている。こういうコマンド行は校正の時には真っ先に、入念にしなければならないところである。どうしてこんな間違いが起きるのだろう。理解に苦しむ。しかもこのtarの前には、sudoがない。

　まあ、この程度なら少しUNIXを知っている人ならすぐわかる間違いだが、次の不具合はもう少し深刻である。正しく入れなおしたtarが全く展開できていない。エラーメッセージを見てわかった。SDカードのルートディレクトリは、root以外の書き込みを許可していない。雑誌の記述では、この先のファイルの作成ではroot権限になれと書いてあるが、tarはsudoで動かしている。

　ファイルの生成は微妙で、誰が作ったかでパーミッションが変るので、こういう作業はユーザーはrootでやるのが間違いがない。いくら管理者権限があってもrootでないと失敗するときがあるのだ。しかし困った。何かの手違いで新しくいれた現在のPCのUbuntuではrootのパスワードが設定されてしまい、現在rootになれない（これはその後、sudo su - で、# passwd　によってrootのパスワードの設定が出来ることがわかった。 Ubuntuでは最初、rootが設定されていない）。

　仕方がないので、SDカードのルートディレクトリをchmod　777　/(SDカード)で、パーミッションを強引に変えて（これはsudoでも出来る）、tarを入力する。正規には、ここでrootになってインストールしなければならない。

　何とか順調にtarボールが展開され始めた。おや、最後の方で少しエラーが出た。うーむ、rootではないからな。いくつかのディレクトリ生成やリンクが失敗に終わっている。だめもとで出来上がったカーネルを立ち上げてみる。いや大丈夫なようだ、順調にブートされていく。いや、やっぱりだめだ。途中で止まってしまった。no initial consoleのメッセージで止まっている。確かtarの展開のときのエラーはディバイス関係のディレクトリでのエラーだった。このあたりでひっかかっているのだろう。

　やれやれ、アマチュアのWebの記事を参考に入れたAngstromは一発で動いたが、雑誌の記事を見て、しかもミスを回避しながらのインストールは失敗に終わった。恐らく沢山の人がこの記事の通りやって動かない動かないと悩んでいることだろう。

　もういちどrootからやってみよう。それに雑誌のrootfsイメージは信用がならないので、正規のサイトから落としたほうが良いかもしれない。

BeagleBoardでやっと日本語が出る(6/22/09)
　翌日、仕事から帰って、もういちどSDカードをフォーマットし直し、正式にrootになってtarで展開する。とりあえずは雑誌のDVDから展開する。うむ、全くエラーもなく、きれいにrootfsはインストールされた。omap3のカーネルイメージも順調に展開された。

　新しく入れたUbuntuのターミナルでcuコマンド（いや、なつかしい。接続終了が、~.という変なコマンド）でシリアル端末を立ち上げる。おやあ、最初のブートローダーがリセットしてしまう。どうした。あ、USBのハブの電源を入れていなかった。入れ直す。よしよし、Linuxのブートが始まった。画面を切り替える。

　おお、PCのUbuntuと全く同じログイン画面が出た。しかしログインでまたはまる。rootでは入れない。これは雑誌にちゃんと書いてあった。BeagleBoardのUbuntuはユーザー名 ubuntu　パスワード ubuntuで入るのだ。

　Angstromと同じようなGUI画面があらわれる。ロケールが日本語になっているので字化けしている。日本語フォントが入っていないからだ。これは自分でいれなければならない。最後の難関、日本語化キットのインストールである。BeagleBoardがネットワークにつながっていないと出来ない。幸い、Net関係は一発で通ったようだ。インストールコマンドの入力だ。何い、こんなコマンドを入れるのか。

(誤）
$ sudo -y apt-get install language-support-fonts-ja

(正)
$ sudo  apt-get install language-support-fonts-ja

　とんでもないところに　-y　が入っている。これ違うよね。念のため、その通り入れてみる。もちろんシンタックスエラーではねられる。-yをとりのぞいて入力。順調にパッケージがインストールされた。Debianは初めてだが、このapt-getは実に便利である。昔々RedHat Linuxを入れて、rpmに感激したことを思い出す。

　ウェブブラウザーを探す。おや、Conkerorという簡易なブラウザーしかない。こいつキーボードからURLを入れさせる。コマンドガイドを頼りに日本語サイトを入れる。出た出た。おおう、きれいな日本語フォントだ。

　いやあたいしたものだ。たかだか8センチ四方のボードでここまで動くのである。ボードのCPUチップに触ってみる。結構熱くなっているが、やけどしそうなほどの熱さではない。せいぜい数ワットというところだ。地球に優しい。

　画面の動きは、一昔前のノート PC、そうちょうど今ターミナルに使おうとしているPentium133Mhz時代のLet'sNoteの画面の動きをもう少し遅くした感じだ。ウインドウを激しく動かすと軌跡が残る。まあ、これが目的ではない。これだけ動けば十分だ。こちらは今のところNASあたりを予定している。

　それにしても、今度の雑誌の誤植には驚いた。信頼性について活字メディアを一段高い位置に置いて考えていた自分がもう古いのかもしれない。Web情報ならいくらでも訂正が効くが、活字はそういうわけにはいかない。だから校正には念には念を入れ、読者もそれを信じていた。そういう自覚が今は薄れているのだろうな。

レガシーなRS232Cインタフェースにはまる

　STM32のRTC（リアルタイマークロック）が動き始めた。次のプロジェクトの目標はSDカードアクセスで、行く行くはこのSTM32で、液晶フォトフレームのようなものを作ってみようと考えている。その前に環境を整備しておこうとして思わぬところで時間を費ってしまった。一週間たっぷりはまりこんで一喜一憂していた。まあこれが趣味の醍醐味だと負け惜しみを言っている(単に耄碌（もうろく）しただけかも)。

printfがやっと動いた（6/08/09）
　当面の懸案は片付いたのだが、具体的な次の作業が見つけられない。そんなこともあって細々とした手直しや、周辺の環境整備をして気分が乗るのを待っている。1年以上前にAVRの実装処女作として作った温度ロガーを久しぶりに動かしてみた。電池はまだ十分あって温度が表示されたが、コマンドを殆ど忘れていることがわかる。あわててコマンドの案内メッセージを出すためにAVRStudioを立ち上げてAVRプログラムの修正。良かった。やり方を忘れていなかった。かと思えばBeagleBoardのために買ったワイヤレスのキーボードを試してみたりする。どうも落ち着きがない。

　当研究所のキーボードは15年以上前に買ったDECのPCについていたものである。中古でも当時30万近くしたPCだったのでキーボードのつくりが良い。こいつの使い勝手、キータッチを上回るキーボードにそれ以来お目にかかったことがない（安物ばかり使っていたこともあるが）。ブラウン管モニター同様愛用していて今も何の不具合もないが、さすがに古くなってきた。今度のワイヤレスはその代替としても考えており、少し高めの製品を選んだためか打ちやすい。

　ところでBeagleBoardのブートローダーや、STM32のファームライターはシリアルを要求する。PC一台では開発の効率が悪いので、戸棚の奥に眠っていた大昔のLet'sNoteを引っ張り出した。Pentium133MhzのWindows95時代のものである。ターミナルだけなら十分だ。立ち上げてみて、色々思い出した。こいつはLinuxと、DOS(V7)まで3つのOSが動くようにしてあった。海外のサイトの情報をもとに、liloを細工してPartitionTableを書き換えるという荒技をやって、DOSとWindowsを両立させている。懐かしい。

　情けないことにLinuxのコマンドを殆ど忘れているのでWindowsのハイパーターミナルでシリアルをテストする。問題なく動いた。これでPCの画面を切り替えなくてもBeagleBoardを動かすことが出来る。

　STM32の方は、ファームライブラリをV1(V2は殆ど同じ)からV3に上げないといけない。STマイクロのmigration guideを少しまともに読んでお勉強する。CMSISなどという大層なコンセプトがついているので何かと思ったら、Cortex Microcomputer Software Interface Standardの略で、ARMのCortex-Mファミリーの中だけの話だ。

　構造的に大きく変わったわけではなさそうだ。直接レジスターを叩くときのライブラリ(core_cm3.h関連)と、構造体を介して動かすソフトのためのライブラリを別に用意したのと、表記上の変更・統一（Atmelと同じようなuint32_tとか、volatileでなく__IO__とか）などが主な変更だ。要するにCortex-Mシリーズの統一したライブラリを目指したもので（ベンダー側のメンテナンスコスト削減）、ユーザーにはたいしたメリットはない。まあ、GNU用のスタートアップルーチンが用意されたのが安心と言えば安心である。

　一気にV3の新しいプロジェクトを立ち上げる気力がなかったので、前からやろうと思っていたprintfの実装をすることにした。Eclipseで#include <stdio.h>が未定義エラーになっているのも以前から気になっている。それでいて標準ライブラリは、sprintfが問題なく使えている。良くわからない。

　オリジナルのデモソースは、printfだったが、動かなかったので、sprintfに替えた経緯がある。理屈から言えばこのあいだのsyscalls.cのスタブルーチンの_write( )にUARTの出力関数を実装すれば動くはずだ。「ねむい」さんのsyscallsのソースもそうなっていた。早速このソースを参考にコーディングしてみる。

　こいつがまた思い通り動かない。出力はされるのだがタイミングがおかしい。色々調べているうち、昔のことを思い出した。かなり昔、UNIXを少しいじっていた頃、標準ストリーム出力が言うことをきかなかったことを思い出す。確か、ストリームは、バッファーリングしているのでデータを残さないで全部を吐き出させるためには何かテクニックがあったはずだ。

　ウェブに慌てて教えを請う。やっぱりそうだった。えー、￥n(ニューライン)がバッファーの区切りなの？それじゃあ、デモソースにある時刻を表示するステートメントの最後が￥r(リターン)では、いつまでたっても表示されない。デモソースのオリジナルは、printfの文法を無視した実装になっている。ちょうど逆だ。

　どうも、オリジナルのデモソースのprintfは標準のpirntfで動いていない。その証拠に\n\rが行頭にあり、これでは全部のステートメントが一回づつ遅れる。それに時刻表示が\rで終わっている。これでは1秒毎に表示されず、バッファーが満杯になって始めて全部の秒表示が行われ、最終的に最後の秒表示が出るだけだ。今のソフトがまさしくこうして動いており、何分かに一回、時刻が更新されている。

　UARTに出すメッセージの行換え文字\rをすべて\nにして行末に移しコンパイルし直す。これで正しくメッセージが表示された。おや、時刻表示が\nによって行を換えて斜めに表示されてしまう。これはまずい。

「ねむい」さんから貰ったsyscallsのソースを確かめて見ると、_write( )で、\nがあると\rを追加している。そうか、これがそれを防ぐ仕掛けか。しかし、時間表示が延々と行を換えて出てくるのは時刻表示らしくない。

　そこで考え付いたのが、\nを\rに、\rを\nにひっくり返す方法だ。これで、\n\rとやれば、従来どおり行を換えて行頭から出力され、\nだけだと、行頭に来るが、行換えをせず重ね書きをして時刻表示らしくなる。恐らく標準ライブラリには、これらを定義する関数か、環境変数があるのだろうが、とりあえずの対策である。

簡易RS232Cの制作ではまる(6/13/09)
　今さらレガシーなRS232Cでもないのだが、COMポートの使用頻度が高くなったきたので、chaNさんの簡易RS232Cインターフェースを作ることにした。USB-UARTがあるから必要ないように思えるが、USBの仮想COMポートは、頻繁にファームを書き直し、リセットしては動かすマイコン相手には、極めて使い勝手が悪い。

　USBの仮想UARTは、セッションのときだけ存在するまさしく仮想的なもので、どちらかのアプリケーションが終われば無効になる。マイコンのように常にリセットするような相手では、PC側の端末ソフトはその都度、立ち上げなおさなければいけないし、フラッシュローダーも仮想COMポートが生きているように見えても実際にはマイコンだけでなく仮想COMポートもリセットしてから（コネクタの抜き差し）でないとつながらない。

　ARMのフラッシュローダーを使うようになってUARTを使う機会が増えた。BeagleBoardもブートローダーはシリアル経由だ。ChaNさんのAVRspもシリアルであり、シリアル、UARTの使用頻度は高い。幸い我が家の自作PCはレガシーなCOMポートがついている。いざとなったら16550を使った拡張COMポートインターフェースだってある（古いものなら何でもある。あ、あれはISAバスだったか）。

　ハードのCOMポートなら端末プログラムを立ち上げておきさえすれば、マイコン側がどういう状態であろうと常に動き出す。フラッシュローダーも端末プログラムを止めればそのまま動く。手始めにSTM32のTTL-UARTをRS232CインターフェースにするChaNさんの簡易RS232CをDSUBソケットに作ることにした。

　これはインバータICを使った至極簡単な回路である。これで+9V,-9VのRS232CラインがTTLになってしまう魔法のような回路だ。規格に合っていない邪悪な方法だそうだが、他のいくつかのサイトでも動作が確認されておりアマチュアが使う分には折り紙つきだ。ブレッドボードに組み、動きを確認する。作るのに1分もかからない。最初はPCからの送信がうまくいかなかったが、端末のフロー制御をしていないという例のオチに気が付いてジャンパーを飛ばして解決し、ブレッドボードでは何の問題なく稼動した。3.3VのVccなのに5Vの入力パルスが来るのが少し気になるが、これは実装のときに100KΩの抵抗を増やせば良いだろう。

　今度は基板を小さく切り取ってDSUBの変換基板に実装する。ところがブレッドボードでは苦もなく動いたのに、こいつが言うことを聞かないのである。TTLからの送信はできるのだが、PCからの送信が出来ない。フロー制御はコネクタで処置済みである。オシロまで持ち出した。結果、PCからの送信、マイコンにとって受信側が、送信データを拾って発振を起こしている。配線が近くなったから？まさか。

　それともインバータの手持ちがなかったので74HCU04というアンバッファータイプを使ったのが原因なのだろうか。Vccを3.3Vにしたので、RS232Cの電圧が高すぎ、ICをこわしてしまったのだろうか（100KΩを200KΩにして3Vまで下げた）。ICを取り替えてみたいが、こういうときに限ってICを半田付けしてしまっている。やれやれ。

　休みに家族と都心に出たついでに秋葉に寄り千石で74HC04を仕入れ、ついでに秋月で、本式のRS232Cのラインドライバー（ADM3202ARN　2ヶ ￥300)を用心のため買う。例の表面実装部品とりはずしの低温半田でインバーターICを取替え（これは確かに楽だ）、組み込みなおす。しかし当然、HC04でも動かない。頭を抱える。ブレッドボードでは問題ないのに。

　思い込みとは恐ろしい。結局、RS232Cを動かすのに3日もかかってしまった。オチは、ここに書くのも恥ずかしい、インバーターの入力ピンと出力ピンの取り違いである。ブレッドボードでは横並びにインバータを使い、実装では配線を短くするため、反対側の回路を使った。ピンナンバー順に入出力が並んでいると頭から思い込んで、片側の回路に入出力を逆につけて動かない、動かない、発振していると悩んでいたのである。

　データシートは見たが、思い込んでいるときは、こういうものである。ふんふん、下から入力、出力、入力、出力ね、とはなから自分で納得し図をろくに見ていない。昔、鉄道の単線で、全速力の列車の正面衝突という大事故の原因が、区間にひとつしかないタブレットという交換器の機械が空かない（実際にもう汽車が走っている）のは故障と頭から決め付けて、鍵をはずしてもう一方の列車に渡してしまった駅長さんの話を思い出した。

　動いたときは、本当に安心した。情けないという自責の気持ちより、これが動かずに終わったらこの先の気持ちの整理をどうしようかと恐れていたのだが、それをしないですんだという安堵感の方が強かった。くだらないことにくよくよする自分が情けなくてまたさらに落ち込むという鬱のスパイラルに陥るときがある。まあ、こんなことで一喜一憂しているのだから本当に安い娯楽だ。

やっぱり本式のラインドライバーは違う。フラッシュローダーが動く(6/14/09)
　手を動かしていると、こういう気持ちの納まらない時の気分転換になる。安全のために買ってあったRS232Cのラインドライバーを実験してみた。DIPではなくあえてSOICのADM3202ARNにしたのは、変換基板に必要部品も乗せてしまおうと言う魂胆である。

　ICのおまけに、チップコンデンサーが付いている（0.1μF、5×2)。これが、今まで実装したことのある20x12ではなく、もう一段小さい16x08（横1.6ミリ、縦0.8ミリ）だ。これをつけろというらしい。うーむ、変換基板の端子に普通のリード線のコンデンサーをつけるつもりをしていたが、挑戦状を突きつけられた感じだ。これは受けるしかないだろう。

　写真を見ていただければ良いが、これは面白かった。良い勉強になった、半田ごてをもう少し細いこて先にすればもっと楽だったかもしれない。被害はチップコン1個（ピンセットで強く挟んだ弾みに机から飛びはね行方不明になった）。まあ、このへんが手配線の限界だろう。

　ブレッドボードにDSUBコネクタと一緒に配線してテストする。うむ、配線違いもなく問題なく動く。オシロで波形を見る。きれいに+6V,-6VにわかれたRS232Cの信号が出ている。STマイクロのフラッシュローダーはどうだ。こいつは気難しくて簡易RS232Cでは動かなかったのだ。おおお、何の問題もなく認識した。やっぱり本式は違う。買っておいて良かった。

STM32基板のRTCを動かす

　それにしてもデバッグは難しい。わかってしまえば、何でこんなことに今まで気づかなかったのだろうというお馬鹿な間違いなのだが、気がつくまでの道のりは決して短くない。まあこの謎解きが面白くて電子工作をやっているようなものだが、今度のSTM32のRTC(リアルタイマークロック）プログラムも結構手こずった。「デバッグは外へ、外へ」などと偉そうなことを常日頃言っているくせに、頭に血が昇るとつい我を忘れてしまう。

軽い気持ちで手をつけたがまるで動かない（6/2/09)
　このところ1年前の雑誌の付録基板、STM32F103(Cortex-M3)　の開発に熱中し、先週、高速化したUSB仮想UARTのモニタープログラムを完成させて意気が上がっている。ウェブでもこの石を使ったCPUボードを時々見かけるようになった。価格もそう高くない（2インチ160x128のカラー液晶付きの評価ボードが￥9000で手に入る）。クロック72Mhzの32ビットプロセッサーだ。ARMコアの中では普及版だそうだが、アマチュアが遊ぶには十分すぎるスペックである。

　RTCはUARTモニターの開発のときから次の目標に決めてある。せっかくバッテリーバックアップ回路を追加したのだ。電池と32.767khzのクリスタルの顔を立ててやらねばならない。RTCはファイルシステムには欲しい機能だし（書き込みの記録）、これが動くと俄然マイコンがプロっぽくなる。幸いSTマイクロの提供するライブラリには、RTCのライブラリを使ったデモソースが収録されている。これを使えば簡単に出来るはずだ。

　早速Eclipseの新規プロジェクトを作り、そこへソースコード一式を放り込む。このソースはIARなどの開発環境用なので、仮想UARTモニター同様、GNUで必要な、Makefileや、リンカースクリプト、スタートアップルーチンを入れて調整する。Makfileを換えるだけでうまく行くはずだ。必要なライブラリを取捨選択し、ビルドする。殆ど問題なくバイナリーが出来た。

　わくわくしながら、フラッシュローダーにかける。おやあ、赤ランプがついて送れない。ええー、hexファイルがないだと？　ほんとだ。ファイルはあるけれど中身は0バイト。これは一体どうしたことだ。elfファイルは60KB以上あるのに。コンパイラーもリンカーもエラーは出ていない。こうなると何が悪いのか見当がつかない。

　マップファイルは出来ていたので、良くわからないままこれを調べる。あれ、関数のエントリーがみな同じ値だ。これはおかしい。でも、エラーは起きていない。念のため、必要なライブラリの数をMakefileで確かめる。一つ少ない。あれえ、stm32f10x_vecter.cが抜けている。デモソースのreadmeには、これを入れろとは書いていない。

　何と言うことだ。こいつがないからに違いない。とにかくこれを含めてビルド。おお、ちゃんとしたhexファイルが出来た。readmeを信じてえらい目にあった（このあと各開発環境のプロジェクトフォルダーにはこのモジュールが入っているのを発見した。GNUのときは注意しないといけない）。それにしても、ビルドやリンクのときのNO ERRORは安心できないことを学ぶ。

　お膝元のメーカーのデモソースである。バイナリーが出来たので簡単に動くかと思ったが、これが全く動かない。おかしい原因はおおよそ見当がついている。UARTへの出力関数printfが恐らく暴走の原因だ。これを、これまで使っていたsprintfに置き換え、受信関数も自前のものにして再度、実行。

　おお、やっとメッセージが出た。しかし、RTC not configured...のメッセージを出したまま、それっきりになる。ロジックを追うと、RTCのセットアップが終わるのをループで待っていて、ここがreadyになっていないようだ。やれやれ、ハードか。念のため電圧を測る。3.24V。この程度なら問題ないはずだ。オシロで周波数を確認する。立派に32.767khzが出ている。大丈夫だとは思うが、要因を減らしてみよう。

　バッテリーバックアップをやめてVccにつなぎなおす。うわあ、RTC configuredのメッセージが出て先へ進んだ。何だ、何だ。電池が原因か。何か部品が足らないのか。

　ハードの問題は別として、これでうまく行ったと思ったら、そうは問屋が卸さなかった。時刻の設定をする受信関数が、がんとしてデータを読まない。受信関数は自前だ。自信がないので、プログラムの頭でテストステートメントを挿入してみた。いや、ちゃんと動く。しかし、時刻設定の入力では、受信データのフラグがあがらない。

　それにしても、UARTぐらいの機能で、このソースの複雑さは何だ。読みにくいことおびただしい、と悪態をつきながらデバッグする。また最適化が原因かと思ってループに、NOP_Processなどを入れるが変わらない。UARTなら、このあいだのGNUサンプルソースにもあった。こちらは至極簡単なソースだ。こいつを持ってきて動かすが、これも駄目。万策がつきる。

原因はUARTではなかった。あっけない幕切れ(6/5/09)
　UART受信が出来ない。本質と関係のないところでつまずいている。RTC不調も電池でない可能性が強い。電源を入れたままリセットをすると、RTCの初期化が途中で止まる。

　UARTの方は、その後ステータスレジスターを問題のところで出力させ不正なビットが立っていないことを確認した。どうもUARTがハングの原因ではなさそうだ。LEDとUART出力を処理の始めから、少しづつ挿入し、ハングアップするステートメントを探していった。

　その結果、RTCの割込みをenableするところでハングすることがわかる。RTC割込みがおかしい。試しに割込みルーチンにLEDを点灯するステートメントを入れるが、点かない。そうだこれに違いない。

　デモソースのバグは考えられないので、これは明らかに、Dfuのためにずらしたプログラムのエントリーアドレスが、ベクターテーブルに反映されていないことを物語る。しかし、ソースの何処を探しても、テーブルのアドレスを設定するところはない。ベクターテーブルは、リンカーの最初のプログラムのスタートアドレスから相対的に展開しているからだ（これが大きな勘違い）。そうすると、リンカースクリプトか、スタートアップルーチンか。しかしここは良く分からないところで手が出せない。

　思い余って、最近お世話になっている「ねむい」さんが、RTCを動かしたと言うので、質問しようかとページを開いたら、ソースを公開されている。質問する前に調べてみようとありがたくソースを頂く。（会社ではダウンロードできなかった）

　おお、このソースは情報の宝庫だ。ユーザープログラムで割込みを止めるステートメントもある。で、ベクターテーブルを設定するところは、どこだ。見つかった。あ、あ、あ、なーんだ。明示的に設定するのだ。

void NVIC_Configuration(void)
{ NVIC_InitTypeDef NVIC_InitStructure;
  /* Set the Vector Table base address at 0x08003000    for Dfu  */
  NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x3000); 

　早速、このステートメントを追加し、コンパイルしなおす。苦もなく動き始めた。全く問題ない。1秒ごとにLEDが点滅し、UARTに時刻が表示される。RTCの出来上がりである。これで、この週始めから悩んでいた問題がすべて解決した。いやあ、知らないと言うことは恐ろしい。NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0); のステートメントでもあれば気がついていたかも知れないが、それにしても「ねむい」さんに感謝である。

　しかし、何故、割込みが原因だということに気がつかなかったのだろう。UARTの不具合と頭から思い込み、こればかりを追求していた。RTC割り込みは1秒である。ちょうど時刻設定の入力と重なる頃だ。一瞬入力が出来たときもあり、少し冷静に考えれば、このとき不具合がUARTでないことにもっと早く気がつくべきだった。

　電池が入っているときに動かないのは、時刻設定をしないで単に時刻表示に行くからで電池が原因でハングアップしていたわけではない。しかも、付録の雑誌の7月号には、このベクターのオフセットをしないとデモなどは動かないよ、とわざわざ解説がステートメント付きで載っていて、これを読んでいたはずだ。この前の仮想UARTのhw_config.cにもちゃんとベクターのシフトがコーディングされている。今になって考えるとヒントはそこらじゅうにころがっていたのだ。お恥ずかしい限りである。

Beagle Boardを動かしてみる

　話は少し前後するが、このあいだ手に入れたBeagle Boardの動作試験の報告である。ウェブ上には既に沢山の人の動作報告があがっているので、今さらの感もあるが、自分の備忘録を兼ねてまとめておく。いや、こいつはすごいマシーンだ。

Linuxの組み込みバージョンAngstromの立ち上がりまで(5/29/09)
　STM32の開発が一段落したので、懸案のBeagleBoardを触っている。足りなかった部品、UARTケーブルは、このあいだ既に作ってあり、ROMモニターが動くところまではテスト済みである。

　次のステップは、ここにLinuxやAndroidなどのOSをインストールすることである。例によって先人の経験をありがたく参考にさせてもらうことにする。お手本にするサイトは、既にここに決めてある。このサイトは前から評判になって目をつけていたところで、ここではLinuxの組み込みバージョン、Angstrom(オングストローム）のデモ版を動かすところまで丁寧に教えてくれる。本当に良い時代になったものだ。

　このサイトの著者はちょうど私と同じソフト系の人で知識の層が似ており理解が早い。恐らく私より遥かに若いのだろう。UARTのフロー制御を「なし」にしないと動かないので苦労したというところで笑った。昔シリアルが全盛のときは、フロー制御をしない「フリーランニング」という結線があり、これは、シリアルのCTSとRTS、DSRとDTRをコネクターの中で結んでしまう。

　こうすると、片側がフロー制御を要求する機器であっても問題なくつながる（自分が要求したものが返るので）。もちろん本当のフロー制御はできない。上品な言い方ではないが「垂れ流し」とも言っていた。そうか、シリアルはもう誰も使っていないので、こういうことは忘れられているのだろう。年をとったことを実感する。

　それはとにかくこのOSのインストールにあたっての問題は、UNIX（Linux)マシンが手元にないことである。Linuxは10年ほど前、今の電子工作同様熱中し、家中のPCや会社のPCにインストールしまくっていたが、今はすっかり手元にない。

　へそ曲がり、天邪鬼な性格なので、みんなが騒ぐようになるとかえって熱が醒めてしまう。Linuxも企業が使うようになってシステムが巨大化し、何か開拓者精神のようなものが失われたような感じがして興味が薄れたこともある。

　BeagleのためにLinuxをインストールするのも何なので、前から残してあったKnoppixのCDでLinuxを立ち上げてみた。ところが、このKnoppixのCDが古く、途中でどこかのサイトにリソースを取りに行く途中で止まってしまう。日付を見たら4年も前のCDだ。

　これじゃあ、いくら何でも古すぎる。久しぶりにLinux関連のキーワードでサイトを探した。最新版のKnoppix(6.1)を落とし（600Mだけれど数分。いや便利になった）、CDに焼いて立ち上げてみた。

　いやあ、立ち上がりの早いの何の。あっという間にLinuxが動き出した。ほんと浦島太郎の気分である。こんなに早いのなら、これを実用としても十分使える。

　SDカードのフォーマットが少しややこしく（fdiskを間違えて、fdisk /dev/sdc1とやって大はまり。 昔もよくやった）、UNIXのコマンドがなかなか思い出せず苦労したが、長い名前のファイル名の入力も、Xの上の端末なので、コピー＆ペーストで間違いなくできて、システムを入れたSDカードが完成した。この時点で夜中の３時。ここまで来たら、最後までやるしかない。BeagleBoardにビデオケーブルをつけ（ケーブルの方が重くてケーブルを動かすとボードがふらふらする）、通電する。

　おお、カーネルロードが始まった。流れるようにメッセージが続く。うむ、順調のようだ。よーし、Angstromのロゴがキャラクタ画面に出た。Loginプロンプトでユーザー名を聞かれて弱った。始め設定かと思って新しいユーザー名、パスワードを入れるが反応しない。夜が白み始めて頭がもうろうとしているので、よくわからない。やけっぱちでrootと入れたら動いた。

　ばかな話である。Linuxの初期設定のあたりをすっかり忘れている。最初はrootしかいないのだ。Xの方はどうだ。残念。画面はこのモードをサポートしないという表示でEnlightmentは動いていない。まあ、動いたことだけでもよしとしよう。部屋を片付けて店じまいする。

　次の日。グラフィック環境が動かない原因がわかった。まだ環境変数を設定していなかった。 グラフィックボードへの設定を、環境変数に設定すると、見事にLOGIN画面が出た。思わずキーボードを叩いてしまって、苦笑いする。USBにまだキーボードがつながっていない。USB-LANとセルフパワーのHUBをまだ買っていない。まあ、LOGIN画面まででたので大丈夫だろう。

　キーボードと、USB-LANアダプター、HUBをアマゾンに発注した。最近はPC用品を通販で買うことが多くなった。値段が安いのである。価格.comなどの安売りランキングを見て、秋葉原に行っても必ずしも同じ値段で買える訳ではない。しかし、アマゾンなどは、安売り通販ショップに伍して、負けていない。秋葉でうろうろするより安いことが多い。

あっけなくウェブブラウザーまで動いて拍子抜け(5/31/09)
　アマゾンからUSB関連の品物（エレコムワイヤレスキーボードTK-FDP001WH、コレガUSB－LAN  FEther USB-TXC）が届いた。早速BeagleBoardにつないでみた。HUBはまだ到着しないが、今使っているセルフパワーのHUB（エレコムU2H-TAP3420SWH)をこちらにつなぐ。こいつはUSB－UARTコネクターの抜き差しをスイッチで出来るように買ったものである。USBマウスは、ウェブでは不調と言われたEeePCにオマケについていたもの(Arvel MS35MBL)。

　ブートする。シリアルポート(COM1)に順調にメッセージが流れ、Angstromのロゴが出て無事に立ち上がったようだ。画面を切り替える。ソフトキーボードのログイン画面が出た。さあ、キーボードが入るか。おおお、ちゃんとパスワード入力がキーボードからできる。Enlightmentの画面に替った。マウスは？これも問題ない。

　なんだなんだ。何の問題もなく認識するではないか。ブートメッセージを見ていくと、キーボードの型番までしっかり出ている。昔のLinuxとは大違いだ。海外の情報を頼りに新しいI/Oディバイスを認識させるのが、インストールのときの大仕事だった。

　次は一番問題のLANだ。うまくいったので調子に乗って、動いたままUSB-LANを接続する。活線挿抜というやつだ。ほほう、何か動き始めたぞ。いかん。コンソールには eth0が設定されたが、downしているというメッセージが出た。ifconfig eth0とすると、IPアドレスが定義されていない。やれやれこれは自分でやれと言うことか。

　これが、ちょっと前までさんざん使っていたコマンドがもう思い出せない。gatewayはどこだ。pingを入れたがやっぱり外へでていかないぞ、とやっているうち、ifconfig eth0を入れてみたら、さっき定義したIPアドレスが変わっている。あれ、どうしたの。そうかDHCPが動いたのか。物は試しと、Elightmentのウェブブラウザーを立ち上げて見る。

　何と、何と、ネットがつながっている。Mogillaの初期画面が出た！いやあきれたものだ。何もしないで、全部つながってしまった。日本語フォントが入っていないので字化けしているが間違いない。余りにも簡単にイーサネットが動いてしまってあっけにとられるばかりだ。

　これは一体何なのだ。一区切りがついて考えた。BeagleBoardは明らかに今までの組み込みコンピューターとは違う。要するに、小さなボードで電子工作っぽいけれど、もう、ここまで来ると、これは電子工作ではない。ここはLinuxと変わらない。世界が全く違う。

　ハードに素人が立ち入る隙がもうないのだ。それにソフトウエアの規模が大きすぎる。ARM7あたりまでは、まだソースを追いかける気力があるが、このレベルでは無理だ。別の趣味に近い。

　これはこれで昔、Linuxにはまっていたから、がた老「AVR」研究所としては研究の意味はあるが、8ビットの石を工夫して機械にしているときの、わくわくする気持ちがない。
嬉しいことに、このあいだのSDカードのLPCMプレーヤーは、周りの複数の人から発注を受けて量産を考えなければいけなくなった。はじめてのプリント基板制作に挑戦しようかとも考えているが、電池ホルダーが難物だ。これの自作はちょっと大変だが、物を作る喜びは、こちらの方が大きい。

　BeagleBoardは、ケースを考えたり、日本語フォントのインストール、それとウェブサーバーとしての能力をテストする課題などが残っているが、これはもう電子工作とは別の次元の話だ。まあ、がた老AVR研究所としては、BeagleBoardは余技としておこう。本業はあくまでもAVRクラスだ（最近はARMばっかりだけど）。

ダブルバッファーでUSB仮想UARTの内部速度が2Mbps

しゃれた実装を考えたが挫折(5/28/09)
　SysTickタイマーで1ms単位の経過時間が測れるようになったので、勇躍、STM32基板のUSB仮想UARTの高速化にとりかかった。これまでにわかっていることは、UARTの速度が遅いときは問題ないが、早くなってくるとエンドポイントの送信終了の割込みがユーザープログラムがデータを移している最中に入り、このときのデータサイズが実際のデータと不整合が生じてデータが欠落する。

　これはSTマイクロが提供するSTM32F(Cortex-M3)用のVCPデモプログラムに最初からあった問題で、STマイクロのフォーラムで去年話題になり議論されていた。少なくとも私の知る限りまだ解決していないはずである。SysTickを使って改修されたコードがアップされたが、その後本人が動かないとして取り下げている。この解決を当研究所がやろうというのである。もしうまく行けば鼻が高い。

　方式はダブルバッファー方式である。前のDACのデコードと同じような考え方だ。ひとつのバッファーをユーザーの送信関数の書き込み用とし、ここに送信データを入れていく。送信関数ではエンドポイントに直接書き込まない。ここで書き込むと、書き込み終了の割り込みがどこで起きるかわからないからである。もうひとつのバッファーは、割込みルーチンが既に書き込み処理をしたデータが入っている。

　書き込み終了の割込みがかかり、割込みルーチンに制御が渡ったときに、バッファーをスイッチして、今度は送信関数が書き溜めていたデータをエンドポイントに書き込む。さきほど送り終わったバッファーが今度は送信関数が新たに書き込むバッファーとなる。これで、データ書き込みと送り出しの衝突を避けることができる。

　最初、コードを少なくするため、2組必要なバッファー配列とカウンターをポインター変数にし、そのアドレスをスイッチして動くようなスマートな方式でコードを組んだ。
バッファーに送信バイトを送り込むとして、

　* ( バッファーアドレス +  * カウンター++ ）=  送信バイト;

みたいなプロっぽいコードである。バッファーアドレスとカウンターポインターを取り替えるだけで、main.cの送信関数USB_Putc()はダブルバッファーであることを知らないで済む。いやコーディング技術も格段に進歩したものだ、と、得意になって完成させた。ロジックはそう難しいものではない。気をつけないといけないところは、バッファーを切り替えるときに、ユーザープログラムの実行と重ならないように、フラグを立てて守るということである。今度は、割込みルーチンが見えているので、ユーザー側は、そのフラグを見て待てばよい。

　と、これが全くうんともすんとも言わないのである。どうもさっきのステートメントのところで暴走している。表記に間違いはないはずだ。何度もウェブなどで確かめる。うーむ、何か勘違いがあるのだろうか。プログラムはまさしく考えたようには動かない。書いたように動くだけだ。いずれにしても、ポインターを使ったコーディングは一歩間違えば、とんでもないところにデータを書き込み、簡単に暴走してしまう。

　色々いじったが好転しない。悩んだ挙句、この方法をとりあえずあきらめ、普通の配列を使い、愚直に2組のバッファーを別々に操作するルーチンに切り替えた。さあ、これでどうだ。これなら暴走しようがない。もう問題ないはずだ。

　ありゃりゃあ、これでも動かない。ええー、どこが悪いんだ？　シングルバッファーに戻すと何事もなく動く。わからない。このあたりでGDBが使えれば良いのだが、今のままでは、USBを使っているので初期化の段階で、HardFaultに落ちてしまいメインループに来ない。環境を大きく換えないと使えない。別のUARTで変数を出してデバッグする手もあるが、どちらも手間がかかる。

ダブルバッファーが動いた！しかしこれで良いのか(5/29/09)
　開発が暗礁に乗り上げている。マラソンや登山と同じだ。この苦しみが歓喜の材料なのだが、その最中はそれどころではない。大げさに言えば人生が暗い。今まで生きてきたことすべてが意味のない時間だったような気分になる。

　BeagleBoardのために久しぶりにモニターを取り替え、1920x1080のワイドディスプレイになって開発環境は一変し（エディターと端末が同時に見られる）、快適になったのだが、気分は優れない。救いは、このあいだの第三のファーム書き込み手法ROMのフラッシュローダーが思いのほか使い勝手が良く、プログラムの修正、ビルド、ファーム書き込みのサイクルが飛躍的に早くなったことである。AVRなみの開発環境である。Eclipseは編集とビルドだけにしか使っていないが、これはこれで便利だ。

　それはともかく、ダブルバッファーが動かない。基本的なところを少しづつ確認していくしかない。何回目かのコードレビューの最中に、ふっと気がついた。送信関数は律義にバッファーにデータを溜め込み、一杯になれば、割込みルーチンがバッファーを切り替えるのを待っている。では誰がUSBのエンドポイントに書き込むのだ。あ、あー、ここだ。エンドポイントに書き込む処理は、エンドポイントに書いた後の割込みルーチンにしかない。ポインターの暴走でもなんでもない。元から動かない。

　何と言うお馬鹿なコードだ。これでは永遠に送れない。しかし、どうすれば良いのだろう。頭の中が混乱する。何か根本的な間違いがあるのかもしれないが、ロジック的には一度mainの初期化のところでエンドポイントにデータを書き込む呼び水のようなダミー処理をすれば良いのではないか。そうすれば次々に割り込みが連続し、うまくいくのではないか。

　やってみた。やっほー、動いたぞ。ダブルバッファーの仮想UARTモニターが前と同じように動き始めた。転送速度を測る。ややや、2Mbpsだ。素晴らしく早い。1KB送るのに数msしかかかっていない。そりゃそうだ。バッファーに1バイトづつ送るだけで60kbps近くあったのだから、その64倍だったら3Mbps近くあっても、おかしくない。

　もちろんこの速度は、単に内部でUSBドライバーが受け取った時の速さで、実際にホスト（PC)との仮想UARTでの転送速度ではない。しかし少なくとも内部では安定的にメガビットのオーダーでデータが送れたことになる。

　肝心のデータ欠落をチェックするために、同じ文字でなく、"0123456789"の文字列を送ってみる。うむ、全く欠落はない。きれいに数列が画面上に並ぶ。1字の落ちもない。いやあ、至福の瞬間である。今までの暗い気持ちが吹き飛び、天下をとった気分になる（相当中毒が進んでいる）。

　しかし、ロジックとしては不満がある。今の状態は、データがなくてもエンドポイントに立て続けに書き込む処理が動いているはずだ。今は単なるモニタープログラムなので関係ないが、別の仕事をするときはCPUリソースを無駄に使っていることになり効率が悪い。

　というので、エンドポイントの割込みルーチンにデータがなければ処理をやめるようにし（割込みが止まる）、送信関数には、バッファーが何もないときのデータ送信では、ダミーのエンドポイント書き込みを入れるようにしたが、こいつはまた全く動かない。

やっと満足できるコードになった(5/31/09)
　速度が2MbpsまでになったUSB仮想UARTだが不満が残っている。呼び水方式で、USBのエンドポイントにデータを送るところまでは良かったが、これでは送信していないときも延々とUSBドライバーは0データを送り続ける。

　送信データがないときはこの繰り返しを止め、データが来たときに再開するロジックを色々考えて試してみるが、ことごとく失敗する。奇怪なことに、メインルーチンの初期化でダミーの書き込みをすると上手く行くのに、送信関数の中でやると先に行かない。

　この間の差は時間だけだ。余りやりたくなかったがタイマーを入れて調整することにした。しかし全く変わりがない。何か変だ。このタイマー（元々の雑誌のソースに入っていたもの）は

   Delay( int i) { while(i)  i--; }

という簡単なコードだが、iをいくら増やしても変わりがない。コンパイラーの最適化を疑ったが、i--は立派な処理だ。無効になるわけがない。それにこの関数は、前から使っていたはずだ。

　しかし、やっぱりおかしい。念のため、コマンドを新設してこいつの待ち時間をSysTickの時間で測ってみた。うひゃー、全部0で帰ってくる。何と言うことだ。コンパイラーがこのステップを取ってしまっているに違いない。

　AVRでやったように、ループにasm volatile("NOP");を入れる（これはアセンブラーコードでなくマクロだそうだ。従ってARMでも共通）。ちゃんと待ち時間遅れが作れた。やっぱりコンパイラーの仕業だ。　雑誌で動いていたのは開発環境IARとGNUの違いだろう。それにしても、i--　がどうして無駄なコードなのだ。理解に苦しむが文句を言っても始まらない。

　ところが、待ち時間を作ってもうまく行くときと行かないときがある。時間待ちはあくまでも対症療法だ。やはり基本から確実な方法を探すしかない。もういちどソースコードをひとつひとつ追いかけて手順を考えることにした。

　BeagleBoardのセットアップ（次記事で紹介）で少し日をあけたのが良かったのだろう。良い方法を思いついた。これまで送信関数の方ばかりに注目して、何とかしようとあれこれ考えていた。しかし、割込みルーチン側で動作モードを設定していけばうまく行くことに気がついた。そうなのだ。送信関数は、いつどこで割込みを受けるかわからないのでデータカウントが変わる可能性がある。バッファーを制御するスイッチにもうひとつ「データなし」というステイタスを追加してプログラムを組み直した。祈る気持ちでテストする。やった。前と変わりなくデータが送信できた。

　CPUのオーバーヘッドが明らかに減っている。その証拠に先のループで待つウェイトルーチンの時間が早くなったのだ。すごい。はっきりと差がわかる。時間にして3%くらい早くなっている。やっとまともなコードになったと思う。

　ソースコードの公開は迷った。単に大量送信の時間が表示されるだけの、このままでは実用性０（ゼロ）のモニタープログラムである。まあ、これをベースに色々アプリケーションを考えれば役に立たないわけでもない。がた老「AVR」研究所の記念すべき、初の「ARM」プログラムソースでもある。

　人のソースを流用させてもらっているが、殆どのソースは雑誌からなので問題ないだろう。STマイクロのデモプログラムも、ソースリストに「責任取らないからね」という文言しかないので問題ないと判断した。Makefile、リンカースクリプトとスタートアップルーチンはこちらのお世話になった。この場を借りて御礼申し上げたい。

 ソースファイル一式（ライブラリ、リンカースクリプト、Makfile）をここにおきます。Eclipseのプロジェクトファイルですが、Eclipseがなくても動きます。また、実行させるだけなら、STM_VCPDフォルダーの中のstm_vcpd.hexをDfuか、フラッシュローダーで書き込めば動きます。

「STMVCPD_archive.lzh」をダウンロード

 コンパイルの簡単な手順は以下の通り。

・コンパイラー（CodeSourcery G++)をここからダウンロードする。（OSはEABI、Sourcery G++ Lite 2009q1-161を選ぶ。　5/31/09現在）
・解凍したフォルダの下のSTM_VCPDフォルダーにカレントディレクトリを置き、DOS窓でコンパイル(make all)する。 FWLibや、USBLibのディレクトリの位置は変えないこと。換える場合は、Makefileを修正する。

・また、gccの標準ライブラリとヘッダーファイルは、gccの入っているbinフォルダーと同列のarm-none-eabiフォルダーの中のlib\thumb2下のライブラリと、include下のヘッダーを使っている。正確にはMakefileを参照。

・解凍ファイルの中のFWLibや、USBLibはV1.0で、現在のV3と混在させると動かない可能性がある。
・出来上がったhexファイルをDfuか、フラッシュローダーでファームに書き込む。
・STM32の電源を入れ、PC側の端末プログラムでUSBのVCPに接続し、何かキーを入力すると、WelComeメッセージが出る。

SysTickを使ったSTM32のUSB仮想UARTの速度測定

転送速度を測ろうとはじめたタイマーの設定に難航する(5/22/09)
　RTC（リアルタイムクロック）のプロジェクトの前に、もう少し仮想UARTモニターをまともなものにしようと色々考えている。週2日出ている事務所の往復がこういうロジックをまとめる格好の時間だ。

　今のプログラムの送信データ量はパケット１個あたり、わずか1バイトだ。USBの送信ポーリング周期を1msとすると、ボーレートは8kbpsしかいかない。今はキーボードからテストメッセージを出しているだけだからこれでも良いが、SDカードあたりのテストでは、少々遅すぎる気がする。

　ダブルバッファーにすれば、理論上では、エンドポイントのパケットバッファーが64バイトあるので、64×8×1000、512kbpsまでスピードを速めることが出来る。これならUARTの最速460kbpsでも楽々だ。やりかたはそう難しくない。バッファーを２つ作って、セマフォーのようなフラグを立て、空いている方へデータを移動させればよい。バッファーが満杯になれば、そこが0になるのを待つだけである。ついでにインターバルタイマーを入れて経過時間を表示するようにすれば改良の成果が良く分かるし、タイマーの勉強にもなる。これは面白そうだ。当面の目標をこれに決めた。

　そこで、STM32のタイマーを詳しく調べ始めたが、これがAVRと違って設定がとんでもなく大変である。高機能タイマーでなく、汎用のタイマーでも設定するレジスターの数は、数えてみたら何と20個もある。こちらはPWMのような複雑なことをやるわけでなく単純なインタバルタイマーが欲しいだけなのだが、これでは、まともに設定するまでどれだけ時間がかかることやら見当がつかない。どこかの応用例を見て組んだほうが早そうだ。

　タイマーなら、最初のテストに使った雑誌（DWM2008/6）のGNUサンプルソースにもあり、10ms単位で時間が測れる。しかし、こちらはSysTickを使ったタイマーで、ここでの設定はレジスターを直打ちで定義しているため、現在のソースに簡単には組み込めない。SystickはCPUの根幹部分であり下手に設定を変えると全く動かなくなる恐れがある。これも容易な作業ではない。

　どちらも壁が高いので、とりあえずは今動いている仮想UARTモニターから、不要なコードを取ってスリムにし、追加開発を楽にしようとした。ところが、これも結構難しいのである。もともとこのコード（蛙がピョン）はSTマイクロのVCP（Virtual COM Port）デモプログラムをベースにしている。ADCやDMAはそう問題なく削除できたが、UARTの関数群がはずせない。仮想UARTと言っても、外にだすわけではない。モニターの内部でUSBとの仮想UARTの入出力をするだけだから、外部のUARTは全く不要なのだが、これが微妙にUSBルーチンとからんで、取りすぎるとコンパイルエラーになったり、暴走したりする。

sprintfの不具合解消。リンカースクリプトの不整合だった（5/24/09)
　少しづつコードは減ってきたのだが、そのうち、仮想UARTモニターが途中でリセットがかかるようになってしまった。最初は、データを出力した直後一回リセットされるだけで、そのあとは問題なかったのだが、コードを減らしていくうち、遂に出力も出さずハングアップしてしまう。

　どうも、以前AVRで経験したスタックがデータをつぶしていく不具合に似ている。プログラムサイズをかえるとトラブルが変化するというのは、こういうときの典型的な現象だ。sprintfの実行で暴走するようなので、sprintfを再びコメントアウトするとOKとなった。やっぱりここが原因だ。うーむ、ヒープ開始アドレスがうまく伝わっていない感じである（ハングとは関係ないがsprintfをとるとフラッシュサイズは37 KBから11KBまで劇的に下がった。そうかGNUではこのへんがタコなのだなと納得）。

　良くわからないがマップファイルを調べる。ARMのマップファイルはAVRのnmコマンドと同じくらいの情報量があり（恐らく同じコマンド）、何とか書いてあることがわかる。ヒープアドレスを示す_endも載っている。あれえ、このアドレスがmain.cのSRAM変数の最初をさしている。このままではもろにかぶるはずだ。おかしい。

　暴走の原因を確認するため、とりあえずはヒープのスタートアドレスをmain.cの変数が終わったところのアドレスに、マップファイルを参考に決め打ちし、sprintfを入れてテストしてみた。おおお、うまくいった。リセットもせず快調にsprintfが動く。

　やっぱり、データのかぶりだった。しかし、何故、_endが正しくエリアの最後を指さないのだろう。今まで敬遠していたリンカースクリプトの勉強が必要になってきた。ウェブで調べ始める。このあたりはコンピューターシステムの専門分野でも一番奥の技術に相当ししかも機種依存が大きく、メーカーの技術者でもここに詳しい人は滅多にいなかった。

　昔はほとんど情報が外に出ない部分だったが、さすがはGNUである。沢山情報がある。ありがたい時代になったものだ。おおよその文法がわかったので、ウェブから拝借してきたリンカースクリプトファイル、memory.defを調べる。

　もういちど、マップファイルにもどって中身を見てみる。おや、COMMONというセクションがあり、これらがすべて.bssのあとに割り付けられている。これはmain.cの変数だ。

　おやおや、COMMONは、リンカースクリプトの.bssの範囲に入れないと全部外に出されてしまう。なんだやり方が書いてあるではないか。オブジェクトファイルかリンカーオプションの宣言の不一致だ。COMMONを.bssの中に入れなおす。

　　.bss : {
        . = ALIGN(4);
        _sbss = .;
        *(.bss)
        *(COMMON)      /*　ここを追加する　 5/24/09 */
        . = ALIGN(4);
        _ebss = .;
    } > RAM          

　コンパイルする。やった。きれいに最終アドレスが_endに入った（sprintfで_endを表示させて確認）。やっとリンカーの仕組みもわかってきた。いやあ、組み込み系は奥が深い。30年前にやっていた大型機のオンラインシステムのシステム生成（シスジェンと言っていた）の経験が役に立つとは。この経験があったから、リンカースクリプトもそれほど恐怖感なく眺められたが、経験のない人にとっては、恐らく記号の密林に立ちすくむばかりだろう。ここはやはりかなり特殊な世界だ。

　いつになく気分が良い。今度のトラブルシューティングは、昼なお暗いジャングルか真っ暗闇の洞窟のアドベンチャーゲームで、何か動いたのであてずっぽうに撃ったライフルの弾が見事に怪獣に命中したのと同じような気分だが、それでも全く偶然ではない。仮説にもとづいて手順を考え、その結果トラブルが解消したときは、どんなささいなことでも格別良い気分である。嬉しいことにもうひとつの不具合も解消した。

　NOP_Process( )がないとハングする原因は、「ねむい」さんからコメントがあり、コンパイラーの最適化のやりすぎではとの指摘があった。これまでテストできなかったが、ついでなので指摘どおり、外部参照宣言(extern)にもvolatileをつけてコンパイルしてみた。結果はその通りでどちらのNOPも必要なく、プログラムは問題なく動いた。変数宣言の方にはvolatileをつけていたが、externにまで必要とは思わなかった。

1バイト送信で57kbpsも出ていることがわかる(5/27/09)
　タイマーの勉強はなかなか進まない。8ビットのAVRのときは楽だった。単純な8ビットタイマーのオーバーフローから始めて自然に複雑なコンペアレジスターを使ったPWM制御まで理解できたが、いきなり10個以上のレジスターを前にして、さあ設定しろと言われても簡単にできるわけがない。32ビットプロセッサーは明らかに初心者向けではない。付録基板のついた雑誌には季節的に良く初心者向け特集などと銘打ってあるが、これは明らかに誤りだ。

　本当に初心者向けに基板を付録にするなら8ビットプロセッサーでないと無理だと思う。もっともこれでは基板に魅力がなくなり売れないのだろうけれど、32ビットプロセッサーの付録基板で、向学心に燃えた初心者が、途方もない壁にはばまれてどれだけたくさん挫折しているかと思うと心が痛む。ステップを踏みさえすれば、そう難しいものではないのに。

　それにしても、良いお手本が見つからない。見つかってもレジスターを直打ちで設定しているソースコードなので、STマイクロのデモソースベースのコードで動くか自信がない。SysTickを使ったタイマーの方が簡単そうなので、STマイクロのハードマニュアルや、ライブラリのSystick.cのソースを調べるが、ソースはいつもの長ったらしい変数の山で全くイメージがつかめない。マニュアルはOSのTick割り込みを意識した書きかたでこれも良くわからない。

　それでも収穫はあった。SｙｓTickはシステムクロックとは独立したリソースで、Tickをだすタイミングを設定するレジスターは根幹部分のクロックリソースとは独立しているということである。そうなると、このあいだのGNUサンプルのSysTickを使ったタイマーが使えそうだ。

　定義を仔細にみていくと、SysTick関係の定義部分だけ持ち出せば、他に影響がなさそうだ。始め関係があると思ったのは、システムクロックの変数が大量に使われていたためだが、よく読むと、これは単に参照しているだけで本体とは関係ないことがわかった。

　まあ、何かがこわれるわけではない。SysTickハンドラーの割り込み先は、デモソースの中に既に定義済みだ。ここにカウンターを入れて、GNUサンプルの定義部分を慎重にとりだし、適当なテキスト表示の前後にタイマーステートメントをはさむ。

　動かしてみた。最初は0としか表示されなかったが、設定を変えると、1という数字が表示された。おお、動いている。少しづつ設定を調整して、それらしい時間がでるようになった。sprintfを直しておいて良かった。プロンプトの前にmsで時間を表示するモニターが動き始めた。リターンキーを打つ間隔がこれで測れる。

　雑誌では10msのTickということで、定義を調整し（それらしい定数を10倍した）、1msにしたが、どうも少し早い。ストップウォッチで時間を測る。1秒で、1500位のTickだ。さらに調整して1msのTickにする。いよいよ転送速度の測定だ。

　おやあ、想定した8kbpsよりもっと早い転送速度だ。56kbpsは出ている。何度か、計算式を確かめる。間違いない。USBの外への転送ポーリングは1msだが、中はもっと早いタイミングなようだ。少なくとも8倍近く早い。そうか、STマイクロのVCPデモプログラムがV3でも改善されていないのはこのへんまでは破綻をしないためだ。これは今度のダブルバッファーの実装は楽しみになってきた。115bpsや、230kbpsでも動くVCPは喜ばれるはずだ。

JTAGは気難しい。恐れていた事態が現実になる

　Eclipseの環境が出来て一息入れたのも束の間、がた老AVR研究所は、次々に事件、出来事が発生し、その対応に追われて仕事どころ（あ、いや、一応、まだ週2日程仕事しています）ではない。

BeagleBoardが届いた(5/14/09)
　4/29に発注して、連休中毎日のようにDigiKeyのサイトをチェックしていたが、注文受理から、なかなか発送のステイタスに変わらずイライラしていた。アメリカも連休だったのだろうか。しかし、11日にステイタスが出荷済みになってからは早かった。何と2日で配達されてきた。13日は家人が不在で、今日14日に無事手元に届いた。電話で用途を聞かれたりするそうだが、全くそれらしいことはなし。ハンコを持って受け取りに行ったら、ポータブル端末のスタイラスペンを渡されてサインを求められる。さすが海外便だ。

　受け取ると、中身が入っているのかと疑うほど軽い。初の海外からの通信販売品である。記念写真をとる。充填材の中から可愛い箱が出てきて、いよいよあこがれのBeagleBoardとのご対面。電源アダプターには親切に5Vの表示ラベルが張ってある。モジュラージャックだと思っていたソケットはビデオのS端子だった。え、Sケーブルでも良いの？

　がた老AVR研究所のハイエンドマシンである。このあいだ8 ビットプロセッサーから32ビットにいきなりあがって大変だったが、今度も大飛躍である。CPUチップはARM一族のハイエンドから2番目のARM CortexA8(ARM11の後継）コアとDSP、ビデオコントローラーを内蔵し、RAMがRevBの128MBからRevCでは256MBと増えている。クロックは600Mhzと一昔前のパソコンのスペックに近い。これが7センチ四方のボードに納まっている。

　気をつけなければならないのは、アプリケーションがどんどんパソコンに近づいていくことである。省電力、ファンレスだといくら威張ってみても所詮はローエンドのPCにも負ける。PCと同じような機能を開発してみても始まらない。本当の用途、最終目標が何なのかをよーく考えておかないと何をしているのかわからなくなる。パソコンで出来ることを何を苦労して作っているの？と笑われるのがオチである。

　接続に必要なケーブルで入手が難しいと言われる、USB-Aメス--ミニBオスのケーブルとHDMI--DVI-Dケーブル（これは入手難というより市販品が金メッキなどで異常に高い）は￥680と、￥1300でアマゾンで発注済である。とりあえず動かすのに必要な部品は、シリアルDSUB9ピンコネクターとボードのシリアルピンに接続するケーブルだけとなった。

　具体的なアプリケーションはまだ全く決まっていない。折角AVインタフェースが充実しているので動画関係に使いたいところだが、直接の用途が思いつかない。Linuxを入れてUSB経由のLANとHDDをつけ、とりあえずはディスクサーバーのようなことをやってみようかと思っている。まあ、これも少し先の話だ。DigiKeyでは私が買った数日後、案の定、在庫が0になって売り切れた。ひそかにほくそえんでいたのだが、昨日見たら在庫が25に戻っていた。何だ。次のロットは遅れるなどと言っていたのは誰だ。少々あせりすぎたかもしれない。しかし所有欲だけは十分満たされた。しばらくは棚に飾って喜んでいよう。

やっとフラッシュにJTAGのOCDコマンドでイメージが書き込めた(5/17/09)
　BeagleBoardはさておき、ARMの開発である。次の目標はRTCと決めてあるが、それまでに片付けておきたいことが沢山ある。GDBによるソースコードデバッグは余り深入りするつもりはない。USBやシリアルなどタイムディペンドな機能の開発ではプログラムを途中でブレークすると動作状況が変わってデバッグにならなくなる。恐らくSDカードのアクセスも同じだ。

　ハングアップしたときなどは威力を発揮すると思うが全体がまだわかっていないので使いこなせるかどうか。それにフラッシュ上ではブレークポイントが限られており、自在に止めるにはSRAM上にコードを移す必要がある。しかしSTM32はSRAMが20KBしかないので今のプログラム（既に38KBもある。もっとスリムに出来ると思うがこれも未着手）でも、もう移動不能である。

　で、やろうとしていることはピンを切り替えたり、リセットすることなしに、Eclipseの下でプログラムが書き込め、そのままテストに入れる環境を作ることである。Eclipseにこだわるのは、ここの豊富なソースコードの編集・検索機能だ。表示されているマクロステートメントにカーソルを当てるだけでプロジェクトの中の定義元を調べてマクロを展開してくれるし、外部変数や関数の所在も一発でわかる。沢山のモジュールで構成されるプロダクトではありがたい機能だ。まだ他にも沢山機能があるらしいが調べ切れていない。

ファーム書き込みのスクリプトを作る前に、コマンド入力で、フラッシュ書き込みのテストをする。要は、プロテクトをoffにし、フラッシュを消去し、書き込むと良いはずなのだが、これがこの前に書いたようにとても難渋した。

バンク、セクター、アドレス、オフセットの設定が難しい。まずバンクである。こういうJTAGのような組み込み系ではいくつもあるのが常識なのだろうが、こちらはAll in oneのワンチップコンピューターの世界しか知らない。コマンドにバンク番号を必ず入れるのがなかなか慣れない。

　バンクが常時0なのは良いとして、セクターの数え方が難しい。STM32では消去の単位がセクターではなく独自のサイズを持っており、4セクター単位にきっちりスタートとエンドを入れないと言う事を聞いてくれない。

　アドレスもそうだ。コマンドの指定するスタートアドレスは、0から始まる相対アドレスなのか、実際にメモリマップしたあとの絶対アドレスなのか、コマンドによって違うような気がする。

　flash write_image ファイル名　<offset>　というコマンドのoffsetも良くわからない。ファイルの種類によって違うような気がする。.binファイルなら良いが、elf、hexのような絶対アドレスが内容に指定されているイメージファイルはどうなるんだろう。offsetされるとそれもずれるのだろうか。いや、わからないことだらけである。

困ったときのGoogle頼みだが、的確な情報がない。仕方なく少しづつ実際に確かめて進めるしかない。アドレスを間違えても大丈夫なように、フラッシュの後半のアドレスに狙いをさだめて、コマンドを確かめてみる。

　何度か怒られながら、0xE000のフラッシュエリアに1KB余りのbinファイルを書きこみ、消去するまでの過程を実現するのに成功した。

flash erase_sector  0 46 49                           　セクター4KB単位に消去（必ず4K単位）
flash write_image  XXXX.bin 0x800E000  bin  　  設定アドレスからファイル書き込み
flash  erase_ check  0　　　            　　　　バンク0のフラッシュのerase状態の表示

以上のコマンドの投入で、0x0800E000のセクターがnot erasedになり書き込まれたことが確認できた。このあと、mdw  0x0800E000  256などで、書き込まれた内容を確認する。
さらに、同じflash erase_sectorをかけて再び内容が　0xFFFF…..になっていることを見る。やっとのことで、Eclipseのフラッシュスクリプトを作る目処がたった。

突然JTAGがR/Wエラーでおかしくなる(5/19/09)
　残るは、いよいよEclipseでのフラッシュ消去、書き込みのコマンドスクリプトの作成である。フラッシュを全て消すのでなく、0x3000以降だけを消去するコマンドを作る。OCDのフラッシュコマンドの基本はセクター単位(１KB )で消去の単位は４KBなので、flash erase_sector 0 XX  YYとして、XXを4、YYを127でよいはずである。このあとはアドレスは考慮しなくて良い（はず）。というよりGDBでロードするから、このコマンドはいらない。

　スクリプトにする前に手動でやってみる。ところが、さっきまで動いていたflash erase_sector が言うことを聞いてくれない。何回かやるうちに何とか書き込むべきアドレス0x08003000以降がerasedになったので、flash write_imageでelfファイルを書き込んでみた。ちゃんと書かれたか、flash erase_check 0　で確かめる。

　おやあ、Dfuが書き残してerasedになっていた、0x08002000から3000までのセクターもnot erasedになってしまっている。不吉な予感がよぎる。Eclipseを止めてJTAGをはずし、基板だけで動かす。全く動かない。不安が高まる。動作モードをDfuに変え、再立ち上げ。うわあDfuSeが基板を認識しない。やってしまった。Dfuを上書きしてしまったようだ。

　JTAGを接続しなおし、DOS窓でOpenOCDを立ち上げフラッシュの状況を見ようとした。これがBlock Read Errorのメッセージで見ることすら出来ない。当然、さっき動いたflash write_imageもエラーリターンする。えらい事になってしまった。予想されていた最悪の事態だ。だいたいflash probe 0というフラッシュの全体状況を表示するコマンドも、サイズはわからないけれど、だいたい128Kくらいかなあ、などという頼りない返事が返ってくる。

　こわしてしまったのだろうか。現象はハードエラーのような感じだ。なるべく冷静になって状況を確認する。JTAGはいわばコンピューターの心臓部に直接、検査針をつっこんで制御しているようなところがある。しかし、コマンドで動かしている限り、ハード的に装置をこわしてしまうようなことはないはずだ。ファームに何かを書いたためにCPUが暴走し、JTAGが正しい結果を返せないと考えるのが妥当だろう（そう思いたい）。

　そういえば、前のLPC2388で何もプログラムが入っていない状態では、JTAGでファームに書くことが出来なかった。そうだそれに違いない。気分が少し明るくなった。何か動くプログラムを書き込めば良いはずだ。しかし、Dfuは消えてしまったし、JTAGはこんな状態だ。

　このあいだ「ねむい」さんのコメントを見て、「十分注意しているから、こんな事態にはなるまい」とたかをくくっていた事態が急に現実になり苦笑いである。第三の方法、ROMブートローダーの出番である。この方法があるのは知っていたし、UART1はこの前のGNUサンプルを動かすときに配線済みだが、実際の手順は「ねむい」さんの記事が大変役に立った。「ねむい」さんありがとう。

　手順が決まっていれば後は作業だけである。BOOT0をHighにするピンヘッダーを立て、STマイクロからPC側のダウンローダーを落とし、UART1を秋月のUSB-UARTアダプターとつなぐ。うむ、STM32を認識した。何、フラッシュが全部プロテクトされているぞ。これが原因だったのか。どうせなら、Dfuを復元してやろう。「ねむい」さんのところからDfuのhexファイルを頂きファームに焼きこむ。よーし。USBをつなぐとPCが反応し、DfuSeがSTM32を認識した。

　これでJTAGが動けば、完全に元に戻ったことになる。あせる気持ちを抑えJTAGケーブルを基板に接続し、OpenOCDを立ち上げる。Telnetを開きコマンドを入れる。万歳！これまでのおかしなレスポンスは全くなく正常な状態に戻った。

　やれやれJTAGは気難しい。Block R/Wエラーが頻発しプロテクトの状態がコマンドを入れるたびにおかしな状況になるのは、ターゲットのCPUが暴走していたからに違いない。しかし逆に言うと、CPUを暴走させてしまうとJTAGが動かない状況に簡単になってしまうということだ。これはやっぱり相当経験を積んでからでないと使いこなせないツールのようだ。

EclipseでARMのソースコードデバッグが出来るようになった

STM32基板にバッテリーバックアップ機能を組み込む(5/9/09)
　STM32でのUSBの仮想COMポート（VCP)がやっとのことで動き、がた老「AVR」研究所の「ARM」プロジェクトは大きく前進した。しかし、折角入れたJTAGとEclipseが活用できていない。ファームのコンパイルはDOS窓からだし、書き込みもDfu経由である。

　なりふり構わず当面の目的に突き進んでVCPモニターが動くところまでは行ったが、他は殆ど手がついていないままである。現在の開発手順、Dfuからのファーム書き込みは、沢山の画面を経由するだけでなく、ターゲットのモードをいちいちジャンパーピンで切り替えてリセットしなおさねばならない。いくらなんでも能率が低すぎる。

　Eclipseの環境は、前のLPC2388基板では実現し、STM32ではUART1を使ったGNUのサンプルがJTAGインターフェースで動くところまで進んだ。しかしどちらもまだ、止めたり動かしたりできるだけで、ソースコードデバッグまで行っていない。統合環境と言っても断片的にしか使えていない。目指す山はまだまだ高く、深い。

　それにSTM32基板の方は、Eclipseでビルドだけはやったが、ターゲットへのファーム書き込みはDfu経由である。参考にしているウェブサイトの書き込みスクリプトには、stm32x mass_erase 0というコマンドがあり、これは明らかに全部のフラッシュを消すコマンドで、これをそのまま使うわけにはいかない。Dfuを消してしまう。

　貧乏性というわけではない。JTAGでファームが間違いなく書ける保証がないのに、Dfuを消してしまうと、失敗したとき当面の書き込み手段をすべて失ってしまうのが怖い。これらとは別に書き込み手段があるのはわかっているが、そのツールのインストール、テストだけでもまた手間がかかる。余計な作業が増えるばかりである。

　これは長年システム開発をしてきた人間の一種の職業病だろう。全体の所要作業量とリスクを最小にしようとして、些細なところに神経質になる。それで結果として先に進めなくなる。困ったものだ。それにしても、調べなければならないことが多すぎる。何から手をつけて良いかわからない。間口を広げすぎて完全な手詰まり状態におちいった。

　こういうときは気持ちを落ち着けるために何も考えないですむ手作業が良い。STM32基板にボタン電池(CR2032)をつけてRTC（リアルタイムクロック）のバッテリーバックアップの機能を実装することにした。付録基板を入手した直後、言われるまま手持ちのクロック用の32.768khzの水晶をハンダ付けしたが、電源をバックアップしていなければRTCは何の意味もなく宝の持ち腐れである。これでこの部品の顔も立ててやれるというものだ。

　付録LPC2388基板のバックアップ用の電源ピンVbatは、Vccにパタンで直結されてしまっているが、このSTM32基板は感心なことに配線図を見ると0Ωの抵抗(R1)でVccにつながっている。0Ωの抵抗なんて何の役に立つのだろうと以前は思っていたが、これはアイデアである。表面実装のこのチップ抵抗を外して、ここへバッテリーからの配線をつなげば電源回路を簡単に分離することが出来るからだ。

　久しぶりにハンダごてに電気を入れる。配線図のR1は基板上ですぐ見つかった。クロック用の水晶のすぐ近くにある。隣に並んでいる0.1μのパスコンまではずしてしまわないように、慎重にチップ抵抗だけにフラックスをつけ素早く両側を暖めてハンダを溶かす。

　とれた。いけない。0Ωの抵抗チップがどこかへ吹っ飛んでしまった。これを探すのはさすがに止めた。電池フォルダーをベース基板に固定しUEW線で接続する。予想していたより早く簡単にバックアップ回路が完成した。これでSDカードの書き込みで正しいTODを記録することができるし、目覚ましやタイマーなど応用の範囲が広がると言うものだ。楽しみである。

ARMとGDBの参考書を買ってきた(5/10/09)
　ARMにしてもEclipseにしても雑誌とウェブの情報だけでは、どうしても断片的な知識になりやすく系統的な知識がなかなか身につかない。今の行き詰まりを打開するためにも、ここはひとつちゃんとした参考書で基本的なところを押さえようと、このあたりでは一番本が揃っている新宿の紀伊国屋本店に足を運んだ。

　ARMの参考書はいくつかあったが、どうも帯に短し、たすきに長しである。結局、「ARM組み込みソフトウエア入門 」CQ出版社￥4,620を選んだ。この本、入門と銘打つわりには店頭にある本の中で、一番高度な内容が書かれており、参考になりそうだ。　ついでにクロス開発用のGDBの参考書「GDBを使った実践的デバッグ手法」CQ出版社￥2,310も買う。

　結果から言えば、この2冊とも、今こちらが直面している具体的な疑問には何も答えてくれなかった。どちらも今の自分には少しレベルが高すぎるようだ。背伸びはするものではない。2年前AVRを始めたとき、PINとPORTを間違えて動かない、動かないと悩んでいたことを思い出した。現在の問題（割込みを止められない、外部変数をループで待っても変化しない）は余りにも基本的な事なのでそれに関することは何も書いていない。

　ただ、ARM入門のほうで、スピード向上とフラッシュの節約のためCでは1バイト変数ではなく、4バイト変数を使えと言う説明は参考になった。もちろん変数を入れるSRAMとのトレードオフになるが、ARMのレジスターとメモリの受け渡しはすべて4バイト単位なので、1バイトにするために無駄なコードが発生するのだそうである。

　GDBの本の方は、直接は何の参考にもならなかったが、皮肉にも今まで悩んでいたコマンドがすべてOCD(On Chip Debugger)のコマンドであることがわかり、ウェブにあるWikiのOCDのコマンドマニュアルを読むことで、結果として飛躍的に知識レベルが上がった。マニュアルは英語だけで、日本語訳がないが、ここに抄訳がある。

　マニュアルを読むうち、OCD のflashコマンドに必須のバンク番号という意味がやっとわかった。STM32 などはフラッシュメモリが一組しかないので、0で良いのである。組み込み系では常識なのだろうが、私のように大型機育ちで、バンク、セグメントが乱立する86系を毛嫌いし、Z80のザイログやモトローラ(Macintoshでアセンブラを少しやった)のリニアなアドレス空間を好んでいた人間にはバンクの概念が薄い。

　昔話はさておき、少し気分が落ち着いてきたのでARMプロジェクトの懸案事項を整理し優先順位をつけて作業を始めることにした。10余りの懸案が揃った。ひとつのグループは先のARMのコードに関する懸案、次がOCD、GDBのデバッグ環境、もうひとつはEclipseの全体環境の懸案である。このEclipse、作業名がプロジェクト単位に独立しておらず、スクリプトをすべてユニークな名前にする必要がある。それでいてやることは同じだ。どうも矛盾があるような気がする。しかし何かまた勘違いしているのかもしれない。

GDBが知らないうちにフラッシュを書いていた(5/11/09)
　とりあえずはデバッグ環境の整備が一番優先順位が高い。コードの問題解決やEclipseの環境整備は、その先の話とする。　で、ひとつ前のUART1で動くプロジェクトをEclipseで開けるようにした。STM32 基板のJTAGインターフェースは、この前実装し、Telnetレベルで動くことを確認しただけでEclipseで動かすのは始めてである。ファーム書き込みは前に書いたように出来ないので、GDBだけでも動くのを確かめようと、OCDのスクリプトを書いてテストしてみた。STM32のフラッシュは前のVCPモニターのままである。

　違うフラッシュに別の情報を持ってGDBが立ち上がるのだから、すぐ止まるだろう。動くことが確認できれば良い。予想通り、GDBは沢山のエラーメッセージを出して、普通はエラーリターンするところを、怒りすぎたのか死んでしまった(GDBコマンドがkillされた）。

　まあ、これは想定どおりだ。しかし、エラーメッセージを頭から見直して行って顔が青ざめてきた。GDBはフラッシュにどうもイメージを書き込んでいる。エラーは別のところだ。 確かにOCDのGDB起動スクリプトには、load main.elfというステートメントがある。これはGDBのPC側の実行空間にelfファイルを展開しているのだろうと思っていたのだが、どうもそうではなさそうだ。

　これはいかん。Dfuを消してしまったか。UART1のプログラムはDfuを避けてロードされるはずなので大丈夫だとは思うが心配だ。折角ここまで我慢してDfuを残しておいたのにと、あわてて、基板のピンをDfuモードにしてPCでDfuローダーを立ち上げる。

　良かった。Dfuは消されていなかった。Dfuローダーにファームの存在を示すメッセージが出た。胸をなでおろす。ということは、前のUART1のイメージがフラッシュに書かれたのか。半信半疑で、STM32基板のUART端子をつなぎPCのUART端末を開く。

　はっはっは。 端末からはADコンバータの数字が出力され0,1のキーでLEDが点滅する。UART1のプログラムがちゃんと動いている。知らぬ間にGDBがフラッシュに正しくファームを書いてしまったのだ。このあいだからフラッシュへのファーム書き込みは、TenetからのOCDコマンド入力でさんざんテストしていたのだが一度も成功していない。

　その都度、セクター番号が違うだの、プロテクトされていて駄目だの、書く前にフラッシュを消しておけだのと叱られて門前払いを喰らっている。それがいとも簡単に出来てしまった。GDBがさっきの煩雑な手続きを全部済ませてしまったのだ。

Eclipseでソースコードデバッグが出来るようになった(5/12/09)
　期せずしてJTAGによるファーム書き込みに成功して、プロジェクトは更に進んだ。もう、これでDfuをいつでも消せる。JTAGで書けるので、必要ならDfuをrestoreすることができる。残った基本的な機能の実現は、GDBによるソースコードデバッグである。

　それにしても、この環境は、ウェブでこぼしていた人がいたように、複雑で、一筋縄では行かない。EclipseとOCD、それにGDBの3つの環境がそれぞれ並列的に動いている。
Eclipseとは別にTelnetを開きコマンドレベルで色々いじっていると、何が何だかわからなくなってくる。

　しかも、EclipseはもともとはJAVAの統合環境なので、GNUのC/C++の開発環境はあとから加えたプラグイン的な扱いであり、どうもしっくりこない。しかし機能の豊富さは大変なものだ。まだ殆ど理解できていないが、数え切れないくらいの沢山の機能がある。

　でも、ソースコードデバッグは、あっけなく実現した。参考にしていたウエブサイトは、このあたりから「ご自分でどうぞ」という姿勢なのでもう頼りにできず、心配していたが、ほどなく必要なGDBコマンドが見つかった。symbol-file　 <ターゲットファイル>　である。必要なリソースは、GDBが勝手に探してロードしてくれるらしい。

　早速、GDBの起動スクリプトにこのコマンドを入れて試してみる。おお、動いた動いた。フラッシュ上のコードなのでブレークポイントの数が少ないが、止まったところのソースの行番号を表示しhaltしてくれる。しかし、VCPモニターをデバッグしたところ、USBのタイムアウト（？）でステップごとのデバッグは無理とわかる。どうもタイムアウトが起きてすぐHardエラーのルーチンに飛んで行ってしまう。このあたりが、私がICEを敬遠してきた理由である。外部条件を良く考えて動かさないと、まともなデバッグが出来ない。まあ、ここも奥の深い世界だ。あわてずじっくり進めていこう。

　先月からほぼ丸1ヶ月、ARM環境整備プロジェクトはこれでおおよその目標を達成した。まだまだほんの入り口に立ったにすぎないが、STM32の開発環境は一応揃ったことになる。これからは楽しいプログラム開発が待っている。まずRTCを組み込んで時計を作ってみよう。SDカードソケットが実装されているので、ここでもファイルシステムを入れてSDカードプレーヤーARM版にしても良い。裸ではコーディングが面倒なので簡易なOSを入れたほうが良いかもしれない。夢がふくらむ。

STM32のUSB仮想UARTモニター遂に完成

　今年の連休は殆ど外に出かけず、いわゆるCQ-STARMと呼ばれるDWM2008年5月号の付録基板、STM32F103をGNUベースで開発するプロジェクトに没頭していた。こんなに夢中になったのも久しぶりである。やっとのことでUSBの仮想COMポートが実用レベルの域に達した。PCから簡易モニターが開けるのでUARTを通じて開発を進めることが出来る。いやあ今度も大冒険だった。

仮想UARTからの送信データが抜ける(5/4/09)
　STM32のUSB仮想UARTは、とりあえず送受信は出来るようになった。しかし、この雑誌のファーム（蛙がピョン）が使っているUSBへの送信関数は不安定極まりない。特に、連続して送ると前のメッセージを無視して最後の送信メッセージしかPCに届かない。

　受信は出来ているようなので1文字単位のエコーバックは出来るが、ARM側からの連続した送信は全く駄目である。それに受信に関しては不審なことがある。この前、書いたようにデバッグ用に用意されている2文字のコマンドがCD-ROMに入っていたオリジナルのファームに戻してみても、全く機能していないことである。どうもおかしい。

　ソースコードを調べて行ってその原因がわかった。メインループの中で受信バッファーにデータがあるかどうかをバッファーのデータサイズ変数(count_out)で聞いている。受信バッファーは、USBの受信エンドポイントから直接移しているだけでキューイングなどはやっていない。しかもこの変数、count_outは、このループの最後でクリアされている。キーボードの入力はどんなに早くても1/10秒単位である。これでは2文字のデータがUSBのエンドポイントのバッファーに揃うことは絶対にありえない。

　送信がおかしいのは、恐らく送信バッファーで、まだ送っていない前のデータを新しいデータで塗りつぶしているからであろう。USBはホスト(PC側）が完全な主導権を握っており、UARTのときは、ディバイス（ARM)側から送信は、ホストのVCPドライバーからのポーリングで送信するはずで確か、最小でも1ms間隔だったと記憶している。バッファーから正しくデータが送られてバッファーが空にならない限り、次のデータは送れないはずだが、このコードはそういう制御は何もしていない。

　受信の方の不備といい、送信のところといい、どうもこのソースコードの作者は、USBが非同期で沢山のバッファーを通して動いていることを理解しているか疑わしい。困ったことになった。お手本が頼りにならない。加速度センサーのADコンバータが既に動いているし、これをベースにアプリが広げられるという最初の期待はもろくも裏切られた。

　確かにキーボードから「＊」の入力で連続した加速度センサーの数値を表示することには成功している。しかし、これは加速度センサーの表示タイミングがUSBの送信間隔よりはるかに遅く、せいぜい10msに一回程度だから、たまたまボロが出なかっただけである。これはオリジナルのSTマイクロのVCPソースからじっくり調べる必要がある。

sprintfは動いたぞ(5/5/09)
　こどもの日の今日は雨。晴れのときは何となく落ち着かないが、雨のときは心置きなくARMマイコンと過ごすことが出来る。このところARMの話題ばかりで、がた老AVR研究所と名前をつけた手前、AVRのことを期待して来られる読者には申し訳ないが、アクセスログを見ていると殆どの読者はキーワード検索で来られるようだ。余り気にすることはないのかもしれない。

　それはともかく、何とか動かすためにこのあいだコメントアウトしたsprintfである。書式付の出力関数は、フラッシュが大きくなっているので気楽に使えるし、今後のデバッグの生産性のためにも生き返らせたい。仮想UARTの不具合究明を少しお休みし、こちらの方をやってみることにした。

　まず、この前のウェブの情報には、問題の_sbrkのミニマムコードが掲載されている。真面目にコードを読んでいく。何だ、そんなに難しいことはやっていない。ヒープアドレスのエントリーを要求に応じて上げているだけだ。その間が確保したメモリというわけだ。メモリの解放は考える必要はない。スタックと被るとエラーを出すようになっているが、これも今のところいらないだろう。

　_endという外部変数が気になったが、リンカーが設定するというコメントを信じてソースを追加しコンパイルしてみた。おおー、NO ERRORである。調子に乗って、オリジナルソースのsprintfのコメントの部分をはずしビルドする。これも問題ない。いよいよテストだ。「＊」を入れる。やった。やりました。加速度センサーの数字が見事に出力された。オリジナルと全く同じ機能が、GNUベースで実現した。

　STM32で、GNUの標準ライブラリが使えないというのは、このあたりに原因があるのかも知れない。私の場合、リンクエラーが出たので顕在化したが、どこかのライブラリの中でもし何もしない_sbrkのスタブルーチンが用意されてしまっていると動かないことになる。

仮想UARTは本家のSTマイクロのサイトでも紛糾(5/6/09)
　お手本にしようとした雑誌の内蔵ファーム（蛙がピョン）の応用をあきらめて、もとのSTマイクロのVirtualComPort(以後VCP)のデモプログラムで仮想UARTの実装を始めた。内蔵ファームの仮想UARTの部分は、このVCPのソースを殆どそっくり利用していたので、理解が早い。送信バッファーの取り扱いがわかった。最初から書き込まず、足しこんでいる。そうか、これなら内蔵ファームのようにデータは失われない。

　その内蔵ファームについて前回の記事では、その後の情報収集で少し誤解があったようなので訂正しておきたい。2文字コマンドは絶対動かないと書いたのだが、これはGainerプロジェクトの仕様なのだそうだ。キーボードでなく、別のマシンからの入力を想定しているのでバグではない。キーボードから入れるときは、端末プログラムで入力コマンドをカット＆ペーストすると動くと言う。

　実際に試してみて動くことを確認した。情報源のサイトでは「変な仕様だなあ」などのコメントがついていたが、同誌の次号6月号3章の記事を読み直して少し謎がとけた。この記事の中で、コマンドがすべてASCIIなのに端末側にわざわざフリーウエアのAcknowrich(アクノリッチ)を要求している理由が全くわからなかったのだが、こういうことだったのである。それなら最初から、そう書いてくれれば混乱することはなかったし、アクノリッチを使うこともなかったように思うのだが。

　それはさておき、STマイクロのVCPデモソースの解析の方である。ここではmain.cとhwconfig.cで、USBの受信バッファーのデータサイズ(count_out)分をUARTへ送り、UARTからのデータは、UARTの受信割込みの度に、USBの送信バッファーに書き足している。USBの送信バッファーはエンドポイントの割込みを処理するusb_endp.cで定期的にハードのパケットレジスターに送信バッファーサイズ(count_in)だけ書き込まれる。いずれも処理のあとにバッファーサイズの値は0にリセットされる。

　問題なさそうである。これを元に鼻歌まじりで、1文字送受信関数、USB_putc、USB_getcを作り、USB_putcを使って、文字列用のUSB_putlineまで用意して、仮想UART超簡易モニターを実装した。STM32の開発ベースになるものである。とりあえずは、入力をエコーバックし、リターンキーでこれまでのデータを送出、0、1、でLEDのOFF/ONという仕様だ。ファームを書き換え、意気揚々とテストに入る。

　と、これが言うことをきかないのである。受信は問題ないが、ホストへの送信が前と同じようにうまくいかない。一文字なら良いが（エコーバックは完全だ）、一気に送るとデータ落ちが激しい。それにおかしなことにデバッグ用のLEDをONするステートメントをメインループからはずすとハングする。？？？である。

　おかしいな。送信バッファーは64バイトもある。いくら実際のUARTよりはるかに早いタイミングでプログラムからバッファーを書き換えても、USBの割込みが入ってハードのエンドポイントレジスターに書き込むときは、正しいバッファーの内容と、そのサイズを示しているはずだ。現象はあきらかに書き足す処理の時に割込みが入って、サイズとバッファーの内容との不整合が起きているとしか考えられない。バッファー転送とサイズ変更の間で割り込まれないようにしておく必要がある。

　しかし、STM32で割込み禁止をかける方法がわからない。8ビットのAVRと違ってSTM32 の割込み環境は目茶目茶複雑だ。下手にかけると他がおかしくなる。それにLEDのステートメントがないとハングアップするというのも奇怪な話である。

　USBの知識も生半可なので少し勉強し直し、色々いじってみたが改善しない。うーむ、よくわからない。思い余って、このあいだ試して味をしめた生のステートメントをGoogleに投げる方法をやってみた。キーワードは、ユーザーバッファーから実際のエンドポイントにデータを移すSTマイクロ提供のライブラリ関数、UserToPMABufferCopy(...)である。

　すると、また当たったのである。こんどもSTマイクロのフォーラムだ。それも私と全く同じ仮想UARTのデータ抜けで困っている人たちの議論である。3ページ分ある。英語の斜め読みなので、完全に理解したとは言い難いが、UARTが低速のときはUSBがパケットを送るタイミングとぶつからないが、高速になると取りこぼすバグの対処の議論である。

　色々な改善案の出し合いがあって、最終的には、一方がsystickを使った新しいコードを提案してスレッドは終わっている。しかし、このコードはのちほど本人が否定して、問題は解決されていない。STマイクロの対応（発言）はない。去年(2008年4月）の話なのでソースはV1.0ベースだ。これを受けて次のバージョン(V2)でどうなったか、USBライブラリをダウンロードしてみたが、何も変わっていなかった。ただこれはこの関数UserToPMABufferCopyだけの問題ではない。V3のVCPのデモソースは見つけられなかった。

　さて、どうするか、である。割込みを止めようとウェブを探し回ったら、何とユーザーモードでは割込みをペンディングできないことがわかった。うーむ、やっぱり32ビットプロセッサーは難しい。LEDを動かさないと何も動かずハングするとか、count_outなどの外部変数を監視していても変化しないとか、まだわからないことだらけだ。

NOP_PROCESS()ですべてが解決した（5/8/09)
　AVRだと気楽に割込みを止めてアトミックオペレーションに備えることが出来るが、ARMあたりはRTOS（リアルタイムOS）を意識しているので、そう簡単にユーザーレベルで割込みを止められたら確かにおかしくなることはわかる。ただ、今の現象はあきらかに、USBのエンドポイントの送出割込みがバッファー転送中に起きていると思われる現象だ。

  向こうが待ってくれないなら、こちらで待つ（バッファーが0になるのを待つ）ようにしようとしたが、これも出来ない。モニターに使うUARTだから早さは求めない。バッファーサイズが0になるのを待って、１バイトづつ送っても問題ないのだが、whileループで、これを調べても変化しない。ここでループしたままになる。ユーザープログラムからこのバッファーサイズ(正確には変化）が見えないのである。

　別のお手本を探すしかないかと、あきらめ気分になっていたとき、STマイクロのソースを見ていてふと目に留まったものがある。何かのフラグを調べているプロセスでwhileのあとの処理クローズにNOP_Process()という関数が入っている。これは何だろう。コンパイラーの最適オプションでおかしくなるのをさけるためなら、インラインアセンブラのasm("nop")で良いのに何故わざわざ別の関数を呼んでいるのだろう。

　頭の中に何か灯りがともった。何かにおう。これが長年この世界にいた勘かもしれない。もしかしたらもしかするかもしれない。エンドポイントにデータを送る関数USB_Putc（）でbuffer_outが0になるまで、このNOP_Process()で待ってみることにしてみた。バッファーを送った直後なら、次のデータ転送の時に割り込まれる可能性は殆どない。ついでにはずすとハングするLEDのステートメントもこの関数にしてみる。だめもとである。あまり期待もせずテストしてみた。

　何と、何と、これが見事に機能したのである。長いメッセージも全くデータ落ちなく出力される。LEDプロセスがなくても問題なく動く。なぜ動くのか理由はわからない。ただ山勘でやってみたのがあたった。一回の転送タイミングで1バイトしか送れない(1msのタイミングで8kbps)が、今はこれで十分である。調整していけばもう少し早くなるだろう。

　いやあ、嬉しい。世の中がばら色に見える。寝ている女房を起こして喜びを分かち合いたい気分である。STマイクロのフォーラムであれほど紛糾していたのだから、殆どあきらめていた。それが低速とは言え、モニタープログラムが問題なく動いた。鼻が高い。リターンキーで、貯めこんだメッセージを1字も抜けずに表示するし、LEDも0、1のキーで点滅する。満足、満足である。

　今のところ高速化は必要ないが、バッファーをリングバッファーにするか、バッファーを書き換えるのときにUSBの割込みをペンディングする方法が見つかれば、もっと高速に送れる。まあ、これは先の話である。それよりも次はJTAG環境を整備したい。Dfu経由だと一回の書き換えに25クリックもかかる。