Re: gEDA-user: Parts DB API

[DJ Delorie <dj@xxxxxxxxxxx>]

> Pin numbers on the schematic _ARE_ back-annotation from the part of
> the work-flow which maps light->heavy.

That works too.  IIRC, the technical problem is that gschem has no way
of adding attributes to pins at the schematic level, unless the symbol
is embedded.  As we all know, I'm not a fan of forced embedding, so
we'd need some technical way of referencing an existing pin in a
schematic.  Something like:

C ...
{
PM "attrname" "attrvalue" [(OR|AND) "attrname" "attrvalue" ...]
{
T ...
attrname=attrvalue
}
}

PM means "pin match", which means it looks for a matching pin.  I
think one name/value match is sufficient, but I'm open to reasons for
more complicated matching parameters.

The T is trickier.  If the attribute is new, we want it to have enough
information to place the attribute on the schematic properly.  This is
especially true for pin numbers - you want them to be positioned
nicely.  If the attribute is an override, we can ignore the new
position information and re-use the old stuff.  That way, special
needs of special symbols can be accomodated.

I suppose we could have a separate attribute verb, that sets an
invisible attribute without needing to specify a location, size,
color, etc.

This, of course, obsoletes the old way of managing slots.

As for *how* the attributes get there, well, there are many ways.
gschem can add them as attributes to the pin, just like it adds
attributes to symbols.  Gattrib already has a "pins" tab that's
unused.  Scripts can add attributes as needed.  Some BOM manager can.
PCB can.  The project manager can.  Etc.

Whether to store attributes there, or in some BOM file, is not a
technical choice - it's a policy choice.  We can do either or both,
but I think at least pin numbering needs to be done in the schematic.


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