AVR and ATmega128 introduction

Micro controllers
Vector graphics

This page contains some introductory notes on how to get started working with the ATmega128 development board and AVR under Linux, and it started out as introductory notes for students (Intelligent Systems Design and Art&Technology programs) at the IT-university of Göteborg.

Development board

atmega128 development board
This development board is powered by 7 - 12 V DC (9V batteries will work just fine for simple applications). If you get the polarity wrong on this development board you won't damage the microcontroller, it just won't work. Other development boards may be more sensitive to the polarity, so if you use another development board please read the documentation before plugging it in!

You will also need a programmer cable of some kind. The Makefiles in the code examples further down assumes that a stk200 programmer connected to the parallel port is used. Parallel ports are becoming increasingly unusual so that is not really the most practical set up any more, but there are also some notes on how to use a stk500 programmer connected with USB instead further down on this page.

AVR installation

Nowadays it is quite easy to install the avr tool chain, but I've also kept the old instructions that builds the tool chain from sources instead.

Installation with yum

You need to install As root, issue
yum install uisp avr-binutils avr-gcc avr-libc
That was all that was needed on the Fedora system I tested it on, but I'm sure it will work similarly on other distros too. Avrdude may also be useful. Install that with
yum install avrdude

Installation with apt-get

On Ubuntu:
sudo apt-get install avr-libc avrdude binutils-avr gcc-avr uisp

Building from sources

Building the tool chain from sources instead is a little bit trickier, but still not so bad. You need to install Download the newest versions and follow the instructions below (the instructions are based on Guido Socher's AVR article):
mkdir /usr/local/avr
mkdir /usr/local/avr/bin
export PATH=/usr/local/avr/bin:${PATH}
Also add /usr/local/avr/bin to the PATH in your .bash_profile.
tar zxvf binutils-2.16.tar.gz
cd binutils-2.16/
mkdir obj-avr
cd obj-avr
../configure --target=avr --prefix=/usr/local/avr --disable-nls
As root:
make install
tar zxvf gcc-core-3.4.6.tar.gz
cd gcc-3.4.6
mkdir obj-avr
cd obj-avr
../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-language=c --enable-multilibs
As root:
make install
tar zxvf avr-libc-1.4.4.tar.gz
cd avr-libc-1.4.4
export PREFIX
./configure --build=`./config.guess` --host=avr
As root:
make install
tar zxvf uisp-20050207.tar.gz
cd uisp-20050207
./configure --prefix=/usr/local/avr
As root:
make install

Test program

A small test program that blinks an LED. The tiny circuit is in the top comment of the source code.


  1. Change PRG and OBJ in the Makefile so it refers to your program.
  2. make
  3. If you have problems with missing include-files try adding
    to the DEFS section of the Makefile.
  4. If you have problems with missing libraries try adding
    -L/usr/local/avr/lib -L/usr/local/avr/lib/avr5
    to the LIBS section of the Makefile.
  5. This has only turned up when building the tool chain from sources, but the compiler may have problems finding crtm128.o. If this happens the configuration step of building gcc has been done with multilibs disabled (most likely in an attempt to minimize the size of the compiler). Rebuild gcc and make sure the configure command line has --enable-multilibs included. Thank you, Peter Garner, for letting me know the cause of this problem and its solution.

    Without multilibs enabled it is still possible help the compiler to find crtm128.o by creating a symlink, i.e.
    ln -s /usr/local/avr/lib/avr5/crtm128.o ./
  6. , but I would recommend just enabling multilibs instead.
  7. Transfering the program to the microcontroller:
    make load
    (You need write permission to the parallell port in order for this to work.)

    Program transfer over USB
    The makefile in this example and the others below it all assume that a stk200 programmer attached to the parallel port is used. Since parallel ports are becoming increasingly uncommon this is a bit impractical. Instead it is preferable to use a stk500 programmer attached to a USB port. I have tested an olimex stk500 programmer and in Fedora it turned up as /dev/ttyACM0 (this may be different in different distros). Assuming that the programmer device turns up as /dev/ttyACM0 the following can be added to the makefiles
    loadusb: $(PRG).hex
        avrdude -c stk500v2 -P /dev/ttyACM0 -e -p $(MCU_TARGET)
        avrdude -c stk500v2 -P /dev/ttyACM0 -U flash:w:$(PRG).hex -p $(MCU_TARGET)
    and then
    make loadusb
    can be used to transfers the program to the microcontroller over USB instead. Just like for the parallel port, you will need write permission to the device in order for this to work. In this case avrdude is used to make the transfer. Uisp can also be used - I just have not personally verified exactly which command line arguments need to be used.

Serial communication back to the computer

Serial communication back to the computer is really helpful when debugging programs. For this you can use minicom. Run minicom (you probably need to be root) and press Ctrl+A Z to display the available commands. Press o for Options and choose 'Serial port setup' and make sure you've got the correct port selected (mine started as /dev/ttyS1 when it should have been /dev/ttyS0). Also make sure that the baud rate is set to 38400 8N1. Once the correct port and baud rate has been chosen use 'Save setup as dfl' and minicom will start up with the correct settings next time. Quit minicom and restart it to activate the new settings. Test program (sends "Hello World!" back to the computer using the serial cable):
If everything works minicom should receive the "Hello World!" message when the program is run.

Timer and speaker

Beep - Uses a timer to send a square wave of variable frequency to a speaker.