Ich suchte nach einer Lösung, um eine serielle Schnittstelle zu kontrollieren und zu steuern. Besonders die Leitungen RTS und DTR sind im Fokus. Nun, so ganz ist es mir bislang nicht gelungen. Aber ich bin nahe dran. Damit ich es nicht vergesse, wie ich das gemacht habe, lege ich es als Dokumentation hier ab.
Mit statserial kann man sich den Status der Leitungen der seriellen Schnittstelle anzeigen lassen. Ist das kleine Tool nicht installiert, so kann es aus dem Repository mit
sudo apt install statserial
nachinstalliert werden. Welche seriellen Schnittstellen vom Rechner verwaltet werden, kann man abfragen mit
dmesg | grep tty
Als Ergebnis kommt etwas heraus, das so oder so ähnlich aussieht:
user@rechner ~ $ dmesg |grep tty
[ 0.089592] printk: console [tty0] enabled
[ 0.271882] 00:05: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
Mich interessiert hier die serielle Schnittstelle mit der Bezeichnung ttyS1, mit der ich die weiteren Versuche anstelle. Zu finden sind alle Schnittstellen im Verzeichnis /dev/. Deshalb ist die korrekte Ansprache der Schnittstelle mit /dev/ttyS1.
Mit dem Aufruf in einem Terminal
statserial /dev/ttyS1
erhält man eine kontinuierliche Abfrage der Leitungen und ihre Zustände:

