The death of Xon/Xoff flow control...

[nctnico]

I'm in a bit of a pickle with a project which needs to receive large amounts of text (more than anticipated) but it can't keep up with processing and buffering is not practical. So as a quick fix I thought to implement xon/xoff handshaking. Much to my surprise this doesn't work. First I wondering I got it wrong or sending the XON/XOFF characters at the wrong time. I tried several terminal programs like minicom, Cutecom and Putty but none seem to work. So I started to wonder if something is broken at a fundamental level. And this seems to be the case. Neither Linux and Windows have working xon/xoff handshaking implemented. More precisely, the xon/xoff function is handed to the driver and (next to) none of the hardware manufacturers seems to have implemented this form of flow control. This sucks because now I have to resort to using Xmodem.

This might not be news to many but I happened to stumble upon it today.

[nctnico]

I need a universal solution which is guaranteed to work on any platform and with any type of serial port. FTDI also has its gremlins BTW.

[iMo]

While looking at the FTDI VCP drivers release notes - the xon/xoff bug was fixed in 2013
So, perhaps those chips work..

[m k]

Seems that my memory doesn't include an UART with data line handshake.

Even DEC had it by the software.
VT100 had 8080 and the standard wasn't really a standard yet.
VT220 had 8051, so hardware was finally a good second.

PC had 8250 and its power was less than more, and no memory.
Maybe it was a competition thing.
Maybe it just wasn't needed.

Shouldn't be a very complicated project though.

[pqass]

What are you connecting with what?  Something like...
[project board]-----RS232(TX/RX/GND)-----[RS232-to-USB]----USB----[host computer]

If your complaint is that the host (running minicom ascii file send) is sending too much data and not responding to XOFF from your project,
then (in minicom) check Ctrl-A Z O serial port G, and/or
in another xterm check "stty -F /dev/ttyUSB0 -a".
       [-]ixoff   enable sending of start/stop characters
       [-]ixon   enable XON/XOFF flow control

Of course, your project must send an XOFF before its buffer is full and XON when its buffer goes empty.

For additional info see "Flow control and blocking I/O" here. It specifically speaks to the scenario of slow ttys connected to fast hosts.

[magic]

I have no experience using this. I have only used HW flow control (CTS/RTS) and it works OK as long as the UART and the driver support it.

I wonder about one thing: XON/XOFF is often called "software flow control", so isn't it implemented by SW? If so, how is it affected by RX buffering in USB UART chips? Isn't it the case that XOFF gets stuck in the buffer and by the time the SW receives it, it has already TX'd too much?

[IanB]

Every time I have used RS-232 communications, XON/XOFF flow control was something that had to be enabled with a flag or switch at both ends. It is not turned on by default because it is only really intended or useful for terminal equipment with keyboard and screen, and only at low bit rates like 9600 or 19200. XON/XOFF could be valid characters in binary data and would therefore mess up the communications in other applications.

In the majority of cases hardware flow control (RTS/CTS) is superior and should be used instead.

You might also consider using the DSR/DTR signals, which sometimes are implemented, and can be used to indicate whether a device is online/offline and whether or not it is ready to receive data.

[nctnico]

What are you connecting with what?  Something like...
[project board]-----RS232(TX/RX/GND)-----[RS232-to-USB]----USB----[host computer]

If your complaint is that the host (running minicom ascii file send) is sending too much data and not responding to XOFF from your project,
then (in minicom) check Ctrl-A Z O serial port G, and/or
in another xterm check "stty -F /dev/ttyUSB0 -a".
       [-]ixoff   enable sending of start/stop characters
       [-]ixon   enable XON/XOFF flow control

Of course, your project must send an XOFF before its buffer is full and XON when its buffer goes empty.

For additional info see "Flow control and blocking I/O" here. It specifically speaks to the scenario of slow ttys connected to fast hosts.

I wish it was this simple. After some Googling and reading it turns out that a lot of USB-serial port drivers don't support xon/xoff flow control and terminal software relies on the OS layers to implement xon/xoff flow control properly. The board is sending xon/xoff character just fine and when software flow control is enabled in any one of the terminal emulators, these characters are being absorbed by the OS / driver layer but no actual flow control is happening. So it all ends there as there is no fixing this problem in a way it will work for every situation.

