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

Re: gEDA-user: Free Dog meeting report: Notes on the topics we discussed

Stuart Brorson wrote:


I thought the current page was OK. However, after some discussion in
the group, placing explicit instructions about what to download and what to do on the downloads page was thought to be a good idea. (The
info is currently hidden in several READMEs linked on the "downloads"
page.) The issue raised by Karel is that we have lots of total
newbies trying to use the software, and Eagle makes their lives much
too easy, at least when it comes to download and installation. Does
somebody have some text they would prefer to see on the download page?
Contributed text would allow Ales the chance to simply cut and paste
to the page . . . .

I wonder if its time to make use of AC_CONFIG_SUBDIRS() and stick a very brief configure.ac at the top level. I've not done this before, but I wonder if it would let you turn gaf from several tarballs and ./configure && make && make install invocations into 1 tarball and 1 config/install. I think that would go a long way to making it easier for most users.


* Backannotation from PCB to gschem. 

This is a topic of frequent discussion.  Last night's idea was to do
backanno in two steps:  The first step (using "geco" program) would
create a cleartext .eco file from a changed .pcb file.  The .eco file
would then be used (by "gbackanno") to update the .sch file.  The
advantage here is that you would have a record of changes made in the
.eco file, and you could edit the .eco file with emacs (or whatever)
before doing any backannotation into gschem.

Here's the full proposed design cycle (in ASCII art):

+------ (.sch) ----> gnetlist ------ (.pcb.new) ------+
| (gsch2pcb) |
| |
| V
gschem pcb
^ |
| |
(.sch) (.pcb)
| |
+-------- gbackanno <----- (.eco) ----- geco <------ -+


Something of this sort has been on my list of 'things we really must have someday'. However, I would argue that this figure is wrong. I think what you want is for each tool, gschem and pcb for now to be able on their own to produce a netlist which contains the connectivity netlist. Then I want a different tool to be able to look at the two and figure out, for example that you needed to add C1, R3, and U6 to your layout and those are 0603, 0603, and SO16 packages. Or maybe you run it the other direction and it tells you that you need to change C2 in the schematic from 1206 to 0603 and swap slots in U1 and make R3 be 10k. Then each tool reads a standardized ECO file and applies the change.

Why? Because right now gsch2pcb knows too much about the .pcb file format. We've see how many times now that as the .pcb file format changes (and I'll note that it is always in a way which lets you read any older version) gsch2pcb gets out of date and needs to be fixed.
At least gnetlist is tied in via libgeda more directly to the schematics.

On the other end if you write this geco program, it again probably knows
too much about .pcb files.

If you add support for other layout tools like PADS (which is supported via gnetlist -g pads and pads_backannotate) then the problem gets worse. In the case of PADS, you have the pads_backannotate program which now knows too much about gschem .sch file formats. There is a fair amount of me which doesn't care about PADS, but then again, I've seen first hand that sometimes you're forced into working with a layout person using pads and it is quite nice to still use gschem to drive things.

The other issue is what happens if you do something which makes you want to backannotate layout changes to the schematic, but you also made a schematic change. I wonder how the loop figure works out.

So, what I'd propose is that the gbackanno program is needed and that in fact pads_backannotate already implements much of what you want. The thing I'd change is to redo it in C instead of perl and take advantage of libgeda so you abstract away the details of the .sch file format from gbackanno. As part of this, you'd want to extend the libgeda api (if it doesn't already deal with it) to do the operations of adding elements and setting their attributes.

On the pcb end I'd like to see the ability to read a .eco file and react by instantiating footprints and naming them. Also pcb needs to be able to dump a netlist like file which basically has connectivity info along with attributes like what footprint, refdes, and part value. Both of these should be easy.

The final missing piece is then something which can compare two of these connectivity+attributes netlists and produce the eco file.

In terms of the .eco file design, one approach is to use the PADS format. It is well documented. The concern is if there are legal issues with that. If not, it is still probably a good examle of what information eco files need and one could probably write a simple geco <-> pads eco converter to support pads.

* Discussion of Dan McMahill's issue raised in his last e-mail: He
wants to embed the library name into the schematic along with the
symbol name. For example: analog/resistor-1.sym instead of
resistor-1.sym.

This idea was discussed, but nobody understood what problem it
solved, besides designer laziness in giving two symbols the same name.
Personally (please flame me if I am wrong), I thought it would break
too many old schematics to fix a minor problem. Dan, please forgive
our (possible) stupidity, but what problem is being fixed by this
suggestion? And is the problem large or small?

The problem gets worse as libraries grow and the number of designers grow. Some of it can be managed via project management tools like cvs, but it doesn't fix everything. Suppose you and I are working on a fairly large board. We find (as one always does on boards of any size) that we need to add some new symbols. You add a ne85634-1.sym. Because you and I are both busy and neither knew the details of the others part of the board, I also add the symbol but put it in a different library. Unfortunately the pins don't exactly line up on our 2 versions of the symbol. As we get closer, to being done, we each do a 'cvs update' on our design directory and sym/stuart/ne85634-1.sym appears in my account and sym/dan/ne85634-1.sym appears in yours. One of us will lose and find our schematics are broken. Can't fix it with search path ordering because we need your pages and mine to both work.

Or, someone creates their own max1234-1.sym for their local library. Later we happen to add one to the standard geda/maxim library. But they're not compatible. It is probably ok to just put the local library first in the search path, but it makes me nervous.

I think the real issue is you may have geda installed libs which grow over time, company-wide libs which grow over time, per-user libs, per-project libs, etc. and sooner or later there will be a name clash. Hopefully the rule of pick your project libs first then company libs, then geda libs is usually correct, but it may not always be.


* Post meeting - use of Wiki in the gEDA webpage.

Ales suggested using a Wiki to hold information about gEDA.  In
particular, he wants to use something like a Wiki to hold a FAQ, and
direct newbies with questions to the FAQ, where currently he has to
monitor the mailing list, or answer via e-mail.  I think this is a
great idea.

THe problem is spam, and how to control/prohibit spammers from writing
garbage to the gEDA Wiki?

I suggested:  Use a Wiki allowing different write permissions on
different pages.  Then, a subset of pages will allow only Ales to
write them (e.g. the basic documentation), and the other pages will be
writable by a set of users who must first get permissions set by
e-mailing Ales.

I think the octave wiki people have a list of allowed IP addresses for posting to the wiki specifically for this problem. Seems like a hack though. Is there no way to require a user/password to post?

-Dan