省電力化の試み -- その3

Power downモードの続きです。タッチパネルとW-SIMからのイベントによるWakeupはできたのですが、問題はBluetoothであるWT32からのイベントによるWakeupです。WT32からのイベント通知はUARTによるシリアル通信なのですが、UARTではWakeupできません。UARTのRXD端子の変化を監視して割り込みかけるという方法も無いではありませんが、Wakeup処理の間にWT32から送られてくるデータを受信することができないので、WT32が何か送ろうとしたことはわかっても、何を送ってきたのかわからないので意味がありません。実際にデータ送信を始めるに先立って変化させてくれるような信号があればいいのですが、RTSはその役目を果たしてくれないので、うまい方法が見当たりません。

そんなわけで、WT32からの任意のデータでWakeupさせることは断念することにします。その代わりに、何らかのBluetoothリンクが張られたことを検出して、GPIO割り込みをかけることにしました。WT32はGPIO端子をもっており、そのうちのひとつをリンクの有無を示すCD端子として動作させることが可能なので、この機能を使います。これにより、MCUがPower downされていても、ヘッドセットの電源が入ってHFPのリンクが接続されると、GPIO割り込みでWakeupさせることが可能になりました。そして、ちょっと残念ではありますが、Bluetoothのリンクが存在する間はPower downしないようにすることにしました。今回のジャケットではMP3再生や通話はBluetoothヘッドセット経由でしかできないので、Bluetoothリンクが無い状態では時計としての機能しか使えないのですけれども。。。

この制約により、W-SIM着信によるWakeup機能も実際にはあまり意味がないことになります。Bluetoothリンクが存在している間はPower downされないので、Wake on Ringも必要ありません。Bluetoohリンクが切れていれば、Wake on Ring でWakeupしますが、送受話につかうBluetoothが動いていないので通話できないことになってしまいます。

こんな経緯で、実際にはPower downモードを有効に利用できないというオチになってしまいましたが、一応実験してみたし、その機能も使えるようにはなっているということで満足することにします。

省電力化の試み -- その2

Idleモード対応の次のステップとして、Power Downモード対応です。Idleモードではプロセッサクロックが止まりましたが、クロック発振器は動き続けており、内蔵周辺機器部分は動いていました。それに対してPower Downモードではクロックの発振器そのものとPLL、そしてフラッシュメモリを止めてしまいます。そのため、内蔵周辺機器も動作しません。Sleepモードも同じようにクロック発振器とPLLを止めますが、フラッシュメモリは止まりません。

Power Downモードは、アプリケーションが休止状態になった時に入ることにしました。時計表示の時には、LCDが消えた時点でユーザには機能的に意味が無いので休止したも同じです。MP3プレーヤの時には、LCDが消えても再生中であれば動作を止めるわけにはいきませんが、再生が休止された状態であれば動作を止めることができます。

クロックが止まり内蔵周辺機器へのクロック供給が止まるので、任意のデバイスからの割り込みで復旧というわけにはいかず、復旧できる割り込み要因は限定されます。外部割り込み、ポート0またはポート2からのGPIO割り込み、Ethernet, USB, CANなどの割り込みでの復旧は可能ですが、UART, SPIなどの割り込みでは復旧できません。まずはタッチパネルにタッチすることで、復旧するとともにバックライトも点灯させることにしました。タッチパネル割り込みはGPIO割り込みを使っているのですが、幸いなことにポート2を使っているので、これでWakeup可能でした。具体的な処理としては割り込みハンドラにおいてWakeupかどうかを判別して、そうであればクロックの初期化とPLLの接続をおこないます。Power downによりPLLが切断されているので、PLLの接続状態を確認することでWakeupされたかどうかを判断しています。

実装としては40秒のタイマを用意して、アプリケーションがこれをリロードしないでいると、タイムアウトが発生してPower downするコードを追加しました。LCDバックライトの30秒タイマよりも長い40秒にしてあるので、LCDが消えてしばらく経ってからPower downします。もともと1秒間隔でボード上のLEDが点滅する処理がメインタスクの中に含まれているのですが、この点滅が止まることでPower downされたことを確認できます。タッチにより、再び点滅を開始するとともにLCD表示が戻ってくるという具合です。

