Lars BrinkhoffMichael Gardi reported dropped characters, even though software flow control using XON and XOFF was enabled. As a heavy Emacs user, I abhor XON/XOFF since XOFF is the same as Control-S which is search in Emacs. But still if you enable it, it should certainly work!
Looking into this, true enough the VT100 does send an XOFF when it's being overwhelmed. But the remote side didn't seem to care about this and kept sending data to the terminal. Why that is, I don't know! My best guess at this point is that there may be a operating system buffer still emptying even though the host received the XOFF and stopped sending characters.
Rather than banging my head against that wall, I applied a quick band aid. The simulator will now intercept XON/XOFF internally and do the flow control. It's not pretty, but it seems to work. Maybe there will be a better solution in the future.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Just a guess: if the other side runs Linux and uses a USB serial interface then the analysis I once did might bring some clarity: https://github.com/neundorf/CuteCom/issues/22
Edit: my analysis was referenced and confirmed in the following Linux kernel.org ticket: https://bugzilla.kernel.org/show_bug.cgi?id=197109
Are you sure? yes | no
Thank you, that is interesting information. I'm mostly testing using a pty. When I type ^S/^Q manually something does react and does flow control. But when my simulator does it, I see in the logs that characters keep coming in. Hence my theory that the ^S is seen too late due to buffering.
I do have a USB serial interface, but no null modem so testing is restricted to typing on my VT220.
Are you sure? yes | no
During the last 30 years serial communication has certainly aged (and in some cases it didn't age well ;-) )
Are you sure? yes | no