Stuart Brorson wrote:
My question: Why should this functionality be embedded into gschem?
What's wrong with a separate GUI-based utility which accomplishes the
same effect? Does integration into gschem solve a problem
which can't be solved using an independent utility?
Perhaps it should be a separate tool - I wouldn't rule it out.
I was just thinking about the workflow issues - ideally, if I am editing
a schematic and need to reconfigure the part, I want to click on the
part and change it. Now, if that action launches a separate program that
doesn't really matter to me - indeed, from an implementation standpoint
it probably would be better if a separate program were launched.
Thinking about it, what I would see happening would be there would be an
attribute added to the part definition in the basic symbol library that
would define a "configuration" script/program/whatever file. I'd think
such data would probably be best stored as an XML file that defined the
configurable pins, the available options for each pin, and the
configuration data (register data) for each pin (with possibly some
scripting embedded to handle any weird conditions). In addition, each
instance of a configurable part on a schematic would have one or more
attributes that defined what the configuration output file(s) were
within the project hierarchy (e.g. ${PROJ}/software/cpld1/config.h).
Then the configuration tool would read that XML file and provide the
user interface for the setup.
Probably the "part" would actually be embedded into the schematic rather
than referenced - adding the part would instantiate the part within the
schematic.
I'm coming at this from the standpoint of an embedded software/hardware
designer of 18 years - I have seen too many mis-matches between the data
the hardware types are working with and the data the software types are
working with. Ideally, I want the whole stinkin' project under version
control, and set up so that when the hardware types make a change, that
can drive a recompile on the software side, and ideally so that when the
software types make a change that back-annotates the schematic.
Like I said earlier - when I dream, I dream big - adding features like
that would REALLY make the gEDA suite stand out when compared with the
likes of Mentor Graphics.
