Main Menu


Electrons :: Articles :: AVR :: AVR Chip Programming with Linux
AVR Chip Programming with Linux
Description: Describes the actual hardware, software and procedures involved in the process of transfering executable code and data to the microcontroller hardware (i.e. programming).

  • 1. AVR Chip Programming with Linux
AVR Chip Programming with Linux
Copyright (C) 2003,2004, Psychogenic Inc. All Rights Reserved.

In this tutorial we describe the process of transfering executable code and data to the microcontroller hardware.


The Programmer's Programmer

Once we've created an AVR project, compiled, built and debugged it, we are ready to get it working on real hardware.

To do so, we need some way to upload the data--transferring it from the computer to the target microcontroller. That is what the programmer is used for; here, we use "programmer" to mean the combination of hardware and software used to transfer program data to the chip's on board flash program memory.

This document will provide an overview of the programming process and its practical application using Linux (and other Unix-type) development systems.

Burning Bits

Program code and data which are uploaded to the microcontroller's flash program memory, EEPROM, fuse or lock bits must remain intact whether a power supply is available or not so, unlike RAM, the information cannot be stored as charge (which must be maintained and refreshed regularly). Instead, the programmer needs some method of requesting modifications to the microcontroller's "permanent read-only" memory (ROM).

In order to store the information in ROM, actual physical modifications are made to the chip while it is being programmed and there is a limit to the number of times a particular area of memory can be written (normally, at least 1000 times for an AVRs flash program memory and 100,000 times for the EEPROM data segment).

The AVR family microcontrollers offer one or two methods (depending on the specific uC) of reading and writing the flash/eeprom/etc. memory: High Voltage and Low Voltage serial programming.

High Voltage Serial Programming

High Voltage Programming High Voltage Serial Programming is one method of writting to the various microcontroller ROM areas. The high voltage is rather low by most standards (+12V) but it indicates that a voltage that is more than 2 times higher than the target supply voltage must be applied to the /RESET pin.

This method has a few advantages over the low voltage version, including faster programming times and the possibility of re-programming and recovering devices that have been locked (e.g. by setting the /RESET Disable--RSTDISBL--fuse bit). In addition, high voltage programming avoids the need for an external oscillator for the target and certain devices (e.g. the ATtiny11) only support HV programming.

The downside is that separate supplies are required (+12V to enable programming and +5V to supply the target chip) and is difficult or impossible to use in system (the chip must be programmed outside the ciruit).

Low Voltage Serial Programming

Low Voltage Programming A great deal of the AVR family microcontrollers support the Serial Peripheral Interface, a three wire interface which allows low voltage, In-System Programming (ISP). Full ISP details are available in Atmel's AVR910: In-System Programming document.

A major advantage of low voltage serial programming is that you can program the chip in-circuit. With a little foresight, you can include a standard 6 (or 10) pin header in your design:
6 pin ISP header 6 pin ISP header

which will allow you to perform software revisions without removing the uC from the circuit, right there in the field if you've got a portable programmer. In addition, a large number of programmers support the protocol, which is simpler, and you don't need a separate +12V voltage (to apply to /RESET, as with HV programming).

Some disadvantages of this method:

  • Can't recover chips with /RESET disabled (RSTDISBL fuse bit)
  • In-system programming mustn't interfere/damage components attached to the SPI lines (SCK, MOSI and MISO), so you're design must consider the effect of programming if you add an ISP header.

An example implementation of this type of programmer, is our ISP Programmer.

Parallel Programming

A final programming protocol is available on certain of the larger (20 pins or more) chips: parallel programming.

Programmer Hardware

Selecting the appropriate hardware to use to program the uCs is important as it will determine the programmer software you'll need to install, which programming methods (high or low voltage) are available to you and ultimately which microcontrollers you can program.

Atmel STK500

AVR STK500 Dev Kit A number of commercial solutions are available. If you're interested in programming a wide selection of the AVR family and have the budget, we strongly recommend you go with Atmel's STK500 kit. More than a simple programmer, the STK500 is a starter kit that allows you to program flash microcontrollers and easily prototype designs. It includes a number of LEDs and switches, an oscilator, RS-232 interface and other niceties which can easily be connected to your target chip. It is, in our opinion, a great way to start and is very decently priced (around USD80 at the time of this writing).

The kit comes with an AT90S8515 microcontroller so you can get started right away. The programmer we received also include an ATMega16 but I'm not certain this is always the case. The kit does not come with a power supply, so you'll have to use a spare wall-wart of your own. The docs request a 12V DC supply, which is to be connected to the standard 2.1mm power jack, but we've gotten away with using a 9V supply as well.

Hombrew Programmers and the Psychogenic ISP

If you're on a low budget or just like a more hands-on approach, you can build your own programmer. You may choose to go dirt cheap and ultra-simple, for instance by implementing the parallel port programmer described on the avrdude site. A slightly more sophisticated home-brew solution would be to build one of our systems. Choose from serial or parallel port serial ISP programmers based on the AVR910: In-System Programming app note:

AVR910 PPI Prog component placement

