Duane Ellis pisze: > As an *end*user* if I saw a sequence of filenames that I recognized I > could examine a few of them - see the simple pattern and settings and > could probably follow that simple pattern successfully. By simple I > mean: perform lots of "set VARNAME VALUE" - then include/source a > common file. > Most developers would understand and modify a simple TCL statement like > this with great success: > > # This chip has 16K flash.. > set FLASH_SIZE 0x4000 > > But instead, using Freddies' approach - one has to (or is lead to > believe they must) read through the "complicated internals" file which > is where lots of magic is happening - magic that is to the benefit of > the maintainer who understands the complexities of the chip family, and > the scripts, and perhaps knows a little bit of TCL.
I still cannot agree on that. Which version is better: Your: > global CHIPNAME > set CHIPNAME lpc2103 > global FLASH_SIZE > set FLASH_SIZE ... > global RA_SIZE > set RAM_SIZE ... > global RESET_CONFIG > set RESET_CONFIG srst_and_trst > global VARIANT > set VARIANT lpc2000_v2 > global CRYSTAL_FREQ > set CRYSTAL_FREQ 12000000 > global JTAG_FREQ > set JTAG_FREQ 1000000 > > source [find target/lpc2xxx_internals.tcl] or mine: > set CHIPNAME lpc2103 > set CRYSTAL_FREQ 12000000 > set JTAG_FREQ 1000000 > > source [find target/lpc2xxx_internals.tcl] With your version the first thing the end user would notice is "what the hell is the variant?" and that does not matter to the end user which flashing algorithm OpenOCD uses. For LPC2xx8 he would enter: FLASH_SIZE 0x80000, start the OpenOCD and be puzzled that this value is invalid, because you need to dig deep to find out, that the top 12k are occupied by bootloader. The same goes for RAM, user would enter 40kB for lpc2148, and that would not be right, as only 32k of those are on the local bus, the rest is for USB DMA. Sure - eventually all would figure that out. But that's easier to figure out just the name and the clock, not all the parameters. Using my version of the file you can do exatly the same as with your version, as ALL variables can be overriden. The bonus is that you do not need that "global sth" everywhere. You can use that script for a chip that is not implemented there withou any trouble. You suggest "taking the developer hat off", but it seems that your's is on all the time. End users do not mess with the config files - what for? 99% of the time they are good, so why change anything there? Anyway - what would you like to change? Beside JTAG_FREQ and CRYSTAL_FREQ all other parameters are useless for normal user. I also see no reason for the user to dig through the _internals.tcl file... 4\/3!! _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
