[PATCH] Cochran: Changed communication parameter to work better with FTDI.

[Jef Driesen]

On 2017-09-11 17:21, John Van Ostrand wrote:
> On Mon, Sep 11, 2017 at 11:13 AM, Jef Driesen <jef at 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