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
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
