Oceanic / Aeris A300CS multipage patches

[Jef Driesen]

On 14-10-14 19:27, Dirk Hohndel wrote:
> On Tue, Oct 14, 2014 at 06:41:29PM +0200, Dirk Hohndel wrote:
>> as discussed earlier today, here are patches that implement aligned
>> multipage reads and mixed blocksize reads ONLY for dive computers that
>> support 256 byte page reads. So far that appears to be only the A300CS but
>> my guess is that we'll see more such dive computers in the future.
>>
>> This way we should get performant downloads from the A300CS without
>> risking to break older dive computers.

Man, you're fast! You have a patch ready before I'm even home :-)

Looks good to me. Just one comment. Are you aware that you are only creating 
aligned reads for the profile data, and not the logbook data?

> BTW: if you'd prefer we could add another field (something like
> "mixed_pagesize_support") to oceanic_atom2_device_t and then could enable
> this for those dive computers with 128 byte pages where we can test and
> verify that this works. That would make it less of a special case for the
> A300CS. I wasn't sure which version you'd prefer, so I implemented the
> A300CS specific one (or actually, the 256 byte page specific one), but I'm
> happy to go the other direction if you think that's better.
>
> Actually, the more I think about it, maybe that's the better way in case
> Oceanic / Aeris come out with a 256 byte page read model that doesn't
> support mixed paged sizes...

I'm not sure if this really helps. A model that doesn't support mixing page 
sizes, will likely no longer support the smaller page size and always require 
the larger page size. (That appears to be what's happening with the F11.) But 
your "mixed_pagesize_support" patch does exactly the opposite: it falls back to 
using single pages only. But why would you enable bigpage in the first place? 
Just keep it at one, and you're done. Or am I missing something else?

With that in mind, I think your first set of patches is the better one.

[The more I think about it, the more I actually like the idea of the caching. 
Internally we can always use a fixed page size, regardless of the requested 
size. Thus completely transparent to the calling code. But okay, let's proceed 
with your latest patches now, and we'll look at what needs to change for the F11 
once we have more info about that. [Me thinking out load now] I wonder if we 
would even need a full cache? Since libdivecomputer always reads successive 
pages, we basically only need the latest page again. Another thing that we may 
have to watch out for, are those few models with an inaccessible last page. But 
I think I've only seen that for devices which support the B1 read, so that 
should be fine.]

Jef