OV9655からの画像

aitendoのOV9655でとったVGA画像をJPEGに変換してみました。aitendoが提供しているパラメータで初期化をおこなうと、OV9655からはRGB 5:6:5で出力されてきます。この形式は、そのまま16ビット幅でLCDに書き込んで表示するのに都合が良く、サンプルのプログラムはそのような玩具向けといったところでしょうか。JPEGに変換するに際しては、AT91SAM<9260のISIの機能を使って画像を取り込む際に、RGB 5:6:5からYCbCrへの色空間の変換をおこなっています。この変換は、ハードが処理してくれます。ソフト側では、YCbCrのデータをlibjpegを使ってJPEGファイルに変換するだけです。

カメラについているレンズがちょっとずれると、画像がいっぺんにボケてしまいます。最初に撮影した画がボケていたので、レンズを調整してみた結果が2枚目の画像です。何度もレンズを廻していたら、だんだんとレンズ筒に切ってあるネジ山がゆるんできたような気がしますorz

<a href="https://blogimg.goo.ne.jp/user_image/64/4c/d5e07bd832ddfc4e9cbd6a83980a2003.jpg">

うだる

気が付くと夏至も過ぎて、うだるような暑さが続いています。日中締め切ったままのわが作業部屋は常時30度超え状態で、33度から34度に達することもしばしば(グラフ赤線)。窓を開ければ少しは下がるものの、風通しもそれほど良くないので、とてもじゃないけどハンダづけなんてできません。そんなところにもはんだづけカフェの意義を感じてしまいます。



週間、月間変化を見れるようにログをフラッシュに記録する機能を追加したいと思いつつも、ずっと作業できずにいます。

SAM3S-EK

2日ほど前のこと。ArrowにSAM3S-EKの在庫が(たしかふたつ)あることに気付きました。きょう、見ると残りひとつに。。。

これが、DigikeyやMouserだったらかなり悩んでいただろうし、ポチッてしまったかもしれません。まだ、ろくっすっぽSAM3U-EKも使っていないのに。自分に対しての言い訳を整えるためにも、もう少しちゃんとSAM3U-EKを使いこまなくてはいけないなぁ。

OV9655

昨年使ったカメラはOV9650だったので、OV9655は同じ1.3Mピクセルだし型番も近いので、ほとんど同じように使えるのだろと想像していました。しかしながら、実際にデータシートを読んでみると、レジスタには細かい違いがあるので初期化部分は全く別に用意しなければならないことが判明。データシートには、細かいレジスタの説明はないので、ほんとの使い方はOmniVisionとNDAして詳しい資料を入手しない限りわかりません。アマチュアにとって頼りにできるのはサンプルプログラムだけです。

当初 aitendoが配布していたサンプルのRARファイルの内容を確認してみたら、中から出てきたのは OV7660.c とか OV7660config.c といったファイルでした。RARファイル名にはOV96555と付いているのに中身が違うように見受けられたので、問い合わせみたところサンプルはこれだけだと言われました。中身の関数名もov7660_init()とかなっており、普通に考えるとov7660用に見えます。ところが、どういうわけか初期化パラメータを書き込む関数だけはwrOV9655Reg()になっており、どのモデルをサポートしているのかわからないような代物でした。しょうがないので、初期化パラメータだけを拝借して実験してみたところ、ファイル名とか関数名とは関係なしに初期化パラメータだけはOV9655に対応しているということが判明。どうやらov7760用のサンプルプログラムの一部だけを「チョロっと」パッチしたものをサンプルプログラムとして出していたようです。あまりなので、ファイル名くらいは直しておいて欲しいと要望を出しておいたところ、現在サンプルはダウンロードできなくなっているようです。

aitendoのサンプルではRGB 5:6:5のQVGA出力に初期化しているようなので、これをRGB 5:6:5の VGA出力に変更し、AT91SAM9260のISIを使って取り込み、QVGAに縮小して表示したのが↓です。



LCDが変更されていることもあって、昨年の実験よりも明るい表示が得られています。センサの前にはでかいレンズ筒がついていますが、ズームができるわけではありません。ユーザ側で焦点を合わせることができるのですが、レンズ自体は固定焦点のようなので、適切に調整しないとボケた画像しかでないが、一度調節すれば以後は変更する必要はなさそうです。結局、このでかい筒は邪魔なだけという感じもします。

OV9655とOV9650の細かい違いは、もっと使ってみなければわからないのですが、ハードを組む上での大きな違いは電源でした。OV9650では 1.8V, 2.5V, 3.3Vの3電源が必要でしたが、OV9655では1.8Vのレギュレータを内蔵しているので、3.3Vと2.5Vの2電源でも動作できるようです。内蔵レギュレータを使用せず1.8Vを供給することも可能となっています。aitendoのモジュールでは2.5Vレギュレータを搭載しているので、3.3Vを与えるだけで動作してくれ、その意味では使いやすかったです。

カメラボードの作り直し

先週から、CMOSカメラボードを新たに作りなおしています。まだ途中ですが、とりあえずカメラまでつなげてあります。