比較的簡単にPower downとWake upが実現できちゃいましたが、Wakeupさせる条件としてはタッチパネルだけでなくW-SIMやWT32の動作も考慮する必要があります。W-SIMについては着信があった時にWakeupさせねばいけません。Wake on Ringというやつですね。着信はW-SIMのRI信号を監視することで検出できますが、UART割り込みではWakeupできません。LPC2388側でRI信号に使っている端子はP2[6]だったので、この端子をGPIOに設定しなおして立下り割り込みでRI信号検出をするように変更。着信を入れると消えていたLCD画面の時計表示が戻ってくるようになりました。そろそろ、ちゃんと電話としての機能も実装しないといけません。

残りはWT32の動作に伴うWakeupですが、ちょっと満足できる方法が見つかっていません。詳しくは、次回の記事で書くことにします。

省電力化の試み -- その1

WT32を使ってのリポ電池充電がちゃんとできるようになったのはいいのですが、現在の状況ではみるみるうちに電池電圧が減っていきます。USB経由で充電していても、消費される電流の方が充電される電流よりも大きいらしく、少しずつではありますが、電圧が下がり続けるようです。

来月のMTM06への参加申し込みをしたので、このBluetooth対応ジャケットもデモしたいと考えていますが、この調子だとあっという間に電池切れになってしまいそうです。そこで、できることから消費電流を下げる試みを施していきたいと思います。

まず現状ですが、消費電流を節約するような試みは何も施していません。MCUも72MHzで動かしていますし、使いたい放題しています。考えられる節約法としては、(実際に対応するかどうかは別として)次のような項目が挙げられそうです。

• LCDバックライトの調整 バックライトの調光機能は全く使用されておらず、常に一定の明るさのままです。しばらく操作されない場合には、バックライトを消灯するべきでしょう。
• MCUのIdleモードを利用する　実行するタスクが何もないアイドル状態になった時にはLPC2388をIdle状態に遷移させ、プロセッサクロックを停止させることで消費電流を節約可能です。
• MCUのPower downモードを利用する アプリケーション上での動きが無い場合にはLPC2388をPower down状態に遷移させ、特定のイベントによりWakeupする。
• こまめに電源を切る　LPC2388の周辺I/O機能の電源をこまめにON/OFFする。必要になった時に、電源を入れて、使い終わったら電源を切る。
• 必要に応じでクロック速度を調整する ほんとうに72MHzのクロックが必要なのは、MP3の再生時くらいだと思われるので、それ以外の時はクロック落としていいはず。
• LCDのsleepモードを利用する LCDコントローラにもsleep機能があるようだ。
• WT32のsleep機能を使う　WT32にもsleepがある。

まずは手を着け易そうな、最初のふたつを実装してみることにしました。バックライトって、いかにも電流喰っている印象があるので、まずはこれから。タッチパネルが30秒間操作されなかったら、バックライトを落とすことにしました。タッチすると点灯させますが、その際のイベントは無視してアプリケーションには通知しないことに。ほんとは、スライドショー機能を使ってJPEG表示している時は消灯してはいけないのですが、この機能は一時的に取り除いてあるので、また後で機能を戻した時に対応することとします。

Idleモードは、なんらかの割り込みがかかるまでは、プロセッサクロックを止めるという機能です。止めるのはプロセッサのクロックだけで周辺機器機能へのクロックは動き続けます。周辺機器あるいは外部からの割り込みにより自動的にクロック供給が再開されるので、特別な復旧処理は何も必要ありません。こいつをTOPPERS/JSPの依存部で使用します。JSPは実行するタスクが無い場合には割り込み待ちの状態になります。この部分の処理はWAIT_INTERRUPTというマクロで定義できるようになっていますが、これまではnopでしたので、実際にはプロセッサは空回りを続けていただけでした。そこで、この部分をIdleモードに遷移するようにPCONレジスタを操作する命令列に置き換えました。

