マイクが動かない

なんとか基板に全部品のハンダ付けを完了。動き始めています。



新たに取り付けたスピーカは表面実装用のものであり、本来であれば表側というか外側に配置すべきものです。しかし、そうするとLCDの横に配置することになってしまい、横幅が必要になります。LCDの位置を中央からずらせば配置できないこともないのですが、そうすると全体なバランスが悪そうです。そこで、表側には穴だけ開けて、スピーカは裏側に取り付けることにしています。リード線を使って、無理矢理配線。加工中のケースに入れていたので、基板が粉だらけになっています。



前回失敗したQFNのCODECは、今回はちゃんと動いてくれているようです。しかし、当初から心配していたデジタル・マイクが動いてくれません。このマイク、最初の試作ではDIPのモジュールを使っていたのですが、大きさのこともあり、基板には半田づけすることにしました。ところがこのマイクは端子パットが完全にチップの裏に配置されており、横側にも出ていません。これをなんとか手ハンダしようと考え、基板上にではパッドの位置にピン穴を開けておき、裏側からハンダを流し込むことで配線しようという作戦をたてました。どうにか固定はできたのですが、ちゃんとハンダ付けできているのかどうか目視確認できないので、動かしてみるしかありません。ところが、わたしの願いは聞き入れられず、動いてくれません。



何度かコテを当て直し、ハンダを流し込み直してみたりしたのですが、やっぱり動かない。最初はまったく何も音が拾えていなかったのが、基板をたたいたり、大きな声で話すとひどく割れた音が時たま拾えるようになったのですが、もっとフツーに音が拾えていいはず。やはり接触不良があるのか、はたまた内部でショートしている箇所があるのか、それともコテを何度もあてているうちにイカレてしまったのかもしれません。

急いでもう１枚基板に部品を実装したいところなのですが、ちょうど手持ちのCODECが無くなりました。もう残りが無いことには気づいていたので、先週のうちにMouserに追加注文を入れておいたのですが、ちっとも出荷されません。運悪くUSはThanks Givingの休暇に入っていたのです。ようやく昨日出荷されたようですが、到着は12/1 の予定。残念ですが、MTM07ではマイクが動かない状態でのデモになってしまいます。

再挑戦

夏に作成した基板はいくつもミスを犯してかなりメゲましたが、再挑戦です。あいかわらずルーティングは auto router頼りで、何の進歩もありません。





前回は本体とLCD部分との２枚構成でしたが、今度は１枚の基板に収めました。２枚構成だと高さが高くなってしまい、あまりにもみっともない姿になっていました。実際にコードを書いてみて不便だと感じたスイッチ用のポート割り当てを変更したり、CODECのライン出力にアンプとスピーカをつなげられるようにもしてみました。ヘッドフォンとスピーカの両方で鳴らしたり、選択したりをできるようになるのですが、オーディオジャックの挿入検知をするための端子が足りなくなってしまったので、端子挿入による切り替え機能がサポートされないというトホホな仕様になってしまいました。

MTM07まで残り１週間になってしまいましたが、なんとか間に合わせたいと思います。これまでのコードは、スイッチ部を変更する程度の修正で使えるはずですが、新たに追加したスピーカを鳴らすための機能追加まで手が廻るかどうかが怪しいところです。そして最後の問題はケースですね。いちおう秋月のこのケースを想定した基板になっているのですが、加工が間に合うかどうか。。

OV7670を使ったバーコード・リーダー

SPI LCDやSAM3Sボードを準備していたのは、新たなCMOSカメラボードを製作をするためです。今回は、入手が容易で製作も簡単にできることを目指したので、ボードはOlimexのヘッダボードSAM3-H256を使うことにしたのです。そして、CMOSカメラも安価なOV7670を使うことにしました。



このカメラは日昇テクノロジーで扱っているもの。aitendoにも良く似た製品があるのですが、両者はピン配置が異なっているという罠が潜んでいます。同じピン数で、同じような色してるんですけどね。

いつものように簡易データシートだけではOmnivisionのカメラの具体的な使い方は、よくわかりません。カメラと一緒に提供されているサンプルコードなんかより、Linuxのドライバの方がコメントが充実しているだけわかり易い印象を受けますが、やはりなんらかのサンプルを参考にしているだけで詳しい意味がわかっているわけではないようで、「魔法の呪文」を示す magicという言葉が散見されます。

