Testing serial_ftdi.c for various FTDI chip based divecomputers
jef at libdivecomputer.org
Wed Jun 11 07:00:01 PDT 2014
On 2014-06-07 10:44, Venkatesh Shukla wrote:
> On Sat, Jun 7, 2014 at 11:39 AM, Jef Driesen <jef at libdivecomputer.org>
>> Another thing we'll have to address some way or another is the
>> in arguments in the normal and ftdi serial implementations. The first
>> accepts a filename, while the latter will probably end up accepting a
>> VID/PID (or whatever, but certainly not a filename).
> Agreed. I think it should be PID. Currently it ignores the filename.
> you do not need to provide path when running universal. ( ./universal
> name -b backend -d dives.xml is enough). serial_ftdi.c t loops over all
> accepted PIDs to find if any of them matches.
I was actually thinking about a more generic solution.
Ideally there should not only be a ftdi driver, but also one for each of
the other usb-serial chipsets (pl2303, cp210x, cdc-acm, etc). Somehow
libdivecomputer (or the application) will have to figure out which
driver to use. For some devices there can be multiple options (e.g. for
Suunto there are several interfaces on the market with different
And once we have a native bluetooth backend, then that one will probably
need some completely different parameters (e.g. 48bit bluetooth
address). Thus neither a filename or PID won't work. On top of that, I
can imagine that if you build libdivecomputer without bluetooth support
enabled, we may want to fall back to serial communication. But that
means the dive computer backend's open function will have to accept
either a bluetooth address or a serial port name.
So we need a more general solution here.
More information about the subsurface