On 2017-08-10 18:01, John Van Ostrand wrote:
On Thu, Aug 10, 2017 at 10:57 AM, Jef Driesen jef@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.
I know the behavior remains the same for the existing devices. That's quite obvious when reading the code. But that's not what my question was about. It's about this part of your answer:
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.
Memory dumps are not only useful for debugging today's problems. They can also help future development (developing new features, regression testing against old data, etc). But if you only download part of the memory, and it turns out the ringbuffer starts at some other address then your initial assumption, or your new feature needs some info from another area, then the old memory dump is suddenly useless. That's why a memory dump should (ideally) contain everything, and also require as little logic as possible (e.g. no knowledge of a certain address range).
A memory dump typically contains other sections besides the logbook and profile ringbuffer(s) too. For example:
* Ringbuffer metadata (pointers where the next item should be written) * Configuration data (user configurable settings) * Dive computer state (decompression tissue loadings, etc) * ... (lots of things we don't know about)
There is probably lots of stuff we aren't interested in, but that's difficult to tell in advance if you don't even know what's in there. So making sure to include everything is the most future proof :-)
Having said that, if the download protocol uses addresses where certain ranges are mapped to the ROM (firmware code) or even RAM, then that's indeed another story. We're not really interested in that kind of stuff. Just the flash (or some other non-volatile storage technology) where the dives are being stored. But so far I've never seen any dive computer where the download protocol gives access to that kind of data (except for the ostc firmware updater).
Have you checked (on the newer devices), whether a read operation at the same address with the slow and fast commands, yields the same data?
Jef