On Sat, 2008-12-20 at 21:46 -0500, DJ Delorie wrote: > This is what I'm thinking for the forward annotation (gsch2pcb) design: > > The PCB has a list of schematics that it gets info from. Do we need > path support, or is full-paths (or relative to the pcb) ok? > Wildcards? Anyway, the list of schematics is stored in the .pcb file > somehow. The GUI needs a way to manage these, too.
I don't like the idea of the .pcb file tracking the schematics / invocations for gnetlist. Many of my forward annotation steps involve running a Makefile (which might introduce new schematics), before gnetlist. Storing some generic command invocation to update might be useful, but we'll have to get very cautious about opening pcb files sent from people if you add that. > When the user asks, PCB uses the list of schematics to run a gnetlist > command with my new backend, passing the list of schematics. The > gnetlist spits out a list of actions, which pcb runs. These actions > update the netlist, add any missing elements, and remove any > appropriate elements. Elements which need new footprints are updated > (magically! in place! we hope ;). > > Also, some additional attributes will be propogated to elements, like > vendor, vendor_part_number, etc. > > If the import is part of a "new board" step, we place the parts and > disperse them, optimize the rats nest, etc. No problem there. > > What do we do with new elements if it's just an update? Eventually, > I'd like to have some separate container for "unplaced elements" but I > mean, what do we do for now? I'm wondering if disperse or autoplace > is smart enough to do something useful if we place the parts and > select them, on a partially laid out board. xgsch2pcb just rather unhelpfully drops them on top of each other in the corner. I wanted to implement a "parts bin", or "rat-parts" view where I could have just a strip of canvas with the parts distributed horizontally / vertically, and drag-drop them onto the board. We could also add it as a tab in the library contents browser, and make them go-away from that list once placed. (You could perhaps even group things like bypass caps together, and that line-item goes away when you've placed them all). > I think this is enough information in the .pcb file that we can get > rid of gsch2pcb and the "project" file it uses. I really don't like that idea, we were supposed to be improving that workflow, not removing it. IMO, we don't want to remove the ability for a GUI project manager to be involved in the task. I'd be really very disappointed if we can't keep xgsch2pcb working with whatever new flow is produced. > It does mean that the pcb cares which schematics go with it, but the > schematics don't care which pcb they go with. Schematics can be > reused/shared, boards generally can't. As I said, between one update and the next, the list of schematics may have changed. I might need a Makefile run to get them up-to-date. What if the user's desired input is just a netlist (and perhaps a parts list)? What if the schematics aren't from gEDA? I like the idea of having a netlist file, and whatever extra file(s) needed to specify the parts and their footprints. PCB can either watch those files, or re-read them at a button-press, then do its update without tying things to a gEDA schematics only flow. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
