Ben's Blog

While working on a project this week, I was trying to see what some silk screen art would look like on a PCB I’m working on, but the “photo realistic” export mode of gEDA pcb was restricted to only green solder mask, tin plating, and white silk screen. The fab house I plan to use only provides purple solder mask, gold plating, and white silk screen. Rather than try to tweak the green image in GIMP until it looks half decent, then repeating the process for each candidate silk screen image (and then each future project as well), I decided I would just write a patch!

My patch for gEDA pcb allows the user to now select a solder mask colour of green, blue, red, purple, black, or a (questionable) white, a pad plating colour of regular tin or gold, and a silk screen colour of white or black. All of these options are pictured above. You can find my proposed patch here, and hopefully it be accepted into the core software soon so that you can get it from your system’s repository.

I’ve been a fan and advocate of open source software for some time now, but I am pretty sure that this is the first time that I have actually submitted a patch to a somewhat mainstream open source project. I’m pretty pumped and I hope to do more soon. I heartily recommend it.

Update 2012-06-14: After some suggested improvement to my patch (additional yellow silk as well as the addition of copper and silver pad plating) my patch has officially been accepted into the gEDA pcb repository! You can get the latest version of the code here: git clone git://git.geda-project.org/pcb.git

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.

Photo "borrowed" from Leif Norman (click image for source)

This past Saturday was Nuit Blanche here in Winnipeg. Some 30,000 people went around the city checking out various exhibits of art and culture. One of the exhibits at the art gallery was ARTcadia. A bunch of displays setup with indie games and hacks. I had the NES-chuck out again and it saw a lot of use. Click here for some more pictures from the WAG.

While similar to Re:Play, the core difference for this event was that the games were setup as displays rather than booths. Because of this, there wasn’t someone around to provide instructions on how to start the game (ie. how to access the start and select buttons). We had a sign up with some instructions, but few people showed any interest in reading the signs. I may have to re-evaluate how this thing works for any future public displays.

CBC was running a contest called “Culture Vulture” where you have to go to cultural events and text in the posted word for an entry. SkullSpace must be getting some attention because the keyword posted at the WAG was “hacker”.

NES-chuck Demo from Benjamin Bergman on Vimeo.

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.

After the break, there is a rough draft of my script for the video.

Read More >>

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.