[PATCH] libdivecomputer - custom implementation for serial communication

[Claudiu Olteanu]

Hello Jef,

Thanks for making time to let us know what you
have in mind for the next release. More or less it is
similar with the changes I made, except that I tried
to avoid to modify the native serial implementation.

I will make you a short resume about the changes
I did because I believe that there were too many
posts and it is not easy to keep the track.

The dc_serial_t structure is declared as:
struct dc_serial_t {
serial_t *port; //serial device port
dc_transport_t type; //the type of the transport (USB, SERIAL, IRDA,
BLUETOOTH)
void *data; //specific data for serial device
const dc_serial_operations_t *ops; //reference to a custom set of operations
} dc_serial_t;

As you can see, the only difference is that I
added a new member (dc_transport_type).
I thought that this can be used to identify the
type of the transport and to do some specific
operations if they are needed.
Also I used a pointer member for serial_t.
Dirk suggested to remove the pointer but
it was easier for me to use it :).

I choose to represent all functions which are
used for the communication and may need
a custom implementation, depending on the
protocol used (Bluetooth, IRDA, etc).

The dc_serial_operations_t is:
struct dc_serial_operations_t
{
int (*open) (serial_t **device, dc_context_t *context, const char *name);
int (*close) (serial_t *device);
int (*read) (serial_t *device, void* data, unsigned int size);
int (*write) (serial_t *device, const void* data, unsigned int size);
int (*flush) (serial_t *device, int queue);
int (*get_received) (serial_t *device);
int (*get_transmitted) (serial_t *device);
} dc_serial_operations_t;

As I said, I tried to avoid modifications on
native serial implementation. Therefore I used
the same signatures for needed functions.

I preferred to do that because I wanted to keep
backwards compatibility and to do as few changes
as possible. So I created a dc_device_custom_open
method where the application  can pass a reference
to a dc_serial_t structure.

Also I added a dc_serial_native_open which
creates a dc_serial_t structure for the
native serial implementation. In this way I could
use it in the DEVICE_FAMILY_device_open
method and maintain the backwards compatibility.

It is obvious that you have a clear idea about
how the libdivecomputer API should look
like and which are the things that need to be
refactored/cleaned.

I would definitely like to help you (now or later).

Dirk, Thiago, do you think that I should refactor
again the libdivecomputer? Should I change
again the design? Or I should continue my current
work, use the current design for all vendors
which have Bluetooth support, implement the
Bluetooth transfer on Windows platforms and finally
start to modify the design as Jef suggested?

I ask this because in the end the Subsurface
custom serial implementation doesn't need
many changes to be integrated with a new
version of libdivecomputer and with its design.
Also, I already have a functional prototype.

I am not sure how to prioritize things. :)

So please let me know what you think.

Thanks,
Claudiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150630/d74a873c/attachment.html>