デバイスを開かずに、シリアルポートが実際にデータを送信しているかどうかを確認するにはどうすればよいですか?


10

シリアル回線と2つのイーサネットNICを介して接続された高可用性クラスター(Heartbeat)があります。切断されたシリアル回線を認識できる監視スクリプトをセットアップしたいと思います(基本的に同じ質問がSO回答されましたが、そのような一般的な回答には満足していません)。

シリアルラインはハートビートによって開かれているため、シリアルデバイスを開いて自分でデータを読み取ることはできません。

だから私はいくつかの間接的な手がかりを探し始めました。これまでに見つけた唯一の違いは、の内容です/proc/tty/driver/serial。接続すると次のようになります。

# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2722759 rx:2718165 brk:1 RTS|CTS|DTR|DSR|CD

切断された場合:

# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2725233 rx:2720703 brk:1 RTS|DTR

/ proc / tty / driver / serialの内容に関するドキュメントが見つからなかったため、行の最後にリストされている信号がケーブルの接続/切断の意味を持っていると判断する自信がありません。信号の存在は、特定の信号が「今」オンになっている(または最近過去にあったか?)シリアルHOWTOが存在する追加の信号ケーブルが接続されていることを述べている(CTSフロー制御信号、DSRは「私が通信する準備ができています」、CD「モデムは相互に接続」)「入力」の方向にすべてです。したがって、反対側で誰かが生きている必要があります。

信号の意味がシリアルHOWTOで説明されていると仮定すると、たとえばCD信号の存在に基づいて判断を下すことができます。しかし、私は本当にわかりません。

だから問題は:私の方法は「正しい」のですか、それとも私が知らないもっと良いオプションがありますか?

編集: 私はいくつかの追加の観察を行い、私の同僚と話をしました。回線の終端での信号の存在または不在は、両端でのシリアルポートアクティビティの非常に優れた指標であることがわかります。ただし、ケーブルの物理的な存在を示すものではありません。シリアルポートに書き込むプログラムがある場合は常に、発信信号が存在していました(RTS | DTR)。反対側が書き込み中のとき、着信信号が存在しました(CTS | DSR | CD)。どちらの側も通信しない場合、信号はまったくありません(ケーブルが存在しないことを必ずしも意味しません)。正確な信号はケーブル配線に依存することを忘れないでください(「部分的なハンドシェイクを備えたヌルモデム」を使用しています)。


reasonabke startのように聞こえ、簡単にテストできます。また、「/ sys / devices / platform / serial8250 / tty / ttyS0 /」の下、またはシステム上で同様のものが表示される場合もあります。
rickhg12hs 2013年

回答:


5

RS232には、いかなる種類の「ケーブルプレゼンス」インジケータもありません。送信信号またはメタデータ(制御)信号を受信して​​いるだけ、または受信していない-それだけです。着信信号(CTS | DSR | CD)を受信すると、ケーブルが接続されていることがわかります。着信信号を受信しない場合、ケーブルの状態は不確定であり、追加のハードウェアソリューションなしで接続されているかどうか、またはリモートデバイスとのなんらかの交換を実行しているかどうかを判断する方法はありません。

通常のアプローチは、ある種の「キープアライブ」送信を実行することです(メタデータだけでも-たとえば、DTRを一時的に設定してCTSを期待する)。ただし、ケーブルの両端でソフトウェアによって使用されるプロトコルの規律がそのようなアイドル交換を禁止している場合は、先に進むためにはんだごてを使用することにかなりこだわりました。

あなたが試すかもしれないのは、パイプをセットアップし、ソフトウェアと物理デバイス(両端)の間でデータを転送し、それをカプセル化し、パイプがアイドル状態の場合に「接続チェック」を実行する、追加の「デーモン」です。

エンドポイントデバイスがハードウェア制御を使用しない場合は、ホスト側のプラグ内でCTSを使用してDTRを短くし、ホスト側で「ハードウェア制御」を使用できます。DTRを生成するとCTSが自動的に駆動され、ケーブルが存在する場合は送信が可能になるため、送信に影響はありません。一方、ケーブルがない場合、システムはこのイベントに適切な方法でCTSの欠如に反応します。たとえば、ケーブルが接続されるまでタイムアウトを生成したり、送信を一時停止したりします。


「デーモン」は賢いアイデアです。ただし、安定性のバグの原因になるのではないかと心配しているので、実装するつもりはありません。/ procからの信号を読み取り、着信/発信信号の有無を示すだけにします。私にはそれで充分です。
Peter Kovac 2013年

シュレディンガーの猫のようなものです。en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
Ufoguy 2014年

0

もう一方の端にデバイスが接続されていることを示すプレゼンスインジケータがありますが、これはオプションであり、プレゼンス信号の有無に関係なく送信が機能します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.