kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

Hi,

On Oct 5, 2010, at 19:26 PM, Brian Sidebotham wrote:

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

I think this would be great. Does this mean we get 3 sorts of files?
symbol, footprint and part-files?
(symbol, e.g., a resistor, 
component, e.g., a 10k 5% resister of .25W with footprint R025W 

Part-files can be project specific or general. Parts can be created automatically when needed and in the simples form only has 2 include-lines (and perhaps a part-number, e.g., R1). You could add lines if you want gate-swapping.


>> 
>> 
>> 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.
Would we really need base-symbols and base-footprints? Meaning, do we want symbols that are derived from other symbols? Why not flatten all symbols and footprints? I *think* this would be much easier to use and maintain.

A part would be "derived" from both a symbol and a footprint, and you can overload some parts (e.g., which NAND to use in the 74LS00). Symbols could already be linked to footprints, such that when you select a symbol you get a list of footprints (you should be able to override this).

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

I think we should not code a VCS into kicad, but let the user choose which one to use. However, it makes sense to host one in SVN on launchpad.


>> 
>> 
>> 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 am not sure if this kind of intelligence does any good. Perhaps it does in another example, but I am not a great fan of a tool choosing the "best" option for me, because a lot of times it is simply wrong.

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

/Martijn