[PATCH] Cochran_commander refactoring

[Jef Driesen]

On 2014-12-22 22:13, John Van Ostrand wrote:
> On Mon, Dec 22, 2014 at 2:48 PM, Jef Driesen <jef at libdivecomputer.org>
> wrote:
>> On 22-12-14 20:33, John Van Ostrand wrote:
>>> What I meant was that I could not produce a contiguous segment of 
>>> memory
>>> that contained everything, which seemed to be what you thought would 
>>> be
>>> ideal for _dump().
>> 
>> Now I'm even more confused. If I'm right, then for the commander the
>> logbook ringbuffer is from address 0x0 to 0x20000. And the profile
>> ringbuffer is from address 0x20000 to 0x100000. So that's one 
>> continuous
>> block of 1M in size. That would be perfect for a memory dump.
>> 
>> Am I missing something here?
> 
> When I say "everything" I mean info, config and misc data too. That 
> can't
> be read the same way log and sample data is.

Ok, now I understand. The cochran backend is not the only one that has 
this "problem". The oceanic backends are similar in that regard. The 
main memory can be download with a read command, but there is one extra 
packet that contains the id string, which is needed to identify the 
memory layout. So that's very similar to the cochran backend, except 
that you now have multiple extra data packets.

The way I dealt with this for the oceanic backends, is to make the 
dc_device_dump() function return the main memory dump. The contents of 
the version packet is passed back to the application with a vendor 
event. For the simulator, this vendor data gets written to a separate 
file.

Some other backends (reefnet, uwatec, etc) also needs the time from host 
clock, so that goes into yet another file.

For the cochran memory dump we could do something similar. The main 
advantage of using separate files (instead of pre-pending the extra 
data), is that you don't have to mess with an additional offset when 
looking at the memory dump with a hex editor. A memory address will map 
directly to the same file offset. Nice and easy :-)

>> If you're interested in the source code for my libdivecomputer 
>> simulator,
>> then let me know and I'll package it for you.
>> 
> I would be interested.

I have uploaded the source code and pre-compiled binaries to the 
libdivecomputer website. You can find them here:

http://libdivecomputer.org/tmp/

The 000?-*patch files is a patch series against a fairly recent 
libdivecomputer version (134da18190b5ea1581d789564979e3e4c73cd243 to be 
precise). The simulator.tar.gz is the corresponding full source tree.

Currently, the simulator expects two files. The main file (e.g. 
emc20.bin), which you pass on the commandline, is the memory dump. This 
is the data downloaded with the read command, ranging from memory 
address 0 to the end. The second file contains the id, misc and config 
blocks, all concatenated to a single file. This file should be named 
exactly the same as the memory dump, but with an extra ".header" suffix 
appended (e.g. emc20.bin.header). The simulator will load this file 
automatically when present.

I have attached the scripts I used to assemble a memory dump from the 
commander and emc20 data files I received from you.

>> Is it possible to install the Analyst software on my side, and make it
>> talk to the simulator, or load the corresponding CAN files? That would 
>> help
>> a lot. But I can only find a demo version, which seems to have the
>> communication disabled
> 
> The software is an extra charge (with cable) and I recall but it seemed 
> to
> call home to authorize or log an activation.
> 
> Do you want screen dumps? I can also run a USB log and export to CSV. 
> The
> file would include lots of collateral data but it's parseable. The CAN
> files are weaklly encrypted and I finished and submitted the Subsurface
> code to read CAN files. The CAN file contains log entries followed by 
> the
> dive sample data in raw format. Since the addresses in the log don't 
> apply
> to the relocated sample data my code uses something similar to corrupt 
> dive
> parsing.

For the parsing it's always very helpful to be able to work directly 
with the official application. In most cases, screenshots are not really 
helpful, because you can't really explore the data. The ideal solution 
would be if we can get the Analyst software to talk to the simulator and 
feed it a memory dump. This has the additional benefit that you can 
tamper with the data, and observe the effect. But if that's not 
possible, an alternative would to just send the CAN files. Assuming I 
can load those in the demo version of course.

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emc20.sh
Type: text/x-shellscript
Size: 380 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141230/e3f256da/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commander.sh
Type: text/x-shellscript
Size: 444 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141230/e3f256da/attachment-0001.bin>