I have a hardware device that was designed by another engineer. This engineer has tied the reset (MCLR) pin to the RTS pin on the UART chip we are using. Because of this, the serial communications cannot have any sort of RTS/CTS flow control.
I can mock this up using a simple terminal program by setting no CTS flow control, and RTS off.
If CTS OR RTS are on, it will hold the device in reset. With CTS and RTS off, I am able to send and receive bytes from the device without issue.
I have an otherwise working QSerialPort implementation that can talk to the device just fine when connected to the device debugger, because the device debugger holds MCLR high, preventing reset even if CTS and RTS go low ("on").
However, when using QSerialPort, even with flow control set to QSerialPort::NoFlowControl and with setRequestToSend(false) returning true following open(), somewhere along the way in the underlying QT code CTS or RTS are going low, triggering the device to reset.
The application is for Windows and Mac.
Can anyone shed some light on how CTS and RTS are handled behind the scenes in case something is not self evident? I have reviewed the platform-specific code and nothing obvious presented itself.
May have got it by setting:
I have this in various places to make sure anything underlying is not re-setting them. Narrowing down which are the important ones now.
I know before these were to be set prior to open, but now should follow open. Will post back if there is anything interesting here for others. I'll leave the thread as well in case anyone else is running into this.