[iMo]

..I wonder about one thing: XON/XOFF is often called "software flow control", so isn't it implemented by SW? If so, how is it affected by RX buffering in USB UART chips? Isn't it the case that XOFF gets stuck in the buffer and by the time the SW receives it, it has already TX'd too much?

I've wired two FTDI USB/UART dongles (232R and 232H) against each other and tried with the xon/xoff text transfers. Frankly, I cannot say whether it works or not. Using two Teraterms 5.1, one is the sender and the other one is the receiver. I do not see the xoff/xon chars from the receiver (watching the led) coming to the sender with any scenario, but it is not easy to simulate one slower and one faster device as the both dongles are on the same PC..
I will look at that tomorrow with oscope, whether it somehow does the handshake or not (the led blink is too fast to see with a single char at 921k8N1)..
Btw., there are infos in various places the FTDI USB UART xon/xoff handshake works with slower devices (ie with plotters).

[pqass]

I wish it was this simple. After some Googling and reading it turns out that a lot of USB-serial port drivers don't support xon/xoff flow control and terminal software relies on the OS layers to implement xon/xoff flow control properly. The board is sending xon/xoff character just fine and when software flow control is enabled in one of the terminal emulators, these characters are being absorbed by the OS / driver layer but no actual flow control is happening. So it all ends there as there is no fixing this problem in a way it will work for every situation.

Maybe switching to a RS232-to-USB adapter with a working driver will be the most expedient solution.

From here:   "I can confirm this problem using the ch341 driver. However using FTDI-driver detecting a FTDI232RL chip flow control with XON/XOFF works ..."

I connected a real VT220 to my PL2303-based RS232-to-USB adapter and confirmed CTRL-S from the terminal halted a large ASCII file send from minicom.  Although, I'm not sure why a CTRL-Q didn't resume it.

[thm_w]

..I wonder about one thing: XON/XOFF is often called "software flow control", so isn't it implemented by SW? If so, how is it affected by RX buffering in USB UART chips? Isn't it the case that XOFF gets stuck in the buffer and by the time the SW receives it, it has already TX'd too much?

I've wired two FTDI USB/UART dongles (232R and 232H) against each other and tried with the xon/xoff text transfers. Frankly, I cannot say whether it works or not. Using two Teraterms 5.1, one is the sender and the other one is the receiver. I do not see the xoff/xon chars from the receiver (watching the led) coming to the sender with any scenario, but it is not easy to simulate one slower and one faster device as the both dongles are on the same PC..
I will look at that tomorrow with oscope, whether it somehow does the handshake or not (the led blink is too fast to see with a single char at 921k8N1)..
Btw., there are infos in various places the FTDI USB UART xon/xoff handshake works with slower devices (ie with plotters).

You'd have to manually set xon/xoff and see if the data stops, then release it to see if the data resumes. You can't just send data at the same rate the PC can receive it, I don't think.

In putty you might be able to press ctrl+s: https://superuser.com/questions/124845/can-you-disable-the-ctrl-s-xoff-keystroke-in-putty

[iMo]

 
So I did again (2:30am here) - FT232R against FT232H, both 9k6 8N1 xon/xoff handshake.
TeraTerm 5.2 latest, a Win10 latest on different PC.
TT_A sends 11MB loremipsum to TT_B with "Send File".
Trying to Ctrl-S and Ctrl-Q in TT_B..
It works, it stops (S) and it resumes (Q) the receving in TT_B.
Did it 3x and got Blue screen with "DPC WATCHDOG VIOLATION".

Restarted and installed TT 4.105.
The same as above, the second Blue screen in last 15 years perhaps

Restarted and looked at the FTDI drivers - both drivers from Jan 8th 2013 (installed by the Win10 automatically, btw).
EDIT: my Win10 image was from 2018 upgraded to latest couple days back, so the old buggy driver comes from that 2018 image, imho..

Installed latest FTDI drivers manually.
Restarted and tried again (TT 4.105).
The Ctrl-S and Ctrl_Q work.

