4

USB2.0のフルスピード実装である組み込みデバイス用の通信デバイスクラス（CDC）ドライバーに取り組んでいます。COMポート設定は、115200、8ビット、パリティなし、1ストップビット、フロー制御なしです。私たちのPCアプリケーション（32ビット、Windows 7、.NET 2.0）は、仮想COMポートを介してターゲットデバイスと通信します。仮想COMポートは、ターゲットデバイス上でFTDI（USB-to-SCIブリッジ）チップまたは統合USBのいずれかに接続できます。アプリケーションによって選択されたポートに応じて、マイクロコントローラの周辺機器。

両方の仮想COMポートは、Realtermを使用して問題なく動作します。ただし、デスクトップアプリケーションはFTDIチップを介して接続された仮想COMポートを使用して動作しますが、マイクロコントローラーの統合USB周辺機器を介して接続された仮想COMを使用しようとするとハングします。

統合USBを使用して仮想COMポート経由で接続すると、アプリケーションはへの2回目の呼び出しで常にハングしますSerialPort.Write(...)。HHDソフトウェアのシリアルモニターを使用すると、への最初の呼び出しでデータが送信されていることがわかりますSerialPort.Write(...)。ただし、そのデータがターゲットデバイスで受信されることはありません。

以前のプロジェクトで同様の問題が発生したのは、バスの両側のフロー制御設定が一致しなかったときだけだったので、奇妙です。

追加情報...

これは、統合されたUSB周辺機器を介してターゲットデバイスに接続されたPCアプリケーションを実行しているときに、さまざまなポート監視ツールからキャプチャされたデータです。任意の洞察をいただければ幸いです。

興味のある方のために、FreescaleのMCF51JM128でCodeWarrior10.2を使用しています。

任意のアイデアや提案をいただければ幸いです。ありがとう。

4

1 に答える 1

3

ログから、ハードウェアのハンドシェイク信号を処理しないという古典的な間違いを犯していることが明らかです。これは偶然にしか機能しないため、Realtermのようなターミナルエミュレータは決してその間違いを犯すことはありません。

DtrEnableプロパティをtrueに設定する必要があります。これにより、データ端末準備完了信号がオンになります。RS-232は終端されていないバスであるため、ケーブルを外したり電源を切ったりすると電気ノイズが発生する可能性があるため、重要です。DTRは、デバイスが実際に電源の入ったデバイスに接続されていることをデバイスに納得させます。もちろん、これはあなたのケースでエミュレートされますが、ドライバーまたはファームウェアは通常、RS-232動作を実装します。

また、RtsEnableプロパティは重要であり、デバイスとのハンドシェイクに使用され、アプリがタイムリーにバッファーを空にしていないときに受信バッファーがオーバーフローするのを防ぎます。実際には、HandshakeプロパティをHandshake.RequestToSendに設定する必要があります。これは、デバイスがそれを実装する最も一般的な方法です。次に、RTSをオンにする処理も行います。何らかの理由でHandshake.Noneを使用する必要がある場合は、RtsEnableをtrueに設定して自分でHandshake.Noneをオンにする必要があります。

これは問題を取り上げるべきです。それでも問題が解決しない場合は、PortMonを使用して、Realtermがドライバーを初期化する方法をスパイします。表示されるコマンドを、SerialPortクラスが送信するコマンドと比較します。それらが同じであることを確認してください。順番ではなく、値で。

于 2013-03-06T19:16:15.637 に答える