Partial push of Josh's configure-dive-computer GSoC project

[Jef Driesen]

On 14-08-14 17:15, Thiago Macieira wrote:
> On Thursday 14 August 2014 13:08:10 Jef Driesen wrote:
>> On 2014-08-14 12:15, Anton Lundin wrote:
>>> Firmware version looks bogus. It says 286 when i have 1.30 currently on
>>> my ostc3.
>>
>> It's correct. You only have to decode the number correctly :-)
>>
>> The value 286 is 0x011E in binary. The highest byte (0x01 or 1) is the
>> major number of the firmware version, and the lowest byte (0x1E or 30)
>> is the minor number.
>>
>> This is encoding is necessary because libdivecomputer always returns the
>> firmware version as a single integer. Thus somehow the two byte firmware
>> version needed to be packed as a single number.
>
> Is that guaranteed to be the same way for all cases?

What do you mean with "all cases"? For the OSTC it will always remain the same, 
unless HW suddenly changes their dataformat (for example 3 bytes instead of 2). 
If you mean for all backends, then no, each backend may use it own encoding.

I assume you get firmware version from the devinfo event? Unless you extract the 
firmware version from the raw data yourself, that's the only place where 
libdivecomputer exposes the firmware. But initially this firmware number was 
intended for internal use only. It was added in case one of the parser would 
need the firmware version (e.g. change of data format after a firmware upgrade). 
But so far that was never needed, because either the format never changes, or if 
it did like in the case of the ostc, the format version was embedded in the dive 
data. For this purpose, the actual encoding doesn't matter because obviously 
libdivecomputer knows how it encoded it.

But now we're of course stuck with this one integer firmware version that's not 
necessary human readable (same applies to the serial number).

Jef