Receiving serial port data in Windows not working properly without PuTTY?
-
Hi! First time poster and first time working with QT.
I've spent the past few weeks working on an app that integrates with an Arduino-based microcontroller - specifically the Raspberry Pi Pico, as well as a related board using the same RP2040 MCU - using the USB serial. Since I daily drive Linux, I wasn't really having any issues with it; and at the moment with the design and code being at a point where I thought it was essentially finished, I thought I could publish and deploy it.
But since the majority of my intended userbase is likely to be running Windows, I figured I would build for it too (in Windows 10 22H2) and test it there.
Unfortunately, the serial port functionality seemed to half-work; sending is fine, because the board responds visually when it receives an initial command upon connection. But the receipt times out (I'm using
.waitForReadyRead()
primarily).I figured, before I jump to conclusions, I at least try the built in Terminal example program if I have any more luck there.
Sure enough, same exact issue: I get no response, even though it's connected to the right port with the right baud rate. Truly baffling, as this same code/same QT version works perfectly in the Linux deployment!In an effort to rule out Windows/the board itself, I installed PuTTY to use as a serial terminal. But in there, I get all the expected outputs from the microcontroller. And then, and only after opening up a terminal in PuTTY, when I go back to run either my code or the Terminal example, it happens to work. I've been able to consistently reproduce this.
I also found an older topic on the subject, seeming to have come to the exact same conclusion: serial reading only works on Windows after running PuTTY and connecting it to the device beforehand.
Re: Sending data to serialInteresting to note, they are also trying to communicate with a Raspberry Pi Pico (or RP2040 board)--fwiw, the code loaded onto my boards are Arduino sketches using Earle Philhower's native core. Both the board's setting and my own in code/in Terminal example are 9600 baud/data8/1stop/noParity/noFlow.
EDIT: And to clarify, I've observed this when building with 5.15.2 (MinGW/MSVC2019) and 6.6.2 (just MSCV2019).
-
Hi and welcome to devnet,
One thing that comes from ancient foggy memory, so I am not sure is related, but: did you try to set the dataTerminalReady property on the port once opened ?
-
Hi and welcome to devnet,
One thing that comes from ancient foggy memory, so I am not sure is related, but: did you try to set the dataTerminalReady property on the port once opened ?
@SGaist I recall trying setting dataTerminalReady before opening the port, though not after.
That's on me for not realizing it doesn't work until after the port's opened.Sure enough, setting that does allow the code to work without any other modifications. I'm guessing either Windows is a bit more stringent, or Linux is the one implicitly setting that flag?
Thank you very much for the clarification!
-
S SGaist has marked this topic as solved on
-
@SGaist I recall trying setting dataTerminalReady before opening the port, though not after.
That's on me for not realizing it doesn't work until after the port's opened.Sure enough, setting that does allow the code to work without any other modifications. I'm guessing either Windows is a bit more stringent, or Linux is the one implicitly setting that flag?
Thank you very much for the clarification!
@That-One-Seong I don't know the low level differences between Windows and Linux serial port handling. It could be a driver thing or simply the default behaviour of the OS.