In June 2013 I attended a workshop on SMD soldering at the Gulaschprogrammiernacht 2013 (GPN13), a German hacker event organized by the regional CCC group in Karlsruhe. The result of a workshop organized by DrLuke was this small board with an ATtiny9 microcontroller and a 74HCT595 shift register.

The image shows my finished board with pin headers soldered. Later I changed the pin header for the 8 output pins again to make them point to the bottom. Now the board can easily be used on a breadboard for prototyping.

To program an ATtiny9, you need a programmer capable of speaking the TPI protocol. I have an AVRISP mkII that supports this, great! Still took me some hours to get it working with avrdude. That even included fiddling with the AVR Studio IDE in a Windows VM, as I just could not get it to work with avrdude. You really should not have anything connected when making the first tests—especially not something pulling the reset pin all the time. On top of that, I left a bitclock parameter in my Makefile that was approved for working with ATmega32. Turns out that causes the little ATtiny9 to feel offended and it refuses to work until a hard power reset. All that resolved, I was able to talk to the device with avrdude, yeah!

However, a greater challenge was to get a working compiler toolchain for this microcontroller. I tried the fairly standard avr-gcc from MacPorts first, but this toolchain does not support the ATtiny9 as target platform:

avr-gcc: error: unrecognized argument in option ‘-mmcu=attiny9’

I then also tried it on both a Debian and a Gentoo system, suspecting that something’s wrong with the compiler configuration. But I got the exact same results there. This was already the latest and greatest avr-gcc version 4.8.1 at the time of this writing. Again, after some tries I gave in and tried it with the AVR Studio IDE on Windows. It worked. So I was able to compile code for the ATtiny9 target using the avr-gcc shipped with AVR Studio, but not with the Mac OS X or Linux AVR toolchains. What was going on here?

After some searches on the web I found out that the support for the GCC architecture avrtiny10 for ATtiny4/5/9/10 was never merged into mainline GCC distributed by the FSF. Apparently, Atmel provides support for more hardware targets in their pre-compiled toolchains than what is provided by packages tracking the FSF GCC releases. But this is GPL’d software, the source must be somewhere!

The only thing I found are large tarball drops, not separate patches as I had expected. As I thought this might be a good idea in general to track this source in MacPorts, I actually tried to compile from their source. Fairly quickly I ran into build errors. These changes touch files without regeneration headers accordingly… I gave up.
(If anyone wants to pick up from where I left, here are my experiments against MacPorts avr-binutils and avr-gcc).

Finally, I settled to use a pre-compiled third-party toolchain, the CrossPack AVR toolchain. It seems to be built from the Atmel sources, as it supports the ATtiny4/5/9/10.

Eventually, I could do what I actually wanted: make something useful with that board that was lying around for so long. Actually, the first time I worked with a shift register, so I learned how to program it. Below you see the final result of this endeavor on a breadboard as published on my twitter account. I also published the simple testing code on my github account. Let’s see what else I could do with this board.