昨年製作したボードは、MMnet1002を使っていましたが、ボードに各種コネクタが載っていることもあり重いうえに電源としてACアダプタが必要なので、カメラとして使うのにACコンセントが必要という不便さを抱えていました。そこで、今回は死蔵してあったMMnet1001を使うことにしました。このボード、MMnet1002とほぼ同じ回路でコネクタが少ないだけなので、コネクタにも同じ信号が出ています。そのため、同じ回路構成で同じソフトウェアが使えます。

LCDは2.8インチのものです。昨年のボードでは3.2インチを使っていましたが、MP3プレーヤと兼用していました。ボードを使い分ける度に差し替えるのも面倒なので、しばらく前に買い置きしてあった2.8インチを使うことにしました。



裏側にはaitendoで購入したOV9655を積んでいます。先月からのセールで安くなってきたので購入しちゃいました。ほんとはわたしもJPEG圧縮できるカメラとか使いたいのですが、QFNとかは大変なので、2.54mmのコネクタ持っているという点に魅かれた次第です。



なんとかカメラからの画像をLCDに表示できるところまできましたが、それに関しては次回の記事にて。

Bluegiga - AVRCPの動きを確認する

A2DPでの再生までできたので、今度はAVRCPの動きを見てみることに。AVRCPには操作をおこなうcontroller側と、操作の対象となるtarget側がありますが、MP3プレーヤはtarget側となるので、そのプロファイルの設定を追加してリセットをかけます。



ヘッドフォンのジョグ・スイッチのPlay/Pauseボタンを押すと、ヘッドフォン側から接続が起動されるため、まずRINGのイベントが表示されます。ジョグ・スイッチの操作に応じてPRESS, RELEASEのイベントが通知されることが確認できました。

このようにヘッドセットの操作に応じて、対応するイベントをUARTで受信できることは確認できましたが、実際にこれを使ってMP3プレーヤを操作するためには、そのソフトを書かねばなりません。ここまで全くソフトに手を加えずにBluegigaの機能確認を進めてきましたが、こればかりはソフトの作業が必要ですので、そろそろ手をつけようかと思います。

技術基準適合証明と表面実装

ここのところしばらくBluegiga　WT32を使ってみて、かなり気に入りました。先月リリースされたばかりのiWRAP 4.0.0によって、これまではツールをつかってあらかじめ設定が必要だった項目が iWRAPのコマンドによって動的に変更可能になった箇所がいくつもあり、ずいぶんと使い勝手が良くなっている印象を受けます。機能的には、まだPCMの部分とかの動作確認をとらなければなりませんが、I2Sやアナログで簡単に音声インタフェースをとって、Bluetoothで飛ばせるのという点ではとても便利で使えるモジュールだと思います。

このBluegiga WT32ですが、実際に人前で堂々と使うには、ひとつ問題が残されています。それが、技術基準適合証明です。2.4GHzを使用する無線機器として技適がとれていないと、電波法違反になってしまいます。国内に代理店があるので、問い合わせてみましたが、Bluegigaや代理店としては技適を取得していないとのこと。すなわち実際にWT32を使用した機器を製造する立場の者が、個々に技適を取得する必要があります。もちろん、わたしのような個人の立場ではできるわけありませんので、人前でオオッピラに電波飛ばすことはできません。

問い合わせた代理店が言うには、WT32は表面実装のモジュールであるので、単体では技適は取れない(と、TELECに言われた)とのことでした。どうやら、XBeeのようにコネクタがついていればよろしいらしい。そんなものなのかなぁとちょっと疑問を感じたので、その理由を考えてみました。技術基準適合証明を受ける際には、技術基準を満たしていることを示すための特性試験結果を提出するか、あるいは特性試験を依頼することができるようです。特性試験を依頼する場合には、当然ながら対象となる無線設備を提出する必要が生じます。XBeeのようにコネクタがあれば、試験機本体(マザーボード)を1枚とXBee基板を必要枚数提出することで試験を受けることができるでしょうが、表面実装モジュールの場合には、モジュールのハンダづけを頼むわけにもいかないでダメということでしょうか。

ブレークアウトボードの形態であれば、XBeeのように取得可能なのでしょう。どこかが証明取ってくれないかぁな。それでは、Bluegigaが特性試験結果を提出すれば、表面実装モジュールの形態でも証明/認証をとれるもんなんでしょうか？もちろん、基板実装時に特性に影響を与えることがないということを示す必要があるのでしょうけど。

　

Bluegiga - アナログ入力を試してみる

MP3再生はBluetoothで飛ばすことができるようになりましたが、FM放送はまだできていません。FMチューナの出力はCODECにつながっているものの、CODEC内の折り返し機能を使ってヘッドフォンアンプに出力しているため、LPC2388にはチューナからの音声データが入ってきていません。



FM放送をUSBスピーカで再生する時と同じように、いったんFMチューナの出力をCODECで受けてI2Sで受信し、それをふたたびCODECに出力してやれば、FM放送もBluetoothで飛ばすことはできます。しかし、ソフトを変更するのも面倒なので、今回はFMチューナからの出力をBluegigaのアナログ入力端子につなげてみることにしました。

