かなわぬ思い

すっかり年末モードです。予期せぬ天災と事故があった１年でしたが、年末まで期待して待っていた楽しみのいくつかは結局やってこず、どうやら来年へと持ち越されそうです。

まず、第一に、結局 SAM3XもSAM3Aも正式に発表されなかったこと。いつものATMELの調子だと発表されてから入手可能になるまで半年は待たされるので、来年後半ですね。他社はCortex-M4も次々に製品投入している状態なんで、ヘタすりゃ製品化見送りですかね。やはり、ここいらでいったん見切りをつけて、来年はメジャーなSTM32やLPCを使うことを考えた方がいいかもしれません。救われたのは、OlimexがSAM3-H256を出してくれたことでしょうか。円高もあって、2500円もしないで買えるようになったのは、わたしにとっては朗報でした。

そして２番目は、iWRAP5.0. iWRAP4.0での不具合修正ファーム(4.0.1)を入手した際に、12月中にでもiWRAP5.0の公開ベータが始まるという情報を得たのですが、結局延期になっている様子。こちらは正式リリースが来年春から夏頃のようですから、まだまだ期待は持てそうです。

SDPの違いは動作の違い

iWRAP4.0.1を導入して、すぐと気がついたことがあります。それは、やはりAVRCPに関する動作でした。今回の記事では、WCA-009を使って動作の違いを確認するとともに、その原因を探ってみることにしまいた。

まずは、どこが違ったのかの説明から。iWRAP4.0.0ではiPadからBluetoothの接続をおこなうと、次のようにWT32上にイベントが表示されました。

それが、iWRAP4.0.1ではこのようになります。

一目瞭然、iWRAP4.0.1ではA2DPだけでなく、AVRCPについても接続されています。本来、こうあって欲しかったのですが、iWRAP4.0.0ではA2DPはつながるものの、AVRCPはつながりませんでした。しょうがないので、callコマンドを使うことでWT32側からAVRCPのリンクを張っていました。どちらの場合も、iPad側はiOS 5.0ですので、この動作の違いが生じる要因はWT32側にあることになります。iPad側から接続手続きが始まっているので、AVRCPのプロトコル動作が原因では無いということもわかります。すると、原因はWT32が公開しているSDP情報の違いに起因していると推測することができます。

と、いうわけで、WT32が提供しているSDP情報を調べてみることにします。使うのはいつものようにLinux上のsdptoolです。まずは、iWRAP4.0.0の場合。

そして、こちらがiWRAP4.0.1の場合。

ほとんど同じような内容ですが、よく見るとiWRAP4.0.0ではA/V Controller ServiceにおいてService Class ID Listが含まれていなかったことがわかります。つまり、iPadではこのService Class IDを確認してAVRCP接続を起動するかどうかを判断していたのですね。実はiWRAP4.0.0を使った場合でも、AVRCPをtarget側に設定した時にはちゃんとService Class ID Listは出ていました。ですから、controller側でSerivice Class IDが出ていなかったのは、iWRAP4.0.0でのバグだったのですね。

iWRAP4.0.1でつないだ場合にAVRCP GET_CAPABILITIES_RSP REJというイベントが表示されていますが、この意味するところは、今のところ不明。avrcp pduコマンドをつかってGET_CAPABILITYを送ってみると、サポートするイベントはちゃんとひろうことができています。iWRAPのAVRCPスタックが自動的に何やらリクエストを送っているのでしょうが、それが何なのかはわかっていません。

SCCBとの相性

先日のMTM07では、CMOSカメラもこっそりと(?)展示していたのですが、そのソフトウェアで気になっていた箇所があったので、ようやくとその部分を調査、修正しました。



その部分とはOmnivisionのCMOSカメラの制御用シリアルであるSCCBとのインタフェースです。SCCBはI2Cのサブセットみたいなシリアルなので、SAM3SであればTWIと接続して使用します。ところが、わたしはこれまでこのTWIとのインタフェースがうまくできずに、結局GPIOでソフト的にSCCBを制御していました。今回も以前作成したコードを流用したのでソフト処理だったのですが、この機会に再度TWIを使っての接続に挑戦することにしました。

