← Back to team overview

kicad-developers team mailing list archive

Re: New part file format document.


Could the schematic support multiple parts lists?

I'm thinking of the problem supporting different builds say a European version or a US version where the schematic is the same but with component value changes due to, for example, 50Hz or 60Hz supply or the different voltages, regulations etc.


On 16/12/2010 18:15, Dick Hollenbeck wrote:
On 12/16/2010 10:33 AM, Wayne Stambaugh wrote:
On 12/16/2010 10:22 AM, Dick Hollenbeck wrote:
On 12/16/2010 08:12 AM, Wayne Stambaugh wrote:
On 12/16/2010 7:18 AM, Brian Sidebotham wrote:
On 16 December 2010 02:31, Wayne Stambaugh<stambaughw@xxxxxxxxxxx>  wrote:
On 12/15/2010 9:19 PM, Karl Schmidt wrote:
On 12/15/2010 07:30 PM, Brian Sidebotham wrote:

When placing components such as passives (mainly R's and C's) you come
across the common problem that you draw the symbol either horizontally
or vertically. When you place the component it could be in one of four
orientations, but generally it's either 0deg rot (horizontal) or 90deg
rot (vertical).
This is called Schematic symbol alternatives - usually you only need 2
versions (bridge circuits need a 45 makes 3 versions) - most CAD systems
have this - and its nice.  I added this to my wiki's wish list.
This would this not be a feature in the schematic capture program?  An
excellent idea but I don't see it as a requirement of the part file or
the part file editor.

It does need a way of telling the schematic capture how to choose a
look for a component. However, I think the functionality is allowed
for in the current spec already. The different versions can be
alternatives, then it is down to the GUI design to make these
alternatives easy to select on a per-component instance basis which
I'm sure is possible, and if I remember rightly desired by Jean-Pierre
for large logic designs too for selecting deMorgan.

So I think this is already covered, I hadn't thought about using
alternatives for this in the part spec. This also covers different
pinouts for processors that are available in different packages.

The only thing not covered for me then would be one schematic pin to
many footprint pins support. I can't see a nice way of doing that yet.
It's only a nice-to-have anyway, and that's only my opinion which
generally seems to differ from most others! ;)
Conceptually its a merge action so the syntax would look like:

(pin_merge PIN_LIST)
The danger on the mailing list, or in any conversation, is not adequately reading or

This is not a bad idea.  If we can have the above verb, i.e. "_merge" during parsing mean:

1) hide all pins but the first by toggling a flag in the pin C++ structure.

2) and control how the netlist is generated later

Then you are done.  The idea may actually be good after all.

We need to avoid having to parse during DRAWING of the part, that would be a bad
design, but I think we've steered clear of that with this option.
Makes sense to me.  The only question left to answer is do we limit pin merge
to inherited parts only or do we allow it anywhere.
If in the PART class, we support a list of lists:

i.e. list of merge lists in binary form, then they can be carried forward in the

PART::Inherit( PART* base ) function just fine from base parts.  This function is
essentially an application specific

PART:: operator=()

like function.  It needs to copy all the pins, even onces hidden via merge in base,
and the already parsed binary merge lists.

PART::Format(?)  should be do-able also, I will put some ideas into design.h soon on that.


Commas:  not really used in s-expressions, got whitespace for separation of list elements.

Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Follow ups