Ben's Blog

A while ago I read this excellent article by Evil Mad Scientist Laboratories describing the need for some form of visual diff tool for open hardware projects. I had been thinking this was a great idea, but while working on a recent project, decided to actually start implementing something. I use the gEDA suite of tools, so that is what I’m creating this for, but the majority of the plumbing should be reusable for other file formats.

The first piece of this puzzle for me was automatically making image files of my schematics and PCBs that have changed and adding them to each commit. GitHub has image diffing capabilities built in, so this works great. I implemented this a pre-commit hook in .git/hooks/. My git hooks can be found here. I have designed them to work with the git-hooks tool by Benjamin Meyer.

This script seems to work fine for me, though I’m open to suggestions for improvements. My major issues with how the hooks work (which are more issues with git than my hook) are

1. The status message in the auto-generated commit comments is not being updated with the new image files and
2. Hooks don’t get pushed into remotes

The first issue feels like a bug to me, but I suspect that it was done intentionally for some reason I’m not aware of. I have played with a work around by adding a prepare-commit-msg hook that just regenerates the commit message comments, but I have tested the pre-commit hook enough that I don’t feel I need to be aware of the addition of the images.

The second issue I am told is a security issue as it would cause arbitrary code to be executed on the machines of others who might clone (and possibly even the server). One nice feature of the git-hooks tool is that it can use hooks in a local repo directory, so if you include my scripts in the git_hooks repository, you just need to run ‘git hooks –install’ and you will have the hooks working. Without that tool, you can just manually copy them into the proper file in the .git/hooks/ directory.

This method works well if I want to view visual diffs online, but sometimes I might be offline or perhaps I just don’t want to push my project to a public GitHub repo. For that, I plan to make some simple scripts that call visual diffing tools on my local repository. Git has the capability to set your git diff tool, so my plan is to write a wrapper script that picks the right tool based on file types. This script might also generate an image from files that cannot be diffed directly and don’t have the above auto generated files

Edit: Of course not 20 minutes after I publish this post I discover schdiff, a tool bundled with gEDA since the start of 2012 that is designed to hook into git-difftool to provide a visual diff of gschem .sch files. One format down, some more to go.  

Edit 2: Less than a day later and I discover there is also a pcbdiff tool on my computer that came with gEDA pcb. In Arch Linux, it installs to /usr/share/pcb/tools/pcbdiff, but it is not in the path, so in my .bashrc I just added ‘export PATH=”$PATH:/usr/share/pcb/tools”‘ at the end. I feel pcbdiff outputs images that are too low a resolution, plus it can’t handle when the .pcb files change in physical size, so I might submit a patch or two. Long story short, now I just need to make a script that auto-calls these diff tools based on the file type.

At the end of last year, Microsoft launched the Kinect, a motion tracking add-on for the Xbox 360 gaming platform. Adafruit Industries, an open source hobbyist hardware company, announced that they would be offering a bounty to whomever first released an open source driver for the Kinect. The bounty started at $1000, but each time Microsoft complained about it, they raised the bounty. After only a week, the bounty had increased to $3000 and was awarded to a man in Spain. Within a few weeks of that, and having seen all of the interesting things that people were doing with the Kinect (and the large volume of sales they were receiving because of it), Microsoft changed their story, saying that they had originally left the Kinect open for such 3rd party projects.

I followed the story pretty much from the beginning and it was pretty interesting to see how things progressed. However, a few days ago Johnny Lee, a former developer of the Kinect and author of the Procrastineering blog, announced that he had been pushing for Microsoft to release Kinect drivers, but that they were unwilling. As a result, he had sponsored Adafruit to organize the Open Kinect challenge. While it probably would have been in Microsoft’s best interests to release the driver themselves, keeping Kinect development largely done on their platform, the Open Kinect challenge made a cross platform driver available which ends up benefiting everyone.

As some of you are aware, I am a member of the University of Manitoba SAE (Society of Automotive Engineers) Formula Hybrid team. The major project that I have been working on for a while now is a CAN bus controller Arduino shield. The system is based on the one designed by Mike Sefton last year. We are using the same CAN interpreter because the manufacturer was generous enough to donate some chips to us. These chips work well, but they are designed to be used with an OBDII reader, so we are using a few work arounds to get the system to work for us the way we need.