今回もいろいろと試行錯誤があったのですが、ようやくとTWIを使っての制御ができるようになりました。要点としては...

• レジスタへの書き込みは、TWIの通常の書き込みを使って行えた。PDCを使ってのDMA転送での書き込みも問題なくおこなえる。
• 苦労したのはレジスタの読み出し。TWIの持つレジスタ番号を指定しての読み出し操作を利用するとNAKエラーになってしまう。デバイスのアドレスとレジスタの指定をする書き込みと、レジスタ内容を読み出す操作のふたつのフェーズに分けて処理することで読み出しできた。

ATMEL ARMのTWIでは、TWI_MMRレジスタ内に読み出そうとするデバイスの対象レジスタ番号を指定して、読み出し操作をおこなうことができます。この機能を用いると、マイコンがデバイスアドレス/レジスタの指定という書き込みと、レジスタの読み出しの二つの処理を連続して一度にやってくれるので、とても便利です。ところが、この機能を使うとほとんど必ずNAKエラーが発生してしまいます。SCCBでは転送の最終ビットがDon't Care Bitとなっており、ACKになっていないための影響だと想像できます。ふたつのフェーズに分けて処理をおこなうと、なぜかNAKエラーも生ぜずに読み取りがおこなえるようです。

コツをつかんでしまえば簡単なことだったのですが、何度も試行錯誤してようやくと得られた結果です。苦労させられたもうひとつの要因は、マイコン側とカメラ側でTWI/SCCBの状態不整合が発生してしまったことです。読み出し時の２つのフェーズの最初のフェーズでマイコン側がエラーを検出すると、その時点で処理が止まり、２つ目の読み出しフェーズの処理がおこなわれません。ところが、カメラ側は読み出しフェーズを期待して待っているようです。マイコン側が、再度読み出しに先立つデバイスアドレスとレジスタ番号を送っても(書き出しても)、読み出しを期待しているカメラ側はこれを受け付けなくなってしまうようです。残念ながら使用したOV7670カメラモジュールにはリセット信号が端子として出ていません。そのため、明示的に初期状態に戻すには電源の入れ直しが必要でした。ソフトを修正しても、カメラをリセットしないとちゃんと動かないということに気づくのに、エラく時間消費してしまいました。リセット端子が出ていればこんなに苦労しなくて済んだのになぁ。

HIDをSSPで試してみる

おそらくこれまでにHIDを試したのは一度しかないと思うのですが、ブログ記事にはしていませんでした。MTM07でHIDへの需要があることがわかったので、改めてHIDの使い方を確認しておくことにします。トラ技で紹介後、試作目的でWCA-009を購入された企業も何社さんかいらっしゃいましたが、その中にもHIDの利用を想定していると思われる方が複数あるようだと想像しております。HIDだけが利用目的であれば、オーディオ機能まで含むWT32はオーバー・スペックであり、WT11で用が足りそうですが、技術適合を通したモジュールとなるとWCA-009に行き着くことになるのでしょうか。今回、実験に使用するのはこの記事で紹介した、簡易Bluetoothスピーカ用に製作したもの。このボードに用意してあるタクト・スイッチも使います。

まずは設定から...



今回はSSP(Simple Secure Paring)を使ってみることにします。SET BT SSP で設定していますが、今回はわざとパスキーを必要とする設定にしてみました。SET BT SSP 3 0にすれば、パスキーの入力は要求されません。

Windows 7とつなげてみます。コントロール・パネルからデバイスの追加を実行すると、HIDの設定をしたWT32-Aが見つかります。



ちなみに、SET BT CLASS 00580と設定しておくと、この段階でキーボードではなく、マウスの絵が表示されます。「次へ」をクリックして進むと。。



デバイス側でのパスキーの入力を要求されますので、WT32側で表示されたキーを入力します。すると次のようにペアリングが完了します。



WT32側の動作の様子は次のようになりました。



最初の２行がペアリングの際の様子です。Windows 7側からパスキー要求があったことが表示されています。そこでSSP PASSKEYコマンドを使って要求されたパスキーを入力します。上記のWindows 7側の表示とは別のキーを入力していますが、これは２つの画面ダンプを取得した時刻が異なっているため。もちろん、Windows 7側で表示されたパスキーを入力します。

