![]() Interestingly, there are small voltage dips on the line from the Arduino (blue curve). When the port is opened, the signal line to the Arduino (yellow curve) is pulled low for a short time. The vertical spikes in both lines are the actual data transfers. The yellow curve is the signal transmitted to the Arduino, the blue curve is the signal from the Arduino. The following pictures all show the activity on these pins over a period of a few seconds. So, I connected an oscilloscope to the TX and RX pins of an Arduino Mega to see what is going on. I found that if I don't wait long enough, the connection also fails for the following transfers. I'd like to share some additional insight on this issue: Is, perhaps, the OS buffering serial input on the port, followed by pyserial opening it at that level and returning control to Python, while the OS then asynchronously starts dumping the contents of its own buffer into pyserial's input buffer? If so, can anyone explain, for curiosity's sake why we get just the oldest two bytes from that buffer when the other end has long disconnected, but a larger number of bytes when the other end is still present, even though there is no flow control turned on? Or more importantly, how to avoid getting leftover garbage in the response when I reopen a closed pyserial connection, write to it, and then read the response from the remote device? (my sleep() workaround is a cheesy and ultimately unreliable non-solution, it seems) 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |