Re: gEDA-user: Matching footprints with symbols

[John Doty <jpd@xxxxxxxxx>]

On Apr 16, 2010, at 10:49 AM, Mike Bushroe wrote:

>     No, that's not what I'm talking about. Footprints depend on the
>     layout tool: gschem is properly agnostic about what layout tool
>     you're using.
>     John Doty              Noqsi Aerospace, Ltd.
>     [1]http://www.noqsi.com/
>     [2]jpd@xxxxxxxxx
> 
>   So that means the shortcoming is with gchs2cpb?

Perhaps the shortcoming is in your expectations.

> We need a better way of
>   stitching two disparate (and intentionally agnostic) tools that
>   newcomers wish to use as if they were an application suite.

The two projects are able to work together *because* they were intentionally designed with clean interfaces, and no unnecessary entanglements. You propose to throw away the very virtue that made the partnership possible in the first place. Some of us want to keep the tools open to other partnerships.

>   We need some way for gsch2pcb to stop at each undefined or unmatched
>   footprint, and since we are running gsch2pcb, we know that the origin
>   of the item is a symbol in gschem, so the symbol can be listed,
>   described, tabulated, or displayed, and then a file browsing window,
>   dialog box, command line menu would open up to go searching to find a
>   matching footprint for that symbol, do some basic reality checks on the
>   pin numbers/names/attributes and possibly either allow the user to fix
>   problems in the symbol or footprint  and save the modified version in
>   the project directory, or allow the user to keep looking for a better
>   match. This would be easiest if done in a GUI like gschem and pcb, but
>   possible even for a command line only interface. Although matching up
>   pins and pads in two text listings of symbol and footprint attributes
>   would be difficult.

One thing that sows confusion here is that "footprint" has different meanings to the person choosing the part and to the person laying out the board. The pattern of pins on isn't the same thing as the pattern of pads on the board, and there isn't a one-to-one relationship. Different manufacturing processes need different pad patterns for the same physical part.

And some design flows don't have footprints (VLSI, simulation, symbolic analysis, ...), although perhaps the hydraulic design process recently discussed here has something analogous ;-)

>      By moving the 'repair' process to gsch2pcb, it would allow gschem
>   and pcb to remain completely agnostic of each other, although to me
>   that sounds more like slightly incompatible with each other. On the
>   other hand, I have never used Spice or any other the other second
>   programs (backends?) that gschem is expected to feed. It may be that
>   with that wider perspective I would be able to see clearly why you want
>   gschem and pcb to remain disjoint. On the other hand, if the interface
>   and conversion programs and scripts between all the tools was more
>   complete, intuitive and foolproof, then the entire package of tools
>   could be combined under a single IDE

Ugh! Yuck! IDE = Inflexible, Dumbed-down Environment. Some prefer that, but shouldn't there remain toolkits for those of us who need flexibility and high productivity automation?

> and act like a unified suite of
>   tools, like I expect most of the commercial packages work.

The commercial package owners have a strong incentive to restrict the flow to tools they control, and make it easy to get sucked into their environments. They have little incentive to give you paths to flexibility or higher productivity once you're caught.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




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