Static Handover

NFC Booster packを使った実験の続きです。前回から何もソフトを変更していないのですが、タグの書き換えができることが確認できたので、今度は違う種類のタグを書いてみます。

NXPのTagWriterには、Bluetooth機器の名前とアドレスを情報として持つNDEFを作成、送信する機能が用意されていますので、これを使ってみます。まずは、情報の入力...




これを送信してやると、次のように成功を示す画面が表示されます。



確認ができたらTagWriterを終了して、音楽プレーヤを起動。そしてBooster Packに近づけると...




ペアリングの許可を求めてきます。この時点ではBluetoothの電源はオフ状態になっていますが、OKをタップ。すると、電源を入れて、ペアリングを実施。続いてWT32への接続を自動的に行ってくれます。




このようにして、NFCでかざすだけでBluetoothのペアリングと接続をおこなえることが確認できました。上記の一連の操作では、マイコンは全く関与していません。そのため、１枚100円もしないで買えるNFCタグシールのようなものを買っても同じことは達成可能です。

NFCを使ってのBluetooth接続の確立手順については、NFC ForumとBluetooth SIGによりBTSSPという標準化がなされています。この文書を読むと、NFCを使ってBluetooth接続をおこなう方法にはNegotiated Handover とStatic Handoverの2種類があることがわかります。タグシールでも実現可能なのは、Static handoverの方です。マイコンのソフトを用意してやれば、Negotiated handoverの方もできると思われるので、これに挑戦してみるつもりです。

NFCによるHello, World

昨日動かし始めたNFCボード。まずは簡単に動作確認のためにHello, Worldしてみました。実際に動かしてみると、バカみたいに簡単に使えます。

1. まず、書き込むべきタグのNDEFデータを用意します。
2. 用意したデータをRF430CL330Hの０番地以降に書き込みます。
3. General Control RegisterのEnable RFビットをセットします。

たったこれだけです。RF430CL330Hは、その名前から察しがつくようにMSP430コアを使ったチップになっており、その０番地から0x0BFFまでの3kBに空間にNDEFデータを保持することができます。制御レジスタもメモリ空間にマップされているようで、16ビットでアドレス指定して、16ビットの値を読み書きします。

NDEF(NFC Data Exchange Format)は、定められた形式に従っている必要がありますが、TIの純正ターゲットボードの説明書にHello, Worldのサンプルがありましたので、これを流用。サンプルプログラムでは割り込みを使ったりしていますが、NFCデータの読み取り動作確認だけであれば割り込みは不要です。注意点としては現行のVersion Dのチップにはまだバグが残っていること。RFが応答しなくなるバグがあるらしく、その回避に必要な初期化操作がエラッタに掲載されていますので、このコードを追加しておきます。

こうしてタグデータの用意ができたなら、実際にその内容を読み取ってみるのにNFCのリーダが必要です。いまどきのAndroid携帯であればNFCを持っているのですが、残念ながらわたしのドコモGalaxy S3はお財布には対応していてもNFCには対応していません。しょうがないので携帯を買い替えるよりは安価な、Nexus 7を購入。個人的好みとしてはNexus 7よりはiPad Miniが欲しかったのですが、iPhone/iPadはNFCをサポートしていないので。。。

NFCのタグ読み取りのためのアプリとしては、NXPのTagWriterとKDDIのNFCタグリーダーをインストール。アプリの読み取りを起動して、ボードのアンテナ部分の上にNexus 7をかざすことでデータを読み取ります。




上の写真は読み取り後、Nexusを横に動かした後の様子。画面は下のとおりです。



KDDIのアプリでも同じように読み取れます。




これらのアプリは、タグの読み取りだけでなく書き込みもできますので、マイコン側ソフトでは何もしなくても、RF430CL33Hのタグデータの書き換えもできます。ちゃんと割り込みの許可と検出を行えば、書き換えられたことを検出して、その内容をマイコン側で読み取ることができます。

NFC Booster Pack

注文してあったブツが届いたので作業を進めたいのですが、連休とはいえ掃除を命じられなかなか作業が進みません。まぁ、正月休みまでかけて、ゆっくりと楽しめばいいのですが。。さて、届いたブツはこれです。




DLP Design社のNFC Booster Packです。TI社のNFCトランスポンダRF430CL330Hを搭載した拡張ボードです。もともと、TIのLaunch pad用に用意された製品です。つい最近発売になったらしく、DLP Designの関連サイトには何も情報が準備できていない状態だったのですが、Digikeyに在庫があるのを見つけて注文しました。どうやら、Mouserにも数日前に在庫が入ったようです。チップ単体でも購入できますが、アンテナパターンをもったPCBを自作することを考えれば、1000円ちょっとで買えるこのボードは充分に安いのではないでしょうか。



