＃Delivery failureという数十通のメールが入っています。 ＃が、みなさんのところには？ ＃それも秒単位ですが・・。 ところで、 > 澤口@一升金です。 > > Shouji Hirataさんの > 高速なCPUを載せて大量のデータ加工をさせるか、 > 逆に簡単な応用はH8+USB > の組み合わせの方が有効だとおもいます > これに賛成。 > Cypress社のEZ-USBシリーズとか、 > FTDI社のチップを使えば > ホスト側ドライバも無償で提供されていますから、 > 手間いらずですみます。 > ↓ > http://www.ipishop.com/ftdi.html > http://www.cypress-japan.co.jp/products/family.php?familyid=14 これの場合、仮にウィンドウズでしたら、取りこぼしの件は どうなるのでしょうか？ ずっと前のご提案でも、同じでして、 仮にPCが間に合わないとすると、 バッファリングして、これを確実に手渡ししなくては なりませんよね？ そのためのロジックは、過去に教わりました。 実は、RTLinuxを開始する直前まで、そのための シリアル通信プログラムを準備中でした。 この場合、スレーブはPLCです。 PLCにインテリジェントI/Oをやらせておき、 外界との折衝は任せます。 PCには、パラレルI/Oを利用して、 データのシリアル番号とデータを渡します。 取りこぼすと、空きができますので、２３２で 通信して、該当する箇所のデータをもらう予定で ソフトを組んでいました。（未完成） しかしこのような取りこぼしはほとんど有り得ないのです。 （最大で８００msecのPCのおとぼけ時間しかなかったので このまま行くと常に間に合う計算です） そんなに、なさそうなことを想定して動作させる割りに 面倒な処理だったので、いっそ、簡単に、I/Oを RTLinuxで受けて、その確実性を確保して、絶対 落とさないとしたほうが、シンプルになるかと、 思ったのです。 PCがリアルタイムでないままに、インテリI/Oに 外界との折衝をさせるとした場合ですが、 PCが遅れる場合を想定したリカバリーはされるわけでしょう か？ あるいは・・・なにか面倒の少ない方法が ありますでしょうか？ わさびぃ __________________________________ Let's Celebrate Together! Yahoo! JAPAN http://pr.mail.yahoo.co.jp/so2005/
