Eon Steel only downloading 16 out of 19 dives

Anton Lundin glance at acc.umu.se
Tue May 19 02:38:35 PDT 2015


On 18 May, 2015 - Linus Torvalds wrote:

> On Mon, May 18, 2015 at 10:39 AM, Anton Lundin <glance at acc.umu.se> 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


More information about the subsurface mailing list