解約しました

今年も残すところあとわずか。年の終わりを飾るのにふさわしいかどうかビミョーですが、しばらく前にW-SIM解約しました。契約期間の区切りもあったし、年に数回しか無いデモの機会のために契約を維持する気も失せました。メールの送信方法とか、電話帳のアクセス方法とかがわかれば、もう少し遊んでみても良かったのですが。。もっぱら電子工作目的での使用のみであり、日常での使用には供していなかったので、解約することにしました。

久しぶりにWillcom Storeを確認してみると、在庫処分していたセットも掃けてしまったようで、W-SIMは完全に姿を消していますね。来年３月一杯で販売やサービス内容も大きく変わるらしく、本家サイトには案内が出ていました。WVALUE割引もなくなるんですね。

思いかえせば、このBlogを始めたきっかけがW-SIMでした。もう５年になるんですね。ひとつの区切りをつけて、来年は新しいネタを見つけたいものです。

飯を喰うヤツ

先週はわずかながらLPC1114が消費する電流を低減することを試みましたが、実際にはマイコンなんかよりWT32の方がはるかに電流を消費します。したがって、まずはこちらの方の消費電流を削減することの方がよっぽど重要です。

WT32のデータシートには消費電流についてはあまり詳しく説明されていないのですが、100mA程度は必要であるとされています。当然のことながら、アクティブに電波を送受している時と、単にスタンバイしている時では消費電流も大きく違うであろうことは容易に想像できます。そんなことを思っていたところ、BluegigaのForumに新たな情報が登録されているのを見つけました。このデータはWT11iの数字ですが、WT32においても同じような傾向を示すだろうと思われます。iWRAPではsleepコマンドを使ってsleep状態に遷移させることができるのですが、それでもピーク時には結構な電流が流れるのですね。しかもpagemodeによってずいぶんと値が異なります。この数字を見ても、他のデバイスから発見可能とするためにinquiryに応答するように設定すると、消費電流が大きいことが良くわかります。通常は、pagemodeを２として使い、しかもsleepさせておくことが望ましいでしょう。

眠らせる

BlueHANDはリポ電池で動くようにしてありますが、正直なところちゃんと連続使用したことがないので、どのくらい電池が持つのかよくわかりません。消費電流を調べればおおよその予測を立てることができるでしょうが、それに先立って考えられる電力削減の手だてを打っておいた方がいいでしょう。

これまでにやってあるのは、次の２点だけ。

1. クロック速度を12MHzに設定
2. アイドル時にスリープする

開発に使っているCrossWorksにはLPC11xx用のCPUサポートも備わっているので、スタートアップルーチンも出来合いのものが用意されています。しかし、そのルーチンではPLLを使ってクロック速度を48MHzに設定してしまいます。こんなに早くなくてもいいので、PLLは使わずIRCの12MHzをそのまま使うようにしています。もっと下げられるかもしれません。

Cortex-MではWFI命令を使って割り込み待ちをおこなうことで省電力モードに遷移することができます。通常のスリープモードは、特別な前処理も必要とせずSCRレジスタのSLEEPDEEPをクリアした状態でWFI命令を実行するだけで遷移することができます。

RTOSを使うとスリープ処理はとても簡単に実現することができます。TOPPERSでは、CPU依存のディスパッチャにおいて実行可能タスクが無い場合にWFI命令を実行してくれます。そのため、ユーザ・プログラム側では何も考えなくてもスリープ状態に入ることができます。一方、CrossWorksで提供されているCTL (CrossWorks Tasking Library)では、アイドルタスク機構は提供されていませんので、明示的にこれを用意することになります。具体的なコードの流れは次のようになります。

int main(void)
{
  change_clock();      /* 12MHz IRC に変更 */
  SystemCoreClockUpdate();      /* クロック変更をCMSIS レイヤに反映 */

  /* 自分自身を main_taskとして登録するとともに、優先度を最高(255)にする */
  ctl_task_init(&main_task, 255, "main");

  /* 他のタスクを登録する */

  ctl_task_set_priority(&main_task, 0);   /* 自分の優先度を最低(0)にする */

  while (1) {
    __WFI();
  }
  return 0;
}

自分自身の実行優先度を最低とすることで、最後のwhileによる無限ループがアイドル時に実行されることになります。ここに__WFI() を挟めばいいだけですね。

ここまでは「いつものおまじない」のようなものですから、もう少し努力しなくては。AN11027によると、Sleepモードではコアのクロックは止まるものの消費電流は12MHzで2mA程度となっています。やはりDeep-sleepさせなくては。

ARM 10pin コネクタ

今回製作したBlueHANDでは、LPC1114をSWDで接続するのに、ARM標準の10ピン　コネクタを使用しました。ピンヘッダーについては、aitendoで見つけたことを記事にしましたので、今回はJTAG側について。

