kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/8/2014 3:45 PM, Vesa Solonen wrote:
> 05/04/14 13:35, Heiko Rosemann kirjoitti:
> 
>> Let me stress that I'm not writing this as a "please someone
>> implement this" eMail, it's just a few thoughts about what I would
>> consider most helpful.
> 
> To get a bit forward I'm asking interested team members to join in
> designing relevant file format _specification_ description of
> components. No consideration should be given to implementation
> details, but what information must be there and how interdependencies
> must be handled. The file format etc. may never get implemented, but
> at least there would be documentation to start from if someone would
> miraculously see value in implementing it.

Vesa,

You are little late to the party (3 years).  Here is the original
discussion which should take you a few days to digest.

https://lists.launchpad.net/kicad-developers/msg06358.html

I have also attached both the schematic and component (part) library
preliminary file format specifications (they are actually commented
files rather than a tradition spec document) for you to take a look at.
 This format is based on the original concept that schematics and
components would be unitless.  It may be worth considering relaxing that
idea in order to move forward but that's a separate discussion.  The
preliminary SWEET component library code has been written and documented
in the new/ folder in the source tree.  The one thing that is missing
from the schematic file format spec is bound objects (both external and
internal).  I have to think about that one carefully and get back to
you.  I personally do not want to reopen the conversation at this time.
 I don't have the time to rehash it right now.  As you can tell from the
original discussion, pretty much everything you would consider for a
schematic file format was discussed.  You are free to discuss whatever
you would like but I will not take part in it so someone will have to
take notes and get back me or one of the other lead developers.  There
are lots of things that need to happen in the Eeschema code base before
any of this can become a reality.  I am currently working on a road map
which should give developers an idea of what needs done in order to make
this happen.  Hopefully in the next week or two I will commit the
initial release of the road map.

Regards,

Wayne


> 
> As a means how to do that I propose adding a folder to documentation
> VCS. Or if it's easier and less risky, ask Dick to open one more
> branch for us – maybe even on Github. The supporting discussion on
> this list under a proper topic subject, but all specifications written
> in relevant (plain text?)files and change logs in commit logs.
> 
> 
> The rough idea what all of this should contain:
> 
> 
> 1) Device description data
> 
> Interdependencies between documentation, logical schematic symbols and
> physical layout footprints and 3D-models. Gate/pin swap data. Back and
> forward annotation support. Dynamic building of
> parts(devices/components) from any symbol and a footprint(or pcb
> fragment). 3D must be here as many 3D models may be linked to a same
> 2D-footprint. The possibility of bundling _everything_ in one DDD-file
> in case of special parts that consists fully non standard and non
> reusable symbol/footprint section. My topmost idea for the DDD bundle
> option is some standard archive format ~zip/tar. Individual bundles
> like current footprints in a library folder.
> 
> 
> 2) Symbols
> 
> The schematic symbols that eventually could reduce to a subset of SVG.
> No pin text or anything but symbol and pin locations must be hard
> coded here. Eventually someone is willing to migrate away from current
> embedded vector font in schematics anyway.
> 
> 
> 3) Footprints
> 
> Do we need any additional information/functionality or not. IIRC it
> was already said that any PCB fragment should/could eventually make a
> footprint. I see it's not exactly easy.
> 
> 
> 4) Something I forgot
> 
> Please see subject and search some more in archives.
> 
> 
> -Vesa
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: eeschema_part_sexpr_format_EN.odt
Description: application/vnd.oasis.opendocument.text

Attachment: eeschema_schematic_file_format_EN.odt
Description: application/vnd.oasis.opendocument.text