カメラの設定さえなんとかなれば、画像の取得はSAM3Sのパラレルキャプチャ機能を使うことで、とっても簡単にできちゃいます。何しろDMAで画像データをメモリ内に取り込んでくれるので、その内容をLCDに転送するだけでも取得画像の確認をすることができます。これまでは、取得した画像をそのままLCDに表示するとか、JPEGに変換してSDカードに保存してみるくらいのことしかやってこなかったのですが、今回は少し画像処理的要素をもつアプリに挑戦してみました。



いまじゃ携帯電話にもフツーに備わっている、CMOSカメラを用いたバーコード読み取りです。何しろRAMが48KBしかないので、２次元バーコードであるQRコードの読み取りは難しそうですが、１次元ならなんとかなるだろうと思いやってみました。バーコードにもいろいろな種類があるようですが、日常生活で一番良く目にするであろう13桁のJANコードだけを対象と想定して、読み取り処理を実装しています。結構、気持ちよく動いてくれます。実用上の一番の問題はカメラのピント合わせではないでしょうか。このCMOSカメラ、レンズ筒があって立派そうに見えますが、実用上は筒を廻してちゃんとピントを合わせないとまっとうな像を結びません。読み取り操作時にはバーコードとの距離を調節するために、だんだんと近づけたり/離したりするのがうまく読み取るためのコツです。バーコードにも何種類かのサイズがあるようですが、大きなものと小さなものではピント合わせをやり直さないといけません。

兄弟ボード

これまでaitendoのAT91SAM7S用ボードにSAM3Sを載せて使っていましたが、こんどはOlimexのSAM3SヘッダーボードSAM3-H256を買ってみました。MouserがOlimexのボードを扱ってくれるようになったので、気軽に買えるようになりました。おまけに円高/ユーロ安のおかげて2,500円もしません。






もともとSAM3SはSAM7Sシリーズとのピン互換性が考慮されているマイコンです。そのため、このヘッダーボードもSAM7Sを使ったSAM7S-H256とピン配列が同じになっています。⬇の写真では、左側がSAM7-H256, 右側がSAM3S-256です。




しかしながら、SAM3Sでは従来フラッシュ用電源やPLL用RCの接続に使われていたピンが、あらたにDACの出力に使えるようになっています。これらのピンはSAM7Sボードではコネクタに出ていなかったので、そのコネクタと同じ配列のSAM3Sボードでも出ていないことになります。これらの信号はJTAGコネクタの下部に見える４つのパッドから引き出せるようになっていました。

チャイナ・リスク

これまでに何枚も購入、使用してきたSPI接続のLCD T1800 。（かなりの誇張表現。ほんとは５、６枚購入して、３、４枚くらい使用。）今回は、対応キャリーボードを使ってみることにしました。この液晶のフレキ端子ピッチは0.8mmなので、0.8mmピッチのSOPの変換基板があれば、それを流用してユニバーサル基板に載せることができるのですが、あいにくと手持ちが無くなったのでこの基板を使ってみることにしました。



さて、基板にLCDをつなげて、基板のシルクを見ながら電源ラインをつないでいたところでハタと気付きました。「あれ？VCCは左の方にあったはず！」LCDのデータシートを確認してみると、やはりそうです。この基板のピン番号と端子名シルクはLCD実物とは逆順についているのです。では、aitendoから引用した画像で確認してみましょう。

まずはLCDのT18003T01です。よく見ると端子の右側が１番で、左側に14番を示す数字が読み取れます。



そして基板側です。2箇所とも左が１番になっています。
おーい、これで「対応キャリーボード」とか言わんでくれ～。> aitendo



端子名のシルクも番号と同じように逆順になっているので、このとおりに配線しても動きません。もっとも、基板を作り間違えてしまった気持ちもわからないではありません。「左側が１番なのが、フツーだろ!!」と、LCDに向かってツッコミたくなります。実際のところ、わたしも何度か同じ過ちを犯しています。前回は、基板を作った際にやらかしてしまいました。今回は、こうした経験が生きて、基板がおかしいことに気づくことができたようなもんです。

