Jinです。 ちょっとした報告と言うか実験結果です。
legOS に付属する、legOS用のファームウエアーを転送する
プログラム、 firmdl3.exe というのがあるのですが、これを
パッチ当てるの面倒だったんで作り直して USB対応のプログラム
を作れました。
そのうち、公開したいと思っています。 もっとも、この
firmdl3.exe がなくても、 UBS 対応の NQCでもファームウエア
は転送できます。

いま、実験しているのは、legOS のバイナリファイル(.lx) を
アップロードするプログラム dll.exe というのが有るのですが
これも、パッチを当てながら作り直しているのですが、まだ、
残念ながら動かないです。

RIS2.0 だけを持っていて、legOS を使いたいと思う人には
必衰なんですが〜。
legOS を古いバージョンを使って、毎回ファームウエアー
を転送する方法も有るけど、それだと、バイナリだけの転送
に比べると遅いのが難点ですね〜。

JinSatoです。

http://www.mi-ra-i.com/JinSato/MindStorms/legOS/usb_ir_with_legOS.html
USB IR-Towerでも legOS を使えるようにするためのパッチと
それの関連情報を公開しました。

もしも、試されてうまくいった方がいらっしゃいましたら教えていただけると嬉しいです。

JinSatoです。
パッチを公開したんですが、ほとんど反応ないみたいです。
やっぱり、日本でのlegOS のユーザーは少なさそうですね〜。

Jinです。

ずいぶん悩み、No496 にも書きましたが、RCXがどうも受信もしていない
ということに気が付いて、パリティ設定が違うのではと思い、legOS の
カーネルのコードを読んでいたら、やはり、legOS の LNP ではパリティ
設定をしていないようです。

legOS のパッチの個所もわかり、legOS の LNPにパッチを当て
ファームウエアーの転送プログラムや、ユーザープログラムの
修正なども行った結果、ユーザープログラムの転送もうまく
動くようになりました！！

そのうち、まとめて公開したいと思います。

legOS のカーネルの変更箇所

include/sys/lnp-logical.h
#ifdef CONF_LNP_FAST
#define LNP_LOGICAL_BAUD_RATE B4800 //!< baud rate
#define LNP_LOGICAL_PARITY SMR_P_NONE //!< parity
#define LNP_BYTE_TIME MSECS_TO_TICKS(3) //!< time to transmit a byte

#else
#define LNP_LOGICAL_BAUD_RATE B2400 //!< baud rate
#define LNP_LOGICAL_PARITY SMR_P_ODD //!< parity
#define LNP_BYTE_TIME MSECS_TO_TICKS(5) //!< time to transmit a byte
#endif

---
lnp-logical.c
// serial setup to 8N1 / default baud rate.
//
// S_MR =SMR_P_NONE;
S_MR =LNP_LOGICAL_PARITY;
S_BRR=LNP_LOGICAL_BAUD_RATE;
S_SR =0;

====
の2箇所を変更して、legOS のカーネルを作ります。

あと、/util/dll-src の方はちょっと多いので、また別のページにでも纏めてみます。
ということで、取り急ぎ。

補足です
USB IR Tower からデーターを読むときに、Windows の APIである
ReadFile を使ってデーターを読むのですが、これの動き方が
シリアルのIR Towerと全然違いますね〜。

シリアルのIR Towerだと、データーを受信できないことを前提
にして、タイムアウトをセットして、データーを受けるのですが

USB の IR Towerだと、データーがあるなし関係なく、ReadFile
をすると、すぐ関数から帰ってくるんですよね〜。
WaitObjectXxxxx 関連の APIを使って、待ってもだめなんですね。
まあ、その辺は、少し小さなロジックをいれて、データーが
なくて ReadFileを抜けた場合の処理をいれて、小さなループ
を作れば問題ないんですが。

ちょっと、ビヘーブが癖有りますね。 USB IR-Tower

どなたか、ほかに、USB IR Tower 関連のプログラムされている
人いらっしゃいますか〜。

