Developing for the Atmel AVR Microcontroller on Linux

You'll enjoy the programming ease and built-in peripherals of the new generation of microcontrollers. Best of all, with these tools you can develop for the popular AVR series using a Linux host.
Memory

Program space is a contiguous block of Flash memory, 16-bits wide that can be erased/rewritten 10,000 times. You can design your circuit to allow firmware upgrades in-circuit, using in-system programming.

All AVRs have some EEPROM, and most have SRAM; both are 8-bits wide. The EEPROM is designed to withstand at least 100,000 erase/write cycles. EEPROM is useful because it can be written from within your embedded program to retain data, even without a power supply, or during programming, such as for production-line calibration.

I/O and Peripherals

All AVRs, from the tiny 8-pin DIPs to the 44-pin Megas, have at least one data port. Data ports allow for input or output of logic-level data. The AVR ports are bidirectional, allowing you to set them for input or output on a pin-by-pin basis.

Many of the AVRs include additional hardware peripherals, such as UARTs for serial communication and calibrated RC oscillators used as internal system clocks. The external pins often serve two or more purposes, and how they are used depends on how you've configured the microcontroller. For instance, Figure 1 shows that certain I/O lines from both ports can be used with the multiplexed A/D converter.

Development Workstation Setup

The set of tools described here isn't the only one available, but it allows you to do basically anything, and the tools function well together. The toolkit is comprised of Binutils, GCC, AVR Libc and our Makefile template to write and build programs for the AVR microcontrollers; GDB and simulavr to debug your software; and avrdude as well as a hardware programmer to transfer your software to the microcontrollers. See the on-line Resources for download URLs for all software.

Fortunately, the recent versions of all these tools include support for the AVR platform, so installation is straightforward. We assume you've chosen to install everything under /usr/local/AVR.

Binutils

Download a fresh copy of the current binutils source by following the link in the Resources. Untar the source, move into the binutils-X.XX directory and run:

$ ./configure --prefix=/usr/local/AVR --target=avr
$ make
# make install

The /usr/local/AVR/bin directory now contains AVR versions of ld, as, ar and the other binutils executables. Add the /usr/local/AVR/bin directory to your PATH now. You can apply the modification system-wide by adding:

PATH="$PATH:/usr/local/AVR/bin"

to the /etc/profile file. Make sure the directory is in your PATH and that the change has taken effect before proceeding.

GCC

After retrieving a recent release of the Gnu Compiler Collection from a mirror, run the following commands from within the unpacked top-level source directory:


$ ./configure --prefix=/usr/local/AVR \
        --target=avr --enable-languages="c,c++" \
        --disable-nls
$ make
# make install

This builds C and C++ compilers for AVR targets and installs avr-gcc and avr-g++ in /usr/local/AVR/bin.

AVR Libc

The AVR Libc package provides a subset of the standard C library for AVR microcontrollers, including math, I/O and string processing utilities. It also takes care of basic AVR startup procedures, such as initializing the interrupt vector table, stack pointer and so forth. To install, get the latest release of the library and run the following from the top-level source directory:

$ unset CC
$ PREFIX=/usr/local/AVR ./doconf
$ ./domake
# ./domake install

Makefile Template

The Psychogenic team has created a standard Makefile template that simplifies AVR project management. You can customize it easily for all your assembly, C and C++ AVR projects. It provides everything for a host of make targets, from compilation and upload to the microcontroller to debugging aids, such as source code intermixed with disassembly, and helpful gdbinit files. A detailed discussion of the template is available, and the Makefile template is available as Listing 1 on the Linux Journal FTP site (see Resources). Store the template with the other AVR tools, moving it to /usr/local/AVR/Makefile.tpl.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

AVR microcontrollers

tom11's picture

AVR microcontrollers is definitely user friendly since the combination of onboard reprogrammable Flash program memory and the in-system programming interface keeps the process of transferring software to the microcontroller simple and cheap.
______
texas criminal defense lawyer

Hi I run Ubuntu 8.10 but got

zainka's picture

Hi