Aside from some simple changes to the circuit, there are two major changes to the system. First, I added a the NUP2105L chip to the CAN bus to give us some over-voltage protection. The major cause of failure last year was over-voltage, which is always a concern when dealing with electric vehicles. The second change was to allow an outside system to communicate with the CAN controller over a serial connection. Last year the CAN devices were controlled directly by the Arduino, but this year the Arduino is basically a middle man that can do some processing of commands if needed.

For the hardware design, I decided to try out a few open source tools. I first tried KiCad because it was more cross platform and a fully integrated suite. There were some things I didn’t like about it though (although I may have just been looking in the wrong place for the feature I thought was missing) so I decided to try out gEDA. I personally liked the feel of gschem better than KiCad’s schematic editor, and the PCB software seemed quite good to me too. The workflow between tools is a bit less intuitive, requiring a few terminal commands, but I am quite comfortable with the command line, so I can see myself using gEDA much more in the future.

The files for the hardware design are posted here: HARDWARE

The firmware for the Arduino is posted here: FIRMWARE

The firmware is currently a very basic repeater but will likely see changes once we start figuring out what specific features we will need. Feel free to post a comment or send me an email if you have any questions about the design.

This Christmas, my lovely girlfriend was kind enough to get me an Arduino Duemilanove. I’ll admit that I may have been somewhat specific about what I wanted as a gift, but she managed to still surprise me by buying an Arduino starter pack and wrapping every portion of the bundle in its own little box, including a whole box for all of the bubble wrap that the thing shipped in. I have a few project ideas for this thing, but I will save those for their own posts. Keep an eye out for some new micro-controller projects here.

I just read an article the other day about an interesting conflict between those that speak out for pro-piracy and those fighting for free (as in freedom) software. In Sweden, the political party that is aptly named the “Pirate Party” is lobbying for new copyright laws, specifically that any copyrighted material will become public domain 5 years after first being published, among other things. The free software advocates, however, depend on the current indefinite copyright law in order to keep their licenses, such as the GPL, working to protect free software from being utilized in proprietary software. Richard Stallman, founder of the Free Software Foundation, has pointed out that, if this new copyright law was introduced, proprietary software would only have the binaries released to the public domain and not the source code. Not only that, but these software providers could put time bombs in the software making it cease to function after the copyright has expired. Add to that the fact that after 5 years, any open source technology could be utilized by these proprietary software companies without passing on the freedoms to the user, this new law could actually end up doing more harm than good.

Stallman proposes a few solutions to this dilemma. The first option would be to allow an extended copyright for free software, but the Pirate Party accurately argues that this opens the doors to other kinds of exceptions, which could quite quickly defeat the whole expiry proposal. The second option Stallman suggests, which in a perfect world I think would be the best, is that proprietary source code would have to be released to the public domain upon expiry as well as the binaries. I suspect that enforcing this kind of ruling would be quite difficult, however, especially if you consider software providers that have faded away within the copyright period of their software and simply aren’t around to release source code. The final solution, which is likely the most feasible, is to have a variable copyright expiration where the most open/free content would be allowed to retain its copyright the longest. This way they do not have to allow for any special exceptions for different groups. The trick here is to find an accurate way of determining where any content fits on this continuum. Fully open and fully locked down software would be easy to pick out, but the gray area would be a tough call. Even amongst the open source community, licenses such as BSD might not be considered as open as ones such as the GPL as the BSD license allows commercial use, but one could also argue the opposite as the GPL locks out users who want to use the software for commercial use.

Lately I have been quite a big fan of Free and Open Source Software (FOSS). In fact, this blog runs purely on FOSS. However, not too long ago I was an advocate for digital piracy and anti-copyright thinking (and I am still not fond of copyright or “intellectual property”). It is interesting how two groups who have quite a number of common sentiments towards copyright law and “the man” can have drastically different demands for the industry as a whole. The fact that a small thing such as copyright expiry which seems beneficial to everyone can end up hurting a a group that is so similar in mindset is quite eye opening. I still fully agree with the Pirate Party that something needs to be done about copyright laws, but if that comes at the expense of FOSS, something needs reconsidering.