BLE serial read/write buffer

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

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

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

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

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>

1 files changed, 3 insertions, 3 deletions

diff --git a/core/qtserialbluetooth.cpp b/core/qtserialbluetooth.cpp
index 3a031e1ae..63fbbd4d2 100644
--- a/core/qtserialbluetooth.cpp
+++ b/core/qtserialbluetooth.cpp
@@ -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)