mifr/subsurface
1
0
Fork 0
mirror of https://github.com/subsurface/subsurface.git synced 2025-02-19 22:16:15 +00:00
Code Issues Projects Releases Packages Wiki Activity

BLE serial read/write buffer

Browse source 
The adapted define was confusingly wrong. Apparently, the BUFSIZ
define was coming from some include file, and was dependent on
platform (Linux 8K, Andorid 1K). Simple rewrite to a new define
and a proper value for both Linux and Android. If 4K is big
enhough, is a little uncertain, as its depends on the read
behavior of all libdivecomputer parsers using this serial
BLE interface.

The buffer size needed (on read, as that is the most prominent
direction when interfacing with DCs) is (most likely) 2x the
maximum block the libdc parsers request at once. I did not
study all parsers, but the Shearwater parser request 20 bytes
at once (we know that from the 1 packet at the time read, we
had before). The OSTC parser request 1K blocks for data
that is longer than 1K (like profiles, header tables).

The 1K we had on Android was working for Shearwater,
Eon Steel, but not for OSTC,as its reads 1K at the time
at max, and overflowing the buffer.

So 32k or 64k seems way to big (as in, much bigger than
any libdc read).

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit is contained in:
Jan Mulder 2017-07-18 19:17:15 +02:00 • committed by Dirk Hohndel
parent 5c7ac7e7d1
commit 883063875e
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
core/qtserialbluetooth.cpp
View file

@ -92,11 +92,11 @@ static dc_status_t ble_serial_open(dc_custom_io_t *io, dc_context_t *context, co
return qt_ble_open(&ble_serial_ops, context, devaddr);
}
#define BUFSZ 1024
#define BT_BLE_BUFSIZE 4096
static struct {
unsigned int out_bytes, in_bytes, in_pos;
unsigned char in[BUFSIZ];
unsigned char out[BUFSIZ];
unsigned char in[BT_BLE_BUFSIZE];
unsigned char out[BT_BLE_BUFSIZE];
} buffer;
static dc_status_t ble_serial_flush_write(void)