マイコン工作実験日記

Microcontroller を用いての工作、実験記録

わずかばかりの改善

2012-04-30 13:52:44 | CMOSカメラ
画像が冴えない新OV7670ボードですが、画面上にいくつか表示されていた黒いドットは消す事ができました。原因は、FIFOからの画像を読み込むタイミングが間違っていたため。しかしながら、画像そのものが汚いという問題は解決できていません。FIFOからの読み取りに起因する問題ではなさそうです。

この問題はしばらく置いておいて、画像をSDカードに保存するための作業を進めることにします。SAM3Sではパラレルキャプチャーと、SDカード接続に利用できるHSMCIが同一の端子に割り当てられていますが、今回のボードではカメラはFIFO経由でつないでおりパラレルキャプチャーは使用していません。そのためSDカード接続にはHSMCIを使っています。ATMELのサンプルを参考にFatFsを動かす作業中です。

7月出荷予定

2012-04-26 23:22:54 | SAM3
久しぶりにDigikeyを覗いて、何気に"SAM3A"で検索をかけたところが、結果が出てきてビックリ。SAM3A, SAM3XのDigikey型番が登録されており、値段も載っています。でも、残念ながら全て在庫ゼロ。「これは、もうすぐ入荷されるという前触れなのかぁ??? 」と期待して試しに数量入れてみると、出荷予想は7月4日と出ました。

SAM3A/SAM3XではUSB OTGがサポートされて、ようやくとホスト機能が使えるようになります。SAM9ではOHCIがサポートされていましたが、SAM3A/3Xでは独自のmini Host機能だけのようです。最小でも100ピンなので工作するにはハードル高いのが難点ですが、在庫が入り次第注文せねば。



HIDマウスを作る

2012-04-24 12:37:32 | WT32/BM20
先日iWRAP5 βのHIDがちゃんと動かないことがわかってガッカリさせられたのですが、そうとわかるといよいよもってHID機能を試してみたくなりました。これまでHIDキーボードを簡単に試したことはあっても、HIDマウスを試したことはなかったので、iWRAP4でこれを試してみることにしました。ハードと基本ソフトを準備しておけば、パッチが出た時にすぐに試してみることができますし。実験材料を探していたところ、千石でSparkfunのアナログジョイスティックを扱っていたので、購入。SAM3-H256とつないでみました。




購入してから気がついたのですが、このスティックの押しボタンは、スティックがセンター位置にある状態でないとうまく押せないのですね。ボタンひとつの疑似マウスに仕立てようと思っていたのですが、この仕組みだとドラッグ操作ができないことになってしまいます。うーん、イマイチだなぁ。他の人はどうしているかと思って調べてみると、Wiiのヌンチャクを使うのが定番のようですね。もっと早くに気がつけば良かった。今回はこのスティクを使うことにして、ヌンチャク用アダプタを買っておくことにしました。

ハードウェアはいたって簡単。WT32をシリアルでつないで、ジョイスティックのVRをSAM3S4BのADCにつないだだけ。ボタンはいまのところ未接続。これだけなので、SAM3S4Bをつかうまでもなく、安価なAVRとかで用が足りるわけですが、AVR用の書き込み器も持っていない自分にとってはSAM3-H256が一番使いやすくて手頃な実験用マイコンボードです。実験目的ならSAM3S4Aでもだいたいの用が足りるし、USBコネクタはミニBにしたいという気持ちもあるので、自分の実験用に基板を作っておくのも悪くないと考え始めています。

バグ出し

2012-04-19 22:31:47 | WT32/BM20
先日、iWRAP5のBATTコマンドの動作でしばらくはまりましたが、後ほど確認してみるとリリースノートのKnown Problemにはこの問題は書かれていませんでした。ベータのリリースからしばらく時間もかかっているので、すでに既知となっている問題だろうと思いつつも、基本的なコマンドがちゃんと動いていないという状況に若干の不安を覚えて一応レポートを送っておきました。翌日すぐに返事があり、やはり既知だったとのこと。