もう少し研究してみました。
シリアルIR-Towerの場合だと、仮に 0x55,0xff,0x00 とデーター送った
あと、すぐシリアルポートを読むと、 0x55,0xff,0x00 とデーターが
送ったものと同じ物がオウム返しで読みこまれますが。

USB IR Towerの場合だと、そのようなオウム返しの部分がないですね。

legOS の ユーザープログラムを送る DLL コマンドなどは
その、オウム返しの部分を前提にしてプログラムされていますね〜。

その部分を外してやって、やれば、ユーザープログラムも転送
できるかと思い、プログラムを修正したのですが、そんなに甘く
はなかったようです。

さらに調べる必用がありそうです。

> シリアルのIR Towerだと、データーを受信できないことを前提
> にして、タイムアウトをセットして、データーを受けるのですが

おお！そうなんですね。Lejosでどうもうまく改造ができないんだけど、
これヒントになりそう。

> USB の IR Towerだと、データーがあるなし関係なく、ReadFile
> をすると、すぐ関数から帰ってくるんですよね〜。
> WaitObjectXxxxx 関連の APIを使って、待ってもだめなんですね。
> まあ、その辺は、少し小さなロジックをいれて、データーが
> なくて ReadFileを抜けた場合の処理をいれて、小さなループ
> を作れば問題ないんですが。

データーがあるとすぐに、データがないとタイムアウト後
（初期値200ミリ秒　Windowsだとコントロールパネル内のUSBタワーの
設定で変えられる）にReadFileから復帰しますね。
よって、ループしてReadfileでデータの受信待ちをしても
データ無しで絶えず復帰してくるので、データ無しなら
ループに戻る等の考慮がいるのではないかと思います。
ちなみに私が作成中のLEMOCON（JavaでRCXをリモコンするクラス）では
ひたすらReadFileして、データが無ければ、何も処理しないように
しています（つまり、プログラムを動かしている間は、
グルグルとReadFileを200ミリ秒ごとにループしている）。

> ひたすらReadFileして、データが無ければ、何も処理しないように
> しています（つまり、プログラムを動かしている間は、
> グルグルとReadFileを200ミリ秒ごとにループしている）。

自分もその方法で、legOSようのコマンドにパッチを入れたのですが、それでも
だめだったんですよね〜。 面倒だからスクラッチビルドして作り直そうかと思ってます。
基本的に、USB IR TowerからのRead はタイムアウトで抜けるのが早いので
別スレッドにして、ある間隔で常にRead して、もしも何かデータ-を読んだら、
リングバッファに入れてしまおうと思っています。
それで、メインのルーチンは、リングバッファからデータ-を読む。 データ-がなければ、
そのむねを返す感じです。

ただ、それでも、問題があって、legOSの場合、2400BPS 以外にも、4800BPSで
データ をやり取りするんですが、USB IR-Tower でそれが可能なのかがちょっとわからない
ところが痛いです。

ちなみに、ファームウエアーの転送するときも、2400BPS で転送するようにパッチを
当て動くようになったんですが。
legOS 0.2.5だと、IPLみたいな感じで初めに4800BPSのダウンロードするための
小さなファームウエアーを2400BPSで転送し、そのコードを使って4800BPSで legOS
のファームウエアーを転送しているんですよね〜。

その部分を組み込まない legOS を作って試してみたいとは思っていますが。

">

> ただ、それでも、問題があって、legOSの場合、2400BPS 以外にも、4800BPSで
> データ をやり取りするんですが、USB IR-Tower でそれが可能なのかがちょっとわからない
> ところが痛いです。

LSCに速度切り替えのAPIが実装されている事から、
ほぼ間違いなくUSB LEGO Towerにも通信速度の切り替えは、
用意されているでしょうね。

ただ、コントロールパネルにもそのUser Interfaceがなく、
実際切り替えるところをUSB Snoopyでも見られないし、
今のところ手も足も...と言う状況ですね。

