Programming an AVR microcontroller using OS X

Christopher Dwan - March 20, 2004

I have been going to meetings of the Twin Cities Robotics Group and have succeeded in programming an AVR microcontroller using the USB port of my Powerbook G4 laptop. So far as I know, this is not a process that is well documented on the web, and there has been some interest within the group in a recipe for what I did to achieve my current, limited success. Here it is. Good luck and caveat emptor.

None of this progress would have been possible without the help and encouragement of Alan Kilian. He's a technical wizard. Most of the work was done at his Robot Shop of Horrors. Jeff Sampson introduced me to the avrproject kit.

In approximate order from the device to be programmed up to the user interface of the computer:

Microcontroller hardware
Programmer
USB to Serial dongle for OS X
Flash software
Compiler

In this image, you can see the powerbook, the USB to serial adapter (teal), an ordinary serial cable (grey), the AVR-ISP programmer (darker grey, with the green light), and the avrproject kit. On the screen (left terminal) is the output from successfully flashing a program onto the kit.

Microcontroller Hardware

I have been using the AVR 2313 chip, mounted in a kit available at avrproject.com. I found the kit to be a good, affordable starting point. It provided what seems to be most important for the novice: A starting place with some set of functionality. I will undoubtedly expand into other mountings and other chip families in the future, but this is what I'm using right now.

The AVR series of chip are made by Atmel corporation. They vary from small form factor, small memory devices like the 2313 (with space for 2,000 instructions) up through the "Mega128" with 128K of memory and several specialized processing units built in. My impression is that the methods I have used will be applicable to any microprocessor in the series, but I could be wrong. I have tested the setup with the "STK-500" starter kit from Atmel, and it worked just fine.

Atmel provides a large number of starter kits, compilers, and other support. They do not, so far as I can tell, provide any software for the Apple's OS X.

Programmer

In order to "flash" a program onto the microprocessor, one must use some sort of "programmer" device to communicate with the chip. This is a piece of hardware which puts the chip into a mode where it can be programmed, sends the memory image to be placed onto the chip, and concludes the session. Using the parallel, 25 pin "printer" port on many PCs, this can be accomplished with a special cable attached directly to the computer and to the "programming" pins of the chip. Serial ports require a bit more work, because of the nature of the interface. I'm being vague about that because I don't really understand it. I'm a software guy.

The programmer I have been using is the AVR-ISP (stands for "AVR In System Programmer"). It is a small plastic connector with a serial port (female) on one side and an AVR six pin "programming" cable on the other. The six pin cable can be swapped with a ten pin version, but for the moment I'm sticking with the six pin. Inside the box are two microprocessors on a printed circut board (PCB). I'm told that one of them holds the "bootloader" and is the brains of the operation, while the other serves as a staging area for the program as it is making its slow, serial way off the serial port.

This device cost me $30 at Digikey. There are others available, this is the one that I have.

USB to Serial dongle for OS X

This is where it starts to get Apple-centric.

My powerbook is a fabulous machine, and I love it. It has no serial port. In order to communicate with the serial port on the programmer, I have to use a USB to serial adaptor. I experimented with three of them, and two worked out okay.

Do not try the Belkin F5U409. It cost me $50 at Compusa, and I will have to sell or return it. I should have done my homework first. The driver software they have available is listed as "beta" and "unsupported." The packaging indicates that OS 8.2 and higher are supported on macs. This (according to Belkin support) does not include the OS X series.

On my system, when I plug the Belkin device into the USB port, I get a message indicating that the "system extension cannot be used." I would think that Belkin might have tested the driver before shipping it at least to the point that it didn't produce an error message when you turn it on.
- This guy seems to have had a similar experience.
- This thread describes a bit of anger with Belkin over this device.
- As does this one
Like I said, I should have done my homework. There's a decent project for someone who loves hardware driver hacking to build an open source driver for this thing. I'm not aware of anyone who has done this, and I do not plan to.
Keyspan sells an adaptor that looks remarkably like the Belkin device, except that their drivers actually work. I do not own one of these, but I've tried one and it worked just fine.
SerialIO seems to be a company that is sold, rebranded, under many names. I got my USB -> serial dongle as part of a deal from Palm because the chargers for the Palm V will occasionally bake a serial port on a motherboard. They sold these devices at a loss to cover their butts. The only difference between the adaptor that I have and the one in the picture on that web page is that mine has a sticker on it that says "iConcepts." I have not yet cracked it open to verify that the chipset is from Prolific...but I'm pretty sure that it will be.