バックライトの消灯により、見た目にも節約している印象を受けます。それに対してIdleモードの方は目にみえる変化が何も無いわけですが、時計表示をしているだけの時なんかには、ほとんどの時間はプロセッサは止まっているので、かなりの節約になっているはずです。

続いて、Power downモードも使ってみようかと思います。

再生中着信時の動作

きょうもWT32ネタです。今回はMP3プレーヤ機能とW-SIM通話の共存を目指していますので、MP3プレーヤで再生中にPHSの着信があった場合にも対応しなければなりません。そんな時に、WT32がどう動くのかを検証しておこうというのが、本日のテーマです。

まずはWT32をブートしてから、ヘッドセットの電源を入れます。するとヘッドセットが自動的にHFPで接続してきます。この状態で、WT32にringコマンドを入力すると、ヘッドセットでちゃんと着信音が鳴ってくれます。そして、ヘッドセット側のスイッチ操作で着信拒否できます。ここまではすでに、HFPの動作確認時に実験済みです。



続いてヘッドセットの再生ボタンを操作すると、A2DPとAVRCPのリンクが張られ、オーディオパスが動作開始。これも望んだとおりの動作です。ところが、再生中にringコマンドを入力して着信通知をしようとするとエラーになってしまいます。それもSYNTAX ERRORです。綴りが間違っているわけじゃやないんで、明らかにA2DPとAVRCPが動いている状態でringを入れているのがいけないようです。

同時に複数プロファイルの動作はできるはずなのに、どうしてHFPのringコマンドがエラーになるのかしばらく理解できずにいましたが、マニュアルを読んで@なるコマンドが存在することを知ってようやくと納得できました。どうやらiWRAPのコマンドは、ディフォルトで直近に選択されたリンクに対して送信されるようなのです。上記の例だと、直前にA2DPのリンクが張られていますので、A2DPに対してringコマンドを送った結果、無効なコマンドと認識されてエラーとなっているようです。ringコマンドはHFPに対して送られるべきであり、そのためには明示的にリンクを指定してやる必要があるのでした。

各リンクにはリンク番号が振られており、listコマンドでこれを確認することができます。HFPとA2DP/AVRCPがつながっている時には、次のようになります。



HFPのリンク番号は0番なので、@コマンドでこれを指定してringを送ってやると、ちゃんと着信音が鳴りました。しかも上記のログにも見えるように、WT32が自動的にA2DPのストリームをいったん止めてくれているようです。なかなか気が利いてるじゃん!! 着信拒否すると、自動的に再開してくれるし。

しばらく悩んでいた問題が解決して、やりたいことが実現できそうなことが確認できたのはいいのですが、複数のプロファイルとそのリンク番号の対応をちゃんと管理しなければいけいないことも判明。これまでずっと、手作業でWT32の動作確認とってきましたが、そろそろちゃんと制御ソフト書かねば。。

見送り

いよいよ明日は、P板.comのワークサイズパッケージキャンペーンの受付日です。10/20受注分のみの記述に注意がいっていましたが、良く見ると受け付けはすでに18時から始まっていたのですね。現在作業中のBluetooth対応ボードのハードがだいたい動作確認取れたので、これをプリント基板化しようかと思いしばらくEagleと格闘していたのですが、やはり時間切れで間に合いそうもありません。

プリント基板化にあたっては、次のような仕様変更を施そうなんて色気を出したのが、時間切れの大きな原因だったりします。

1. MCUをLPC2387に変更。ピン数の少ないLPC2387で用が足りそうなので、変更することに。ピン数が少ない方がハンダ付けも楽だし、基板のレイアウトも楽になりそうなので。
2. SDカードをマイクロSDに変更。これも面積の低減に有効ですし、今でもマイクロSDをアダプタを使ってSDソケットに挿しているくらいで、ホントはマイクロSDを使いたい。