こうして、シルクの罠を見破って無事に配線終了。いつものLCD表示コードを動かしてみたのですが。。。。表示できません。LCDの初期化ができないようです。配線間違いも、接触不良も無いことを再度確認。そうすると、残る可能性として思い当たる節がひとつあります。それが、コントローラのST7735とST7735Rの違い。ねむいさんのブログ記事にも書かれていますが、このT1800というSPI LCD、外見も型番も同じでも、実際に使用しているコントローラが、ST7735のものと、ST7735Rのものの２種類があるというのです。しかも、初期化のコードに違いがあるという困った製品です。これまでわたしが使ってきたT1800はすべてST7735でした。ひょっとして、今回のものはコントローラがST7735Rになっているのかもしれません。

ねむいさんの記事によれば、タブの色で使用しているコントローラの区別がつくとのことでしたが。。。そういえば、わたしが今回購入したLCDには保護シートがはってないじゃないですか!!　ムクムクと「これって、ホントに新品??」という疑惑が沸き起こります。

ともかくも、初期化部分のコードをST7735Rのサンプルコードを探して、入れ替え。無事に表示できました!!　ねむいさんの記事と、この記事のことを教えていただいたmediwareさんに感謝です。

このLCDを使って製作しているものについては、またいずれ。

逃げ手をうつ

「大きすぎるハム音」でつまずいていたSAM3ジャケット。アナログ部分に別のレギュレータを入れてみたりもしたのですが問題を解決できませんでした。W-SIMからノイズを拾っているのは確かなのですが、どうすればいいのかわからないので断念して、別のチップ使ってみることにしました。




追加したのはやはり秋月で買ったMC34119です。結果として、まだハム音がするものの、以前とは比べ物にならないくらい音が小さくなりました。これならまぁ我慢できるので、HT82V739の方はあきらめることにします。気がついたのですが、チップとして秋月で売られているHT82V739は、DIPパッケージなんですね。試作には便利そうですが、基板に載せるとなると場所取りなので、この点からも小さいMC34119の方が良さそうです。

初期化忘れ

前回の記事では、USBコネクタをつながないとBluetooth接続ができないという問題に気がつきましたが、実際に問題を調査してみるとあっさりと原因が判明しました。

Bluetooth接続ができないことは、WT32から接続メッセージが出力されてこないことからも確認できていたのですが、調べてみると受信割り込みがまったく発生していないことが判明。テスタで確認すると、そもそもWT32のVREGENA端子がアクティブになっていませんでした。VREGENAはWT32内部のレギュレータのイネーブル端子であり、これをアクティブにしないとWT32のデジタル部が動作しませんので、Bluetooth接続できなかったのも当然のことです。

VREGENAはSAM3SのPB5端子で制御していたのですが、原因はこの端子の初期化忘れでした。PB5は初期状態ではJTAGのTDO端子として動作しているため、PIOを操作したつもりでも実際には機能していなかったのです。PB4端子は、USBでホストと接続されたことを検出しようと思いUSBコネクタのVBUS検出に利用するつもりで配線してあります。同じようにこの端子も初期状態ではJTAGのTDI端子に割り当てられており、GPIO入力としては機能しません。USBでつないだ状態ではTDIがHとなりますが、それに影響されてTDOがHとなった結果VREGENAがアクティブになっていたようです。

SDWを使うことで必要の無くなったTDI/TDOをPIOとして使ったつもりだったのですが、その設定がちゃんとできていなかったわけです。この設定変更を追加して、ようやくとUSBケーブル無しでBluetoothも動作するようになりました。




ダイアル・ボタンのドライバも作成したので、ダイアルを廻すことで音量調節できますし、方向キーを左右に押すことで曲送りや、戻しもできます。かなり自分が妄想していたイメージに近づいてきた感じです。

何かがWT32の動作を妨げている

HFPを使っての時刻取得を実装すべく、必要なコードを追加。iPod Touch側から時刻を取得して、BlueSAMのRTCを設定するようにしたつもりだったのですが。。。




上の写真のようにUSBケーブルをつなげて動作させるとちゃんと動いて時刻の取得/設定もできたのですが、USBケーブルをはずしてしまうとiPodとWT32とのBluetooth接続ができないことが判明。何かしらがWT32の動作をブロックしてしまっているようです。これまで、電池の充電やデバック目的でいつもUSBケーブルをつないでいたので気がつきませんでした。うーん、何がいけないんだろう。タスク間でのイベントの待ち合わせに関連したバグがあるのでしょうか。じっくりと見直しが必要なようです。