> その部分を組み込まない legOS を作って試してみたいとは思っていますが。

いっそのこと、最初の部分でlzh解凍ソフトを送りbootさせ、
後半部分は、圧縮バイナリ-を2400bpsのまま送って高速化するとか、
別の手を考える方が、良いかもしれませんね。

最終的にWork RAMになる領域に解凍プログラムをmapして、
DL終了後は「自爆」すれば、無駄にならないし、
もし、4800bps通信が可能になったときは、
さらに高速化することになるし(^^)

H8のバイナリ-に限定されているので、
圧縮用のマッピングテーブルをあらかじめ最適化できるんで、
相当小さい圧縮／解凍プログラムでも、
結構な性能のものが作れるんじゃないかと思います。

> いっそのこと、最初の部分でlzh解凍ソフトを送りbootさせ、
> 後半部分は、圧縮バイナリ-を2400bpsのまま送って高速化するとか、
> 別の手を考える方が、良いかもしれませんね。

現状だと、legOS(0.2.4) のファームウエアーをインストールした
RCXは USB IR Towerから送られたデーターを一切受け付けない
ようなのです。

そのレベルなので、圧縮して送るというのは、夢のまた夢
状態です。（悲しい）

USB IR Tower から出ている赤外線の信号は、たとえば、石川さん
が作られたポケステ用のIR Monitorや、自分がPICで作った
LCDに表示するハードなどでは問題なく受信しているのですが、
どうも、RCXは反応しないようなんですよね〜。

RCXのROMの部分を使ってのlegOS自体のファームウエアーの
ダウンロードは問題なくUSBを使ったIR-Towerでも可能なのですが。

