Mail Archives: geda-user/2015/08/24/23:05:13
On Mon, Aug 24, 2015 at 8:38 PM, Lev (leventelist AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> I started to write a script that generates an sqlite database from pcb
> footprint objects to be able to easily generate pick and place data, and
> other useful information.
>
> So I started to write the scheme of the database, then I found myself in
> defining a complete database structure for PCB data.
>
> Here I propose the file format of the next generation of PCB. The file is an
> sqlite database. This is not uncommon in EDA; Zucken's CR5000 product has its
> file format as a database.
People including me have long resisted databases but PCB is so broken
I will embrace anything that causes people to unify file handling.
Thank you very much for doing this.
> Take a look at tree.txt. You can define primitive object, that is oval,
> rectangle, etc, and you can define pcb, and component objects. There is
> one table that lets you attach (many to many relation) objects to each
> other. There are relations, that doesn't make any sense, i.e. attaching
> a pcb object to a primitive object.
I think (DJ is the authority here) our current file architecture does
not do ovals and etc because it was based exclusively on things that
are directly from the gerber specification. The one exception I is
polygons. We need higher level objects like this just keep what I said
in mind, it might make the PCB interface easier to map.
While you are doing this there are some things that would be nice to
add before you have users. It would be nice to have copper areas that
are exposed but not automatically given solder paste, we also have no
mechanism right now for keep always.
The current format also includes netlist. Really it should have 3. The
one you are feeding in. The one you are feeding back (for back
annotation) and the one you have now.
> However, you can attach pcb to a pcb. Footprint in this sense is a
> sub-pcb. There is a 'component' object, but this can be omitted, or
> just simply a placeholder for refdes, and other data.
Ok but everything should have it's own file type and version number.
> Coordinates are relative to parent object's 0 point.
>
> With this data format, one can define arbitrary footprints. No restrictions
> like "no silkscreen polygons".
To be fair to DJ and the other authors those are not arbitrary. Folks
just kind of coded themselves into a corner.
> Lot of things are missing, like texts. This is just a sketch.
>
> Okay. I'm not a database architect, and you can now start throwing eggs,
> potatoes, tomatoes. Please be gentle. I know, it is hard to diff (but you
> can make a nice difftool for this). I know that sqlite is yet another
> dependency, but makes it very easy to work with PCB data.
Can we keep your concepts and dump the idea of sql? I will really miss
having human readable PCB files.
> Attached is scheme.sql and the tree.txt.
>
>
> Lev
>
> --
> 73 de HA5OGL
> Op.: Levente
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
- Raw text -