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.
The version.h header file is generated by autoconf and therefore
located in the build directory and not the source directory. If
building out-of-tree, and a version.h header file is accidentally
present in the source tree, the wrong file will be picked up.
By reversing the order of the include directories, the build directory
is searched first, and the correct header file will be used.
For bug reports it's very convenient to know the exact version. For
release builds, the standard version triplet (major.minor.micro) is
more than sufficient, but that's not the case for development builds.
Due to the post-release version increment, development builds already
have a version number that is distinct from previous releases, but
including the git commit SHA1 is even more accurate.
On Windows, the git commit SHA1 is also embedded in the version
resource.
With the introduction of a context object, library initialization and
shutdown can be performed without requiring any global state. A single
process can use multiple independent contexts without any problems. The
lack of a global state also improves the thread-safety of the library.
At the moment, the new context object is primary used to implement an
improved logging system.
As the name already indicates, a device descriptor is lightweight
object which describes a single device. Currently, the api supports
getting the device name (vendor and product) and model number. But
this can extended with other features when necessary.
The public header files are moved to a new subdirectory, to separate
the definition of the public interface from the actual implementation.
Using an identical directory layout as the final installation has the
advantage that the example code can be build outside the project tree
without any modifications to the #include statements.
The memory layout of the Mares Puck and Nemo devices is very similar,
which allows to share the parsing code between the backends.
The Mares Puck protocol allows for a more efficient implementation, by
reading only the data that we really need. But as an intermediate
solution, reusing the Nemo code is good enough.
The memory layout of all Oceanic devices is very similar, which allows
to share the parsing code between the different backends. Differences in
the layout are passed by means of a new layout descriptor structure.
Memory buffers are now allocated dynamically to support devices with
different amounts of memory.