Und tatsächlich, die Zustände der Leitungen ändern sich, wenn andere Programm diese in Benutzung haben und steuern. RTS schaltet mal auf 0 und wieder auf 1, usw. Je nach Rechner können die Low-Pegel (logisch 0) von -3V bis -15V und High-Pegel (logisch 1) von +3V bis +15V betragen. Nebenbei angemerkt benötige ich das Ganze für eine PTT- und Squelch (COS)-Steuerung von Funkgeräten.
Dies ist die fortlaufende Anzeige. Eine einmalige Anzeige wird mit dem Parameter -n erreicht. Die Parameter -d und -x generieren eine dezimale bzw. hexadezimale Ausgabe der Zustände.
Jetzt, da ein Monitoring der Schnittstelle schon mal ansatzweise geschaffen ist, bastele ich ein kleines Steuerprogramm mit Hilfe der Tool Command Language TCL zusammen. Dies hilft mir beim Organisieren der Steuerung, es trägt -wie einfallsreich- den Namen sertest.sh und muss ausführbar gemacht werden:
#! /bin/bash
# this is only Comment where the line ends with backslash \
exec tclsh "$0" "$@"
set myDEVICE "/dev/ttyS1"
#-----------------------------------------
proc openTTY { dev } {
# oeffnet die Verbindung / serielle Leitung.
# + raw Mode
# + 9600 bps
# + 8 Bit, 1 Stopbit, ohne Parity
# RET: des File-Descriptor
#-----------------------------------------
set cdes [open $dev r+ ]
# 9600 bps, no parity check, 8 data bits, 1 stop bit
# handle everything binary
fconfigure $cdes -encoding binary -translation binary -mode 9600,n,8,1 -handshake rtscts
return $cdes;
}
#-----------------------------------------
proc setRtsDtr { fdes rts dtr } {
# setzt an der seriellen Schnittstelle
# die Signale RTS und DTR
#-----------------------------------------
puts "setze RTS=$rts und DTR=$dtr"
fconfigure $fdes -ttycontrol [list RTS $rts DTR $dtr]
return
}
#-----------------------------------------
proc getTTYStatus { sdes } {
# liefert den Status der seriellen Schnittstelle
# RET: Status der Verbindung, nicht der des
# angeschlossenen Gerätes
#-----------------------------------------
return [fconfigure $sdes -ttystatus ]
}
puts "+++ Starte Test"
set myDes [openTTY $myDEVICE]
after 1000
setRtsDtr $myDes 0 0
after 4000
setRtsDtr $myDes 0 1
after 4000
setRtsDtr $myDes 1 1
after 4000
setRtsDtr $myDes 1 0
after 4000
setRtsDtr $myDes 0 0
after 4000
set lstatus [getTTYStatus $myDes];
puts $lstatus
after 1000
puts "+++ Beende Test"
Keine Bange, das ist nicht mein Gehirnschmalz, sondern das, was bereits im Internet überall dazu zu finden ist. Also DANKE an den Erfinder unbekannterweise!
In einem neuen Terminal Auf dem Bildschirm wird dies so abgearbeitet:
user@rechner ~ $ ./sertest.sh
+++ Starte Test
setze RTS=0 und DTR=0
setze RTS=0 und DTR=1
setze RTS=1 und DTR=1
setze RTS=1 und DTR=0
setze RTS=0 und DTR=0
CTS 0 DSR 0 RING 0 DCD 0
+++ Beende Test
In dem Terminal, wo statserial immer noch läuft kann man beobachten, wie sich die Leitungszustände ändern.
Der letzte Output zeigt die Zustände der Leitungen CTS, DSR, Ring und DCD, als Input-Leitungen. Das geschah mit dem Aufruf des -ttystatus. Leider liefert die Ausgabe aber nicht die Zustände von RTS oder DTR, den Output-Leitungen. Deswegen bin ich von der kleinen TCL-Logik etwas enttäuscht. Mein Gedanke war, dass ich mit der Abfrage auch den Zustand der PTT-Leitung (RTS oder DTR) beobachten kann. Dann war das erstmal nix. Wie schade…
Vielleicht weiß ja jemand, wie man das trotzdem hinbekommen kann die Leitungen RTS (für PTT) und RI oder DCD (SQL/COS) in Linux direkt vom Rechner in Echtzeit zu monitoren, was man dann über MQTT an einen Broker schicken kann? Letztlich bliebe hier nur noch eine elektronische Lösung mittels Arduino oder ESP32 oder vielleicht LoRa und Meshtastic? SVXLink kann es doch auch…
Gefällt mir:
Gefällt mir Wird geladen …
Ähnliche Beiträge
Ich suchte nach einer Lösung, um eine serielle Schnittstelle zu kontrollieren und zu steuern. Besonders die Leitungen RTS und DTR sind im Fokus. Nun, so ganz ist es mir bislang nicht gelungen. Aber ich bin nahe dran. Damit ich es nicht vergesse, wie ich das gemacht habe, lege ich es als Dokumentation hier ab.
Mit statserial kann man sich den Status der Leitungen der seriellen Schnittstelle anzeigen lassen. Ist das kleine Tool nicht installiert, so kann es aus dem Repository mit
sudo apt install statserial
nachinstalliert werden. Welche seriellen Schnittstellen vom Rechner verwaltet werden, kann man abfragen mit
dmesg | grep tty
Als Ergebnis kommt etwas heraus, das so oder so ähnlich aussieht:
Mich interessiert hier die serielle Schnittstelle mit der Bezeichnung ttyS1, mit der ich die weiteren Versuche anstelle. Zu finden sind alle Schnittstellen im Verzeichnis /dev/. Deshalb ist die korrekte Ansprache der Schnittstelle mit /dev/ttyS1.
Mit dem Aufruf in einem Terminal
statserial /dev/ttyS1
erhält man eine kontinuierliche Abfrage der Leitungen und ihre Zustände:
Und tatsächlich, die Zustände der Leitungen ändern sich, wenn andere Programm diese in Benutzung haben und steuern. RTS schaltet mal auf 0 und wieder auf 1, usw. Je nach Rechner können die Low-Pegel (logisch 0) von -3V bis -15V und High-Pegel (logisch 1) von +3V bis +15V betragen. Nebenbei angemerkt benötige ich das Ganze für eine PTT- und Squelch (COS)-Steuerung von Funkgeräten.
Dies ist die fortlaufende Anzeige. Eine einmalige Anzeige wird mit dem Parameter -n erreicht. Die Parameter -d und -x generieren eine dezimale bzw. hexadezimale Ausgabe der Zustände.
Jetzt, da ein Monitoring der Schnittstelle schon mal ansatzweise geschaffen ist, bastele ich ein kleines Steuerprogramm mit Hilfe der Tool Command Language TCL zusammen. Dies hilft mir beim Organisieren der Steuerung, es trägt -wie einfallsreich- den Namen sertest.sh und muss ausführbar gemacht werden:
Keine Bange, das ist nicht mein Gehirnschmalz, sondern das, was bereits im Internet überall dazu zu finden ist. Also DANKE an den Erfinder unbekannterweise!
In einem neuen Terminal Auf dem Bildschirm wird dies so abgearbeitet:
user@rechner ~ $ ./sertest.sh +++ Starte Test setze RTS=0 und DTR=0 setze RTS=0 und DTR=1 setze RTS=1 und DTR=1 setze RTS=1 und DTR=0 setze RTS=0 und DTR=0 CTS 0 DSR 0 RING 0 DCD 0 +++ Beende Test
In dem Terminal, wo statserial immer noch läuft kann man beobachten, wie sich die Leitungszustände ändern.
Der letzte Output zeigt die Zustände der Leitungen CTS, DSR, Ring und DCD, als Input-Leitungen. Das geschah mit dem Aufruf des -ttystatus. Leider liefert die Ausgabe aber nicht die Zustände von RTS oder DTR, den Output-Leitungen. Deswegen bin ich von der kleinen TCL-Logik etwas enttäuscht. Mein Gedanke war, dass ich mit der Abfrage auch den Zustand der PTT-Leitung (RTS oder DTR) beobachten kann. Dann war das erstmal nix. Wie schade…
Vielleicht weiß ja jemand, wie man das trotzdem hinbekommen kann die Leitungen RTS (für PTT) und RI oder DCD (SQL/COS) in Linux direkt vom Rechner in Echtzeit zu monitoren, was man dann über MQTT an einen Broker schicken kann? Letztlich bliebe hier nur noch eine elektronische Lösung mittels Arduino oder ESP32 oder vielleicht LoRa und Meshtastic? SVXLink kann es doch auch…
Teilen mit:
Gefällt mir:
Ähnliche Beiträge
admin