On Monday 31 August 2009, Michael Schwingen wrote: > > 3) One feature that I think may make sense to add at some point in the > > future to the main software is support for label/value associations that > > allow hexadecimal register values to be associated with more legible and > > understandable names. Looking at "mww 0xffff3ec2 0x2" in a configuration > > script is more likely to introduce mistakes during reuse, then say "mww > > some_xyz_register 0x2" where the name of the register clues you into what it > > does or at least where to find it in the datasheet. > > > Agreed. I wonder if this is already possible now?
Yes: set some_xyz_register [dict get $regs some_xyz_register] And be sure that $regs is defined in contex to match that core; don't have it be global, allow for separate cores on the same scan chain. More typical might be using that for controller base addresses, so that when a chip variant relocates the address you can just continue to use the relevant offset: set xyz_base [dict get $regs xyz_base] set some_xyz_register [expr $xyz_base + 0x28] Yes, annoying and tedious typing required. All the more reason to adopt some conventions there, and facilitate reusing them between compatible chip families... I've started doing that for the DaVinci chips, but haven't finished it. (As noted, there are some subtle differences. The clock controller versions are not fully compatible, and Tcl isn't as friendly for programming as C-ish languages are.) The AT91 family chips are a lot more compatible in those respects. Re the notion of reusing C #defines supplied by some vendors, that's the reason at least some JTAG tool vendors use languages which facilitate such stuff, not Tcl. :) - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
