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.
I received a bug report from a device which failed to download new dives
after a reset (probably caused by an empty battery). This reset appears
to reset the internal dive counter back to zero, and also resets the
write pointer back to the begin of the logbook ringbuffer, but leaves
the existing logbook entries in place. The result is that the logic to
find the most recent dive based on the highest internal dive counter,
will be wrong because it finds those old entries.
The discovery of the logbook (and profile) write pointers eliminates the
need to search for the most recent logbook entry.
After being removed from the public api, these functions can be changed
into local, static functions. And in a few cases, they are no longer
necessary and can be removed completely.
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 logbook entries are stored separately from the profile data. If the
profile ringbuffer is filled faster than the logbook ringbuffer, then
the oldest logbook entries can still point to profile data that has
already been overwritten with newer data.
To detect such overwritten profile data, we keep track of the remaining
space in the profile ringbuffer.
On linux, several users are reporting download problems, while on
windows everything works fine. Simply toggling the DTR line appears to
fix the problem.
A possible explanation is that on windows, the SetCommState() function
not only configures the serial protocol parameters, but also initializes
the DTR and RTS lines. In the libdivecomputer implementation the default
state is enabled (DTR_CONTROL_ENABLE and RTS_CONTROL_ENABLE). The result
is that the DTR line gets automatically initialized to enabled, and then
manually disabled again.
On linux, the DTR and RTS lines are not automatically initialized during
configuration, and need to be controlled explicitely. The result is that
the DTR line ends up disabled without being toggled.
The read command appears to be limited to the range 0x1000-0x1100. That
range seems to correspond with the first 256 bytes of the full memory
dump. The packet size of 32 bytes is an arbitrary choice.
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.
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.
The fingerprint is used unconditionally, regardless of whether it's
explicitly set by the application or not. Therefore it needs to be
initialized properly.
Normally, the last valid dive is followed by an empty entry with all
0xFF bytes. However, we received data from a device where a few of those
bytes are not equal to 0xFF. This causes the entry to be processed
incorrectly as a valid dive.
As a workaround, we now check the internal dive number for 0xFFFF.
The serial number appears to be either a 24 or a 16 bit number, but
certainly not a 32bit number. Whether it's 24 or 16 bit is hard to
tell because the data we have available always contains a zero value
in the third byte.
The communication protocol and memory layout of the Cressi Giotto
appears to be identical to that of the Leonardo. The first byte seems
to be the model number, with 0x01 for the Leonardo and 0x04 for the
Giotto.
Sometimes there are garbage bytes present after opening the serial
port, which causes the communication to fail. Flushing the buffers
after a small delay is all it takes to get rid of those bytes.
Currently, each backend has it's own function to verify whether the
object vtable pointer is the expected one. All these functions can be
removed in favor of a single isintance function in the base class,
which takes the expected vtable pointer as a parameter.
Functions which are called through the vtable, don't need to verify the
vtable pointer, and those checks are removed.
The term "backend" can be confusing because it can refer to both the
virtual function table and the device/parser backends. The use of the
term "vtable" avoids this.
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.
