Comparing signed and unsigned integer expressions can have unexpected
results because the signed integer will get promoted to an unsigned
integer. To avoid the warning, add an explicit cast to the unsigned
type, along with a check to catch negative values.
Commit d1b865d192afc9efde337b5cff8a239366f15565 breaks the OSTC4
firmware upgrade because the OSTC4 expects to receive the service init
command and the service key all at once, before sending any response.
The hwOS firmware still reads the service init command one byte at a
time, and sends the echo immediately after each byte. But in the
meantime, the hwos firmware has also been optimized. The processing time
for an incoming byte is now always faster then the time it takes for the
next byte to physically arrive via the serial line between the USB/BT
chip and the processor. Thus, even without any buffering, sending all
bytes at once should no longer be a problem.
This partially reverts commit d1b865d192afc9efde337b5cff8a239366f15565.
Reported-by: Anton Lundin <glance@acc.umu.se>
Suggested-by: Ralph Lembcke <mail@ralph-lembcke.de>
The S_BLOCK_WRITE (0x30) command sends a stream of bytes to the dive
computer. Because the payload has no fixed length and there is no length
field included, the hwOS firmware detects the end of the stream by means
of a 400ms timeout. The main disadvantage of this approach is that a
short hiccup in the communication will be incorrectly detected as the
end of the stream. Hence only a part of the data will get written to
the flash memory, and the remainder of the data will get interpreted as
the next commands.
To avoid this problem, the hwOS firmware v3.09 and later supports a new
S_BLOCK_WRITE2 (0x31) command, which uses a fixed size payload of 256
bytes.
Reported-by: Ralph Lembcke <mail@ralph-lembcke.de>
By reading the firmware version information immediately after entering
download or service mode, we can identify the specific firmware version
and adapt to minor differences in the communication protocol.
The S_BLOCK_WRITE (0x30) command sends a stream of bytes to the dive
computer. Because the payload has no fixed length and there is no length
field included, the hwOS firmware detects the end of the stream by means
of a 400ms timeout. Therefore the ready byte is always delayed by this
400ms timeout.
The same remark applies to the DISPLAY (0x6E) and CUSTOMTEXT (0x63)
commands. But because libdivecomputer always pad the text with zeros and
sends the maximum payload size, we won't hit the timeout.
Reported-by: Ralph Lembcke <mail@ralph-lembcke.de>
Erasing a flash memory page is a relative slow operation and takes a
significant amount of time. Therefore, the ready byte is delayed, and
the standard timeout is no longer sufficient. Estimate the required
delay and wait.
Reported-by: Ralph Lembcke <mail@ralph-lembcke.de>
The hwOS firmware reads the service init command one byte at a time, and
sends the echo immediately after each byte.
Reported-by: Ralph Lembcke <mail@ralph-lembcke.de>
Replace the manual polling, implemented using a combination of the
dc_iostream_get_available and dc_iostream_sleep functions, with the new
and more efficient poll function.
The logbook ringbuffer is always updated sequentially. Therefore, emtpy
entries can only be present after the oldest dive. However it appears
that under some special conditions (for example an empty battery during
the dive), the logbook entry is not always stored correctly, which can
result in an empty entry after all.
I suspect that at the start of each dive, the OSTC erases the next
available entry in the logbook ringbuffer and updates the internal write
pointer. Once the dive is finished, the actual content of the erased
logbook is written. Thus, when the OSTC runs out of battery power during
the dive, that last step never happens, and the erased entry remains in
place.
As a workaround, ignore all empty logbook entries instead of assuming we
reached the last dive.
Instead of reading data packets, the code is actually sending some
random data to the dive computer! A small typo with bad consequences!
This is a critical bug because it not only causes the download to fail,
but also appears to change random settings on the dive computer. I
suspect that the garbage data that gets send to the dive computer
happens to contain some valid write settings commands.
The main difference with the serial communication is that the BLE
communication uses data packets (with a maximum size of 20 bytes)
instead of a continuous data stream.
Currently the dive computer backends are responsible for opening (and
closing) the underlying I/O stream internally. The consequence is that
each backend is hardwired to a specific transport type (e.g. serial,
irda or usbhid). In order to remove this dependency and support more
than one transport type in the same backend, the opening (and closing)
of the I/O stream is moved to the application.
The dc_device_open() function is modified to accept a pointer to the I/O
stream, instead of a string with the device node (which only makes sense
for serial communication). The dive computer backends only depend on the
common I/O interface.
I received a bug report complaining that the most recent dives did not
get downloaded. It turns out that the internal dive number in the
logbook entries got reset back to zero somehow:
Logbook 0: empty
...
Logbook 209: empty
Logbook 210: 1
Logbook 211: 2
...
Logbook 235: 26
Logbook 236: 27
Logbook 237: 0
Logbook 238: 1
...
Logbook 254: 17
Logbook 255: 18
This confuses the logic to locate the most recent dive. Because that
logic assumes that the entry with the highest internal dive number is
always the most recent dive, it finds logbook entry #236 instead of the
correct entry #255. Now, when processing the logbook entries backwards,
it stops at those empty entries, and thus never reaches then newest
entries #237 to #255.
The workaround is based on the fact that the OSTC4, unlike the other
hwos based models, already re-orders the logbook entries and always
sends the most recent logbook entry last. So we can ignore the dive
number and simply use the last non-empty entry.
Appending data to the buffer may fail if a memory allocation is
necessary to enlarge the buffer. Hence the return value of the
dc_buffer_append() call should always be checked, unless the memory was
already pre-allocated or the check is deferred after the last operation.
The OSTC3 stores the dive headers and profile data in two separate
memory areas. There is a header area with fixed positions and a profile
area which is used as a ring buffer. Each dive header stores the
position of the profile data in the ring buffer.
Now, once there are more dive headers then room for the profiles, the
oldest profiles (but not the headers) are overwritten with new data.
Because the dive headers are not updated when their profile data gets
overwritten, they will now point to data that is no longer available.
The internal logbook detects this situation and does not display the
profile. But during the download, there is no such check, and the OSTC
will send invalid profile data.
This invalid profile data should be dropped on the receiver side.
Unfortunately implementing the exact same check as is done by the OSTC
itself isn't possible, because the OSTC doesn't send the 6 byte internal
header on which the check is based. As a workaround, the two byte
end-of-profile marker and the length field in the profile header is used
to detect overwritten profiles.
Being able to synchronize the dive computer clock with the host system
is a very useful feature. Add the infrastructure to support this feature
through the public api.
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.
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>
