[GELÖST] USB-RS232-Adapter funkt nur in eine Richtung

[generalmajor]

Moin!

Ich verfüge über einen USB-RS232-Adapter mit ch341-Chip. Er wird auch problemlos erkannt (und ist dann als /dev/ttyS0 verfügbar), doch, kommuniziert er nur in eine Richtung, nämlich vom Gerät (ist bei mir ein VT420-Terminal) zum Rechner, aber niemals in die andere Richtung. Die Baudrate ist beiderseits 9600, Xon/Xoff und HW-Handshake sind aus. Das sagt dmesg:

veteran:/home/jacek # dmesg | tail
[  461.526023] usb 1-1.1: new full-speed USB device number 8 using ehci-pci
[  461.612302] usb 1-1.1: New USB device found, idVendor=1a86, idProduct=7523
[  461.612305] usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  461.612306] usb 1-1.1: Product: USB2.0-Ser!
[  462.718912] usbcore: registered new interface driver usbserial
[  462.718927] usbcore: registered new interface driver usbserial_generic
[  462.718938] usbserial: USB Serial support registered for generic
[  462.724521] usbcore: registered new interface driver ch341
[  462.724539] usbserial: USB Serial support registered for ch341-uart
[  462.724564] ch341 1-1.1:1.0: ch341-uart converter detected
[  462.726218] usb 1-1.1: ch341-uart converter now attached to ttyUSB0

Verdächtiges kann ich nichts daran erkennen. Auch die stty-Config schaut nicht wirklich suspekt aus:

─jacek@veteran ~  
╰─➤  sudo stty -aF /dev/ttyS0                                               1 ↵
root's password:
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Getestet habe ich die Kommunikation übrigens mit minicom:

veteran:/home/jacek # minicom -D /dev/ttyUSB0 -b 9600 -L -t vt102

Was stimmt hier nicht? Ist vielleicht der Dongle kaputt? Danke für jeden zweckdienlichen Hinweis!

UPDATE: An einem Raspberry Pi 3B kann ich dieses Verhalten ebenfalls reproduzieren.

 

[Gräfin Klara]

Terminal DTR --> Rechner DCD ?

 

[generalmajor]

Terminal und USB-Adapter habe ich gerade durchgemessen. Ergebnis: Das Terminal hat +5,6 V zwischen den Pins 5 und 6. Alle anderen Pins haben 0 V. Der Adapter hat +5,3 V zwischen den Pins 4 und 5, sonst 0 V.

 

[Gräfin Klara]

Herr Generalmajor,
ich kann jetzt leider nicht sagen, welcher Spannungszustand Ein oder Aus ist. Du hast gemessen auf der
1. Terminalseite: GND (5) <-> DSR (6)
2. Adapter: GND(5) <-> DTR(4)
Das hilft mir leider nicht.

Wenn vom Terminal zum PC gesendet werden kann aber umgekehrt nicht, dann kann das eigentlich nur ein Handshake Problem sein.
Ich verwende nun andere Namen - PC und Modem.

Folgendes:
Der PC will ein DCD, sonst sendet er nicht. Dieses Signal erhält der PC vom Modem.
Modem DTR(out) ---> (in)DCD PC
Damit weiß der PC, dass der Carrier vom Modem erkannt wurde. Solange das nicht der Fall ist, sendet der PC nicht zum Modem.
Da du kein Modem hast, sollte sich der PC das Signal selbst geben.
Du machst eine Brücke auf Seite PC von pin DTR(4) auf DCD(1).
Sobald der PC sein eigenes DTR ausgibt, kommt es an DCD wieder herein und fertig.

Der PC will ein CTS(8), sonst sendet er nicht. Dieses Signal erhält der PC vom Modem.
Modem RTS(out) ---> (in)CTS PC
Normalerweise ist es so, dass das Modem ein RTS (Request To Send) an den PC nach CTS (in) schaltet, wenn das Modem alles gesendet hat.
Auch wenn das HardwareHandshake ausgeschalten ist, soll CTS (Clear To Send) auf Seite PC EIN sein.

Leider kann ich dir nicht sagen, ob +5,6 V zwischen GND und X ein Ein oder Aus ist. Ich vermute eher, 0V ist Ein.
Deshalb solltest du dir eine Software besorgen, die die Eingänge CTS und DCD am PC auf Ein und Aus prüfen kann. Davon gibt es genug.
Sobald CTS und DCD am PC als Ein erkannt wird, wird der PC auch senden, davon bin ich überzeugt.

Gruß
Gräfin Klara

 

[generalmajor]

My Lady,

bei Geräten, die keine Modems sind, benützt man Nullmodemkabel mit gekreuzten Daten- und Handshake-Leitungen. Ob DCD (das es ja nur 1× gibt) da überhaupt Sinn macht, weiß ich ehrlich gesagt gar nicht. Das mit den Spannungen auf DTR und DSR stimmt aber so:

Bei den Steuerleitungen (DCD, DTR, DSR, RTS, CTS und RI) wird der aktive Zustand durch eine Spannung zwischen +3V und +15V dargestellt, der inaktive Zustand durch eine Spannung zwischen −3V und −15V.…

Relevanz haben DCD, DTR und DSR bei Nullmodemkabeln aber angeblich eh keine. So sind solche Kabel nämlich verdrahtet: https://commons.wikimedia.org/wiki/File:Null_modem_DB-9_5-wire.svg

Das Terminal hat aber früher mal funktioniert (ist zwar uralt, doch 1989 war Hardware nicht so kurzlebig wie heute). Ich teste es heute Abend mal an einem normalen RS232-Port aus. Klappt es dort mit der Datenübertragung, wird wohl der Adapter der Schuldige sein.

UPDATE: Ich habe das Terminal jetzt an einen noch vorhandenen RS232-Port meines PCs gesteckt, mit minicom ausgetestet und (bis auf eine Inkompatibilität beim Zeichensatz; das alte Trumm kennt natürlich kein UTF-8) keine Probleme feststellen können. Das Kabel habe ich übrigens durchgemessen und lediglich bemerkt, dass Pin #1 (Carrier Detect) nicht beschaltet ist. Ansonsten ist es ein stinknormales Nullmodemkabel.

 

[spoensche]

Überprüfe mal, ob du bei dir am PC die Hardware Flusskontrolle eingeschaltet hast. Wenn ja schalte sie mal ab.

 

[generalmajor]

Eigentlich ist der HW-Handshake abgeschaltet, oder nicht? Ich habe in stty ja diese Einstellung stehen:

-crtscts

Etwas komisch finde ich aber, dass man DTR/DSR offenbar nicht auf- und abdrehen kann. Die Option -cdtrdsr aus der stty-Manpage liefert nämlich einen Fehler (ist jetzt auf dem Raspi getestet):

pi@autoradio:/import/valen/autoradio $ sudo stty -cdtrdsr -F /dev/ttyUSB0
stty: ungültiges Argument „-cdtrdsr“
„stty --help“ liefert weitere Informationen.

UPDATE: Ich glaube, rausgefunden zu haben, wo der Hund begraben liegt: in der XON-/XOFF-Konfiguration nämlich! Beim VT habe ich XON/XOFF ausgeschaltet, doch auf dem Rechner war XOFF aus, XON aber an (weiß der Geier, wieso)! So bekam ich es raus und das Terminal zum Laufen:

pi@autoradio:/import/valen/autoradio $ sudo stty -ixon -F /dev/ttyUSB0