Testing ftdi code
Anton Lundin
glance at acc.umu.se
Mon Oct 31 13:01:07 PDT 2016
On 31 October, 2016 - Willem Ferguson wrote:
> On 31/10/2016 14:29, Anton Lundin wrote:
> >On 31 October, 2016 - Anton Lundin wrote:
> >
> >>On 31 October, 2016 - Willem Ferguson wrote:
> >>
> >>>On 11/10/2016 14:18, Anton Lundin wrote:
> >>>>>On 18/09/2016 10:48, Anton Lundin wrote:
> >>>>>>After the last round of custom serial rewrite, the ftdi custom serial
> >>>>>>code now can be used with all libdivecomputer backends, and not just
> >>>>>>OSTC3.
> >>>>>>
> >>>>>>3. Plug in your ftdi device/cable and chown the usb character device
> >>>>>>your test user. lsusb will give you bus / device and the device is found
> >>>>>>at /dev/bus/usb/$bus/$device . This can be automated with udev.
> >>>>>>
> >>>>>>
> >>>>>>//Anton
> >>>>>>
> >>>Anton,
> >>>
> >>>Seems to work ok on my Ubuntu with Tusa IQ900 (equiv of Oceanic Atom2)
> >>>
> >>>One error message close to the beginning:
> >>>INFO: Flush: queue=3, input=0, output=-1
> >>>INFO: Wrote 2 bytes
> >>>INFO: Read 1 bytes
> >>>INFO: Read 17 bytes
> >>>INFO: Wrote 4 bytes
> >>>INFO: Sleep: value=1
> >>>INFO: Sleep: value=2
> >>>INFO: Sleep: value=4
> >>>INFO: Sleep: value=8
> >>>INFO: Sleep: value=16
> >>>INFO: Sleep: value=32
> >>>INFO: Sleep: value=64
> >>>INFO: Sleep: value=128
> >>>INFO: Sleep: value=256
> >>>INFO: Sleep: value=489
> >>>ERROR: FTDI read timed out.
> >>>[1.917694] ERROR: Failed to receive the answer. [in
> >>>../../src/oceanic_atom2.c:473 (oceanic_atom2_packet)]
> >>>INFO: Flush: queue=1, input=0, output=-1
> >>>INFO: Wrote 4 bytes
> >>>INFO: Sleep: value=1
> >>>
> >>>Dives load ok into memory and display ok within Subsurface, though.
> >>>
> >>Can you enable the libdivecomputer log too, and send me one?
> >>
> >I would love to have one log file from when you're using the
> >custom-serial-ftdi code path, and one where you're using the regular
> >in-kernel driver, to be able to compare. I guess there is some thing
> >missing somewhere.
> >
> Anton,
> I hope this is what you wanted. Attachment filenames self-explanatory.
> INFO: Open: name=/dev/ttyUSB0
> INFO: Configure: baudrate=38400, databits=8, parity=0, stopbits=0, flowcontrol=0
...
> INFO: Open: name=/dev/ttyUSB0
> INFO: Configure: baudrate=38400, databits=8, parity=0, stopbits=0, flowcontrol=0
...
I think you did some snafu there, and didn't capture a log file using
the ftdi driver? (or overwrote your log file...)
The ftdi log file should start with:
INFO: Open: name=ftdi
Anyhow. The same "error" shows up in these log files, so I'm confident
that this is just a quirk of the oceanic_atom2 protocol. There are quite
a bit of retry / error handling in the code so I don't think there is
anything to worry about.
I would love to see a real ftdi log from that computer anyway...
//Anton
--
Anton Lundin +46702-161604
More information about the subsurface
mailing list