On 2014-06-07 10:44, Venkatesh Shukla wrote:
On Sat, Jun 7, 2014 at 11:39 AM, Jef Driesen <[email protected]>
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).
Agreed. I think it should be PID. Currently it ignores the filename.
Hence
you do not need to provide path when running universal. ( ./universal
-n
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
chipsets).
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.
Jef
_______________________________________________
subsurface mailing list
[email protected]
http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
