ようやく発表

ようやくと、ATMELがSAM3XとSAM3Aを発表しました。これまで、SAM-BAに含まれるヘッダファイル等からおおよそどのようなデバイスであるかは想像がついていましたが、これで詳細を確認することができます。SAM3XとSAM3Aはデータシートも共通となっているようです。

新デバイスと同時に発表されたのがATMEL Studio 6. これまでのAVR Studio 5にARMのサポートが加わったのに伴って、名称も変更されたようです。各社IDEを無料で提供してくれるのはいいのですが、チップ毎に異なるIDEをインストールしなきゃならないのは、正直勘弁して欲しいというのが私の感想。わたしの場合、お金払ってもいいので同じ環境にで暮らし続けたいですね。

久しぶりにPBAPを試す

先週記事にしたようにiWRAP 5.0のβが始まったので、わたしもアップデートしてみました。まずは、infoの出力から。



βであることの警告が目を引きますが、内容を見るといつのまにやらBluetooth version が 3.0になっています。ファームのアップデートに際しては、注意することがひとつできました。機能の追加によりファームのサイズが大きくなったために、WT32では用途に応じて２種類のファームが用意されるようになりました。具体的には音声を受ける側(HFP unit, A2DP sink)のデバイスを作るのか、あるいは音声を送る側(HFP Audio Gateway, A2DP source)のデバイスを作るのかに応じて、適切な方のファームウェアイメージを選択する必要があります。

iWRAP 5.0ではApple のiAPや、HDPをサポートする機能が標準ファームウェアの一部として提供されるようになったために、ファームウェアサイズの増大を招き、このような解決策をとるにいたったようです。ちなみにiAPの方は、AppleのMFiプログラムに参加してライセンスを受けているユーザにしか利用することはできません。参加費用を払って技術資料を入手したうえで、さらにiAPを使う際に必要となる認証用のチップをAppleから購入して、製造販売する製品に組み込む必要があるようです。このチップはI2Cでつなぐらしいのですが、WT32ではGPIOピンのうちの２つの端子がI2C端子として機能することで、このチップを接続することができます。WCA-009ではGPIO端子も全て使用可能となっていますので、iAP対応デバイスの開発試験に使用することも可能なわけですが、個人では手の出しようがありません。

一方のHDPは体重計、血圧計、脈拍計といった機器を接続するためのプロファイルですが、対応する計器を持っていないので試してみることができません。以前、タニタがBluetooth対応の体重計を出しているとのことで確認してみましたが、SPPでした。ひょっとしたら、健康診断のような業務用用途には対応機器が売られているのでしょうか？個人用に安価に買えるものがあれば、実験してみたいものです。

こんなわけで、iWRAP 5.0で強化された機能を試す機会はなかなか訪れないのですが、久しぶりにAndroid端末を使ってみる機会があったので、久しぶりにPBAPの動作を確認してみました。以前調べた時にはマニュアルの説明と動作が違うと理解していたのですが、それはマニュアルの表記がわかりにくかったために、内容を誤って解釈していたためでした。わたしの質問を受けて、iWRAP 5.0のマニュアルでは、PBAPコマンド部分の説明の一部が修正されたようです。

さて、今回つないでみたのは Android 2.3.4搭載のF12C. わたしの電話番号を連絡先に登録しておいて、着信を受けた後で、PBAPで着信履歴を調べてみました。



PBAPコマンドの最初の引数 01 で電話機内の着信履歴にアクセスすることを指示。つづく 1 0のふたつの引数で履歴先頭からひとつ読み出しを指定。最後の 0 1では、全ての内容をVcard 3.0形式で出力のハズだったのですが、どういうわけか 2.1形式で返答が返ってきました。単純に電話帳をダンプする場合には、Vcard 3.0で出力できるので、端末側が対応できていないのでしょうか？
FNならびにN属性は名前を表しているのですが、QUOTEされた16進表示になってしまっているので読みにくくなっていますが、デコードすれば "506 sirius"となっています。この部分も Vcard 3.0で返してくれれば、UTF8で読み出せるハズなのですが。。。

いいかげんに自分でスマホ買えばいいようなもんですが、こういう結果を見るにつけ事前の確認をとっておきたくなります。HFP 1.6を試すうえでも、Android 4.0が必要ですしね。

在庫限りとなるのか

昨年、アンプのノイズで頓挫してからというものの、W-SIMジャケットの製作は停滞を続けています。アンプはMC34119に変更したところだったのですが、いつの間にか秋月ではMC34119の取り扱いが無くなっています。古いデバイスでしたから、どうやら在庫が掃けたのにともない、取り扱いも無くなってしまったようです。違うものに置き換えを考えた方が良さそうです。

こんな事情もあって、W-SIMジャケットの製作意欲を失っていたのですが、今週はさらに追い討ちをかける情報を耳にしました。W-SIMのコネクタはALPSの製品で、わたしはMouserから購入しています。入手した情報によると、ALPSが製品カタログからW-SIMソケットを削除したとのことでした。確認してみると、同社の製品情報で検索してもたしかにW-SIMソケットを見つけることができません。Mouserを確認してみると、まだ在庫が残ってはいるようですが、ALPSにリンクを張っていたデータシートは、リンク切れになってしまっています。

