2017-04-27 18:24:53 +00:00
|
|
|
// SPDX-License-Identifier: LGPL-2.1+
|
2015-08-20 22:19:41 +00:00
|
|
|
/*
|
|
|
|
* libdivecomputer
|
|
|
|
*
|
|
|
|
* Copyright (C) 2008 Jef Driesen
|
2015-08-20 22:19:44 +00:00
|
|
|
* Copyright (C) 2014 Venkatesh Shukla
|
2016-09-17 15:27:56 +00:00
|
|
|
* Copyright (C) 2015-2016 Anton Lundin
|
2015-08-20 22:19:41 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
|
|
|
|
* MA 02110-1301 USA
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdlib.h> // malloc, free
|
|
|
|
#include <string.h> // strerror
|
|
|
|
#include <errno.h> // errno
|
|
|
|
#include <sys/time.h> // gettimeofday
|
|
|
|
#include <time.h> // nanosleep
|
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#include <libusb.h>
|
|
|
|
#include <ftdi.h>
|
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
#ifndef __ANDROID__
|
|
|
|
#define INFO(context, fmt, ...) fprintf(stderr, "INFO: " fmt "\n", ##__VA_ARGS__)
|
|
|
|
#define ERROR(context, fmt, ...) fprintf(stderr, "ERROR: " fmt "\n", ##__VA_ARGS__)
|
|
|
|
#else
|
|
|
|
#include <android/log.h>
|
|
|
|
#define INFO(context, fmt, ...) __android_log_print(ANDROID_LOG_DEBUG, __FILE__, "INFO: " fmt "\n", ##__VA_ARGS__)
|
|
|
|
#define ERROR(context, fmt, ...) __android_log_print(ANDROID_LOG_DEBUG, __FILE__, "ERROR: " fmt "\n", ##__VA_ARGS__)
|
|
|
|
#endif
|
|
|
|
//#define SYSERROR(context, errcode) ERROR(__FILE__ ":" __LINE__ ": %s", strerror(errcode))
|
|
|
|
#define SYSERROR(context, errcode) ;
|
|
|
|
|
2017-06-18 06:50:37 +00:00
|
|
|
#include <libdivecomputer/custom_io.h>
|
2016-09-17 15:27:56 +00:00
|
|
|
#include <libdivecomputer/context.h>
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
#define VID 0x0403 // Vendor ID of FTDI
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
typedef struct ftdi_serial_t {
|
2015-08-20 22:19:44 +00:00
|
|
|
/* Library context. */
|
2015-08-20 22:19:43 +00:00
|
|
|
dc_context_t *context;
|
|
|
|
/*
|
|
|
|
* The file descriptor corresponding to the serial port.
|
|
|
|
* Also a libftdi_ftdi_ctx could be used?
|
|
|
|
*/
|
|
|
|
struct ftdi_context *ftdi_ctx;
|
|
|
|
long timeout;
|
|
|
|
/*
|
|
|
|
* Serial port settings are saved into this variable immediately
|
|
|
|
* after the port is opened. These settings are restored when the
|
|
|
|
* serial port is closed.
|
2015-08-20 22:19:41 +00:00
|
|
|
* Saving this using libftdi context or libusb. Search further.
|
|
|
|
* Custom implementation using libftdi functions could be done.
|
2015-08-20 22:19:43 +00:00
|
|
|
*/
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
/* Half-duplex settings */
|
2015-08-20 22:19:43 +00:00
|
|
|
int halfduplex;
|
|
|
|
unsigned int baudrate;
|
|
|
|
unsigned int nbits;
|
2016-09-17 15:27:56 +00:00
|
|
|
} ftdi_serial_t;
|
2015-08-20 22:19:44 +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 serial_ftdi_get_received (dc_custom_io_t *io, size_t *value)
|
2015-08-20 22:19:44 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:44 +00:00
|
|
|
|
|
|
|
// Direct access is not encouraged. But function implementation
|
|
|
|
// is not available. The return quantity might be anything.
|
|
|
|
// Find out further about its possible values and correct way of
|
|
|
|
// access.
|
2016-09-17 15:27:56 +00:00
|
|
|
*value = device->ftdi_ctx->readbuffer_remaining;
|
2015-08-20 22:19:44 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:44 +00:00
|
|
|
}
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
static dc_status_t serial_ftdi_get_transmitted (ftdi_serial_t *device)
|
2015-08-20 22:19:44 +00:00
|
|
|
{
|
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:44 +00:00
|
|
|
|
|
|
|
// This is not possible using libftdi. Look further into it.
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_UNSUPPORTED;
|
2015-08-20 22:19:44 +00:00
|
|
|
}
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
static dc_status_t serial_ftdi_sleep (ftdi_serial_t *device, unsigned long timeout)
|
2015-08-20 22:19:44 +00:00
|
|
|
{
|
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:44 +00:00
|
|
|
|
|
|
|
INFO (device->context, "Sleep: value=%lu", timeout);
|
|
|
|
|
|
|
|
struct timespec ts;
|
|
|
|
ts.tv_sec = (timeout / 1000);
|
|
|
|
ts.tv_nsec = (timeout % 1000) * 1000000;
|
|
|
|
|
|
|
|
while (nanosleep (&ts, &ts) != 0) {
|
|
|
|
if (errno != EINTR ) {
|
|
|
|
SYSERROR (device->context, errno);
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:44 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
// Used internally for opening ftdi devices
|
2015-08-20 22:19:44 +00:00
|
|
|
static int serial_ftdi_open_device (struct ftdi_context *ftdi_ctx)
|
2015-08-20 22:19:41 +00:00
|
|
|
{
|
2017-05-30 03:56:42 +00:00
|
|
|
INFO(0, "serial_ftdi_open_device called");
|
2015-08-20 22:19:41 +00:00
|
|
|
int accepted_pids[] = { 0x6001, 0x6010, 0x6011, // Suunto (Smart Interface), Heinrichs Weikamp
|
|
|
|
0xF460, // Oceanic
|
|
|
|
0xF680, // Suunto
|
|
|
|
0x87D0, // Cressi (Leonardo)
|
|
|
|
};
|
|
|
|
int num_accepted_pids = 6;
|
|
|
|
int i, pid, ret;
|
|
|
|
for (i = 0; i < num_accepted_pids; i++) {
|
|
|
|
pid = accepted_pids[i];
|
|
|
|
ret = ftdi_usb_open (ftdi_ctx, VID, pid);
|
2017-05-30 03:56:42 +00:00
|
|
|
INFO(0, "FTDI tried VID %04x pid %04x ret %d\n", VID, pid, ret);
|
2015-08-20 22:19:41 +00:00
|
|
|
if (ret == -3) // Device not found
|
|
|
|
continue;
|
|
|
|
else
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
// No supported devices are attached.
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Open the serial port.
|
|
|
|
// Initialise ftdi_context and use it to open the device
|
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 serial_ftdi_open (dc_custom_io_t *io, dc_context_t *context, const char* name)
|
2015-08-20 22:19:41 +00:00
|
|
|
{
|
2017-05-30 03:56:42 +00:00
|
|
|
INFO(0, "serial_ftdi_open called");
|
2015-08-20 22:19:43 +00:00
|
|
|
// Allocate memory.
|
2016-09-17 15:27:56 +00:00
|
|
|
ftdi_serial_t *device = (ftdi_serial_t *) malloc (sizeof (ftdi_serial_t));
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL) {
|
|
|
|
SYSERROR (context, errno);
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_NOMEMORY;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2017-05-30 03:56:42 +00:00
|
|
|
INFO(0, "setting up ftdi_ctx");
|
2015-08-20 22:19:41 +00:00
|
|
|
struct ftdi_context *ftdi_ctx = ftdi_new();
|
|
|
|
if (ftdi_ctx == NULL) {
|
2015-09-10 04:19:04 +00:00
|
|
|
free(device);
|
2015-08-20 22:19:41 +00:00
|
|
|
SYSERROR (context, errno);
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_NOMEMORY;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Library context.
|
2016-09-17 15:27:56 +00:00
|
|
|
//device->context = context;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Default to blocking reads.
|
|
|
|
device->timeout = -1;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Default to full-duplex.
|
|
|
|
device->halfduplex = 0;
|
|
|
|
device->baudrate = 0;
|
|
|
|
device->nbits = 0;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
// Initialize device ftdi context
|
2017-05-30 03:56:42 +00:00
|
|
|
INFO(0, "initialize ftdi_ctx");
|
2015-08-20 22:19:43 +00:00
|
|
|
ftdi_init(ftdi_ctx);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_set_interface(ftdi_ctx,INTERFACE_ANY)) {
|
2015-09-10 04:19:04 +00:00
|
|
|
free(device);
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
if (serial_ftdi_open_device(ftdi_ctx) < 0) {
|
2015-09-10 04:19:04 +00:00
|
|
|
free(device);
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_usb_reset(ftdi_ctx)) {
|
2015-12-27 22:33:17 +00:00
|
|
|
free(device);
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_usb_purge_buffers(ftdi_ctx)) {
|
2015-09-10 04:19:04 +00:00
|
|
|
free(device);
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
device->ftdi_ctx = ftdi_ctx;
|
2015-08-20 22:19:44 +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 = device;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Close the serial port.
|
|
|
|
//
|
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 serial_ftdi_close (dc_custom_io_t *io)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:41 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Restore the initial terminal attributes.
|
2015-08-20 22:19:41 +00:00
|
|
|
// See if it is possible using libusb or libftdi
|
|
|
|
|
|
|
|
int ret = ftdi_usb_close(device->ftdi_ctx);
|
|
|
|
if (ret < 0) {
|
|
|
|
ERROR (device->context, "Unable to close the ftdi device : %d (%s)\n",
|
2015-08-20 22:19:43 +00:00
|
|
|
ret, ftdi_get_error_string(device->ftdi_ctx));
|
2015-08-20 22:19:41 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ftdi_free(device->ftdi_ctx);
|
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Free memory.
|
|
|
|
free (device);
|
2015-08-20 22:19:41 +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
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Configure the serial port (baudrate, databits, parity, stopbits and flowcontrol).
|
|
|
|
//
|
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 serial_ftdi_configure (dc_custom_io_t *io, unsigned int baudrate, unsigned int databits, dc_parity_t parity, dc_stopbits_t stopbits, dc_flowcontrol_t flowcontrol)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:41 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
INFO (device->context, "Configure: baudrate=%i, databits=%i, parity=%i, stopbits=%i, flowcontrol=%i",
|
|
|
|
baudrate, databits, parity, stopbits, flowcontrol);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
enum ftdi_bits_type ft_bits;
|
|
|
|
enum ftdi_stopbits_type ft_stopbits;
|
|
|
|
enum ftdi_parity_type ft_parity;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_set_baudrate(device->ftdi_ctx, baudrate) < 0) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Set the character size.
|
|
|
|
switch (databits) {
|
|
|
|
case 7:
|
|
|
|
ft_bits = BITS_7;
|
|
|
|
break;
|
|
|
|
case 8:
|
|
|
|
ft_bits = BITS_8;
|
|
|
|
break;
|
|
|
|
default:
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Set the parity type.
|
|
|
|
switch (parity) {
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_PARITY_NONE: /**< No parity */
|
2015-08-20 22:19:43 +00:00
|
|
|
ft_parity = NONE;
|
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_PARITY_EVEN: /**< Even parity */
|
2015-08-20 22:19:43 +00:00
|
|
|
ft_parity = EVEN;
|
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_PARITY_ODD: /**< Odd parity */
|
2015-08-20 22:19:43 +00:00
|
|
|
ft_parity = ODD;
|
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_PARITY_MARK: /**< Mark parity (always 1) */
|
|
|
|
case DC_PARITY_SPACE: /**< Space parity (alwasy 0) */
|
2015-08-20 22:19:43 +00:00
|
|
|
default:
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Set the number of stop bits.
|
|
|
|
switch (stopbits) {
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_STOPBITS_ONE: /**< 1 stop bit */
|
2015-08-20 22:19:43 +00:00
|
|
|
ft_stopbits = STOP_BIT_1;
|
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_STOPBITS_TWO: /**< 2 stop bits */
|
2015-08-20 22:19:43 +00:00
|
|
|
ft_stopbits = STOP_BIT_2;
|
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_STOPBITS_ONEPOINTFIVE: /**< 1.5 stop bits*/
|
2015-08-20 22:19:43 +00:00
|
|
|
default:
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
// Set the attributes
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_set_line_property(device->ftdi_ctx, ft_bits, ft_stopbits, ft_parity)) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Set the flow control.
|
|
|
|
switch (flowcontrol) {
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_FLOWCONTROL_NONE: /**< No flow control */
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_setflowctrl(device->ftdi_ctx, SIO_DISABLE_FLOW_CTRL) < 0) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
2015-08-20 22:19:43 +00:00
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_FLOWCONTROL_HARDWARE: /**< Hardware (RTS/CTS) flow control */
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_setflowctrl(device->ftdi_ctx, SIO_RTS_CTS_HS) < 0) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_FLOWCONTROL_SOFTWARE: /**< Software (XON/XOFF) flow control */
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_setflowctrl(device->ftdi_ctx, SIO_XON_XOFF_HS) < 0) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
2015-08-20 22:19:43 +00:00
|
|
|
break;
|
|
|
|
default:
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
device->baudrate = baudrate;
|
|
|
|
device->nbits = 1 + databits + stopbits + (parity ? 1 : 0);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Configure the serial port (timeouts).
|
|
|
|
//
|
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 serial_ftdi_set_timeout (dc_custom_io_t *io, long timeout)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:41 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
INFO (device->context, "Timeout: value=%li", timeout);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
device->timeout = timeout;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +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 serial_ftdi_set_halfduplex (dc_custom_io_t *io, unsigned int value)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:41 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
// Most ftdi chips support full duplex operation. ft232rl does.
|
|
|
|
// Crosscheck other chips.
|
|
|
|
|
|
|
|
device->halfduplex = value;
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +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 serial_ftdi_read (dc_custom_io_t *io, void *data, size_t size, size_t *actual)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// The total timeout.
|
|
|
|
long timeout = device->timeout;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
// Simulate blocking read as 10s timeout
|
|
|
|
if (timeout == -1)
|
|
|
|
timeout = 10000;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
int backoff = 1;
|
|
|
|
int slept = 0;
|
2015-08-20 22:19:43 +00:00
|
|
|
unsigned int nbytes = 0;
|
|
|
|
while (nbytes < size) {
|
|
|
|
int n = ftdi_read_data (device->ftdi_ctx, (char *) data + nbytes, size - nbytes);
|
2015-08-20 22:19:41 +00:00
|
|
|
if (n < 0) {
|
2015-08-20 22:19:43 +00:00
|
|
|
if (n == LIBUSB_ERROR_INTERRUPTED)
|
|
|
|
continue; //Retry.
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO; //Error during read call.
|
2015-08-20 22:19:43 +00:00
|
|
|
} else if (n == 0) {
|
2015-08-20 22:19:41 +00:00
|
|
|
// Exponential backoff.
|
2016-09-17 15:27:56 +00:00
|
|
|
if (slept >= timeout) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR(device->context, "%s", "FTDI read timed out.");
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_TIMEOUT;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
2015-08-20 22:19:44 +00:00
|
|
|
serial_ftdi_sleep (device, backoff);
|
2016-09-17 15:27:56 +00:00
|
|
|
slept += backoff;
|
2015-08-20 22:19:41 +00:00
|
|
|
backoff *= 2;
|
2016-09-17 15:27:56 +00:00
|
|
|
if (backoff + slept > timeout)
|
|
|
|
backoff = timeout - slept;
|
2015-08-20 22:19:41 +00:00
|
|
|
} else {
|
|
|
|
// Reset backoff to 1 on success.
|
|
|
|
backoff = 1;
|
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
nbytes += n;
|
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
INFO (device->context, "Read %d bytes", nbytes);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
if (actual)
|
|
|
|
*actual = nbytes;
|
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +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 serial_ftdi_write (dc_custom_io_t *io, const void *data, size_t size, size_t *actual)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:41 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:43 +00:00
|
|
|
|
|
|
|
struct timeval tve, tvb;
|
|
|
|
if (device->halfduplex) {
|
|
|
|
// Get the current time.
|
|
|
|
if (gettimeofday (&tvb, NULL) != 0) {
|
|
|
|
SYSERROR (device->context, errno);
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned int nbytes = 0;
|
|
|
|
while (nbytes < size) {
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
int n = ftdi_write_data (device->ftdi_ctx, (char *) data + nbytes, size - nbytes);
|
|
|
|
if (n < 0) {
|
|
|
|
if (n == LIBUSB_ERROR_INTERRUPTED)
|
|
|
|
continue; // Retry.
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO; // Error during write call.
|
2015-08-20 22:19:43 +00:00
|
|
|
} else if (n == 0) {
|
|
|
|
break; // EOF.
|
|
|
|
}
|
|
|
|
|
|
|
|
nbytes += n;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (device->halfduplex) {
|
|
|
|
// Get the current time.
|
|
|
|
if (gettimeofday (&tve, NULL) != 0) {
|
|
|
|
SYSERROR (device->context, errno);
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
// Calculate the elapsed time (microseconds).
|
|
|
|
struct timeval tvt;
|
|
|
|
timersub (&tve, &tvb, &tvt);
|
|
|
|
unsigned long elapsed = tvt.tv_sec * 1000000 + tvt.tv_usec;
|
|
|
|
|
|
|
|
// Calculate the expected duration (microseconds). A 2 millisecond fudge
|
|
|
|
// factor is added because it improves the success rate significantly.
|
|
|
|
unsigned long expected = 1000000.0 * device->nbits / device->baudrate * size + 0.5 + 2000;
|
|
|
|
|
|
|
|
// Wait for the remaining time.
|
|
|
|
if (elapsed < expected) {
|
|
|
|
unsigned long remaining = expected - elapsed;
|
|
|
|
|
|
|
|
// The remaining time is rounded up to the nearest millisecond to
|
|
|
|
// match the Windows implementation. The higher resolution is
|
|
|
|
// pointless anyway, since we already added a fudge factor above.
|
2015-08-20 22:19:44 +00:00
|
|
|
serial_ftdi_sleep (device, (remaining + 999) / 1000);
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-20 22:19:44 +00:00
|
|
|
INFO (device->context, "Wrote %d bytes", nbytes);
|
2015-08-20 22:19:43 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
if (actual)
|
|
|
|
*actual = nbytes;
|
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:43 +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 serial_ftdi_flush (dc_custom_io_t *io, dc_direction_t queue)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
size_t input;
|
2017-06-28 04:04:53 +00:00
|
|
|
serial_ftdi_get_received (io, &input);
|
2016-09-17 15:27:56 +00:00
|
|
|
INFO (device->context, "Flush: queue=%u, input=%lu, output=%i", queue, input,
|
2015-08-20 22:19:44 +00:00
|
|
|
serial_ftdi_get_transmitted (device));
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
switch (queue) {
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_DIRECTION_INPUT: /**< Input direction */
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_usb_purge_tx_buffer(device->ftdi_ctx)) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
2015-08-20 22:19:43 +00:00
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_DIRECTION_OUTPUT: /**< Output direction */
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_usb_purge_rx_buffer(device->ftdi_ctx)) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
2015-08-20 22:19:43 +00:00
|
|
|
break;
|
2016-09-17 15:27:56 +00:00
|
|
|
case DC_DIRECTION_ALL: /**< All directions */
|
2015-08-20 22:19:43 +00:00
|
|
|
default:
|
|
|
|
if (ftdi_usb_purge_buffers(device->ftdi_ctx)) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
2015-08-20 22:19:43 +00:00
|
|
|
break;
|
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +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 serial_ftdi_send_break (dc_custom_io_t *io)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
INFO (device->context, "Break : One time period.");
|
|
|
|
|
|
|
|
// no direct functions for sending break signals in libftdi.
|
|
|
|
// there is a suggestion to lower the baudrate and sending NUL
|
|
|
|
// and resetting the baudrate up again. But it has flaws.
|
|
|
|
// Not implementing it before researching more.
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_UNSUPPORTED;
|
2015-08-20 22:19:41 +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 serial_ftdi_set_break (dc_custom_io_t *io, int level)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
INFO (device->context, "Break: value=%i", level);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
|
|
|
// Not implemented in libftdi yet. Research it further.
|
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_UNSUPPORTED;
|
2015-08-20 22:19:41 +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 serial_ftdi_set_dtr (dc_custom_io_t *io, int level)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
INFO (device->context, "DTR: value=%i", level);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_setdtr(device->ftdi_ctx, level)) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +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 serial_ftdi_set_rts (dc_custom_io_t *io, int level)
|
2015-08-20 22:19:41 +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
|
|
|
ftdi_serial_t *device = (ftdi_serial_t*) io->userdata;
|
2016-09-17 15:27:56 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (device == NULL)
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_INVALIDARGS;
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
INFO (device->context, "RTS: value=%i", level);
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2015-08-20 22:19:43 +00:00
|
|
|
if (ftdi_setrts(device->ftdi_ctx, level)) {
|
2015-08-20 22:19:44 +00:00
|
|
|
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_IO;
|
2015-08-20 22:19:43 +00:00
|
|
|
}
|
2015-08-20 22:19:41 +00:00
|
|
|
|
2016-09-17 15:27:56 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
2015-08-20 22:19:41 +00:00
|
|
|
}
|
|
|
|
|
2017-06-18 06:50:37 +00:00
|
|
|
dc_custom_io_t serial_ftdi_ops = {
|
2016-09-17 15:27:56 +00:00
|
|
|
.userdata = NULL,
|
2017-06-18 06:50:37 +00:00
|
|
|
.serial_open = serial_ftdi_open,
|
|
|
|
.serial_close = serial_ftdi_close,
|
|
|
|
.serial_read = serial_ftdi_read,
|
|
|
|
.serial_write = serial_ftdi_write,
|
|
|
|
.serial_purge = serial_ftdi_flush,
|
|
|
|
.serial_get_available = serial_ftdi_get_received,
|
|
|
|
.serial_set_timeout = serial_ftdi_set_timeout,
|
|
|
|
.serial_configure = serial_ftdi_configure,
|
|
|
|
.serial_set_dtr = serial_ftdi_set_dtr,
|
|
|
|
.serial_set_rts = serial_ftdi_set_rts,
|
|
|
|
.serial_set_halfduplex = serial_ftdi_set_halfduplex,
|
2016-09-17 15:27:56 +00:00
|
|
|
// Can't be done in ftdi?
|
|
|
|
// only used in vyper2
|
|
|
|
// NULL means NOP
|
2017-06-18 06:50:37 +00:00
|
|
|
.serial_set_break = NULL
|
2015-08-20 22:19:44 +00:00
|
|
|
};
|