[PATCH 2/6] Cochran: Added descriptors for early Commander

[John Van Ostrand]

On Thu, Aug 10, 2017 at 10:55 AM, Jef Driesen <jef at libdivecomputer.org>
wrote:

> On 2017-07-15 22:39, John Van Ostrand wrote:
>
>> -#define COCHRAN_MODEL_COMMANDER_PRE21000 0
>> -#define COCHRAN_MODEL_COMMANDER_AIR_NITROX 1
>> -#define COCHRAN_MODEL_EMC_14 2
>> -#define COCHRAN_MODEL_EMC_16 3
>> -#define COCHRAN_MODEL_EMC_20 4
>> +#define COCHRAN_MODEL_COMMANDER_TM 0
>> +#define COCHRAN_MODEL_COMMANDER_PRE21000 1
>> +#define COCHRAN_MODEL_COMMANDER_AIR_NITROX 2
>> +#define COCHRAN_MODEL_EMC_14 3
>> +#define COCHRAN_MODEL_EMC_16 4
>> +#define COCHRAN_MODEL_EMC_20 5
>>
>
> These values are now out of sync with the ones in src/descriptor.c:
>
> --- a/src/descriptor.c
>> +++ b/src/descriptor.c
>> @@ -297,6 +297,7 @@ static const dc_descriptor_t g_descriptors[] = {
>>         {"Cochran", "EMC-14",           DC_FAMILY_COCHRAN_COMMANDER, 2},
>>         {"Cochran", "EMC-16",           DC_FAMILY_COCHRAN_COMMANDER, 3},
>>         {"Cochran", "EMC-20H",          DC_FAMILY_COCHRAN_COMMANDER, 4},
>> +       {"Cochran", "Commander TM",     DC_FAMILY_COCHRAN_COMMANDER, 5},
>>  };
>>
>
> That's not only confusing but also breaks the parser side when using the
> dc_parser_new2() function. That function obtains the model number from the
> descriptor, while the dc_parser_new() gets it from the devinfo event.


Okay, I did a re-arrangement, the wrong way again, based on the assumption
that no Cochran users are storing dive blobs for later processing.


-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20170810/9809c03c/attachment.html>