I2C液晶を使おうと思ったが

MiniSAMボードを使ったMMA8452Qのデモ動画を用意しようと思っているのですが、なかなか時間がとれないでいます。今度の週末には簡単なデモ動画を用意するつもりです。

そうしていたところが、Strawberry LinuxからMMA8451Qを使ったDIPモジュールが発売されたことを知りました。コンデンサも実装済みですから、これならハンダ付けに自信が無くても安心して使えますね。うーん、惜しいところで注文がすれ違いになってしまいました。実は、ちょうどStrawberry Linuxから小型I2C液晶を買ったところだったのです。



LEDの代わりにI2C液晶をつなげるつもりでC基板を用意したのですが、Strawberry Linuxの説明書によるとこの液晶はプルアップ抵抗として数10Kを使わないとちゃんと動かないとの注意書きがあることに気がつきました。現在MiniSAMボードではMMA8452Qに都合のいいように4.7Kを実装済みなのですが、これでは小さすぎるのではないかと思われます。抵抗付け替えようとするとパターン剥がしそうな気がするので、もう１枚組もうと思ったのですが、こんどはSAM3Sの在庫が切れていることに気がつきました。うーん、しょうがないから追加でSAM3S買うかな。

iWRAP 5.0リリース

長らくベータが続いていたiWRAP 5.0ですが、先週 火曜日にRC6が出たと思ったら、続いて金曜には正式リリースとなったようです。User Guideも 5.0.0用が公開されましたが、Application Noteの更新はまだこれからのようです。そんな事情もあっってか、先週はなんの公式アナウンスもありませんでした。そろそろ正式にアナウンスがあるでしょう。

さて、iWRAP 5.0ですが、これまでのiWRAP 4.0とは大きくことなる点がいくつかあります。そのおもだったものを列挙しておくことにします。

• ライセンスキーが必要となった
  なんといっても一番大きな違いがコレ。ライセンスキーが無いと、ファームウェア自体は動き始めるものの無線部分が動作しないため電波の送受信ができません。ライセンスキーはsupport@bluegiga.comに連絡すればもらえますので、これを新たに用意されたlicenseコマンドを使って入力してやります。
• 複数のファームウェアイメージから用途に応じて選択
  以前にも紹介したことがありますが、オーディオ送信側(A2DP source/HFP AGW)か受信側(A2DP sink/HFP HF unit)かに応じて使用するイメージを選択する必要があります。コードが大きくなってフラッシュに入りきらなくなったのでしょう。
• iAPサポートは別イメージ
  同様にAppleのiAPに対応するファームも別イメージとして提供されます。ただしイメージの提供を受けるにはAppleのMFIプログラムに参加していることが条件ですので、一般アマチュアユーザには関係の無いところです。iAPを実際に使うためには、MFIに参加したうえでAppleから認証チップを購入して接続する必要があります。Appleってこういうライセンスビジネスもしっかりしていますよね。
• HDPはWT32ではサポートされない
  これもサイズが原因でしょうか。ちょっと残念。

ライセンスキーの入力には、licenseコマンドを使う以外にも、PSTOOLをつかったり Serial DFUで指定する方法もあるようですが、licenseコマンドを使うのが一番簡単なようです。

3g出そうと振ってみる

乾電池で動かすことができるようになったので、そろそろMMA8452Qのデモ動画を用意しようかと思案中。これまでに実験してきたタップ検出と縦横検出を使ってLEDの点滅を変化させるLチカをやるつもりでいますが、これだけではちょっと寂しいので動き検出機能も使ってみることにします。



近頃の加速度センサーの例に漏れず、MMA8452Qでも加速度の閾値を超えたことを検出することで自由落下や動きを検出することができます。例えば、手で振ったりすればちっと大きめの加速度が生じますので、閾値を超えたことで検出ができます。同様に自由落下であれば0gになるので、小さめの閾値以下になったことで検出が可能です。持続時間を設定することで、例えば数センチの落下は無視して、10cm程度以上であれば検出ということもできるのですが、デモとしては手で振った方が見栄えがしそうです。

他の例と同じようにAPノートにあった100ms以上3g超えの設定を試してみました。実際にやってみると、これが思ったよりも大変。ちゃんと気合い入れて振らないと条件を満たせません。ちょっと楽するために1.5g～2.0g程度でいいかな。

2枚目は電池で

