Electronic – Version control of schematics and source code

ceaglehardware

I am developing an electronic device which has two parts: hardware (Eagle schematics) and firmware (C++ source code). I would like to track changes in both source code and schematics, but there are some points where I am not sure how to organize my work:

  • For the source code I would definitely use Git. But are schematics worth
    versioning when they are in fact binary files (new Eagle versions
    use some XML format, but it is not so human readable…)?

  • Is it good idea to put sources and schematics into one Git repository? It
    would make sense, but on the other hand my log would contain both software
    and hardware changes. Also the software can have several branches, but
    hardware probably not…

  • How to deal with hardware revisions? Tag them or save them in separate
    directories?

  • Also there could be some dependencies between hardware revision and firmware
    version. How to deal with them?

Could you please share your best practices with me?

Best Answer

Most of it comes down to personal preferences.

I track everything I do for a project in Git. Especially since Git handles most types of files, even binary, sufficiently efficiently. (In stead of built-in Altium SVN nonsense)

One of my main reasons to do so is that my customers don't all feel Dropbox is safe enough and I need a back-up system that I can access across the world, with also some versioning context on most of what I do. So I set up a private Git server and encrypted backup system and it works a treat. Boards, Schematics, Code, Documentation, Reports, Manual Modifications, everything is tracked.

I would normally create a a Repository for Hardware, one for Software and one for Firmware if it is a large, potentially long-running project, but for small service projects, examples or little experiments I often put it all in one repository, since the resulting chaos won't be big.

In Git you can use sub-repositories as well to integrate the Firmware into the Hardware project or the other way around, even if they are separately managed repositories.

For the larger projects I also commonly use bug tracking systems to keep track of issues and resolutions, again for HW as well as SW, Mantis is a nice one that can be used for free.

For hardware revisions I generate Gerbers, or whatever have you, tagged with the Git Hash for that revision, those Gerbers then are the only discrete "old fashioned" versioned stuff in folders by R01, 02, etc. Since you don't want to regenerate them all the time, but they are resulting files so shouldn't be versioned in Git itself, really (because your design software should be deterministic with generating production content, or else ...).

If there's something interesting in R01 that isn't happening in R02 (or the other way around), you have two Git Hashes with which you can compare source files, no worries.

As a final note, one conceptual example of a project, would have a Hardware repository, which also hosts a "BoardPinout.h" file. This file is included as a remotely versioned file into the Firmware repository, which has a few interface definition files that get remotely included into the Software repository.

Meaning every time I change a few signals without modifying broad functionality the HW project "updates" the BoardPinout, which then can be updated and used in Firmware, and so on.