duane> $TARGETNAME mdw
david> You'll notice most of the reset-init event handlers can't use that.
CAN'T - or "just happen to not use that" - Big difference.
By design, they should be able to do exactly that, see:
src/target/target.c - lines 3559 ... 3731
By design, it should work, that is why for example how [$TARGETNAME cget
-chain-position] works.
======================
duane> (B) Hidden in C code... effectively enforced, like above, see
target.c
duane> - line 3444..3456
david> That is, the "-chain-position" logic should change?
Yes, exactly. What is happening here is the "tap_by_jim_obj()" is passed
the argument to the -chain-position parameter.
I suggest instead, doing a simple "sprintf()" and add ".tap" as a suffix
here
That can be done *IN*CODE* - or in the CFG file...
One could argue (2)(A) or (2)(B) - either way... it's a toss up.
=====
david> If one were to take your (1) forcing the ".tap" suffix, then IMO
david> the correct route is to take your (2A) and change all scripts,
david> plus (1a) update the TAP naming convention to tell folk not to
david> use "tap" themselves, and (1b) when creating targets, reject
david> any target name with a ".tap" suffix.
I do like your approach - it *enforces* a specific naming scheme that
is unambiguously clear that "foo.tap" is the *TAP* and not the thing the
tap is controlling, be that "boundary scan" or "a cpu", or a "embedded
flash".
david> This seems to me like it'd be much thrash for not much benefit.
In consumer electronics, the most important thing is: "Can the customer
understand/install the product without using the manual". In our case,
that will be impossible, but reducing manual lookups is a good thing.
There's a subtle thing here that I did when I created these new
commands, I quietly enforced inline documentation of parameters in the
script files.
How? I *COULD* have made the parameters positional, ie: 'the 5th
parameter is the tap name' - but i did not on purpose. By *REQUIRING* a
prefix it serves as *EXPLICIT* documentation of the parameters purpose,
one does not need a comment line above the script command explaining the
positional parameters :-)
Look at the "flash bank" command as a *nasty* example.
(tcl/target/sam7x256.cfg - line 48)
Sure, it is extra typing - but - it is *far*less* end user and developer
confusion, after a few parameters I can't keep track of the order of things.
It's not thrash if it becomes *in*line* documentation, think +2 years
from now, with +10 more targets, and +10 more boards, they will be
better documented, that is the bigger win.
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