MCU変更にともなって、Interfaceの付録基板を使わないことになるので、周辺パーツもすべてレイアウト必要になって時間切れです。一応レイアウトするだけはしたのですが、全然確認していないので、今回は断念。ちゃんと確認してから、Fusion PCBでも使ってみましょうか。。

P板ではいつの間にかEagle出力データのオンラインチェッカーなんて提供していたんですね。今回は見送るにしても、このチェッカーだけは通してみようかと思います。

ATMEL Store

久しぶりにATMELのサイトに正面から入ったので、ATMEL Storeが開いたことを今頃になって知りました。どうやら、7月頃から開いていたらしいのですが。。

やはりAVR中心の品ぞろえですね。AT91SAM関連はひとつもありません。ちょっと覗いてところでは、在庫数が10+という商品が多く見受けられ、中途半端な印象を受けます。いちおう、AVR Xplainも在庫ありですね。各社、採算度外視の評価ボードを出して目を引こうとしていますから、ATMELさんもそろそろ新しい目玉を出して欲しいものです。個人的趣味としては、SAM3ベースでQTouchできるものとか。SAM3S-EKもQtouch使えるらしいのですが、150ドルしますので。

どこに違いがあるのか？

3.3V駆動だとW-SIMがうまく動いてくれない問題で悩んでいましたが、とりあえずの逃げ手が見つかりました。それは、W-SIMの交換。

わたしはW-SIMをふたつ契約しています。いずれもRX420INです。以下、説明のためにSIM-AとSIM-Bと記すことにします。SIM-Aは前作である携帯できる電話機の試作版で使っていました。SIM-BはPCB版の方で使っていたもので、今回のBluetooth対応ボードでもこちらのSIM-Bを使っていました。SIM-BはPCB版の携帯できる電話機では何の問題も無く使えていたので、SIM-Bを疑ってはいなかったのですが、試しにSIM-Aを挿してみるとちゃんと動いたのです!! SIM-Bを携帯できる電話機試作版に装着してみると、やはり動きません。下表のような関係です。

	SIM-A	SIM-B
携帯できる電話機(試作版)	○	×
携帯できる電話機(PCB版)	○	○
Bluetooth対応ボード	○	×

うーん、どこが違うのかわかりません。ファームのバージョンも確認してみましたが、同一でした。とりあえず、W-SIMを挿し替えて作業を進めることにします。

ちっとも充電できない!

WT32のLiPo電池充電機能を実際に使ってみると、ここにもワナが待っていました。USBからの5Vで充電可能にしてある状態でも、本体が動作していると電池の電圧は順調に減っていくばかりです。本体が消費している電流を充電では補いきれていないようです。LCDのバックライトを落とすとかの対策を講じないと、それもしょうがないかと思い、本体の電源を切断して一晩待ってみると。。電圧は3.6V程度から3.8V程度に増えただけ。まだ充電完了していません！こんな、調子ではいったいフル充電(4.2V)まで何時間かかることやら。。

電池電圧が2.9V以上、4.2V以下では定電流での充電動作になっているハズなのですが、どうやらその充電電流が少なすぎるようです。しかし、ハードウェア的には充電電流を設定する抵抗なんかありません。WT32のデータ・シートを読み直してみると、充電機能の説明のところに充電電流を16段階で設定できるようなことが書いてあります。ところが、それをどのように設定するのかが説明されていません。iWRAPのマニュアルを読み直しても、電圧監視に関わるコマンドはあっても、充電電流に関わるコマンドはありません。

これはもうBluegigaに問い合わせるしかないのかとも思いましたが、そもそも充電機能はCSRのBlueCore5(以下、BC5)の機能のようなのでBC5の資料にあたるべきであることに気が付きました。BC5のデータシートをダウンロードして読んでみると、充電関連の記述にはWT32のデータシートと同じ文面が並んでいます。WT32のデータシートの記述は、BC5のデータシートからのコピペだったんですね。ところが、BC5のデータシートを読んでも充電電流の設定方法については書かれていませんでした。その代わり、充電機能の詳細については、別途アプリケーションノートが用意されていると明記されていました。ようやく情報源を見つけられたと喜んでアプリケーション・ノートのダウンロードにいったのですが、アクセス権限がなくて入手できません(泣)。 なんか登録してあるメアドのドメイン名で判定してはじかれているようです。

