RTS being set high on port connection

[Faller9249]

I'm using the API to make a connection with a UART to USB adapter, the CP2102, and everytime I make a fresh connection with it, by fresh I mean disconnecting the USB cable entirely, the RTS(Request To Send) pin gets set high, even with flowcontrol disabled(set to 'none'), and that is a very big problem for me as the RTS pin of the chip is being used for a very important purpose and this kind of behavior isn't very suited for our application. The code for the actual application is proprietary to the company I work at, but below is a simple code that has the same problem.

Connect with Serial Device

9600 19200 38400 57600 115200 230400 460800 500000 921600 1000000 Get serial messages

I've tested a couple of things already:

• calling the setSignals() method before and after the open() method
• calling the setSignals() method with requestToSend as true and false, dataTerminalReady as well just to be sure
• setting flowcontrol to 'none' and to 'hardware'
• making the code synchronous instead of asynchronous

I don't know if I'm missing some critical piece of code or if I'm using something wrong. I've even tried reading the Blink implementation C code to try and understand if there was a problem in the abstraction layers or something like that.

[reillyeon]

Assuming you are on Windows then the code in SerialIoHandlerWin::ConfigurePortImpl() is relevant here. If hardware flow control is disabled then the DCB structure is configured with both RTS_CONTROL_ENABLE and DTR_CONTROL_ENABLE. This means the default state of these two control signals is high.

It should be possible to lower them after opening the port with setSignals({ dataTerminalReady: false, requestToSend: false }) but this isn't helpful if the device responds poorly to any high state of the RTS line. Have you been able to lower the RTS signal in this way? It isn't clear from your report.

The two solutions to fix this at an API level would be to support calling setSignals() before open(), or add signals property to the options dictionary which can include dataTerminalReady and requestToSend options. We will need to check that the macOS and Linux implementations are also capable of setting the initial value of these signals the way the Windows implementation is.

[Faller9249]

About the second paragraph, I did test setting it right after the open method, but as you said, our device is affected by any alteration in the RTS line. What you suggested in the third paragraph would be ideal, as we have tested with the electron-serialport library on node.js running locally and if we had a way to set the RTS upon opening the port, that would be perfect. But my main concern with an API level change would be whether or not this change would be easy to dissipate for users of our application.

[reillyeon]

An API-level change would need to be specified and implemented before it could roll out to your users. Unfortunately it seems like there isn't any workaround given the current API design.

[Faller9249]

Do you if there is another option of API or is this one really the only one we can use on web browsers? I know the answer is probably no, but we really needed to solve this ASAP.

[reillyeon]

After doing a bit more research it looks like setting the initial RTS and DTR state is only supported on Windows. macOS and Linux systems will always assert these pins when the port is opened. At best this means that if we implemented the option to control the signal state when the port is opened the lines would flash briefly into the high state before being reset during initial port configuration.

I recommend working with your hardware vendor to not reuse the RTS line for an unintended purpose.