Serial, RTS, and DTR

[fivdi]

The set method of class Serial controls the value of the RTS and DTR pins. If RTS and DTR are supported, I would expect the Serial constructor options object to support rts, cts, dtr and dsr properties for specifying the corresponding pins but this doesn't appear to be the case.

[phoddie]

You are correct that there is no way to set RTS and DTR in the constructor. I'm curious why you expect that.

As background, there is precedent for those being separate from the constructor:

• POSIX open doesn't specify those. It is done using an ioctl.
• Windows CreateFile doesn't either. It uses EscapeCommFunction.
• The experimental Web Serial JavaScript API in Chrome doesn't set those in the constructor (at least as far as I can find) but defers those to setSignals.

If I understand well, CTS and DSR are inputs. Web Serial retrieves them using getSignals, for example. If my understanding is correct (and serial is such a complex world due to its long history, I could easily be wrong!), then these wouldn't apply to the constructor.

[fivdi]

The goal is not to set the value of RTS and DTR output pins. The goal is to specify, with Pin specifiers, which pins are used for RTS, CTS, DTR and DSR. I would expect this to be possible in the constructor because this is where the Pin specifiers for TX and RX are specified.

[phoddie]

@fivdi - my misunderstanding. Thank you. Yes, that makes sense. The API style is to use full names, so borrowing from Web Serial, those could be:

• dataTerminalReady
• requestToSend
• clearToSend
• dataSetReady

The current draft only uses DTR and RTS. We could reserve the other two names, as we did with parity. stop, and data.

[phoddie]

@fivdi, I committed changes to address your comments above. Unfortunately, I put the wrong issue number... here's the commit.

[fivdi]

While the changes are almost certainly formally correct I'm still a little puzzled. As you mention above, serial is such a complex world due to its long history.

I may also be making assumptions that I shouldn't be making. As an example, I'm assuming that RTS can be used for flow control. However, I don't know if it's correct to make this assumption as there is no mention of flow control in the specification.

Assuming that RTS can be used for control flow, if the RTS pin is asserted then the corresponding UART is ready to receive data. However, RTS is only one side of the story, the other side is CTS. I expect RTS on one piece of equipment to be connected to CTS on another piece of equipment. But the specifications only mentions supporting RTS today and this is what puzzles me.

Let say there are two MCUs and an implementation of the ECMAScript Modules for Embedded Systems is available for both MCUs. Can these MCUs communicate with each other via UART using RTS and CTS for flow control? My assumption here is that they can't as CTS is not available. This also puzzles me.

[phoddie]

The scope is broadening! We began with additional pin specifiers and are now on to flow control. Granted, the pins under discussion are typically used for flow control.

There are uses of RTS and DTR beyond flow control. For example, they are commonly used to program MCUs over serial – to restart the device and/or enter programming mode.

We can add flow control.

• define clearToSend and dataSetReadypins
• define the get method to return clearToSend and dataSetReady (parallels set)
• add optional flowControl property to the constructor's options object, using values of none and hardware (as in Web Serial)

Would that be sufficient?

[fivdi]

The scope is broadening! We began with additional pin specifiers and are now on to flow control. Granted, the pins under discussion are typically used for flow control.

There is need no need to broaden the scope if you don't think it's necessary. The problem here is that I misunderstood the scope by assuming that it included flow control. If you think it makes sense to add flow control then please do but don't add it because I misunderstood.

We can add flow control.

• define clearToSend and dataSetReady pins
• define the get method to return clearToSend and dataSetReady (parallels set)
• add optional flowControl property to the constructor's options object, using values of none and hardware (as in Web Serial)

Would that be sufficient?

I would say it is sufficient.

[phoddie]

I was referring to the scope of this GitHub issue. ;) There's no problem at all to include flow control.

I've committed the changes discussed. I also updated the property names used by set (and now get) to be consistent. That's an easier change to make today than it will be in the future.

Please let me know if these look reasonable. Thanks.

[fivdi]

Yes, this looks reasonable.

Some MCUs allow RTS flow control and CTS flow control to be enabled separately from one another. I'm not sure if the specification allows for this. I would assume it does because if flowControl is set to "hardware" and a requestToSend Pin specifier is specified but no clearToSend Pin specifier is specified, I would only expect RTS flow control to be enabled. Is this correct?

[phoddie]

Correct.

There is nothing in the specification text that requires both requestToSend and clearToSend to be provided, as there is no requirement that both transmit and receive be specified. An implementation may support the behavior you describe just as it may support a transmit only serial port.

[fivdi]

Nice. I guess this issue can be closed now.