Linuxでのシリアル通信の異常？

Question

私は、シリアルポートRS232を使用して、外部サブシステムと通信するためにselectコールを使用しています（同じプロトコルが提供され、Qtスレッドとして実装されています）。私たちは外部システム用のハードウェアを持っていないので、.Net 2.0とC＃を使用して屋内のシミュレータで開発し、基盤となるサブシステムハードウェアの動作を模倣しました。私たちのアプリケーションと通信する5つの異なるサブシステムがあります。サブシステムのすべてのインターフェイスはQtスレッドとして実装されています。これはリアルタイムアプリケーションではなく、シミュレータを使用して通信するときには実際のハードウェアを持っていないため、すべてのシステムは24時間程度検出され、その後は通信が上下し、最終的にすべての通信が切断されます私は、私のアプリケーションを閉じずにシミュレータのマシンを再起動すると、ものは問題なくなります。なぜこれが起こるのですか？

.Net/C＃はリアルタイムフレームワークではないし、シミュレータを24時間実行した後も、データ送信速度が遅くなり、シリアルポートが詰まっていると思う。再起動するとすべてが消去され、すべて正常に戻ります。これは単なる推測です。誰かがより良い意見を持っている場合は、それを共有してください。注意してください、シミュレータは、.Netの人の別のチームによって作られています。

注：各プロトコルには、1 Hz、5 Hz、10 Hzという異なるデータ転送速度があります。

再起動後にシミュレータを再起動しても通信を再開しないシステムが1つあります。このシステムのポート設定もリセットポート機能は

SetPortConfiguration() 
{ 
    tcgetattr(Fd,&mOldtio); 
     mNewtio.c_cflag = B4800 | CS8 | CLOCAL | CREAD | CRTSCTS; 
     mNewtio.c_iflag = 0; //setting the input flag to icrnl causes a blank frame to be displayed after every frame. 
     mNewtio.c_oflag = 0; 
     mNewtio.c_lflag =ICANON; 
     mNewtio.c_cflag &=~PARENB; 
     mNewtio.c_cflag &= ~CSTOPB; 
     //mNewtio.c_cflag &= ~HUPCL; //added on 24/3/09 
     mNewtio.c_cc[VEOL]=0; //setting VEOL to '\r' or '\n' causes a blank frame to be displayed after every frame. 
     mNewtio.c_cc[VKILL] = 0;  /* @ */ 
     mNewtio.c_cc[VSTART] = 0;  /* Ctrl-q */ 
     mNewtio.c_cc[VSTOP] = 0;  /* Ctrl-s */ 
     mNewtio.c_cc[VMIN]=0; 
     mNewtio.c_cc[VTIME]=0; 
     tcflush(Fd, TCIFLUSH); 
     tcflow(Fd,TCION); 
     tcsetattr(Fd,TCSANOW,&mNewtio); 
} 

があるさ：

ResetPort() 
{ 
    tcflush(Fd, TCIFLUSH); //flush all data received but not read 

    tcflow(Fd,TCIOFF); //transmits a STOP character, which stops the terminal device from transmitting data to the system 
    tcsetattr(Fd, TCSANOW, &mOldtio);//set the old terminal settings 

    ClosePort(); //close port 
    OpenPort(mStrPortNo); //open the port specified by port number and in read mode 
    SetPortConfiguration(); 
} 

通信のいずれかの中断があった場合、私はポートを閉じ、再び開くResetPort関数を呼び出します。これは、1つのシステムがXYZと言うことを除いて、すべての場合の問題を解決します。 XYZシステムは、各パケットをCarriage Return、LineFeedの組み合わせで終了する一連のデータとしてNMEA形式でデータを送信します。

何が問題なのでしょうか？

Answer 1

私はこの問題を解決しました。もし私が私のことを知ることができなければ、私の謝罪。以前は、専用のシリアルポートに接続された各システムとのシリアルインタフェースに信号処理を使用していましたが、この設計では、信号ハンドラが複雑すぎるため、最初から問題がありました。理想的にはシグナルハンドラはいくつかのフラグを設定するだけで、処理する同期問題が存在する可能性があるので関数呼び出しを含まないようにする必要があり、アプリケーションで見つけたようにデバッグが難しい同期の悪夢に雪が降ります。この設計は、シリアルポートからのパケットの損失を招く。このような状況に対処するため、リセットポート機能を使用していましたが、これはパケットロスの問題を修正するための粗雑な方法でした。 私は信号ハンドラを落とし、個々のシステムにselectコールを使用しました。しかし、以前の設計の一部であったリセットポートを落とさなかった。デバッグでは、私はリセットポートを偽の機能を発見し、それを落とした。 Voila !!すべてが今完璧に動作します。 レコードでは、選択システムコールを使用するためにLinuxのpaltformでシリアル通信を使用している人に私の助言。シリアル通信の詳細を処理し、着信パケットの処理に専念することができます。

私はこのソリューションがlinux/unixプラットフォーム上でシリアル通信を行っているすべての人に役立つことを願っています。主題についての文献はあまりなく、ネット上のすべての検索はmikeとsweetによっていくつかの文書につながりますが、実用的にはあまり役に立ちませんが。私はstackoverlowのすべてのメンバーが提供してくれた助けを認めています。私はこの問題を手にするために考えられない考えを持っていました。ありがとう、歓声!!!!!!

Answer 2

".Netリアルタイム"ビットは赤いニシンです。シリアルポートは非​​常に遅いため、8086がそれらを制御できます。どの現代のCPUでも、115200ボーでさえ、余裕のあるサイクルが存在する可能性が高い。たとえそれがなかったとしても、RS232バッファの深さは、典型的にはミリ秒単位で測定されます。

シリアルポートの「目詰まり」により、物理的な類推が行き渡っていません。

あなたの問題の原因となっていることを実際に私たちに教えてくれていないので、正確に把握するのは難しいです。 「ブレークダウン」は私たちが解決できるものではありません。紛失したバイトは、タイムアウトを書き込みます。これは、具体的な対処方法です。