A dive computer typically writes its ringbuffer in the forward
direction. Thus, when downloading the dives in reverse order (newest
first), the ringbuffer needs to be read in the backward direction.
However, some dive computers already re-arrange the data in the correct
order, which means the data needs to be read in the opposite direction.
To support this case without drastic changes in the logic, the rbstream
implementation is extended to also support reading in the forward
direction.
Because the dive_count variable is decremented, it doesn't contain the
total number of dives, but the index of the last dive. A negative number
indicates no dives. The same result can be obtained by using the total
number of dives directly. That's not only more intuitive, but also fixes
a -Wsign-compare compiler warning.
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.
The parameters used with the FTDI USB serial port drivers didn't work
well with directly with libftdi1. The new baud rate results in the same
effective baud rates for both.
The rbstream block size was reduced to help with the unreliability of
the libftdi communications.
Using FTDI for custom I/O resulted in very unrealible reads. This patch
allows more reliable use of FTDI custom I/O, like what might be needed
when used on a mobile device like Android.
[Jef Driesen: Modified to retry only for non-fatal errors. This simply
restores the code from commit b3d2c603ddec9758fb36706bbde46ce23ca9f0ed,
which was removed in commit 55e8f83eb5d934e65fbf587d427de267f174c651.]
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 dived the model enough to wrap the profile buffer and I was wrong
about where the end was. Also, the buffer starts 3 bytes after where it
could. We were treating profile pointers as 4 bytes when they are two
bytes. This worked most of the time when short tissues were clear
(tissue load follows the pointer).
The Cochran Commander TM appears to be a first generation Commander with
limited storage and function compared to later models.
The main differences are:
- The TM doesn't support high-speed transfer so use the 0x05 read
command and don't change to a higher baud rate. Still reset to 9600
to wait for the heartbeat.
- The TM has a different config command (one byte).
- The TM has only one config page.
For previously supported Cochran computers high-speed read of log and
profile data started at byte 0. Older models that lack the high-speed
transfer function use the standard speed read commands and so the log
and profile data are read at higher addresses.
Since moving to per-dive download of profile data (and now rbstream
download) the data->sample_data_offset and data->sample_size variables
aren't used so calculating them doesn't make sense.
The progress bar was taking 18 seconds between updates on a Commander II
when using a 128K pagesize. Since devices differ in their baud rates, it
makes sense to use smaller pages on slower devices. This change reduces
it to 32K on a Commander II and to 64K on EMC devices.
The method used to calculate the data used by dives (to determine when
we run out of ringbuffer) incorrectly didn't include surface sample
data. Ten to twenty minute of sample data is recorded at the surface in
case the diver re-descends, continuing the dive. The code then thought
that older dive profiles were not yet overwritten. The improper data was
returned to the user.
This function is much more useful if it works like a
ringbuffer_distance() function. It assumed the wrong values when
calculating profile size and it didn't have easy access to values it
needed to properly calculate profile sizes.
It makes sense to keep since it validates pointers.
Commander II pointers to profile ringbuffer data was wrong. After seeing
the Commander I encoding I realized the Commander II encoding of RB
pointers was in a flipped word big endian format. It only appeared to be
in normal big endian format because of an adjacent pointer that usually
shared the same first two bytes.
This adds support for older Cochran Commander dive computers,
specifically Commanders with serial numbers prior to 21000.
This also renames "Commander" model to "Commander II" and
adds "Commander I" to refer to pre-21000 models.
Since commit 344bfab229a17c7227b9bec02f616505a8d9e998 only a subset of
the id string is used to detect the model. But because the offset was
never updated, the model detection always fails now.
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 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.
