On 2015-04-25 18:33, Anton Lundin wrote:
This adds a dump function for the ostc3 series computers. This function dumps the whole external eprom, that contains the dive-headers and the dive data.
Signed-off-by: Anton Lundin glance@acc.umu.se
I haven't seen the code for the simulator, but the relevant parts are that the dive headers are located at: ; 1st: 200000h-2000FFh ; 2nd: 201000h-2010FFh ; 3rd: 202000h-2020FFh ; 100: 264000h-2640FFh ; 256: 2FF000h-2FF0FFh
And in those headers at byte 2 and 5 are the pointers to where in the memory the actual dive profile are, in little endian.
It shouldn't be too hard to write simulator code for that.
The simulator code is located here (as pre-compiled binaries, a tarball, or a patch series against libdivecomputer git):
http://libdivecomputer.org/simulator/
I don't mind applying your patch, but I wonder whether this is the "right" kind of memory dump. For me, the main use case for memory dumps is to be able to replay a download on the simulator. Now, one of the nice features of the ostc3 protocol is that we don't need to know the internal memory layout, and can just ask for the dives. With a raw dump of the eeprom, we'll need all those details again in the simulator. Certainly not impossible, but not ideal either.
An alternative that I have been thinking about, for those devices without support for memory dumps, is to define a simple binary data format that can store multiple dives. That way, the simulator can easily read and send individual dives, all without needing any internal knowledge.
Of course that's not mutually exclusive with your patch, so let's apply it after a few modifications:
- //unsigned int size = (RB_LOGBOOK_SIZE * RB_LOGBOOK_COUNT) +
SZ_MEMORY;
Remove this uncommented code.
- unsigned int size = 0x400000;
Can you add a macro? Something like SZ_EEPROM for example.
// packet size. Can be almost arbetary size.unsigned int len = 4096;
Same here. You can re-use SZ_FIRMWARE_BLOCK here.
// Limit the packet size to the total size.if (nbytes + len > size)len = size - nbytes;
This isn't strictly necessary if the total size is a multiple of the packet size.
Jef