Re: gEDA-user: pcb flip-sides

[Ineiev]

On 10/28/09, Kai-Martin Knaak  wrote:
> Unfortunately, the V parameter does not change anything. This is how I
> try to extract a print of the bottom view of the layout:
>
> pcb -x eps \
>   --action-string 'SwapSides(V)' \
>   --as-shown  \
>   --layer-stack "comment, outline, elements, bottom" \
>   --eps-file "/tmp/out.eps" \
>   $PCBFILE

On my machines, it segfaults because the SwapSides actions,
both the GTK and the Lesstif one, are written to use
with the GUI initialised, and this is not correct in your case:

diff --git a/src/hid/gtk/gtkhid-main.c b/src/hid/gtk/gtkhid-main.c
index cbdd104..893e36b 100644
--- a/src/hid/gtk/gtkhid-main.c
+++ b/src/hid/gtk/gtkhid-main.c
@@ -2013,6 +2013,8 @@ SwapSides (int argc, char **argv, int x, int y)
 1);
}
 }
+  if (!ghidgui)
+return 0;

   /* Update coordinates so that the current location stays where it was on the
  other side; we need to do this since the actual flip center is the
diff --git a/src/hid/lesstif/main.c b/src/hid/lesstif/main.c
index 370d816..0ac98c1 100644
--- a/src/hid/lesstif/main.c
+++ b/src/hid/lesstif/main.c
@@ -573,21 +573,22 @@ SwapSides (int argc, char **argv, int x, int y)
   /* SwapSides will swap this */
   Settings.ShowSolderSide = (flip_x == flip_y);
 }
