Woher weiß ich, ob eine serielle Schnittstelle tatsächlich Daten überträgt, ohne das Gerät zu öffnen?


10

Ich habe einen Hochverfügbarkeitscluster (Heartbeat), der über eine serielle Leitung und zwei Ethernet-NICs verbunden ist. Ich möchte ein Überwachungsskript einrichten, das in der Lage ist, getrennte serielle Leitungen zu erkennen (im Grunde wurde dieselbe Frage bei SO beantwortet , aber ich bin mit einer solchen allgemeinen Antwort nicht zufrieden).

Ich kann das serielle Gerät nicht einfach öffnen und die Daten selbst lesen, da die serielle Leitung von Heartbeat geöffnet wird.

Also fing ich an, nach indirekten Hinweisen zu suchen. Der einzige Unterschied, den ich bisher gefunden habe, ist der Inhalt von /proc/tty/driver/serial. So sieht es aus, wenn es verbunden ist:

# 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

Und wenn die Verbindung getrennt ist:

# 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

Ich bin nicht sicher genug, um zu entscheiden, dass die am Ende der Zeile aufgeführten Signale genau die Bedeutung eines verbundenen / getrennten Kabels haben, da ich keine Dokumentation zum Inhalt von / proc / tty / driver / serial gefunden habe. Ich kann nur annehmen, dass das Vorhandensein des Signals bedeutet, dass das gegebene Signal "gerade" eingeschaltet ist (oder in der jüngeren Vergangenheit war? Oder?). Das serielle HOWTO sagt, dass zusätzliche Signale, die beim Anschließen des Kabels vorhanden sind (CTS-Flusssteuersignal, DSR "Ich bin bereit zu kommunizieren", CD "Modem mit einem anderen verbunden"), alle in der "Eingangs" -Richtung sind. Am anderen Ende muss also jemand am Leben sein.

Unter der Annahme, dass die Bedeutung von Signalen der im seriellen HOWTO beschriebenen entspricht, kann ich meine Entscheidung auf das Vorhandensein von beispielsweise CD-Signalen stützen. Ich bin mir jedoch nicht sicher.

Die Frage ist also: Ist meine Methode "richtig" oder habe ich bessere Optionen, die mir nicht bekannt sind?

EDIT: Ich habe einige zusätzliche Beobachtungen gemacht und ein Gespräch mit meinem Kollegen geführt. Es stellt sich heraus, dass das Vorhandensein oder Fehlen von Signalen am Ende der Leitung an beiden Enden ein recht guter Indikator für die Aktivität der seriellen Schnittstelle ist. Dies ist jedoch kein Indikator für das physische Vorhandensein eines Kabels. Immer wenn ein Programm auf die serielle Schnittstelle schrieb, waren ausgehende Signale vorhanden (RTS | DTR). Beim Schreiben der anderen Seite waren eingehende Signale vorhanden (CTS | DSR | CD). Wenn keine der Seiten kommuniziert, gibt es überhaupt keine Signale (das bedeutet nicht unbedingt, dass kein Kabel vorhanden ist). Vergessen Sie nicht, dass die genauen Signale von der Verkabelung des Kabels abhängen (ich habe "Nullmodem mit teilweisem Handshake").


Klingt nach einem vernünftigen Start, der leicht zu testen ist. Sie können auch unter '/ sys / Geräte / Plattform / serial8250 / tty / ttyS0 /' oder etwas Ähnliches auf Ihrem System nachsehen.
Rickhg12hs

Antworten:


5

RS232 hat keinerlei Anzeige für "Kabelpräsenz". Sie erhalten nur Übertragungs- oder Metadatensignale (Steuerungssignale) oder nicht - das ist alles, was Sie wissen. Wenn Sie ein eingehendes Signal (CTS | DSR | CD) empfangen, wissen Sie, dass das Kabel angeschlossen ist. Wenn Sie kein eingehendes Signal empfangen, ist der Status des Kabels unbestimmt und es kann nicht festgestellt werden, ob es ohne zusätzliche Hardwarelösungen angeschlossen ist - oder ob ein Austausch mit dem Remote-Gerät durchgeführt wird.

Der übliche Ansatz besteht darin, eine Art "Keep-Alive" -Übertragung durchzuführen (auch nur Metadaten - z. B. vorübergehend DTR einstellen und CTS erwarten). Wenn jedoch die von der Software an den beiden Enden des Kabels verwendete Protokolldisziplin einen solchen Leerlaufaustausch verbietet, können Sie Ich bin ziemlich fest damit beschäftigt, einen Lötkolben zu verwenden, um fortzufahren.

Was Sie versuchen könnten, ist eine Art zusätzlicher "Dämon", der eine Pipe einrichtet, Daten zwischen Ihrer Software und dem physischen Gerät (an beiden Enden) weiterleitet, sie einkapselt - und "Verbindungsprüfungen" durchführt, wenn die Pipe inaktiv ist.

Lassen Sie mich eine recht häufige Lösung hinzufügen: Wenn Ihr Endgerät keine Hardwaresteuerung verwendet, können Sie DTR mit CTS im Stecker auf der Hostseite kurzschließen und auf der Hostseite die Hardwaresteuerung verwenden. Das Generieren von DTR treibt automatisch CTS an und ermöglicht die Übertragung, wenn das Kabel vorhanden ist, sodass die Übertragung nicht beeinträchtigt wird. Wenn das Kabel nicht vorhanden ist, reagiert das System in der für dieses Ereignis geeigneten Weise auf das Fehlen von CTS, z. B. indem eine Zeitüberschreitung erzeugt oder die Übertragung unterbrochen wird, bis das Kabel eingesteckt ist.


Das "Daemon" -Ding ist eine clevere Idee. Ich werde es jedoch nicht implementieren, da ich befürchte, dass es zu einer Quelle von Stabilitätsfehlern wird. Ich bleibe beim Lesen von Signalen von / proc und zeige nur das Vorhandensein oder Fehlen von eingehenden / ausgehenden Singals an. Das ist genug für mich.
Peter Kovac

Es ist wie Schrödingers Katze. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
Ufoguy

0

Es gibt eine Anwesenheitsanzeige, die anzeigt, dass ein Gerät an das andere Ende angeschlossen ist. Optional ist die Übertragung jedoch mit oder ohne Anwesenheitssignal möglich.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.