Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-dd-dev] Re: FW: Load/save/fill memory operations


I'll be more than happy to yield this feature to you :-) I've got a million other things to do, so I have no problem letting this one go. This is a must-have feature for our first Eclipse based product, and that's why I was going to jump on it. If you were planning on contributing this anytime in the next six months or so, that would work for us. And of course, I'll be more than happy to work with you on the feature if you'd like to team up on it.

See my comments inlined below:

At 09:36 PM 4/3/2006, Williams, Ted wrote:


Yes, I've been planning to contribute such a feature, but (oops) I
wasn't aware of the bugzilla. If you're planning to implement this soon,
I'll hold off. :-)

I understand the feature will be extensible, but I'd like to add a few
thoughts in addition to what I see in the bugzilla.

- The reading/writing should happen on a Job. Large chunks can take
substantial time to transfer to and from embedded targets. The cancel
flag should be checked periodically, between read and write requests.


- Would a verify option (checkbox in the dialog, read and compare after
write during the download) be useful?


- There may be some overlap with the "copy to clipboard" action. Maybe
copy and paste could be shortcuts to import/export actions or at least
some of the code could be reused? Export to textual is similar to copy.

Indeed, there's overlap, but I'm not sure there will be a good mapping between copy&paste and the actions. If we can think of copy&paste as an import/export action with a fixed, pre-defined set of parameters...but even there, the destinations are quite different. I imagine there's potential for code reuse but not a direct link between the two sets of actions.

- Any thoughts on supporting expressions in the address field of the
import/export dialog?

I think Samantha and I were envisioning import/export being retargetable actions that could be invoked from, say, the context menu of the variable view and _expression_. To that extent, expressions would be supported, but such an action would bring up the dialog with the physical ptr/variable value/address as the start address, pre-populated in the dialog. Whether we should directly support expressions in the dialog...I suppose, but I don't see a pressing need for it.


Back to the top