Serial flow control issue with ttyUSB0

Question

This is related to a previous thread I created about a month ago and which was answered.

Today I am attempting to setup a serial console login prompt on a laptop running Ubunutu 20 with a Belkin F5U409 USB serial adapter. I have run into the same issue where larger text output will eventually fall apart into scrambled text. However, this time setting stty ixon does not resolve the behavior. See below for sample output of the issue.

For context, the computer I am using to connect to the Ubuntu laptop over RS232 is an EPSON PX-8. On the PX-8 I am using terminal emulation software called TEL.COM. See below for terminal parameters I have configured on the PX-8.

I am using systemd to enable a console on USB0 with systemctl start serial-getty@ttyUSB0.service. Do I need to configure flow control with systemd? Is there some place other than stty I need to configure parameters for ttyUSB0?

I have attempted to set this up on another laptop running Debian 10 but get the same behavior.

TEL.COM settings on the PX-8:

Baud: 9600, Char Bits: 8, Parity: NONE, Stop Bits: 2, RTS: ON, Flow Control: ON

Example of this issue when I attempt to output command history:

albert@t450:/$ history
    1  sudo rasp-config
    2  sudo raspi-config
    3  sudo nano /boot/cmdline.txt
    4  tail /boot/cmdline.txt
    5  sudo shutdown -r now
    6  sudo vim ~/boot/cmdline.txt
    7  cd /./boot
    8  dir
    9  sudo vim cmdline.txt
   10  sudo vim config.txt
   11  sudo shutdown -r now
   12  dfgdf
   13  vim
   14  sudo vim cmdline.txt
   15  cd /./boot
   16  sudo vim cmdline.txt
   17  sudo shutdown -r now
   18  cd /./boot
   19  sudo vim cmdline.txt
   20  sudo shutdown -r now
   21  ping 8.8.8.8
   2 xprt TEM=Vvj9s9ds9j3oin so nat1 machine
  x Rom =vos cngas-2goses9g3
-xtiet n n5
-s oiy
y

stty configuration on the Ubuntu machine:

albert@t450:/$ stty -a
speed 9600 baud; rows 40; columns 80; 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; discard = ^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 -flusho -extproc

Note that all of these parameters are set in stty:

ixon
ixoff 
stop = ^S
start = ^Q;
cs8 
cstopb
-parenb

Answer 1

The Belkin F5U109 seems to be a device of fairly old design, so perhaps the F5U409 with the same usb vendor:device id is similar. In this case the Linux driver chosen because of the id is the mct_u232.c. We can read in the .h file for Flow control:

no flow control specific requests have been realized apart from DTR/RTS settings. Both signals are dropped for no flow control but asserted for hardware or software flow control.

So it seems that XON/XOFF software flow control is not implemented in this driver, which is derived by sniffing the usb commands issued under Windows98. Perhaps the hardware itself does not provide this feature.

You could try implementing the flow control at the user level, but it is unlikely to be adequate as there will probably be a fifo on input and output so that when the XOFF arrives at the user level, there may still be too many characters already in the fifo that cannot be cancelled. Perhaps the PX-8 provides other protocols that could be used to packetize the data?

You might still be able to use hardware flow control, by connecting the extra modem lines RTS and CTS (pins 7 and 8 for 9pin DB9, 4 and 5 for DB25). You may need to swap these if you PX-8 is wired as a computer rather than a terminal. You would need stty crtscts too, and perhaps -clocal.

Alternatively, there are other serial-usb devices that Linux supports better, due to adequate documentation by the manufacturer, such as the popular FTDI series. The FTDI driver seems to have code to set the XON and XOFF characters in the device, which would allow for a rapid response by the hardware to the reception of an XOFF character, without needing to wait for the character to arrive at the kernel to be recognised. There are illegal copies of the FTDI chip, so try to buy a reputable make to ensure full compatibility.