Splitting my response here in two parts ... this first one seems more in the "after 0.2.0 ships" territory.
On Saturday 06 June 2009, Rick Altherr wrote: > On Jun 6, 2009, at 1:20 PM, David Brownell wrote: > Sorry, I thought you were recommending naming things such as > "omap3530" for both the target and TAP. As long as we stick to > descriptive names such as "omap3530.cpu" for both, I'm OK with it. But Duane suggests e.g. omap3530.cpu (target) vs omap3530.cpu.tap .. > The confusion can partially be resolved by changing the layout of the > commands. Right now, the TAP-related commands are spread out (some > are under JTAG, some are top-level (irscan, drscan), etc). The target > commands are less so, but still are to an extent (targets are created > with 'target create', but every other operation is done on the target > name rather than 'target <target_name>'). If we straightened out the > commands such that it is obvious which namespace we are working in, > then the confusion of overlapping namespaces would be reduced > considerably. I could see "jtag irscan" etc (better: "jtag execute $arrayname"). But remember that "irscan" and "drscan" apply to the entire scan chain, not individual TAPs; there aren't many commands to address individual TAPs. That'd seem post-0.2.0 no matter how it all shakes out. > I'd still prefer to keep the -chain-pos portion of the > target command since I'd not a fan of automagic operations. We could > make it optional and have the default be the target name, but I'd like > to keep the option of being explicit and to allow for non-standard > naming. That's where I started. Easier to explain that way too: it works <this simple/obvious way>, unless <advanced wierdstuff>. Then I noticed that there *is* no such wierdstuff today, and so I entertained the slightly subversive thought that we should try to do without the wierdstuff for as long as possible, and at least until we have real use cases for it. > As long as the command structure and documentation make this obvious, > it's fine. As it stands today, it's not obvious that the reason > 'halt' failed it because it is trying to use the current target name > as a command, but that target doesn't exist. This gets worse if you > have more than one target. However, nothing you've said offers a *fix* for that bug... _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
