On Sep 29, 2008, at 9:24 PM, Peter Clifton wrote: > On Mon, 2008-09-29 at 20:55 +0900, John Doty wrote: >> On Sep 28, 2008, at 9:54 PM, Peter Clifton wrote: > >>> I'm of the opinion that the .sch file should still end up >>> containing all the required design information, > >> I have the opposite opinion. The "everything in the schematic" >> approach is a serious barrier to schematic reuse. It makes the >> process of choosing and and especially changing parts tedious and >> inefficient. > > [snip] > >> We have this capability already. Symbol files are nice flexible >> containers for the database information, easy to edit graphically or >> textually. > > Ok, fair enough. Heavy symbols is another way to go about things. I > was > talking about the possibility of using lighter symbols in the the > library, then associating more specifics in the schematic. You could > also attach the specifics in a "heavied up" symbol file if so desired.
Again, attaching the specifics in the schematic becomes a barrier to reuse. Even within the same project, parts selection often evolves in ways that shouldn't require schematic changes. And having built up a collection of circuit building blocks in gEDA, I increasingly find myself recycling them in new projects. Even when the circuit stays the same, every project has its own specific environmental, miniaturization, performance, and QA requirements driving parts selection. > >>> This said, it would still be nice to see the >>> schematic cache the results of any database lookup, so they can be >>> distributed eaily to other parties who might not have the same >>> database > setup. >> >> The way I do this is that the design is a collection of files: there >> are often multiple top level schematics, and I use hierarchy quite a >> bit. Each project has a collection of project symbols that mostly >> start as copies of symbols from either the gEDA distribution or from >> a previous project. >> >> Ideally, every component symbol should be in the project collection. >> Then "Hs" does exactly what you need: it edits the component database >> for your project. > > If the symbols start really light, don't you find you need to have > multiple resistor symbols, transistors, diodes etc.. once you've > heavied > them up? Yes. The "heavied-up" symbol symbol names represent roles, like npn_low_noise or bypass_cap. For example, a specific project might choose either BCX70K or 2N930JANTXV for the npn_low_noise role, depending on qualification requirements. The bypass_cap might be the largest value I can get in the smallest package I dare specify without risk of mayhem by the tech who has to build the thing ;-) Any database-driven approach will face this issue one way or another. > > I'm sure it would be fairly easy to have gschem make a copy when > selecting a symbol, but I wouldn't expect that the name ends up > correct > without user input. Yes. > >> The missing ingredient here is a simple one: the symbol browser >> should be able to automatically copy symbol files into the project's >> symbol repository. Right now, I find myself browsing for a symbol, >> getting its name, using "locate" and "cp" to get it to the project >> repository under a project-specific name, refreshing the symbol >> browser, and then browsing for and placing the symbol. > > This part "under a project-specific name" is the gotcha. You'd need a > GUI or something to enter that name. Indeed. Another handy feature I used a lot in my old Viewlogic days was a "replace symbol" menu function. That let me quickly capture schematics using just the generic library symbols, then think about parts selection (how many different kinds of NPN do I need?), make the heavied-up symbols, and then replace the generic symbols with the appropriate heavied-up ones (select all the NPN's that need to have low noise, Edit->Replace, browse for low_noise_npn, click OK). > >> This slightly inconvenient procedure saves a great deal of work >> later. > >> One thing that can get in the way is gschem's default of promoting >> attributes like footprint. That gets in the way: the project's >> default footprint isn't usually a sensible schematic-level attribute. >> Of course, if I have a special requirement for a particular instance, >> it's easy to override it with an attached attribute. So > > I presume you turned promotion of those attributes off in your gafrc? Yes. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
