Hi, On Oct 5, 2010, at 19:26 PM, Brian Sidebotham wrote:
> On 5 October 2010 15:33, Dick Hollenbeck <d...@softplc.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
