search

WICG / serial

Serial ports API for the platform.
https://wicg.github.io/serial/
Other
255 stars 46 forks source link

Specify default DTR and RTS output states #177

Open codembed opened 1 year ago

codembed commented 1 year ago

What is the default state for these pins after a call to open ?

On Windows, it seems that DTR and RTS assert on open. In some cases, automatically asserting these is not desirable.

In my experience, some serial port drivers leave these pins in the state set by a previous OS handle. Perhaps other drivers or APIs always set a default state (which is not always asserted)?

If possible, it would be nice to have consistency over all platforms.

My preference would be for DTR and RTS to be unmodified by open. However, this can be problematic as there is currently no function to get the existing state of these outputs. In addition, setSignals is not permitted before the port is opened.

Please discuss one the following enhancements:

  1. open will not modify signals states, and setSignals will return the existing/modified signal states in its Promise, and will support no parameter, so that setSignals({}) or setSignals() will return the current states - unmodified.

or,

  1. Add optional signals parameters to the SerialOptions dictionary to allow these signals to be set synchronously when the port is opened. In some cases, this would prevent glitches in the signals between calls to open and setSignals.

I prefer 1, but I suppose this is considered a 'breaking' change. Having a way to retrieve the current output states would be good!

If neither implementation is practical, it would be good to at least have the default states specified in the standard.

It seems that close will leave DTR and RTS in their current state. I'm okay with that.

reillyeon commented 1 year ago

In this message I'm referring to the Windows APIs but I think similar issues exist on POSIX systems.

I don't think (1) is possible because the underlying OS APIs don't allow us to observe the state of the output signals. For example, there doesn't appear to be an equivalent to EscapeCommFunction() which returns the state of these signals rather than setting them. There also isn't an option which could be passed to CreateFile() when opening the port which prevents the driver from automatically setting the signal state.

Given that, the best we could achieve with (2) is to add the signal parameters to SerialOptions so that we can immediately call EscapeCommFunction() after CreateFile() so that, at best, signals like DTR are only asserted for a short time.

Am I missing something? Are there other serial APIs which enable the behavior you're looking for?