DJ Delorie wrote: >> We have talked many times about the need for gsch2pcb to defer >> actual layout processing into PCB. I don't know if there are >> sufficiently flexible PCB actions to do this without some work on >> PCB though. > > I'm willing to add actions, if someone defines what they need to do.
I think whats needed is a way to instantiate a footprint to the layout. Arguments should be something like name of footprint ("TQFN68EP"),refdes ("U32"), value ("MAX12559") x, y, rotation. If not defined rotation should be 0, if not defined, x,y should be 0,0 or maybe half of the bounding box in each direction, its probably ok to require the first 3. The trick is if we find footprints in a search path way or a library+name way. Personally, it has always been a complaint of mine that gschem/gnetlist use a search path mechanism which can cause strange conflicts if a library gets updated and you suddenly have 2 symbols with the same name. In the old-style way in pcb of grabbing the footprints 1 by 1 in the gui (yuck!), you don't have this since you know exactly where it came from. In the gsch2pcb approach, you have a search path approach for newlib footprints and the m4 ones basically require no conflicting names. So again, there is a little exposure if you're not careful with library orders. I think I generally like the method of referencing a footprint and/or a symbol via library:name which makes things a little more unambigous. Maybe the short term fix is to provide the action to instantiate a footprint and also provide actions to modify the m4 vs newlib preference and set the newlib search path. That should be doable with todays code without too many other far reaching changes. So how about: InstantiateFootprint(name, refdes, value, [x, y, [rotation, [{top/bot}]]) SetLibPref({m4,newlib,m4newlib, newlibm4}) SetNewlibPath(dir1:dir2:....) That gets you the ability for gsch2pcb to add elements. We'd also want something like: WriteFootprintList(filename) to get out a file in a fixed format that gsch2pcb could read to see what needs updating. I'm thinking of basically a netlist minus the connectivity. Maybe resource file format? Maybe this is an opportunity to try the verilog or vhdl approach that Al has suggested? For each instance, we'd write out all attributes we know about (name of footprint, refdes, value, x, y, rotation, board side, any other attributes that show up in the future). Maybe if we do it right gsch2pcb won't need to continually reproduce the pcb file parser. -Dan _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user