The latest v2.09 (hwOS) and v1.1.0 (hwOS4) firmware introduced a new
variant of the hardware descriptor command. This extended command
returns:
- a 16 bit hardware descriptor
- a 16 bit feature descriptor
- an 8 bit model descriptor
The hardware descriptor is backwards compatible with the existing one
(upper bits are all zero for now). For the OSTC4, the feature descriptor
is currently used to indicated the Bonex scooter version (0x01), and the
model descriptor is 0x43. For all other models, the feature and model
descriptors are always zero for now.
For older firmware versions, which do not support the new extended
descriptor yet, there is an automatic fallback to the previous
descriptor.
The OSTC4 firmware version uses four digits for the firmware version
(X.Y.Z.Beta), while all other hwOS models use two digits (X.Y). To
preserve backwards compatibility with the existing two byte data format,
the OSTC4 firmware version is packed into a 16 bit integer as follows:
XXXX XYYY YYZZ ZZZB
and stored with little endian byte order.
The low level serial and IrDA functions are modified to:
- Use the libdivecomputer namespace prefix.
- Return a more detailed status code instead of the zero on success and
negative on error return value. This will allow to return more
fine-grained error codes.
- The read and write functions have an additional output parameter to
return the actual number of bytes transferred. Since these functions
are not atomic, some data might still be transferred successfully if
an error occurs.
The dive computer backends are updated to use the new api.
By reading the hardware descriptor immediately after entering download
or service mode, we can identify the specific model and adapt to minor
differences in the communication protocol.
Both the allocation and initialization of the object data structure is
now moved to a single function. The corresponding deallocation function
is intended to free objects that have been allocated, but are not fully
initialized yet. The public cleanup function shouldn't be used in such
case, because it may try to release resources that haven't been
initialized yet.
Instead of freeing the object data structure in the backend specific
cleanup function, the memory is now freed automatically in the base
class function. This reduces the amount of boilerplate code in the
backends. Backends that don't allocate any additional resources, do no
longer require a cleanup function at all.
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.
With firmware version 1.84 (beta), a more compact logbook header is
introduced. Due to their smaller size (16 vs 256 bytes), the total
amount of data that needs to be transferred is much smaller (4K vs 64K).
Therefore, downloading these compact headers is roughly 16 times faster
then downloading the full headers.
For backwards compatibility with older firmware versions, there is an
automatic fallback to the full logbook headers.
This adds a dump function for the ostc3 series computers. This function
dumps the whole external eprom, that contains the dive-headers and the
dive data.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
The latest firmware v1.75 introduced a new hardware descriptor byte to
identify the different models based on their hardware features. This new
hardware descriptor is now used as the libdivecomputer model number. For
older firmware versions, which do not support the descriptor yet, there
is an automatic fallback to the previous method based on the serial
number.
When trying to send an unsupported command, the ostc will simply ignore
the command. Instead of echoing the command byte back, the ostc will
immediately send the ready byte, to indicate it's ready to receive the
next command. We can use this to detect unsupported commands, because
the ready byte is a reserved value and guaranteed to never be a valid
command byte.
Normally we don't send invalid commands. But newer firmware version can
always introduce new commands to support new features. To maintain
backwards compatibility with older firmware versions, it's important to
be able to detect unsupported commands and provide a fallback.
The OSTC3 can display a status message of up to 16 characters large.
Since this does not include the terminating null character, the buffer
needs to be one byte larger.
The new implementation is similar to the already existing code for
reading Intel HEX files. It can handle arbitrary line endings, and not
just CRLF or LF.
This simplifies the code to check and handle state switching for the
OSTC3.
Suggested-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This connects the bits and implements firmware upgrade for the OSTC3.
This code is inspired by JeanDo ostc-companion.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This function triggers a reboot into the bootloader which flashes the
new firmware to Prom.
This code is inspired by JeanDo ostc-companion.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This is how you transfer a new firmware to the OSTC3.
This code is inspired by JeanDo ostc-companion.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This is necessary to verify that the memory written got transfered
correctly.
This code is inspired by JeanDo ostc-companion.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This is the fist step in the firmware upgrade process.
This code is inspired by JeanDo ostc-companion.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This lifts the OSTC3 INIT command out from the open function and does
that separately. This is refactoring to be able to enter service mode so
we can access service mode commands.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Although the OSTC Sport uses bluetooth communication, the new model
remains fully compatible with the OSTC3, because it provides a virtual
serial port interface. As usual, the new model can be detected based on
the serial number.
Starting with firmware v1.23, the OSTC3 settings can be configured
through the USB interface. There are new commands for reading, writing
and restoring the settings to their default values.
The workaround in the previous commit has a bug. If after a reset, the
first entry happens to be located near the end of the TOC, then after a
few dives, the TOC will overflow and new entries will be written at the
start of the TOC. But the current algorithm starts scanning the TOC from
the start and abort the scan as soon as an empty entry is found. Thus if
there are less than 256 dives present, those entries near the end will
never be reached.
We now ignore all uninitialized entries, when searching for the most
recent dive. An explicit safety check is added in case dives are
unexpectedly interleaved with empty entries.
Normally, the OSTC3 will always start writing dives at the first entry
in the TOC (Table of Contents). Therefore, uninitialized entries can
only be present after the last dive. However due to a minor firmware
bug, resetting the logbook erases the TOC but leaves the internal dive
counter unchanged. The consequence is that the next dive will still be
stored at the corresponding next TOC entry, while all previous TOC
entries have been erased.
As a workaround, we simply ignore uninitialized entries, unless we have
already found at least one dive.
The OSTC 3 dataformat does contain the profile length twice: once in the
main 256 byte header, and again in the small profile header. However due
to a firmware bug, both values are not identical. The value in the main
header is wrong and 3 bytes larger than the value in the small profile
header. This bug was fixed in firmware version 0.93.
Unfortunately we rely on the length in the main header to calculate the
number of bytes to read when downloading the dive. The consequence is
that for all dives recorded with firmware 0.93 or later, the length is
calculated incorrectly, and the download fails. Luckily the firmware
version is stored in the main header too, and we can adjust the length
calculation accordingly.
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.
