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

[John Van Ostrand]

On Mon, Sep 11, 2017 at 11:13 AM, Jef Driesen <jef at libdivecomputer.org>
wrote:

> 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 b3d2c603ddec9758fb36706bbde46c
>>> e23ca9f0ed)
>>> 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).
>
>
That's what I thought, but a flush after the baud rate change didn't seem
to make it less likely.


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


-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20170911/0f7e9b86/attachment-0001.html>