[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: moving slotting to pcb?

On Jun 29, 2010, at 10:16 AM, John Doty wrote:

> 
> On Jun 28, 2010, at 10:56 PM, kai-martin knaak wrote:
> 
>> John Doty wrote:
>> 
>>> You're not thinking of reuse at the same level I am. Consider a Sallen-Key
>>> low pass filter. Why should we have to draw that more than once? Somebody
>>> could post a symbol along with a source schematic on gedasymbols, and then
>>> we could all use it.
>> 
>> see the block paragraph in my section of gedasymbols. E.g:
>> http://www.gedasymbols.org/user/kai_martin_knaak/symbols/block/opamp_with_booster.sym
> 
> I was thinking more of a regular schematic, attached to something like lowpass.sym with a source= attribute.
> 
>> 
>> Currently, there is a catch, though:
>> The symbols are embedded in the schematic. The gschem GUI provides no way to 
>> get them out of the schematic. The unembed action simply fails, if it can't 
>> find a matching symbol in the local library. If it saved the symbols locally 
>> instead, embedding would provide a powerful way to distribute reusable 
>> circuits. The schematic itself knows best, which symbols it contains. No 
>> need for a separate application to collect symbols. No packaging of files 
>> required. Just a single *.sym file.
> 
> I'm not fond of embedded symbols in most cases. I don't embed my .h files in my .c files either. But since we have embedded symbols, orthogonal design would suggest that they should be editable and extractable.
> 
>> 
>> 
>>> But each application requires different component
>>> values, a different op amp, etc. So a file like:
>>> 
>>> R1      value   51.1k
>>> U1      device  OP90
>> 
>> IMHO, it is nice to dream about perfect solutions. But we need to get the  
>> basics straight. The basics in this case is a way to distribute the symbols 
>> needed for a particular circuit without involving a whole infrastructure. Be 
>> it a data base, a whole library, or a set of design rules to adhere to.
> 
> That isn't the issue I was trying to address here, and I don't find that terribly burdensome. It's not much different from managing a software project, with its include files, libraries, makefiles, etc. Indeed, many of my gEDA projects include software components anyway, so the tools to manage such collections of files are already in use.
> 
> I simply do not understand why some find the "cram anything into one file" attractive for anything but a very small, "throwaway" project. Modularity is a good thing. Directories and files are excellent tools for organizing modules.
> 

It is useful for archival purposes as well.
If I want to share a design with the community in it's finished state, then I want it to be in a nice small bundle.
but when creating and working on it i want it as modular as possible.

>> 
>> That said, it looks like your are talking about using an editor for the the 
>> job gattrib does?
> 
> No. gattrib is a "touch-up brush", good for manually fixing little problems, but not an effective tool of automation.
> 
>> That would be neat. Even better would be, if the file were 
>> in spread sheet format. Seems to me, gattrib has a hard time reinventing the 
>> spread sheet GUI wheel. The result feels pretty awkward when compared to 
>> gnumeric, oocalc and the like.
> 
> Spreadsheets are a slick trap: easy to use, but massive time wasters. Occasionally, a spreadsheet is effective for a small, simple problem, but mostly see http://en.wiktionary.org/wiki/fritterware.
> 
>> 
>> How about this: Use the gschem parser of gattrib to synthesize an 
>> intermediate file in comma separated spread sheet format. Pipe this file to 
>> gnumeric/oocalc/whatever. The user manipulate values and attributes and 
>> saves.
> 
> Violates the ideal flow sources->data products.
> 
>> The non GUI gattrib application detects the changes and writes them 
>> back to the original gschem file.
> 
> No. Don't corrupt your source file. When you want to annotate the schematic with specific parameters (component values, slots, etc.) move *forward* to that annotated file. Keep the source clean for reuse. Keep the parameter source around so that make can regenerate the annotated product.
> 

Would a cleared way be to express the source schematics as templates?

>> I haven't inspected the code yet. But I'd 
>> expect the this rewrite back-end to be already there in the gattrib source. 
>> If a user feels like not using a spread sheet application he or she can use 
>> scripting to manipulate the intermediate file as well.
> 
> Better simply to generate the parameter file with a script straight up. For the Sallen-Key example, have a script that converts frequency, Q, and impedance to component values.
> 
I'd like this script to have an interface that allows it to be called from gschem or other applications.


>> Ouups, I am guilty of dreaming about perfect solutions, too ;-)
>> 
>> ---<)kaimartin(>---
>> -- 
>> Kai-Martin Knaak
>> Öffentlicher PGP-Schlüssel:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53
>> 
>> 
>> 
>> _______________________________________________
>> geda-user mailing list
>> geda-user@xxxxxxxxxxxxxx
>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 
> John Doty              Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd@xxxxxxxxx
> 
> 
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user