MiniSAMボードの2枚目を製作。こちらは電池駆動で使ってみようかと思います。思えば、いままでLiPo電池は使っても、乾電池で動くようなものを作ったことがありません。これまでバックアップ用途で使っていた手持ちのCR2032をつなげてみましたが、今度はこれを主電源に使って動かしてみようかと思います。sleepとか deep sleep使わないと電池もたないでしょうから、これらの勉強するのも目的のひとつです。

小型LCDでもつなげたいところなのですが、手持ちがないので、とりあえず手持ちの２色LEDで動作状況表示することにしてみます。スペースもあったので、なんとなく２つ使用。ずいぶん前に買ってあったのですが、改めてみるとこのLEDは赤、緑、赤になっており、赤が２つ入っています。なんかうまい使い方あるんでしょうか？

消えゆく風景

きょうはマイコン ネタではなく、ローカル ネタです。

夏休みです。駅のホームの端には、撮り鉄達が陣取ります。しかし、この時期ばかりはわたしのような「にわか撮り鉄」も多いに違いありません。



そして、そんな彼らの視線の先にも....



普段は気にも留めないありふれた風景でも、それが消えるとなると人はみなそれを記録に残して自分の記憶を補強しようとするのでしょう。老若男女を問わず踏切の中で足を止めてシャッターを切る人が絶えません。

京王線調布駅周辺では連続立体交差事業に伴って、駅舎と線路が地下化され、踏切が無くなろうとしています。そして、踏切を横切る電車を見られるのもいよいよ今週一杯となりました。

こちらの方は自転車に乗って「消えゆく踏切巡り」のさいちゅうでしょうか。踏切名称の書かれた非常ボタン説明板を撮影中。



線路や踏切わきばかりではありません、電車に乗ってもこのとおり。。



線路が地上から消えることにより駅周辺では区画整理がおこなわれ、交通の便も大幅に改善されることが見込まれていますが、それにともなって消えてゆく風景もあるようです。誰でも見覚えのある踏切角のラーメン屋さんも10月には閉店するそうです。

iOS5とHFP 1.6

Android 4.0でHFP 1.6がサポートされていないことがわかってガッカリしていましたが、今頃になってiOS5がHFP 1.6に対応していることを知りました。いままでもどこかで情報を目にしていたのかもしれませんが、iWRAP5側が対応していなかったため気に留めていなかったのかもしれません。

カミさんのiPod Touchを使ってつなげてみるとこうなりました。

余分なメッセージが出ないように、WT32側ではHFPのみをイネーブルしています。iOS5ではFaceTimeが Bluetooth対応したために、Bluetooth接続するとHFP接続ができます。

HFP 1.6らしいところは、最初のHFPのイベントメッセージが HFP 0 CODEC NEGOTIATIONとなっていることでわかります。これまではHFP 1.5だったので使用できるCODECはCVSDだけだったのですが、両者がHFP 1.6対応になったことでCVSDとmSBCをネゴして使えることを示すようになったようです。しかしながら実際にFaceTimeで着信を入れてみるとCODECとしてはCVSDが使われてしまいます。うーん、残念。残念ながらiWRAP5とiPod Touech側のどちらが悪いのか調べるすべを知りません。あるいはFaceTimeがそもそも16K音声対応していない可能性もあるかもしれませんね。

iPod TouchでFaceTimeを使う場合にはメールアドレスと紐づけて使いますが、Apple側では擬似的な電話番号を割り当てているらしく、CALLERIDとして見えるのが興味深いところです。でも、これではヘッドセット側ではメールアドレス表示できませんね。もう一つ気になるのは、HFP 0 STATUS "service" 0 となっていること。ネットワークサービスダウン状態なのに、いきなり着信入ってくるんですけど。。

MBAも先日 MacOS X 10.8 Mountain Lionに上げていたので、念のために確認してみました。同じくFaceTimeで着信いれてみました。

こちらはHFP接続した段階でCODECとしてCVSDが選択されてしまっています。確認しましたが、HFPのプロファイルバージョンは1.5のままでした。しかし、ちゃんと STATUS "service" 1が出ており網側サービスが利用可能なことが通知されています。ネットワークがAPPLEになっているのもちょっと面白いところです。しかしながら、着信入れても発信者番号の通知は出ていません。

Mountain LionになってさらにiOS5との統合が進んでいると言われていますが、Bluetoothに関してはまだまだ動作に細かな違いが残っているようです。

Digikeyでも買えるOLIMEX

昨年からMouserで買えるようになっていたOLIMEXのボードですが、今度はDigikeyでも買えるようになったとのこと。こいつは助かります。OLIMEXには、そろそろSAM4Sのヘッダーボードを出して欲しいものです。

