Re: gEDA-user: How to deal with single/dual parts?

[Henry Von Bank <hvonbank@xxxxxxxxxxxxxxx>]

While I am wasting time with this mailing list when I should be
working, here is how I propose to change the symbol organization.
Feel free to do with this as you wish, including criticizing any of
the (I'm sure many) issues with this proposal.

Symbol file
----------------
The symbol itself should just be a graphical/logical representation of
the device.  It shouldn't even have pin numbers, just labels for each
pin.  The only attributes within it should be related to the graphics:
author, version, license,...   There should be no knowledge of the
physical device, or what it is going to be used for (i.e. pcb
footprint or spice,...).

On a related note, it would be good if in gschem you could select an
object, click edit and change which symbol is being used, without
having to cut/paste and copying over attributes.

After a symbol is placed in the schematic an attribute should be
specified that points to another file containing component or other
info.  This would be equivalent to an import/include statement.  It
should probably just be limited to one of these statements per object,
although you could make a case (see below) for allowing multiple ones
of these.  Also note that when in the design process you specify this
attribute would depend on your workflow.

 Note that a default component could be specified, but I would not
suggest this.  Or when a user is making their own custom parts library
they can specify this.

Component/metadata file
-----------------------------------
This file could use the same .sym extension and be a superset of the
existing format, or a new file format.  It should not have any
graphical constructs in it, but should essentially be a list of
attributes.  However, the big difference would be support for some
kind of macro language, or at a minimum an if/else construct.  In
general, the attributes in this file should be made read-only, and NOT
inherited/copied into the schematic data file, as it would make
switching to a different component a pain.  When the schematic is
loaded, or if some design attribute is changed, the design and object
attributes are first loaded, and then this component file is parsed
using those attributes as input to if statements or other constructs.
The result is that you get a graphical representation and a list of
attributes that can be loaded into the internal data structures just
like before.

For example, in you schematic, you add an opamp, and add an attribute
pointing to a component file for a specific quad opamp part.  You also
add an attribute specifying to use slot 3 to your schematic.  The
component file defines that if slot==3, the pin labeled as IN+ gets
mapped to pin number 8,...  There should also be a numslots defined in
this component file to be used for design checks.

Another thing you could do with this approach is define some global
attributes for you schematic that help define your workflow.  For
example, if a global "spice" attribute is set, spice related
attributes in the component file get used, while if "pcb" is defined,
footprint related attributes are instead loaded.  This could also be
an argument for allowing multiple component/metadata files to be
specified for each object in the schematic, where one component file
is for pcb, one for spice,...


Advantages of this approach
---------------------------------------
- Would not require huge changes to the internals of the programs, as
they should look essentially the same once loaded into data
structures.

- Should be a good migration path, as symbols that do not define the
component/import attribute would be treated as before.

- Should be more flexible for supporting different workflows, and
hopefully allow better ways of organizing component libraries.

Issues/disadvantages with this approach
---------------------------------------------------------
- Would need to find/create a macro language.  Order of operations,
and other things would be need to be specified.  Adding too many
constructs to this language could make symbol creation more work, or
cause incompatibilities between symbols/components created by
different people.

- Would still require updating parsing routines for a number of
different scripts/tools.

- Component files would be more complex than existing symbols.
However, it would be possible to encapsulate more info/intelligence
into these libraries.


-Henry

_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user