小ネタに向けて、PCとAVRをBluetooth(以降、BT)経由で接続してみる。接続形態はまずは図のようにAVR->BT無線モジュール->BTドングル->BTドライバ->仮想COM->ターミナルソフトとした。AVRとBT無線モジュールはシリアルで接続される(デフォルトで、9600bps/1stop/ノンパリ)。BTドングルはUSBでPCと接続され、PCのBT用ドライバで受けて、仮想COMが提供される。PC側のアプリは仮想COMと接続することで、AVRと通信することができる。
左の写真はブレッドボード上で動かしているところ。BT無線モジュールはRBT-001を使用。マイクロテクニカで購入。BT送信モジュールは3V動作とのことで、とりあえず電池２本で駆動。PC側にはBTドングルで受ける。PLANEX Bluetooth USBアダプタ (BT-Micro3E1XZ)を使用。
BT無線モジュール＜−＞BTドングル（BTドライバ＋仮想COM）の間は電源入れてドライバ入れるだけですんなり繋がりましたが、当初目標の全経路を接続するのはかなりてこずりました。
teratermで仮想COMと接続。AVRが送出するASCIIコードを表示させてみる。
AVRとBT送信モジュールをシリアルで繋いでいるだけなんですが、今回は（今回も？）はまりにはまった。。はまった点とどうあるべきだったかの反省
- PC側のBTのドライバ、仮想シリアルは動きが繊細で、一度変な状態になるとなかなか復活しない。PC側で一旦調子悪くなるとデバッグのためにAVR側を変更しても接続状態が直らず、AVR側は本来正常なのにいつまでも通信できない状態が続く
反省点：AVR側の設定を変えてテストしたい場合、面倒でもPC側はBTのドングルを抜いて仮想シリアルも全部消して、ドングルの再挿入、BTデバイスの検索、シリアルポートの構成をやり直した方がいい。
- AVR側は最初ケチって外部水晶を使わず、内部オッシレータで代用していた。多分周波数も誤差が大きくてうまくBT送信モジュールと通信できていなかったのでは
反省点：最初は外部水晶を使って信頼性の高い構成で不確定要素を減らして接続検証を行う
反省点：FUSE+CLOCKは過去の確実なパターンをそのまま踏襲すべき
- AVRのシリアルポートがBTの送信モジュールに使われてしまっていて、AVR内でいったいどういう動きをしているのかまったく分からず、デバッグも難航した
反省点：SPI等で内部動作を引き出せるよう通信手段を別途設けるべきであった。動くようになったので今はいらないけど、本来は内部動作を知る経路を確保すべき
- 無線だけに動作状態をプローブできずどの段階で異常なのか切り分けが困難
反省点：BTで繋がる何か既製品があれば比較試験できたかも。自分は持ってない。
久しぶりにAVRを触ったのではまった。でもまぁどうにかこうにかAVR→BT送信ユニット→BTドングル→BTドライバ→仮想COM→ターミナルソフトと接続できた。
まだASCIIコードしか送っていないけど、AVRが無線で飛ばしてくるのはなんだかケナゲではるか遠方から帰ってきた、はやぶさを思わせる。。技術レベルは全然違いますが。
■ご参考URL
http://www.microtechnica.net/ マイクロテクニカ
