On Tue, Sep 15, 2009 at 10:48 PM, David Brownell <[email protected]> wrote:
> On Tuesday 15 September 2009, Ųyvind Harboe wrote:
>> Can we strip away the "memory" from reset_config?
>>
>> I.e that it just *sets* the flags, ignoring any previous state.
>
> It just sets what you tell it to set ... ignoring anything
> you didn't tell it to change.  No confusion possible!  There
> are no hidden/automagic changes carried out on your behalf.
>
> I'm opposed to changing that because it would make it impossible
> to just tweak the *existing* JTAG adapter configuration without
> crapping on unrelated stuff you have no reason to know about.

Is this used today?

I have only seen examples about users being confused that
the effect of invoking "reset_config" depends on previous history.

>> If target & board scripts need to communicate they can do it in
>> tcl.
>
> Actually, they can't ... not without mechanisms (or at least
> conventions) that don't exist today.
>
> A change that could be useful is adding a way to see that config
> data in TCL.  Maybe just having the no-params "reset_config" call
> return the currently-applicable strings.  (Not display; return,
> so TCL scripts can use those values.)

What I'd like to see is reset_config split into two:

- one tcl proc that implements the reset_config scheme to manipulate
the existing
state(reset_config as-is)
- a low end function(in C) that just sets the flags passed in, ignoring
any previous history.



-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to