On Saturday 06 June 2009, Duane Ellis wrote: > duane> $TARGETNAME mdw
Though "mdw" is really impractical for scripting. The "memread32" thing would be better ... but notice that *it* ignores $TARGETNAME too, for much the same reason other scripts can't use it. > 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. A third option: too painful to use. How exactly is $_TARGETNAME going to get *into* the event handler since nothing binds the right value to that name?? I'll tell you how. By hard-wiring a particular target name. Which means non-reusable code. But ... the entire point of switching to that new "$target_name mww addr value" is reusability, right? By decoupling from the "current target" notion. Else there's no reason not to continue using un-adorned "mww"... Some of that's a general event handler issue: the event handlers have no invocation-specific context. They have to be coded to know they're working on a specific target and event. They can't know if the "reset-init" code is going to run later, or if the reset mode is "run". (Example: "reset run" normally means the first stage loader will run and set up clocks, so jtag_khz can be upped from pokey-slow to something non-painful. Likewise with "reset init". But "reset halt" means I get a bare CPU, in need of serious re-init, and using a slow JTAG clock...) > 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) Also known as "require an armload of zeroes before the only useful parameter". What's the "preferred" number of zeroes lately ... a dozen? Sooo easy to lose count there. :( > It's not thrash if it becomes *in*line* documentation, I'm in favor of non-positional paramters, but that's unrelated to my point: that the changes you suggest touch a *LOT* of code, forcing a flag day ... but for relatively minor benefit. One could for example adopt the coding convention incrementally, withoug the "flag day" provision of your "part #1". No code thrash at all. > think +2 years > from now, with +10 more targets, and +10 more boards, they will be > better documented, that is the bigger win. If only ten more targets and boards appear in two years, this project won't have lived up to a fraction of its potential. Heck, I've got at least five more ARM boards I could hook up, and a few non-ARM ones. Expect at least ten more boards by the 0.3 release, and that should be a more realistic model. Maybe they won't all have nontrivial configs -- as in, DRAM initialized, and OpenOCD can replace their bootloaders -- but I think there must be a lot of "low hanging fruit" lurking. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
