On 2017-09-11 17:21, John Van Ostrand wrote:
On Mon, Sep 11, 2017 at 11:13 AM, Jef Driesen jef@libdivecomputer.org wrote:
If you change the baudrate while data is arriving, then it might be that some data was still read with the old baudrate (because it was already sitting in the driver receive queue).
That's what I thought, but a flush after the baud rate change didn't seem to make it less likely.
Maybe it works better when you purge the buffers before doing the break? And for the heartbeat you could try to use a small loop where you discard invalid heartbeat bytes, until you receive a good one.
With fatal errors, I was referring to errors reported by operating system and/or driver. If for example the write call fails because the connection is down (usb cable unplugged, bluetooth connection lost) or some other serious I/O error happened, then there is no point in retrying. In that case you want to bailout as soon as possible. Typically only for errors at the communication protocol level (e.g. timeouts, corrupt data packets, etc) retrying helps. Those correspond to the DC_STATUS_TIMEOUT and DC_STATUS_PROTOCOL error codes. Everything else is pretty much fatal.
Ahh, I see it now. That commit should work fine.
Patches have been pushed.
Jef