[PATCH 3/6] Cochran: Dump function no longer assumes reads begin at byte 0

[John Van Ostrand]

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

> On 2017-07-15 22:39, John Van Ostrand wrote:
>
>> For previously supported Cochran computers high-speed read of
>> log and profile data started at byte 0. Older models that lack the
>> high-speed transfer function use the standard speed read commands
>> and so the log and profile data are read at higher addresses.
>>
>
> I don't really understand the reason for this change. With this change you
> are only downloading the memory area containing the logbook and profile
> ringbuffers, and not a full memory dump. Can you explain why you changed
> this?


I figured I should start staging changes into patches that are more easily
reviewed and doing it in a way that still results in a good build in case a
build occurs at the commit. This patch is a staging patch intended to set a
path for support for Commander TM computers. This patch also fixes an
assumption I made in _device_dump.

Prior to this patch the read command that read the log and profile data
always had addresses that started at 0. Log data always started at 0 and
profile data followed after. So layout->rb_logbook_begin for every computer
was always 0x0. In _device_dump I should have used this variable but I used
a hard coded 0. Using the variable makes more sense.

In effect, this patch doesn't change what the dump contains for computers
supported at the time of this patch. A dump done after this patch matches a
dump done prior to it.

As to downloading *all* memory I presumed it wasn't supposed to dump all
memory. I presume it was only supposed to dump log and profile data.

There may be two reasons why I thought the device_dump was only intended to
dump the user data, i.e. logbook and profile data. Prior to my patches
currently under review, the code uses what I now realize is a high-speed
read function which seems intended to only download log and profile data
probably because of the large size. I was confused when working with the
older Commander TM models because the high-speed download commands didn't
work and I had no reference to how to download it (i.e. no vendor program
to observe.) Then I decided to brute force it recently, take the DC apart,
obtain the IC specs, and try a wide range of commands. I realized that the
read commands I've been using to access some data on new models were
generic low-speed read commands and I could use them to access all memory
areas on the older computer. Because it had randomized SRAM logbook and
profile data it took a while to find the user data. It starts at 0x10000.

I could read all data on the old computer and dump all that data but there
are also 32K of RAM and ROM which I figure only confuses the data and
doesn't help the user much. RAM, being RAM, changes a lot.

That said, I've started experimenting with a simulator that uses a full
memory dump so there might be some benefit to changing this. The new
simulator would be simplified and might be more robust when working with a
less predictable program like the vendor's software.




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