kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

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,
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).

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).

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.


--
Jean-Pierre CHARRAS