-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with Software Flow Control #22
Comments
I went through the CuteCom source code, and apparently it's relying on flow control on the serial device layer. It's likely that the root cause is related to a bug in Debian, and the only thing CuteCom could do is work around the issue. Edit1: the problem might be rather intricate: http://linux-serial.vger.kernel.narkive.com/ufjVkd8J/serial-flow-control-appears-broken , and in this case the bottom line is that assumptions about flow control on the driver level have been invalid for a very long time. Edit2: here is something very similar: http://qubanshi.cc/questions/1900501/pyserial-xon-off-fails-on-linux-but-works-on-windows Question: did you test flow control (software or hardware), or did you rely on the device driver? |
Hi thanks for reporting this rather complex bug and your thorough investigation. |
Hi, thanks for the quick reply! In the meantime, something in my system has changed - it's a bit like chasing a phantom, but there seems to be something that can be addressed. I installed Qt Creator, and checked the behavior of the Terminal Example:
With
This was much more what I expected, except for the undesired result of the typing during transmission test. The Now I repeated the test with CuteCom 0.22 and 0.3x with the same result! I also tested However, in CuteCom (0.22 and 0.3x), miniterm.py, and in minicom, sending files still failed (which is consistent with the finding that all programs still send keys when XOFF is active. The conclusion is that on my machine Edit: Currently I'm looking in the direction of synchronous (or blocking) communication. Qt provides blocking master and blocking slave examples. The UNIX tty concept with "master-termios-slave" is explained here. |
After doing some experiments with
The bottom line is this: today a serial terminal program can either rely on on legacy hardware (e.g. @cyc1ingsir I'd be really interested in your thoughts! |
Issue moved to https://gitlab.com/cutecom/cutecom/issues/22 |
A related note. When using xon/xoff with small linux routers, I found the latency was up to as 20 chars (at 57k). This means your embedded device fifo must have 20 bytes free after the trigger point. I changed the rx fifo to 48bytes to be reliable. |
The project and hence the issue has moved. |
@cyc1ingsir it's really nice that you took the issue to the new platform but it's also a good thing that you left it here for reference. |
I'm reporting on neundorf/CuteCom 7da86b3 compiled on Ubuntu 14.04 using up-to date qt5-default and libqt5serialport5-dev.
In my use case, I need software flow control with XON/XOFF (DC1 0x11, DC3 0x13). After receiving CR the embedded device sends XOFF (0x13), does some processing, sends some text followed by a LF, and then sends XON (0x11) to indicate that the next line of text can be received and processed.
My expectation is that CuteCom stops sending characters in the interval between XOFF and XON, and that it hides the control characters, just like CR and LF, unless "Settings/Display Control Characters" is checked.
However, although I didn't check "Settings/Display Control Characters", CuteCom displays the hex values for DC1 and DC3:
Flow control as such doesn't appear to be working:
When I send a text file using the "script" feature, in the combined rendering of sent and received characters below, CuteCom sends the sequence ": dec -1" even after receiving a , causing an overrun:
My expectation is that CuteCom honors software flow control, and after receiving waits with sending new characters until has been received.
Please note that other communication programs, like MiniCom, show a similar behavior regarding the visibility of and . It's possible that "I'm doing it wrong" or that something in underlying communication layers is broken.
The text was updated successfully, but these errors were encountered: