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

[John Van Ostrand]

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.

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.

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