MMA8452Qで縦横向き検出

前回タップ検出をおこなったので、続いて縦横の向き検出です。近頃のタブレットをはじめとする電子機器では、縦横の向きを変えると それに応じて画面表示を回転してくれますが、これを実現しているのが加速度センタを用いた向きの検出機能です。この機能についてもアプリケーション・ノートAN4068が用意されており、向き検出の原理とMMA845xQでの具体的な設定について説明されています。



基本的には上図に示すようにX軸、Y軸に加わる重力加速度の変化を調べることで、向きが変わったことを検出します。しかし机のような水平面上にタブレットやスマホを置いて向きを回転させても、画面表示を回転させてくれることはありません。水平面上で向きを変えても、X軸、Y軸に加わる重力加速度には変化が生じないため、検出できないからです。わずかな傾きしかない場合にも、変化が微小であるために向き変化の検出は困難となりますので、ある程度Z方向に傾けた状態で向きを変えてやる必要が生じます。MMA8451Qでは、検出のために必要なZ軸方向の傾きを14度～42度の範囲で選択することができますが、MMA8452Qでは29度で固定となっています。同様に、MMA8451Qでは向き変化の判定に必要な回転角度やヒステリシスの大きさを指定することができますが、MMA8452Qではそれらの値も固定値となっています。結果として、APノートにはいくつものレジスタを設定する手順が示されていますが、MMA8452Qではその多くは設定の必要がありません。

MMA8452QをMiniSAMボード上に実装した状態では、方向の定義は次のようにUSBコネクタがついている向きで示すことができます。

上図のようにボードを回転させていくと、向きが変わったことを検出して割り込みがかかります。その時点でPL_STATUSレジスタの内容を調べれば向きを知ることができます。実際に実行した場合のログは次のようになりました。

設定後、センサーをアクティブにした時点でダミーの状態変化割り込みを発生してくれるので、現在の状態を知ることができるというのもナイスな仕様です。また、Z軸の値でボードが表向きか裏向きかも判別できるので、その状態変化も検出できます。このように向きや裏表の状態でデバイスの動きを制御するのに利用できそうです。タップ検出もそうでしたが、向き検出ロジックは全てMMA825Qが内部で処理してくれるので、マイコン側では各軸の加速度データは全く読み出さずに、これらの検出処理ができてしまします。

説明文よりも動画の方がわかり易いでしょうから、そのうちに何かしらデモ考えてみます。

MMA8452Qでタップ検出

前回に続き、MMA8452Qです。タップ検出機能を試してみたので、その概要報告です。まず、タップ検出の仕組みを下図に示します。MMA8452Qではタップ操作によって生じた加速度変化を検出して、外部に割り込みをかけることができます。タップとして認識するための条件として、加速度の大きさや持続時間をレジスタで指定できます。ダブルタップの検出の場合には、２回目のタップまでの間隔(Pulse Window)を指定することができます。このように条件さえ指定してやれば、あとはチップ内蔵の検出ロジックが働いてくれるので、ホストマイコン側は割り込みを寝て待てばいいだけなんでとっても楽チンです。



とはいうものの、加速度の大きさや持続時間なんて実際にデータでもとってみないとどういう値を指定すればいいのか見当もつきません。幸いなことにFreescaleがアプリケーション・ノート(AN4072)を用意してくれており、実際のレジスタ設定例も出ていますので基本的にそれを真似れば動作確認することができます。設定例としては、シングルタップ検出、ダブルタップ検出、シングル/ダブルタップ検出の３種類の例が紹介されていますが、どうせならということで両方を検出できるシングル/ダブルタップ検出を試じてみました。実際に試してみてわかった注意点を列挙しておきます。

• 設定例には設定すべきレジスタと設定値が順序だてて紹介されているので、そのとおりにプログラムすればいいのですが、どういうわけかCTRL_REG2の設定だけが示されていません。例ではLPモード(Low power mode)の場合のレジスタ値が示されているので、まず最初にCTRL_REG2に0x18を書き込んでLPモードに設定しておかないと、その後のレジスタ値の意味が違ってきてしまいます。
• 設定例では、XYZの３軸ともにトリガ条件を指定しています。XY軸では加速度の閾値を1.575gに設定していますが、Z軸では2.65gに設定しています。最初は「どうしてZ軸だけ大きい値を指定しなければいけないんだ？」と思いましたが、Z軸方向には重力加速度が1g加わっていますから、当然ですね。
• シングルタップとダブルタップの両方の検出を許可してダブルダップをおこなった場合には、上図のシングルタップ検出と同じように割り込み要求は2回発生します。ただし、PULSE_SRCのDPE(Double Pulse on first Event)ビットの内容が異なります。最初の割り込みではDPEが0ですが、2回目の割り込みではDPEが1となります。

