ThomasI'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.
I'm at it. Stay tuned :-)
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Just ran into this problem, myself... Thank you for posting this and all your research at the link.
Are you sure? yes | no
You're welcome :-)
In the meantime my analysis somehow made it into the Linux Kernel Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=197109
Are you sure? yes | no
Nicely done. Great to see hard work like yours serve to benefit folk like us ;)
Are you sure? yes | no
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
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 miniterm.py).
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:
https://blog.nelhage.com/2009/12/a-brief-introduction-to-termios/
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 (-> https://en.wikipedia.org/wiki/Race_condition ). It's like drugs: wrong is wrong even if everyone is doing it ;-)
Are you sure? yes | no
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
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