用意しておいたボードの上に載せてみて、ほくそ笑みます。WCA-009実験ボードとは、LCDと同じくI2Cで接続しています。WCA-009実験ボードにはI2Cの終端抵抗を実装済みですが、このBooster pack上にも終端抵抗が載っていました。どちらか取り外さねばならないかと心配していましたが、とりあえずレジスタの読み出しができるようなので、このままでも大丈夫そうです。RF430CL330H自体は、SPIとI2Cの両方のインタフェースをサポートしており、SCMS/CS#端子で選択することができます。この端子は内部でプルアップされているので、ディフォルトではSPIが選択できるように設計されていますが、このBooster packボード上ではI2Cがディフォルトとなるようにプルダウン抵抗が実装されていました。I2CアドレスはE0, E1, E2端子で選択できますが、まだ回路図が公開されていなかったので、ボード現物をテスターであたってこれらの端子はすべてGNDに接続されていることを確認。I2Cアドレスは0x28となります。

さて、このRF430CL330Hを使うと何ができるかというと、動的に内容を変更できるNFCタグが作れます。I2C/SPIを経由してマイコンからNFCタグの情報(NDEF)を設定、変更することができますので、これをNFCをサポートするスマホやタブレットで読み出すことができます。したがって、例えばマイコンにつなげたセンサが収集したデータをスマホをかざして読むとるといった応用も考えられるでしょう。このプロジェクトではWCA-009実験ボードにつないでいるので、もちろんBluetoothがらみで使うつもりです。最近NFCでタッチするだけでペアリングできるBluetooth対応スピーカ製品が数多く発表、販売されるようになってきましたが、アレをやってみようという次第です。

新たな拡張ボード

新しいネタを探していたところ、ちょうど面白そうなものが見つかったので、その準備作業としてWCA-009実験ボード用に新たな拡張ボードを製作。



液晶を下側に配置し、キーパッドは無し。新たなヘッダピンを立ててありますが、これは手配中のボードを接続するためのものです。先日、Digikeyでポチったところなので、あさってくらいに届く予定。詳しくは、ボードが届いてから記することとしたいと思います。

blobs

先週、いしかわさんの日記を読むまでSeed StudioでGameduino 2が発売になったとは知りませんでした。とういか、US以外のbackerに対してはseedから出荷されるみたいですね。Kickstarterで資金調達に成功していたのは知っていましたが、まさかこんなに早くに発売になるとは思っていませんでした。

さて、このGameduino 2ですが、今のところライブラリの仕様がbacker以外の人には公開されていません。しかしながら、いくつかのデモコードを見れば、基本的にはFT800のもつコマンドに対応したAPIが用意されているようです。そこで簡単に移植できそうなblobsをLPCCappucinoで動かしてみました。タッチされたパネル座標の軌跡に円を描いていくデモです。時間が経過するにしたがい円の半径が大きくなるとともに、色が薄くなっていき消えて行くというデモなんですが、ボンヤリ見ているのもけっこういいもんです。





色が薄くなっていくのはアルファチャンネルの値を減少させているだけです。このようにアルファチャンネルを使った効果が出せるのもFT800の楽しいところではないでしょうか。

Gameduinoの他のデモも良くできているなぁと感心させられますが、綺麗なビットマップを製作するのは、わたしにはムリだなぁ。

在庫グレード

秋月のページを覗いていたら、LPC810の在庫グレードがAになっているのに気がつきました。あれれっ？　販売開始した時には 少なくともAAはあったような気がするんですが。。売れ行きが好調なために、あっという間にグレード落ちたんでしょうか？

安いのをいいことに、みんな５個、10個とまとめ買いしていくんでしょうか？円安の影響で、次のロットは80円じゃ買えなくなるかなぁ？

日本語フォントで表示する

LPCcappuccinoのSDカードの使い道として計画していた日本語フォントの格納と、それを用いた表示作業を時おり進めてきましたが、ようやくと表示できるようになりました。まだまだやっつけ作業なので、これから改善要。



フォントデータはもともとSAM4LでのLCD表示に使っていたものを流用しています。元となっているのはやさしさゴシックフォントです。マイコンにはttfの展開処理は重すぎるので、freetype2を使ってビットマップ展開した独自フォーマットのファイルを作成し、これをSDカードに保存しておきます。上の例では文字の大きさに応じて2種類のビットマップフォントファイルを用意しています。

描画時には、実際に使用しされる文字のビットマップとメトリックデータだけをSDカードから読み込んで、これをEVEにダウンロード、そしてCMD_SETFONTによりユーザ定義フォントとして登録します。現時点ではEVEで使うユーザ定義フォント用のビットマップとするためには、データ読み込み後にさらに加工が必要になってしまっています。また、元データが深さ8ビットであることもあり、EVE上でも深さ8ビットのフォーマット(L8)でダウンロードしています。そのため、RAM_Gの空間をいたずらに消費してしまっています。この例では25kB程度を使用。深さ4ビットに変えれば半分近くに減るはずです。ttfファイルからビットマップデータへの変換ツールを作りなおした方がいいので、そのうちにやろうかとは思っています。

