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

[Jef Driesen]

On 2017-09-11 16:15, John Van Ostrand wrote:
> On Mon, Sep 11, 2017 at 5:22 AM, Jef Driesen <jef at libdivecomputer.org>
> wrote:
> 
>> On 2017-09-06 22:02, John Van Ostrand wrote:
>> 
>>> The parameters used with the FTDI USB serial port drivers didn't
>>> work well with directly with libftdi1. The new baud rate results
>>> in the same effective baud rates for both.
>>> 
>> 
>> What's the effective baudrate? Why don't you just use that effective
>> baudrate, instead of 850000? Now the baudrate change looks rather 
>> arbitrary
>> to me.
>> 
>> Other than that, the changes look good to me. For the retrying, I'll
>> restore the old retry function (see commit 
>> b3d2c603ddec9758fb36706bbde46ce23ca9f0ed)
>> because it handles fatal errors better.
> 
> I was working with FTDI to get mobile communications to work and 
> high-speed
> data was coming back with bit 7 set on all bytes. While I was tracking 
> that
> down I noticed that at the USB packet level the baud rate command was
> different, there was a different clock divisor for the custom baud 
> rate.
> Clearly the ftdi_sio kernel module that translates serial commands to 
> FTDI
> was translating baud differently than the libftdi1 library routines. I
> suspect either the logic is different or one of them is wrong about 
> which
> FTDI chip it's talking to. I didn't debug deeper than that.  I 
> translated
> the working divisor back to a baud rate which turned out to be
> 857,143 baud. I expect the actual baud rate is tied to the clock on the 
> CPU
> of the dive computer, we don't know what that is, so stating 857,143 as 
> the
> baud rate suggests accuracy. I figured 850,000 was within the 5% 
> required
> by the libftdi1 logic, visually more reasonable and about as wrong as
> 857,143.

This kind of info helps understanding the reason behind the change, so 
why not add it to the commit message? In a couple of months or years you 
probably won't remember either :-)

> I'll give that commit a try to see how it works. I know that one of the
> problems I was having was that after a baud rate change a heartbeat 
> byte
> would be received at the wrong baud rate and show up as a 0xFE, that's 
> the
> only case that is a permanent failure if we used that commit. I'm 
> starting
> to wonder if the serial flush command given to the FTDI chip is 
> working, or
> if the DC ignores the baud rate change some times.

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).

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.

Jef