kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

> 
> 
> 
> Dick
> 
> 
> _______________________________________________
> 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
>