こういう状況では、Mouserの在庫が無くなれば、個人でW-SIMソケットを入手する手だてが失われることになりそうです。最後のチャンスになるかもしれないので、次の機会に数個買いだめしておこうかと考えています。

iWRAP 5.0 β始まる

iWRAP 5.0のβが先週からダウンロード可能になっていたようです。何のアナウンスもないので、先ほどTech Forumを覗いてみて初めて気がつきました。当初の予定では12月中にβ開始と聞いていたので、２ヶ月遅れくらいでしょうか。そうすると正式リリースは夏近くになるかもしれません。

HIDの機能強化とHFP 1.6対応が目玉というところでしょうか。HIDはレポートディスクリプタを設定してやらねばならないようで、ちょっと使い方が難しそう。HFP 1.6は通話音質向上をもたらす機能ですが、対応端末をもっていないことには意味がありません。Androidだと 4.0 ICSがHFP 1.6対応のようですから、そのうちには動作確認実験する機会が巡ってくるかもしれません。まだマニュルに目を通しているだけですが、そのうちにファームも上げて使い始めようかと思います。

レイアウト決め

トラ技の頒布カメラが一時的に品切れ状態になっているようです。通常価格より1,000円安いというのは、値打ち感はありますので、ついついポチリたくなりますね。



わたしもFIFO付きカメラを使うことも考えたのですが、コネクタの向きと大きさが気に入らなかったので、FPCコネクタのカメラと変換基板を使うことにしました。もともとこの変換基板にはコネクタが２箇所についていましたが、じゃまなので片方は取り外してしまいました。変換基板で面積を喰っているうえにEye-FiのためにマイクロSDではなくてSDカードを使う必要があるので、部品点数は少ないわりに基板が埋まってしまった印象を受けます。裏面は、まだ配線作業中ですが、いちおうLCDを載せられるようにしておきます。

3.0V対応

トラ技に書いた記事にさっそく大きなミスを発見。使用したカメラは定格動作電圧は3.0Vなのに、3.3Vを加える回路図になっていました。当初3.3V動作が可能なOV7725を使って実験を始めていたので、OV7670もおそらく3.3V加えても壊れるないことはないどろうと見込んで、使っていたような次第です。実際のところ何の問題もなく使い続けていたのですが、3.0Vに修正しないでそのままの回路図を出してしまいました。

もちろん、3.3Vで使うのは好ましくないので3.0V動作に修正すべきです。修正方法はあらかじめわかっていたのですが、後回しになっていました。全体の動作電圧である3.3VはSAM3-H256ボード上のレギュレータによって生成されているので、ここで3.0Vを生成するように改造を加えれば、全体が3.0V動作となり問題は解決です。都合の良いことにレギュレータとしては出力電圧可変型のLM1117-ADJが使われているので、出力電圧を決定する抵抗２本のうちの片方を変更してやるだけで、3.0Vへの変更が行えます。具体的には、USBコネクタのそばに実装されている240Ωの抵抗(R1)を270Ωに変更するだけです。



カメラの動作電圧は2.5Vからとなっていますが、3V未満になるとSAM3SではUSBが動かなくなる可能性があるので、やはり3Vで使うのが好ましいでしょう。

OV7670を使ったナンバー認識

本日発売のトランジスタ技術３月号に記事を書かせていただきました。主なネタとしては２点ありまして、ひとつは本ブログでも紹介した、OV7670を使ったバーコード・リーダです。OlimexのSAM3-H256とCMOSカメラ、LCDの３点を直結しただけの簡単ハードウェアなので、極端なはなし回路図なんかなくてもいいくらいですが、もちろん紙面には回路図載っています。こちらは、MTM07でもデモしましたが、それから少しソフトを改善してあります。USB電源で動かしていますが、「読み取り結果はPC側には送信されないのか？」というツッコミを頂戴したので、その機能も用意しました。(MTM07の時も結果表示は可能だったのですが、デバッグメッセージも一杯出していました。)

そしてもう一点は、車のナンバーの数字を読み取るナンバー認識です。こちらもバーコード・リーダと同一のハードウェアを使っており、ソフトを書き換えるだけです。初歩的な画像処理を施して数字認識を試みました。



実際にやっていることはとっても簡単な画像処理だけです。連続した画素から構成される部分領域を切り出して、それを数字の辞書ビットマップと単純に比較しているだけです。そのため、正面から撮った傾きの無い画像でないと正しく認識できません。近頃は、学部学生の実験でも、この程度の画像処理の課題があるようです。上の動画もMTM07の頃に作成したものなので、その後 処理時間を短縮したり、Setup機能を追加して解像度選択もできるようになっています。詳しく知りたい方は、トラ技を参照願います。こちらもUSB電源で動作させていますが、PCからは電源をもらっているだけであり、全ての画像処理はマイコン単体でおこなっています。当初、CrossWorksを使ってソフト作りましたが、マイナーなツールはダメだということで、Keilに書き換えました。同時に、コードを整理してデバックや試験用のコードを削ったところ、32KBから35KBくらい使っていたフラッシュ容量が26.54KBに減ってしまいました。Keilの期限無し評価版は32KBまで使えるので、まだ機能追加/性能改善可能です。

