add optional parameter signalOptions to open about web-serial-polyfill HOT 2 CLOSED

As I explained in my response to the Chromium issue you filed, from my research the serial port drivers included with most operating systems automatically assert the DTR signal when the port is opened by an application and release it when the port is closed. The behavior of this polyfill library, since it attempts to duplicate what both the browser and operating system do, is to do the same. However unlike in Chromium, since this library is taking over the role of the USB device driver, it can choose to work differently.

This needs to be done carefully to avoid deviating too much from the interface specified by the Web Serial API. The best option seems to be to extend the SerialPolyfillOptions dictionary that is passed to requestPort() to include an option for controlling this behavior.

Edited to add: My recollection is that some sketches will not start executing until the DTR signal is asserted and it is possible that the Arduino serial API itself won't start sending data until the connected system asserts that it is ready (which is what DTR means). As I recommended in the Chromium issue, based on similar questions asked on the Arduino forums, I think the best workaround for this behavior is to use one of the other UARTs available on the Arduino instead of the one used for programming which has the DTR-reset behavior.

from web-serial-polyfill.

Yes you are right, after digging into this some more and writing some native programs for Windows and Debian I found out that I can only make this work after the arduino's port was opened at least once (resetting on first open) without unplugging which defeats the hole point. So scrap, but it was worth a try. Knowing that it just behaves this way is not necessarily a bad thing after all. Thank you for the inisghts and these great projects you are working on (serial>blink and polyfill) 😎. I think the possibilites of this combined with pwa are really great.

from web-serial-polyfill.