BluegigaではTech Forumからβ版を配布していますが、新しいビルドを作成してもForumにはアップしてくれないようです。Forumとはいってもユーザ相互の情報交換の場が用意されているわけでもないので、他のユーザがどんなバグを見つけているかもわかりません。そんなわけで、見つけたバグは片っ端から報告しておいた方が良さそうです。今週はHIDプロファイルが全く動かなくなってしまっているというバグに遭遇。メモリ不足のエラーが出ます。


set profile hid d 80 100 0 en 409 BT Mouse
hid set 3c 05010902a1010901a1008501050919012903150025019503750181020501093815f1250f9501750581060501093009311581257f750895028106c0c0

reset

!!! THIS IS BETA RELEASE AND MAY BE USED FOR EVALUATION PURPOSES ONLY !!!

WRAP THOR AI (5.0.0 build 518)
Copyright (c) 2003-2012 Bluegiga Technologies Inc.
:ERROR:NOMEM
READY.
hid get
NOMEM 0


この問題はまだ報告がなかった様子。WT11やWT41など他のモデルではちゃんと動いており、問題が発生するのはWT32だけだったようです。他のモデルとちがってWT32ではHFP/A2DPをサポートするために、メモリの消費量が多くなっており、このようなメモリ不足が発生する危険性が高いようです。HIDがちゃんと動くようになったら、ジョイスティックを試してみようかと目論んでいます。


画像は取得できたけど

2012-04-15 16:05:36 | CMOSカメラ
しばらくぶりにCMOSカメラです。FIFOから画像を取得する処理を用意して、ようやくとOV7670からの画像を表示できるようになりました。が、しかし、画像が汚い。




なんか感度が低いうえにノイズがのっているような画像しかとれていません。写真からでも黒いドットが乗っていることがわかります。そしてさらにはカメラの向きが90度傾いているので、対象を画面のなかに捉える操作に不自由します。カメラの資料として



という絵があったので、わざとボードに対してカメラを横向きに設置したのに... この絵は、そういう意味じゃないのかぁ??!! 資料すら当てにはできないとは、さすが中国製ジャンクカメラです。実際に動かしてみないとわからない。

画像はオートまかせにせずにゲインと露出を調整すれば少しは改善できるかもしれないので、今後の課題。ノイズはどうすりゃいいんだか。。クロック速度落としたりしてみましょうか。もう少し綺麗な画がすんなり拾えると思っていたので、大きく期待を裏切られた感じです。もっとも、送料込みで$7.99のカメラに期待する方が間違っていたのでしょう。綺麗な画が欲しければ、安物じゃダメということですかね。

同時2通話の接続

2012-04-12 06:18:57 | WT32/BM20
WCA-009が搭載するWT32の特徴のひとつに、複数のデバイスと複数のBluetooth接続をおこなえるマルチリンク、マルチポイント接続機能があります。単に複数のリンクを扱うだけであれば、音楽プレーヤと接続して用いるBluetoothヘッドフォンのような用途ではステレオ音声のリンクを扱うために必須の機能でもあります。これに加えて、携帯電話の通話にも使うためには、音楽プレーヤと携帯電話の双方とペアリングを行い、同時にA2DP/AVRCPとHFPの接続を保持できる必要があります。

このように複数のデバイスと異なるプロファイルで接続することが可能なのですが、複数のデバイスと同一のプロファイルで接続することもできます。例えば、携帯電話を2つ接続することもできます。


list
LIST 2
LIST 0 CONNECTED HFP 667 0 0 71 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 34 8d 8d 00:16:97:25:9f:48 3 INCOMING SNIFF MASTER ENCRYPTED 0


上の例のように2つの携帯をつなげたとしても、WT32の音声インタフェースはひとつしかありませんので、通常は片方の端末としか通話はできません。片方の端末で通話中に、もう片方の端末に着信があったとしたならば、着信を拒否しないといけないわけですが、着信を受けてしまったらどうなるんでしょうか?実際に試してみました。