I run Ubuntu 8.10 but got troubles when making bin utilities. Giving message "format not a string literal and no format arguments"

Tried to google but one of the thread said it would be dificult to omit. I guess they are wrong but how to solve it is out of my mind. I understand it have something to do with 8.10 using -Wformat=2 and that this flag may give false positives. Any sugestions???


libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c avr-dis.c -o avr-dis.o
cc1: warnings being treated as errors
avr-dis.c: In function 'avr_operand':
avr-dis.c:112: error: format not a string literal and no format arguments
avr-dis.c:152: error: format not a string literal and no format arguments
avr-dis.c:161: error: format not a string literal and no format arguments
avr-dis.c:172: error: format not a string literal and no format arguments
make[4]: *** [avr-dis.lo] Error 1
make[4]: Leaving directory `/home/zainka/Downloads/binutils-2.19.1/opcodes'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/zainka/Downloads/binutils-2.19.1/opcodes'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/zainka/Downloads/binutils-2.19.1/opcodes'
make[1]: *** [all-opcodes] Error 2
make[1]: Leaving directory `/home/zainka/Downloads/binutils-2.19.1'
make: *** [all] Error 2

AVR libc

FatsDominoTheory's picture

Maybe the configure process for AVR Libc has changed since this was written; "./doconf" is not present in the archive I downloaded.

The INSTALL file tells me to:

./configure --build=`./config.guess` --host=avr

To follow the directory conventions in this article, append that with a "--prefix" option like this:

./configure --build=`./config.guess` \
--host=avr --pref \
--prefix="/usr/local/AVR"

Then make it with:

make
make install

AVR STK500

marcus's picture

I have an AVR STK500 and I am using Ubuntu8.04. I am trying to download the update necessary to run the my AVR STK500 but I can't. Are these packages free?

Problem with optimization in the sample file kr.c from psychogen

mlcy's picture

I had a problem with gcc just skipping the busywait() function until i switched off optimization in the Makefile.
This resulted in all LEDs glowing since they were each turned on with approximately 30 clock cycles in between.

Lovely guide anyway!

Wrinkle (& resolution) using gcc-4.2.2 sources to build avr-gcc

Jason Clark's picture

I ran into a problem with the above instructions, using the gcc-4.2.2 sources. The build died with a long string of errors, starting with:

../../../gcc-4.2.0/libssp/ssp.c: In function '__guard_setup':
../../../gcc-4.2.0/libssp/ssp.c:70: warning: implicit declaration of function 'open'
../../../gcc-4.2.0/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function)

A little research showed this popping up for a few other folks trying to build cross-compilers with gcc 4.x. This message on the gcc-help list suggests that libssp is not likely to be needed when compiling for embedded systems, and suggests the expedient of disabling it during configure. The following worked for me:

$ ./configure --prefix=/usr/local/AVR \
        --target=avr --enable-languages="c,c++" \
        --disable-nls --disable-libssp
$ make
# make install

Simulavr

Anonymous's picture

Hi,

I am using simulavr version 0.1.2.2 in current Debian testing. In the article you stated, regarding output from simulavr, that "You should see a message to that effect, for example, writing 0xff to 0x0038." I don't get that output from simulavr, I only get the following message for each time through line 71:

Breakpoint 2, main () at kr.c:71
71 PORTB = ~currentValue;
(gdb) c
Continuing.
decoder.c:737: MESSAGE: BREAK POINT: PC = 0x00000045: clock = 194

Am I doing something wrong or could it be different versions of simulavr causing the problem?

Re: Simulavr

Anonymous's picture

Ok,

I figured it out. I had to use the following changes to the simulavr command in one terminal:

simulavr --gdbserver --device at90s8515 -X -P simulavr-disp

Before I ran this command in another terminal:

The -X -P simulavr-disp invokes the display program, that shows all the register info for simulavr, and puts it in a normal terminal window instead of an xterm.

Re: Simulavr

Anonymous's picture

The command I ran in the other terminal that I forgot to put above is the same as the one in the article:

avr-gdb -x gdbinit-helloavr

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState