search

tarm / serial

BSD 3-Clause "New" or "Revised" License
1.6k stars 453 forks source link

change parity on the fly? #52

Closed jcw closed 7 years ago

jcw commented 7 years ago

I'm trying to implement fimrware upload to STM32 microcontrollers for Windows, MacOS, and Linux using this package, which requires setting the serial port in even parity 8 bits mode. This can be done on open, but not on-the-fly, given the current API.

Would it be an option to add this capability? I can have a go at it - it'd be nice to know if a pull request has any chance of being considered.

I tried closing and re-opening the serial port as a workaround, but can't seem to close the port when there is a read pending in another goroutine.

UPDATE: a read timeout would let me close the port, but unfortunately it looks like a timeout is indistinguishable from an EOF due to a port disconnect, so this too seems to be a no-go.

tarm commented 7 years ago

I have a similar problem with a bootloader.

I don't think it would be right to change the baud rate while a read operation is occurring. That would cause a race condition and you would not know whether the data returned from the read was before or after the baud rate change (some bytes at different baud rates look valid at other baud rates depending on how the hardware samples the values). You should finish the read before changing the baud rate.

As you mentioned in the UPDATE, one way to force the read to finish and get a point to synchronize the code between goroutines is to use a read timeout. That is what I recommend and what I do for my bootloader 9600->faster transition.

I'm not sure what you mean by "EOF due to a port disconnect". As far as I know most serial hardware does not provide a way to determine a port disconnect. Unless you mean the whole module disappears (ie a USB<->serial cable gets unplugged at the USB side.

jcw commented 7 years ago

"EOF due to a port disconnect"

Yes, I meant an unplugged cable. It'd be useful to detect the difference between an unplugged cable (and possibly try to re-open the device periodically), and a timed-out read request.

Changing parameters mid-flight is not necessarily a problem: the upload process starts with a sync handshake, ignoring any characters left over from a previous session until they're in sync.

jcw commented 7 years ago

I'll close this issue. Feel free to re-open of course if you want to keep it around. I've switched to go.bug.st/serial.v1, which supports on-the-fly mode changes. Thanks for your response.