list
LIST 3
LIST 0 CONNECTED HFP 667 0 0 101 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING ACTIVE SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 64 8d 8d 00:16:97:25:9f:48 3 INCOMING SNIFF MASTER ENCRYPTED 0
LIST 2 CONNECTED SCO 5 5c:9a:d8:c4:49:5f INCOMING ACTIVE SLAVE ENCRYPTED
NO CARRIER 3 ERROR 11f HCI_ERROR_UNSPECIFIED
RING 3 00:16:97:25:9f:48 SCO
HFP 1 STATUS "callsetup" 1
HFP 1 RING
HFP 1 CALLERID "042XXXXXX0" "" 31
@1 answer
HFP 1 RING
HFP 1 CALLERID "042XXXXXX0" "" 31
HFP 1 STATUS "call" 1
HFP 1 STATUS "callsetup" 0

list
LIST 4
LIST 0 CONNECTED HFP 667 0 0 125 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 88 8d 8d 00:16:97:25:9f:48 3 INCOMING ACTIVE MASTER ENCRYPTED 0
LIST 2 CONNECTED SCO 29 5c:9a:d8:c4:49:5f INCOMING SNIFF SLAVE ENCRYPTED
LIST 3 CONNECTED SCO 7 00:16:97:25:9f:48 INCOMING ACTIVE MASTER ENCRYPTED


着信にanswerコマンドで応答すると、ちゃんと音声パスのSCOリンクが新たに作られます。ところが、実際には2つ目の呼では音声通話はできません。相手側は無音状態になってしまいました。Bluetoothリンク上では音声が流れているハズなのですが、それをユーザに対して入出力するクチが無いために無音状態となってしまいます。

このように、複数の音声通話リンクは普通は扱えないのですが、iWRAPではこれを可能とするための仕掛けが用意されています。MULTISCO機能がそれで、SET CONTROL AUDIOコマンドで設定することがでできます。この機能を用いると、最初の通話にはステレオヘッドセットの左側のチャネルを割り当て、次の通話には右側のチャネルを割り当てるという仕掛けです。実際に試してみました。


set control audio internal internal multisco event
...
...
NO CARRIER 3 ERROR 11f HCI_ERROR_UNSPECIFIED
RING 3 00:16:97:25:9f:48 SCO
AUDIO ROUTE 3 SCO RIGHT
HFP 1 STATUS "callsetup" 1
HFP 1 RING
HFP 1 CALLERID "042XXXXX20" "" 31
@1 answer
HFP 1 RING
HFP 1 CALLERID "042XXXXX20" "" 31

HFP 1 STATUS "call" 1
AUDIO ROUTE 2 SCO LEFT
AUDIO ROUTE 3 SCO RIGHT
HFP 1 STATUS "callsetup" 0

list
LIST 4
LIST 0 CONNECTED HFP 667 0 0 55 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 51 8d 8d 00:16:97:25:9f:48 3 INCOMING ACTIVE MASTER ENCRYPTED 0
LIST 2 CONNECTED SCO 33 5c:9a:d8:c4:49:5f INCOMING SNIFF SLAVE ENCRYPTED
LIST 3 CONNECTED SCO 20 00:16:97:25:9f:48 INCOMING ACTIVE MASTER ENCRYPTED


SET CONTROL AUDIOコマンドにEVENTパラメータを付けておくことで、チャネル割り当て状況が表示されるようになりました。が、しかし。。。やっぱりふたつめの通話は無音状態になってしまいました。マニュアルには、「この機能は実験的な実装であり、ちゃんと動かないかもしれない」と明記されています。なんらかの条件によって、動く場合もあれば動かない場合もあるということなのだと推測しますが、その条件については全く触れられていません。iWRAP5 betaでも動作確認してみましたが、2通話評価する以前に、2通話目への応答ができませんでした。まだまだ、問題山積の様子。うーん、残念ですが、今回の実験はここまで。

なお、ことなるデバイスと複数のA2DP接続をおこなうこともできますが、やはり双方のデバイスからストリートを同時に流されると音が途切れるという不具合が生じてしまいます。片側のストリームを止めてから、もう片側のストリームを流すように制御してやる必要があるようです。

電圧表示であわてる

2012-04-08 19:44:53 | WT32/BM20
WT32をLiPo電池動作できるようにしたので、iWRAP5での動作確認を始めたのですが、さっそくつまずきました。BATTコマンドを使って電池の電圧を調べると、とても低く表示されます。



