kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

Simon,

Hang on to this thought.  We are limiting the discussion to the part file
format.  The schematic file format discussion will happen after we've nailed
down the part file.  I want to keep the focus narrow so we can get this done in
a timely manor.

Wayne

On 12/16/2010 3:50 PM, Simon Rogers wrote:
> 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.
> 
> Simon
> 
> 
> 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.
>>>>>>>
>>>>>>> Wayne
>>>>>> 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
>>>> listening.
>>>>
>>>> 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
> 
> _______________________________________________
> 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
>