| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
None of these seem to point to actual issues, so let's quiet them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Most writes to a connected DC are small, typically some
command bytes to get DC in download mode, or to set
some parameter. All this just worked over BLE,
however, sending a full firmware update (on an
OSTC device) failed, as the underlying BLE interface
can only handle small 20 byte BLE packets at once.
So, send max ble->packet_size chuncks at once.
Tested for the following cases (linux desktop with
OSTC3 over BLE):
1) normal download of dive data.
2) read and write settings from configure UI
3) update firmware (from 2.15 to 2.15)
And to my surprise, no flow control credit administration
is required here.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
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>
|
|
See also b409e9fc91d87bbd5 and 709c1df2af4b87. The OSTC parser
cannot handle reads of single 20 byte BLE packages in serial mode.
Instead of doing a deeper down agressive read, we can read on
the serial level more subtile. As the parser is requesting a
specific number of bytes, we just read that number of bytes and
return them. As the 20 byte BLE packets do (obviously) not
align with the reading requirement of the libdc parser, a little
housekeeing needs to be done in between individual reads.
CAVEAT 1: In contradiction to 709c1df2af4b87, this is supposed to
work for all parsers that properly specify the needed bytes to fetch.
CAVEAT 2: All above tested on Linux Desktop with bluez stack.
Subsurface mobile is step 2.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
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>
|
|
This is somewhat hacky, but it allows at least the Shearwater
libdivecomputer backend to continue to treat even the BLE GATT model as
just a serial protocol.
What it does is create a special "emulate serial behavior over the
packetized BLE protocol" helper layer, that qtserialbluetooth falls back
on when rfcomm is not available.
NOTE! This still requires some BLE packet code changes to work with the
odd way that Shearwater sets up their BLE GATT communication. So note
that no further patches are necessary to *libdivecomputer*, but some
updates are needed for the subsurface qt-ble.cpp code.
I have those updates in my tree, and this code is all tested on my
Perdix AI, but those patches are currently too ugly to commit as-is.
I've cleaned up this "fake serial" code sufficiently, that cleanup comes
next.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
This is some very early and hacky code to be able to access BLE-enabled
dive computers that use the GATT protocol to send packets back and forth
(which seems to be pretty much all of them: a vendor-specific GATT
service with a write characteristic and a notification characteristic
for reading).
For testing only. But it does successfully let me download dives from
my EON Steel and my Scubapro G2.
NOTE! There are several very hacky pieces in here, including just
"knowing" that the write characteristic is the first one, and the
notification characteristic is second. The code should actually check
the properties rather than have those kinds of hardcoded assumptions.
It also checks "vendor specific" by looking at the UUID string
representation, and knowing that the standard ones start with zero.
Crazily, there doesn't seem to be any normal way to test for this,
although I guess that maybe the uuid.minimumSize() function could be
used.
There are other nasty corners. Don't complain, send me patches.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Instead of being "custom serial", it's a IO model that allows serial or
packet modes, independently of each other (ie you can have a bluetooth
device that does serial over BT rfcomm and packet-based communication
over BLE GATT with the same serial operations that describe both cases).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
While it seemed logical to use the advertized service UUID that doesn't
appear to be working - instead using this hard coded UUID seems to do
the trick. I now did a successful download from my Shearwater Petrel.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
We remember the offered service uuids as we detect the device and then
try the first one - likely this needs to be fixed / tuned to pick the
right one if multiple uuids are offered.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
By copying a line from the Linux bluetooth code I can download
from OSTC dive computers on Mac. Don't ask me why this works.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
|
|
The function is unused, to silence the warning add the "unused"
GCC attribute to the function declaration.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
We need to return a DC_STATUS here.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
This rewrites the custom serial code to use the new api which I
implemented in the Subsurface-branch of libdivecomputer.
This is a bit to big patch but I haven't had the time to break it down
into more sensible patches.
This rewrite enables us to support more ftdi based divecomputer
communication and is tested with both a OSTC3, OSTC2N and a Suunto
Vyper, all over the libftdi driver.
The bluetooth code paths are tested to, and should work as before.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
Berthold Stoeger
Dirk Hohndel
Jan Mulder
Linus Torvalds
Robert C. Helling
Lubomir I. Ivanov
Anton Lundin