Bluegigaは音声入力として、アナログ入力、I2S入力、PCM入力のいずれかを設定で選択できます。そこで、

   set control audio internal internal

というコマンドを1行入れて入力を切り替えてみました。

チューナ出力を直接Bluegigaにつないでしまうと、音が歪んでしまったので、手持ちの100KΩをかましたところ、いい具合になったようです。MP3を聞く時はI2Sを選択し、FM放送を聞く時はアナログ入力を選択すれば、どちらもBluetoothで飛ばすことができることが確認できました。ただし、実際には次のような問題があるので使い勝手は良くありません。

• プレーヤのソフトは何も変更していないので、プレーヤの操作に連動してBluegigaの設定が変更できるわけではない。Bluegigaの設定を手動で切り替えている。
• オーディオ入力源を変更するには、いったんBluegigaをリセットしないといけない。そのため、再度A2DPの接続を張り直す操作が必要となってしまう。

ソフトを変更したとしても、FMとMP3を切り替える度にA2DPを張り直すのは、どうも使い勝手悪そうです。

Bluegiga - A2DPでMP3再生

ペアリングまではできたので、いよいよA2DPでMP3プレーヤで再生した音声をヘッドフォンに飛ばして聞いてみます。

ディフォルトでは音声パスはアナログの入出力に廻るようになっているので、これをI2Sに向けます。I2Sは master/slaveのどちらにもなれるのですが、MP3プレーヤではボード上のCODECがマスターになっているので、WT32はスレーブに設定。そして、ステレオのモードに設定しておきます。

A2DPにはオーディオを送出するsource側と受け手となるsink側がありますが、MP3プレーヤはもちろんsource側です。A2DPのプロファイルを許可して、いったんリセットをかけます。どうやら、プロファイル設定を変更したら、いったんリセットをかけないと有効にならないようです。



リセット後、callコマンドでヘッドフォンに接続をかけてやります。"A2DP STREAMING START"のイベント表示とともに、耳元から音楽が流れ始めました。LISTコマンドで接続状況の確認、CLOSEコマンドでリンクの切断がおこなえます。

ここまで、MP3プレーヤ側のソフトウェアには一切手を加えていません。LPC2388がI2SでCODECに送出した音声データをWT32でも受けて、WT32が設定に基づいてA2DPで飛ばしてくれています。SETコマンドで設定した内容は、電源を切っても覚えていてくれますが、このままではヘッドフォンへの接続のためにCALLコマンドの入力が必要です。

この課題に対する対処としては、AUTOCALLというWT32側から自動的に継続して接続を試みてくれるという機能も用意されているのですが、MP3プレーヤ側から接続を起動しなくても、ヘッドフォン側から接続をかければいいことに気が付きました。DR-BT140QPでは、ジョグダイアルのボタンを押すことでA2DPの接続を開始することができます。この時、WT32側では↓のようにRINGイベントが表示されます。



やはり、ひも無しは快適ですね。このようにWT32は一度設定させしてしまえば、マイコン側から何も制御しなくてもA2DPを飛ばすことができることが確認できました。今回はI2Sを使っていますが、A/DやD/Aも内蔵しているのでアナログでの入出力も可能です。

Bluegiga - ペアリングする

Bluegigaは、ATモデムにようにコマンドを打つことにより、設定を変更したり機能の操作をしたりします。設定変更はSETコマンドでおこないますが、このコマンドは、ディフォルトではエラーがなければコマンドに対するレスポンスはありません。またBluetoothでの接続が確立されたり、切断されたりといったイベントが生じた場合には、それが表示されませす。

以下、シリアルで投入するコマンドは全て小文字で入力/表示されています。大文字の行がBluegigaからの出力です。

SETコマンドを引数無しで投入すると、現在の設定が表示されます。初期設定はこんな感じ。



デバイスアドレスは、イーサネットと同じでIEEEからOUIの割り当てをもらっているので、このページで00-07-80を検索してみたら、ちゃんとBluegiga Technologyになっていました。

ヘッドフォンと接続するためには、相手を見つけてペアリングしなければなりません。そこで、まずはinquiryでサーチをおこまいます(引数はタイムアウト時間)。最初のinquiryでは何も表示されていませんが、これはヘッドフォン側をペアリングする状態に置いていない場合の出力です。ヘッドフォン側の準備を整え、再度inquiryするとヘッドフォンのデバイスアドレスが表示されます。



ヘッドフォンのデバイスアドレスがわかったところで、そのアドレスに対してcallコマンドを使ってA2DPの接続を張りにいきます。callの前のSETコマンドでは、ペアリングの際のパスコードを指定しています。↑の実行例では接続できたかと思いきや、すぐに切断されてしまった様子を示しています。失敗するのは、WT32側でA2DPのプロファイルの設定等ができていないからなのですが、その設定についてはまた次回。

ここまで動かしたところで、SETコマンドで設定状況を確認してみると。。



ペアリングできたヘッドフォンのアドレス設定に対応するSETコマンドが新たに追加されています。電源を入れ直しても設定を覚えていてくれるので、ペアリングし直す必要はありません。