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 Comments
Leave a Reply. |