ペアリングが完了すると、Windows 7が接続してくるのでRINGが表示されます。以降、シリアルからの入力はHIDデバイス入力を指定するものと解釈されます。通常の7ビットASCIIコードの範囲はキーボード入力としてホスト側に渡ります。この状態になると、シリアル入力は全てホスト側へ渡す扱いになってしまうので、シリアル入力によってWT32をコマンドモードに戻すことができません。そこで、タクト・スイッチの登場です。SET CONTROL ESCAPEの設定によりPIO6がDTR信号によるエスケープとして機能するように設定してあるので、該当スイッチを押すことでコマンドモードに戻ってREADYプロンプトが表示されます。

LISTコマンドを使うことで、２本のリンクが張られていることがわかりますが、これらはUSB HIDのControl pipeとInterrupt pipeに相当します。

コマンドモードから再びHIDモードに入るには、SELECTコマンドを用います。スイッチを押して、CLOSEすればHIDの接続を切断することができます。

このように、英字キーボード代わりに使うのは簡単にできます。マウス入力をするためには、HIDのマウスレポート形式での送信が必要となるので、端末ソフトを使っての簡易的な実験では無理があります。マイコン使えば、加速度センサーでマウス動かすくらいは簡単にできそうです。簡単に使えることができる反面、大幅に簡略化されており、ユーザが制御できない事項もあります。

• デバイスのモデルがマウスとキーボードに限定されている。他の種類のデバイスのレポートを送れない。
• ホスト側からのデバイスへの送信や制御ができない。キーボード上のLEDの点灯制御やマウスの感度調節というようにホスト側から情報を送信したり、パラメータを設定する操作がサポートされていません。

基本的なキーボドやマウス代わりに使うのであれば、さほど困ることは無いと思われますが、ちょっとシャレた機能になるとサポートできません。例えば、マウスのホイールなんかはサポートできないようです。こういったHIDサポートの制約は、iWRAP5でいくらか緩和されるようで、ホイールのサポートやキーボード上のLEDの制御等ができるようになり、デバイスモデルとしてもJoystickやGame controllerが追加されるようです。iWRAP5が使えるようになったら、改めて調査する必要ありです。

iWRAP 4.0.1

何度かご紹介したWT32のファームウェアiWRAP 4.0とiOS5とのAVRCP接続不具合。これまでは、バグ対応したβ版コードを使っていましたが、昨日 Bluegiga社から正式なパッチ版がリリースされました。バージョンは 4.0.1 build 488です。




わたしはBluegigaの supportに「正式パッチは出さないのか？」と問い合わせていたので、向こう側から連絡入れてくれました。まだBluegigaのサポートサイト上では公開されていないようです。待てば公開されるのかもしれませんし、このまま必要な人にしかコード出さないのかもしれません。来年にはiWRAP 5.0のリリースを予定していることもあり、製品出荷についても特別な要望がない限り当面は現行どおり iWRAP 3.0またはiWRAP 4.0で出荷される模様です。WCA-009は、iWRAP 4.0のモジュールをヘッダボード上に実装した製品となっていますが、本日以降の注文分については、あらかじめ当方で4.01にバージョンアップした上で出荷させていただくことにします。

先日のMTM07で購入していただいた方を含め、これまでにWCA-009を購入していただいた方には、わたくしからコードをお渡ししますので、御面倒ですがメールにてご連絡をいただけるようお願い申し上げます。

MTM07へのご来場ありがとうございました

ようやくと２日間の疲れが抜けてきました。まずは会場にお越しいただいた方々にお礼申し上げます。



会場ではiPod Touchで再生する音楽をBlueSAMで聞けて、タイトル情報等が見れる様子をデモしました。多くの皆さんがケースを手にとると裏返してみようとなさるのですが、なにしろ急ごしらえのケースなもんでちゃんと蓋が閉まっていません。蓋が外れてしまい、中の基板がずっこけて出てきてしまうことしばしば。もともとしっかりと蓋がしまるようなケースでもないのもいけないのですけど。



