Testing serial_ftdi.c for various FTDI chip based divecomputers
jef at libdivecomputer.org
Fri Jun 6 23:09:53 PDT 2014
On 07-06-14 05:59, Venkatesh Shukla wrote:
> I have prepared serial_ftdi.c for usage on android devices. It uses libftdi1
> for all communications with the dive computer. While building for android, this
> would be used instead of serial_posix.c I have been testing it on my system
> using Heinrichs Weikamp OSTC 3. As I do not have access to other ftdi based
> divecomputers, I could not thoroughly check my implementation.
> I am attaching universal binary which is compiled using serial_ftdi.c. If you
> have a divecomputer which uses ftdi chip, I would request you to test
> downloading of dives using this binary. For reference, the command would be like
> ./universal -b ostc3 -n 'Heinrichs Weikamp OSTC 3' -l import.log -d dives.xml
The only ftdi based devices I have available for testing myself are HW OSTC2 and
I didn't had time to review or try your work yet, but it's on my todo list. Is
the serial_ftdi.c you used to compile the same as in your libdivecomputer github
Note: I can produce Windows and Mac OS X binaries if someone needs them.
> Do note, the above binary only takes in account PIDs 0x6001, 0x6010 and 0x6011.
Several manufacturers (Suunto, Oceanic, et) use custom VID/PID's. I suggest you
add those as well, to increase your pool of potential testers. I maintain an
(incomplete) overview with the known VID/PID's here:
> If this works, then the only link remaining to enable download of dives on
> android would be getting permission from user using it to access the device. I
> have tested the script on android emulator as a root user. It works perfectly.
> But the same thing should be possible without root access. I am facing some
> difficulty in this regard. I'll let you know as soon as I resolve it.
Another thing we'll have to address some way or another is the difference in
arguments in the normal and ftdi serial implementations. The first one accepts a
filename, while the latter will probably end up accepting a VID/PID (or
whatever, but certainly not a filename).
More information about the subsurface