Electronics design, automation?

26.01.2012 16:03

Recently I had an opportunity to see development labs of a few local hardware shops and chat with people working there. In addition to my recent work at the Jožef Stefan Institute it made me realize that, for someone familiar with development practices in the world of free open source software, the field of professional electronics development is quite lacking in some regards.

Interesting. The software world has long ago established a need for revision control systems, code review tools, bug trackers and release procedures. And rightfully so - as I often rant about here, most software is so complicated today you are basically forced to use of such tools to achieve any kind of collaboration or a usable quality level. While it's true that too often good practices are overlooked in commercial settings and deadlines and marketing given priority, at least most developers will tell you what is the ideal they strive for.

Compared to that it was somewhat striking to hear that manual checking over multiple-sheet schematics for differences is common practice. Or that proper revision control systems aren't required and that keeping multiple folders of versions was all anyone would ever need. Or procedures for making fabrication documents, equivalent to a software release, that take too many minutes of clicking various settings in a graphical interface.

Agreed, most electronics development done in small groups and companies is simple enough to involve only one person. It also involves simpler designs and nowhere near the layers of abstraction present in software. But on the other hand mistakes are much costlier here. If a botched software release these days means uploading a new package or even just updating some scripts on your web server, a broken prototype hardware design sent to manufacture wastes much more tangible resources.

A collection of Eagle dialogs

One thing software developers learn is not to trust themselves. Any repetitive tasks should be scripted and should involve as few and as simple steps as possible. There should always be ways to double check your or your colleague's work. After a long work day I don't trust myself that upon saving a file I only made the changes I wanted and didn't accidentally drag an odd trace out of place while I was experimenting with layout. I don't believe that I won't forget to check that critical check box in the GUI the tenth time I will be exporting Gerber files. And most of all, I will never be sure that when comparing two PDFs centimeter by centimeter and line by line I won't miss a difference.

Not surprisingly, voices to improve this situation are being heard as open hardware philosophy becomes more widespread. Some of the blame here certainly goes to the lack of tools that would allow such processes. It appears that if you want to have them out of the box, you either need to go for some very expensive proprietary software aimed at large teams and huge projects, or funny enough, free software tools like gEDA.

More concretely, CadSoft Eagle, the software most used for small projects and not that uncommon also in the open hardware community because of its low cost, has a distinct lack of such capabilities. Having just finished my first design in it and finding out all of the above, I tried to change a few things for the better.

Demonstration of eaglediff, visual diff for CadSoft Eagle.

Hence, eagle-automation. It's a small collection of Python scripts that currently allow you to do just two things:

  • Make a set of fabrication documents from a single Makefile without clicking on a single dialog (with credits to Andrew and his blog post).
  • Do visual diffs between revisions of schematics and board layouts stored in git, like the one shown above

The installation is as simple as the usual Python setup.py install dance (you need Python Imaging Library) and the git integration uses git-difftool which is present in recent versions of git. For the rest I refer you to the README file. Apart from finicky Eagle scripting it's quite simple actually.

So, most of all, I hope this will make open hardware development easier and more reliable. I will still strive to use open tools like gEDA as much as possible - with which, by the way, I never had much use for visual diffs because of its human readable ASCII file format - but I also understand that a lot of people are stuck and will be stuck for some time behind proprietary tools. But I don't see that as a reason why lessons learned the hard way by the software world should not be reused.

Posted by Tomaž | Categories: Code

Comments

Interesting... and it looks like the diff tool could be made to work with KiCAD easily enough...

Pulkomandy, if you manage to do that, send me a mail or a pull request on github. Maybe it can evolve from eaglediff to edadiff.

Posted by Tomaž

unfortunately, there is no support yet for scripting or command line access in kicad. However, I asked for some help and found this :
https://blueprints.launchpad.net/kicad/+spec/add-qi-hardware-patches
http://src.lgg.ru/2011/12/kicad-schhist-view/

The main problem being I can't read russian and google translate isn't very good at it either...

Thanks for the links. Unfortunately I don't understand Russian either, but from the screenshots pcbhist and schhist definitely look very interesting.

Posted by Tomaž

Add a new comment


(No HTML tags allowed. Separate paragraphs with a blank line.)