[PATCH 08/11] Add code to write rom of the OSTC3

Jef Driesen jef at libdivecomputer.org
Wed Dec 17 02:48:17 PST 2014


On 16-12-14 20:06, Anton Lundin wrote:
> On 16 December, 2014 - Jef Driesen wrote:
>
>> On 2014-11-21 21:28, Anton Lundin wrote:
>>> +static dc_status_t
>>> +hw_ostc3_device_write_block (dc_device_t *abstract, unsigned int
>>> addr, unsigned char block[], unsigned int block_size)
>>> +{
>>> +	dc_status_t rc = DC_STATUS_SUCCESS;
>>> +	hw_ostc3_device_t *device = (hw_ostc3_device_t *) abstract;
>>> +	dc_context_t *context = (abstract ? abstract->context : NULL);
>>> +#if 0
>>> +	// FIXME: This variant doens't work
>>> +	// Things doesn't get written to memory. Timing issues?
>>> +	// Version below works, serial_sleep (2) is probably the thing.
>>> +	unsigned char buffer[4 + block_size];
>>> +	buffer[0] = WRITE_BLOCK;
>>> +	uint24_be_array(addr, buffer + 1);
>>> +	memcpy(buffer + 4, block, block_size);
>>> +
>>> +	rc = hw_ostc3_transfer(device, NULL, WRITE_BLOCK, buffer,
>>> sizeof(buffer), NULL, 0);
>>> +	serial_sleep (device->port, 1100);
>>> +	return rc;
>>> +#else
> ...
>>
>> With the exception of those sleep calls, that's identical to the
>> hw_ostc3_transfer() function. Notice how your code is missing the read of
>> the echo. I'm pretty sure that got lost due to the flushing. So this
>> probably works correctly only by accident.
>>
>> The reason why hw_ostc3_transfer doesn't work for you, might be because you
>> include the WRITE_BLOCK byte in the input buffer. That causes it to send
>> twice. The ostc probably doesn't like that. Can you have a look at this? I
>> have the feeling that we can use hw_ostc3_transfer here after all. Worst
>> case we may need to add those sleep calls there, wrapped in a "if (cmd ==
>> WRITE_BLOCK)".
>>
>>> +	n = serial_read (device->port, &response, sizeof (response));
>>> +	if (n != sizeof (response) || response != S_READY)
>>> +		return EXITCODE (n);
>>
>> You should split those checks in two parts. Right now you'll return
>> DC_STATUS_TIMEOUT when response!=S_READY, and that's misleading. If we can
>> re-use hw_ostc3_transfer, then this is no longer an issue.
>>
>
> After i started to rewrite the code for like the .. 7th time i spotted
> the bug in the hw_ostc3_transfer-based variant, and indeed it was the
> extra WRITE_BLOCK i never spotted.
>
> Now the hw_ostc3_device_write_block-helper looks like this:
>
> static dc_status_t
> hw_ostc3_device_write_block (hw_ostc3_device_t *device, unsigned int addr, unsigned char block[], unsigned int block_size)
> {
> 	unsigned char buffer[3 + block_size];
> 	array_uint24_be_set(buffer, addr);
> 	memcpy(buffer + 3, block, block_size);
>
> 	return hw_ostc3_transfer(device, NULL, WRITE_BLOCK, buffer, sizeof(buffer), NULL, 0);
> }
>
>
> Just like hw_ostc3_device_read_block, and works just fine.

Excellent news! Just one comment. Use a fixed size array here. Variable Length 
Arrays (VLA) are not supported in C++, so this breaks msvc compatibility :-(

There are also a few other minor issues for msvc. See the attached patch.

(For the snprintf function, I should make some helper function, because the 
semantics of the msvc _snprintf is quite different. For example it does not 
always null terminated the string, which is really bad. What the hell where they 
thinking?)

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip_msvc.patch
Type: text/x-patch
Size: 1172 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141217/78ccd3bb/attachment-0001.bin>


More information about the devel mailing list