kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.