2017-04-27 18:24:53 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2015-07-06 14:07:34 +00:00
|
|
|
#include <errno.h>
|
|
|
|
|
|
|
|
#include <QtBluetooth/QBluetoothAddress>
|
|
|
|
#include <QtBluetooth/QBluetoothSocket>
|
|
|
|
#include <QEventLoop>
|
|
|
|
#include <QTimer>
|
2015-07-06 14:11:02 +00:00
|
|
|
#include <QDebug>
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2015-07-07 18:47:48 +00:00
|
|
|
#include <libdivecomputer/version.h>
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
#include <libdivecomputer/context.h>
|
2015-07-07 18:47:48 +00:00
|
|
|
|
2017-06-18 06:50:37 +00:00
|
|
|
#if defined(SSRF_CUSTOM_IO)
|
2015-07-07 18:47:48 +00:00
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
|
|
|
#include <winsock2.h>
|
|
|
|
#include <windows.h>
|
|
|
|
#include <ws2bth.h>
|
|
|
|
#endif
|
|
|
|
|
2017-06-18 06:50:37 +00:00
|
|
|
#include <libdivecomputer/custom_io.h>
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2017-06-13 02:47:50 +00:00
|
|
|
#ifdef BLE_SUPPORT
|
|
|
|
# include "qt-ble.h"
|
|
|
|
#endif
|
|
|
|
|
2017-05-31 00:50:31 +00:00
|
|
|
QList<QBluetoothUuid> registeredUuids;
|
|
|
|
|
|
|
|
void addBtUuid(QBluetoothUuid uuid)
|
|
|
|
{
|
|
|
|
registeredUuids << uuid;
|
|
|
|
}
|
|
|
|
|
2015-07-06 14:07:34 +00:00
|
|
|
extern "C" {
|
2016-09-17 15:27:56 +00:00
|
|
|
typedef struct qt_serial_t {
|
2015-07-06 14:07:34 +00:00
|
|
|
/*
|
|
|
|
* RFCOMM socket used for Bluetooth Serial communication.
|
|
|
|
*/
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
|
|
|
SOCKET socket;
|
|
|
|
#else
|
2015-07-06 14:07:34 +00:00
|
|
|
QBluetoothSocket *socket;
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
2015-07-06 14:07:34 +00:00
|
|
|
long timeout;
|
2016-09-17 15:27:56 +00:00
|
|
|
} qt_serial_t;
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2017-06-27 03:03:09 +00:00
|
|
|
#ifdef BLE_SUPPORT
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_open(dc_custom_io_t *io, dc_context_t *, const char* devaddr);
|
|
|
|
static dc_status_t ble_serial_close(dc_custom_io_t *io);
|
|
|
|
static dc_status_t ble_serial_read(dc_custom_io_t *io, void* data, size_t size, size_t *actual);
|
|
|
|
static dc_status_t ble_serial_write(dc_custom_io_t *io, const void* data, size_t size, size_t *actual);
|
|
|
|
static dc_status_t ble_serial_purge(dc_custom_io_t *io, dc_direction_t queue);
|
|
|
|
static dc_status_t ble_serial_get_available(dc_custom_io_t *io, size_t *available);
|
|
|
|
static dc_status_t ble_serial_set_timeout(dc_custom_io_t *io, long timeout);
|
2017-06-27 03:03:09 +00:00
|
|
|
|
|
|
|
static dc_custom_io_t ble_serial_ops = {
|
2017-06-28 03:53:21 +00:00
|
|
|
.userdata = NULL,
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
.user_device = NULL,
|
2017-06-27 03:03:09 +00:00
|
|
|
|
|
|
|
.serial_open = ble_serial_open,
|
|
|
|
.serial_close = ble_serial_close,
|
|
|
|
.serial_read = ble_serial_read,
|
|
|
|
.serial_write = ble_serial_write,
|
|
|
|
.serial_purge = ble_serial_purge,
|
|
|
|
.serial_get_available = ble_serial_get_available,
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
.serial_set_timeout = ble_serial_set_timeout,
|
2017-06-27 03:03:09 +00:00
|
|
|
// These doesn't make sense over bluetooth
|
|
|
|
// NULL means NOP
|
|
|
|
.serial_configure = NULL,
|
|
|
|
.serial_set_dtr = NULL,
|
|
|
|
.serial_set_rts = NULL,
|
|
|
|
.serial_set_halfduplex = NULL,
|
|
|
|
.serial_set_break = NULL,
|
|
|
|
|
2017-06-28 03:53:21 +00:00
|
|
|
.packet_size = 20,
|
|
|
|
.packet_open = qt_ble_open,
|
|
|
|
.packet_close = qt_ble_close,
|
|
|
|
.packet_read = qt_ble_read,
|
|
|
|
.packet_write = qt_ble_write,
|
2017-06-27 03:03:09 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_open(dc_custom_io_t *io, dc_context_t *context, const char* devaddr)
|
2017-06-27 03:03:09 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
dc_context_set_custom_io(context, &ble_serial_ops, io->user_device);
|
|
|
|
return qt_ble_open(&ble_serial_ops, context, devaddr);
|
2017-06-27 03:03:09 +00:00
|
|
|
}
|
|
|
|
|
BLE serial read/write buffer
The adapted define was confusingly wrong. Apparently, the BUFSIZ
define was coming from some include file, and was dependent on
platform (Linux 8K, Andorid 1K). Simple rewrite to a new define
and a proper value for both Linux and Android. If 4K is big
enhough, is a little uncertain, as its depends on the read
behavior of all libdivecomputer parsers using this serial
BLE interface.
The buffer size needed (on read, as that is the most prominent
direction when interfacing with DCs) is (most likely) 2x the
maximum block the libdc parsers request at once. I did not
study all parsers, but the Shearwater parser request 20 bytes
at once (we know that from the 1 packet at the time read, we
had before). The OSTC parser request 1K blocks for data
that is longer than 1K (like profiles, header tables).
The 1K we had on Android was working for Shearwater,
Eon Steel, but not for OSTC,as its reads 1K at the time
at max, and overflowing the buffer.
So 32k or 64k seems way to big (as in, much bigger than
any libdc read).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-18 17:17:15 +00:00
|
|
|
#define BT_BLE_BUFSIZE 4096
|
2017-06-27 03:03:09 +00:00
|
|
|
static struct {
|
|
|
|
unsigned int out_bytes, in_bytes, in_pos;
|
BLE serial read/write buffer
The adapted define was confusingly wrong. Apparently, the BUFSIZ
define was coming from some include file, and was dependent on
platform (Linux 8K, Andorid 1K). Simple rewrite to a new define
and a proper value for both Linux and Android. If 4K is big
enhough, is a little uncertain, as its depends on the read
behavior of all libdivecomputer parsers using this serial
BLE interface.
The buffer size needed (on read, as that is the most prominent
direction when interfacing with DCs) is (most likely) 2x the
maximum block the libdc parsers request at once. I did not
study all parsers, but the Shearwater parser request 20 bytes
at once (we know that from the 1 packet at the time read, we
had before). The OSTC parser request 1K blocks for data
that is longer than 1K (like profiles, header tables).
The 1K we had on Android was working for Shearwater,
Eon Steel, but not for OSTC,as its reads 1K at the time
at max, and overflowing the buffer.
So 32k or 64k seems way to big (as in, much bigger than
any libdc read).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-18 17:17:15 +00:00
|
|
|
unsigned char in[BT_BLE_BUFSIZE];
|
|
|
|
unsigned char out[BT_BLE_BUFSIZE];
|
2017-06-27 03:03:09 +00:00
|
|
|
} buffer;
|
|
|
|
|
|
|
|
static dc_status_t ble_serial_flush_write(void)
|
|
|
|
{
|
|
|
|
int bytes = buffer.out_bytes;
|
|
|
|
|
|
|
|
if (!bytes)
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
buffer.out_bytes = 0;
|
2017-06-28 03:53:11 +00:00
|
|
|
return ble_serial_ops.packet_write(&ble_serial_ops, buffer.out, bytes, NULL);
|
2017-06-27 03:03:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static dc_status_t ble_serial_flush_read(void)
|
|
|
|
{
|
|
|
|
buffer.in_bytes = buffer.in_pos = 0;
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_close(dc_custom_io_t *io)
|
2017-06-27 03:03:09 +00:00
|
|
|
{
|
|
|
|
ble_serial_flush_write();
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
io->userdata = NULL;
|
2017-06-27 03:03:09 +00:00
|
|
|
return qt_ble_close(&ble_serial_ops);
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_read(dc_custom_io_t *io, void* data, size_t size, size_t *actual)
|
2017-06-27 03:03:09 +00:00
|
|
|
{
|
2017-06-28 03:53:11 +00:00
|
|
|
Q_UNUSED(io)
|
|
|
|
size_t len;
|
2017-07-11 11:41:21 +00:00
|
|
|
size_t received = 0;
|
2017-06-27 03:03:09 +00:00
|
|
|
|
|
|
|
if (buffer.in_pos >= buffer.in_bytes) {
|
2017-07-11 11:41:21 +00:00
|
|
|
ble_serial_flush_write();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* There is still unused/unread data in the input steam.
|
|
|
|
* So preseve it at the start of a new read.
|
|
|
|
*/
|
|
|
|
if (buffer.in_pos > 0) {
|
|
|
|
len = buffer.in_bytes - buffer.in_pos;
|
|
|
|
memcpy(buffer.in, buffer.in + buffer.in_pos, len);
|
|
|
|
buffer.in_pos = 0;
|
|
|
|
buffer.in_bytes = len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read a long as requested in the size parameter */
|
|
|
|
while ((buffer.in_bytes - buffer.in_pos) < size) {
|
2017-06-27 03:03:09 +00:00
|
|
|
dc_status_t rc;
|
|
|
|
|
2017-07-11 11:41:21 +00:00
|
|
|
rc = ble_serial_ops.packet_read(&ble_serial_ops, buffer.in + buffer.in_bytes,
|
|
|
|
sizeof(buffer.in) - buffer.in_bytes, &received);
|
2017-06-27 03:03:09 +00:00
|
|
|
if (rc != DC_STATUS_SUCCESS)
|
|
|
|
return rc;
|
|
|
|
if (!received)
|
|
|
|
return DC_STATUS_IO;
|
2017-07-11 11:41:21 +00:00
|
|
|
|
|
|
|
buffer.in_bytes += received;
|
2017-06-27 03:03:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
len = buffer.in_bytes - buffer.in_pos;
|
|
|
|
if (len > size)
|
|
|
|
len = size;
|
|
|
|
|
|
|
|
memcpy(data, buffer.in + buffer.in_pos, len);
|
|
|
|
buffer.in_pos += len;
|
|
|
|
if (actual)
|
|
|
|
*actual = len;
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_write(dc_custom_io_t *io, const void* data, size_t size, size_t *actual)
|
2017-06-27 03:03:09 +00:00
|
|
|
{
|
2017-06-28 03:53:11 +00:00
|
|
|
Q_UNUSED(io)
|
2017-06-27 03:03:09 +00:00
|
|
|
dc_status_t rc = DC_STATUS_SUCCESS;
|
|
|
|
size_t transferred = 0;
|
|
|
|
|
|
|
|
ble_serial_flush_read();
|
2017-09-22 08:03:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Most writes to a connected DC are small, typically some command bytes to get
|
|
|
|
* DC in download mode, or to set some parameter. All this just worked over BLE,
|
|
|
|
* however, sending a full firmware update (on an OSTC device) failed, as the
|
|
|
|
* underlying BLE interface can only handle small 20 byte BLE packets at once.
|
|
|
|
*
|
|
|
|
* So, send max ble->packet_size chuncks at once.
|
|
|
|
*/
|
2017-06-27 03:03:09 +00:00
|
|
|
while (size) {
|
2017-09-22 08:03:42 +00:00
|
|
|
size_t len = sizeof(buffer.out) - transferred;
|
2017-06-27 03:03:09 +00:00
|
|
|
|
2017-09-22 08:03:42 +00:00
|
|
|
if (len > io->packet_size)
|
|
|
|
len = io->packet_size;
|
2017-06-27 03:03:09 +00:00
|
|
|
if (len > size)
|
|
|
|
len = size;
|
|
|
|
memcpy(buffer.out + buffer.out_bytes, data, len);
|
|
|
|
buffer.out_bytes += len;
|
|
|
|
|
2017-09-22 08:03:42 +00:00
|
|
|
if (buffer.out_bytes <= io->packet_size || buffer.out_bytes == size) {
|
2017-06-27 03:03:09 +00:00
|
|
|
rc = ble_serial_flush_write();
|
|
|
|
if (rc != DC_STATUS_SUCCESS)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
transferred += len;
|
|
|
|
data = (const void *) (len + (const char *)data);
|
|
|
|
size -= len;
|
|
|
|
}
|
|
|
|
if (actual)
|
|
|
|
*actual = transferred;
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_purge(dc_custom_io_t *io, dc_direction_t queue)
|
2017-06-27 03:03:09 +00:00
|
|
|
{
|
2017-06-28 03:53:11 +00:00
|
|
|
Q_UNUSED(io)
|
|
|
|
Q_UNUSED(queue)
|
2017-06-27 03:03:09 +00:00
|
|
|
/* Do we care? */
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_get_available(dc_custom_io_t *io, size_t *available)
|
2017-06-27 03:03:09 +00:00
|
|
|
{
|
2017-06-28 03:53:11 +00:00
|
|
|
Q_UNUSED(io)
|
2017-06-27 03:03:09 +00:00
|
|
|
*available = buffer.in_bytes - buffer.in_pos;
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t ble_serial_set_timeout(dc_custom_io_t *io, long timeout)
|
|
|
|
{
|
2017-06-28 03:53:11 +00:00
|
|
|
Q_UNUSED(io)
|
|
|
|
Q_UNUSED(timeout)
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
/* Do we care? */
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-06-27 03:03:09 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2017-05-31 00:50:31 +00:00
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_open(dc_custom_io_t *io, dc_context_t *context, const char* devaddr)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
2017-06-27 03:03:09 +00:00
|
|
|
#ifdef BLE_SUPPORT
|
|
|
|
if (!strncmp(devaddr, "LE:", 3))
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
return ble_serial_open(io, context, devaddr);
|
2017-06-27 03:03:09 +00:00
|
|
|
#endif
|
|
|
|
|
2015-07-06 14:07:34 +00:00
|
|
|
// Allocate memory.
|
2016-09-17 15:27:56 +00:00
|
|
|
qt_serial_t *serial_port = (qt_serial_t *) malloc (sizeof (qt_serial_t));
|
2015-07-06 14:07:34 +00:00
|
|
|
if (serial_port == NULL) {
|
|
|
|
return DC_STATUS_NOMEMORY;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Default to blocking reads.
|
|
|
|
serial_port->timeout = -1;
|
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
2015-08-18 18:37:11 +00:00
|
|
|
// Create a RFCOMM socket
|
|
|
|
serial_port->socket = ::socket(AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM);
|
|
|
|
|
2015-09-10 04:19:03 +00:00
|
|
|
if (serial_port->socket == INVALID_SOCKET) {
|
|
|
|
free(serial_port);
|
2015-08-18 18:37:11 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-09-10 04:19:03 +00:00
|
|
|
}
|
2015-08-18 18:37:11 +00:00
|
|
|
|
|
|
|
SOCKADDR_BTH socketBthAddress;
|
|
|
|
int socketBthAddressBth = sizeof (socketBthAddress);
|
|
|
|
char *address = strdup(devaddr);
|
|
|
|
|
|
|
|
ZeroMemory(&socketBthAddress, socketBthAddressBth);
|
|
|
|
qDebug() << "Trying to connect to address " << devaddr;
|
|
|
|
|
|
|
|
if (WSAStringToAddressA(address,
|
|
|
|
AF_BTH,
|
|
|
|
NULL,
|
|
|
|
(LPSOCKADDR) &socketBthAddress,
|
|
|
|
&socketBthAddressBth
|
|
|
|
) != 0) {
|
|
|
|
qDebug() << "FAiled to convert the address " << address;
|
|
|
|
free(address);
|
|
|
|
|
|
|
|
return DC_STATUS_IO;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(address);
|
|
|
|
|
|
|
|
socketBthAddress.addressFamily = AF_BTH;
|
|
|
|
socketBthAddress.port = BT_PORT_ANY;
|
|
|
|
memset(&socketBthAddress.serviceClassId, 0, sizeof(socketBthAddress.serviceClassId));
|
|
|
|
socketBthAddress.serviceClassId = SerialPortServiceClass_UUID;
|
|
|
|
|
|
|
|
// Try to connect to the device
|
|
|
|
if (::connect(serial_port->socket,
|
|
|
|
(struct sockaddr *) &socketBthAddress,
|
|
|
|
socketBthAddressBth
|
|
|
|
) != 0) {
|
|
|
|
qDebug() << "Failed to connect to device";
|
|
|
|
|
|
|
|
return DC_STATUS_NODEVICE;
|
|
|
|
}
|
|
|
|
|
|
|
|
qDebug() << "Succesfully connected to device";
|
2015-08-18 17:51:10 +00:00
|
|
|
#else
|
2015-07-06 14:07:34 +00:00
|
|
|
// Create a RFCOMM socket
|
|
|
|
serial_port->socket = new QBluetoothSocket(QBluetoothServiceInfo::RfcommProtocol);
|
|
|
|
|
|
|
|
// Wait until the connection succeeds or until an error occurs
|
|
|
|
QEventLoop loop;
|
|
|
|
loop.connect(serial_port->socket, SIGNAL(connected()), SLOT(quit()));
|
|
|
|
loop.connect(serial_port->socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
|
|
|
|
|
|
|
|
// Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
|
|
|
|
QTimer timer;
|
|
|
|
int msec = 5000;
|
|
|
|
timer.setSingleShot(true);
|
|
|
|
loop.connect(&timer, SIGNAL(timeout()), SLOT(quit()));
|
|
|
|
|
2015-07-13 20:37:49 +00:00
|
|
|
#if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)
|
2015-07-06 14:07:34 +00:00
|
|
|
// First try to connect on RFCOMM channel 1. This is the default channel for most devices
|
|
|
|
QBluetoothAddress remoteDeviceAddress(devaddr);
|
2015-09-29 19:12:55 +00:00
|
|
|
serial_port->socket->connectToService(remoteDeviceAddress, 1, QIODevice::ReadWrite | QIODevice::Unbuffered);
|
2015-07-06 14:07:34 +00:00
|
|
|
timer.start(msec);
|
|
|
|
loop.exec();
|
|
|
|
|
|
|
|
if (serial_port->socket->state() == QBluetoothSocket::ConnectingState) {
|
|
|
|
// It seems that the connection on channel 1 took more than expected. Wait another 15 seconds
|
2015-07-06 14:11:02 +00:00
|
|
|
qDebug() << "The connection on RFCOMM channel number 1 took more than expected. Wait another 15 seconds.";
|
2015-07-06 14:07:34 +00:00
|
|
|
timer.start(3 * msec);
|
|
|
|
loop.exec();
|
|
|
|
} else if (serial_port->socket->state() == QBluetoothSocket::UnconnectedState) {
|
|
|
|
// Try to connect on channel number 5. Maybe this is a Shearwater Petrel2 device.
|
2015-07-06 14:11:02 +00:00
|
|
|
qDebug() << "Connection on channel 1 failed. Trying on channel number 5.";
|
2015-09-29 19:12:55 +00:00
|
|
|
serial_port->socket->connectToService(remoteDeviceAddress, 5, QIODevice::ReadWrite | QIODevice::Unbuffered);
|
2015-07-06 14:07:34 +00:00
|
|
|
timer.start(msec);
|
|
|
|
loop.exec();
|
|
|
|
|
|
|
|
if (serial_port->socket->state() == QBluetoothSocket::ConnectingState) {
|
|
|
|
// It seems that the connection on channel 5 took more than expected. Wait another 15 seconds
|
2015-07-06 14:11:02 +00:00
|
|
|
qDebug() << "The connection on RFCOMM channel number 5 took more than expected. Wait another 15 seconds.";
|
2015-07-06 14:07:34 +00:00
|
|
|
timer.start(3 * msec);
|
|
|
|
loop.exec();
|
|
|
|
}
|
|
|
|
}
|
2015-07-18 20:14:00 +00:00
|
|
|
#elif defined(Q_OS_ANDROID) || (QT_VERSION >= 0x050500 && defined(Q_OS_MAC))
|
2015-07-13 20:37:49 +00:00
|
|
|
// Try to connect to the device using the uuid of the Serial Port Profile service
|
|
|
|
QBluetoothAddress remoteDeviceAddress(devaddr);
|
2017-05-31 00:50:31 +00:00
|
|
|
#if defined(Q_OS_ANDROID)
|
2017-06-01 05:16:25 +00:00
|
|
|
QBluetoothUuid uuid = QBluetoothUuid(QUuid("{00001101-0000-1000-8000-00805f9b34fb}"));
|
2017-05-31 00:50:31 +00:00
|
|
|
qDebug() << "connecting to Uuid" << uuid;
|
2017-05-31 18:43:18 +00:00
|
|
|
serial_port->socket->setPreferredSecurityFlags(QBluetooth::NoSecurity);
|
2017-05-31 00:50:31 +00:00
|
|
|
serial_port->socket->connectToService(remoteDeviceAddress, uuid, QIODevice::ReadWrite | QIODevice::Unbuffered);
|
|
|
|
#else
|
2017-04-28 19:30:39 +00:00
|
|
|
serial_port->socket->connectToService(remoteDeviceAddress, 1, QIODevice::ReadWrite | QIODevice::Unbuffered);
|
2017-05-31 00:50:31 +00:00
|
|
|
#endif
|
2015-07-13 20:37:49 +00:00
|
|
|
timer.start(msec);
|
|
|
|
loop.exec();
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2015-07-13 20:37:49 +00:00
|
|
|
if (serial_port->socket->state() == QBluetoothSocket::ConnectingState ||
|
|
|
|
serial_port->socket->state() == QBluetoothSocket::ServiceLookupState) {
|
|
|
|
// It seems that the connection step took more than expected. Wait another 20 seconds.
|
|
|
|
qDebug() << "The connection step took more than expected. Wait another 20 seconds";
|
|
|
|
timer.start(4 * msec);
|
|
|
|
loop.exec();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
if (serial_port->socket->state() != QBluetoothSocket::ConnectedState) {
|
2015-07-06 14:07:34 +00:00
|
|
|
|
|
|
|
// Get the latest error and try to match it with one from libdivecomputer
|
|
|
|
QBluetoothSocket::SocketError err = serial_port->socket->error();
|
2015-07-06 14:11:02 +00:00
|
|
|
qDebug() << "Failed to connect to device " << devaddr << ". Device state " << serial_port->socket->state() << ". Error: " << err;
|
|
|
|
|
2015-09-09 15:34:49 +00:00
|
|
|
free (serial_port);
|
2015-07-06 14:07:34 +00:00
|
|
|
switch(err) {
|
|
|
|
case QBluetoothSocket::HostNotFoundError:
|
|
|
|
case QBluetoothSocket::ServiceNotFoundError:
|
|
|
|
return DC_STATUS_NODEVICE;
|
|
|
|
case QBluetoothSocket::UnsupportedProtocolError:
|
|
|
|
return DC_STATUS_PROTOCOL;
|
2015-07-08 17:58:31 +00:00
|
|
|
#if QT_VERSION >= 0x050400
|
2015-07-06 14:07:34 +00:00
|
|
|
case QBluetoothSocket::OperationError:
|
|
|
|
return DC_STATUS_UNSUPPORTED;
|
2015-07-08 17:58:31 +00:00
|
|
|
#endif
|
2015-07-06 14:07:34 +00:00
|
|
|
case QBluetoothSocket::NetworkError:
|
|
|
|
return DC_STATUS_IO;
|
|
|
|
default:
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
|
|
|
}
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
io->userdata = serial_port;
|
2015-07-06 14:07:34 +00:00
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_close(dc_custom_io_t *io)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
qt_serial_t *device = (qt_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
if (device == NULL)
|
2015-07-06 14:07:34 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
2015-08-18 18:37:50 +00:00
|
|
|
// Cleanup
|
|
|
|
closesocket(device->socket);
|
|
|
|
free(device);
|
2015-08-18 17:51:10 +00:00
|
|
|
#else
|
|
|
|
if (device->socket == NULL) {
|
|
|
|
free(device);
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2015-07-06 14:07:34 +00:00
|
|
|
device->socket->close();
|
|
|
|
|
|
|
|
delete device->socket;
|
|
|
|
free(device);
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
2015-07-06 14:07:34 +00:00
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
io->userdata = NULL;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-07-06 14:07:34 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_read(dc_custom_io_t *io, void* data, size_t size, size_t *actual)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
qt_serial_t *device = (qt_serial_t*) io->userdata;
|
2017-06-27 03:03:09 +00:00
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
|
|
|
if (device == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
size_t nbytes = 0;
|
2015-08-18 18:38:17 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
while (nbytes < size) {
|
|
|
|
rc = recv (device->socket, (char *) data + nbytes, size - nbytes, 0);
|
|
|
|
|
|
|
|
if (rc < 0) {
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO; // Error during recv call.
|
2015-08-18 18:38:17 +00:00
|
|
|
} else if (rc == 0) {
|
|
|
|
break; // EOF reached.
|
|
|
|
}
|
|
|
|
|
|
|
|
nbytes += rc;
|
|
|
|
}
|
2015-08-18 17:51:10 +00:00
|
|
|
#else
|
2015-07-06 14:07:34 +00:00
|
|
|
if (device == NULL || device->socket == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
size_t nbytes = 0;
|
2015-07-06 20:59:14 +00:00
|
|
|
int rc;
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2015-09-22 21:33:15 +00:00
|
|
|
while(nbytes < size && device->socket->state() == QBluetoothSocket::ConnectedState)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
|
|
|
rc = device->socket->read((char *) data + nbytes, size - nbytes);
|
|
|
|
|
|
|
|
if (rc < 0) {
|
|
|
|
if (errno == EINTR || errno == EAGAIN)
|
|
|
|
continue; // Retry.
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO; // Something really bad happened :-(
|
2015-07-06 14:07:34 +00:00
|
|
|
} else if (rc == 0) {
|
|
|
|
// Wait until the device is available for read operations
|
|
|
|
QEventLoop loop;
|
2015-09-22 21:33:14 +00:00
|
|
|
QTimer timer;
|
|
|
|
timer.setSingleShot(true);
|
|
|
|
loop.connect(&timer, SIGNAL(timeout()), SLOT(quit()));
|
2015-07-06 14:07:34 +00:00
|
|
|
loop.connect(device->socket, SIGNAL(readyRead()), SLOT(quit()));
|
2015-09-22 21:33:14 +00:00
|
|
|
timer.start(device->timeout);
|
2015-07-06 14:07:34 +00:00
|
|
|
loop.exec();
|
2015-09-22 21:33:14 +00:00
|
|
|
|
|
|
|
if (!timer.isActive())
|
2016-09-17 15:27:56 +00:00
|
|
|
break;
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
nbytes += rc;
|
|
|
|
}
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
2016-09-17 15:27:56 +00:00
|
|
|
if (actual)
|
|
|
|
*actual = nbytes;
|
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_write(dc_custom_io_t *io, const void* data, size_t size, size_t *actual)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
qt_serial_t *device = (qt_serial_t*) io->userdata;
|
2017-06-27 03:03:09 +00:00
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
|
|
|
if (device == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
size_t nbytes = 0;
|
2015-08-18 18:38:47 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
while (nbytes < size) {
|
|
|
|
rc = send(device->socket, (char *) data + nbytes, size - nbytes, 0);
|
2015-08-18 17:51:10 +00:00
|
|
|
|
2015-08-18 18:38:47 +00:00
|
|
|
if (rc < 0) {
|
2016-09-18 14:41:55 +00:00
|
|
|
return DC_STATUS_IO; // Error during send call.
|
2015-08-18 18:38:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
nbytes += rc;
|
|
|
|
}
|
2015-08-18 17:51:10 +00:00
|
|
|
#else
|
2015-07-06 14:07:34 +00:00
|
|
|
if (device == NULL || device->socket == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
size_t nbytes = 0;
|
2015-07-06 20:59:14 +00:00
|
|
|
int rc;
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2015-09-22 21:33:15 +00:00
|
|
|
while(nbytes < size && device->socket->state() == QBluetoothSocket::ConnectedState)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
|
|
|
rc = device->socket->write((char *) data + nbytes, size - nbytes);
|
|
|
|
|
|
|
|
if (rc < 0) {
|
|
|
|
if (errno == EINTR || errno == EAGAIN)
|
|
|
|
continue; // Retry.
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO; // Something really bad happened :-(
|
2015-07-06 14:07:34 +00:00
|
|
|
} else if (rc == 0) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
nbytes += rc;
|
|
|
|
}
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
2016-09-17 15:27:56 +00:00
|
|
|
if (actual)
|
|
|
|
*actual = nbytes;
|
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_purge(dc_custom_io_t *io, dc_direction_t queue)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
qt_serial_t *device = (qt_serial_t*) io->userdata;
|
2017-06-27 03:03:09 +00:00
|
|
|
|
2016-03-10 03:07:42 +00:00
|
|
|
(void)queue;
|
2015-08-18 17:51:10 +00:00
|
|
|
if (device == NULL)
|
2015-07-06 14:07:34 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-18 17:51:10 +00:00
|
|
|
#if !defined(Q_OS_WIN)
|
|
|
|
if (device->socket == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
#endif
|
|
|
|
// TODO: add implementation
|
2015-07-06 14:07:34 +00:00
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_get_available(dc_custom_io_t *io, size_t *available)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
qt_serial_t *device = (qt_serial_t*) io->userdata;
|
2017-06-27 03:03:09 +00:00
|
|
|
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
|
|
|
if (device == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
|
|
|
// TODO use WSAIoctl to get the information
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
*available = 0;
|
2015-08-18 17:51:10 +00:00
|
|
|
#else
|
2015-07-06 14:07:34 +00:00
|
|
|
if (device == NULL || device->socket == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
*available = device->socket->bytesAvailable();
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
2016-09-17 15:27:56 +00:00
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
|
|
|
|
2017-03-11 20:08:34 +00:00
|
|
|
/* UNUSED! */
|
|
|
|
static int qt_serial_get_transmitted(qt_serial_t *device) __attribute__ ((unused));
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
static int qt_serial_get_transmitted(qt_serial_t *device)
|
2015-07-06 14:07:34 +00:00
|
|
|
{
|
2015-08-18 17:51:10 +00:00
|
|
|
#if defined(Q_OS_WIN)
|
|
|
|
if (device == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
|
|
|
// TODO add implementation
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
#else
|
2015-07-06 14:07:34 +00:00
|
|
|
if (device == NULL || device->socket == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
|
|
|
return device->socket->bytesToWrite();
|
2015-08-18 17:51:10 +00:00
|
|
|
#endif
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
|
|
|
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
static dc_status_t qt_serial_set_timeout(dc_custom_io_t *io, long timeout)
|
2015-08-18 17:17:45 +00:00
|
|
|
{
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
qt_serial_t *device = (qt_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-18 17:17:45 +00:00
|
|
|
if (device == NULL)
|
|
|
|
return DC_STATUS_INVALIDARGS;
|
|
|
|
|
|
|
|
device->timeout = timeout;
|
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
2015-07-06 14:07:34 +00:00
|
|
|
|
2017-06-18 06:50:37 +00:00
|
|
|
dc_custom_io_t qt_serial_ops = {
|
2016-09-17 15:27:56 +00:00
|
|
|
.userdata = NULL,
|
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
|
|
|
.user_device = NULL,
|
2017-06-18 06:50:37 +00:00
|
|
|
.serial_open = qt_serial_open,
|
|
|
|
.serial_close = qt_serial_close,
|
|
|
|
.serial_read = qt_serial_read,
|
|
|
|
.serial_write = qt_serial_write,
|
2017-06-27 03:03:09 +00:00
|
|
|
.serial_purge = qt_serial_purge,
|
|
|
|
.serial_get_available = qt_serial_get_available,
|
2017-06-18 06:50:37 +00:00
|
|
|
.serial_set_timeout = qt_serial_set_timeout,
|
2016-09-17 15:27:56 +00:00
|
|
|
// These doesn't make sense over bluetooth
|
|
|
|
// NULL means NOP
|
2017-06-18 06:50:37 +00:00
|
|
|
.serial_configure = NULL,
|
|
|
|
.serial_set_dtr = NULL,
|
|
|
|
.serial_set_rts = NULL,
|
|
|
|
.serial_set_halfduplex = NULL,
|
2017-06-13 02:47:50 +00:00
|
|
|
.serial_set_break = NULL,
|
|
|
|
|
|
|
|
#ifdef BLE_SUPPORT
|
|
|
|
.packet_size = 20,
|
|
|
|
.packet_open = qt_ble_open,
|
|
|
|
.packet_close = qt_ble_close,
|
|
|
|
.packet_read = qt_ble_read,
|
|
|
|
.packet_write = qt_ble_write,
|
|
|
|
#endif
|
2015-07-06 14:07:34 +00:00
|
|
|
};
|
|
|
|
|
2017-06-18 06:50:37 +00:00
|
|
|
dc_custom_io_t* get_qt_serial_ops() {
|
|
|
|
return (dc_custom_io_t*) &qt_serial_ops;
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-07-06 14:07:34 +00:00
|
|
|
}
|
2015-07-07 18:47:48 +00:00
|
|
|
#endif
|