subsurface/core/serial_ftdi.c

611 lines
16 KiB
C
Raw Normal View History

// SPDX-License-Identifier: LGPL-2.1+
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
/*
* libdivecomputer
*
* Copyright (C) 2008 Jef Driesen
* Copyright (C) 2014 Venkatesh Shukla
* Copyright (C) 2015-2016 Anton Lundin
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
#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) ;
#include <libdivecomputer/custom_io.h>
#include <libdivecomputer/context.h>
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
#define VID 0x0403 // Vendor ID of FTDI
typedef struct ftdi_serial_t {
/* Library context. */
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.
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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.
*/
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
/* Half-duplex settings */
int halfduplex;
unsigned int baudrate;
unsigned int nbits;
} ftdi_serial_t;
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)
{
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
// 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.
*value = device->ftdi_ctx->readbuffer_remaining;
return DC_STATUS_SUCCESS;
}
static dc_status_t serial_ftdi_get_transmitted (ftdi_serial_t *device)
{
if (device == NULL)
return DC_STATUS_INVALIDARGS;
// This is not possible using libftdi. Look further into it.
return DC_STATUS_UNSUPPORTED;
}
static dc_status_t serial_ftdi_sleep (ftdi_serial_t *device, unsigned long timeout)
{
if (device == NULL)
return DC_STATUS_INVALIDARGS;
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);
return DC_STATUS_IO;
}
}
return DC_STATUS_SUCCESS;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Used internally for opening ftdi devices
static int serial_ftdi_open_device (struct ftdi_context *ftdi_ctx)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
{
INFO(0, "serial_ftdi_open_device called");
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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);
INFO(0, "FTDI tried VID %04x pid %04x ret %d\n", VID, pid, ret);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
{
INFO(0, "serial_ftdi_open called");
// Allocate memory.
ftdi_serial_t *device = (ftdi_serial_t *) malloc (sizeof (ftdi_serial_t));
if (device == NULL) {
SYSERROR (context, errno);
return DC_STATUS_NOMEMORY;
}
INFO(0, "setting up ftdi_ctx");
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
struct ftdi_context *ftdi_ctx = ftdi_new();
if (ftdi_ctx == NULL) {
free(device);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
SYSERROR (context, errno);
return DC_STATUS_NOMEMORY;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
// Library context.
//device->context = context;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Default to blocking reads.
device->timeout = -1;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Default to full-duplex.
device->halfduplex = 0;
device->baudrate = 0;
device->nbits = 0;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Initialize device ftdi context
INFO(0, "initialize ftdi_ctx");
ftdi_init(ftdi_ctx);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (ftdi_set_interface(ftdi_ctx,INTERFACE_ANY)) {
free(device);
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
if (serial_ftdi_open_device(ftdi_ctx) < 0) {
free(device);
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
return DC_STATUS_IO;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (ftdi_usb_reset(ftdi_ctx)) {
free(device);
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
if (ftdi_usb_purge_buffers(ftdi_ctx)) {
free(device);
ERROR (context, "%s", ftdi_get_error_string(ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
device->ftdi_ctx = ftdi_ctx;
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;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (device == NULL)
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Restore the initial terminal attributes.
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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",
ret, ftdi_get_error_string(device->ftdi_ctx));
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return ret;
}
ftdi_free(device->ftdi_ctx);
// Free memory.
free (device);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
INFO (device->context, "Configure: baudrate=%i, databits=%i, parity=%i, stopbits=%i, flowcontrol=%i",
baudrate, databits, parity, stopbits, flowcontrol);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
enum ftdi_bits_type ft_bits;
enum ftdi_stopbits_type ft_stopbits;
enum ftdi_parity_type ft_parity;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (ftdi_set_baudrate(device->ftdi_ctx, baudrate) < 0) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
// Set the character size.
switch (databits) {
case 7:
ft_bits = BITS_7;
break;
case 8:
ft_bits = BITS_8;
break;
default:
return DC_STATUS_INVALIDARGS;
}
// Set the parity type.
switch (parity) {
case DC_PARITY_NONE: /**< No parity */
ft_parity = NONE;
break;
case DC_PARITY_EVEN: /**< Even parity */
ft_parity = EVEN;
break;
case DC_PARITY_ODD: /**< Odd parity */
ft_parity = ODD;
break;
case DC_PARITY_MARK: /**< Mark parity (always 1) */
case DC_PARITY_SPACE: /**< Space parity (alwasy 0) */
default:
return DC_STATUS_INVALIDARGS;
}
// Set the number of stop bits.
switch (stopbits) {
case DC_STOPBITS_ONE: /**< 1 stop bit */
ft_stopbits = STOP_BIT_1;
break;
case DC_STOPBITS_TWO: /**< 2 stop bits */
ft_stopbits = STOP_BIT_2;
break;
case DC_STOPBITS_ONEPOINTFIVE: /**< 1.5 stop bits*/
default:
return DC_STATUS_INVALIDARGS;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Set the attributes
if (ftdi_set_line_property(device->ftdi_ctx, ft_bits, ft_stopbits, ft_parity)) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
// Set the flow control.
switch (flowcontrol) {
case DC_FLOWCONTROL_NONE: /**< No flow control */
if (ftdi_setflowctrl(device->ftdi_ctx, SIO_DISABLE_FLOW_CTRL) < 0) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
break;
case DC_FLOWCONTROL_HARDWARE: /**< Hardware (RTS/CTS) flow control */
if (ftdi_setflowctrl(device->ftdi_ctx, SIO_RTS_CTS_HS) < 0) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
break;
case DC_FLOWCONTROL_SOFTWARE: /**< Software (XON/XOFF) flow control */
if (ftdi_setflowctrl(device->ftdi_ctx, SIO_XON_XOFF_HS) < 0) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
break;
default:
return DC_STATUS_INVALIDARGS;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
device->baudrate = baudrate;
device->nbits = 1 + databits + stopbits + (parity ? 1 : 0);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
INFO (device->context, "Timeout: value=%li", timeout);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
device->timeout = timeout;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Most ftdi chips support full duplex operation. ft232rl does.
// Crosscheck other chips.
device->halfduplex = value;
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// The total timeout.
long timeout = device->timeout;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Simulate blocking read as 10s timeout
if (timeout == -1)
timeout = 10000;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
int backoff = 1;
int slept = 0;
unsigned int nbytes = 0;
while (nbytes < size) {
int n = ftdi_read_data (device->ftdi_ctx, (char *) data + nbytes, size - nbytes);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (n < 0) {
if (n == LIBUSB_ERROR_INTERRUPTED)
continue; //Retry.
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO; //Error during read call.
} else if (n == 0) {
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Exponential backoff.
if (slept >= timeout) {
ERROR(device->context, "%s", "FTDI read timed out.");
return DC_STATUS_TIMEOUT;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
serial_ftdi_sleep (device, backoff);
slept += backoff;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
backoff *= 2;
if (backoff + slept > timeout)
backoff = timeout - slept;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
} else {
// Reset backoff to 1 on success.
backoff = 1;
}
nbytes += n;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
INFO (device->context, "Read %d bytes", nbytes);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (actual)
*actual = nbytes;
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (device == NULL)
return DC_STATUS_INVALIDARGS;
struct timeval tve, tvb;
if (device->halfduplex) {
// Get the current time.
if (gettimeofday (&tvb, NULL) != 0) {
SYSERROR (device->context, errno);
return DC_STATUS_IO;
}
}
unsigned int nbytes = 0;
while (nbytes < size) {
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +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.
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO; // Error during write call.
} else if (n == 0) {
break; // EOF.
}
nbytes += n;
}
if (device->halfduplex) {
// Get the current time.
if (gettimeofday (&tve, NULL) != 0) {
SYSERROR (device->context, errno);
return DC_STATUS_IO;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +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.
serial_ftdi_sleep (device, (remaining + 999) / 1000);
}
}
INFO (device->context, "Wrote %d bytes", nbytes);
if (actual)
*actual = nbytes;
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 serial_ftdi_flush (dc_custom_io_t *io, dc_direction_t queue)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
size_t input;
serial_ftdi_get_received (io, &input);
INFO (device->context, "Flush: queue=%u, input=%lu, output=%i", queue, input,
serial_ftdi_get_transmitted (device));
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
switch (queue) {
case DC_DIRECTION_INPUT: /**< Input direction */
if (ftdi_usb_purge_tx_buffer(device->ftdi_ctx)) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
break;
case DC_DIRECTION_OUTPUT: /**< Output direction */
if (ftdi_usb_purge_rx_buffer(device->ftdi_ctx)) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
break;
case DC_DIRECTION_ALL: /**< All directions */
default:
if (ftdi_usb_purge_buffers(device->ftdi_ctx)) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
break;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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.
return DC_STATUS_UNSUPPORTED;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
INFO (device->context, "Break: value=%i", level);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
// Not implemented in libftdi yet. Research it further.
return DC_STATUS_UNSUPPORTED;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
INFO (device->context, "DTR: value=%i", level);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (ftdi_setdtr(device->ftdi_ctx, level)) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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)
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
INFO (device->context, "RTS: value=%i", level);
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
if (ftdi_setrts(device->ftdi_ctx, level)) {
ERROR (device->context, "%s", ftdi_get_error_string(device->ftdi_ctx));
return DC_STATUS_IO;
}
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
return DC_STATUS_SUCCESS;
serial_ftdi.c for communication with ftdi devices This script is based on serial_posix.c and is primarily meant to work on android, but could be used elsewhere as well. This script communicates with libftdi devices connected to the system using libftdi library. ftdi_read_data returns 0 if no data is received from the device. Allowing to continue on recieving 0 might end up in an infinite loop. But it works in OSTC3. This needs to be checked further. libftdi returns -3 when it could not find any device corresponding to the pid and vid given. (Different from -3 of libusb which means you do not have permissions to access the device) Use this to return value to check for other accepted chipsets including the custom pids used by divecomputer manufacturers such as Cressi (Leonardo), Suunto and Oceanic. ftdi_read_data returns the number of bytes read (+ve), 0 when there is no data to read, and negative when there is an error. Instead of infinitely waiting for the data to appear, it is better to implement an exponential backoff which times out after MAX_BACKOFF. [Anton Lundin: This code was originally intended to be included in libdivecomputer, but because we now got the custom-serial patches, its included in subsurface instead, and wired in from there - renamed the resulting file to serial_ftdi.c] Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in> Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Rename serial_ftdi.c for subsurface source Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-08-20 22:19:41 +00:00
}
dc_custom_io_t serial_ftdi_ops = {
.userdata = NULL,
.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,
// Can't be done in ftdi?
// only used in vyper2
// NULL means NOP
.serial_set_break = NULL
};