+  if (gui->gui)
+{
+  n = 0;
+  if (flip_x)
+   stdarg (XmNprocessingDirection, XmMAX_ON_LEFT);
+  else
+   stdarg (XmNprocessingDirection, XmMAX_ON_RIGHT);
+  XtSetValues (hscroll, args, n);

-  n = 0;
-  if (flip_x)
-stdarg (XmNprocessingDirection, XmMAX_ON_LEFT);
-  else
-stdarg (XmNprocessingDirection, XmMAX_ON_RIGHT);
-  XtSetValues (hscroll, args, n);
-
-  n = 0;
-  if (flip_y)
-stdarg (XmNprocessingDirection, XmMAX_ON_TOP);
-  else
-stdarg (XmNprocessingDirection, XmMAX_ON_BOTTOM);
-  XtSetValues (vscroll, args, n);
-
+  n = 0;
+  if (flip_y)
+   stdarg (XmNprocessingDirection, XmMAX_ON_TOP);
+  else
+   stdarg (XmNprocessingDirection, XmMAX_ON_BOTTOM);
+  XtSetValues (vscroll, args, n);
+}
   Settings.ShowSolderSide = !Settings.ShowSolderSide;

   /* The idea is that if we're looking at the front side and the front
@@ -620,7 +621,8 @@ SwapSides (int argc, char **argv, int x, int y)
}
}
 }
-  lesstif_invalidate_all ();
+  if (gui->gui)
+lesstif_invalidate_all ();
   return 0;
 }

This is just another quick workaround (the first I suggested was to
add a gui-ignorant SwapSides version).

Cheers,


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: My uEDA-designed open source hardware board works!

[DJ Delorie]

> P.S. Yes, I'm heavily into retrocomputing.

I think it would be neat to do anti-retro computing.  Take a retro
form factor, like AT with ISA slots, and build a motherboard that's as
powerful as that class of computer, but using a single SoC processor
like ARM.  The m32c is very similar to an 8086...

You could almost do a whole PC (except for the 8086-compatibliity) in
a single FPGA.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: can't find last rat

[DJ Delorie]

> optimize reports 1 remaining rat but I can't find it anywhere.  What can 
> I do to find it?

http://www.delorie.com/pcb/findrat.c


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Working on xgsch2pcb-0.1.3 for Gentoo

[DJ Delorie]

> http://frajasalo.de/frank/projekt/pcb/pcb_part-view_20091028-2257.png

That board looks familiar...  ;-)

Where do you keep "unplaced" parts in your scheme?  Do they still show
up on the board at all?


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: My uEDA-designed open source hardware board works!

[Michael Sokolov]

David SMITH  wrote:

> However, I think you'd have a problem with non-GUI PCB layout.  Whilst
> you could automate all of the routing and some of the placement, I'd
> really struggle without a GUI for placing the parts where their location
> matters (e.g. connectors, front panel stuff, etc.).  I suspect that
> doing this textually would be a rather tedious and long-winded process.

Actually for me it's exactly the other way around: when it comes to
putting down those elements whose locations are fixed by external
constraints, vi-ing the .pcb file is my preferred method for doing that:
I'm really good at doing the centimil math involved in that and this way
I have the confidence that the element or the mounting hole (Via object)
is exactly where I need it to be.

For the OSDCU board this has turned out to be a non-issue because I went
with the strategy of making the board first and then building an
enclosure for it later once it's 100% working, so I told Ineiev that it
was OK to move the "fixed" components around a little if necessary on
this first pre-enclosure PCB revision, but previously I had a different
plan.  My previous plan had been to fit my board into the enclosure from
a gutted Inefficient Networks router, and I had measured the old board
out with a caliper and entered all fixed locations into OSDCU.pcb with
vi.

But then I changed my mind because I wanted to use right angle LEDs
instead of the upward-shining ones used by FP/EN, and I didn't want the
IEC 320 AC mains entry right on my board as I wanted more flexibility
(allow OSDCU+router or multi-OSDCU combinations sharing a common
enclosure and power supply).  So I trimmed my PCB down to a rough size
equivalent of the functional section (sans AC mains entry) of FP/EN's
PCB, made it simple rectangular, made the dimensions metric (I still
consider myself a Soviet citizen and follow Soviet standards) and let
Ineiev have a go at it. :-)  And now we have a working board, yay!

k...@aspodata.se (Karl Hammar) wrote:

> The ueda don't compile out of the box here, there are a lot of forward 
> references to static functions, exit(3) and strlen(3) no declared, and
> conflicting declaration of malloc.

uEDA is intended to run on 1970s-80s versions of UNIX like I use, but it
builds OK on my Linux boxes too if one simply ignores the voluminous gcc
warnings.

> Attached diff fixes thoose for me.

With this diff it would be unusable to me because  doesn't
exist on UNIX systems like V7 and 4.3BSD.

MS

P.S. Yes, I'm heavily into retrocomputing.  The OSDCU board I've just
built is actually a retrocomputing device too, as its primary purpose is
to hook SDSL circuits up to 1980s-style routers.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Working on xgsch2pcb-0.1.3 for Gentoo

[Kai-Martin Knaak]

On Wed, 28 Oct 2009 15:29:41 +, Peter Clifton wrote:

> Somewhat difficult to do for all cases (e.g. hierarchical boards,
> mangled net-names output from gnetlist).

I know...


> Finally, assuming you have some process to query gnetlist for a the
> correct refdes, you need to use PCB actions to select elements by name
> (that "might" already exist, I can't recall).

This action does indeed exist. In the GTK HID it can be found in the 
Select menu:
Select -> Select_by_name -> Elements
This is the find dialog I referred to when I described my manual work 
around to compile a selection. Fortunately, the dialog understands regexp 
syntax and can do AND-searches.


> __OR__
> 
> Code for the common case of gschem refdes == PCB refdes, and accept that
> for some advanced users it won't work at present.
>

__OR__
Code for the common case of gschem refdes == PCB refdes, and let the 
advanced user hint to the algorithm how to correctly mangle the initial 
refdes. A text field with an editable prefix in the find dialog might 
already do the job. 
If the selection contains components from different sheets, this still
does not work. However, this is an exception of an exception. 


> 
>   This is not easy to do correctly in a flexible suite like gEDA.
> 

A missing feature means "not working" in all cases. So, a feature that 
does not work for all cases, is way better than none. Adding the ability 
to transfer selections only for the most common case does not in any way 
interfere with the current work-flow. Each and every trick and technique 
will still work like before.

---<(kaimartin)>---
-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: can't find last rat

[gene glick]

optimize reports 1 remaining rat but I can't find it anywhere.  What can 
I do to find it?

gene


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Working on xgsch2pcb-0.1.3 for Gentoo

[Stefan Salewski]

Am Mittwoch, den 28.10.2009, 00:15 +0100 schrieb Stefan Salewski:
> On Mon, 2009-10-26 at 15:09 +, Peter Clifton wrote:
> 
> > 
> > The latest version is
> > http://geda.seul.org/dist/geda-xgsch2pcb-0.1.3.tar.gz
> > 
> > Although I think I was slack and didn't get a release announcement
> out.
> 
> 

The current inofficial ebuild for Gentoo is available here:

http://www.ssalewski.de/tmp/geda-xgsch2pcb-0.1.3.tar

It may take some time before we will have it in the main Gentoo tree.

I have tested only for AMD64. Seems to work for schematics with not too
many parts and no AVR microprocessors.

With 

export LANG="de_DE.UTF-8"
export LC_COLLATE="C"

(in .bashrc) we get german menu text, but if we try default english
locale we get a gettext warning.

Please use it only with care.

Best wishes,

Stefan Salewski




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: My uEDA-designed open source hardware board works!

[Karl Hammar]

Michael Sokolov:
...
> But I guess the gEDA community is quite different, and I've noticed that
> quite a few people here (perhaps even the majority) are *not* doing Open
> Source Hardware, instead they are using FOSS EDA to create closed
> proprietary hw designs.  Argh!  I'll spare my obligatory Marxist-Leninist
> comment on what I think should be done to such people.

Not really, I have just set up an new project reachable with:

 $ git-clone git://aspodata.se/openhw.git

It consists for the moment of a README. You are more than welcome to 
discuss it.

...
> cvs -d :pserver:anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda 
> ifctf-part-lib OSDCU

The ueda don't compile out of the box here, there are a lot of forward 
references to static functions, exit(3) and strlen(3) no declared, and
conflicting declaration of malloc. Attached diff fixes thoose for me.


? diff
Index: libueda/readmcl.c
===
RCS file: /fs1/IFCTF-cvs/ueda/libueda/readmcl.c,v
retrieving revision 1.1
diff -r1.1 readmcl.c
7a8
> #include 
32a34,40
> 
> static finish_component();
> static setup_partdef(register char *np);
> static parse_refdes_list();
> static clone_component();
> static handle_part_ref(char *partname);
> static getline();
Index: libuschem/graphsym_load.c
===
RCS file: /fs1/IFCTF-cvs/ueda/libuschem/graphsym_load.c,v
retrieving revision 1.7
diff -r1.7 graphsym_load.c
7a8,9
> #include 
> #include 
10c12
< extern char *malloc();
---
> //extern char *malloc();
18a21,30
> 
> static mymain();
> static handle_pin(char *objline, int objlineno);
> static read_pin_attrs(struct graphsym_pindef *pin, int objlineno);
> static handle_attr(register struct graphsym_pindef *pin, register char *line);
> static handle_T_obj(char *objline, int objlineno);
> static parse_numline(char *line, int lineno, int *numarray, int nfields);
> static getline(char *linebuf);
> static skip_ps_block();
> static skip_over_ps_string();
Index: libuschem/rdschem_lex.c
===
RCS file: /fs1/IFCTF-cvs/ueda/libuschem/rdschem_lex.c,v
retrieving revision 1.2
diff -r1.2 rdschem_lex.c
8a9,10
> #include 
> #include 
12c14
< extern char *malloc();
---
> //extern char *malloc();
14a17,18
> static yylex_qstr();
> static skip_over_ps_string();
Index: libuschem/rdschem_parse.c
===
RCS file: /fs1/IFCTF-cvs/ueda/libuschem/rdschem_parse.c,v
retrieving revision 1.11
diff -r1.11 rdschem_parse.c
7a8
> #include 
19a21,23
> 
> static skip_over_ps_string();
> static int parse_number();
Index: uschem-netlist/pinconn.c
===
RCS file: /fs1/IFCTF-cvs/ueda/uschem-netlist/pinconn.c,v
retrieving revision 1.3
diff -r1.3 pinconn.c
6a7
> #include 
10c11
< extern char *malloc();
---
> //extern char *malloc();
15a17,19
> 
> static record_pin_connection_tab(register struct pinconn *pc);
> static record_pin_connection_chain(register struct pinconn *pc);
Index: uschem-print/gschemcode.c
===
RCS file: /fs1/IFCTF-cvs/ueda/uschem-print/gschemcode.c,v
retrieving revision 1.7
diff -r1.7 gschemcode.c
8a9,10
> #include 
> #include 
33a36,51
> 
> static mymain();
> static do_line(char *objline);
> static do_box(char *objline);
> static do_circle(char *objline);
> static do_arc(char *objline);
> static setlinewidth(int newval);
> static setdash(int dashstyle, int dashlength, int dashspace);
> static emit_coordpair(int x, int y);
> static handle_pin(char *objline);
> static handle_T_obj(char *objline, int objlineno);
> static parse_numline(char *line, int lineno, int *numarray, int nfields);
> static getline(char *linebuf);
> static do_ps_block();
> static skip_over_ps_string();
> 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Working on xgsch2pcb-0.1.3 for Gentoo

[Peter Clifton]

On Wed, 2009-10-28 at 22:06 +, Frank Bergmann wrote:
> On Tue, 27 Oct 2009 22:50:29 +, Peter Clifton wrote:
> 
> > What I want to have eventually, is a "parts bin" window, where all the
> > parts yet to be placed are available. The user can then pick them up
> > just like out of the footprint library.
> > 
> > Bonus points for being able to multi-select, and hit "auto-disperse
> > selected" in the parts bin. Filter by name, by footprint (leave all
> > those decoupling caps to last etc..)...
> > 
> > Anyone want to code this??
> 
> Mmmh - digging in my local git repos give me this:
> 
> http://frajasalo.de/frank/projekt/pcb/pcb_part-view_20091028-2257.png
> http://frajasalo.de/frank/projekt/pcb/pcb_part-view_20091028-2258.png
> 
> Its a "part list" showing all parts in the design, not only the
> one that has not been placed. It still lacks some features
> (removing/adding parts from/to the design has no effect in the
> "part list", same for moving) especially a "pick up" button for
> your purpose. And its just a piece of code for learning something
> about pcb's internals :-)

That is cool.. I like the concept a lot.

Best wishes,

Peter C.




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Working on xgsch2pcb-0.1.3 for Gentoo

[Frank Bergmann]

On Tue, 27 Oct 2009 22:50:29 +, Peter Clifton wrote:

> What I want to have eventually, is a "parts bin" window, where all the
> parts yet to be placed are available. The user can then pick them up
> just like out of the footprint library.
> 
> Bonus points for being able to multi-select, and hit "auto-disperse
> selected" in the parts bin. Filter by name, by footprint (leave all
> those decoupling caps to last etc..)...
> 
> Anyone want to code this??

Mmmh - digging in my local git repos give me this:

http://frajasalo.de/frank/projekt/pcb/pcb_part-view_20091028-2257.png
http://frajasalo.de/frank/projekt/pcb/pcb_part-view_20091028-2258.png

Its a "part list" showing all parts in the design, not only the
one that has not been placed. It still lacks some features
(removing/adding parts from/to the design has no effect in the
"part list", same for moving) especially a "pick up" button for
your purpose. And its just a piece of code for learning something
about pcb's internals :-)

Frank.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB adding exporter GUI

[DJ Delorie]

After modifying Makefile.am, did you run automake?


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB adding exporter GUI

[Alberto Maccioni]

I modified the Makefile.am but Make still complained, so I tried with
makefile.in and this time it went through compilation; now the linker
(I suppose) can't find hid_png_init reference in hidinit.o. This is
strange, as I didn't modify hidinit.c.
Maybe I should reconfigure with some magic parameter, but which one?
I'm making an exporter to gcode, so that I can mill my pcbs without
chemicals; I think it should be kept separate from the main png
exporter.

Thank you for your help,
Alberto


2009/10/28 Peter Clifton :
> On Wed, 2009-10-28 at 09:02 +0100, Alberto Maccioni wrote:
>> I'm trying to write a modified version of png exporter gui, but I
>> continue to get compilation errors; it seems that Make doesn't have a
>> rule to build the new code (which is in a separate directory with a
>> different name).
>> I modified the .Po file in the .deps subdirectory but probably there's
>> something to do to the configure script as well.
>> Does anyone know how to do it?
>
> Leave the .Po files alone.. they are auto-generated.. If you open up the
> Makefile.am in src/, you will find the list of files to build:
>
> For different exporters (which can be conditionally built), there are
> separate sections, e.g.:
>
> libpng_a_CPPFLAGS = -I./hid/png
> LIBPNG_SRCS = \
>        dolists.h \
>        hid/hidint.h \
>        hid/png/png.c \
>        hid/png/png.h
> libpng_a_SOURCES = ${LIBPNG_SRCS} hid/png/png_lists.h
>
> hid/png/png_lists.h : ${LIBPNG_SRCS} Makefile
>        true > $@
>        (for f in ${LIBPNG_SRCS} ; do cat $(srcdir)/$$f ; done) | grep 
> "^REGISTER" > $...@.tmp
>        mv $...@.tmp $@
>
>
> You'll probably want a copy of that block, but changing the name to your new 
> name.
>
> Other blocks you might need to add to:
>
> EXTRA_LIBRARIES = \
>        libgtk.a liblesstif.a libbatch.a \
>        liblpr.a libgerber.a libbom.a libpng.a libps.a libnelma.a libgts.a
>
>
> BUILT_SOURCES = \
>        core_lists.h \
>        gpcb-menu.h \
>        hid/gtk/gtk_lists.h \
>        hid/lesstif/lesstif_lists.h \
>        hid/batch/batch_lists.h \
>        hid/png/png_lists.h \
>        hid/nelma/nelma_lists.h \
>        hid/ps/ps_lists.h \
>        parse_y.h \
>        pcb-menu.h \
>        res_parse.h \
>        hid/common/hidlist.h
>
>
> EXTRA_DIST= \
>        check_icon.data \
>        default_font \
>        $(srcdir)/hid/batch/hid.conf \
>        $(srcdir)/hid/bom/hid.conf \
>        $(srcdir)/hid/gerber/hid.conf \
>        $(srcdir)/hid/gtk/gui-icons-misc.data \
>        $(srcdir)/hid/gtk/gui-icons-mode-buttons.data \
>        $(srcdir)/hid/gtk/hid.conf \
>        $(srcdir)/hid/gtk/pcb.rc \
>        $(srcdir)/hid/lesstif/hid.conf \
>        $(srcdir)/hid/lpr/hid.conf \
>        $(srcdir)/hid/png/hid.conf \
>        $(srcdir)/hid/nelma/hid.conf \
>        $(srcdir)/hid/ps/hid.conf \
>        gpcb-menu.res \
>        pcb-menu.res \
>        pcbtest.sh.in \
>        dbus.xml
>
>
> DISTCLEANFILES= pcbtest.sh gpcb-menu.h pcb-menu.h \
>        hid/batch/batch_lists.h \
>        hid/common/hidlist.h \
>        hid/gtk/gtk_lists.h \
>        hid/lesstif/lesstif_lists.h \
>        hid/png/png_lists.h \
>        hid/nelma/nelma_lists.h \
>        hid/ps/ps_lists.h \
>        gts/gts_lists.h \
>        core_lists.h \
>        dbus-introspect.h
>
>
> You will probably be able to get your code to compile even if you
> haven't got _all_ of the above setup correctly. (They relate to creating
> dist tarballs, and cleaning things up so make distcheck will pass).
>
>
>
> Then.. open configure.ac in the top level directory. You'll find
> configure tests for the PNG exporter. You "might" not need to modify
> anything in confgure.ac, as it actually searches for HIDs to build:
>
>
> for hid in `cd $srcdir/src/hid; echo *`; do
>    F=$srcdir/src/hid/$hid/hid.conf
>    if test -f $F
>    then
>    echo checking $F
>        . $F
>        case $type in
>          gui ) hid_guis="$hid_guis $hid" ;;
>          printer ) hid_printers="$hid_printers $hid" ;;
>          export ) hid_exporters="$hid_exporters $hid" ;;
>          always ) hid_always="$hid_always $hid" ;;
>        esac
>    fi
> done
>
>
>
> I hope that points you in the right direction. Good luck.
>
> I should have asked at the beginning of this email.. what is it that
> your new PNG exporter does differently to the existing .png exporter?
>
> Would it be possible to just add features to the existing exporter?
>
>
> Best wishes,
>
> Peter Clifton
>
>
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Working on xgsch2pcb-0.1.3 for Gentoo

[Peter Clifton]

On Wed, 2009-10-28 at 03:36 +, Kai-Martin Knaak wrote:
> 
> What would be most useful is a way to transfer a selection from gschem to 
> pcb: Close neighbors on the schematic tend to be good candidates for 
> close neighbors on the layout. Currently I do this transfer semi manually 
> with the aid of the find dialog in pcb: Read the refdeses in gschem and 
> enter them as a regexp to the find dialog. Then do "disperse-selected". 

Somewhat difficult to do for all cases (e.g. hierarchical boards,
mangled net-names output from gnetlist).

I think you need to emit a list of gschem refdes for a given schematic
page, then feed into gnetlist (with a suitably modified back-end,
possibly additional front-end functionality too), so effectively you are
asking gnetlist:

Given this list of refdes:

R1
R54
U34
C9

What is the output refdes on the board.

The answer might be:

X3/R1
X3/R2
X3/U1
C9

(Depending on what gnetlist back-end people are using, possibly
including their own modifications).

We know the gnetlist _front_ end does the hierarchy names. Still.. the
netlist backend has an ability to provide new refdes for an input name.

gschem may need to provide context to gnetlist for which level of
hierarchy you are in. (My "input-buffer.sch" might be used in multiple
places). That makes things trickier! Perhaps the query ends up being:

top.sch:X3/input_section.sch:X2/input-buffer.sch/R1

(gnetlist given top.sch could then track the name.. it might also be
able to cope with "X3/X2/R1" directly).

Finally, assuming you have some process to query gnetlist for a the
correct refdes, you need to use PCB actions to select elements by name
(that "might" already exist, I can't recall).


__OR__

Code for the common case of gschem refdes == PCB refdes, and accept that
for some advanced users it won't work at present.



This is not easy to do correctly in a flexible suite like gEDA.


Best wishes,

Peter C.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB adding exporter GUI

[Peter Clifton]

On Wed, 2009-10-28 at 09:02 +0100, Alberto Maccioni wrote:
> I'm trying to write a modified version of png exporter gui, but I
> continue to get compilation errors; it seems that Make doesn't have a
> rule to build the new code (which is in a separate directory with a
> different name).
> I modified the .Po file in the .deps subdirectory but probably there's
> something to do to the configure script as well.
> Does anyone know how to do it?

Leave the .Po files alone.. they are auto-generated.. If you open up the
Makefile.am in src/, you will find the list of files to build:

For different exporters (which can be conditionally built), there are
separate sections, e.g.:

libpng_a_CPPFLAGS = -I./hid/png
LIBPNG_SRCS = \
dolists.h \
hid/hidint.h \
hid/png/png.c \
hid/png/png.h 
libpng_a_SOURCES = ${LIBPNG_SRCS} hid/png/png_lists.h

hid/png/png_lists.h : ${LIBPNG_SRCS} Makefile
true > $@
(for f in ${LIBPNG_SRCS} ; do cat $(srcdir)/$$f ; done) | grep 
"^REGISTER" > $...@.tmp
mv $...@.tmp $@


You'll probably want a copy of that block, but changing the name to your new 
name.

Other blocks you might need to add to:

EXTRA_LIBRARIES = \
libgtk.a liblesstif.a libbatch.a \
liblpr.a libgerber.a libbom.a libpng.a libps.a libnelma.a libgts.a


BUILT_SOURCES = \
core_lists.h \
gpcb-menu.h \
hid/gtk/gtk_lists.h \
hid/lesstif/lesstif_lists.h \
hid/batch/batch_lists.h \
hid/png/png_lists.h \
hid/nelma/nelma_lists.h \
hid/ps/ps_lists.h \
parse_y.h \
pcb-menu.h \
res_parse.h \
hid/common/hidlist.h


EXTRA_DIST= \
check_icon.data \
default_font \
$(srcdir)/hid/batch/hid.conf \
$(srcdir)/hid/bom/hid.conf \
$(srcdir)/hid/gerber/hid.conf \
$(srcdir)/hid/gtk/gui-icons-misc.data \
$(srcdir)/hid/gtk/gui-icons-mode-buttons.data \
$(srcdir)/hid/gtk/hid.conf \
$(srcdir)/hid/gtk/pcb.rc \
$(srcdir)/hid/lesstif/hid.conf \
$(srcdir)/hid/lpr/hid.conf \
$(srcdir)/hid/png/hid.conf \
$(srcdir)/hid/nelma/hid.conf \
$(srcdir)/hid/ps/hid.conf \
gpcb-menu.res \
pcb-menu.res \
pcbtest.sh.in \
dbus.xml


DISTCLEANFILES= pcbtest.sh gpcb-menu.h pcb-menu.h \
hid/batch/batch_lists.h \
hid/common/hidlist.h \
hid/gtk/gtk_lists.h \
hid/lesstif/lesstif_lists.h \
hid/png/png_lists.h \
hid/nelma/nelma_lists.h \
hid/ps/ps_lists.h \
gts/gts_lists.h \
core_lists.h \
dbus-introspect.h


You will probably be able to get your code to compile even if you
haven't got _all_ of the above setup correctly. (They relate to creating
dist tarballs, and cleaning things up so make distcheck will pass).



Then.. open configure.ac in the top level directory. You'll find
configure tests for the PNG exporter. You "might" not need to modify
anything in confgure.ac, as it actually searches for HIDs to build:


for hid in `cd $srcdir/src/hid; echo *`; do
F=$srcdir/src/hid/$hid/hid.conf
if test -f $F 
then
echo checking $F
. $F
case $type in
  gui ) hid_guis="$hid_guis $hid" ;;
  printer ) hid_printers="$hid_printers $hid" ;;
  export ) hid_exporters="$hid_exporters $hid" ;;
  always ) hid_always="$hid_always $hid" ;;
esac
fi
done



I hope that points you in the right direction. Good luck.

I should have asked at the beginning of this email.. what is it that
your new PNG exporter does differently to the existing .png exporter?

Would it be possible to just add features to the existing exporter?


Best wishes,

Peter Clifton




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: My uEDA-designed open source hardware board works!

[Peter Clifton]

On Wed, 2009-10-28 at 04:12 +, Michael Sokolov wrote:
[snip]
> Well, I have some news: I have finally got this board physically built
> (sent gerbers to fab, got PCBs back, populated one of them) and it works!
> So far I only have the CPU subsystem populated (not the SDSL part yet),
> but I still find it amazingly cool that I have an MC68302 microprocessor
> system designed by me, it's running at ~16.67 MHz with no extra wait
> states, 16-bit SRAM and flash, I've got a working serial console port
> and I'm talking to it: my own little M68K debug monitor running on my
> very own hardware design!

Congratulations!

[snip]

> * Being unhappy with the too-much-GUI-for-me EDA programs like gEDA, I
>   wrote my own non-GUI, non-WYSIWYG, totally Makefile-driven EDA system
>   (uEDA) to make this board and others in the future, and this board
>   project is naturally uEDA's first.  GUI-indoctrinated "professional
>   hardware engineer" types may scream in horror at the thought of
>   non-GUI, non-WYSIWYG EDA, yet I've designed a board of this complexity
>   with it and it works!

Well.. looking at it this way.. FPGA desiners use a lot of non-graphical
EDA design data with VHDL and verilog. That doesn't seem to stop them,
so I don't see why it shouldn't transfer for some aspects of electronics
design too. I'd have thought it applied more easily for digital, than
discrete analogue stuff though.

(I personally prefer a hybrid approach with FPGA design.. schematics for
high-level blocks showing the architecture, then VHDL for the innards.


Best wishes,

Peter C.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: My uEDA-designed open source hardware board works!

[David SMITH]

On Wed, Oct 28, 2009 at 04:12:12AM +, Michael Sokolov wrote:
> * Being unhappy with the too-much-GUI-for-me EDA programs like gEDA, I
>   wrote my own non-GUI, non-WYSIWYG, totally Makefile-driven EDA system
>   (uEDA) to make this board and others in the future, and this board
>   project is naturally uEDA's first.  GUI-indoctrinated "professional
>   hardware engineer" types may scream in horror at the thought of
>   non-GUI, non-WYSIWYG EDA, yet I've designed a board of this complexity
>   with it and it works!

Not necessarily - this is a change that the ASIC world went through many
years ago.  When I first started (mid 90s), we were using synthesis tools
to generate sub-block netlists, but then the top-level integration was
done using schematic capture.  Nowadays, it's done by writing HDL (VHDL
or Verilog) text netlists which connect them together.

I could certainly see the attraction of text-based netlist generation
for a heavily digital board, particularly one with lots of busses
flying around.  For the stuff I design at home, though, I think I'd
stick to GUI-based schematic capture, as virtually all of my digital
stuff goes inside a single EPLD/FPGA, and the schematic is all the
analogue stuff (PSU, I/O signal conversion, etc.)

However, I think you'd have a problem with non-GUI PCB layout.  Whilst
you could automate all of the routing and some of the placement, I'd
really struggle without a GUI for placing the parts where their location
matters (e.g. connectors, front panel stuff, etc.).  I suspect that
doing this textually would be a rather tedious and long-winded process.

Again, there are parallels with the ASIC world, in that a GUI tool is
usually used to create a floorplan for a block, which defines the layout
perimeter, the locations of all I/O pins, and sometimes the placement of
a small number of cells within the block, but the placement and routing
of most of the cells is left entirely to the automatic tools.

For professional PCB layout of complex boards, the PCB designer will
usually place the connectors, switches, displays, etc. and some of the
critical components, and then let the tool auto-place and then route
the rest.

-- 
David SmithWork Email: dave.sm...@st.com
STMicroelectronics Home Email: david.sm...@ds-electronics.co.uk
Bristol, England  GPG Key: 0xF13192F2


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: PCB adding exporter GUI

[Alberto Maccioni]

I'm trying to write a modified version of png exporter gui, but I
continue to get compilation errors; it seems that Make doesn't have a
rule to build the new code (which is in a separate directory with a
different name).
I modified the .Po file in the .deps subdirectory but probably there's
something to do to the configure script as well.
Does anyone know how to do it?

Thanks,
Alberto


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user