Re: gEDA-user: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: snip But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? Rick Please note: I am not saying this for or against XML. I just felt like the above sentences implied using a specific file format is an ultimate solution for compatibility. Please always read XML as any standard or widespread format, text or binary, for example json, plist, sql dumps, whatever. Using xml as file format for PCB (or any CAD program) will not automatically make it compatible with any other CAD program. I see two different things here. 1. Use a file format that is well documented and known (this can be a standard format like XML, json, plist, or a custom format with proper documentation). 2. How the content is actually represented. Point 1. is a basis, a must. Without that, we can not talk about making two programs compatible, since the data can not be read or written by the other program. However, just being able to read the file, but not understanding what they mean, won't make any compatibility. Thus point 2. is a must too. XML may or may not be a good solution for 1., but doesn't do _anything_ to 2. The current file format is plain text and documented enough (in worst case by the source code) that any developer has the chance to parse or generate it, this it also fulfills the reqiurements in 1. Switching (or not switching) to XML will not make a real difference in compatibility. Switching to any standard format may ease implementation as one doesn't need to write a custom parser. But don't overestimate this part either: using a parser generator helps a lot, and even going without that, I strongly believe that finally the real complex and big part of the work is 2., not 1. Making two CAD programs compatible is harder on the how we represent the design internally level than how do we convert the representation to an actual file format. Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Am 04.09.2010 05:29, schrieb Rick Collins: XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway? There is already a preliminary XML based CAD data spec proposed by IPC, you know, the guys who write specs for the PCB assembly industry... I don't know if it is the best thing ever invented and I expect the spec is not complete enough for everyone to make their data files 100% compatible without a lot of communication, but wouldn't it be a great idea to at least start on a path which could result in a common data base for CAD packages? What a concept! The spec I have seen that looks like it would apply is IPC-2511B. These things don't seem to be free, but I found this one somewhere, maybe on the IPC site. Rick There are some standards (IPC-2511B, IPC-2511A, IPC-2511-1, IPC-2511-2, IPC-2511-3) at http://webstds.ipc.org/2511/2511intro.htm http://www.google.de/url?sa=tsource=webcd=10ved=0CE0QFjAJurl=http%3A%2F%2Fwww.ipc.org%2F4.0_Knowledge%2F4.1_Standards%2FSpecTree.pdfrct=jq=IPC-2511ei=7veBTPvfG8aOswbSypTmCAusg=AFQjCNHHckOZXnmnwkjb51O54CMh0RGDxwcad=rja tries to map the standards world (design track on the right side is probably what we're interested in). Goggling the standard's names seems to suggest that these standards have found some adaption in other tools. ICP-2581 (with it's sectional requirements IPC-2582 to IPC-2588) is the latest; from a quick glance it doesn't look like XML though. IPC-2511B was the only XML one I noticed. Philipp ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus verilog Synthesis
Am 04.09.2010 06:19, schrieb Ronald Mathias: I transform the Verilog code containing behavioral statements into verilog code that contains only gate level instantiations. This is passed as input to ABC Logic synthesis tool. Finally the output generated by ABC is passed to Versatile Place and Route(VPR) program which generates the bitstream. You don't have to go down to gate level: Simple verilog, (e.g. still allowed to use '+', '-', but not '*', etc) can be read by vl2mv, you can the use vis to flatten the resulting blif-mv into blif, which can be read by abc. This is the way I currently do synthesis (for a simulated asic, directly writing the simple verilog vl2mv understands; the resulting gate level verilog is then simulated in Icarus to get timing). Philipp ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: error while loading shared libraries: libltdl.so.3:
On Fri, 2010-09-03 at 15:10 -0500, Kipton Moravec wrote: I upgraded my Ubuntu 08.04 to 10.04 and now gschem will not work. k...@red:/home/backup/Work/BuddiPole/Schematic/condisp $ gschem condisp-*.sch gschem: error while loading shared libraries: libltdl.so.3: cannot open shared object file: No such file or directory I checked Synaptic Package manager and it says libtdl7 is installed. I did find this: libltdl3: Package libltdl3 has no available version, but exists in the database. This typically means that the package was mentioned in a dependency and never uploaded, has been obsoleted or is not available with the contents of sources.list So do I have to reinstall the whole gEDA system? If you built from source, it sounds like a recompile may well be required to resolve the problem. 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: crosshair snaps to pins and pads... on locked component
On Thu, 2010-09-02 at 16:11 -0400, Ethan Swint wrote: I just can't figure out why can't the Crosshair snaps to pins/pads work when the component is locked. As far as I know, locking a component is for to lock the position of the component. What a coincidence. We were just discussing that on IRC. I think snap-to-locked is OK, but I want locked *elements* to be ignored. I have one design that has a big LCD covering up all my other parts, it's really hard to edit when every operation tags the LCD instead of the parts under it. How about snapping to pads on the far side? That can get pretty annoying for me. I want to see pads on the other side so I know where I can place vias, but I don't want to snap to them. On my various OpenGL branches, there is a patch which disables snapping to pads on layers which you aren't on. (IE.. only snap to component side pads if you are on a component copper layer). I don't think it can be separated too easily from the other patches I have to improve snapping heuristics. At some point I want to rationalise the whole stack and see if those changes can be pushed to master. -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote: As a kludge, call your layer by one of the magic names outline or route and it will be ignored by the DRC, and treated as non-copper. 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On 9/3/10, Stefan Salewski m...@ssalewski.de wrote:
On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote:
Can I get pcb to either treat a layer other than the default silk as
non-metal
(so it would not short pads and mess up nets),
No, currently we have only one silk layer. You may miss-use other
copper layers for that task -- it may work when that layer is not in
your real copper layer groups, but unfortunately it still connects to
vias and can generate shorts.
Probably this patch may be used as a workaround.
Put your non-copper layer into a distinct layer group
(File-Preferences-Layers, Groups Tab), add to the layer an attribute
named PCB::skip-drc (Edit-Edit attributes of-Current Layer),
and PCB should skip the layer during DRC and connections lookup.
Kind regards
From 1bec53aea09312b99ee14c40fe7efcaa80158467 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Sat, 4 Sep 2010 14:12:46 +0400
Subject: [PATCH] recognize PCB::skip-drc layer attribute
layers with `PCB::skip-drc' attribute are excluded
from DRC and connection lookup
---
src/action.c |2 +-
src/action.h |2 ++
src/find.c | 23 +--
src/global.h |1 +
4 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/action.c b/src/action.c
index 32e294c..2936080 100644
--- a/src/action.c
+++ b/src/action.c
@@ -6957,7 +6957,7 @@ find_element_by_refdes (char *refdes)
return NULL;
}
-static AttributeType *
+AttributeType *
lookup_attr (AttributeListTypePtr list, const char *name)
{
int i;
diff --git a/src/action.h b/src/action.h
index ee116e8..7b64e05 100644
--- a/src/action.h
+++ b/src/action.h
@@ -46,4 +46,6 @@ void warpNoWhere (void);
/* In gui-misc.c */
bool ActionGetLocation (char *);
void ActionGetXY (char *);
+AttributeType * lookup_attr (AttributeListTypePtr list, const char *name);
+
#endif
diff --git a/src/find.c b/src/find.c
index 593be70..ac94f4b 100644
--- a/src/find.c
+++ b/src/find.c
@@ -81,6 +81,7 @@
#include global.h
+#include action.h
#include crosshair.h
#include data.h
#include draw.h
@@ -826,6 +827,8 @@ LookupLOConnectionsToPVList (bool AndRats)
/* now all lines, arcs and polygons of the several layers */
for (layer = 0; layer max_layer; layer++)
{
+ if (LAYER_PTR (layer)-no_drc)
+ continue;
info.layer = layer;
/* add touching lines */
if (setjmp (info.env) == 0)
@@ -1173,6 +1176,8 @@ LookupPVConnectionsToLOList (bool AndRats)
/* loop over all layers */
for (layer = 0; layer max_layer; layer++)
{
+ if (LAYER_PTR (layer)-no_drc)
+ continue;
/* do nothing if there are no PV's */
if (TotalP + TotalV == 0)
{
@@ -2900,6 +2905,18 @@ ListsEmpty (bool AndRats)
return (empty);
}
+static void
+reassign_no_drc_flags (void)
+{
+ int layer;
+
+ for (layer = 0; layer max_layer; layer++)
+{
+ LayerTypePtr l = LAYER_PTR (layer);
+ l-no_drc = lookup_attr ((l-Attributes), PCB::skip-drc) != NULL;
+}
+}
+
/* ---
* loops till no more connections are found
*/
@@ -2907,6 +2924,7 @@ static bool
DoIt (bool AndRats, bool AndDraw)
{
bool new = false;
+ reassign_no_drc_flags ();
do
{
/* lookup connections; these are the steps (2) to (4)
@@ -3349,6 +3367,7 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
/* check if there are any pins or pads at that position */
+ reassign_no_drc_flags ();
type
= SearchObjectByLocation (LOOKUP_FIRST, ptr1, ptr2, ptr3, X, Y, Range);
@@ -3365,8 +3384,8 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
int laynum = GetLayerNumber (PCB-Data,
(LayerTypePtr) ptr1);
- /* don't mess with silk objects! */
- if (laynum = max_layer)
+ /* don't mess with non-conducting objects! */
+ if (laynum = max_layer || ((LayerTypePtr)ptr1)-no_drc)
return;
}
}
diff --git a/src/global.h b/src/global.h
index bb78abc..1c7ca26 100644
--- a/src/global.h
+++ b/src/global.h
@@ -301,6 +301,7 @@ typedef struct /* holds information about one layer */
char *Color, /* color */
*SelectedColor;
AttributeListType Attributes;
+ int no_drc; /* whether to ignore the layer when checking the design rules */
}
LayerType, *LayerTypePtr;
--
1.6.0.2
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Hello, DJ; On 9/4/10, DJ Delorie d...@delorie.com wrote: Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. Could you elaborate on the arcs, please? what it doesn't do? Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem doesn't store slot info?
On Thu, 2010-09-02 at 12:42 -0400, DJ Delorie wrote: Well, I did a git fetch/rebase, built, and installed... and still there. About says 20100214, gitk says no commits since May, do I have the wrong repository? The gschem binary is dated today. What is the SHA1 of your repository head. (Not including any local patches)? I've tried to reproduce the bug, but so far haven't been able to. -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: the incredible growing PCB window
gene glick wrote: Stefan Salewski wrote: On Sat, 2010-08-28 at 20:35 -0400, gene glick wrote: I haven't yet put my finger on what operations cause this, but the PCB GUI window keeps growing larger than my screen! Anybody know what gives? yep, sorry about that - PCB version 20091103 OS : linux, slackware V12 GUI: GTK compiled myself. Desktop: KDE 3.5 Some further info: - The problem is repeatable on other desktops (XFCE, Fluxbox, KDE) - It looks like the screen always grows when I set a mark, CTL-M, and move the mouse around. In the title bar is the position indicator. As the numbers move and become larger than the allocated space, the indicator box expands. On XFCE desktop, the position indicator grew to the left, pushing the pcb title left but the screen didn't grow - at least for a while. Eventually, it grew to the right. But on all other desktops, the window grew to the right only. It pushes the right hand side of the window off the visible viewing area. My pcb board area is 20 X 14, and the pcb itself is 11 X 11. regards gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 01:37:32AM -0400, DJ Delorie wrote: If we tagged individual objects with rules it would be difficult to edit rules in a systemetic way. So I don't think that's a good way to go. No, we tag objects with rule *names*. Hopefully rules can nest, so you can have meta-rules like signal-line-rule or 12vac rule. Without a tag, you'd get synthetic tags like line-rule or pin-rule. But suppose the user creates a rule like, all traces on Layer 3 must be at least 5mm apart, and then saves the file and reloads it. Now the information about what traces are affected is lost, except that all the traces on Layer 3 are coincedentally tagged with the rule. What if the user then decides he wants the rule to apply to Layer 4 instead? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: Don't hold back, tell us how you really feel! The spec is large because it addresses a wide range of design aspects, which is one of the great reasons for using it, one file for the entire design, schematic, layout, mechanical, etc, even board lay up. So the compatibility issue is moot because any one app only needs to deal with the portion that applies to it. Just don't muck with the other parts. The heavy issue is a red herring (are you planning on hosting this on a cell phone maybe?) No PCB file format is going to be easy for humans to read. Bandwidth? Back to the MCU in the cell phone I guess. Ugly, now there is a great technical argument. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? This is not an emotional argument, but a technical one, and the choice is not between XML and reinventing the wheel. (Sadly, my Lisp suggestion has been shot down - by better arguments than popularity, I might add. ;) There are other formats to consider, and yes, inventing one might be an option. How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? How do you know we won't one day need to work with 1000-layer boards when suddenly it /does/ matter how heavy the file format is? Unless you want feature-parity with other CAD programs, it is impossible to have file-format-parity. So no matter what, conversion programs will have to be written. Creating similar file formats won't help anything, other than to limit our own format, and potentially cause problems if PCB and another CAD program are able to open (and corrupt) each other's files. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 01:38:15AM -0400, DJ Delorie wrote: 1. Refuse to export-as-footprints any PCB with more than one copper layer. This will likely eliminate the most common problems. Edge connectors. Hmm. How about two copper layers, which would by default map to the top and bottom layers (whatever they are) on the PCB that the footprint is being used in? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
I'll have to save a sample next time it happens, I can't reproduce it manually :-P Mostly it's when you're using the global puller or toporouter and it makes all those sweeping graceful curves. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem doesn't store slot info?
What is the SHA1 of your repository head. (Not including any local patches)? I've tried to reproduce the bug, but so far haven't been able to. And, of course, now I can't reproduce it either :-P ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: the incredible growing PCB window
On Sat, 2010-09-04 at 07:54 -0400, gene glick wrote: gene glick wrote: OK, maybe now I do understand your problem. Your problem may be, that your GTK+ PCB main window grows horizontally, because there is not enough space available to show all text, that is the Menu text, filename, coordinates of mouse pointer... That may occur if your display screen is small, and your GTK font large. Please try this: Select File-Preferences, and then General, and Alternate window layout to allow smaller horizontal size. And try Put layout name on the window title bar below. Hope this helps. Another solution may be to select a smaller default font for your window manager, but that will concern all programs. If this still fails, you may need to patch the PCB sources... Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: the incredible growing PCB window
What's your screen resolution? I can reproduce the window grows feature, but only if I start with a really small window, and it only grows so far then stops. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
But suppose the user creates a rule like, all traces on Layer 3 must be at least 5mm apart, and then saves the file and reloads it. Now the information about what traces are affected is lost, except that all the traces on Layer 3 are coincedentally tagged with the rule. What if the user then decides he wants the rule to apply to Layer 4 instead? In that specific case, we could apply rules to layers as well as objects, but I see your point. Unfortunately, the math behind DRC is expensive, so generalizing the rules needs to mesh well with doing the math only once. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? iPcb . . . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Hmm. How about two copper layers, which would by default map to the top and bottom layers (whatever they are) on the PCB that the footprint is being used in? Stripline Antennas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Andrew Poelstra wrote: suppose the user creates a rule like, all traces on Layer 3 must be at least 5mm apart, and then saves the file and reloads it. Now the information about what traces are affected is lost, except that all the traces on Layer 3 are coincedentally tagged with the rule. What if the user then decides he wants the rule to apply to Layer 4 instead? I see having attribs define state for the whole board. If you change your mind, you would use the same script that you used to select a set of objects, then delete the unwanted attrib, or overwrite it. You need to search the whole design for attribs, since they may have moved along with their object to a new layer... I can't see a system of tracking how things are applied, just how they are now. In other words, use GUI and scripts to make selections, then change attribs. Do the same generic steps to add attribs as to delete. Which means it would be nice to have a GUI selection by area be well defined so action commands can refine the selection further. Right now we have various selected sets defined, but not sure how general that is. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Andrew Poelstra wrote: How do you know we won't one day need to work with 1000-layer boards when suddenly it /does/ matter how heavy the file format is? As in 3D circuitry in printed organic semiconductor... printed along with volume-defining material for circuit and package in one... We'll maybe be able to print a machine capable of running gschem and pcb with machines that are affordable by local shared fablabs or on a hobby budget in say, ten years? fifteen? Depending... Wish I had some expendable man-months-money to hire all the developers on the list today. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sep 4, 2010, at 4:30 AM, Ineiev wrote: Hello, DJ; On 9/4/10, DJ Delorie d...@delorie.com wrote: Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. Could you elaborate on the arcs, please? what it doesn't do? I've been running into trouble with the DRC and arcs, myself. I discovered it when doing some simple tests of the toporouter-- certain arcs produce DRC errors when there clearly is none-- says that there isn't 10 mils of clearance when there obviously is much more than that. Here's a minimal test case that demonstrates the errors: http://evilmadscientist/source/temp/topo_puzzle.pcb ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sep 4, 2010, at 4:30 AM, Ineiev wrote: Hello, DJ; On 9/4/10, DJ Delorie d...@delorie.com wrote: Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. Could you elaborate on the arcs, please? what it doesn't do? I've been running into trouble with the DRC and arcs, myself. I discovered it when doing some simple tests of the toporouter-- certain arcs produce DRC errors when there clearly is none-- says that there isn't 10 mils of clearance when there obviously is much more than that. Doh! Bad link. Correct one is: http://evilmadscientist.com/source/temp/topo_puzzle.pcb ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sat, Sep 4, 2010 at 1:11 PM, Peter Clifton pc...@cam.ac.uk wrote: As a kludge, call your layer by one of the magic names outline or route and it will be ignored by the DRC, and treated as non-copper. Peter, thanks for the tip. I may be doing something wrong, but even following the tips at http://www.geda.seul.org/wiki/geda:pcb_tips#how_do_i_make_a_board_outline_to_go_with_my_gerbers_to_the_board_maker the outline layer still connects my vias together. Kind regards, -- Pawel Kusmierski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sat, Sep 4, 2010 at 1:24 PM, Ineiev ine...@gmail.com wrote: Probably this patch may be used as a workaround. Put your non-copper layer into a distinct layer group (File-Preferences-Layers, Groups Tab), add to the layer an attribute named PCB::skip-drc (Edit-Edit attributes of-Current Layer), and PCB should skip the layer during DRC and connections lookup. Ineiev, thanks for the patch, it applied fine. However, I'm unable to find the (Edit-Edit attributes of-Current Layer). Is it placed somewhere else, or can I manually edit the .pcb file for the same result? I'm using pcb source tree from git, version 1.99z. I haven't found anything on editing layer attributes around google. Is there any place (apart from the source code) with some info on other possible values? Kind regards, -- Pawel Kusmierski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.09.2010 18:18, schrieb DJ Delorie: How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? iPcb . . . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I showd a geda schematic and the pcb board layout on my Nokia N900 (debian based) to my colleagues at work and they were impressed. I'm not saying that it's useful to do EDA work on a smartphone, in my case it was more or less a fun project raising the question Can you do that with your iPhone?. Nevertheless I was really impressed how easy it was to install the geda + pcb suite to my smartphone. The other valid question would be Can you do this with your $$$ eda application :-) . - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyCvZoACgkQn22l+QvEah3fxQCeO84y3Cuz83Hev3cYp1YJZndL awsAn1xalA6/rivS4bUKPSjjQj2EIIws =fMqF -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sat, 4 Sep 2010 11:24:38 + Ineiev ine...@gmail.com wrote: Probably this patch may be used as a workaround. Why don't we just push this patch to HEAD? This works just great. Thanks, Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
Ineiev, thanks for the patch, it applied fine. However, I'm unable to find the (Edit-Edit attributes of-Current Layer). Is it placed somewhere else, or can I manually edit the .pcb file for the same result? I'm using pcb source tree from git, version 1.99z. Do you have a local ~/.pcb/gpcb-menu.res or something? The .pcb file format is documented in the doc/pcb.pdf generated file, including the Attributes() syntax. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
At 11:49 AM 9/4/2010, you wrote: On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: Don't hold back, tell us how you really feel! The spec is large because it addresses a wide range of design aspects, which is one of the great reasons for using it, one file for the entire design, schematic, layout, mechanical, etc, even board lay up. So the compatibility issue is moot because any one app only needs to deal with the portion that applies to it. Just don't muck with the other parts. The heavy issue is a red herring (are you planning on hosting this on a cell phone maybe?) No PCB file format is going to be easy for humans to read. Bandwidth? Back to the MCU in the cell phone I guess. Ugly, now there is a great technical argument. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? This is not an emotional argument, but a technical one, and the choice is not between XML and reinventing the wheel. (Sadly, my Lisp suggestion has been shot down - by better arguments than popularity, I might add. ;) There are other formats to consider, and yes, inventing one might be an option. How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? How do you know we won't one day need to work with 1000-layer boards when suddenly it /does/ matter how heavy the file format is? So are you suggesting that we should, at this time, plan for running PCB on a cell phone? Do you want to design PCB to work on overtaxed virtual machines, if so, I expect there will be a lot more important things to optimize than the file format which only impacts the performance when reading or saving the file. If we need to work with 1000 layer boards, I expect we would have computers which would be not at all burdened by XML file formats. I'm trying to be realistic about the requirements. I think that the 2x or 3x factor of file size of using something like XML would be lost in the noise. The advantages of working with an industry standard file format could be very large. Of course as you or someone pointed out, IPC-2511B is not a well established format. But to my knowledge it is the only one that spans most if not all aspects of circuit board manufacturing. It seems like a great idea to work with something this useful and I am pretty sure that concerns with using it can be ironed out. Unless you want feature-parity with other CAD programs, it is impossible to have file-format-parity. So no matter what, conversion programs will have to be written. Creating similar file formats won't help anything, other than to limit our own format, and potentially cause problems if PCB and another CAD program are able to open (and corrupt) each other's files. I don't agree that a common file format has to be restrictive. If the file format is flexible enough, the program won't be limited. Everything doesn't have to be included from the start. I don't know if IPC-2511B is flexible enough for PCB and future ideas for PCB, but using XML I expect it can be expanded easily. I don't think anyone here has really looked hard at it. It may well be extensible. I don't know. But I would like to at least consider it and not toss it away without giving it a chance. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.09.2010 01:44, schrieb Andrew Poelstra: Hey all, I am working on the structuring PCB files in terms of functional blocks, and generalizing/extending the DRC rule format. (Things have slowed down as summer is ending but I am still working on this.) Mostly I am doing GUI work, since that is more-or-less stateless; I can spend 20 minutes reading docs or GTK code and not worry about making it work with PCB. But for the underlying logic: Naturally, I want to avoid any breaking changes to the PCB format, both to increase the chances of my code being accepted, as well as the obvious compatibility reasons. So I have a few thoughts: 1. Initially my plan was to tag every object in the PCB with a functional block. This would make attaching multiple tags easy, though it might bloat the file, and would be slow to initially parse and search. 2. Another idea would be to create functional blocks as recursive PCBs. This has been mentioned a few times on the list, and creates all sorts of exciting possibilities - from importing recursive schematics to reusing layout parts to clearer source control of PCBs. However, this also brings the ability to edit PCB components individually, which means that some parts could have different layers than others, for example. And then you have to deal with layer mappings and stuff and it's a huge complicated mess, both for the user and in the code. What do you guys think I should do? What would require the fewest changes to the PCB format, if any? Generalized DRC rules at least could be tacked on anywhere and would be quietly ignored by old versions of pcb, right? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Andrew, here are my thoughts about DRC: There are (at least) 2 contributors to what should be checked by DRC: 1. The obvious one: The capabilities of the manufaturer, e.g. min trace width = 4 mil, min distance = 4 mil, min drill . 2. The usage pattern: Traces where you expect high current (Vdd, GND, ...) can't use the minimum trace width, while traces that carry high voltages (and need to meet UL, VDE specs) can't have the minimum distance. A conclusion of the above is that the DRC rules are on a net base (potentially on a layer base, if you forece nets with a similiar DRC requirement to the same layer (sharing the copper with otherlayers). I see 4 roout styles in the defualt PCB, they could be used to work around a net specific definition. - From my point of view, there should be a way of defining net attributes from geda (see thread wishful UI). If you want to exetend the DRC capabilites things like handling of differenatial pairs, comparing netlenghs of busses comes to my mind. Going slightly off-topic, one goal would be to extract all physical parameters of a board (RLC for each net segment) and feed that back into a simulation (spice, gnucap, ...). - -- Mit freundlichen Gruessen Dietmar Schmunkamp PS: I won't have internet access for ht next 2 days, I'll comment responses on Tuesday. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk =Y576 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
I am currently having a conversation in the FreePCB forum about DRC. I think copper only checking is not adequate. There are design rules regarding solder mask which can not be checked properly just by checking copper to copper rules. Is there any checking done on the solder mask layer? If you want to read my post regarding this go to http://freepcb.com/ and visit the forum, Bug Reports, Design Rule Checking. The last post has a PDF attached. Rick At 06:41 PM 9/4/2010, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.09.2010 01:44, schrieb Andrew Poelstra: Hey all, I am working on the structuring PCB files in terms of functional blocks, and generalizing/extending the DRC rule format. (Things have slowed down as summer is ending but I am still working on this.) Mostly I am doing GUI work, since that is more-or-less stateless; I can spend 20 minutes reading docs or GTK code and not worry about making it work with PCB. But for the underlying logic: Naturally, I want to avoid any breaking changes to the PCB format, both to increase the chances of my code being accepted, as well as the obvious compatibility reasons. So I have a few thoughts: 1. Initially my plan was to tag every object in the PCB with a functional block. This would make attaching multiple tags easy, though it might bloat the file, and would be slow to initially parse and search. 2. Another idea would be to create functional blocks as recursive PCBs. This has been mentioned a few times on the list, and creates all sorts of exciting possibilities - from importing recursive schematics to reusing layout parts to clearer source control of PCBs. However, this also brings the ability to edit PCB components individually, which means that some parts could have different layers than others, for example. And then you have to deal with layer mappings and stuff and it's a huge complicated mess, both for the user and in the code. What do you guys think I should do? What would require the fewest changes to the PCB format, if any? Generalized DRC rules at least could be tacked on anywhere and would be quietly ignored by old versions of pcb, right? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Andrew, here are my thoughts about DRC: There are (at least) 2 contributors to what should be checked by DRC: 1. The obvious one: The capabilities of the manufaturer, e.g. min trace width = 4 mil, min distance = 4 mil, min drill . 2. The usage pattern: Traces where you expect high current (Vdd, GND, ...) can't use the minimum trace width, while traces that carry high voltages (and need to meet UL, VDE specs) can't have the minimum distance. A conclusion of the above is that the DRC rules are on a net base (potentially on a layer base, if you forece nets with a similiar DRC requirement to the same layer (sharing the copper with otherlayers). I see 4 roout styles in the defualt PCB, they could be used to work around a net specific definition. - From my point of view, there should be a way of defining net attributes from geda (see thread wishful UI). If you want to exetend the DRC capabilites things like handling of differenatial pairs, comparing netlenghs of busses comes to my mind. Going slightly off-topic, one goal would be to extract all physical parameters of a board (RLC for each net segment) and feed that back into a simulation (spice, gnucap, ...). - -- Mit freundlichen Gruessen Dietmar Schmunkamp PS: I won't have internet access for ht next 2 days, I'll comment responses on Tuesday. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk =Y576 -END PGP SIGNATURE- ___ 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: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 06:37:37PM -0400, Rick Collins wrote: So are you suggesting that we should, at this time, plan for running PCB on a cell phone? Do you want to design PCB to work on overtaxed virtual machines, if so, I expect there will be a lot more important things to optimize than the file format which only impacts the performance when reading or saving the file. If we need to work with 1000 layer boards, I expect we would have computers which would be not at all burdened by XML file formats. I don't see any value in making PCB work on cell phones, but we shouldn't unnecessarily preclude it. Certainly I don't believe the benefit of XML would outweigh the costs. Right now I am working on my laptop, which has no personal data on it; my entire /home is located on the server in my basement, mounted via SSHFS. Over a gigabit link this is fine; over wireless, opening large files is a relatively big deal. On a fast enough link, the CPU load for the encryption is the bottleneck. The point is that we can't be sure what the future will bring in terms of IOPS, storage capacity (even big servers often RAID together dozens of small drives to get high speeds against low capacity). Plus, even if individual file bloat is something we can ignore, what happens when you have thousands or millions of files in source control or in backups? I'm trying to be realistic about the requirements. I think that the 2x or 3x factor of file size of using something like XML would be lost in the noise. The advantages of working with an industry standard file format could be very large. Of course as you or someone pointed out, IPC-2511B is not a well established format. But to my knowledge it is the only one that spans most if not all aspects of circuit board manufacturing. It seems like a great idea to work with something this useful and I am pretty sure that concerns with using it can be ironed out. The problem is that there /isn't/ a useful industry standard format. If one appears, there is no guarantee that it will be long-lived or widely-adopted. Better we have a file format that works well for what we want to do, and use exporters for compatibility. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
How do you know PCB won't ever run on cell phones, or over a slow network link I have run gEDA and PCB over VNC, on slow links. Not fun. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB format wishlist
In parallel to how we want to implement the PCB file format, why don't we have a separate thread on *what* we want to implement? I'll propose the following as a starting point: 1) Better angle support: include rotation (in degrees, rotation/translation matrix, whatever) as a location argument instead of altering the pad/pin/silk/refdes/whatever location data separately 2) Footprint re-use: reduce file size by having components refer to a 'base' component with XYRS information, make component tweaking easier. Say you wanted to change all your 0603 resistors - it's easier to change the fundamental component, rather than the present case of to modifying individual components in all of their rotations. 3) Connectivity information: include the connection information between line segments, similar to (but not necessarily exactly!) SVG format, where multiple points and arcs can be included in one line. 4) DRC re-use: refer to a 'base' DRC rule, rather than re-describing the DRC at every instance. DRC rules could be arbitrarily complex or simple, e.g. elements in DRC class '250V' must have a 0.050 clearance from class '5V', but can have 0.010 clearance within '250V', or something along the lines of the 'skinny, normal, fat, power' we have in place now. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. We might not be able to use this flexibility until PCB's internals are modified, but the ability will be there, waiting to be tapped. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Andrew Poelstra wrote: The point is that we can't be sure what the future will bring in terms of IOPS, storage capacity (even big servers often RAID together dozens of small drives to get high speeds against low capacity). This kind of argument goes against any change. geda development already almost grind to halt because of it. Plus, even if individual file bloat is something we can ignore, what happens when you have thousands or millions of files in source control or in backups? How would XML lead to millions of files? The problem is that there /isn't/ a useful industry standard format. Like it or not, XML _is_ an industry standard. A standard for highly structured data formats. There is a reason why it is adopted by so many projects. The availability of well tested parser code is just one of them. If one appears, there is no guarantee that it will be long-lived or widely-adopted. XML is a good candidate for both. It already enjoys wide spread adoption. Many of them with high profile like SVG, DocBook, or OpenStreetMap. See http://en.wikipedia.org/wiki/List_of_XML_markup_languages Better we have a file format that works well for what we want to do, and use exporters for compatibility. This does not preclude XML. XML is not a format by itself, but just a framework of rules to define a format. If there are features that are too heavy for your taste, just don't use them in your specific instance of XML conform format. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: crosshair snaps to pins and pads... on locked component
Peter Clifton wrote: On my various OpenGL branches, there is a patch which disables snapping to pads on layers which you aren't on. (IE.. only snap to component side pads if you are on a component copper layer). I noticed this and liked it :-) I don't think it can be separated too easily from the other patches I have to improve snapping heuristics. At some point I want to rationalise the whole stack and see if those changes can be pushed to master. Yes, please. This semi forked state of the project is no good. I find myself selectively starting different versions of pcb depending on the task I want to perform. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: the incredible growing PCB window
Stefan Salewski wrote: Please try this: Select File-Preferences, and then General, and Alternate window layout to allow smaller horizontal size. And try Put layout name on the window title bar below. That is a good work around, thanks! DJ: What's your screen resolution? 1280 X 800. I have to run a video patch at boot time called 915resolution. Without this, I don't get resolution beyond 1040 X something. I can reproduce the window grows feature, but only if I start with a really small window, and it only grows so far then stops. Yes, same here - as long as I check off the alternate window option. Otherwise the window fills up all the horizontal width of display, and grows past it. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sun, Sep 05, 2010 at 03:00:45AM +0200, kai-martin knaak wrote: Andrew Poelstra wrote: The point is that we can't be sure what the future will bring in terms of IOPS, storage capacity (even big servers often RAID together dozens of small drives to get high speeds against low capacity). This kind of argument goes against any change. geda development already almost grind to halt because of it. ... Plus, even if individual file bloat is something we can ignore, what happens when you have thousands or millions of files in source control or in backups? How would XML lead to millions of files? XML brings with it an enormous cost in terms of file size and parsing speed. There will be millions of files regardless. But with a million files, every kilobyte of bloat becomes a gigabyte of bloat. We could use a zipped-XML format and avoid the filesize problems, but then we make script-parsability a lot harder. Actually, using any whitespace-independent format makes script-parsability harder, since tools such as grep or sed treat newlines specially. Also, comments are harder to insert. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sat, Sep 04, 2010 at 07:50:51PM -0400, Ethan Swint wrote: In parallel to how we want to implement the PCB file format, why don't we have a separate thread on *what* we want to implement? I'll propose the following as a starting point: I have one more suggestion: the facility to create recursive PCBs. What this will look like in the file format, I dunno. But we should keep it in mind. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sep 3, 2010, at 9:11 PM, Andrew Poelstra as...@sfu.ca wrote: On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote: XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway? For most data, XML ends up being 50% tags (and 50% data). It's hard to read for humans, bandwidth-intensive for machines, difficult to parse and generally ugly. Plus, the entire spec is enormous, and using only a subset of the spec means that we've lost a lot of the compatibility arguments in favor of it. This is why I use yaml to store data. It was designed to be human readable. It holds most high level data structures. And is very low bloat. You can tag the yam code to say that this is a particular data structure, like a footprint or via It allows for references. So all vias of a type could point to the same data and then we only would have to change one data structure to change all of the vias with the same tag. There is a c library libyaml. And many other languages have libraries, perl python ruby and many more. Although I did not see an official lisp library. But before we pick a file format we need to decide what we want to store. And then choosing how we want to store it. I am a fan of backwards and forwards compatible file formats. And if a file is a later version than we support then we should warn and only error if we encounter a difference that matters. Example the new polygon changes only break older versions of pcb if they are used. It would be nice if the parser knew what the minimum version of the format was required to store the design. Eg it uses pins pads and polygons, then it is version 2.0. If it used a polygon hole it's version 2.3, etc... Steve Andrew ___ 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: Functional blocks and PCB format changes
On Sep 3, 2010, at 9:45 PM, Andrew Poelstra as...@sfu.ca wrote: On Fri, Sep 03, 2010 at 04:44:14PM -0700, Andrew Poelstra wrote: However, this also brings the ability to edit PCB components individually, which means that some parts could have different layers than others, for example. And then you have to deal with layer mappings and stuff and it's a huge complicated mess, both for the user and in the code. For layer mappings, things don't necessarily have to be difficult. Especially if we had a good file format, people could write their own scripts if they want to do crazy things. In the meantime, we could: 1. Refuse to export-as-footprints any PCB with more than one copper layer. This will likely eliminate the most common problems. Disallows for edge connectors that have an a and b side. 2. As for PCB components that are themselves PCBs (ie, recursive PCBs), we could present the user with a mapping dialog when he tries to import a sub-PCB. The dialog would look something like (when importing a 6-layer sub-PCB into a 5-layer PCB): Imported PCB Current PCB Silk -- Silk Top-- Top Layer One -- Layer One Layer Two -- Layer Two Layer Three-- Bottom Bottom -- *New Layer...* The left-hand column is read-only. The right-hand column consists of drop-down boxes listing all the existing layers. Selecting *New Layer...* would pop up the New Layer dialog. We could even store this mapping information in the .pcb file and allow the user to change it after-the-fact. I like this idea. Andrew ___ 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: Functional blocks and PCB format changes
On Sep 4, 2010, at 8:49 AM, Andrew Poelstra as...@sfu.ca wrote: On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: Don't hold back, tell us how you really feel! The spec is large because it addresses a wide range of design aspects, which is one of the great reasons for using it, one file for the entire design, schematic, layout, mechanical, etc, even board lay up. So the compatibility issue is moot because any one app only needs to deal with the portion that applies to it. Just don't muck with the other parts. The heavy issue is a red herring (are you planning on hosting this on a cell phone maybe?) No PCB file format is going to be easy for humans to read. Bandwidth? Back to the MCU in the cell phone I guess. Ugly, now there is a great technical argument. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? This is not an emotional argument, but a technical one, and the choice is not between XML and reinventing the wheel. (Sadly, my Lisp suggestion has been shot down - by better arguments than popularity, I might add. ;) There are other formats to consider, and yes, inventing one might be an option. How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? How do you know we won't one day need to work with 1000-layer boards when suddenly it /does/ matter how heavy the file format is? Think BIG designs, a bloated file format will hurt. And I want PCB on my iPad. It has OpenGL ES, that would be putting it on a phone Unless you want feature-parity with other CAD programs, it is impossible to have file-format-parity. So no matter what, conversion programs will have to be written. Creating similar file formats won't help anything, other than to limit our own format, and potentially cause problems if PCB and another CAD program are able to open (and corrupt) each other's files. Andrew ___ 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: Functional blocks and PCB format changes
iPAd is about as closedsores and proprietary as it gets; you sure you want to support that? On 5 Sep 2010 11:57, Steven Michalske [1]smichal...@gmail.com wrote: On Sep 4, 2010, at 8:49 AM, Andrew Poelstra [2]as...@sfu.ca wrote: On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: Don't hold back, tell us how you really feel! The spec is large because it addresses a wide range of design aspects, which is one of the great reasons for using it, one file for the entire design, schematic, layout, mechanical, etc, even board lay up. So the compatibility issue is moot because any one app only needs to deal with the portion that applies to it. Just don't muck with the other parts. The heavy issue is a red herring (are you planning on hosting this on a cell phone maybe?) No PCB file format is going to be easy for humans to read. Bandwidth? Back to the MCU in the cell phone I guess. Ugly, now there is a great technical argument. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? This is not an emotional argument, but a technical one, and the choice is not between XML and reinventing the wheel. (Sadly, my Lisp suggestion has been shot down - by better arguments than popularity, I might add. ;) There are other formats to consider, and yes, inventing one might be an option. How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? How do you know we won't one day need to work with 1000-layer boards when suddenly it /does/ matter how heavy the file format is? Think BIG designs, a bloated file format will hurt. And I want PCB on my iPad. It has OpenGL ES, that would be putting it on a phone Unless you want feature-parity with other CAD programs, it is impossible to have file-format-parity. So no matter what, conversion programs will have to be written. Creating similar file formats won't help anything, other than to limit our own format, and potentially cause problems if PCB and another CAD program are able to open (and corrupt) each other's files. Andrew ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [5]geda-u...@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:smichal...@gmail.com 2. mailto:as...@sfu.ca 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 5. mailto:geda-user@moria.seul.org 6. 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: Functional blocks and PCB format changes
On Sep 4, 2010, at 6:00 PM, kai-martin knaak k...@familieknaak.de wrote: Andrew Poelstra wrote: The point is that we can't be sure what the future will bring in terms of IOPS, storage capacity (even big servers often RAID together dozens of small drives to get high speeds against low capacity). This kind of argument goes against any change. geda development already almost grind to halt because of it. Plus, even if individual file bloat is something we can ignore, what happens when you have thousands or millions of files in source control or in backups? How would XML lead to millions of files? The problem is that there /isn't/ a useful industry standard format. Like it or not, XML _is_ an industry standard. A standard for highly structured data formats. There is a reason why it is adopted by so many projects. The availability of well tested parser code is just one of them. If one appears, there is no guarantee that it will be long-lived or widely-adopted. XML is a good candidate for both. It already enjoys wide spread adoption. Many of them with high profile like SVG, DocBook, or OpenStreetMap. See http://en.wikipedia.org/wiki/List_of_XML_markup_languages I once proposed that we use SVG as the footprint format and making layers in the SVG represent the proper layer. Then footprints are automatically drawable by modern web browsers. Better we have a file format that works well for what we want to do, and use exporters for compatibility. This does not preclude XML. XML is not a format by itself, but just a framework of rules to define a format. If there are features that are too heavy for your taste, just don't use them in your specific instance of XML conform format. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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: Functional blocks and PCB format changes
Yes, I like walled gardens, you only let in those you trust. Don't like the walled garden don't use it. Anyhow, the software is free. Who cares about MY platform of choice be it Linux, Mac OS X, or windows, all of which geda supports, and more. On Sep 4, 2010, at 8:05 PM, timecop time...@gmail.com wrote: iPAd is about as closedsores and proprietary as it gets; you sure you want to support that? On 5 Sep 2010 11:57, Steven Michalske [1]smichal...@gmail.com wrote: On Sep 4, 2010, at 8:49 AM, Andrew Poelstra [2]as...@sfu.ca wrote: On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: Don't hold back, tell us how you really feel! The spec is large because it addresses a wide range of design aspects, which is one of the great reasons for using it, one file for the entire design, schematic, layout, mechanical, etc, even board lay up. So the compatibility issue is moot because any one app only needs to deal with the portion that applies to it. Just don't muck with the other parts. The heavy issue is a red herring (are you planning on hosting this on a cell phone maybe?) No PCB file format is going to be easy for humans to read. Bandwidth? Back to the MCU in the cell phone I guess. Ugly, now there is a great technical argument. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? This is not an emotional argument, but a technical one, and the choice is not between XML and reinventing the wheel. (Sadly, my Lisp suggestion has been shot down - by better arguments than popularity, I might add. ;) There are other formats to consider, and yes, inventing one might be an option. How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? How do you know we won't one day need to work with 1000-layer boards when suddenly it /does/ matter how heavy the file format is? Think BIG designs, a bloated file format will hurt. And I want PCB on my iPad. It has OpenGL ES, that would be putting it on a phone Unless you want feature-parity with other CAD programs, it is impossible to have file-format-parity. So no matter what, conversion programs will have to be written. Creating similar file formats won't help anything, other than to limit our own format, and potentially cause problems if PCB and another CAD program are able to open (and corrupt) each other's files. Andrew ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [5]geda-u...@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:smichal...@gmail.com 2. mailto:as...@sfu.ca 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 5. mailto:geda-user@moria.seul.org 6. 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus verilog Synthesis
Hi, Thanks a lot. Regards Ronald Mathias On 9/4/10, Philipp Klaus Krause [1]...@spth.de wrote: Am 04.09.2010 06:19, schrieb Ronald Mathias: I transform the Verilog code containing behavioral statements into verilog code that contains only gate level instantiations. This is passed as input to ABC Logic synthesis tool. Finally the output generated by ABC is passed to Versatile Place and Route(VPR) program which generates the bitstream. You don't have to go down to gate level: Simple verilog, (e.g. still allowed to use '+', '-', but not '*', etc) can be read by vl2mv, you can the use vis to flatten the resulting blif-mv into blif, which can be read by abc. This is the way I currently do synthesis (for a simulated asic, directly writing the simple verilog vl2mv understands; the resulting gate level verilog is then simulated in Icarus to get timing). Philipp ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:p...@spth.de 2. mailto:geda-user@moria.seul.org 3. 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: Color silk layers in pcb
On 9/4/10, DJ Delorie d...@delorie.com wrote: Ineiev, thanks for the patch, it applied fine. However, I'm unable to find the (Edit-Edit attributes of-Current Layer). Is it placed somewhere else, or can I manually edit the .pcb file for the same result? I'm using pcb source tree from git, version 1.99z. Do you have a local ~/.pcb/gpcb-menu.res or something? The .pcb file format is documented in the doc/pcb.pdf generated file, including the Attributes() syntax. In case your gpcb-menu.res lacks this item, you can issue the action through (Window-Command entry), the command is 'Attributes(Layer)'. Hope that helps ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 4, 2010, at 4:50 PM, Ethan Swint wrote: In parallel to how we want to implement the PCB file format, why don't we have a separate thread on *what* we want to implement? I'll propose the following as a starting point: 1) Better angle support: include rotation (in degrees, rotation/translation matrix, whatever) as a location argument instead of altering the pad/pin/silk/refdes/whatever location data separately 2) Footprint re-use: reduce file size by having components refer to a 'base' component with XYRS information, make component tweaking easier. Say you wanted to change all your 0603 resistors - it's easier to change the fundamental component, rather than the present case of to modifying individual components in all of their rotations. 3) Connectivity information: include the connection information between line segments, similar to (but not necessarily exactly!) SVG format, where multiple points and arcs can be included in one line. 4) DRC re-use: refer to a 'base' DRC rule, rather than re-describing the DRC at every instance. DRC rules could be arbitrarily complex or simple, e.g. elements in DRC class '250V' must have a 0.050 clearance from class '5V', but can have 0.010 clearance within '250V', or something along the lines of the 'skinny, normal, fat, power' we have in place now. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. We might not be able to use this flexibility until PCB's internals are modified, but the ability will be there, waiting to be tapped. I think that we should start from a bit lower level an include discussions of wishes for footprint file format as well, because currently footprints are a pcb file snippet. Desires for PCB footprints: True solder and paste mask layers. (could be converted to pads with no copper and the proper mask clearances set in the current PCB data structures) keepouts: - Mechanical: no components in these places. - Electrical: - No surface copper. (housings, connectors) - No internal copper. (antennas) Alignment points: - board edges - board slots - mating connector alignments glue/potting/underfill points. Any other thoughts? Steve ___ 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
gEDA-user: PSGroove open source hardware project
Does anybody want to help me make a PSGroove hardware project for sony ps3. Atommann's baby came early and I need someone else to help me finish it. [1]http://www.maxconsole.net/showthread.php?155644-Open-source-ps-jailb reak-hardware-designp=1258686#post1258686 References 1. http://www.maxconsole.net/showthread.php?155644-Open-source-ps-jailbreak-hardware-designp=1258686#post1258686 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
