Here, I agree with Duane, The end user want to debug/flash a device -> not a concept of multiple devices.
You may auto-generate the files one time at the MAKE of openocd. Or you may have a separated script, generating this file one time and put these file to the trunk. Regards, Laurent http://www.amontec.com JTAGkey-2 : high-speed USB JTAG adapter / 30Mhz TCK / RTCK / support 1.3V to 5V @ 32ma output drive per IOs / on-board 4 leds for an easy use. > avid> Having a hundred or so chip-specific config files is > david> a messy concept... > > Yes, but that is exactly what is needed. > > If there are 100 chips - you need 100 files, with 100 names. > > Take the "openocd-developer-hat" off for a little bit and think about this. > > Configure files are something *END*USERS* mess with. > > Yes, from our end (the developer end) 100 files is a P.I.T.A, but it is > exactly what the *end*user* needs, or they at least need the *SIMPLE* > means to add the +1 more file they need. > > 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. > > Wearing a "naive new users hat" - I would see the big internal file > Freddie has and assume that I should "weave" my new chip into that file, > and become very confused. That is *NOT* something I think we want users > to do. > > Bottom line: > > 1) Freddies 'internal' file does too much, and does too much > magic about figuring things out. > > It is ok for the 3 of us to understand... > Remember: Our goal is the *end*user* > > 2) We don't need to create 100 files for 100 chips.. instead we > need to create a few of them - such that is very *CLEAR* > to a new user how to add 1 more. > > That's why we converted the configuration files into 3 "source" statements > > (1) the interface > (2) the board > (3) which includes a chip... > > In the past, there was just one configuration file users where weaving > their changes into other files. By splitting them up - it made it easier > to understand. > > SUGGESTION > > Freddie could create a simple textfile/database and generate 100 "chip > files" from a quasi-table of some sort... that only runs in "maintainer > mode". > > BETTER SOLUTION: > > In contrast, if the *SCRIPT* would examine the chip some how - and read > registers and/or other things it *could* configure it self auto > magically. For example ATMEL at91 series parts have some registers in > the DEBUG UART at a fixed address... > > I just don't think this better solution is that easy to implement. > > -Duane. > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
