kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/16/2010 12:15 PM, 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.


Well I guess if schematic pins can have non-numeric names, then this is not
necessarily "binary" is it, I guess we are working with strings all the way through.

The merge lists do not get used again until netlist generation time that I can see, or
unless:


The user wants to add in another pin later in derived part, into an existing merge
list.  There's probably a way to do that, sort the pins, create a concatonation of all
the names in the list, use that as a lookup into the list of lists.  Parser coder
person decides.

Dick