まぁ相手にしてもらえない身分ではありますんで、アクセス権限がもらえなくても当然かもしれません。しかし、答えはもうちょっとのところにあるハズなので、もう少し自分で調べてみることにしました。BC5の機能として充電電流が選択/設定可能であるならば、その値はI2Sの動作モードの設定でも使ったPSTOOLで設定可能であるに違いありません。そこでPSTOOLで表示される沢山の項目をひとつひとつ確認していくと、次の項目が見つかりました。

   Set the charger current -- PSKEY_CHARGER_CURRENT

ずばり充電電流設定です。0から15の16段階の値が指定できるところ、初期値は0になっていました。おそらくは、これが原因で充電電流が最低値の設定で動作していたと推察されます。そこで、この値を10に設定したところ、順調に充電が進むようになりました。BATTというコマンドで電圧を見ていると着実に増えていくのが確認できます。ところが、この電圧値が4.2Vを過ぎても、まだ上がり続けていき、ついには4.3Vに到達。これは、ちょっとヤバいんじゃないかということで、あわてて充電中止。

データシートには、充電完了電圧も16段階で設定可能であると書かれていたのですが、WT32ではあらかじめ4.2Vになるように調整済みという記載もあったので安心していました。充電電流を変更すると、充電完了電圧の設定値の解釈が影響を受けるのでしょうか。ふたたびPSTOOLでパラメータを探すと

   Trim value for the current charger -- PSKEY_CHARGER_TRIM

という値があり12に設定されていたので、10に変更してみました。しばらく様子を見ている状況ですが、どうやらおよそ4.2Vになると電圧が安定するようですし、充電中を示すLEDの点滅も止まります。充電関連らしいパラメータとしては、

   Turn off voltage for charger adjustments -- PSKEY_CHARGER_MONITOR_END_VOLT

というのもあったんですが、こちらは設定値が16進4桁になっておりちょっと想像がつきませんので、いじらないでおいてあります。

こんな調子で、ようやくと充電はできるようになりました。まだ良く分からないのが充電状態表示のLED動作です。電源スイッチを入れている状態では充電中を示すLEDが点滅しているのですが、電源スイッチを切るとなぜかLEDは点滅しなくなってしまいます。

充電機能を試してみる

WT32にはリチウムイオン/リチウムポリマ電池を充電するための機能も用意されています。WT32の機能というか、WT32が使用しているCSRのBlueCore5がもともと持っている機能のようですけど。データシートに回路例が示されているので、LDOを手持ちのものに変更しただけの回路を付加してみました。LDOは2枚目の写真でわかるようにWT32の下に配置されています。



はい、さっそくWT32のブレッドボードにジャンパです。外部LDOのイネーブル端子を制御するために使用するPIOと充電状態を示すLEDの端子を出していませんでした。今となってはアナログ関連端子とか使いそうもないので、それらの代わりに出しておけば良かったのですが。。。

WT32の充電機能ですがデータシートの回路例のとおりに組むことで、単に電池を充電することができるだけでなく、WT32自身がもつ内蔵のレギュレータと外部のレギュレータを制御することができます。充電の状況を示すLEDをドライブすることもできます。タクトスイッチもWT32が検出して、外部LDOの制御をおこなってくれます。具体的にはスイッチを押し続けることで、内蔵レギュレータと外部LDOがONとなり、WT32とLPC2388が動き始めます。WT32が動き始めるとPIO端子を使って外部LDOの制御端子を操作してON状態に固定するので、スイッチを離します。もう一度、スイッチを押してから離すと、離したタイミングで内蔵/外部レギュレータをOFFにすることができます。



LPC2388基板上には3.3V生成用のLDO(ISL9007)が載っていますが、この制御をする端子は外部に出ていないので、代わりにLD39080を追加しました。そして、外部LDOで生成した3.3VをLPC2388基板に供給するために、基板上のISL9007は足上げして使わないように改造。これで、全てがLiPo電池で動作するとともに、USB給電で充電もできるようになりました。

