[GSoC] Week 3 (Native Bluetooth support)

[Jef Driesen]

On 2015-06-15 13:46, Anton Lundin wrote:
> On 15 June, 2015 - Claudiu Olteanu wrote:
> 
>> Ok. In the beginning I will try to implement the downloading
>> entirely in Subsurface and re-implement the dive computer
>> protocol for HW OSTC family.
>> 
> 
> I think this is a bad path.
> 
> I would rather suggest something like implementing a "serial" backend 
> in
> libdivecomputer which takes a Qt5-Bluetooth-thingie to work with.
> 
> 
> The same thoughts have bin about having libftdi-"serial"-backends and
> cdc-"serial"-backends to support platforms where kernel-drivers for
> those aren't a option (Android).
> 
> 
> This is rather a puck for Jef to think about how a dc_device_open
> version which passes on parameters for different backends.
> 
> I could see a dc_device_open which takes something else than just a
> "const char *name", rather a dc_serial_type_t, and a void *arg.
> 
> I could see something like a dc_serial_type_t SERIAL which takes a
> regular char* and is implemented with the regular serial.c backend, and
> a QT5_BLUETOOTH, which gets a Qt-bluetooth-object-thingie, and a FTDI
> which gets the correct args for a ftdi_usb_open to succeed.

I did already think about this :-) See [1] for some more background 
info.

In a nutshell, the serial layer will be changed from a concrete 
implementation into an abstract interface. This will allow us to have 
multiple implementations: native (using kernel drivers), bluetooth 
(using rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc

Instead of passing a device name to the dc_device_open() function, the 
application will first need to create an instance of one of those serial 
backends (with the appropriate parameters), and pass that one:

dc_serial_t *serial = NULL;
dc_device_t *device = NULL;

/* Open the low-level communication transport. */
dc_serial_native_open(&serial, devname);
dc_serial_rfcomm_open(&serial, address, channel);
dc_serial_usbserial_open(&serial, vid, pid);

/* Connect to the dive computer. */
dc_device_open(&device, ..., serial);

/* Do something useful here. */

/* Close the connection. */
dc_device_close(device);
dc_serial_close(serial);


Although this will clearly require some extra code on the application 
side, there are other advantages too. For example it will be possible to 
expose functions for device enumeration. The code is already there, but 
applications can't use it, because the serial layer is a completely 
private api.

[1] http://libdivecomputer.org/pipermail/devel/2014-June/000305.html

Jef