Getting started with AVR micro controllers.
From HBRC WIki
The intent of this guide is to help you get started with Atmel AVR family 8-bit microcontrollers.
This article is incomplete! Feel free to help fill it out.
Contents |
Decide whether to use a board or chips.
This article focuses on the best way to access all the power and resources available: using a tool chain and a device programmer/ice.
The easiest way to start working with AVR micro controllers is to use AVR development boards. Boards typically come with a powerful yet very easy to use library and IDE. Many are low cost ($10-$30), "open", and give you access to nearly all the chips capabilities. You don't have to worry about tool chains, programmers, fuse settings, or low level device specifics.
Selecting a tool chain.
What's a tool chain?
The term "tool chain" refers to the collection of programs that process your source code into code that can run on the processor. It refers to the pre-processor, compiler, assembler, linker, and debugger in most systems. In embedded programming, most people include the device programmer and it's host software in the tool chain.
Tool chain choices by platform.
Unix/Linux
Most *nix-based AVR development uses avr-gcc and its related tools for the compiler/assembler/linker tool chain. avr-gcc is the regular gcc front end, built to cross-compile to the AVR target. Cross-compile means that it runs on your workstation, but generates code for the microcontroller. With the gcc tool chain, you can write in C or assembler, and with certain restrictions also in C++ (more on avr C++ below).
Since the result of the gnu linker is a .elf file that can not be directly used by the AVR, it first has to be converted to a .hex file, which is an image ready to write to the AVR's flash, and then it needs to be written. The avr-objcopy tool converts the .elf to .hex and .ee.hex files for program flash and data eeprom, respectively.
The avrdude program runs on the host, reads the .hex files, and communicates with your chosen device programmer. Avrdude supports a wide variety of device programmers, refer to avrdude documentation for more information.
Good old gdb is used for debugging. The AVaRICE program can communicate with a JTAG ICE or a Dragon, and presents the standard remote debugging interface to gdb. In the workstation world, remote debugging is when the debugger and source code live on one workstation, and the program being debugged is executing on another workstation, with debugger commands and responses going across the network using a client/server protocol. AVaRICE simply implements the same interface, using a loop back port for the network interface, so debugging using a JTAG ICE or a Dragon is very similar to remote debugging with gdb.
See Using avr-gdb and AVaRICE Together.
What about C++ on the AVR? Umm... well, first off, what exactly do you expect new and dispose to do for you on a processor with 2K of SRAM? C++ is available, but there are obvious resource limitations. You probably want to stick to statically allocated objects. You will want to disassemble the resulting binary and look for unexpected code bloat -- some C++ constructs can be unexpectedly resource intensive. The AVR C++ run time library is not complete. You may find that you get some linker errors because the library does not include some of the standard routines, and you will need to provide your own stub. A notorious example is the error trap routines that are called if a polymorphic function call gets dispatched to a pure virtual function (something that should never happen). You will most likely want to stub that out. Remember that there is no OS underneath the run time, so some things that seem obvious in a workstation environment are not quite so obvious to implement in a micro-controller, so you are on your own for certain library functions.
OS X
For the most part like Unix. (Somebody please write something more intelligent here.)
Windows
Atmel provides AVR Studio for free, as in free beer, not free as in free speech. Out of the box, AVR Studio supports assembly language development and supports and documents all the Atmel development tools. AVR Studio supports plug-ins, and various compiler vendors sell C compilers that run in the AVR Studio environment. Many people use WinAVR, which is a port of the free (as in free speech) gcc tool chain that runs as an AVR studio plug-in. The avr-gcc developers work diligently to keep WinAVR in sync with the *nix version of avr-gcc so code portability between development environments is excellent.
AVR Studio is the simplest way to update the firmware in the device programmers, also.
See: AVR Studio WinAVR, ImageCraft, Code Vision
Programmers and in-circuit emulators.
Programming Methods
First, it's important to understand the different ways AVR's can be programmed. Not all devices support all methods, check the data sheet for your device.
In-circuit Serial Programming, or ISP is supported by most, if not all, AVR devices. Usually, but not always, it uses the SPI port. The protocol is very simple, and many inexpensive home-brew AVR ISP programmer designs exists. The Atmel AVRISP MK II is under $40 and is supported on Windows, OS X, and Linux. You will probably use ISP at some point and probably as your first programming method when you get started since the programmers are cheap and ubiquitous. The one gotcha to watch out for is that there are two different ISP connector standards, one uses a 6 pin header, and the other uses a 10 pin header. And again, don't assume that ISP uses the SPI port, because on a few devices it doesn't, and this trips up enough people that "Why can't I program my <device>?" is a FAQ.
The JTAG port can be used to program those devices that support it. Not all do, the smaller devices that don't have the I/O pin budget omit JTAG. The advantage to JTAG programming is that the JTAG port also supports debugging. The disadvantage is that the programmers are generally much more expensive (Dragon excepted.)
High Voltage Programming refers to the mode where the device is in a socket on a programmer. All devices support HVP, but in this day of surface mount components it isn't always convenient. The one advantage to HVP is that if you manage to goof up your fuse settings and disable both JTAG and ISP, you can rescue the chip with HVP.
Many AVR's support self-programming. This allows you to write a boot loader that can download code into the AVR's program flash. Standard protocols exist, or you can get as creative as you like. You can use any interface that you like. Some devices have fuse settings to write protect the bootloader area so that it can't accidentally scribble over itself.
Debugging Methods
The larger AVR's support debugging through the JTAG interface. The chip contains breakpoint registers and a debug interface to examine and change memory. With a suitable ICE and software, this allows source level debugging. The tool chain for *nix systsm is: the avr-gcc compiler->gdb->avarice->JTAGICE MK II->your board.
The newer small AVR's support DebugWire, which is a single wire debug interface that allows similar capability by overloading the reset line with a bi-directional serial protocol. These chips do not include breakpoint registers, so breakpoints are emulated by programming a 'break' instruction into flash which is later removed as you step through the instruction.
Programmers
These units support programming only.
AVRISP MK II: Atmel's ISP programmer, USB interface, supported on all platforms.
Parallel port: It is simple to wire up an ISP programmer that uses a standard parallel port. Here's one but you can probably google up a bucket full of implementations. This is less popular now that units like the AVRISP MK II are so cheap.
STK500: Atmel's starter kit board. Serial interface, and can do high voltage programming. This is a flexible starter kit aimed at professionals with many other features beyond programming.
Buttload: Software to convert an Atmel Butterfly development board into a programmer.
AVRISP clones: Many people have built ISP programmers that are essentially AVRISP-alike devices that support the openly documented STK500 protocol. Google will turn them up.
Programmer/ICE's
These units support programming and in-circuit debug:
JTAG ICE MK II: Atmel's JTAG programmer/ICE, USB interface, supported on all platforms.
Dragon: Inexpensive ICE from Atmel, some assembly required. Supported on all platforms. Supports AVR devices up to 32K only. Linux users should check out the HowTo: AVR-Dragon_Under_Linux.
Selecting a device.
Oh my, there are a zillion AVR's in many configurations. How to pick the one you want?
You might consider starting with one of the many available AVR development boards.
If you want to select a device for a circuit of your own, first you will want to get familiar with the device comparison tool at AVR Freaks. That is much faster than trying to dig out from under a blizzard of data sheets.
But before you spend a lot of time driving the device comparison tool, here are a few key tips:
AVR's come in "families" of similar devices. The devices in a family will share a pin-out and most or all peripherals, differing mainly in size of the three main memories: program flash, SRAM, and data eeprom. An example being the ATMega48/ATMega88/ATMega168/ATMega328 family. Each processor roughly doubles in memory capacity but is the same otherwise.
In general the "ATTiny" processors do not have sufficient SRAM to support C, they are considered assembler-only processors. They are small and inexpensive and well suited to simple, dedicated tasks.
The "ATMega" parts are the mainstream parts that are most suitable to hobby robotics applications, and can be programmed in C.
The newly announced "XMega" parts have many more peripherals, most of the peripherals have been redesigned, and they include a sophisticated DMA complex. XMega parts are in limited sampling as I write this.
"Ya, ya, ya, I don't want to think -- just tell me a part to use." OK, here's two to look at for your hobby robot: ATMega168, ATmega324. If neither of those suit your project, then go to the 'Freaks device comparison tool and dig.
Setting Up Your Tool Chain
Linux
Building the software is quite straight forward. As of this writing, the AVR Freaks forum has a sticky thread to the "Bingo scripts" (named for user Bingo600) which apply the patches and build the avr tools for you. This is the standard recipe for Linux. (Note: You need to be logged into AVR Freaks in order to see the attachments that contain the actual scripts. Forum feature, so they say.)
Most users configure with prefix set to /usr/local/avr or similar, so that the tools are not mixed in with all the other /usr/local stuff. That makes it easy to update by simply blowing away /usr/local/avr and building new, or building two side-by-side tool chains of different revisions or patch levels.
Note to Gentoo users: Don't use crossdev. crossdev is the Gentoo developers' idea of how to make their own lives better, not how to make your life better. Use the Bingo scripts so that you have the canonical set of patches and put the tools in /usr/local/avr.
After the compiler, related tools, and avrlibc are installed, you are ready to roll. Usually the next problem that you run into is that your USB based programmer such as the AVRISP MKII will not talk. You might see something like:
avrdude: usb_open(): cannot read serial number "error sending control message: Operation not permitted" avrdude: usb_open(): cannot read product name "error sending control message: Operation not permitted" avrdude: usbdev_open(): error setting configuration 1: could not set config 1: Operation not permitted avrdude: usbdev_open(): did not find any USB device "usb"
Try again as root. If you can program as root, but not as a normal user, then it is a permissions issue. In most cases, this is because the udev system does not assign permissions appropriately when the programmer is plugged in. The solution is to add some udev rules. On my Gentoo system, I created the file /usr/udev/rules.d/51-atmel-programmer.rules with this content:
# JTAGICE mkII
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2103", GROUP="users", MODE="0666"
# AVRISP mkII
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", GROUP="users", MODE="0666"
# Dragon
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2107", GROUP="users", MODE="0666"
This gives world read/write so anyone can use the programmers. You might consider mode=0660 so that only members of the group "users" can program, or you could create an "avruser" group if you are concerned about security. Note that you need to force udev to reload the rule set for this to take effect.
OS X
You can build and install the tools from source, as you would in Linux, but there are some good pre-built packages that make it even easier. AVR MacPack is highly recommended. OSX-AVR is an older package that has been quite popular, though its author now endorses AVR MacPack.
Windows
Setting up AVR Studio and WinAVR is pretty much download-and-click.
Getting help.
Did you read the excellent documentation at the avr-libc web site, and work through the excellent examples?
HBRC members can start with the HBRC mailing list, that will flush out AVR users.
The members at the AVR Freaks forum are very helpful and friendly, as long as you form clueful questions and have made an attempt to read the data sheet. (Skool kiddies trying to get grown-ups to do their homework for them will be savagely ridiculed.) Really, AVR Freaks is a great forum.
Mailing lists:
- avrdude-dev
- avr-libc-dev
- avr-gcc-list
Outside references.
AVRFreaks forum is full of helpful folks.
The avr-libc home page is the first stop for anyone using the gnu tool chain for AVR's. In addition to documentation on avr-libc, you'll find links to the other pieces of the avr tool chain and some very good example projects to get you started.
