From 883063875e253a1cf944c5f524d46ec9ab0b796d Mon Sep 17 00:00:00 2001 From: Jan Mulder Date: Tue, 18 Jul 2017 19:17:15 +0200 Subject: [PATCH] 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 --- core/qtserialbluetooth.cpp | 6 +++--- 1 file 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)