個人的にはSAM3Sを普及させるべく、もう少しSAM3Sの特徴的機能について説明したかったのですが、ページ数の関係もありそれはかないませんでした。同じようにカメラ直結できるSTM32 144pin の方が受けはいいんだろうなぁ。

	トランジスタ技術 (Transistor Gijutsu) 2012年 03月号 [雑誌]
	CQ出版
	CQ出版

AL422B FIFO

今度はカメラからの画像をSDカード(Eye-fi)に保存することにしましたが、SAM3S4Bでこれを処理するにはいくつかの問題があります。

1. SAM3S4Bの内蔵メモリは48KBしかないので、この容量ではVGAどころかQVGAの画像データも保持できない。JPEG圧縮のためにメモリを使うと、QQVGAすら保持できない。SAM3S4Cを使えば、外部メモリを接続できるが、100pinとなり配線作業が大変。
2. SAM3S4Bでも、画像データを何回かに分けてカメラから受けて、順次JPEGに変換してカードに書き込むという方法がなくもない。しかし、何フレームにも分けて画像を取得することになるので、対象物が静止していないと、画像がブレることになってしまう。
3. CMOSカメラ接続に使うパラレルキャプチャ機能に割り当てられた端子と、SDカード接続に使うHSMCIに割り当てられら端子が重複しているので、これらの機能を同時に使うことができない。順番に使うにしても、バス切り替えが必要になってしまう。

そこで今回は、OV7670から出力された画像データをいったんFIFOに蓄えることにしました。使うのはAL422BというFIFOで、この商品のようにFIFO付きのカメラが売られていることをきっかけに知りました。秋月の新しいSOP 28P変換基板を使ってハンダ付け。パスコン用のパターンがあるけど、VCC/GNDのピン配置が合わないので使えずとなりました。



このFIFOの容量は384KB. 書き込みと読み出しのデータが独立していますから、カメラからのPCLKで書き込んでおいたデータを、あとからゆっくりとマイコンで読み出すことができます。マイコンではカメラからのPCLKの速度を全く考えなくていいので、8ビットのマイコンでもカメラつなぐことができます。このFIFOを使えば、もはやパラレルキャプチャは必要無いので、HSMCIとの端子重複の問題も解決。FIFOからの読み出しは、GPIOを使って行うことにします。

Eye-Fi

引き続いてOV7670のカメラを作ろうと思っているのですが、今度は撮影した画像を保存しようと思っています。ただ保存するだけでは面白くないので、定期的に自動撮影した画像をPicasaやFrickrにアップロードできる定点観測カメラに仕立てることをもくろんでいます。SAM3SにはEthernetはないので、ネットワーク接続にはEye-Fiを利用してやろうと考えConnect X2を購入。



購入したはいいのですが、このカードって技術情報が何も開示されていないんですね。「いつのまにか転送してくれる」のは普通の人には便利なのかもしれませんが、こちらとしては転送中かどうかを判断する方法が知りたいところ。世の中にはEye-fi対応を謳うカメラもあり、転送中は電源を落とさないらしい。したがって、転送中かどうかを調べる手順があるはず。マイコンで制御する場合にも、できれば転送終了を待ってパワーダウンモードに入るとか、SDカードへの給電を停止するとかしたい。

マイコンに接続する場合の方法については、SPIモードが使えるかどうかも気になるところですが、検索したところエレキジャックの記事が見つかりました。何回かの連載の内容がこの本にまとめられていたので、立ち読みしてみるとSPIモードでも書き込めるようです。やろうとしていることは、この記事と同じようなことですが、よりシンプルなハードで安価に作れるかな。SAM3SはHSMCIというSDカードインタフェースを持っているので、考え直してSPIを使ってのSDカード接続は取り下げ。この機会にHSMCIを使ってみようと思います。

転送できるファイルはJPEGあるいはRAWならびにいくつかの動画形式に限定されているようなので、BMP形式ではアップロードできないことになります。そこでOV7670で撮影したデータもJPEGにしてやる必要があります。libjpegを使えばできることはわかっているので、変換してSDカードに書き込んでやれば、自動的にアップロードできるはず。転送がおわった写真ファイルを自動的に削除してくれる「エンドレス・モード」という機能もあるので、自動で写真を撮り続けてもSDカードがいっぱいになる心配をしなくてもすみます。しかし、この機能もどういうタイミングでファイル消すのか不明なので、ちょっと不安なところです。自分だったらこの機能をどうやって実現するかを考えてみましたが、やはりカードの初期化手順の中で処理してしまうのがいいかな。CMD0とか CMD1のようなカード初期化時に実行されるコマンドを処理するついでにファイル消去すれば、それ以降の読み書き処理に影響を与えずに済みます。OV7670はVGA解像度しかないので、これをJPEGにしてしまえば100KBも使わないはずです。4GBもあれば、当分は困ることもないのですけどね。