I suspect there is double-buffering occurring. In the process of creating a simple test-case, I discovered that the read() also does not work immediately after opening, and read() seemed like a test-case with a better signal-to-noise ratio (and/or wider understanding/adoption) for discussion than flushInput() - thus making it a better candidate for illustrating the issue. So I started with a flushInput() immediately after opening, which silently fails to actually flush the input buffer. I was attempting to read the response from a particular command, but it was often prepended with junk left-over from a previous session that didn't get cleared out. Such a scenario is actually what put me onto this problem. It only gets the first two bytes of what I had sent to it earlier, but only upon the second read() attempt. Then I run my Python test script that I posted in the first post here, on COM13, which is attached to COM12.
Then I answer an email to kill some time. Then I close TeraTerm, to ensure that it isn't simply buggy and waiting for some RTS signal or something from the other end.
Using TeraTerm, I send a handful of random characters, which I record for posterity.
To confirm, I opened a TeraTerm serial port on COM12 (with no flow control), which is connected to COM13. The issue discussed here involves writing to a serial port that is connected to another serial port, like in your case, but then going and having a cup of coffee, and then coming back and reading from the connected port immediately after opening it, but long after we know it has had ample opportunity to receive & buffer what we sent to it (much) earlier.
I'm not sure that is unexpected behavior. Your sample writes to one serial port, and then immediately tries to read that data from another, connected, serial port, without any delay between the write and the read. Thanks Riccardo, but what you did doesn't actually confirm that the issue at hand happens in Linux.
0 kommentar(er)