そんなBluetooth部分をみたがる方のために、トラ技の記事で紹介した実験ボードも持参。「紹介記事が掲載されています」とご案内すると、多くの方が「買ってあるので、帰ったら読んでみます」とおっしゃってくださいました。また、その場で購入を即決してくださる方もいらっしゃり、ありがたい限りです。決して安くはない買い物なので、「そんなに簡単に決断しちゃって、いいの？」とちょっと心配になってしまいます。技術的質問にはできるだけお答えしますので、購入された方は遠慮なくメールでご連絡ください。

また、すでに購入された方も4名訪ねてくださり、挨拶をかわすことができました。ほんと嬉しい限りです。

会場でみなさんと話をしてみると、HIDができるモジュールを探しているという方が何人かいらっしゃいました。WT32はHIDプロファイルもサポートしていますが、デバイス側だけでホスト側はサポートしません。ほとんどの方は、デバイス側に興味があるようなので、使えそうでもありますがWT32のHIDサポートには機能的な制約もあるので、そのあたりの確認が必要になるかもしれません。このへんの事情については、簡単に調べて次回の記事にしようかと思います。

残念ながら今年はW-SIMジャケットの用意が間に合わなかったので、代わりにCMOSカメラを持っていきました。こちらは、視線を向けた人だけを対象に控えめにデモ。




バーコード読み取りのデモをしましたが、電子工作に興味のある人からは、すぐにどうやってカメラつなげているのかの質問が飛んできます。一方、多くの人からは「ふーん。QRコードはできないの?」というツッコミを頂戴します。携帯電話でもできることなので、これだけでは訴求力に欠けているのは確かで、当初から予想された反応でもあります。

カメラはUSB給電で動かしているのですが、USBケーブルがつながっていると、コードの読み取りはPC側でやっているのだろうと思われる方がいらっしゃいました。そこで２日目は写真のように電池を使ったUSB電源を並べて配置することで、スタンドアロンで動作していることを強調できるようにしてみました。

説明文に示したように、CMOSカメラのデモとしては「バーコードリーダ」だけでなく「ナンバー読み取り」というのも用意してありました。こちらは、会場の光線やカメラの向きによって結果が左右されがちなデモでした。そのため、カメラに関心を持って質問された方や、知り合いの一部の方だけにデモさせていただきました。いずれ、当ブログでも簡単に紹介したいと思います。

今回の展示物では、BlueSAMでは SAM3S4A, CMOSカメラではSAM3S4Bと、どちらもATMELのCortex M3マイコン SAM3Sを使っています。使っているマイコンを尋ねる質問は、FAQなのであらかじめハードウェア概要を示した説明を用意しておきました。（最初の写真参照)。しかしながら、多くの方が、ATMELと聞くと 次に「AVRですか？」と尋ねられます。やはりATMELがARM出していることは認知度低いですね。そして、CMOSカメラの方ではOlimexのボードを使っていますので、1) ATMELベースであり, 2) ボード形状であるという２点から、「これって、Arduinoなの?」と聞かれる方もかなり多い印象。なんだか、

ATMEL --> AVR --> Arduino

という図式というか連想の流れができている感じ。恐るべし Arduino!!

MTM07出陣前

あっという間にMTM07当日です。どうにかBlueSAM用のケースを用意しました。



LCDをレース内に収めてしまえば液晶正面が外に露出しなくても済むのですが、そうすると厚みが増えてしまいフタが閉まらなくなってしまいます。穴をあけることでなんとかフタが閉まります。こうなることはだいたい予測できていたので、万一これでもフタが閉まらない場合には、WCA-009の足を短くしてしまえるようにWCA-009を受けるヘッダソケットにはロープロファイルのものを使ってあったりします。ただし、これをやってしまうと細かいことを言うと電波法違反になってしまいます。

残念ながら今年はW-SIMジャケットの新作を間に合わせることができませんでした。昨年製作したものの広く公開はしていないBluetoothジャケットを持ってはいきますが、認証/認定されていないWT32を使用しており電波法違反になるので公開デモは控えます。代わりにCMOSカメラを持っていきます。