右片麻痺のIT好き。左手で生きてます。
なんかIDEが重たいなぁと思ってたら・・・。ローカルのコンパイル環境も作成しないとイザというときに使えない。
復帰したようだが重たい・・・のはFireFoxのせいだな。chromeに変えたら軽いや。
んで、無事にArduino -> mbedでSDに保存してあるファイルの転送ができました。Arduinoは1.0でやってみた。まだ、最終chunkの処理が完全ではないけどね。後ろを0x00で埋めてるけど、そんなんでもjpeg画像としては読めるんだな。
次はJpegシリアルカメラをArduinoに接続して、カメラ→SD保存。SDから読みだしてXBee転送を試します。それが上手く行ったら、ちょいと工作して、SDの部分をSPIのSRAMに変更します。
特にカメラに限ったことじゃないですが。XBeeでの大きなデータのやり取りはchunkにして何回か送らないと行けません。今は320×240の10Kbyte程の画像ファイルを送ろうとしてます。ペイロードサイズ32byteで300回ちょいに分割。
昨晩試してましたが、ハンドシェイクをサボったらやはり厳しい様です。ちゃんとやろうｗ。あと謎のリセットがかかるのだが、コレはメモリリークが怪しいな、2Kbyteしかないからなぁメモリ。とりあえずArduino=>Arduinoでテスト中。安定したら受信側はmbedに移植します。
・・・と思ってたけど、受信側はは最初からmbedに切り替えよっと。3.3VなのでXBee直結できるし、USB仮想シリアルあるし。現物シリアルも3つあるし。フラッシュメモリもある。
なんせArduinoでのXBeeのテストだと、XBee用に1つ・コンソール用に1つと最低2つのシリアルが必要で。カメラ側にいたっては、カメラ用にもう1つシリアル。送信側もmbedにしたい所ですが、テスト機がなくなってしまうズラ。Arduino系はたくさん転がってるののです。MTM07で頒布してもらったアルシオーノでもいいがな、まだ組み立てて無いけど。
シリアルJPEGカメラのライブラリを読んでいてハタと気づいて再チャレンジ。XBeeはAT透過モードで。タイムアウトまでをカウントする回数変数がuint8_tだったので、もちっと長くしてみて。それでも1,2回は通しでシーケンスが完了したものの、画像データに抜けがあって画像としては見られなかった。うーん、やっぱ当初の予定どおりAPIモードでやり取りしよっと。XBeeのATモードは無かったものと思おうｗ。PICでフローコントロールしてる人は見かけたけど、まだハードの技術がないのです、自分。
電力メーター紙カバー
やっとこさ紙カバーを切り出して、縁をセメダインCで接着して乾かして、センサー基板にかぶせました。インシュロックで止めている部分を考えてなかったので、即席で一部切り取りしましたが・・・。でも、また剥がすんですけどね。Arduino1.0が落ち着いたら移行しますから。この自作基板はプログラミング端子は引っ張らかっていないので、プログラムの書き換えはマイコンチップ毎入れ替えになりますので。
カバー付ける前は↓こんな感じでした。
実はこんなだった
昨日、シリアルJPEGカメラのコントロールを有線ではなく、無線でやるテストをしていた。XBeeのシリーズ2(うちにあるのは全部シリーズ2だし、使用中も含めて全部で10個あるw。)で、透過モードにて。
どうも、フロー制御無しでは厳しそう。XBeeの無線区間は半二重になるのでだろうか。なので、
運用想定図
こんな感じでの運用の為に実験検証中です。カメラと直結のArduino or SeeeduinoStalkerはベランダ置き。多分Stalkerを使うと思う。こいつ、microSDやXBeeのコネクタどころかRTCやらI2Cドライバまで付いているし、電源も太陽電池とバッテリーで運用出来るように充放電制御チップが載っている。クロックは8MHzだけど。コレには、土壌温度・土壌水分チェックと水やりもやってもらう予定。
カメラの画像は一旦microSDに保存しておいて、XBeeでたらたらとフロー制御しながら送信しようかと。XBeeは垂れ流し透過モードにするか、APIモードにするかは要検討。受信側をmbedにまとめるのならAPIモードかな。10Kbyteの画像だと何回やり取りが必要だろうか？XBee自体、大きいデータをやり取りするのには向いてないからなぁ。
まぁ、2月中を目処に実験していきたいと思っています。
秋月で買った急加熱ボタン付きの半田ごてgoot TQ-95。標準のこて先より細いこて先を探す。TQ-77RT-SBをマルツで売ってたので、他のパーツ(XBeeの電圧合わせ用のツェナーダイオードとか各種基板コネクタとか。)と併せて発注。送料はかかるけども、以前から書いているように秋葉にでる電車代やそこでショップを回る労力を考えたらなんとも無い。確かに数百円のパーツだったりすると気持ち的には気になるでしょうが、現代日本では代替手段が無いのだから。高いからって待っていたら機会喪失の損失のほうが大きくなるってもんだ。長生きしても身体が動かなければ好きな事も出来なく無駄に生かされて税金を使うだけだもの。
話題かわって、豆カメラに使う予定の2台目のJPEGシリアルカメラ。昨晩のテスト中にうすうす気がついてはいたが、撮影解像度変更が保存されない。販売元でも、
と、注意書きが入ってた。1台目を買う時はこんな注意書きも無く、解像度変更保存もOKで動いているのだが。豆カメラ自体は320×240で撮ろうと思っていたので購入した。だから、販売元にクレームする気はさらさら無い。実用上なにも問題は無い訳だし。
試しに、mbedにつないで撮影してみた。やはり解像度の変更は保存できないようだ。ただ、製造元のページにFAQがあってそこに、(以下転記)
Question:
We received 4 more cameras that are having the same issue in that we cannot set them to 640×480 with the LS-Y201 program. They only capture in 320×240. Please advise.
Answer:
There are two solutions.
One is we exchange these 4 cameras for you.
The second one, perhaps a better one, is you issue an command to the RAM to set it to 640×480. The only drawback is you have to run this command every time the camera is powered up, which I think is trival. Here is how:
command return
1.56 00 54 01 00 640*480 76 00 54 00 00
2.56 00 54 01 11 320*240 76 00 54 00 00
3.56 00 54 01 22 160*120 76 00 54 00 00
This is to change RAM, not EPROM, so a reset is not needed. However, the data cannot be saved after powering down. The same command needs to be run after everytime the camera is powered up.
なんてやり取りがあって、実際このAnswerの通りのコマンドを送ってみたら解像度変更はできた。ただ、電源を切ってしまうとデフォルトの320×240に戻ってしまうけども。でも、電源切って再起動する時にマイコンから解像度変更コマンドを送れば良いだけなのだから何も問題は無いのだ。まぁ、こういうハブニング的な事はアジアンデバイスでは良くある事だ。(頻繁なのでハプニングではないかも？)
明日は月次作業で出勤して、終わったら床屋に寄って、立川で書籍を購入予定なので、工作は進まないと思います。