Re: gEDA-user: Parsing and writing schematics with Perl

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Mon, 2008-04-21 at 10:22 +0200, fricker wrote:
> On 21 avr. 08, at 02:53, Peter Clifton wrote:
[...]

> Reading you it seems to me that the gschem file format changes less  
> often than a potential API in libgeda. I should therefore keep such  
> parser/writer completely independent from libgeda and base it only on  
> the file format. I.e. I went down the right path so far... Thanks!
> 
> BTW: Parse:RecDescent provides the extra benefit of error handling,  
> it flags quite nicely if the file has errors and where, in a top-down  
> fashion. I didn't write any parsing code, just its grammar.

[...]
> It's just the way Data:Dumper outputs an internal data structure of  
> arrays [] of hashes {} containing string elements and other arrays,  
> containing hashes, etc. I can just access things like this then to  
> change the sheet number on every sheet of a design:
> 
> $data[$file_idx]->{objects}->[$object_idx]->{Attributes}->[$attr_idx]- 
>  >{value} = $sheets++;
> 
> > What sort of processing are you needing to automate in this way?
> 
> Here is a short list:
> - update/create sheet to sheet net cross references (with ~200  
> sheets, this is a must have!)

That is a lot of sheets! So far, my power converters sit at ~ 20 sheets,
for 5 small(ish) boards. How big boards are you working with?

> - update current sheet number and total sheet numbers
> 
> - replicate similar subsections of schematics (a given schematic page  
> used multiple times where you need to update refdes and netnames).  
> Some might want to use hierarchical designs instead, but I stay away  
> from such approach for board design!

I use a Makefile, and a modified version of refdes_renum, but my
solution is far from optimal. A perl module to read / write the
schematic to/from a data structure (like you did),  would probably be a
nicer way of scripting those changes.

> - update component attributes based on an "Approved Device  
> List" (output from a PLM database), i.e. add/update device=<part  
> number> on passives based on value, tolerance and ratings attributes  
> and verify the other active components
> 
> - design-wide component updates (with correct handling of attributes  
> and symbol version changes)
> 
> - design-wide cleanup and checks (text size, alignment, location, not  
> connected nets, etc., mostly to enforce drawing guidelines)
> 
> - generate multiple versions of a given root schematic based on a  
> configuration file: simulation vs. prototype vs. production bom  
> alternatives, each one having its own set of pdf, etc. I use a  
> bom=1,2,... attribute to tag such alternatives in the root design,  
> then change it to bom=NOSTUFF in the specific versions, this way the  
> folks debugging the board don't have to look-up the bom options in a  
> table. I then generate actual boms using gnetlist out of these  
> derived schematic files. I also replace the CVS tags such that they  
> look neat when printed.

> - generate tagged pdf, with sheet to sheet net links and attributes  
> pop-ups.

That would be very neat to see.

> And all of this has to be controllable through Makefiles, this way  
> the generation process is inherently documented for your coworkers or  
> newbies.
> 
> I used to use Makefiles and sed s/.../.../ a lot but file-wide regex  
> are dangerous since it isn't so easy to control what the s/.../.../  
> is really going to change.

Indeed, and it needs something more complex (awk?) to pick out context
such as "s/.../.../" for attribute "foobar=..." on a device with
"refdes=R10[0-9]"

> And I would not want this to be integrated in the gschem gui! gschem  
> is - and IMHO should remain - just a drawing tool. It is far more  
> powerful and convenient to control the above with perl scripts and  
> Makefiles, including and especially bom handling stuff.

I can't imagine how you could integrate all that, even if someone wanted
to.

> What I need to achieve all of this is a Perl module that offers:
> - readFiles(\@files) that returns a reference to an array of hashes  
> (file names are pushed into the data structure)
> - writeFiles(\@data) that writes the data structure back into the  
> files (file names are within the data structure already)
> 
> I could package what I have and share it if anyone is interested.

I think a lot of people would appreciate that, I'd certainly be
interested.

Best regards,

-- 
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-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user