Actions
Forum Thread Details
  • Replies 30 replies
  • Subscribers 182 subscribers
  • Views 6317 views
  • Users 0 members are here
Related

CadSoft EAGLE development team developing XML format for schematic, layout and parts libraries!

Former Member

hello makers -

 

this is my first post here, i'm the senior editor at MAKE magazine and also the creative director at adafruit. i've been part of a growing movement called "open-source hardware" for the last 5 years or so. today we just got some great news from the CadSoft EAGLE development team about the their long term commitment to text based file formats in the world of electronics development. with their permission i am posting this here and on MAKE (as well as adafruit). it's extremely exciting for those of us who wanted an XML format for files and we're thrilled CadSoft EAGLE has said they're committed to it!

 

here's the overview of what we learned:

 

  • CadSoft EAGLE (our preferred schematic/layout software) has told us they are committed to a text based format in the long term.
  • The CadSoft EAGLE development team is developing a new format for schematic, layout and parts libraries that is XML, this means every object and line will be written out in text description.
  • You won't have to worry about binary file corruption, you will be able to hand-edit or generate schematics and layouts and of course the magic of version-control (such as github) will be easier than ever with real text 'diff's!
  • This will be a fully documented format and also of course a converter for old CadSoft EAGLE binary-type formats.

 

 

this is a great direction and i encourage you to support EAGLE as you decide which tools to use now and in the future. but that's not all, i've chatted with the element-14 folks and they're all set up for your feedback, if they're very interested in Maker voices their product development. so here's your chance folks!

 

cheers,

pt

Parents

  • I think having a text based format would be a real win for Cadsoft, it would bring greatly desired version control into our process scope.Being able to edit the files also adds to the version control benefits for community (OS) based work. As for the format I can see why some are afraid of XML as it can be bulky compared to simpler text formats. However XML does allow for powerful features like schema to reduce ambiguity and provide readable open standards. It also allows for easy transformation/conversion to other XML standards using standard XSL tools. Most programming languages also have good XML libraries opening the eagle files to an even wider audience for hacking and manipulation.

     

    As pointed out above by yzf600 size can be a real issue with larger netlists and projects, xml file editing with larger files is very difficult for a human. not so much on the parsing side for SAX based libraries. Probably the best way to alleviate size issue is to support and promote modularity. Modularity in Eagle allows sections of a design to be copied and pasted into new or existing projects, it also allows for repetitive reproduction of identical sections within a circuit/design. This can be represented in XML using XLinks pointing to accompanying XML modules. These modules get linked in during parsing. This is much more efficient as it reduces duplication of XML and allows for tree structures of a design. Such a standard could also allow for hardware licenses and or copyright/copyleft inclusion to make the entire sharing process much simpler. Modularity of this type would be a boon for community and opesource development within Eagle whilst simultaneously keeping file size under control. It also makes version control even easier particularly if the Xlink usage includes remote Git or subversion hrefs (via the standard url identity) allowing for remote version controlled modularity, something that the hardware opensource community would love to have.

     

    regards

    Al

  • in reply to Former Member

    Folknology - I don't know about your tree structure idea. That would work to a point. Hierarchical schematics are a good thing but what I suspect is that people will always tar and gzip their files.

  • in reply to Former Member

    Well folk can still tar and zip files as they wish, hierarchical/modularity makes no difference..

     

    regards

    Al

  • in reply to Former Member

    I would rather see hierarchical files layed out to do it than one large file that has in internal hierarchy. I have two suggested methods.

     

    1) Use the same format to make schamatics as you do for the symbols. Then placing a section of a schematic repeatedly is just the same as placing a symbol repeatedly. The thing is I don't see needing one large schematic like that.

    2) Just draw a top level schematic and show each repeated instance as a block. Then store the contence of the block in a seperate file. The question is one of how to make the netlister understand how to process it all.

     

    In the software I use now it basically could use ether method. Number 2 is cleaner but not I have had netlisting issues. I don't like number 1 because I don't like having that many repetitions on one page. Once you have seen one why draft or show multiples, it is just clutter.

Reply
  • in reply to Former Member

    I would rather see hierarchical files layed out to do it than one large file that has in internal hierarchy. I have two suggested methods.

     

    1) Use the same format to make schamatics as you do for the symbols. Then placing a section of a schematic repeatedly is just the same as placing a symbol repeatedly. The thing is I don't see needing one large schematic like that.

    2) Just draw a top level schematic and show each repeated instance as a block. Then store the contence of the block in a seperate file. The question is one of how to make the netlister understand how to process it all.

     

    In the software I use now it basically could use ether method. Number 2 is cleaner but not I have had netlisting issues. I don't like number 1 because I don't like having that many repetitions on one page. Once you have seen one why draft or show multiples, it is just clutter.

Children
No Data