風センサーにかぎらず、単位時間当たりのカウントを取りたい場合にどう作るかを検討。
1)簡単なのはAVRマイコンの割り込みをカウントして、その値をインターフェイスで渡す。インターフェイスはSPIが簡単かな。シリアルだと相手側MCUにも開いているシリアルが必要。今回はベランダ気象台のArduinoがマスターなのでシリアルはXBeeですでに埋まっている。
2)ロジックICでやるとラッチカウンタと一定周期でリセットする為のタイマーを組み合わせる感じかな。チャタリング対策も必要。
　手持ちATmega328PがAVRが有るので、AVRでSPIスレーブを作る方向でテストをしてみます。正直、マイコン使ったほうが安いし汎用性あるからなあ。

手持ちのATmega328PU (一番左は88)

梅雨前の工作目標
　今、テスト的に雨センサーと倉庫部屋温度センサーのホストにしているArduino EthernetをSanguinoで置き換えようとしてます。TCP/IPネットワークはwiznetのW5200のブレイクアウトが有るのでそれで。でも、別にSanguino(ATmega644)でなくてもATmega328でもいい気はしますけど(笑)、モノは試しっていうか。でも、将来的にはmbedのマスターコントローラに集約したいですけどね。

　新しい長いの2列のブレッドボードにメインパーツを配置してみました。広いなぁ。これで実証実験したらコンパクトな基板に押し込めていきます。

ベランダに雨センサーを設置しました。

　XBeeのEndDeviceモード。28*2秒起きにデータを投げつけてきます。自宅では初のプッシュ型センサーです。電池駆動なのも自宅初です。単4アルカリ電池3本の4.5VをLDOなレギュレータで3.3Vにして利用。電源の電圧は約5分に1回のcosm(旧pachube)へのデータアップロードのタイミングでホスト側XBeeからリモートATコマンドで確認しています。意外と電池は持つのかも？

　全くもってローテクですが、サンハヤトのくし型のシール基板をセンサーに使用。金フラッシュなので、電気分解や腐食にいくらか耐えられるかと。土台にはブレッドボード基板を使用。どちらもパターンが丁度良いのですよ。
　雨センサーは他にもセンシングの方法を考えており、
　・交流導通センサー(腐食防止の為)
　・静電容量センサー
　・いわゆる気象雨量計の転倒ますタイプ
　・濡れると色が変わるものをカラーセンサーで検知(夜とかこまるけど)
などと検討してます。雨が降ってることを検知するのって意外と大変かもと思う今日この頃。

　ブレッドボードで試してたXBee エーハイムモニターを基板に固定化しました。ケースはテンポラリ。プログラムサイズが小さかったので、CPUは余らしているATmega168Pを使ってます。

　今回のミステイク、
　1.秋月のスルーホールC基板を使ったのだけど、裏返しに使っていしまった事。スルーホール両面基板だから特に問題はないですけどね。ガイドの5 15 25の5ピンごとのシルク印刷が見られないだけ。
　2.XBeeとのrx,txの接続が逆だった事。SoftwareSerialでの接続だったのでプログラムでピンを入れ替えて修正はできたけども、今回5VのATmegaとの接続かつATmegaのTX側の分圧抵抗レベルシフトのみだったので危ないところでした。まぁ、前にも5VをXBeeに入れることはやらかしてて短時間なら大丈夫な事はわかっているので結果OK。

　今回の工夫、
　1.SoftwareSerialでxbee-arduinoライブラリを使用した事。
　2.マルチカラーLEDを使ってプログラムの動作状態を把握できるようにした事。
　　　ハードウエアrx,txはRS485に取られているしSoftwareSerialの1個しか使えないRXも使われているので楽ちんななUSBシリアルのモニターはつかえませんから。コマンド待ち、エーハイムデータ受信中、データ送信中で赤・緑・青に光らせてみました。

　今回利用した秋月DIP化基板は３つ。XBee基板とオーディオピンプラグ基板とUSBminiメス基板。どれもサイズが大きめなので、C基板だと手狭になってしまい配線に苦労しました。あと、スルーホールはハンダがリード線をたどって裏側に流れてしまうのがちょっと厄介ですね。隣のホールをはんだブリッジしたいのに全然つながらない事があります。裏をみると大変な事になってたり(苦笑)。
　このエーハイム外部フィルターのモニター基板は、ハードウエア的にはこれで打ち止め。ソフトウエアは改良して、外部フィルターへ設定変更コマンドを送信出来るようにソフトウエア面の改良はしていきます。

RS485トランシーバを足した程度。

流量とモーター回転数取得

　ArduinoのSoftwareSerialでAPIモードのxbee-arduinoライブラリによるXBee通信ができたので、エーハイムの外部フィルターと無線接続を試してみた。
4/28の実験ブレッドボードにRS485の回路を設置。ハードUARTのRX,TXはRS485に使ってしまうので、USBから電源は取れない。sparkfunのブレッドボード用電源を追加。
ソフトは、ArduinoEthernetで動かしてたヤツのネット部分を外してXBee部分を追加。動作確認用のmbed側はリターンデータの解釈の部分の変更のみ。
で、相変わらずtxとrxを逆に繋いでたりといった凡ミスを経てすぐに動作しました。大したことしてないしね。自分の使い方みたいな少量データならばSoftwareSerialでXBeeを使うのもありですね。UARTでやるのと消費電力的にどれくらい違うですかね？まぁ、Ethernetを使うと消費電力は(マイコン的には)超増えるからどっちがお得かわからんです。
　連休後半の雨の時に、秋月C基板かスイッチサイエンスのXBee対応C基板でハードウエア固定化しますかね。

　で、ATmega644P。こいつで同じ事をする(シリアルは、2つあるUARTを使いますけど)テストもしてみますよ。どうやらArduinoのご先祖のWiringが644Pだったりするのですので情報調査します。

　UARTが1つしか無い、ATmega168/328シリーズ。水槽フィルターモニターをXBee経由でコントロールしたいので試してみた。水槽フィルターとの接続は115200bps(フィルター側のファームで固定。いつかバラしたいｗ。)と高速なのでハードウエアUARTが必要。かたや,xbeeの定番Arduino用ライブラリxbee-arduinoもHardwareSerialが基本。r22の時はNSSに対応してたみたいですが最新は公式対応してない。ので、SoftwareSerial専用にライブラリを書き換えた。書き換えたってもシリアルのオブジェクトを変えただけで、両対応はしてません。
　画像のように親機のmbedからコマンドを送って、それをArduino側で受け取って、何らかのデータを返すパターンでテスト。どうも、コマンドは送られてきて、Arduino本体でも受信できているのだが、返却データがタイムアウトしている。それも親機子機双方で。なんとなく親機のアドレスが上手くとれてなくて、変な相手に返信しようとして双方タイムアウトかなとおもいつつ。プロアナで流れてるXBeeAPIフレームをみてみたら・・・。ビンゴでした。アドレスの最上位16ビットがへんてこな値でした。　何のことはないXBeeのAPIモードのAPIモードの設定が一部違っとるがな。XBeeの設定をX-CTUで直して無事動作。
　さて、UARTが2つあるATmega644も買ってみたのだが、どうしますかね。いわゆるsanguinoをお手製でやるわけですが。ライブラリの改築とか面倒かも。ATmega644はArduinoのデフォルト想定CPUファミリーとはちと違うのでねぇ。