duane> $TARGETNAME mdw
david> Though "mdw" is really impractical for scripting.
yea, it's probably a very bad example, one probably needs to use
'$targetname mem2array" or "$targetname array2mem", or we can create a
helper sub-command
david> A third option: too painful to use. How exactly is $_TARGETNAME
david> going to get *into* the event handler since nothing binds the right
david> value to that name??
david> I'll tell you how. By hard-wiring a particular target name.
I presume you mean the $_TARGETNAME will not be valid when the event is
invoked. TK handles events with things like %w for the window path,
treating the event handler body sort of like an "sprintf()" format
string. Sadly, JIM is not that complicated, I thought about adding a %T
for the current target name. That would be a good future enhancement.
But - today I think what you mean is this:
Today, all target reset handlers are done like this:
$_targetname configure -event reset-init { CURLYBRACE }
TCL variable parsing rules mean that things in { CURLYBRACE } are not
not expanded right now.
The *could* be done like this:
$_targetname configure -event reset-init "double-quoted-string"
In the double-quoted case, the "double-quoted" method would cause the
embeded $_TARGETNAME to be expanded prior to invoking the "configure"
sub command.
david> Some of that's a general event handler issue: the event handlers
have no invocation-specific context.
There is no doubt in my mind there are giant dragons we do not know about.
david> [snip] But "reset halt"means I get a bare CPU, in need of
serious re-init, and using a slow JTAG clock...)
Good example of that is a complex multi-target board. However, that
senario presents an N-way way combination that we cannot today make
reusable code for. We can, however document each thing seperately - so
that the user/victim can figure out how to weave the two reset processes
they need together.
-Duane.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
