On Sun, 2008-12-21 at 11:15 -0500, Stuart Brorson wrote:
> Hi --
> 
> > I guess the question here is this:
> >
> > Is the input which PCB reads a netlist + parts list with enough info to
> > update the board?
> 
> No.

It should be possibly to describe the whole design enough to do that
though.

> > Or is it an action script which contains specific verbs, such as "place
> > component X", "delete component Y"?
> 
> Yes.  Also, verbs like
> 
> (set_trace_width <X>);
> (route_trace <X1, Y1> <X2, Y2>);
> 
> Just MHO.

Fine, add to the description... but you'll need to think carefully what
object / entity in the design those attributes apply to.

> > This is more like the current gsch2pcb, which needs to grok what's
> > already on the board, then issues instructions to make an update.
> 
> My thought is that the forward annotation file would carry all info
> necessary to take the current .pcb file to whatever the new schematics
> call out.  That is, the fwd anno file would represent a delta between
> the existing .pcb file and what's changed in the .sch files.  That
> means:

The I thought that part of the idea was that gsch2pcb shouldn't have to
understand the PCB file-format. (As well as not having to re-implement
code for looking up and placing footprints).

> *  With the very first invocation of gsch2pcb, the output .fwd file
> (or whatever suffix is chosen) would emit all commands necessary to
> place all footprints outside the drawing area, create the netlist
> inside of PCB, and also emit any other necessary info.
> 
> *  Thereafter, gsch2pcb would read both the .pcb and the .sch files,
> and figure out what commands are necessary to update the .pcb file.

I got the impression that this wasn't what DJ was doing, rather
exporting enough information to create the whole design inside PCB.
Which is IMO quite sensible.

The action syntax DJ is proposing does fit your incremental update
suggestion better though, and would also form a good basis for live
updates of connectivity between running programs (actions sent over
DBus). You just have to be careful who is responsible for understanding
the format at both ends and being able to create a list of actions to
sync them. (You're proposing gsch2pcb, I think DJ and I are proposing
PCB).

> This implies that gsch2pcb must be able to read and parse a .pcb file,
> as well as a .sch file.  The .sch part is easy -- use gnetlist.  To
> read & understand the .pcb file, gsch2pcb would probably be best off
> calling functions living an a libpcb, which would also be used by PCB
> itself to do its thing.
> 
> Or am I completely off base?

PCB can't export any sensible information at the moment. Only its DBus
interface would be easily extended to support returning data, but that
would be a divorce from the one-way action syntax it already has
internally.

> [....]
> > OR; we could teach PCB to spot changes in those files it cares about on
> > disk, and will automatically update once I've pressed the button to
> > update the files in the project manager.
> 
> Right.  Or at least that's what I was thinking.

Another variant.. PCB could look for an action script on disk, although
that is more dangerous... it would need to delete it after running if it
contained any actions which were harmful to execute twice on the same
board.

-- 
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

Reply via email to