テストに使っている RCXは1.0 のもの、パワージャックが無くなった
1.0(RIS1.5に付属の）、そして、RIS2.0に付属のRCX2.0 で試して
いるのですが、全部同じ状況です。

いずれにせよ、もう少し研究が必要な感じがします。

現状で分かっていること
１：シリアル IR-Tower では ReadFileでデーターを読んでも
タイムアウトを自分で設定しない限り返ってこない。
しかし、USB IR-Towerはコントロールパネルで指定した
時間が過ぎると、帰ってくる。
そのため、その部分のソフトのつくりを変更する必要有り

２：シリアル IR-Towerの場合は、初めに１０Byte Writeした
あとすぐ、Readすると、初めにWriteした１０Byteと同じ
物がオウム返しで帰ってくるが、USB IR-Towerの場合は
そのようなことが無い。
そのため、ハンドシェイクをするようなソフトの場合、
オウム返しの部分の処理を変更する必要がある。

という２点が大きな違いみたいです。
もっとも、まだ legOS のユーザープログラムがうまく送れて
いないので、上の２点も、間違っている点がある可能性が
大きいですが。

> 現状で分かっていること
> １：シリアル IR-Tower では ReadFileでデーターを読んでも
> タイムアウトを自分で設定しない限り返ってこない。
> しかし、USB IR-Towerはコントロールパネルで指定した
> 時間が過ぎると、帰ってくる。
> そのため、その部分のソフトのつくりを変更する必要有り
>
> ２：シリアル IR-Towerの場合は、初めに１０Byte Writeした
> あとすぐ、Readすると、初めにWriteした１０Byteと同じ
> 物がオウム返しで帰ってくるが、USB IR-Towerの場合は
> そのようなことが無い。
> そのため、ハンドシェイクをするようなソフトの場合、
> オウム返しの部分の処理を変更する必要がある。

書き忘れていた3番目の違いが有ります。
３：シリアル IR-Towerは最後に転送したあと2秒間ほど、受信可能になり、それを
示すかのように緑色のLEDが点滅します。
しかし、USB IR Towerの場合はいつも受信可能です。 緑色のLEDが点滅がしていない
時でも受信可能です。 受信するとLEGが点滅するようになっています。
そのため、シリアル IR-Towerを使って、コミニケーションをするようなプログラムの場合、
シリアル IR Towerをアクティブにするために、2秒間隔でダミーのデーターを送る必要が
有りますが、USB IR Towerの場合は、その必要がありません。

という感じですね。

">

> しかし、USB IR Towerの場合はいつも受信可能です。 緑色のLEDが点滅がしていない
> 時でも受信可能です。 受信するとLEGが点滅するようになっています。

USB Lego towerの受信動作と緑のLEDの点滅に関する詳細は、
Q&A BBSのPieさんの質問に答えて、
http://www.mi-ra-i.com/JinSato/MindStorms/QA/BBS/qa_153.html
その後
http://www.line.to/mac/MindStorms/legotower/
にまとめました。
受信したとき、必ず点灯するわけでなく、もうちょっと複雑です。

さきの、遮光問題は、
http://www.mi-ra-i.com/JinSato/MindStorms/SGI/BBS/sgi_6.html
http://207.236.16.161/JinSato/MindStorms/BBS/a_1018.html

なのですが、いずれも、どうもうまく検索にかかりません。
http://207.236.16.161/cgi-local/namazu.cgi?
何か原因に思い当たることありませんか？

> http://207.236.16.161/cgi-local/namazu.cgi?
> 何か原因に思い当たることありませんか？

過去ログに入っていないものはインデックスの対象にはならないんですが、
数個のファイルがまだ、インデックスがかかっていませんでした。
いま、インデックスをかけなおしてみましたが、どうでしょうか〜。

">

> いま、インデックスをかけなおしてみましたが、どうでしょうか〜。

ありがとうございます。
ばっちり引けました。

ところで、過去のLogへの入り口は、
BBS CGIになっているためか、
なかなか外部検索サーバーにもかからないようです。

以前ですと、外部検索サーバーの性能がそこそこで、
専用になまずを仕立てるほうが、ずっと効率がよかったと思いますが、
google.comなど、相当強力になって、
しかもノイズをうまく減らしているためずいぶん使いやすくなりました。

「過去のログ」にも、「外部検索ロボットをうまく誘い込む」というのが、
結構有用で、効果的じゃないかと思います。
Topから、「過去のLog置き場」などというLinkを作り、
普通のHTMLで、片っ端から過去ログにLinkしたPageを、
BBS CGIが過去ログを作るたびにLinkを自動的に追加するようにしたら、
人が見るのには役立ちませんが、検索サーバーが、
しっかりIndexを作ってくれるんじゃないでしょうか？

どうも、mac さん

> google.comなど、相当強力になって、
ですね、私もずいぶん愛用しています。

> 「過去のログ」にも、「外部検索ロボットをうまく誘い込む」
> というのが、結構有用で、効果的じゃないかと思います。
> Topから、「過去のLog置き場」などというLinkを作り、
> 普通のHTMLで、片っ端から過去ログにLinkしたPageを、
> BBS CGIが過去ログを作るたびにLinkを自動的に追加す
> るようにしたら、人が見るのには役立ちませんが、検索サーバーが、
> しっかりIndexを作ってくれるんじゃないでしょうか？

にゃるほど、CGIを作って、一発でUpdate できるようなもの
考えてみます。 いま、内部的に過去ログが2箇所に分散さ
れているのもちょっと問題なんですよね〜

手動でFTPをつかって同期を時々とるようにしているんですが、
どうも、面倒で。 まじめに sh のスクリプト書けばよいのですが〜。

">

> にゃるほど、CGIを作って、一発でUpdate できるようなもの
> 考えてみます。

joyfulはちゃんと書かないと無理だと思いますが、
Web forumは、過去ログがhtmlになっているので、
これを置いてあるデレクトリーを専用にして、
ほかには何も置かないようにし、
デレクトリーリスティングを許可した上、
単にそこへLinkしてやれば、一発ですね。

Ｊｉｎです
> joyfulはちゃんと書かないと無理だと思いますが、

joyfull の方、ログファイルを、html にして残すように実はしてあるんですよ〜。
そうしないと、Namazu の方が後でIndexをつけれなくなるので。

> Web forumは、過去ログがhtmlになっているので、
> これを置いてあるデレクトリーを専用にして、
> ほかには何も置かないようにし、
> デレクトリーリスティングを許可した上、
> 単にそこへLinkしてやれば、一発ですね。

ディレクトリの構築は、以外にシンプルになっているので、簡単かもしれないですね。
そのうちやってみたいと思います。
その前に、RIS2.0 で legOS を使う方法を纏めて、Noga に送らないと ....

ききょうやです
RcxCCの改訂版を作ってるときに、独自の通信ルーチンを作成したので
いろいろ調べた範囲では・・・

> 現状で分かっていること
> １：シリアル IR-Tower では ReadFileでデーターを読んでも
> タイムアウトを自分で設定しない限り返ってこない。
> しかし、USB IR-Towerはコントロールパネルで指定した
> 時間が過ぎると、帰ってくる。
> そのため、その部分のソフトのつくりを変更する必要有り
>
> ２：シリアル IR-Towerの場合は、初めに１０Byte Writeした
> あとすぐ、Readすると、初めにWriteした１０Byteと同じ
> 物がオウム返しで帰ってくるが、USB IR-Towerの場合は
> そのようなことが無い。
> そのため、ハンドシェイクをするようなソフトの場合、
> オウム返しの部分の処理を変更する必要がある。
その通りです。でもその分速くデータが転送できます。
RcxCCピアノでの反応が全然違います。
ただしScoutにとっては不都合だったのかもしれませんけど
（データ欠損おこしやすいので）

">

>> オウム返しの部分の処理を変更する必要がある。
>その通りです。でもその分速くデータが転送できます。
>RcxCCピアノでの反応が全然違います。

Serial Portだと確かにエコーバックの為のオーバーヘッドは、
結構なSystem Resourceを浪費しますが、
これは、ディスクリート部品でハードウエアーを簡略化したためのことで、
USBの場合に、エコーバックしなくなったのは、
そこにLocal CPUが介在するため、Echo Backの有る無しを、
同じコストで選択可能になったためと思います。

もし、エコーバックありを選択したとしても、
無駄といえば無駄ですが、USB BUSの速度は、
2400bpsに比べ充分に速く、RcxCCピアノの応答速度に、
人間が認知できる影響を与えるような差を生じることはおそらく無いでしょう。

システムの互換性として考えると、COMの属性を与えず、
USB LEGO Towerに独自のAPIを用意したのは、
ユーザーにとってかなり都合の悪い失策だと思います。

もっとも、Spilit.ocxを廃止したのとあわせて、
意識的にそうしたのかもしれませんが...

>ただしScoutにとっては不都合だったのかもしれませんけど
>（データ欠損おこしやすいので）

Scoutのデータ-欠損は、エコーバックの禁止が、送信終了後の時間で切っていて、
その時間が必要時間ぎりぎりだから生じたのではなく、
送信用赤外線LEDの放射光が、受信モジュールに直接入射しやすい、
構造的な問題にあることは、アルミホイルをいれて遮光すれば、
この現象が防止できることから、すでに証明したとおりです。

もし、エコーバックを禁止していなくても、
IRMの性質上、今の構造であれば、データ欠損を生じます。

ききょうやです。

> >RcxCCピアノでの反応が全然違います。
>
> もし、エコーバックありを選択したとしても、
> 無駄といえば無駄ですが、USB BUSの速度は、
> 2400bpsに比べ充分に速く、RcxCCピアノの応答速度に、
> 人間が認知できる影響を与えるような差を生じることはおそらく無いでしょう。
ということは、エコーが問題ではないということかな？
COMのIRタワーの方が反応が鈍いのは他の原因があるのかな？
RcxCCコードに問題があったりして・・・調べなきゃ。

> >ただしScoutにとっては不都合だったのかもしれませんけど
> >（データ欠損おこしやすいので）
>
> Scoutのデータ-欠損は、エコーバックの禁止が、送信終了後の時間で切っていて、
> その時間が必要時間ぎりぎりだから生じたのではなく、
> 送信用赤外線LEDの放射光が、受信モジュールに直接入射しやすい、
> 構造的な問題にあることは、アルミホイルをいれて遮光すれば、
> この現象が防止できることから、すでに証明したとおりです。
そういうことでしたか。。。勘違いしていました。
COMのIRタワーは、そうならないような構造になっているのでしょうか？
あまり考えたことがありませんでした。
だとすればUSBタワーは構造的に欠陥があるということになりますね
うーむ・・・
RIS2.0の世界発売の時には改善されるかもしれませんね。

">

>> 無駄といえば無駄ですが、USB BUSの速度は、
>> 2400bpsに比べ充分に速く、RcxCCピアノの応答速度に、
>> 人間が認知できる影響を与えるような差を生じることはおそらく無いでしょう。
>ということは、エコーが問題ではないということかな？
>COMのIRタワーの方が反応が鈍いのは他の原因があるのかな？

エコーバックの有無による差の考察は、
USB IRTでもしエコーバックしても...
ですので、COM IRTでは差が出ると思います。
できれば、COM IRTの時にエコーバックしない設計にして、
USBでもそれと同一にするのが理想なのですが、
あのCOM IRTの回路構成で、エコーバックをしないようにするのは、
コスト増になるので、しなかったのでしょう。

>> この現象が防止できることから、すでに証明したとおりです。
> そういうことでしたか。。。勘違いしていました。

こちらこそすみません。
このBBSと「元祖」で発表しただけで、
http://www.line.to/mac/MindStorms/legotower/
を更新するのをサボっています。

>だとすればUSBタワーは構造的に欠陥があるということになりますね

多分そうです。
RCXで確認した物の、Scoutで十分検証しなかったので、
この問題を見過ごしているのです。

無線機でもFull break-in
(送信中も受信を続け、単送同士なのに、
半二重のように通信できるようにふるまうこと）
で通信すると送信直後、受信部のAGCの応答速度で、
一瞬だけ、送信後に受信の空白を生じ、
「ひゃっくり」などと言います。

USB IRTに生じているのも、
おそらくこれと同じ現象です。

">

> このBBSと「元祖」で発表しただけで、
> http://www.line.to/mac/MindStorms/legotower/
> を更新するのをサボっています。

ようやく、更新しました。

とても翻訳まで手が回らないので、この現象に気付いているかだけでも、どなたか、MS開発チームに問い合わせていただけると助かります。

どうも、mac さん

> > このBBSと「元祖」で発表しただけで、
> > http://www.line.to/mac/MindStorms/legotower/

拝見しました〜。 早速ですが、 IR-Tower のページからもリンクさせていただきました。
http://www.mi-ra-i.com/JinSato/MindStorms/deep/programing-of-ir-tower.html


> とても翻訳まで手が回らないので、この現象に気付いているかだけでも、
>どなたか、MS開発チームに問い合わせていただけると助かります。

全部、訳すとなると大変ですよね〜。

短く纏めると、
基本的な問題点は SCOUT での認識率が低い。
原因は、USB IR Towerの内部で起きている赤外線のリフレクションが原因と考えられる。
簡単なアルミのカバーを取り付けるだけで認識率が高くなる。

という感じでしょうか。

">

> 基本的な問題点は SCOUT での認識率が低い。
> 原因は、USB IR Towerの内部で起きている赤外線のリフレクションが原因と考えられる。
> 簡単なアルミのカバーを取り付けるだけで認識率が高くなる。

そうですね。
因果関係を整理して、
1. USB IRTとSCOUTの通信はエラーが多発する。
2. USB IRTの送信用LEDの光が受信モジュール(IRM)に直接当たり、この為に、送信終了直後はAGCが、かかり過ぎ、受信感度が下がってデーターを取りこぼすことが原因と予想された。
3. これを検証するため、アルミホイルをLED/IRMの間にはさんだところ、エラーの発生がなくなった。
ですかね。

">

> 1. USB IRTとSCOUTの通信はエラーが多発する。
> 2. USB IRTの送信用LEDの光が受信モジュール(IRM)に直接当たり、この為に、送信終了直後はAGCが、かかり過ぎ、受信感度が下がってデーターを取りこぼすことが原因と予想された。
> 3. これを検証するため、アルミホイルをLED/IRMの間にはさんだところ、エラーの発生がなくなった。
> ですかね。

この程度に要約すれば、私でもレポートできますね(^^;
というわけで、一応送っておきました。

Jinです
> というわけで、一応送っておきました。

す、すばやいです、mac さん。 lego からお礼とかくるといいんですけどね〜。

そういえば、ふと、思ったのが２つあります。 １つはRCXのことです。

RCXは赤外線LEDが2個、受信モジュールを両側からはさむように配置してありますが
その配置でも、リフレクションによる、ロスがあまりない感じがしたことです。

２つめは、以前 話題になった 赤外線受信モジュール IS1U60 でテストをしていたときに、
前面部分ではなくて上面部分からの雑音をとても拾ってくる事がわかりました。 100Wの白熱灯
から（ちなみに60Khzです、オタワは）からもノイズを拾うのか、てっぺんの部分を手でカバーすると
ノイズを拾わなくなるんです。

CRVP1738 はノイズを拾うことはないのですが、正面だけではなくて、てっぺんの部分でも
割と受信できるようなので、USB IR Tower の部品配列を見ると、CRVP1738を上下を
逆に取り付けているので、下に３つあるLEDからの乱射を受けやすいような感じがしました。

いずれにせよ、LEGOも CRVP1738 を上下反対に付けた理由があるんだと思いますが、
こういうのって、色々推論したりすること自体が結構楽しいですね。

> 基本的に、USB IR TowerからのRead はタイムアウトで抜けるのが早いので
> 別スレッドにして、ある間隔で常にRead して、もしも何かデータ-を読んだら、
> リングバッファに入れてしまおうと思っています。
> それで、メインのルーチンは、リングバッファからデータ-を読む。 データ-がなければ、
> そのむねを返す感じです。
Ｃ，Ｃ＋＋は詳しくないんですが、私もLEMOCON（Java）でそうしています。
Read専用のスレッドをたてて、そのスレッドは常にReadしていて、
データを受けた時点でイベント（ＩＲメッセージやリモコンのコマンド）か
それ以外（コマンド発行の返答や光を拾って勝手に反応したゴミ等）に
振り分けています。コマンド発行時の返答ではスレッドの同期を使って
Readスレッドから返答を取り出し、イベントとして認識したメッセージは
新たにスレッドを生成して、Javaのイベントモデルとしてコールバックして
います。

> ただ、それでも、問題があって、legOSの場合、2400BPS 以外にも、4800BPSで
> データ をやり取りするんですが、USB IR-Tower でそれが可能なのかがちょっとわからない
> ところが痛いです。

うーん。これはまったくわかりません。わたしにも教えて欲しい(^_^)。
通信速度っていう概念がＵＳＢにあるのかな(?_?)　ＲＣＸ側や
ＩＲ−ＴＯＷＥＲにはありそうだけど。
まだまだＵＳＢ−ＴＯＷＥＲに関する情報が少ないですよね。
＃まあ、RIS2.0の推定ユーザ数が数千人では仕方がないか。
USBポートを監視するソフト（USB-SNOOPYだったけ？）を
ＧＥＴしてみたんですが、Win2000では動かなくって、こちらは
これ以上調査できませんでした。ＴＯＷＥＲの赤外線もIrDAでは
ないようなので詳しくは分からないし。
という事で、何かネタができたらまた書きますね。