The functionality provided by the filter function is not only useful for
the built-in transports, but also for the applications. For example in
combination with a custom transport.
The latest versions of the Divesoft Freedom (HW 4.x) and Liberty (HW
2.x) dive computers support BLE communication. Previous generations did
support only a mass storage mode, where the dives are available as DLF
files. The BLE communication protocol uses HDLC framing for the data
packets. The dives downloaded over BLE have the same data format as the
DLF files.
Co-authored-by: Jan Matoušek <jan.matousek@rekomando.cz>
Tested-by: Jakub Hečko <jakub.hecko@divesoft.com>
The Windows version resource is compiled and can include the (generated)
version.h header file for the definition of the version macros. There is
no need to have it generated by autotools. Less generated files makes it
easier to use other build systems, like Visual Studio.
The Oceans S1 uses a plaintext and line based communication protocol
over BLE. The larger payloads, which also contain plaintext data, are
transferred using the XMODEM-CRC protocol.
Based-on-code-by: Linus Torvalds <torvalds@linux-foundation.org>
The Deepblu Cosmiq+ uses a plaintext and line based communication
protocol over BLE, where the binary payload data is encoded as
hexadecimal characters.
Based-on-code-by: Linus Torvalds <torvalds@linux-foundation.org>
The Sporasub SP2 uses a very simple communication protocol and memory
layout, but with some unusual aspects:
Dives are artifically limited to a maximum of 6000 samples.
Unlike all other dive computers, the dives are not stored in some kind
of ringbuffer structure. Once the memory is full, no new dives can be
recorded. The existing dives need to be erased first, and the dive
computer will start recording again at te start of the memory area. The
Sporasub application has an "Auto-clear watch memory after data
transfer" feature for this purpose.
I didn't implement a more efficient download algorithm because
downloading a full memory dumps takes less than 10 seconds.
The USB communication is now also implemented as an I/O stream
transport. Unlike most I/O devices, USB communication supports multiple
interfaces and endpoints. This requires some some special care:
In the general case, autodetection isn't really possible without
additional knowledge. Hence the need for the filter parameters to pass
this kind of information.
The implementation assumes two bulk endpoints for the standard
read/write interface. Communication with the control endpoint is
supported through the new DC_IOCTL_USB_CONTROL_{READ,WRITE} ioctl's.
The Uwatec Smart, Meridian and G2 backends are almost identical, except
for the low-level packet sending and receiving code. With the new I/O
layer, those three backends can easily be unified in a single backend.
The Meridian and G2 are completely removed, only the family types are
kept for backwards compatibility.
The new timer module provides an cross-platform interface for a high
resolution monotonic clock. The timestamps are always relative to the
creation of the timer and their unit is one microseconds.
The timers can be used for logging, measuring elapsed time and
implementing timeouts.
The device descriptors are extended with a filter function. During the
device discovery, this filter function is used to return only devices
that match a known dive computer.
The filtering is optional, and can be disabled by passing a NULL pointer
for the device descriptor when creating the iterator with one of the
dc_xxx_iterator_new() functions.
In the case of a submodule, the .git file is a text file pointing to the
correct module in the parent's .git folder. The git rev-parse works
correctly in both cases.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Wih the custom I/O implementation, an application can use its own
low-level I/O layer instead of using one of the built-in ones. The
application only needs to provide a set of callback functions, and
libdivecomputer will wrap them into a I/O stream.
The purpose of the new I/O interface is to provide a common interface
for all existing I/O implementations (serial, IrDA, bluetooth and USB
HID). With a common interface the dive computer backends can more easily
use different I/O implementations at runtime, without needing
significant code changes. For example bluetooth enabled devices can
easily switch between native bluetooth communication and serial port
emulation mode.
The new interface is modelled after the existing serial communication
api. Implementations where some of those functions are meaningless (e.g.
IrDA, bluetooth and USB), can just leave those functions unimplemented
(causing the call to fail with DC_STATUS_UNSUPPORTED), or implement it
as a no-op (always return DC_STATUS_SUCCESS).
The back-end parser seems to be the same as for the Uwatec Smart (aka
Galileo Sol). At least that's the assumption right now.
The downloader just uses USB HID (very similar to EON Steel) rather than
the horrible IrDA thing.
There's also eventually a BLE thing, but that's for the future.
This is an unholy mixture of the Uwatec Smart downloader logic and the
EON Steel usbhid transfer code. The back-end is pure Uwatec Smart
(model 0x11, same as Galileo Sol).
I'm not at all sure this gets everything right, but it downloads
*something*.
[Jef Driesen: Renamed the backend to uwatec, and made some smaller
cosmetic changes to match the existing coding style.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For the time being, the bluetooth communication code is of very limited
use. It's not used anywhere in the library, and as an internal api it's
also not available to applications. It serves mainly as a reference
implementation for future use.
The implementation supports Windows and Linux.
The dummy IrDA implementation is integrated in the main file. The
appropriate implementation is selected using conditional compilation
based on the features detect by the autotools build system.
The vendor_product_parser_create() and vendor_product_device_open()
functions should be called indirectly, through the generic
dc_device_open() and dc_parser_new() functions. And the
vendor_product_extract_dives() functions are internal functions that
should never have been part of the public api in the first place.
Reading a ringbuffer backwards in order to process the most recent data
first, is a very common operation. Nearly every dive computer backend
has its own implementation. Thus with a common implementation, the
amount of code duplication and complexity in the dive computer backends
can be greatly reduced.
The common algorithm is implemented as a simple ringbuffer stream, which
takes care of all the technical details like the ringbuffer boundaries,
alignment to the page size, using the optimal packet size and caching
the remaining data.
When building the Windows version resource, the -DHAVE_CONFIG_H option
isn't passed to resource compiler automatically. The result is that
development builds don't have their git revision embedded in the DLL.
On Mac OS X, libusb doesn't work for USB HID devices. We can use the
hidapi library instead. Although the hidapi library supports Linux and
Windows too, we keep using libusb there to avoid the extra dependency.
When the close function returns, all resources should be freed,
regardless of whether an error has occured or not. The error code is
purely informative.
However, in order to return the first error code, which is usually the
most interesting one, the current implementation is unnecessary
complicated. If an error occurs, there is no need to exit immediately.
Simply store the error code unless there is already a previous one, and
then continue.
The new gasmix sample contains the index of the active gas mix.
This new sample is intended as a replacement for the existing gas change
events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2). To maintain
backwards compatibility, the legacy events are marked as deprecated but
not removed yet.
For obvious reasons, the -static-libgcc linker option is not supported
by non gcc compilers, like clang. Since we only need this option when
building Windows DLL's, we can easily avoid the problem with a
conditional on the mingw compiler.
When compiling a 32bit dll with the mingw-w64 compiler, some 64bit
integer arithmetic operations are implemented using functions from
libgcc (e.g. __divdi3 and __moddi3 from libgcc_s_sjlj-1.dll). This
unexpected dependency is inconvenient for applications.
The run-time dependency can be avoid by linking statically.
This imports Tiny AES128 from https://github.com/kokke/tiny-AES128-C for
use in the decoding of OSTC3 firmwares.
This aes-code is released into the public domain.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Basic Suunto EON Steel downloading copied from my test application.
This parses all the core dive data, including sample data (time, depth,
cylinder pressure, deco information etc).
The deco information returns ceiling and TTS rather than ceiling and
"time at ceiling", because that's what the dive computer has, and I
don't see any other way to return the information.
We don't report any events yet, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Uwatec Meridian protocol is identical to the Uwatec Smart/Galileo
protocol, except for some additional framing around each data packet,
and the switch from IrDA to usb-serial communication. For parsing, the
data format appears to be identical to the Galileo data format.
Although the communication protocol of the OSTC3 is nearly identical to
that of the Frog, the different size parameters make it hard to share
the code easily. On top of that, if we ever implement native bluetooth
communication support, we'll need a completely separate backend anyway.
Therefore the Frog backend is simply duplicated, with a few OSTC3
specific changes applied here and there.
The existing ostc parser is upgraded to support the new OSTC3 data
format.
The Petrel (with updated firmware) supports an enhanced communication
protocol, which is more efficient and powerfull than the legacy Predator
compatibility mode. The new protocol uses data compression for faster
transfers and supports the ability to selectively download individual
dives. Last but not least, the new protocol isn't limited to the last
128kB of logbook data, but can access the full logbook capacity (16MB).
