<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 11, 2017 at 10:18 AM, Jef Driesen <span dir="ltr"><<a href="mailto:jef@libdivecomputer.org" target="_blank">jef@libdivecomputer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-08-10 19:32, John Van Ostrand wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Thu, Aug 10, 2017 at 11:00 AM, Jef Driesen <<a href="mailto:jef@libdivecomputer.org" target="_blank">jef@libdivecomputer.org</a>><br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So this means that the byte sequences:<span class=""><br>
<br>
05 9D FF 00 43 00<br>
05 BD 7F 00 43 00<br>
<br>
that are send in the cochran_commander_read_id() function are actually<br>
read operations at the addresses 0xFF9D and 0x7FBD (and a size of 0x0043<br>
bytes). Interesting. I didn't realize that before.<br>
</span></blockquote><span class="">
<br>
<br>
It seems so obvious, but yes, that's exactly what it means. It didn't dawn<br>
on me until I had to get creative reading the Commander TM.<br>
</span></blockquote>
<br>
Having less "magic values" is always nice!<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-       // Read the sample data, from 0 to sample end will include logbook<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-       rc = cochran_commander_read (device, &progress,<br>
device->layout->rb_logbook_beg<wbr>in, dc_buffer_get_data(buffer),<br>
device->layout->rb_profile_end<wbr>);<br>
+       // Read the sample data, logbook and sample data are contiguous<br>
+       rc = cochran_commander_read (device, &progress,<br>
device->layout->rb_logbook_beg<wbr>in, dc_buffer_get_data(buffer), size);<br>
        if (rc != DC_STATUS_SUCCESS) {<br>
                ERROR (abstract->context, "Failed to read the sample<br>
data.");<br>
                return rc;<br>
<br>
</blockquote>
<br>
This can't work. The size variable is calculated as:<br>
<br>
layout->rb_profile_end - layout->rb_logbook_begin<br>
<br>
For the Commander TM that is 0x010000 bytes (0x020000 - 0x010000). But the<br>
size field in the command is only 16 bits wide. So you'll try to read 0<br>
bytes. Oops. I think the only solution here is to split the large read<br>
operation into multiple smaller blocks.<br>
</blockquote>
<br>
<br>
I thought so too but when I ask for ask for 0 bytes it returns 32K.<br>
</blockquote>
<br></span>
That's a bit weird, but if it works, fine. The rationale behind it is probably that doing a read operation for 0 bytes makes little sense, so they can re-use that value to mean 0x10000. In that case we should probably add some extra checks:<br>
<br>
if (size > 0x10000)<br>
    return DC_STATUS_INVALIDARGS;<br>
<br>
if (size == 0)<br>
    return DC_STATUS_SUCCESS;<br>
<br>
and some comment saying that 0 is interpreted by the device as 0x10000. Otherwise someone will ask the same question in the future. And by that time we probably forgot about that detail :-)</blockquote><div><br></div><div>Good idea. </div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>John Van Ostrand<br></div><div>At large on sabbatical<br></div><br></div></div>
</div></div>