Archive for 11月, 2009

ベランダ菜園のトマトを倒した

Posted by ゆのじ on 11月 3rd, 2009

青トマトのピクルス

もういい加減寒くなってきたので、ベランダ菜園のトマトとゴーヤをたたむことにした。ベランダ菜園のトマトは数週間放置気味だったのでいい加減何もなかろうと思っていたら、青い実があるわあるわ、ボールに二杯ほど採れてしまった。勿体ないので青トマトのピクルスにすることに。

青トマトのピクルスはいくつかのサイトを調べたが、一番それっぽかったサイト(*)を参考に、1時間ほど5%程度の塩水に漬けた後、ピックル液(酢5に対して水1の割合で混ぜたものに月桂樹の葉数枚、丁字数個、大蒜数欠けを投入、沸騰してから10分ほど中火で沸かしてさましたもの)を使って漬けてみた。数週間後からは食べられるだろう、楽しみである。

 

(*)サイトのコンテンツはいいのだけど、運営者がSEO(Search Engine Optimization)を売りにしている会社なのがなんとも胡散臭い。正直SEOなんぞサーチエンジンの尻を追いかけるだけのしょーもない商売で、そういう会社がまじめに漬け物サイトを作るわけが無く。このサイトだっておそらくただの実績作り用で作ったら作りっぱなしでサーチエンジンが方針を変えたとき以外は変更されることもあるまい。有り難く参考にはさせてもらったが、釈然としないなぁ。

XBeeを最高速で使いたい

Posted by ゆのじ on 11月 2nd, 2009

Digi社のXBee、かなり便利に使える道具だと思うのだが、割とはまっているのが速度。ああいった物に速度を求めるなという話もあるが、実際どれくらい出るのだろうと思って試してみることにした。なお、XBeeといっても802.15.4だけしか使えないOEM RF Moduleで、ZigbeeやDigimeshを使えるモデルではない。また、転送レートを調べることが目的なので、Transparent modeで使っての試験とした。

試験は自宅というごくありふれた環境で、送信元と送信先のXBee距離は40cm程度、WiFiの電波もそれ以外の妨害電波もばしばし飛んでいる状況である。その中でXBeeのボーレートを250kbpsにして、適当なソースをつないでフロー制御なしで走らせてみることにした。設定は8bit/Odd/1Stopとしたので、1バイトあたり9bit分のデータを飛ばすことになる。

その結果だが、数回繰り返したところ、おおよそ12~13kbytes/sec程度の転送レートが出ることがわかった。流れたビット数で108~117kbps、つまり出ても定格の半分程度ということになるだろうか。このテストでは、最大速度を知ることが目的だったのでフロー制御をしていない。そのため、パリティをつけている分欠損データは拾わない(カウントしていない)ものの、データの欠落は山ほど出る。実際に使うには送信側できちんとフロー制御しなければいけないだろう。また、XBeeは無線の制御にCSMA-CA方式をつかっているため、リアルタイム性も保証されない。ビットレートを落とせばある程度の安定したタイムラグを得ることは出来るだろうが、正確なリアルタイム制御をしたければNTP的にラウンドトリップタイムを得たりしなければならいような感じである。

ちなみに、マニュアルによれば、フロー制御をしたくない場合、DI Buffer size(202bytes)より1メッセージを小さくしたりボーレートを下げることを要点としてあげている。

簡単なテストではあったが、割と勘所はつかめた気がしてきた。ひとまず、CTSを握って制御してやることがまず第一のようだ。

引き続き開発。

追記:その後、CTSをきちんと処理するようにした結果、目視する限りビット落ち無しで、8k~9kbytes/sec程度のスループットが出ることもわかった。鉄筋コンクリートの壁を数枚隔てたくらいではほぼスループットは落ちない感じ。ビット落ちがきわめて少ないのは大変有り難い。

AVRが予想せずリセットされる時

Posted by ゆのじ on 11月 2nd, 2009

WinAVRの環境(avr-gccなら同じだと思うが)で複雑な割り込みがかかるようなプログラムを書いているとき、原因不明のリセットがかかる場合、可能性として考えられるのは1)ウォッチドッグ、2)電圧低下のBORリセット、3)割り込みベクタが変、が考えられる。このうち1と2は割とデバグしやすいのだが3がどう対応すればいいのかと思って調べてみたところ、こう書けばいいということがわかった。

ISR(BADISR_vect) 
{ 
    cli();    // これ以上割り込ませない
    // このあたりでデバグメッセージ	
    for(;;);  // ここで止めておく
} 

とりあえずこの中でデバッグメッセージを書いて止めてしまえば、何か起きていることまではわかる。その先はさらにデバグデバグ。

 

なんでこういうことになったかというと、送信可能状態になったときに飛んでくる割り込み(USART1_UDRE_vect)を書かないといけないところに、ぼんやりしていて送信完了時に飛んでくる割り込み(USART1_TX_vect)を書いてしまっていたからだった。そりゃBADISRにもなる。

同じはまり方をしないためにメモ。

追記:何も考えずにTXCIEnを有効にする場合、USARTn_UDRE_vectだけだとBADISRになる。USARTn_TX_vectも書いておくこと。

追追記:嘘書いた。TXCIEnはUSARTn_TX_vect、UDRIEnがUSARTn_UDRE_vectに対応ということのよう。もう少し調べてまとめたい。