A serial terminal for Linux with working XON/XOFF?

A project log for eForth for cheap STM8S gadgets

Turn cheap modules from AliExpress into interactive development kits!

ThomasThomas 11/12/2016 at 21:167 Comments

I've been adding XON/OFF (or rather vice versa) to STM8EF. In theory it should work like this:

After receiving CR the eForth sends XOFF (0x13), the interpreter starts processing, some text followed by a LF gets written to the serial interface, and then XON (0x11) is sent to indicate that the next line can be received and processed.

In practice all the Linux terminals I tested are based on the termios layer which apparently doesn't stop transmission after receiving XOFF.

Edit2: I traced the problem through picoterm, stty/termios, line-discipline, and all the driver levels down to the device driver (e.g. 8250, or CH341). The short version is that there is no such thing as "flow control" in any USB-serial adapter based on USB-serial. The long version is here in the 5th post.

Edit: I'm getting somewhere. A discussion of the problem is here.

I'm at it. Stay tuned :-)


Eric Hertz wrote 07/15/2022 at 10:52 point

Just ran into this problem, myself... Thank you for posting this and all your research at the link.

  Are you sure? yes | no

Thomas wrote 07/16/2022 at 15:10 point

You're welcome :-)

In the meantime my analysis somehow made it into the Linux Kernel Bugzilla:

  Are you sure? yes | no

Eric Hertz wrote 07/17/2022 at 04:41 point

Nicely done. Great to see hard work like yours serve to benefit folk like us ;)

  Are you sure? yes | no

Thomas wrote 11/13/2016 at 11:35 point

Post updated. I've found some rather surprising answers that might help to bust a myth or two about low-level serial communication in Linux.

  Are you sure? yes | no

Thomas wrote 11/12/2016 at 22:04 point

Hi K.C., thanks for your reply!

I first thought that the FIFO might be the culprit, and I tested the behavior with different amount of CR delay, but even with 9600 baud and empty FIFO typed characters get through when the line state should be "stop". I'm currently discussing the issue with one of the guys behind CuteCom.

I've also been thinking about synchronous operation (send some text, wait for an ACK, send the next chunk of text), but there are few serial terminals that support this (e.g. gtkterm). If everything else fails I'll write some kind of "synchronous uploader" (e.g. a hacked

EDIT: reading some docs helps when one is dealing with legacy stuff like serial terminals. The key is indeed TERMIOS, and the serial terminal programs I checked are doing it wrong. The question now is if I need to address the XONXOFF problem at the serial terminal program level or if I should better write a "synchronous uploader" that works in "canonical mode". Essential reading is here:

EDIT2: K.C., I checked your reference to termcap: this isn't the right layer for solving this issue, and time compensation is also not a good way for dealing with it (-> ). It's like drugs: wrong is wrong even if everyone is doing it ;-)

  Are you sure? yes | no

K.C. Lee wrote 11/12/2016 at 21:43 point

Modern day UART has deep FIFO, so the earliest time host software *could* stop is after the FIFO is emptied.  That's assuming if the Linux terminal software even bother.

There are newline delay setting in termcap.  Not sure if that would help by modifying one by adding delays.  (I don't do Linux.)  Other trick is to use a very slow baud rate, so that the carriage return could buy you enough time for processing.

On some Windows terminals, they have user programmable delays after CR for ASCII upload.

  Are you sure? yes | no

Thomas wrote 08/13/2022 at 09:56 point

A delay for fixing communication is, by design, a race condition. When there is a very high degree of confidence in the duration of process this may be indistinguishable from an asynchronous protocol design. Until something changes, that is.

  Are you sure? yes | no