わたしは、ここしばらくCrossWorksを開発に使っています。SAM3SをつなぐにはJ-LinkのOEMであるSAM-ICEを使っていたのですが、ATMEL以外のマイコンでは使えないという制約があります。そこでしばらく前に、思い切ってCrossWorksのJTAGであるCrossConnectを買いました。



値段は高いけど、CrossWorksがサポートするマイコンであればほとんど使えるので、CrossWorksとの相性はベストです。Mac環境でも問題無く使えるのも嬉しいところ。おかげて近頃は仮想マシンでWindows 7を立ち上げることもまれになりました。

ちょっと残念なのは写真でもみるように、SWDを使う場合には信号の方向制御のために変換アダプタが必要なこと。どのみち、20pinと10pinの変換が必要になるので、この大きさなら許容範囲ではあるのですが。。実際に使ってみると10pinはやはり小ささが魅力です。今後、基板作る際には積極的に導入しようかと思います。

autopair と autocall

Maker Faireの時もそうでしたが、Bluetoothのデモのために観客の方に携帯やスマホを使ってBluetoothでの接続を頼むと、少なからぬ方々から、「Bluetooth使ったことないから、どうやるのか良くわからない」という返答があります。Bluetoothという言葉は知っていて、設定メニューの中にそういう項目があるのもわかっているけど、実際には使ったことがないという方がまだまだ多いようです。

今回はそんな客層を相手にデモするのに便利に使えそうな機能として、iWRAP5から新たに加わったautopairを紹介することにします。autopairは既存のペアリング情報情報が無い場合に、inquiryをかけてみて、見つかったデバイスに対してWT32側からペアリングをかけるという機能です。ペアリングができたら、さらにautocall機能を使ってWT32側から接続をかけることもできます。したがって、相手にはBluetoothの電源を入れてデバイス名を公開してもらいさえすれば、後の操作はこちらから行ってデモを進行できることになります。

実際にAndroidでやってみると端末側の動きは次のようになります。



まず、最初の状態です。スマホ側のBluetoothの電源を入れて検索がかかるとWT32が見えてきます (WT32側がデバイス名公開する設定にしているため)。



通常でしたら、ここでWT32をタッチして接続してもらうわけですが、今回はデバイスを公開してもらうことにします。



しばらく待っているといつの間にかペアリングが済んで、表示が「接続可能なデバイス」から「登録済みデバイス」に変化します。(ここまでがautopair機能の働き)



そして、つづいてWT32でautocall機能が動いて接続要求が来るので、写真のようにその確認メッセージが表示されます。「はい」でこれを許すと接続完了。



WT32側の設定は次のとおり。

ポイントとしては、

• 接続相手を限定するために、paircountを１にしておく。
• 初期状態ではペアリング情報を全て消しておく。
• 上記設定では、ペアリングができたらautocallが動いてHFPでの接続を張りにいく。
• HFPが張れたことをCDの設定でPIO7(0x80)に反映させる。
• bindでPIO7の立ち上がりを検出して、HFPにAT+CNUMを送る。５秒間のディレイを置いているのは、端末側での接続受付確認作業に要する時間を待つため。
• 接続が切れたらペアリング情報を消去しておく。

WT32側の動きにともなうメッセージは次のようになります。

ここでは電話番号を調べてみましたが、電話発呼するとかもできますね。
同じ要領でHFPの代わりにA2DP/AVRCPを張ると、音楽プレーヤの再生を勝手に開始するなんてデモもできます。機会があったら、次はこれをやってみたいな。

LCD画面とアイコン

今回製作したBlueHAND-Miniですが、当初はハンドセットを使うことをメインで考えていましたが、Maker Faireでのデモを考えるとSAM3S版のBlueHANDとの違いを明確にしたくなり、音楽再生機能の方がメインとなってきました。具体的にはA2DPで受信した音楽を聞けることはもちろんですが、AVRCPを使ってプレーヤの制御ができます。それに伴ってLCDの持つアイコン機能の使い方も決まってきました。

• 一番左のアンテナアイコンはHFPでの接続があることを示します。その下の数字が信号強度を示します。
• アンテナの右には電話機のオフフック状態を示すアイコンがあるのですが、この写真ではオンフック状態なのでアイコン表示は消えています。
• その隣のアイコンはなんらかのBluetoothリンクが存在することを示します。
• 左から４番目の位置のアイコンはA2DPの接続があることを示します。
• その隣の上下矢印アイコンはAVRCPの接続があることを示します。
• 鍵のアイコンは自局を発見可能にしていないことを示します。ペアリングのために発見可能な状態にすると、このアイコンが消えます。
• 電池アイコンは自分の電池電圧を反映させようかと考えていますが、いまのところ常に満充電表示となっています。

