Create parallel helper functions that use libmtp to walk the file tree on the
device and to then read a specific file from the device into our dc_buffer.
MTP is not a file system, it's an object storage, that just happens to allow
object names and parent/child relationships between objects. As a result we
need to remember those file ids for MTP downloads.
The mtp_get_file_list function is rather complex as it includes both the
initial communication with the device and the code to walk the object tree and
then create the list of file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge upstream changes by Jef Driesen:
- add support for Liquivision dive computers
- add support for the Aqualung i470TC
- extract out Atomic Aquatics Cobalt USB support as a iostream
- misc fixes
* git://github.com/libdivecomputer/libdivecomputer:
Fix the OSTC4 firmware upgrade
Handle a negative number of bytes as an error
Update the example application
Use the new USB transport for the Atomic Aquatics Cobalt
Add an I/O implementation for USB communication
Add support for filter parameters
Disable direct access to the filter function
Increase the receive timeout to 5 seconds
Fix the McLean Extreme bluetooth name
Add support for Liquivision dive computers
Add support for the Aqualung i470TC
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.
Add initial support for the Oceans S1.
This expands a bit on the generic functions for the field-cache code,
and uses that to then add a fairly minimal Oceans S1 downloader.
And while it's minimal, it downloads about everything the S1 offers,
which is mainly just depth and temperature.
There are a few fields that it currently doesn't use, notably the
events and NDL information that the dive computer presumably reports in
the auxiliary data that comes in the sample, but without documentation
and more testing I'm not comfortable parsing that.
There's also some "current dive computer state" that isn't imported,
like the battery status. I know how to read it, but it's not per-dive
data that could be added as extra fields: it's literally just the
current dive computer battery state at the time of the download.
The Oceans team said they'll provide more information about the
download, so this might be expanded in the future, but it seems fairly
usable even in this form.
Thanks to Dhaval Giani for sending me his Oceans S1 as a loaner, and to
Seth Garrison for doing the initial BLE packet dumps that made me think
it was fairly easily doable.
* Oceans-S1:
Oceans S1: polish up the downloading logic for usability
Oceans S1: actually download all dives and parse them
Oceans S1: fill out core download protocol details
Oceans S1: start filling in protocol details
Oceans S1: start documenting the download format and first packets
Add skeleton for Oceans S1 downloader
Add generic dc_field_get() helper
Initial support for McLean Extreme
Signed-off by: David McLean Carron <david_de_carron@hotmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This uses pretty much all of our new infrastructure: the USB storage
iostream for the actual IO, the field-cache for the divecomputer fields,
and the string interface for the events.
It's also a very fast downloader.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This ends up being just a file interface for dive computers that expose
their data as a filesystem that can be mounted.
Right now that's only the Garmin Descent Mk1, although technically the
Uemis Zurich also did that (but oddly, and the backend was never merged
into libdivecomputer).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the infrastructure for the "field cache", which is just
various helpers for the dc_get_field() interface.
This includes the 'dc_field_cache_t' structure that a libdivecomputer
backend can just add to its parser data structure, and a few macros to
make it very easy to initialize the fields and then return them in the
'get_field()' callback.
And part of it is the infrastructure support for the 'dc_field_string_t'
type, which adds the support for string fields. That will be used to
return various string-formatted data from the dive computer, like deco
models, serial numbers, etc.
And no, a serial number is most definitely not a "number". It's a string.
Right now there are no users of this yet, that comes next.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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).
This is done in preparation for the implementation of the new Petrel
protocol, which shares the low level communication with the existing
Predator protocol.
This is only a preliminary version. There is certainly some room for
improvement, but the basic functionality is already in place. That
should be sufficient for daily use, and possibles issues can always be
fixed when discovered.
