kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/2/2010 11:45 AM, jean-pierre charras wrote:
> Le 02/10/2010 16:03, Wayne Stambaugh a écrit :
>>
>> On 10/2/2010 6:30 AM, Vesa Solonen wrote:
>>> On 01.10.2010 23:42, Wayne Stambaugh wrote:
>>>
>>>> 5) Drop support for creating components with alternate body styles
>>>> (DeMorgan).
>>>
>>> Would this mean we also lose the possibility of representing a component
>>> with multi part symbol and combined symbol? For example some
>>> microcontrollers fall in between where representation with one symbol is
>>> almost too difficult, but port level splitting is not always needed. How
>>> about opamps and comparators with or without power pins? Also style
>>> flexibility, like IEC / old ANSI / user defined style, etc. Embedding
>>> multiple versions of symbols to the library would be a very useful
>>> feature. Otherwise we need to define a policy how and when to split very
>>> large components regarding symbols. Just to mention I hate policies very
>>> much, but like flexibility. Naturally I'm willing to make compromises if
>>> flexibility means too much complexity or implementation cost. I may not
>>> understand everything correctly here, so please feel free to advice ;)
>>
>> There would be no change in defining multiple parts per package symbols
>> for components such as op-amps and logic gates.  I am proposing that we
>> split the current libraries with alternate body styles (DeMorgan) out
>> the into two libraries.  One library with the standard symbols and one
>> with the alternate symbols.  I'm not sure but this may only effect the
>> 74xx.lib.
> This is useful for other libraries which handle gates (CMOS4000,
> CMOSIEEE...) and some components that include gates (some translators
> and drivers ...)
> But alternate bodies cannot be stored in an other library,

In my case they would no longer be alternate body styles, they would be
stand alone components drawn with the alternate body style extracted
from the old library format.  In other words the normal body style for a
7400 would be in 74xx.lib and the DeMorgan version of the part would be
a separate component in 74xx_demorgan.lib.

> but only as an alternate body of the *same* component, exactly like the
> other parts in multiple parts per package.
> There are some reasons:
> - changing the shape must be easy. This is not the case if the alternate
> shape is an other component (meaning delete and reload components).
> - but mainly this is needed because when a component has multiples parts
> per package (most of gates) these parts *must be*
> grouped in one package (= one footprint) when possible.
> But if 2 identical gates (for instance 2 74ls00 ) are used, one with a
> body, the other with an alternate body,
> and if these two 74ls00 come from 2 different libraries, Annotate is
> unable to merge these 2 gates in the same physical component,
> and therefore there will be 2 footprints for only 2 gates (and 6 unused
> gates).

I hope people are not doing this in their schematics.  I would think
most folks would choose one body style or the other.  I wouldn't be to
happy looking over a schematic where half of the gates of a 7400 were
drawn in the default style and the other half were DeMorgan.  Does
anyone actually do this?  If so, why?

> 
> So for many reasons, I believe using different libraries for alternates
> shapes of the *same component* could create serious annotation problems.
> 
> So, I am not sure having alternate bodies in an other library is a good
> idea.
> Sorry.
> 
>   My reasoning is that when you open a library and view a
>> component, you expect to see how the component will be drawn in your
>> schematic.  In the current design, you must enable displaying the hidden
>> alternate body style.  It isn't ready obvious to a user that this other
>> body style even exists.
> 
> It is easy to display both bodies on screen. This could be an
> improvement of Viewlib.
> (My very old Orcad schematic tool did it).

This solves the visibility problem but does not address the underlying
complexity to the library objects required to support alternate body
styles.  I'm not saying that we cannot continue to support this the way
we already do.  I'm trying to find a way reduce some of the internal
complexity of the source if possible.  Splitting out the alternate body
styles into a separate library is just one possible solution.  There may
be others.

Thanks for your input.

Wayne

> 
> I would rather open a library named
>> 74xx_demorgan.lib and see the components displayed the same as they will
>> be when I place one in my schematic.
>>
>>>
>>>> Before I submit the new file format document for comment, would you
>>>> prefer a
>>>> more readable but larger file format:
>>>>
>>>> ( arc
>>>>    ( start_point 1000 1000 )
>>>>    ( end_point 1500 1500 )
>>>>    ( start_angle -45.0 )
>>>>    ( end_angle 45.0 )
>>>>    ( unit 2 )
>>>>    ( line_width 1 )
>>>>    ( fill_type none )
>>>> )
>>>>
>>>> or a less readable but more compact file format:
>>>>
>>>> ( arc ( 1000 1000 ) ( 1500 1500 ) -45.0 45.0 2 1 unfilled )
>>>
>>> I like the compact approach, but maybe a "doc header" could contain the
>>> library grammar. Would it make sense to define a non parsed comment
>>> area? Is pin and functional block swap is one level deeper, so it was
>>> left out from this discussion?
>>
>> I'm pretty sure adding a comment block at the top of library file can be
>> accommodated.  I just chose to show an arc as an example.  Once I finish
>> up the file format document, the rest of it will make more sense.  We
>> can discuss comments, pins, and functional block when I publish it.  I
>> just wanted to get a feel for what everyone's preference was so I can
>> finish up the document.
>>
>>>
>>> Thanks Wayne, for reworking the library. It's the cornerstone you
>>> mentioned and will enable lots of usability enhancements.
>>
>> Thank you for your input.
>>
>> Wayne
>>
>>>
>>> -Vesa
>>>
> 
> For other proposals, I agree.
> For file format, I prefer by far the more readable but larger file format.
> Because it is easy readable, one can expect:
>  less mistakes (for instance for guys who create files format converters,
>  easier changes in the future.
> 
> Wayne,
> Thanks for your great work.
> 
>