Set 921k8N1, and it still works..

While looking at the FTDI VCP drivers release notes - the xon/xoff bug was fixed in 2013
So, perhaps those chips work..

[m k]

Some DEC controllers had serial ports connecting only Tx, Rx and GND.
Then ReGIS was also a thing.

One other thing is communication cable length.
Hardware handshake is a constant signal level.

Back in the day handshaking was also "very close" to actual transmission line.
For graphics functions there were different MCUs.

Speed has nothing to do with handshaking per se, but 1/92k seconds for a character is not a very long time.
And being a single character to the other direction is counter intuitive, even that the speed is actually pretty slow.

[BrianHG]

Careful trying to use an FTDI com port with synchronous handshaking.  If the FTDI is transmitting, what you send to it during this time must be synced/framed with what you are receiving, otherwise, it may drop the first character you send in return.

It's been a decade since I played with this, but, a good test is to wire 2 PC, you master who has x-on/x-off enabled null modem wired to a second PC with a dumb terminal in 8N1 mode.  See if you can get you master to pause sending the ascii text on the second dumb terminal with while sending the control codes.

If the 2 PCs work, then your UART in the peripheral you are designing isn't generating a properly 'famed' TXD output and your X-on/X-off handshaking transmission is being ignored.


If you are using a homemade cheap public domain FPGA UART HDL, you will need to use something like my FPGA Synchronous UART to prevent this sync bug when attempting realtime handshaking.

[nctnico]

Xon/xoff are normal ASCII characters (DC1 and DC3) and send as part of the regular data. If a UART isn't handling those, then the UART won't work at all.

[PlainName]

Don't know about Xon/off availability but are you in control of the protocol? If so, take a leaf from TCP and implement a sliding window of appropriate buffer size. Or use Zmodem if you want a ready-rolled protocol.

[Bicurico]

Xon/xoff is/was heavily used by CNC machines when using the DNC protocol, which basically sends a big NC program to the CNC controller, for direct execution, because the controllers memory is smaller than the program to execute.

Most USB Serial port adapters do not work for this task, which is why companies still using DNC rely on old computers with a proper serial port.

Also, xon/xoff can be implemented by software using the two mentioned characters or by means of, if I remember correctly, pin 4 and 5 on DB25. This not support by most USB adapters, either.

The reason you need the hardware and/or driver handle xon/xoff is because this is toggled in regards of the buffer.

If you are stuck with a USB serial interface, your best bet is to reduce the baud rate so that you don't need xon/off.

[nctnico]

Don't know about Xon/off availability but are you in control of the protocol? If so, take a leaf from TCP and implement a sliding window of appropriate buffer size. Or use Zmodem if you want a ready-rolled protocol.

I have used Xmodem instead at the cost of quite a bit of extra code. I need things to work with any reasonable standard terminal emulator for simplicity.

[IanB]

I have used Xmodem instead at the cost of quite a bit of extra code. I need things to work with any reasonable standard terminal emulator for simplicity.

While reading through this thread, I never quite got to understand the application.

If I understood correctly there is some piece of bespoke hardware ("board") with a serial port, and it uses this to communicate with a user via a terminal or terminal emulator? But then you say that large amounts of text are involved. Does that imply upload/download operations to the device, or is it simply that the device sends vast amounts of data to the display (terminal or terminal emulator), which is faster than the terminal can keep up with? And you want flow control so that the screen doesn't glitch?

Which hardware do you have control over? Is the board a black box from a third party, or is it a board you have designed/implemented? And is the flow control required by the display terminal, by the board, or by both?

I know you said you have reached a resolution, but it was hard to follow where the problem exists. Like, does the terminal end send XOFF to the board to stop sending, but the board does not respond to the XOFF character? Or the board responds to XOFF/ON when it receives them, but the terminal does not send them?

And the question of RTS/CTS hardware flow control did not get much discussion.

At the end of the day, I don't think the terminal emulator is meant to do flow control. I think the terminal emulator program is supposed to configure the serial port with the right settings, and the serial port driver is meant to do the heavy lifting.