上の表示は自分のスマホSC-06Dをつないだ状態。HFP, A2DP, AVRCPがつながり、AVRCPでプレーヤの状態を調べてPAUSEDと表示されます。SC-06Dの場合、A2DPがつながって、しばらく間をおいてSC06-D側からAVRCPの接続が張られてきます。こちらから張りにいっていないので、それを確認してからAVRCPを張ってくれているのでしょうか？



オンフック状態ではキーパッドがリモコンとして機能します。０のキーを押す毎にPLAYING/PAUSEDが切り替わります。

SPP経由で設定変更

先月、muxコードを使うことでWT32のイベントメッセージをSPP接続したリンクに出力できることを記事にしました。これだけではWT32とのやりとりが片方向でしたので、さらにチョット手を加えて双方向化、SSP経由でWT32のコマンドも入力できるようにしてみました。PCからSPP経由で WT32に ATコマンドを送り、その応答であるOKが表示されるまでの経過を図示すると下図のようになります。

• muxモードでは、WT32が出力するメッセージには、つねにリンク番号がついている。Bluetooth接続を経由して受信したデータには、そのリンク番号。WT32が出力するイベントメッセージには、リンク番号として255が使用される。この例では、SPPのリンク番号は０であると想定する。
• マイコンでは、0番リンクからのデータはSPP経由で入力されたWT32コマンドであると解釈。そこで、受信した文字列 at を、WT32の制御リンクである255番リンクに送り返す。
• WT32はATコマンドを実行し、その応答である OK を制御リンク255番を使って返す。
• マイコンでは、制御リンクからのメッセージを全てSPPのリンクに出力する。
• 結果として、OK応答がPCに伝わる。

このようにWT32とLPC1114の間のやりとりは倍増してしまいますが、ワイヤレスでWT32の動作をモニタできるだけでなく、その設定変更までできるのは、なかなか便利です。これまではWT32の設定変更が必要になると、他の実験基板にWT32を載せ代えたり、ボード上のジャンパ設定を変更して外部シリアルにつなぎかえて作業をしていましたが、もうその必要もなくなりました。

はたせなかったデモ

週末のMFT2012ですが、有料イベントとなったにも関わらず多数の入場者があったことに驚きました。その影響もあってか、２日間とも会場内ではワイヤレス機器を扱う人の数が多く、入場者が増えた午後はわたしのブース位置からは全くWLANが使えない状況になってしまいました。自分で用意したワイヤレス・ルータや携帯のデザリングを使おうと思っても、会場内に電波強度の強い他のアクセスポイントが多数あるのがいけないのか、自分のMBAからはそのSSIDすら見つけることができないというひどい状況に。土曜日の開場後しばらくは状況が良かったのですが、午後はしだいにつながってもパケ落ちが頻発する状況となり、午後２時過ぎには完全にWLANの使用を諦めました。もちろん、皆さん同じような状況だったのでしょう、遅くてたまLANというSSIDを付けている人もいました。

Bluetooth接続の方は、A2DPで音楽再生をしている分にはさほど影響はありませんでしたが、AVRCP操作で若干ディレイを感じることがたまにありました。そしてHFPで通話する場合にはSCOでリアルタイム性が要求されるため、ときおり音声がブツブツと切れることがありました。

そんな事情もあって、BlueHANDを使ったデモの内容を変更せざるを得なくなりました。土曜は午後２時くらいまでは、先日紹介したBoundioのサービスを利用して架電して、BlueHANDで着信するというデモをしていたのですが、その後は接続状況の悪化に伴いデモを断念。端末側から発呼してもらうデモに変更しました。計画していたデモは、BlueHANDにBluetoothで接続するだけで、しばらくすると知らない番号から電話がかかってくるというものです。先日のboundio meetupでも、このデモを行いました。概要はこちらの紹介スライドを参照してください。

以前、この記事でも紹介したように、iPhoneやAndroid端末では検索したBluetoothデバイスにタッチするだけで、自動的につながるプロファイルを探して、接続を試みてしまいます。デバイス側でSSP Just worksモードを許容していれば、PINコードを入力することもなくHFPで接続してくれちゃいます。その結果、デバイス側では端末の電話番号を調べることができてしまいます。デモではBlueHANDからノートPCにSPPで電話番号データを送り、ノートPCからBoundioのAPIを叩くことで架電をおこないましたが、デバイス側にXbeeのようなWLAN機能を追加すれば、単独で実行することも可能です。なお、Androidにウイルス対策ソフトを入れている方の端末では、HFP接続をしようとする時点で確認メッセージが出ていました。そのくらいの確認の手間はとってもいいのではないでしょうか。