6

この問題を解決しようとしている間(助けをいただければ幸いです)、PortMon を使用して RXTX のアクティビティを監視しながら RXTX を実行したところ、Java クライアントが gnu.io.SerialPort オブジェクトからのみ読み取りを行う場合でも、データが利用可能かどうかを RXTX が常にチェックしていることに気付きました。 SerialPortEventListener を介して。

どうしてこれなの？それは、RXTX 関係者による不適切な実装の選択、Sun による不適切な API の選択 (RXTX は javax.comm API に従うため)、またはネイティブ コードでサポートされている Java の実行の制限ですか?

一方、ハイパーターミナルはポーリングを行いません (問題なく動作します)。これを可能にする隠しWindowsシステムコールにアクセスできますか?

4

1 に答える 1

4

いいえ、javax.xomm API が原因ではありません。Rxtx は、その API を介して使用することも、使用しないこともできます。

ただし、Rxtx の内部は少し異なり、奇妙で、いくつかのバグがあります。短いバージョンでは、これがどのように機能するかを示しています: タイムアウトとしきい値の 2 つのパラメーターを使用します。ソース コードによると、タイムアウトを 0 (なし) に設定し、しきい値を 1 (戻る前に少なくとも 1 バイトが必要) に設定すると、InputStream で定義されたブロック読み取りにより、通常どおりになります。

問題は、このように設定しても、現在の安定リリース (2.1.7r2) にバグがあることです。しきい値パラメータは常に 0 に設定されています。ソースコードから：

/* テスト ttyset.c_cc[ VMIN ] = しきい値; */ ttyset.c_cc[ VMIN ] = 0;

紛らわしいのは、これは 2004 年にも当てはまり、メーリング リストで報告されて修正されましたが、実際には修正されなかったか、再び再発したことです (回帰)。実際、何らかの理由で最初は見つけられなかった新しいバグ レポートがあります。最終的に、プレリリース パッケージのソース コードがスローされることがわかり、それ以外の場合は公開されていない変更ログが見つかりました (Web ページには、最後の安定バージョン以降の変更ログは表示されませんが、CVS で利用可能です)。

解決

  1. HEAD で修正されているため、最新のプレリリース バージョン (2.2 シリーズ) を使用するか、CVS からコンパイルできます。

  2. 次の行に沿って醜い回避策を作成します。

    int read(InputStream in) throws IOException {
  int b; 
  while ((b=in.read()) == -1) { 
    try { Thread.sleep(10); } catch (InterruptedException e) { }
  }
  return b;
}

次に、次のようread(in)にしますin.read()。

実は忘れないように、2年前にこれについてブログエントリを書きました。

于 2012-03-04T00:36:27.720 に答える