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.
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 packet size for the nemo and puck backends happens to be identical.
But the value for the nemo backend is truly fixed, while the value for
the puck backend can be adjusted. To avoid breaking the nemo backend
when changing the default value, we redefine the packet size explicitly
to the correct value.
The common device structure was used only for sharing the fingerprint
and layout descriptor, but the nemo backend doesn't even store a layout
descriptor, and the fingerprint can equally well be passed around as a
function argument.
Because the user needs to initiate the transfer on the device itself, we
have to wait for an unknown amount of time. The infinite timeout works,
but causes problems if the data never arrives. By polling the serial
line, an application can at least cancel the operation.
The total memory size is hardcoded again because the protocol does not
allow to retrieve the correct memory layout in advance. As long as there
is no device with a different amount of memory, that should be fine.
Using a resizable memory buffer allows to allocate the right amount of
memory inside the backend, avoiding having to know the required buffer
size in advance.
The memory layout of the Mares Puck and Nemo devices is very similar,
which allows to share the parsing code between the backends.
The Mares Puck protocol allows for a more efficient implementation, by
reading only the data that we really need. But as an intermediate
solution, reusing the Nemo code is good enough.
