2

標準の COM ポートを使用していくつかのカスタム ハードウェアと通信する Windows ユーティリティ プログラムに取り組んでいます。通信プロトコル (制御不能) では、生の 8 ビット データ バイトを送受信する必要があります。

現在、次の Windows API 関数を使用して COM ポートにデータを送信しています。

WriteFile(hFile, lpBuffer, numberOfBytesToWrite, ...)

ここhFileで、 は適切に開かれた COM ポートへの参照でありlpBuffer、メモリに保存したバイトの配列です。null 文字 (ASCII ゼロ) をデバイスに送信する必要があるまで、コードは完全に機能します。WriteFileヌル文字を検出するとすぐに送信を停止します。これは、文字列の末尾に到達したと見なされるためです。numberOfBytesToWriteこれは、適切に設定しても発生します。

Windows API を使用して生データを COM ポートに送信するにはどうすればよいですか? のような標準の API 呼び出しを使用したいとWriteFile思いますが、提案は受け付けています。

私は現在RapidQを使用してユーティリティを構築していますが、Windows API 関数を直接呼び出すだけです。

編集：私のセットアップは、シリアルポートを介してカスタムハードウェアモジュールに接続されたWindows PCで構成されています。モジュールには、送信された文字を表示できる小さな画面があります。このセットアップを別のサードパーティ ユーティリティ プログラムでテストしました。このサードパーティ プログラムを使用してモジュールと通信でき、ヌル文字が正しく表示されます。私自身のプログラムで を使用するWriteFileと、送信ストリームのどこかにヌル文字があると、残りのストリームが送信されなくなります。

4

6 に答える 6

3

以前に Windows のシリアル ポート プログラミングを行ったことがあり、シリアル ポートを介して null 文字を送信できたことは確かです (そうでなければ、さまざまなファイル転送プロトコルは機能しませんでした)。考えられる説明として、次の 2 つが考えられます。

  1. 受信デバイスは、最初のヌル文字で停止する方法を使用して、受信したデータを印刷しています。送信デバイスが最初のヌルで終了していることをどのように判断していますか? 問題はさらに先のどこかにあるのでしょうか?
  2. シリアルドライバーが壊れています。これはかなりありそうもないことですが、考えられる説明です。危険な独自のサード パーティ製シリアル ポートとそのドライバーを使用している場合は、疑わしい可能性があります。標準のビルトイン シリアル ポートを通常の Windows ドライバで使用している場合、これはおそらく問題にはなりません。

RapidQ をざっと見てみたところ、3 つ目の説明が考えられます。

  1. Win32 API 関数を呼び出すプロセスで RapidQ が行うマーシャリングでは、送信するデータにヌル文字が埋め込まれていると問題が発生する場合があります。私は RapidQ について何も知りませんが、これは考慮しなければならないチェーンのもう 1 つのリンクです。
于 2008-12-22T21:20:12.577 に答える
2

Win32 でのシリアル通信

于 2008-12-22T21:18:10.257 に答える
1

これが役に立たない場合は、いつでも私が行うことを行うことができます。でデバイスをテストするには、GregのCOMMコードを使用します。Qmodemを覚えていますか？:)シリアルルーチンをテスト/デバッグするための非常に優れたツール。Qmodemと単純なQmodemスクリプトを使用して、別のボックス（または同じボックス内の別のポート）のCOMポートを読み取り、送信されたすべての文字の16進値を出力することもできます。えっ、ちょっと待って。Qmodemにはそれが組み込まれています。:)DebugASCIIエミュレーションを使用すると、シリアルポートに到達するすべての文字の16進値が表示されます。次に、少なくともコードが正しく機能しているかどうかを確認できます。

さて、質問。WriteFileは、NULLに達したときに戻りますか、それともただ座って待って、決して戻りませんか？

戻らない場合は、コードではない可能性があります。WriteFileは、すべてのdwBytesToWriteを送信した場合、またはエラーが発生した場合にのみ返されます。それ以外のもの、そしてそれは書き込もうとしていますが、もう一方の端に失敗があります。

于 2008-12-22T21:44:22.870 に答える
1

Greg はおそらく正しいと思いますが、COM ポートの設定も確認します。DCB 設定が正しく設定されていることを確認してください。詳細については、SetCommState および GetCommState を参照してください。

通常、シリアルは 8N1 ですが、デバイスが他のパリティやストップ ビット構成などを使用している可能性があります。

Greg のように、私もシリアルで多くの作業を行ってきましたが、これが問題の原因となることがよくあります... RS485 と不適切な DCB 構造で試してみてください... へー..

ラリー

PS: まだ持っていない場合は、優れたシリアル ブレークアウト ボックスを用意することをお勧めします。私は家のどこかに 1 つ持っており、すべての通信中にすべての回線ですべての信号が何であるかを示し、非常に強力なデバッグ ツールです。

于 2008-12-22T21:28:18.037 に答える
1

過去に WriteFile を使用したことがありますが、null バイトでも問題なく動作しました。私は RapidQ を掘り下げますが、それが問題になる可能性があります。

于 2008-12-22T21:34:46.370 に答える