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 At 11:00 PM 9/3/2010, you wrote:
Re: functional blocks If we contemplate changing the PCB file format, it would be nice if we went with something that was intrinsically extensible. Knowing that the 5th element in a list with '[' means "clearance" is a bad format, but seeing "clearance=5mil" in a list of attributes is much better. We use something suitable as our menu resource, but folks have argued for XML too. I don't want to bring in something as heavy and complex as XML, but maybe a small parser like our resource parser that "just happened" to use XML format would buy us some usefulness at low cost. For performance reasons, it might be useful to have both an ASCII and a compiled binary format for these, with a converter. I've done stuff like this before; parsing a huge ascii file is a CPU hog compared to something designed to be digested by a program. Note we already have the ability to store attributes at the layout, layer, and element level. Perhaps that would be one place to hold new DRC rules? If we tagged the rulesets, we could then assign those tags to objects on the board, although storing such tags means a file format change. Maybe the new format can specify mandatory stuff as the first few non-tagged values (like line start/end coordinates) and have everything else be tagged after that (like clearance=1mm) so it's more free-form? We'd need some meta-rules for specifying defaults. Re: DRC Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. It would be nice if it told us the *actual* design rules used (what's the closest cross-net spacing? Smallest drill? Etc) too. Re: recursive PCBs I think the first step in this type of change is to tag layers by type. I've spec'd this out before, I think, and it's the "Upgrade of layer and design objects" in our big "statement of work" (SOW): http://www.geda.seul.org/wiki/geda:pcb_funding_sow Those items are approximately in do-in-this-order order, but the GUI stuff can go anywhere. Anyway, layer design tags each layer with a type, such as "top side silk" or "inner keepout" (a combination of a "where" and a "what", and optional "invert"). This is the basis for elements-as-pcbs and nested pcbs. The tricky part is not the data structures, but mapping the various layers in each submodule. For example, if you imported a two-layer board module into a four-layer board, what happens? Or an element description with "keepaway" on "all inner layers", how does that map to a six-layer board? Etc. Some of that work can be made easier to code if we switch to C++ officially so we can use a real OO language instead of the OO hack we currently have. There's a patch in the tracker to make the code C++-compatible, someone (i.e. me) needs to review it so we can get it committed and start seeing who'll have problems if we switch to C++. Then you could have each object know how to draw itself (or part of itself, usually by layers) just by foo->draw(). I don't think this is *needed* though. We just need a new object type that is itself a PCB (or at least the PCB->Data structure, like a Buffer), a way to nest all the draw/find/select etc stuff, and a way to tell the GUI which object(s) you're editing. That automatically gives you a footprint editor too :-) If you'd rather work on the GUI, though, that's also a needed project. It would be nice if the GTK gui supported all the modern Gnome stuff, like dockable toolbars and menus-with-icons. The SOW has an entry for that also. _______________________________________________ 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