The version function requires device specific knowledge to use it (at
least the required buffer size), it is already called internally when
necessary, and only a few backends support it. Thus there is no good
reason to keep it in the high-level public api.
These macros are used internally and don't need to be exposed. In some
cases, the actual values are not even constant, but dependant on the
model and/or the firmware version.
I forgot to update the device and parser initialization functions to
store the context pointer into the objects. As a result, the internal
context pointers were always NULL.
The public api is changed to require a context object for all
operations. Because other library objects store the context pointer
internally, only the constructor functions need an explicit context
object as a parameter.
Adding the "dc_" namespace prefix (which is of course an abbreviation
for libdivecomputer) should avoid conflicts with other libraries. For
the time being, only the high-level device and parser layers are
changed.
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 Veo 1.0 has very limited memory and doesn't have a logbook and
profile ringbuffer. Hence downloading dives isn't really supported, but
even this limited amount of data might be useful for someone.
The init command appears to behave more like a hard reset. If the
command is sent during the communication, the device immediately closes
the connection and no further communication is possible without
disconnecting and reconnecting the device.
Sending the command at the start of the communication seems to require a
long delay before sending the next command. However the communication
works equally well without sending this command. For some devices it
even improves the success rate of the initialization sequence, and thus
there is no reason to keep it.
Some devices are having problems during the initialization sequence. The
extra delay appears to improve the success rate for the affected
devices. There is obviously a small performance penalty, but being able
to establish a reliable connection with all devices is more important.
For the devices in the list below, the last 512 bytes of the memory area
are not part of the profile ringbuffer. The real purpose of these bytes
is currently unknown.
Oceanic Atom 2.0 (firmware 3I or greater)
Oceanic Geo 2.0
Oceanic OC1
Oceanic ProPlus 2.1
Oceanic Veo 2.0
Oceanic Veo 3.0
Sherwood Insight
Sherwood Wisdom2
Tusa Element II
Tusa Zen
Tusa Zen Air
Some but not all of these devices also have an unreadable last page,
making the autodetection code even more complex.
Especially the version commands seems to be sensitive to errors. Once
the initialization phase is over, a delay is usually not necessary, but
it should cause a noticable slowdown either because errors are supposed
to be rare.
When trying to read the last memory page from an Oceanic Atom 2, the
device does not respond. Strangely, other compatible devices are not
affected by this problem.
The Geo 2 appears to respond with a single NAK byte instead of three.
The issue is fixed by expecting only a single byte, and flushing the
serial line to discard all other bytes (if there are any).
To be able to cancel an operation, an application should register a
callback function that returns a non-zero value whenever the active
operaton should be cancelled. A backend can invoke this callback function
to query the application for a pending cancellation request.
