Sometimes it makes sense to intentionally disconnect a SerialProxy object and reconnect (e.g., to flash a firmware update). This is currently possible by terminating the serial thread via the SerialProxy.terminate() method and calling SerialProxy._connect(); however, it could be simplified.
For one, the serial parameters (port, baudrate, settling_time_s, and retry_count) could be cached so that in the case of a reconnect, the SerialProxy._connect() method uses the same parameters from the previously established connection.
Question: should caching these parameters also be the default after an unintentional loss of the serial connection? How does this work now? I think caching it makes sense for most of these parameters; however it is possible that the serial port may change between connections, so maybe we should be trying the previously established port first, and if that fails, try other ports.
Problem
Sometimes it makes sense to intentionally disconnect a SerialProxy object and reconnect (e.g., to flash a firmware update). This is currently possible by terminating the serial thread via the
SerialProxy.terminate()method and callingSerialProxy._connect(); however, it could be simplified.For one, the serial parameters (
port,baudrate,settling_time_s, andretry_count) could be cached so that in the case of a reconnect, theSerialProxy._connect()method uses the same parameters from the previously established connection.Question: should caching these parameters also be the default after an unintentional loss of the serial connection? How does this work now? I think caching it makes sense for most of these parameters; however it is possible that the serial port may change between connections, so maybe we should be trying the previously established port first, and if that fails, try other ports.