Handling parity errors and timeouts at the same time

[CrazyRobMiles]

I'm writing a program that runs in the browser and downloads binary firmware into an embedded device connected via a serial port. As part of the process I do a hardware reset on the device with the signals arranged in such a way as to force a reboot into firmware download mode. This works fine, but the action generates parity (and sometimes buffer overrun) errors on the serial connection. Plus, I'd like to be able to respond sensibly if the device does not respond because the usb interface doesn't support the signals or it is the wrong kind of device.

I've found it pretty much impossible to make anything work using the present stream based design. I've found the discussions on read timeouts very useful, but if a parity error occurs while the code is waiting it throws exceptions that are very hard to untangle so that the read process can get back to a known good state and continue. I can't close and open the serial port because this would reset the target device into the wrong mode.

I'd love to have some hints from someone who knows about these things on the best way to handle this.

[reillyeon]

A link to your code where you've been trying to work through these issues would be helpful.

Closing and reopening the port isn't necessary to handle a parity or buffer overrun error. When an error is encountered while reading the ReadableStream returned by the readable attribute is put into an errored state and a new one is created the next time the attribute is accessed. This new stream can be used to continue to read from the device. This is why in Example 4 the code snippet starts with a loop checking that port.readable is not null. As long as the browser believes that the port hasn't encountered a fatal error (e.g. the port is provided by a USB device that has been unplugged) it will keep returning new streams so that the site can continue to read after handling an error.

As discussed in #122, timeouts are something that need to be handled at a layer above the stream because we don't support canceling a read() without also erroring the stream. This is being discussed in whatwg/streams#1103 but isn't strictly necessary to make your code work because it is possible to write a wrapper around read() that allows cancellation either by discarding any data that is received after the timeout or enqueuing it for later.

[reillyeon]

Closing this issue due to lack of activity. Discussion of timeouts continues on the referenced issues.