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
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- uisp
- avr-binutils
- avr-gcc
- avr-libc
yum install uisp avr-binutils avr-gcc avr-libcThat 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):Preparations
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.
binutils
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 makeAs root:
make install
gcc
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 makeAs root:
make install
avr-libc
tar zxvf avr-libc-1.4.4.tar.gz cd avr-libc-1.4.4 PREFIX=/usr/local/avr export PREFIX ./configure --build=`./config.guess` --host=avr makeAs root:
make install
uisp
tar zxvf uisp-20050207.tar.gz cd uisp-20050207 ./configure --prefix=/usr/local/avr makeAs 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.Compilation
- Change PRG and OBJ in the Makefile so it refers to your program.
make
- If you have problems with missing include-files try adding
-I/usr/local/avr/include
to the DEFS section of the Makefile. - 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. -
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 ./
, but I would recommend just enabling multilibs instead.
- 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 makefilesloadusb: $(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 thenmake 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.
