Testing serial_ftdi.c for various FTDI chip based divecomputers

[Jef Driesen]

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 
>> 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