Click on the image for the detailed description of the schematics, printed circuit board (PCB) art work and construction hints for both of our ISP Programmer projects.

Other Programmers

Some additional hardware possibilities can be found in the docs for the programmer software, such as the Pony Programmer, pAVR and others, described below.

Programmer Software

Your development system needs to communicate with your selected hardware programmer in order to transfer data to the microcontrollers. To do so, you'll need a software program that knows how to talk to your selected hardware.

If you are using MSWindows and have purchased the STK500 development kit, you will probably have received the AVR Studio software on the bundled CD-ROM. If not, you can retrieve it from the AVR Freaks site and probably directly from Atmel as well.

Linux and Unix users have (as usual!) a number of different options, though we will only mention three.

To use the Pony Programmer, you need some pony specific hardware (including the base programmer and an AVR extension module) and no one here has actually tried it. The advantage is that it runs under Linux and supports a gazillion (or somewhere thereabouts) microcontrollers and EEPROMs.

UISP is GPLed and available through it's project page on savannah. It supports AVR910 devices (including our own design based on the app note), the STK500 dev kit and the pAVR programmer hardware.

AVRDUDE, formally "AVRPROG", is also distributed under the GPL and available through its own savannah project page. Descriptions and schematics for very simple parallel port programmers can be found on their site. AVRDUDE supports a host of different hardware, include PPI (parallel port interface programmers), avr910 appnote serial programmers (like this) and the STK500 dev kit. The complete list of supported devices, including pointers to more schematics and information, may be found in the avrdude info page under the -c PROGRAMMER-ID command line option details.

Should you elect to use the avrdude programmer software, as we have, you will find writing your compiled program to the microcontroller extremely simple if you use our AVR Project Makefile template: all you will need to do is enter

$ make writeflash
to have your program compiled and uploaded to the microcontroller's flash memory.

Programming Process

The specifics of the programming process will of course depend on the hardware/software combination you've selected for your AVR programmer, so you will have to look into relevant docs/man/info pages. One important thing to remember is that the programmable AVR memory is split into distinct blocks (see the datasheet for your part for specifics):

  • flash program memory
  • fuses

The size and location of each of these will vary from device to device.

Program memory

The flash program memory is where your program code is stored and will usually be measured in kilobytes. It will usually need to be completely erased (all bytes in memory set to 0xFF) before being written to.


The EEPROM can be written to using your programmer (e.g. to set production line calibration values) as well as from within the code that will be executed on the microcontroller (to provide long term storage of values). It is meant to be written to more frequently and can sustain a much larger number of erase/write cycles than the flash memory (typically, around 100,000 vs 1000 for flash) but it is much more size constrained (around 64 to 256 bytes).

Fuses and Lock Bits

Fuses are used to configure the device (e.g. selecting the type of oscillator which will drive the uC--crystal, internal RC oscillator, etc.). Some devices have multiple fuses, some only one. Each bit of a fuse has an assigned meaning, described in the datasheets. Certain lock bits may be programmed such that the device is no longer writeable or even readable by the programmer (in which case, only a complete chip erase will allow the uC to be reused).

The "unprogrammed" state for a fuse or lock bit is a logic high, programming a lock or fuse bit will change its level to a logic low. All AVR devices contain two Lock bits, LB1 and LB2 and programming these (remember that that means setting them to 0, in this context) will add a certain amount of protection to your microcontroller:

Memory Lock BitsProtection
111 Unprogrammed: memory read and write enabled
201 Programming disabled: no writes allowed, read back enabled
300 Locked: Programming and read back disabled.

The specific Fuses and fuse bit settings available are microcontroller dependent so you should check the datasheet. Fuse settings are not affected by chip erase, so to erase a programmed fuse, you need to set a logic high.

Certain fuses are only available in parallel programming mode. When you've change fuses, cycle the power to the uC to ensure the changes take effect.

Programmer commands

Programmer software should let you write to each of these memory areas. Here, for instance, is an example command instructing AVRDUDE to write the contents of the diag.hex file to program memory, the contents of eeprom.hex to the EEPROM and the three fuses of an ATmega128 device:

$ avrdude -p m128 -U flash:w:diag.hex \
          -U eeprom:w:eeprom.hex \
          -U efuse:w:0xff:m \
          -U hfuse:w:0x89:m \
          -U lfuse:w:0x2e:m

Our Makefile template automates part of this process, by providing a writeflash target to automatically write the AVR program flash memory.

Additional Notes

  • Program fuse bits before programming lock bits.
  • "Unprogramming" the SPIEN fuse bit (setting the SPI ENable to 1, that isn't a typo and really is 1--see the datasheet), if available, will disable further in system ("low voltage") programming. Only do so if you have a High-Voltage programmer available or are certain you won't want to reprogram the MCU. The same applies to the RSTDISBL (ReSeT DISaBLe) bit.
Level: Article
Additional Article Data
Level: Article

The comments are owned by the poster. We aren't responsible for their content.

Jump to section

All contents are Copyright (C) 2004-2005 Psychogenic Inc -- All rights reserved