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

The status message in the auto-generated commit comments is not being updated with the new image files and

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.

Back in October I had the opportunity to compete in the 5th annual IEEEXtreme programming competetion, a 24 hour challenge to complete as many programming problems as possible. There were a total of about 16 problems, released roughly once per hour or so. Our team completed around 5 or 6 problems (some were remarked after the completion of the competition due to a bug in the test system, so I am not sure about the final tally). Our team started with 3 members, but unfortunately we were down to 2 about 8 hours in, but we still felt as though we managed to do pretty well. We recently got the results back and were pleased to discover that we came in 240th (out of a total of 1515 teams), putting us in the top 16%! We also came in 14th place in Canada and 3rd place at our home University. I somehow managed to miss this event every other year it has happened but have always wanted to go, so I am glad that I got this final chance to compete.

I finally got around to making a quick demonstration of my NES-chuck. Code for the NES-chuck can be found here. The future event I mention is ArtCadia, which is part of Nuit Blanche. I’m not yet sure if I (or the NES-chuck) can attend, but I will keep this updated.

Two weeks ago I had the opportunity to go to Loudon, NH for the 2011 SAE Formula Hybrid competition. We had a long (38+ hr) drive out to competition and many sleepless nights working on the car, but it was a good experience. We brought 14 guys from our team out and there was always at least one person working on the car 24/7. Most of us electrical engineers wound up with the overnight shift and ended up working on the car from about 1 pm to 6 am, sleeping a few brief hours in the late morning. It was an interesting experience spending quite a few nights in the infield of a Nascar track. One day there were a bunch of locals riding their bikes around the track. A couple guys even brought out their penny-farthings. The first day we were there, they had an open track day and so there was a wide range of cars attempting an obstacle course, from a brand new Lotus to an 80’s station wagon.

As for our car, the short story is we weren’t able to drive it at competition. We poured many hours into it and after a passing preliminary mechanical and electrical tech inspections saw that we had a lot of work to do to pass final inspections. At that point we decided to focus solely on getting the car driving. After much frantic running around stripping, soldering, and crimping wires, plugging things in and seeing random smoke, and just general exhaustion, we finally got the tires to spin on their own. One of the motors started smoking pretty badly, but we decided that it just burned out a metal shaving that had found its way into the housing (the car had been super hard to push before that and was suddenly very easy to push after, so we must have released a short). At this point we were pretty excited, but noticed that the batteries were pretty low, so we went to get the charger. We had never charged our battery packs in their assembled state before, so we didn’t really know how it would work. As it turned out, it didn’t and so we took that as a good place to toss in the towel and go get some sleep.

Being so close to driving the car motivated us to get it driving in our spare time following competition. Well, that and the fact that they want to reuse much of the car for next year’s competition. Last Saturday we got together to work on it and, while I really didn’t want to work on it, I did want to see it move. We were just about to get the generator working so we could charge the batteries that way when we noticed we had no fuel. While some guys went to locate more (the engine needs fairly special fuel that is hard to find) a couple of us tried to get into the room where they stored extra fuel (everyone had forgotten their keys). Let’s just say that the locks on the doors are overpriced.

Once we got fuel, some maintenance people (one in a full haz-mat suit) came into the shop saying they needed to cut power to the building. Having lost most of our motivation to work on the car, we decided to try just driving the car on the little juice it had until it was run flat. Let me tell you that that thing can move. We shot a couple clips of it and they don’t do the thing justice, even when you were standing next to the camera. I’ve embedded some of the clips here (unfortunately Vimeo limits you to one HD video and 500 MB per week, so I will put up all the SD video and replace it with HD as I have the chance). I look forward to seeing how the team does next year now that they have a solid platform to start off with.

Last Sunday, UMIEEE together with UMARS (two University of Manitoba student groups I am a part of) got together to hold an embedded systems workshop on campus. We helped teach a bunch of fellow students the basics of designing and programming embedded systems. We used TI’s MSP430 Launchpad development kit, a super low price dev kit, so that everyone could go home with their project and continue experimenting. While the Launchpad (or rather the MSP430 microcontroller on the board) isn’t as easy to program as something like an Arduino, the Launchpad allowed us to convey some of the more fundamental principles of embedded design like bit masking and timer interrupts.

The morning consisted of getting the tools setup and getting a “hello world” application running. The official tools are Windows only, but the Launchpad does work with Mac and Linux once you figure out how to install everything. It actually seemed to work better, due partly to the fact that the tools are open source and hence not crippled versions of paid software, but also because the environment was less integrated (ie you use a text editor, a compiler, and a debugger all separately instead of a full blown IDE like they use in Windows). The Windows users ofter had to restart the whole IDE when one part of the system locked up for unknown reasons.

After lunch, we dove into making a much more ambitious project: an LED chaser. The design specifications we gave to everyone was something to the effect of “when you press a button, your chain of LEDs will light up one by one until you reach the final one in the string.” The idea was then to replace the final LED with the next person’s button input pin and watch as the lit LED ran across everyone’s boards. The day before, the volunteers leading the workshop got together and pumped out a quick (and admittedly buggy) code for this, so we felt it was an attainable project. We nudged everyone along, showing them how to light individual LEDs, use interrupt pins and timers, and wire up buttons with pull up resistors. I think only a few people actually got the final chaser working, but everyone had a good time.

You can see an abstract for the event along with a bunch more pictures here.