In any event, once you get a USB to serial adaptor, install the driver. After that (and a theraputic reboot if needed) plug in the adaptor and (in a terminal window) run ls /dev | more. Look for a line that looks like: cu.usbserial0. That will be your device file for later on in the instructions. The tipoff that it's really the correct file is that it will appear and dissapear when you plug and unplug the USB adaptor. This will be fun at first, but quickly loses its appeal.

Flash Software

Flashing the microprocessor is the process of transferring a compiled program from the computer to the chip. At this point, use of the command line becomes very important.

The most popular application for flashing AVR chips from the Unix command line is probably Avrdude (AVR Download/UploaDEr...yeah, it's a reach). It provides lots of options, and it's open source which means that we were able to hack the code directly rather than meekly whining at a support tech. Avrdude does not compile "out of the box" for OS X. We had to disable all support for the parallel port in order to get it to build. This was a pretty horrible hack job that I'm too proud to document here. At some point in the future, I plan to take a second look at these code modifications, to do them correctly, and to contribute them back to the project. For the moment, I'll just provide a binary executable here, and a configuration file crippled so that it will also work here.

I have installed these at the following locations on my machine: /usr/local/bin/avrdude and /usr/local/etc/avrdude.conf. I don't want to go into too much detail on the Unix shell environment and the command line on this page (which is too long as it is). Suffice to say that you will need to be able to run programs from the command line in order to make any of this work, and that there are many excellent books available on the topic.

Assuming that we have downloaded a compiled binary for the 2313 (from AVR Project for example), here is what I would do to flash it onto the processor:

To see all the options available for avrdude, run it all by itself

riptide:~/robot cdwan$ avrdude
Usage: avrdude [options]
Options:
  -p                 Required. Specify AVR device.
  -C            Specify location of configuration file.
  -c             Specify programmer type.
  -D                         Disable auto erase for flash memory
  -P                   Specify connection port.
  -F                         Override invalid signature check.
  -e                         Perform a chip erase.
  -m                (deprecated) Memory type to operate on.
  -i               (deprecated) Write device. Specify an input file.
  -o               (deprecated) Read device. Specify an output file.
  -f                 (deprecated) Specify the file format.
  -U :r|w|v:[:format]
                             Alternate memory operation specification.
                             Multiple -U options are allowed, each request
                             is performed in the order specified.
  -n                         Do not write anything to the device.
  -V                         Do not verify.
  -t                         Enter terminal mode.
  -E [,] List programmer exit specifications.
  -v                         Verbose output. -v -v for more.
  -q                         Quell progress output.
  -?                         Display this usage.

The four arguments we really need are the part number, the programmer type, the communication port, and the command (-U). For the AVR ISP programmer, the argument for -c is avrisp.

To see the correct magic word to put for partno, run avrdude with just the programmer option:

riptide:~/robot cdwan$ avrdude -c avrisp
avrdude: No AVR part has been specified, use "-p Part"

Valid parts are:
  t26  = ATTINY26        [/usr/local/etc/avrdude.conf:2576]
  m8535 = ATMEGA8535      [/usr/local/etc/avrdude.conf:2461]
  m8515 = ATMEGA8515      [/usr/local/etc/avrdude.conf:2345]
  m8   = ATMEGA8         [/usr/local/etc/avrdude.conf:2228]
  m161 = ATMEGA161       [/usr/local/etc/avrdude.conf:2130]
  m32  = ATMEGA32        [/usr/local/etc/avrdude.conf:2012]
  m169 = ATMEGA169       [/usr/local/etc/avrdude.conf:1890]
  m163 = ATMEGA163       [/usr/local/etc/avrdude.conf:1775]
  m162 = ATMEGA162       [/usr/local/etc/avrdude.conf:1641]
  m16  = ATMEGA16        [/usr/local/etc/avrdude.conf:1537]
  m128 = ATMEGA128       [/usr/local/etc/avrdude.conf:1415]
  m64  = ATMEGA64        [/usr/local/etc/avrdude.conf:1291]
  m103 = ATMEGA103       [/usr/local/etc/avrdude.conf:1197]
  8535 = AT90S8535       [/usr/local/etc/avrdude.conf:1122]
  8515 = AT90S8515       [/usr/local/etc/avrdude.conf:1047]
  4434 = AT90S4434       [/usr/local/etc/avrdude.conf:966]
  4433 = AT90S4433       [/usr/local/etc/avrdude.conf:884]
  2343 = AT90S2343       [/usr/local/etc/avrdude.conf:802]
  2333 = AT90S2333       [/usr/local/etc/avrdude.conf:719]
  2313 = AT90S2313       [/usr/local/etc/avrdude.conf:653]
  4414 = AT90S4414       [/usr/local/etc/avrdude.conf:592]
  1200 = AT90S1200       [/usr/local/etc/avrdude.conf:509]
  t15  = ATtiny15        [/usr/local/etc/avrdude.conf:421]
  t12  = ATtiny12        [/usr/local/etc/avrdude.conf:333]

In my case, the correct value will be "2313." Your milage will vary.

The communications port will be the file in /dev which appears when you plug in the USB to serial adapter. In my case, this is /dev/cu.usbserial0.

Last, but not least, is the command that you would like to do. The -U flag is split into three or four parts which will be seperated by colons:

memory type: This will usually be flash
command: r for read, w for write
file: Put the filename to read the flash image from or to.
format: If you are reading the flash image off the chip, then you will also need. The only one with which I have experience is the "hex dump" format, which is indicated by the letter i. I read that as "intuitive".

So, to upload a program called "LCD.HEX" to my 2313 using communications port /dev/cu.usbserial0 over my avr isp programmer, I would run:

avrdude -c avrisp -p 2313 -P /dev/cu.usbserial0 -U flash:w:LCD.HEX

avrdude: please define PAGEL and BS2 signals in the configuration file for part AT90S2313
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9101
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: please define PAGEL and BS2 signals in the configuration file for part AT90S2313
avrdude: reading input file "LCD.HEX"
avrdude: input file LCD.HEX auto detected as Intel Hex
avrdude: writing flash (1246 bytes):

Writing | ################################################## | 100% 3.60s

avrdude: 1246 bytes of flash written
avrdude: verifying flash memory against LCD.HEX:
avrdude: load data flash data from input file LCD.HEX:
avrdude: input file LCD.HEX auto detected as Intel Hex
avrdude: input file LCD.HEX contains 1246 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.67s

avrdude: verifying ...
avrdude: 1246 bytes of flash verified

avrdude done.  Thank you.

What could be simpler? There were whoops of joy at Alan's house the first time we saw that output.

Compilers

GCC is a suite of open source compilers which can build programs for a wide variety of processors. The folks at have created a set of additions to the gcc package which allow it to build for the AVR chip as well.

The very easiest way to get this package installed is to use Fink. Fink is an open source project in which a wide variety of folks all over the world are porting other open source packages to OS X. You install it using the binary installer available at the Fink website, and (if you're me) use it from the command line. I know nothing of the "Fink Commander" graphical interface.

Once you get fink installed, run:

riptide:~/robot cdwan$ fink list avr
Information about 2895 packages read in 8 seconds.
 i   avr-binutils    2.14-1       GNU binutils for ATMEL AVR micro controllers
 i   avr-gcc         3.3.2-1      GNU GCC for ATMEL AVR micro controllers
 i   avr-libc        1.0.2-1      AVR LIBC for GNU GCC & GNU binutils

The i in the left hand column indicates that the package is installed. If there were no i there, I would run fink install avr-gcc, and a whole lot of text would go by. One useful thing about Fink is that it will automatically install other software if it is required for the package that you have requested.

Once you have the compiler installed, then running avr-gcc should be possible. At this point, we're just as empowered to do development and program our microcontrollers as any of those Linux or Windows people. Actually developing software for these AVR beasts seems, to me, to be a whole different page worth of information. More on that as it happens.

Good luck.