電池駆動と充電機能だけでなく、電源スイッチも一緒に用意できて喜んでいたのですが、重大な問題を発見。どういうわけか、W-SIMのCTS信号がアクティブにならないので、W-SIMに対してコマンドの送信ができません。試しにW-SIMだけを5V動作に戻してみると問題無く動いてくれます。以前のようにリセットを繰り返すような問題は無いのですが。。どうして3.3Vだと動かないのか、今のところ原因不明です。

I2Sマスター・モードでのMP3動作

MP3プレーヤの改造を進めI2Sマスタ・モードへの変更ができたので、MP3プレーヤが動き始めました。マスタ・モードではLPC2388側からクロックを供給してやる必要があるので、I2S_TXRATEレジスタを設定してクロックを生成してやります。音源のサンプリング速度に応じてクロックを生成する必要があるのですが、実際のところ自分で用意している曲はCDから取り込んだものばかりなので44.1KHzのものばかりです。そこで、いまのところ44.1KHz固定で動かしています。

I2SのクロックはLPC2388のPCLKを分周することで生成します。WT32へのI2S送信データは16ビットのステレオデータとして送る必要がありますので、44.1K X 16 X 2 = 1411.2KHzのクロックが必要となります。PCLKは72MHzですので、72000/1411.2 = 51.02 となりますが、I2S_TXRATEにはこれから1を引いた50を設定します。

MP3プレーヤのタスクを動かし、WT32へのI2Sへの接続を切り替える74157を制御してLPC2388のI2S信号をWT32へつなげてやります。



これで音が出るハズだったのですが、何も出ません。WT32側ではA2DPを使ってストリームを送信しているのですが、ヘッドフォンからは何も聞こえません。ちょっと焦りました。WT32の設定を確認するために、自分の書いたブログの記録を読み直しているうちに、記録し忘れている事項があることに気が付きました。

WT32のI2Sインタフェースでは、LPC2388のI2Sと同じようにI2Sフォーマットだけでなく、左詰めや右詰めのフォーマットも扱えるようになっています。ところがこのフォーマットの選択はiWRAPのSETコマンドを使ったコマンドではおこなうことができません。それではどのようして選択するかというと、CSRから提供されるBlueSuiteという開発ツール群に含まれるPSTOOLというツールを使うことにより、WT32モジュールが使用しているBlueCore 5内の設定(Permanent Store)を書き換えることで、これをおこないます。16ビットのI2Sで使用するためには、WT32のデータシートにも明記されているように、PSKEY_DIGITAL_CONFIGというキーを0x0406に書き換える必要があるのでした。Windowsに例えていうのならば、レジストリを書き換えるのに似ている感じでしょうか。

というわけで、PSTOOLを立ち上げて書き換え作業を実施したところ、無事音がでるようになりました。PSTOOLで操作できるパラメータはたくさんあるのでうが、WT32のデータシートで説明されているのは、そのうちのほんのわずかなものだけです。これらのパラメータのほとんどはCSRから提供されるファームウェアに関わるもののようですので、詳しくはCSRからライセンスを受けるとか、開発キットを購入するとかしないと情報を入手できないのであろうと思われます。

現在のボード全景です↓SDカード部分はMP3プレーヤ用に作成したものを借用中。LCDの表示がヘンですが、JPEGの表示コードと漢字のフォントを用意していないため、その処理を省略しているのが原因です。これらについては、後で元に戻すつもりです。MP3プレーヤの画面には音量調節のアイコンもあるのですが、前回の記事で書いたとおり音量調節機能はすでに動作しなくなっているので、この表示はゆくゆくは消すつもりです。



赤黒まだらのコードはLiPo電池のコードです。電池本体がW-SIMの下からちょっとだけ顔を出しています。現在、この電池で動作するようにハードウェアを変更作業中です。この件については、また次回の記事にでも書くことにします。