[IanB]

I did a quick search of Windows documentation on serial ports. I found this (link below):

A COM port controlled by Serial.sys is assigned a device name. A user-mode application can open this port by name, and then send I/O requests directly to the port.

...

Another difference is that Serial.sys implements software flow control, but Sercx2.sys does not. Both Serial.sys and Sercx2.sys support hardware flow control using the request to send (RTS) and clear to send (CTS) signals. For more information about flow control, see SERIAL_HANDFLOW.

Note that Serial.sys is intended for use with COM ports by terminal emulators and similar applications. Sercx2.sys is intended for high speed, point-to-point connections on circuit boards in hardware.

A terminal emulator using Serial.sys should be able to use the Windows API to configure the COM port with the required settings, including which flow control to use.

If it is a virtual COM port provided by a USB adapter, then it will depend on the features of that device. But the common hardware signals were provided on a USB serial adapter I have used.

[nctnico]

I have used Xmodem instead at the cost of quite a bit of extra code. I need things to work with any reasonable standard terminal emulator for simplicity.

While reading through this thread, I never quite got to understand the application.

If I understood correctly there is some piece of bespoke hardware ("board") with a serial port, and it uses this to communicate with a user via a terminal or terminal emulator? But then you say that large amounts of text are involved. Does that imply upload/download operations to the device, or is it simply that the device sends vast amounts of data to the display (terminal or terminal emulator), which is faster than the terminal can keep up with? And you want flow control so that the screen doesn't glitch?

The problem is not the board but the PC with the terminal emulator. The PC sends a large amount of text to the board. But the board can't keep up due to writing the text to flash. So as there is no way to implement hardware flow control, my idea was to use software flow control (xon/xoff). Only to find out the implementation of software flow control at the PC side is not guaranteed at all (which is the problem) so I needed a different solution (like Xmodem).

[pqass]

There is the Linux pv command (-L switch) that will rate limit a byte stream through a pipe.  Whenever you need to send a file, call a script that cats your file through pv and appends to the tty.

However, I think using XMODEM is probably the better way to go because there is inevitably a missing/bad byte every few K of data sent over RS232.  Simple and dumb XMODEM protocol has the advantage of small packets (132 bytes) with no sliding window so should give acceptable throughput over a low-latency link (host to board separated by meters).  A one byte checksum is still better than none but you might want to look at backward compatible XMODEM-CRC for extra protection.

[BrianHG]

One thing about FTDI USB converters, I did a project a few years back and flooding the transmit buffer with more than 2048 bytes could drop bytes even with hardware handshaking.  Even though the FTDI drivers supposed to have 4096 byte FIFOs.

One pacing method I used was a simple delayed echo, though depending on how you handle this, you can cut your bandwidth in half.  But logic wize, this used the least amount of cells in my FPGA handling the IO and still offered data verification.

[IanB]

The problem is not the board but the PC with the terminal emulator. The PC sends a large amount of text to the board. But the board can't keep up due to writing the text to flash. So as there is no way to implement hardware flow control, my idea was to use software flow control (xon/xoff). Only to find out the implementation of software flow control at the PC side is not guaranteed at all (which is the problem) so I needed a different solution (like Xmodem).

OK, that is clearer. But terminal emulators only send data as fast as someone can type, so that should not be a problem. Therefore, perhaps we are considering a file upload situation?

It seems if you want a reliable solution, you should have control over the PC side of things. Perhaps by writing bespoke software or defining the software to be used, and by requiring the use of validated hardware?

Also, if the board can't keep up with the incoming data, and the board does not have hardware flow control enabled, that would seem like a problem with the board.

[Andy Chee]

But terminal emulators only send data as fast as someone can type, so that should not be a problem. Therefore, perhaps we are considering a file upload situation?

Most terminal emulators are now able to "cut & paste" text directly into the window.  So it cannot be strictly called a file upload situation, but it is actually the equivalent of someone typing extremely fast into the terminal buffer.

(Reminds me of the Stargate SG-1 episode Upgrades, where Samantha Carter speed types several scientific papers, having a break now and then to allow the computer keyboard buffer to empty)