david> 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
