On 2014-12-22 22:13, John Van Ostrand wrote:
On Mon, Dec 22, 2014 at 2:48 PM, Jef Driesen jef@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