HFPを使っての時刻取得

先日、iPadをiOS5にしてAVRCP 1.3に対応できたことに気分を良くしたので、iPod Touchを買ってみました。新色ホワイトです。




iPadとiPod TouchのどちらでもiOS5が使えますし、同じようなアプリが使えるわけですからBluetoothプロファイルも同じようなものがサポートされるのですが、我が家のiPadは初代のもの。そのため、ハード的にもアプリ的にも細かい違いがあり、それがBluetoothサポートの仕様にも反映されます。具体的にはHFPのサポートが大きな違い。現在のiPad/iPod Touchにはカメラがついており、FaceTimeが使えます。そのため、これをBluetooth経由で利用する便を図るためにHFPがサポートされているのです。きょうはトラ技９月号で紹介したWCA-009実験ボードを使って接続確認してみました。

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

iPod Touch側からデバイスを選択して接続すると、次のように３つのリンクが張られました。FaceTimeを立ち上げていなくてもHFPが張られるようです。そのため、serviceのstatus値が0になっており、サービスが利用できないことを示しています。そのうちにFaceTimeも使ってみますかね。



さて、HFPに関連して確認したかったことがもうひとつ。時刻の取得です。HFPが時刻取得用のATコマンドであるAT+CCLK?をサポートしているかどうかを確認したかったのです。結果は次のとおり、サポートしていました!!　UNKNOWNというメッセージは、WT32のHFP層がAT+CCLKの応答を解釈できないことを示す表示なので、この部分はアプリレベルで無視してやらなくてはなりません。



このAT+CCLK コマンドですが、なかなかサポートしている端末に出会えずにいました。iPhoneは最初からサポートしているみたいですが、わたしがいくつか調べたドコモの端末は全滅でした。ドコモさんのことですから、ガラ携でサポートすべきATコマンドまできちんと仕様化されていて、それに漏れたコマンドはサポートされていないのかもしれんと想像してみてみたり。そんな仕様化とは関係の無い(?)最近のAndroid端末ならサポートしているのかもしれません。MBAでもFaceTimeが使えますのでHFPがサポートされているのですが、Mac OS X10.7.2ではAT+CCLKはサポートされていませんでした。このあたりも、iOSとMac OS Xのビミョーな違いです。

このコマンドが使えれば、HFP接続した際に時刻を取得してヘッドセット側の時計の時刻合わせができることになります。ソニエリのMW600なんかもこの機能をサポートしているのですが、AT+CCLKをサポートする端末が使えなかったので、これまで動作確認したことがありませんでした。




これで演奏中の曲名に加えて時刻表示もできるようになって、MW600もようやくと本領発揮という感じです。もちろんBlueSAMでもこの時刻合わせ機能をサポートするつもりです。普通はアプリを使ったり作ったりするためにiPhone/iPod Touch買うのでしょうが、わたしの場合そういうことにはほとんど興味が無くて、BlueSAMを使うのに都合のいい端末という理由でiPod Touchを購入したのですから。

	SONY ソニーエリクソン ワイヤレスヘッドセット MW600 (ホワイト) MW600/W
	ソニー
	ソニー

製品ロードマップ

先週発表になったSAM4S。気がつくと製品紹介ページができていて、そこにこんな図が。。



良かった、SAM3XもSAM3Aも来年出てくるようですね。SAM-BAも新しいバージョンが出ていて、こちらのリリースノートを見るとSAM3S8, SAM3S16, SAM3X8, SAM3X4, SAM3X2がすでにサポートされていることになっています。SAM3SDって、どういう構成かな？フラッシュの容量としてはSAM3S8と同等だと思われますけど。

今回もSAM-BAのパッケージに含まれるデバイスのヘッダファイルを覗いてみていますが、SAM3XとSAM3AはHigh speedでOTG対応になる模様。XとAの違いはEtherの有無でしょうか？SAM3Xでは100ピンを超えるピン数のデバイスも出すようですが、LCDコントローラはサポートしないように見受けられます。SAM3SでサポートされていたParallel Capture機能も,
SAM3Xではサポートされていないようです。CMOSカメラつなげるには手軽に使える機能なんですが、SAM3SではHSMCIと端子割当がだぶっているのが痛かったので、SAM3Xで改善されないかと期待していたのに。。