On 18 May, 2015 - Linus Torvalds wrote: > On Mon, May 18, 2015 at 10:39 AM, Anton Lundin <[email protected]> wrote: > > > > That might be a good thing to implement as a "memory dump" function in > > libdivecomputer. That way users with future potential problems already > > have a tool to produce the debug data needed. > > So with old-style dive computers libdivecomputer supports that dump > facility. But the EON steel really doesn't have a notion of a memory > dump that you parse to figure everyting out. So while it would be > easy to dump individual dive files, for debugging things like "I don't > get all dives" you really would need to dump all the other > interactions with the dive computer. And that's just not how the > regular libdivecomputer dump support works. > > It would be a one-off special thing for the EON Steel (or we'd need > some new libdc model for dumping the actual data packets going > back-and-forth). >
I rather thought that you write a custom dump format which where you pretend to run a full download of all dives, and write those packages into a dump buffer, for you to later debug and verify the download process. Yea, its not a "real memory dump" but to me it sounds like the sanest way to actually produce a usable debug dump. I and Jef discussed doing such a "dump" format for the OSTC3/hwOS computers but when I figured out how to actually dump the real memory I opted for doing a real dump of the external eeprom. In the case of the EON Steel, writing a communications dump of a full download might be the only good way to write a "dump debug tool", and abusing the memory dump infrastructure is probably close enough. //Anton -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