このように、シングル/ダブルタップの両方を検出するための設定はあるのですが、どちらの事象が発生したかの区別はユーザ側で処理する必要があります。シングルタップの発生を通知する割り込みであるかのように見えても、それはダブルタップ操作の１回目のタップを検出しているのかもしれません。Pulse Window時間を待ってみて、DPEの通知があるかどうかを見極める必要があります。実際に、この処理をおこないタップ検出をおこなってみた様子を次に示します。

• ミニUSBコネクタのあたりを指で叩いているのですが、その時によって検出する軸が違っていたりします。コネクタがボード下部についていることもあり、Z軸よりもY軸での検出が多いようです。
• カンマで区切られた２つの数字は、左側がとおしの割り込み発生回数、右側が結果表示回数です。ダブルタップ検出時には、DPEの表示がありますが、その場合には割り込み回数が2回増えていることがわかります。

幸いなことにAPノートの例のとおりの閾値設定で調子良く動いてくれましたが、実際にケースに収納する場合には設定パラメータを調整する必要が生じるかもしれません。

MMA8452Q

ハンダ付けを終えたSAM4SAボード、自分のプロジェクトととしてはMiniSAMボードと命名したので、以後この名前で呼んでいくことにします。SAM3S本体は動いているので、続いて加速度センサーのMMA8452Qの動作確認に入いるつもりです。

MMA8452Qには、MMA8451Q, MMA8453Qという兄弟デバイスもあり、加速度データのビット長やFIFO機能の有無といった違いがあるようです。MMA8451Qがフル機能で、MMA8452QはそこからFIFO機能を削ったもののようです。もっともこういう違いを認識したのは買った後の話でして、もともとSparkfunがMMA8452Q単体やBreakout boardを販売していたので、これが一番メジャーなんだろうと思って買っただけのことです。機能重視するんだったら対して値段も変わらないことだしMMA8451Qを買ってもいいでしょう。前回の記事でも触れたようにMMA8452Qはとっても安くて機能も豊富なのに、不思議と国内では趣味の電子工作で使われた例を見かけない気がします。やはり小さいからでしょうか。高くても入手性の良い秋月のセンサーがダントツでポピュラーですよね。Switch science magazineのこの記事なんかじゃ、「単純に値段で選ぶならコレ」という調子で紹介されていますが、ちゃっと可哀想すぎる扱いです。そこで、今回はこのセンサーの概要について簡単に書いておくことにします。



まず、ハード的な使い方は上図のとおり。I2Cでつないで、レジスタを読み出すことで加速度データやイベントを読み取ります。アナログ出力がないので、I2Cでレジスタ読んでみないとちゃんと動いているかどうかの確認ができません。今回はどうやら無事にハンダ付けできたようで、３軸加速度の値が変化することを確認できました。割り込み要求のラインが２本あり、ホストに対してイベントの発生を通知することができます。SA0はI2Cのデバイスアドレスの最下位ビット値選択用です。

レジスタを設定することで、いろいろな動作をさせることができます。

• 省電力だけども精度は低い動作と電流は消費するけど精度の高い動作モードを選べる。データの更新頻度も選択でき、それによっても消費電流が異なる。
• 自由落下や一定以上の加速度の検出をトリガとして割り込みをかけられる。
• タップ、ダブルタップの検出ができる。
• 縦向きから横向き、横向きから縦向きに変わったことを検出できる。

加速度とその持続時間を閾値として設定しておくことで、自由落下や動きを検出する機能は、秋月が扱っているKXP84-2050なんかにも備わっていますが、MMA8452Qではタップ検出や向き検出までやってくれるというのに興味をひかれた次第です。これらの検出も関係するパラメータをレジスタで設定しておけば、対応するイベントが発生した時に割り込みで通知してくれます。そのため、マイコン側処理としては割り込み要因を解析する程度の処理をすれば良く、加速度データを読み出してその変化を解析するようなソフトウェア処理をまったく必要としません。

こりゃ楽チンですね。そういうわけで、まずはタップ、ダブルスタップの検出を試してみるつもりです。