« 2009年9月 | トップページ | 2009年11月 »

2009年10月の6件の記事

2009年10月30日 (金)

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

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

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

 前の第一ステップの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)Xbeeavr
 飛び起きて、朝食をとるのももどかしく開発を再開した。しかし、このあとも苦戦が続いたのである。考えてみたら、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バイト整数にする。Xbeemonitor

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

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

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

2009年10月26日 (月)

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回測定してからまとめて送信

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

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

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

ワイヤレス電力ロガーの親機の開発に着手する(10/24/09)
 そろそろデータをログする親機の開発にとりかかろう。これまでに数々作った基板を納めたガラスの引き出しから、久しぶりに以前の電光掲示板のコントローラーに使ったMega128のCPU基板を取り出した。Aa252398 こいつはこれから実装しなければならない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でこれは出来る。

UART2つを動かすのは難しい(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電力ロガーのテスト用の親機のハードの準備は終わりである。あっけない。Aa262404

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

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

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

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

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

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

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

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

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

2009年10月22日 (木)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009年10月16日 (金)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 EAGLEを調べている余裕はない。仕方がないので、型番が違うオペアンプになっているが、正しい(誤配線を修正、フォンジャック修正)、EAGLEのボードファイルと回路図ファイル、それにAVRstudioのソース一式をzipファイルとし、画面にはオペアンプを正しい型番にした回路図を掲示することとした。 掲載した回路図に誤りがありました。図は修正済みのものです。大変失礼しました。4/16/2011)

Lpcm2_1023

 ついでに、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」をダウンロード

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

2009年10月 9日 (金)

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

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

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

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

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

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

 それにしてもよくここまで来たものだ。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は、そのパタンのレジストをはがし、そこへ結線する。うまくいったぞ。Photo

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

ケースは作り直し、EAGLEのライブラリを公開(10/9/09)

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

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

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

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

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

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

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

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

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

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

2009年10月 5日 (月)

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

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

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

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

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

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

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

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

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

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

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

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

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

 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カードを動かすのに半年近くもかかった。Aa042315

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

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

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

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

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

« 2009年9月 | トップページ | 2009年11月 »