kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 5 October 2010 15:33, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>
> I get paid to brainstorm, so brace yourself.
>
> Continuing with library brainstorming, the following is put on the table
> for consideration and eventual evaluation. Brace yourself, this is out
> of the box.  Open up your mind before proceeding.
>
> Remember the HTML editors which let you view HTML source and the
> resultant GUI presentation at the same time?  One panel has the html
> source, another shows you its effects.  The following concepts use that
> UI paradigm.  Use the source Luke, use the source.
>
>
> A library is not a library file:
> -------------------------------
>
> The concept of a *library file* is gone.  There are none.  The concept
> of a library can still exist but it is a RAM resident concept.  Each
> component that we traditionally think of residing in a *library file* is
> actually in its own file on disk in a directory (or repo or schematic).
> A library is only built in RAM during the loading of a collection of
> components.
>
>
> Loading components:
> ------------------
>
> The act of loading components utilizes the notion of inheritance and
> classical file inclusion like the C++ #include.  Let's go back an
> understand inheritance thinking about Java. In a Java virtual machine
> each class definition container has a method table.  That table is
> initially populated with methods from the base class.  As the base class
> is extended some of those methods are overloaded (replaced) with ones
> from the derived class in the internal method table.  Additional fields
> can be introduced in derived classes also, into what is a field table
> for that class.  Now lets move that conceptual model to a component.
> Lets assume we have a pin table, and a graphics table.  We give a
> component the ability to inherit from: 1) a base code fragment,  or 2)
> symbol or 3) component.  In this case you can do pin additions, or pin
> modifications, pin swapping, in the same way you can overload a Java
> class's method table.  Pins can be overloaded or replaced, and graphical
> primitives can be inherited and extended.
>
> The magic happens during the loading phase of the S-expressions, so that
> the "built up" component is fully assembled in RAM by using pieces from
> various places "out there", while *loading*.
>
> If desired, the various pieces can be ear-marked with their origins in
> full recognition of the existence of inheritance.  One might do this
> only to facilitate graphical editing of a derived component, although if
> the grammar is sweet enough, textual editing may be enough for all
> editing of derived components.
>
> Re-loading is simply done by clicking a "parse" or "show" button.  The
> the parser reloads the source stream and does file inclusions as called
> for.  A portion of that source stream comes from the textual UI panel.
> Inherited portions come from a library (which is now a RAM resident
> concept only).
>
>
> Example
> -------
>
> (component SOMENAME
>  # inherit is like C++'s #include
>  (inherit SOMEOTHERNAME WHERE)
>  (pin 12 ... WHERE...ORIENTATION)
>  (pin 13 ... WHERE...ORIENTATION)
>  (pin 14 ...)
> )
>
> Pin 12 and 13 are provided here and they are overloads because 12 and 13
> have already been defined in SOMEOTHERNAME.  So this could be the means
> of a *pin swap*.   However pin 14 is new, since SOMEOTHERNAME did not
> have one, so this is an extension. In one example we see both a)
> overloading and b) extension.
>
> This example would be a new SOMENAME component, and its graphics are
> fully inherited from SOMEOTHERNAME, and can be extended here, but not
> overloaded in any way that I can think up.
>
>
> Where do they come from? and component versioning:
> -------------------------------------------------
> The ability to reference an external component by a GUID (globally
> unique ID) of some kind lets you pull in components from anywhere in the
> world.  A GUID inherently needs to respect versioning.  That is to say,
> if you make an edit to a component that somebody else depends on, you
> still have to provide the original version also.
>
> Enter the version control system.  Since each component and component
> source code fragment exists in its own file, a source code control
> system is used to house these files, and they can be accessed by using a
> SCCS repo, file name and version number, over the Internet, or locally.
>
> One possibility for this is to build a tcp socket oriented bridge into
> Bazaar's access API, which I assume lets you access any version of any
> archived file.  Only one such server is needed for the "kicad supplied
> libraries".  Behind the scenes the bridge/server simply uses launchad's
> bazaar based repo.
>
> The loading of code fragments from afar need to be cached in RAM, so the
> concept of a *library* does not go away.  A library is a RAM container
> that caches those things coming from afar in order to enhance speed.
> But remember, kicad supplied libraries are essentially "read only" (for
> all but those with the generating scripts).  So putting them under SCCS
> and in launchpad as a primary place of dwelling is reasonable for those
> with Internet access.  Others could check out the library branch.
>
>
> How?
> ----
>
> I can have this coded by Tuesday, given enough incentive.  (I'm just not
> going to say which Tuesday.)

Includes would be awesome, and I think that having the source +
graphical split would work very well.

Some descriptors could be very generic. For example I first draw a
generic op-amp package which results in a purely graphical symbol.
Then I can create a set of components which include the graphical
items from the symbol, and maybe do some pin mapping, footprint
selection and include some spice parameters.

Just thinking of future expansion and the possibility of using Spice
simulation in KiCad, variable substitution might be nice to include
the relevant spice parameters depending on what the user sets the
value field to in the schematic.

Assuming that variable substitution is evaluated between pairs of % symbols:

e.g.:
(component QUANDOPAMP
  (inherit QUADOPAMPSYMBOL)
  (inherit SPICE%Field:Value%)
)

So in the above, when I edit the value field in the schematic, the
relevant spice parameters are included for the op-amp that I'm using
(provided that the spice parameters can be found of course!) This
would make evaluating different components really easy.

Intelligent Components
---------------------

This opens up a thought that you can do evaluation on components
properties. A single resistor component could translate to several
different parts in a schematic depending on the field values.

For example, a generic resistor could set its own footprint field
depending on the power field:

(component RESISTOR
  (inherit ANSIRESSYBOL)
  (field Footprint
    (option 0.25W (footprint 025WRES) )
    (option 0.5W (footprint 050WRES) )
    (option DEFAULT (footprint 025WRES) )
  )
)

I'm not sure this would be valid syntax, but hopefully you get the
idea. Set the resistor power in eeschema and the footprint will be
selected semi-automatically. Obviously more options can be inherited
or inserted if the source of the component is available to edit.

Possibly, we could have an equivalent of a switch statement in the part.

I think inheritance could open up a world of possibilities...

Best Regards,

Brian.