最初は、いつの間にかLiPo電池を過放電させてしまったのかと焦りましたが、どうやらそういうわけでは無い様子。テスタで電圧を確認すると4V以上あるのにもかかわらず、BATTコマンドでの表示は3V以下。電源関連の配線をどこか間違えたかとも考えて、確認するも問題無し。

確認のためにファームをiWRAP4に戻してみると、BATTコマンドは期待したとおりに4V以上の値を表示しました。どうやら、iWRAP5の不具合のようです。

再製作

2012-04-06 12:52:53 | WT32/BM20
WT32の実験ボードを再度製作しました。このボードは昨年のトラ技9月号で紹介したボードと同じようにヘッドフォンアンプとしてTPA6132A2をつないだものです。記事で紹介したボードは、WCA-009と一緒に部品一式を欲しいという方がいらっしゃったので、ボードごと売ってしまいました。それいらいアンプのついた実験ボードが無い状態だったのですが、やはりHFP/A2DPの実験をするにはアンプが無いと不便なので再度製作することにしました。







昨年のボードと異なる点がいくつかあります。
  1. LEDを追加。写真ではわかりにくいですが、GPIOにつないだLEDをふたつと、充電状況を示すLEDの合計3つのLEDを持たせました。充電状況表示LEDはWCA-009の下側に配置されています。
  2. USBシリアル変換器をCP2102に変更。自分で使うものなので、eBayで安くかったモジュールを使用。秋月のFT232モジュールに比べて小さいのも気に入ったので。
  3. LiPo電池動作に変更。USBつなげて設定。USBはずしても、限定された機能を提供するだけであれば、スタンドアロンで動作できます。
  4. QFN変換基板は無用に大きいので、カットして使用。
ほとんど手持ちの部品で作ったので、オーディオジャックとして微妙に大きさの違うもの2つが並ぶことになっちゃいました。基板にはまだスペースが空いていますので、タクトスイッチをつけるつもりですが、実験用のマイコンも載せようか思案中。16ピンのSAM3とかあればいいのになぁ。

さて、動作確認しようと思ってMac Book Airにつなげてショック受けました。CP2102のドライバは、silabsからダウンロードしてインストールしたんですが、Mac Book Airでは動かないのです。調べてみると、ドライバのインストール時に64bitドライバを選択してやるべきだったらしい。そんなカスタマイズが必要とは知らず、ディフォルトでインストールすると32bitドライバが動こうとするようです。再度、インストール作業をやり直したところ、ドライバは動き始めているようなのですが、途中でタイムアウトエラーが発生してしまいます。しょうがないので、Win 7の仮想マシン立ち上げて動作確認しました。こんな罠があるなんて思ってもいませんでした。うーん、不便だなぁ。

爆弾低気圧

2012-04-03 23:55:23 | Weblog
先週の土曜日もかなりの風でしたが、きょうはさらにその上をゆく爆弾低気圧でしたね。せっかく咲き始めた桜がツボミごと飛ばされたんじゃないかと心配です。とんでもない天気ではありましたが、気圧記録を採っている観点からすると、これはまさに絶好の機会です。ちょうど週間記録が採れています。




土曜日に気圧の谷底がありましたが、きょうはそれをさらに10hPa以上も下まわる爆弾ぶりです。我が家は、海抜100m程度に位置しているため、都心に比べると10hPa程低めの値になります。この後は低気圧通過にともない、グングンと気圧が上がっていくでしょう。

このグラフですが、先週のグラフから1点修正を加えました。先週までのグラフは照度(ルクス)の値が1桁大きく表示されていました。日中、上限に達しているのが10kルクスだと思っていたので、それにあわせて位取りをして表示していたのですが、実際には1kルクスで上限でした。S9705のデータシートでは最大周波数(fmax)の条件が10kルクスと記されていのがその理由ですが、特性グラフを見ると1kルクスですでに周波数は頭打ちになっていたのでした。

週間グラフでは日曜のデータにおかしな部分があり、調べてみるとどうやら24時間記録のデータが週間記録のデータの中に紛れ込んでしまっているようです。どうやらフラッシュに記録するページアドレスの計算を間違えてしまっているようです。他の曜日は問題無いようなので、日曜の場合だけ発生するバグのようです。近いうちに、原因調査せねば。