ユーザフォントデータは, RAM_Gの空間にダウンロードするので、画面キャプチャはこの領域を破壊しないようにします。そうすると、全画面をCMD_SNAPSHOTでキャプチャすることはできなくなるので、今回は画面の上半分(480×135)画素分だけをキャプチャしています。

画面キャプチャを取る

ブログ記事を書くのは夜になってしまうことが多いので、なかなか丁寧に写真を撮影する時間がとれません。とくにEVEのようにLCD画面を撮影した場合には室内照明の反射が入ってしまううえに、自分やカメラが映り込んでしまったりします。そこで、LPCcappucinnoでSDカードが使えるようになったのを機会に画面キャプチャを取得することにしました。

普通のLCDコントローラーであれば、フレームバッファのメモリ内容を読み出して適当なフォーマットでダンプしてやれば画面キャプチャを取得できます。ところがFT800にはフレームバッファが無いので、この方法は使えません。しかし、画面への出力内容をRAM_G空間に取り込むスナップショット機能がコマンドとして備わっています(CMD_SNAPSHOT)。このコマンドでいったんRAM_G空間に画面データを取得してから、RAM_Gの内容を読み出してSDカードに書き出すという2段階の手続きを経ることで画面キャプチャを取得することが可能です。RAM_G空間の大きさは256kBなので、ちょうどWQVGAの画面データを収用することができます。

そこで、実際にやってみました。

CMD_SNAMSHOTが取得するフォーマットはARGBが各4ビットというフォーマットになっています。色数が減ってしまうのがちょっと残念。AがあるのでPNGファイルに変換しておけばいいかと思い、libpngを使って簡単な変換プログラムを作成。その結果がコレです。



写真と違って、画像が鮮明になって気持ちいいですねぇ。実際の画面よりも綺麗だし。文字や図形を見てもアンチ・エイリアス処理が施されている効果が良く表れています。元データはARGB4444ですが、PNGファイル上ではcolor_typeとしてPNG_COLOR_TYPE_RGB_ALPHA を使う場合には、ビットの深さは8または16でなければならないようなので、RGBA8888に変換しています。

いい感じだったので、「EVE姐さんを回転しててみる」で生成した画面のキャプチャを取得してみようと思いました。が、これには大きな問題があることに気付きました。"EVE姐さん"の元画像はJPEGなのですが、これを展開した結果もまたRAM_G空間に保存されるのです。そして、残念なことにRAM_G空間はWQVGAの全画面をキャプチャすると、全て消費されてしまいます。CMD_SNAPSHOTではレジスタ設定により、キャプチャする画面サイズを指定することも可能ですので、メモリをやりくりすれば例えば画面の左上部分だけをキャプチャするといった妥協案は考えられます。でも、まぁ、ここはそんなことはせずに、わざとメモリ空間衝突させてみることにしました。



おぉ、どうやらメモリ内容が壊れていく途中の様子がキャプチャされているようです。ちなみにキャプチャが完了すると、もとももとEVE画像の入っていたメモリ領域はすべてキャプチャされたデータに置き換わってしまうので, 再度キャプチャを取り直すとこうなりました。

notificationとbrowsing

久しぶりにBluetoothネタです。

最近はしばしばスマート・ウォッチが話題になりますが、その典型的な使い方がMail, SMS, SNSのメッセージが読み取れるという通知機能の利用です。近頃は低電力化のためにBLEのシングルモードを使った製品が多いようですが、Bluetooth ClassicではもともとMAP (Message Access Profile)が定義されているので、カーナビのような用途では引き続きMAPが利用される場面もあるのではないでしょうか。

MAPではメッセージを保持するサーバ側をMSE, メッセージにアクセスするクライアント側をMCEと呼びますがWT32がサポートしているのはMCE側です。MAPの重要な機能として、次の2種類の機能があります。

1. Message Notification
   MSEが新着のメッセージが届いたことをMCEに通知する機能です。
2. Message Browsing
   MCEがMSEのメッセージを閲覧する機能です。

そしてMAPの標準仕様としては、この２つのうちのどちらかをサポートすることが必須とされています。言い方を変えれば、片方だけサポートすれば、MAPに準拠していると言えるということです。では、WT32ではどうなっているかと言うと、Browsingの方しかサポートされていません。そのため、残念ながら携帯に新着SMSが届いても通知をWT32に飛ばすことはできません。

さて、このMAP機能ですがiPhoneだけでなくAndroidでも使えていたのですが、Android 4.2でBluetoothの周りがBlueZからBluedroidに切り替わったことも影響してか、端末によっては4.1から4.2にアップデートしたらMAPが使えなくなったという悲鳴があがっていたようです。BluedroidではBluetooth部分のHALを定義しているらしく、BlueZの方では改めてこのHALに対応したリリースを出しているようです。