Embedded Systems/Atmel AVR

The Atmel AVR^TM is a family of 8-bit RISC microcontrollers produced by Atmel. The AVR architecture was conceived by two students at the Norwegian Institute of Technology (NTH) and further refined and developed at Atmel Norway, the Atmel daughter company founded by the two chip architects.

Memory

The memory of the Atmel AVR processors is a Modified Harvard architecture, in which the program and data memory are on separate buses to allow faster access and increased capacity. The AVR uses internal non-volatile memory for program storage, and so does not need to initialize itself from external memory.

The four types of memories in a Atmel AVR are:

Data memory: registers, I/O registers, and SRAM
Program flash
EEPROM
Fuse bits

Each kind of memory is completely separated from each other; address 0 in data memory is distinct from address 0 in program flash and address 0 in EEPROM.

Program Memory

All AVR microcontrollers have some amount of 16 bit wide flash memory for program storage, from 1KB up to 128KB (or, 512-64K typical program words). The program memory holds the executable program opcodes and static data tables. Program memory is linearly addressed, and so no mechanism like page banking or segment registers is needed to call a function, regardless of its location in program memory.

AVR's cannot use external program memory; the flash memory on the chip is the only program memory available to the AVR core.

The flash program memory can be reprogrammed using a programming tool, the most popular being those that program the chip in situ and are called in-system programmers (ISP). Atmel AVR's can also be reprogrammed with a high-voltage parallel or serial programmer, and via JTAG on certain chips. The flash memory in an AVR can be re-programmed at least 10 000 times.

Many of the newer AVR's (MegaAVR series) have the capability to self-program the flash memory. This functionality is used mainly by bootloaders.

Data Memory

Data Memory includes the registers, the I/O registers, and internal SRAM.

The AVR has thirty-two general purpose eight-bit registers (R0 to R31), six of which can be used in pairs as sixteen-bit pointers (X, Y, and Z).

All AVR microcontrollers have some amount of RAM, from 32 bytes up to several KB. This memory is byte addressable. The register file (both general and special purpose) is mapped into the first addresses and thus accessible also as RAM. Some of the tiniest AVR microcontrollers have only the register file as their RAM.

The data address space consists of the register file, I/O registers, and SRAM. The working registers are mapped in as the first thirty-two memory spaces (0000₁₆-001F₁₆) followed by the reserved space for up to 64 I/O registers (0020₁₆-005F₁₆). The actual usable SRAM starts after both these sections (address 0060₁₆). (Note that the I/O register space may be larger on some more extensive devices, in which case memory mapped I/O registers will occupy a portion of the SRAM.) Even though there are separate addressing schemes and optimized opcodes for register file and I/O register access, all can still be addressed and manipulated as if they were in SRAM.

The I/O registers (and the program counter) are reset to their default starting values on when a reset occurs. The registers and the rest of SRAM have initial random values, so typically one of the first things a program does is clear them to all zeros or load them with some other initial value.

The registers, I/O registers, and SRAM never wear out, no matter how many times they are written.

External Data Memory

Some of the higher pin-count AVR microcontrollers allow for external expansion of the data space, addressable up to 64KB. When enabled, external SRAM is overlaid by internal SRAM; an access to address 0000₁₆ in the data space will always resolve to on-chip memory. Depending on the amount of on-chip SRAM present in the particular AVR, anywhere from 512 bytes to several KB of external RAM will not be accessible. This usually does not cause a problem.

The support circuitry required is described in the datasheet for any device that supports external data memory, such as the Mega 162, in the "External Memory Interface" section. The support circuitry is minimal, consisting of a '573 or similar latch, and potentially some chip select logic. The SRAM chip select may be tied to a logic level that permanently enables the chip, or it may be driven by a pin from the AVR. For an SRAM of 32KB or less, one option is to use a higher-order address line to drive the chip select line to the SRAM.

EEPROM Storage

Almost all AVR microcontrollers have EEPROM memory for non-volatile data storage. Only the Tiny11 and Tiny28 have no EEPROM.

EEPROM memory is not directly mapped in either the program or data space, but is instead accessed indirectly as a peripheral, using I/O registers. Many compilers available for the AVR hide some or all of the details of accessing EEPROM. IAR's C compiler for the AVR recognizes the compiler-specific keyword __eeprom on a variable declaration. Thereafter, a person writes code to read and write that variable with the same standard C syntax as normal variables (in RAM), but the compiler generates code to access the EEPROM instead of regular data memory.

Atmel's datasheets indicate that the EEPROM can be re-written a minimum of 100,000 times. An application must implement a wear-leveling scheme if it writes to the EEPROM so frequently that it will reach the write limit before it reaches the expected lifetime of the device. AVR's ship from the factory with the EEPROM erased, i.e. the value in each byte of EEPROM is 0xff.

Many of the AVR's have errata about writing to EEPROM address 0x00 under certain power conditions (usually during brownout), and so Atmel recommends that programs not use that address in the EEPROM.

Fuse Settings

A Fuse is an EEPROM bit that controls low level features and pin assignments. Fuses are not accessible by the program; they can only be changed by a chip programmer. Fuses control features which must be set before the chip can come out of reset and begin executing code.

The most frequently modified fuses include:

Oscillator/crystal characteristics, including drive strength and start-up time.
JTAG pins used for JTAG or GPIO
RESET pin used as a reset input, debugWire, or GPIO
Brown Out Detect (BOD) enable and BOD voltage trigger points

There is a also a fuse to enable serial in-system programming, which is set by default. This fuse can be disabled over serial ISP, but for obvious reasons cannot be re-enabled over that same interface. If it is set incorrectly, recovery of the chip would require a high-voltage programmer, such as the STK-500, AVR Dragon, or third-party programmer. A developer is therefore cautioned to be careful when manipulating fuses.

Reset

The AVR's RESET pin is an active-low input that forces a reset of the processor and its integrated peripherals. The line can be driven by an external power-on reset generator, a voltage supervisor (which asserts RESET when the power supply voltage drops below a predefined threshold), or another component in a larger system. For example, if the AVR is managing a few sensors and servos as part of a large integrated system, another controller might observe some condition that justifies resetting the AVR; it could do so by asserting the AVR's RESET line.

AVR's also include a watchdog timer, which can reset the processor when it times out. The watchdog timer must be reset periodically to prevent it from timing out. Failure to reset the watchdog timer is usually an indication that the program code has failed (locked up, entered an infinite loop, or otherwise gone astray), and the processor should be reset.

The RESET pin is used for in-system serial programming, as a GPIO, or for debugWIRE^TM low pin count debugging, depending on the chip and the programming of the fuse bits. If the reset functionality of that pin is disabled, it cannot be recovered by in-system serial programming, and another method such as high-voltage programming must be used.

Interrupts

AVR's support multiple interrupt sources, both internal and external. An interrupt could be from an internal peripheral reaching a certain state (i.e. character received on UART), or from an external event like a certain level on a pin. Each interrupt source causes a jump to a specific location in memory. That location is expected to contain either a RETI (Return from Interrupt) instruction to essentially ignore the interrupt, or a jump to the actual interrupt handler.

Most AVR's have at least one dedicated external interrupt pin (INT0). Older AVR's can trigger an interrupt on a high or low level, or on a falling edge. Newer AVR's add more options, such as triggering on the rising edge or either edge. Additionally, many of the newer AVR's implement pin-change interrupts for all pins in groups of eight, eliminating the need for polling the pins. The pin-change interrupt handler must examine the state of the pins that are associated with that interrupt vector, and determine what action to take.

Due to button bounce issues, it is considered poor design to connect a push button or other user input directly to an interrupt pin; some debouncing or other signal conditioning must be interposed so that the signal from the button does not violate the setup and hold times required on the interrupt pins.

General Purpose I/O Ports

General Purpose I/O, or GPIO, pins are the digital I/O for the AVR family. These pins are true push-pull outputs. The AVR can drive a high or low level, or configure the pin as an input with or without a pull-up. GPIO's are grouped into "ports" of up to 8 pins, though some AVR's do not have enough pins to provide all 8 pins in a particular port, e.g. the Mega48/88/168 does not have a PortC7 pin. Control registers are provided for setting the data direction, output value (or pull-up enabled), and for reading the value on the pin itself. An individual pin can be accessed using bitwise manipulation instructions.

Each port has 3 control registers associated with it, DDRx, PORTx, and PINx. Each bit in those registers controls one GPIO pin, i.e. bit 0 in DDRA controls the data direction for PortA0 (often abbreviated PA0), and bit 0 in PORTA will control the data (or pullup) for PA0.

The DDR (Data Direction Register) controls whether the pin is an input or an output. When the pin is configured as an output, the corresponding bit in the PORT register will control the drive level to the pin, high or low. When the pin is configured as an input, the bit in the PORT register controls whether a pull-up is enabled or disabled on that pin. The PIN (Port Input) register was read-only on earlier AVR's, and was used to read the value on the port pin, regardless of the data direction. Newer AVR's allow a write to the PIN register to toggle the corresponding PORT bit, which saves a few processor cycles when bit-banging an interface.

Timer/Counters

The timers and counters (TC) all are capable of up-counting. All timers are equipped with a programmable prescaler, allowing to clock the timer with selected frequencies derived from the processor clock. By selecting an external port bit pin as source, they are capable of counting external events. TCs can be stopped and restarted at any time by setting the clock source multiplexer to zero. Timers/Counters can all be used both in polling mode and in interrupt mode. The content of the timers/counters can be read and modified at any time. Timers/Counters of the 16-Bit type additionally provide the opportunity of comparing their content with one or two programmed values and automatically setting flags, if the TC content matches these values. These flags can be enabled to cause interrupts. Some timers/counters can be programmed to automatically produce a pulse-width-modulated signal (PWM), with the pulse-width determined by setting comparison values. The resulting PWM signal can be echoed externally on a certain port bit.

Timer 0

All AVRs have at least an 8-bit timer. The internal structure of this TC is shown in the picture.

File:Tc0.png

TC0 graph

The clock source for TC0 is controlled by three bits in TCCR0: CS02, CS01 and CS00. These connect TC0 either to nothing (000), to the processor clock (001) or to the divided processor clock. The last two combinations (111, 110) can be used to count events on the port pin T0, either on the rising or falling edge.
If the clock source is enabled (CS02:CS00 <> 000), TC0 counts up. The current result of the count is accessible in the 8-bit-port TCNT0.

If TCNT0 overflows from 255 to 0, it restarts automatically and the overflow interrupt bit TOV0 in the flag register at port TIFR is set. If enabled in the timer interrupt mask register TIMSK, and if the CPU status register has the I-bit set, this results in a TC overflow interrupt. TOV0 is automatically cleared during the jump to the respective interrupt service routine. If interrupts are disabled, the flag can be cleared by writing a logical 1 to it.
The overflow interrupt can be used to add additional timer bytes in registers. In that way the counter length can be expanded from 8 bits to a practically unlimited length. An example: If the processor clock is 8 Mcs/s, the prescaler can divide this by 1024, causing an overflow interrupt every 128 microseconds. If the interrupt service routine increases a register, this register overflows every 256 * 128 microseconds = 32.768 milliseconds. If the interrupt service routine then increases a second register, this overflows after 256 * 32.768 milliseconds = 8.3886 seconds. And so on.

Some of the 8-bit-counters provide the opportunity to continuously compare the content of TCNT0 with the content of another port, OCR0. If the content of these two ports matches, the flag OCF0 in the flag register TIFR is set one. If so enabled in the mask register TIMSK by having the OCIE0 flag set, and if the I-bit in the status register is set, this compare match causes an interrupt and a jump to the respective interrupt service routine. This jump automatically clears the OCF0 flag. If interrupts are disabled, the flag can be cleared by writing a logical 1 to it.

The compare match can be echoed on an output pin called OC0. Reaching the compare match value, this pin is either set, cleared or is toggled. By this feature pulses with an exactly defined and selectable pulse width can be created.

Some of the 8-bit- pull-up timers in ATmega and ATtiny types can make use of the compare register in another way: on reaching the compare match value, the timer is cleared. This mode is called CTC, and can be selected by setting the respective mode bits in the timer control registers. This mode is used when the timer length shall be shorter than 256, e.g. by dividing the input or the (pre-divided) clock source by 100 or any other number between 1 and 255. In CTC mode, the compare match interrupt can be used to detect the restart of the timer.

Timer 1

16-bit timer + PWM

Timer 2

8---bit timer + PWM

Dead Time Generator

The Dead Time Generator is a new feature in the AVR'05 lineup. PWM outputs are available as positive (OC1A) and complementary (OC1A) signals in newer models. DTG places a pause between the positive signal's drop and the "complement's" rise. Can perverse settings create an overlap at the other end?

Serial Communication

AVR microcontrollers are in general capable of supporting a plethora of serial communication protocols and serial bus standards. The exact types of serial communication support varies between the different members of the AVR microcontroller family.

On top of support in hardware there is also often the option to realise a particular serial communication mechanism entirely in software. Typically this is used in case a particular AVR controller does not support some serial communication mechanism in hardware, the particular hardware is already in use (e.g. when two RS232 interfaces are needed, but only one is supported in hardware), or the chip's hardware can't be used, because it shares pins with other chip functions, and such a function is already in used for the particular hardware. The later often happens with the low-pincount AVRs in DIP packages.

Finally, there is also the possibility to use additional logic to realise a serial communication function. For example, most AVRs don't support the USB bus (some later ones do so, however). When using an AVR which doesn't support USB directly, a circuit designer can add USB functionality with a fixed-function chip such as the FTDI232 USB to RS232 converter chip, or a general-purpose USB interface such as the PDIUSB11. Adding additional electronics is in fact necessary for some supported communication protocols, e.g. standard-compliant RS232 communication requires adding voltage level converters like the MAX232.

The number of serial communication possibilities supported by a particular AVR can be confusing at times, in particular if the pins are shared with other chip functions. An intensive study of the particular AVR's datasheet it highly recommended. The serial communication features most commonly to be found on AVRs are discussed in the following.

Universal Synchronous Asynchronous Receiver Transmitter (USART)

Recent AVRs typically come with a Universal Synchronous Asynchronous Receiver Transmitter (USART) built-in. A USART is a programmable piece of hardware which is capable of generating and decoding various serial communication protocols. The words in the name stand for:

Universal: Can be used in a lot of different serial communication scenarios
Synchronous: Can be used for synchronous serial communication (sender and receiver are synchronised by a particular clock signal)
Asynchronous: Can be used for asynchronous serial communication (sender and receiver are not explicitly synchronised via a clock signal, but synchronise on the data signal).
Receiver: The hardware in the AVR can receive serial data
Transmitter: The hardware can generate serial data

Earlier AVR's had a UART (note the absence of the "S"). This is basically the same type of hardware, only that a UART can't handle synchronous serial communication.

USARTs or UARTs work with logic voltage levels while e.g. the RS232 protocol requires much different voltage levels than the 5V or 3.3V supplies found on AVR circuits. The conversion from and to such voltage levels is performed by an additional chip which is commonly called a line driver or line interface.

With the right line interface an AVR's USART can, for example, be used to do RS-232, RS-485, MIDI, or CANbus communication.

RS-232 Signalling

The RS-232 specification calls for a negative voltage to represent a "1" bit, and a positive voltage to represent a "0" bit. The spec allows for levels from +3 to +15V, and -3 to -15V, but +/-12V is commonly seen. The AVR does not have the ability to drive a negative output voltage on any GPIO pin, and so a level converter, such as the MAX232, is used to talk to PCs and strict RS-232 devices. Many applications can "cheat" by using a voltage divider input and straight output, but this does not work properly in all situations, and is a poor choice for anything but a "one-off" design.

See Serial Programming:RS-232 Connections for more detail on RS-232 wiring.

RS-232 has a relatively short maximum cable length. For longer cabling distances, consider using RS-485 signaling on your USART.

Two Wire Interface

TWI is a variant of Phillips' I²C bus interface. I²C consists of two wires, known as SDA (serial data) and SCL (serial clock), which use open-drain drivers and therefore require pull-ups to a logic-1 state. I²C uses a common ground, so all devices on the bus should be at the same ground potential to avoid ground loops. TWI uses 7 bit addressing, which allows for multiple devices to connect to the bus.

Many TWI devices have at least the top four bits of the address hard-coded, and the remaining bits configurable by some means such as connecting dedicated address pins to power or ground; this often allows for only 2-8 model X devices on the bus. The AVR's TWI hardware can act as Master or Slave, and can meet the 400Kbit/s spec.

Serial Peripheral Interface (SPI)

SPI, the Serial Peripheral Interface Bus, is a master-slave synchronous serial protocol. This means that there is a clock line which determines where the pulses are to be sampled, and that one of the parties is always in charge of initiating communication. It uses at least three lines, which are called:

MISO: Master In Slave Out.
MOSI: Master Out Slave In.
SCK: Serial Clock.

Conceptually, SPI is a bidirectional shift register; as bits are shifted out on either MISO or MOSI, bits are shifted in on the other line. The master always controls the clock.

An SPI slave has a Slave Select (SS) signal, which signals to the slave that it should respond to messages from the master. SS is almost always active-low. If there is only one master and one slave, the slave's SS line could be tied low, and the master would not need to drive it. If there are two or more slaves, then the master must use a separate slave select signal to each slave. The downside of this approach is that the master can only address as many slaves as it has extra outputs (without the use of a separate decoder).

Hardware Implementation The larger AVR microcontrollers have built-in SPI transceivers (from the ATMEGA8 upwards). The serial clock is derived from the processor clock, with several divisors available. The data length is always 8 bits. The clock polarity and phase may be configured, leading to four possible combinations of when the data is clocked in and out of the chip. This interface is very popular, and is widely available on a variety of other processors and peripherals.

The pins used for the SPI bus are also used as a way of programming the chip via ISP (In System Programming).

Universal Serial Interface Some AVR's, particularly in the Tiny family, provide a Universal Serial Interface (USI) instead of an SPI. The USI is capable of operating as an SPI, but also as an I2C controller, and with a little extra effort, a USART. The bit length of the transfer is configurable, as is the clock driver. The clock can be driven by software, by the timer 0 overflow, or by an external source.

Software Implementation SPI can be implemented using bit-banging of the I/O lines. An efficient implementation of a slave can be done by connecting SCLK to an external interrupt source.

The datasheet for a particular AVR provides a block diagram of the SPI or USI controller on that chip.

Protocol Issues

SPI, RS-232, I²C, and other serial interfaces only define the method by which bits and bytes are transmitted; they correspond to layer 1 in the OSI model, the physical layer. The bytes could be anything: temperature readings (in Centigrade or Fahrenheit?), readings from a pressure sensor, control signals to turn off a pump, or the bytes of a JPEG image.

If the bytes are temperature readings, what happens after you connect 2 temperature sensors to your microcontroller? If you transmit each temperature as one byte, how does the PC know which temperature corresponds with which sensor ?

Also, what happens if the cable gets unplugged momentarily, and then you plug it back in? Can the software at each end recover?

This leads to the idea of serial protocols, which would require an entire book to discuss, please see Serial Programming.

Analog Interfaces

Analog to Digital

Analog to digital conversion uses digital number to represent the proportion of the analog signal sampled. For example, by applying a 3V to the input of an ADC with a full-scale range of 5 V, will results a digital output of 60% of the full range of the digital output. The digital number can be represented in 8 or 10 bits by the ADC. An 8 bit converter will provide output from 0 to $2^{8} - 1$ , or 255. 10 bits will provide output from 0 to $2^{10} - 1 = 1023$ .

10 bit sample: $\frac{3 V}{5 V} = 0.6 \times 1023 = 614$ in ADCH:ADCL or

8 bit sample: $\frac{3 V}{5 V} = 0.6 \times 255 = 153$ in ADCL

Many AVRs include an ADC, specifically a successive-approximation ADC. The ADC reference voltage (5V in the example above) can be an external voltage, an internal fixed 1.1V reference.

AVRs with an ADC have several analog inputs which are connected to the ADC via an analog multiplexer. Only one analog input can be converted at any given time. The ADC controller provides a method for sequentially converting the inputs, so that an AVR can easily cycle through multiple sources thousands of times a second. AVRs can run ADC conversions continuously in the background, or use a special "ADC sleep" mode to halt the processor while a conversion is taking place, to minimize voltage disturbances from the rest of the MCU.

Analog Comparator Peripheral

Nearly all AVR microcontrollers feature an Analog Comparator which can be used to implement an ADC on those AVRs which do not have an ADC, or if all of the ADC inputs are already in use. Atmel provides sample code and documentation for using the comparator as a low-speed ADC. The signal to be measured is connected to the inverted input, and a reference signal is connected to the non-inverting input. The AVR generates an interrupt when the signal falls below or rises above the reference value.

A common use for the analog comparator is sensing battery voltage, to alert the user to a low battery.

Other Integrated Hardware

Aside from what might be considered typical peripherals for a microcontroller (UART, SPI, ADC), some AVR's include more specialized peripherals for specific applications.

LCD Driver

In larger models like the ATMega169 (as seen in the AVR Butterfly), an LCD driver is integrated. The LCD driver commandeers several ports of the AVR to drive the column/row connections of a display. One particular trait of Liquid Crystal that must be taken care of is that no DC bias is put through it. DC bias, or having more electrons passing one way than the other when pumping AC, chemically breaks apart the liquid crystal. The AVR's LCD module uses precise timing to drive pixels forwards and backwards equally.

USB Interface

The AT90USB series includes an on-chip USB controller. Some models are "function" only, while others have On-The-Go functionality to act as either a USB host (for interfacing with other slave devices) or as a USB slave (for interfacing with a USB master). These USB-enabled AVRs can be found here [1].

As a sidenote, AVR's without built-in USB can use a basic firmware-only approach such as the IgorPlug firmware.

Other firmware USB drivers are obdev, which is available under an Open Source compliant license with some restrictions, and USBtiny, which is licensed under the GPL. In contrast to the IgorPlug solution, which is completely written in assembly, these two implementations are written in C, with only the time-critical parts in assembly.

Although these software implementation provide a very cheap way to add USB connectivity, they are limited to low-speed transfers, and tie up quite some AVR resources. Other hardware ICs which translate USB signals to RS-232 (serial) for the AVRs are available, from vendors such as FDTI. These ICs have the advantage of offloading the strenuous task of managing the USB connection with the disadvantage of being limited to the speed of the AVR's serial port.

Temperature Sensor

Some newer models have a built in temperature sensor hooked up to the ADC.

AVR Selection

The AVR microcontrollers are divided into three groups:

tinyAVR
AVR (Classic AVR)
megaAVR

The difference between these devices mostly lies in the available features. The tinyAVR microcontrollers are usually devices with lower pin-count or reduced feature set compared to the megaAVR's . All AVR devices have the same instruction set and memory organization, so migrating from one device to another AVR is easy. In addition, the classic AVR is mostly EOL'd, so if you are looking to be able to buy replacements ever, go for the Mega or Tiny series.

Some AVR's contain SRAM, EEPROM, External SRAM interface, Analog to Digital Converters, Hardware Multiplier, UART, USART and the list goes on.

Atmel provides a Parametric Product Table which compares the memory, peripherals, and features available on the entire line of AVR's.

Hardware Design Considerations

Atmel provides the AVR Hardware Design Considerations to assist the hardware designer. This document also shows the standard in-circuit serial programming connector.

AVR development/application boards

Butterfly Demo Board

The AVR Butterfly is a self-contained, battery-powered demonstration board running the ATMEL AVR ATmega169V Microcontroller. The board includes an LCD screen, joystick, speaker, serial port, RTC, flash chip, temperature, light & voltage sensors. The board has a shirt pin on its back and can be worn as a name badge.

The AVR Butterfly comes preloaded with software to demonstrate the capabilities of the microcontroller. Factory firmware can scroll your name, display the sensor readings, and show the time. Also, the AVR Butterfly has a piezo buzzer that can reproduce sound.

The AVRButterfly demonstrates LCD driving by running a 14-segment, 6 alpha-numeric character display. However, the LCD interface consumes many of the I/O pins.

The Butterfly's ATmega169 CPU is capable of speeds up to 8Mhz, however it is factory set by software to 2Mhz to preserve the button battery life. A pre-installed bootloader program allows the board to be re-programmed with a standard RS-232 serial plug.

Ecros Technology produces a carrier board for the Butterfly which provides a power supply, convenient connections to I/O ports, a DB-9 serial port (with level translator), and a large prototyping area.

STK500 starter kit

The STK500 starter kit and development system features ISP and high voltage programming for all AVR devices, either directly or through extension boards. The board is fitted with DIP sockets for all AVRs available in DIP packages.

Several expansion modules are available for the STK500 board. These include:

STK501 - Adds support for microcontrollers in 64 pin TQFP packages.
STK502 - Adds support for LCD AVRs in 64 pin TQFP packages.
STK503 - Adds support for microcontrollers in 100 pin TQFP packages.
STK504 - Adds support for LCD AVRs in 100 pin TQFP packages.
STK505 - Adds support for 14 and 20 pin AVRs.
STK520 - Adds support for 14 and 20 pin microcontrollers from the AT90PWM family.

Third-Party Boards

There are many AVR based development and/or application boards available from third parties, far too many to list all of them here.

Arduino is built around an ATmega8 or ATmega168, and is designed to be used with an open source development environment.
AVR Based Support and Application Boards by Mr. Pascal Stang from Stanford University
GPMPU40 supports many different Atmel AVR chips
Futurlec 2313 Board (Note that the AT90S2313 is obsolete, and has been replaced by the ATtiny2313.)

Programming Interfaces

There are many means to get Program code onto the AVR.

In System Programming

Functionally, ISP is done through SPI, with some twiddling on Reset. As long as the SPI pins of the AVR aren't connected to anything disruptive, the AVR chip could stay soldered onto a board while reprogramming. All that's needed is a 6 pin plug, and an affordable PC adapter. This is the most common way to develop with an AVR.

Atmel's AVR ISP mkII connects to a PC's USB port and performs in-system programming using Atmel's software.

avrdude (AVR Downloder UploaDEr) runs on Linux, FreeBSD, Windows, and Mac OS X, and supports a variety of in-system programming hardware, including Atmel AVR ISP mkII, Atmel JTAG ICE, older Atmel serial-port based programmers, and various third-party and "do-it-yourself" programmers.

High Voltage Programming

HV programming is mostly the backup mode on smaller AVRs. An 8 pin package doesn't leave many unique signal combinations to kick the AVR into programming mode. A 12 volt signal, however, is something the AVR should never see in a proper circuit.

Parallel Programming

Parallel is a backup mode on larger AVRs. It may be the only way to talk to an AVR that has a crazy oscillator fuse set. Parallel programming may also be faster, good if you have a modest production line going.

Bootloader Programming

Most AVR models can reserve a bootloader region, 256B - 2KB, where re-programming code can reside. At power on, the Bootloader runs first, and does some user-programmed determination whether to re-program, or jump to the main application. The code can re-program through any interface available, it could read an encrypted binary through an ethernet adapter if it felt like it. Atmel has application notes and code pertaining to any interface from RS-232 onwards.

Bootloaders are covered in detail in chapter [[../Bootloaders and Bootsectors/]] .

No Programming at All

The AT90SC series of AVR's are available with a mask ROM rather than flash for program memory. [2]

Because of the large up-front cost and minimum order quantity, mask ROM is only cost-effective for a large production run.

Debugging Interfaces

The AVR offers several options for debugging, mostly involving on-chip debugging while the chip is in the target system.

JTAG

JTAG provides access to on-chip debugging functionality while the chip is running in the target system. JTAG allows accessing internal memory and registers, setting breakpoints on code, and single-stepping execution to observe system behaviour.

Atmel provides a series of JTAG adapters for the AVR.

The JTAGICE adapter interfaces to the PC via a standard serial port. It is somewhat expensive by hobbyist standards at around US $300, although much more affordable than many other microntroller emulation systems. The JTAGICE has been EOL'ed, though it is still supported in AVR Studio and other tools.
The JTAGICE mkII replaces the JTAGICE, and is similarly priced. The JTAGICE mkII interfaces to the PC via USB, and supports both JTAG and the newer debugWIRE interface.
The AVR Dragon is a low-cost (approximately $50) substitute for the JTAGICE mkII for certain target parts. The AVR Dragon provides in-system serial programming, high-voltage serial programming and parallel programming, as well as JTAG or debugWIRE emulation for parts with 32KB of program memory or less.

There are also several third party JTAG debuggers/reprogrammers for around $40, such as those from Ecros and Olimex, as well as DIY projects, including Evertool and Aquaticus. These are clones of the original JTAGICE, and do not support the debugWire interface.

JTAG can also be used to perform a Boundary Scan test [3], which tests the electrical connections between AVRs and other Boundary Scan capable chips in a system. Boundary scan is well-suited for a production line; the hobbyist is probably better off testing with a multimeter or oscilloscope.

debugWIRE

debugWIRE^TM is Atmel's solution for providing on-chip debug capabilities via a single microcontroller pin. It is particularly useful for lower pin count parts which cannot provide the four "spare" pins needed for JTAG. The JTAGICE mkII and the AVR Dragon support debugWIRE. debugWIRE was developed after the original JTAGICE release, and none of the JTAG clones support it.

Simulation

Simulation is not a debugging interface, per se, but simulation in software can be an effective debugging aid prior to committing a design to physical hardware.

AVR Studio simulates the AVR core at the assembly language level, and allows viewing and manipulation of all internal registers. HAPsim is a set of virtual devices that plug into AVR Studio. It provides LCDs, LEDs, buttons, and dumb terminals.

Other software packages exist which provide software simulation of the AVR core and peripherals are available.

VMLab provides full-circuit simulation as well as a virtual oscilloscope. The debugger offers the ability to single step C code, as well as edit and rebuild winAVR programs. As of version 3.12, VMLab is freeware.

AVRora is an "AVR simulation and analysis framework."

Proteus provides schematic capture, PCB editing, and microcontroller simulation, including the AVR. The simulator "downloads" code into simulated AVR core. There is also support for a variety of virtual peripherals within the simulator.

Firmware Programming

A microcontroller won't do much without firmware; program code to tell the microcontroller what to do. Firmware for AVR's can be written in many different languages. Atmel published The Novice's Guide to AVR Development, part of Atmel Applications Journal 2001 Summer, which provides a brief tutorial in assembly language programming using AVR Studio.

AVR Assembly Language

Some features of the AVR microprocessor can only be accessed with assembly language.

Assembly language will almost always produce the smallest code as compared to other compiled languages, and for this reason, it is a popular choice for applications that must fit into a very small code space.

Ada

AVR-Ada at Sourceforge – Ada compiler from GCC and libraries for AVR.

BASIC

BASCOM-AVR development environment – BASIC Compiler for the AVR Family; Complete IDE with editor, compiler, simulator and a lot of library functions. The demo version's limited to 4K code. The bascomp.exe command-line works in Wine.

BASIC to C has a free starter ATMEL AVR BASIC called RVK-BASIC. Click on forums to see the updates. Runs on Windows platforms only at this time and can be downloaded for free. (Not anymore. Shareware is limited to 100 lines of code.)

No known implementations of BASIC for the AVR can be used interactively; they all require some degree of compilation on a separate PC.

C

GCC, the Gnu Compiler Collection, has thorough AVR support for C language.
- Windows: WinAVR development tools, the Windows port of GCC. Now, it can even plug into the latest AVR Studio.
  - WinAVR and Butterfly Quickstart Guide
- Linux: Introduction to using AVR-GCC under Linux
  - Debian and Ubuntu users, simply "apt-get install binutils-avr gcc-avr avr-libc"
  - Gentoo "emerge avr-libc avrdude crossdev" then "crossdev --target avr-softfloat-linux-gnu"
- Development upon AVR GCC itself happens at the avr-gcc maillist.
- Libraries for GCC
  - The avr-libc project or avr-libc manual describes the library you probably found bundled with AVR GCC.
  - Procyon AVRlib An extensive AVR C Code library with example application code included.
  - A Doubly Linked Memory Manager for WinAVR
- It is possible to use C on the Tiny series which have no RAM (aside from the 32 registers), as demonstrated by Bruce Lightner.

ImageCraft C is an inexpensive commercial compiler.
IAR is an expensive commercial compiler.
CodeVisionAVR is a relatively inexpensive commercial C compiler for the AVR.

C++

GCC also has support for C++ on the AVR.

Certain features of C++ are unsuitable for use on a smaller micro like the AVR due to the amount of memory requires to implement them; these include exceptions and templates. However, when using a suitable subset of C++, the resultant code is of comparable size to its C language equivalent. One notable use of C++ on the AVR is the Arduino.

Java

NanoVM - Java virtual machine written in C for Atmel AVR microcontrollers with at least 8k flash.

MCU Java source - Java source to C source translator, which allows to write MCU programs in Java.

Pascal

AVRco development environment – Complete IDE with editor, compiler, simulator, HLL debugger with JTAG-ICE, and a plethora of library functions

MikroPascal New Pascal compiler for AVR family. Very good, simple user interface, extensive set of libraries, almost pure pascal syntax. Free version limitation is 4KB, commercial price is quite reasonable. Supplied with good help and examples.

Forth

AVR ByteForth development environment – Includes (dis)assembler, simulator, ISP-programmer and supports almost any AVR to date. Many library functions and example programs. Comes with complete (Dutch) language manual. There is however an English language version with crash course included in the free but complete 2 kByte demo version. ByteForth runs under DOS or any system that supports a working DOS-box as Linux, Windows-95, Windows-98SE, etc.

amforth: atmega forth is a compact Forth for AVR atmega micro controllers. It is released under the GPL 2 and is modeled after ANS 94.

Avise (Atmel VIrtual Stack Engine) is a "modified version of the Forth programming language." Avise is only available as HEX files to program into one of the supported AVR's; source code is not available. The author's web site also includes some PCB layouts for use with Avise.

Note that some Forth environments run interactively on the AVR. For example, Avise presents a console on the AVR's UART0 which can accept new word definitions and execute operations. No software (other than a terminal emulator) is required on the PC.

Python

PyMite is a subset of Python that runs on "any device in the AVR family that has at least 64 KiB program memory and 4 KiB RAM."

References

Books

Dhananjay Gadre - Programming and Customizing the AVR Microcontroller, McGraw-Hill, 2000.
Richard H. Barnett, Sarah A. Cox, Larry D. O'Cull - Embedded C Programming and the Atmel AVR, Thomson Delmar Learning, 2002.
John Morton - AVR: An Introductory Course, Newnes, 2002.
Claus Kuhnel - AVR RISC Microcontroller Handbook, Newnes, 1998.
Joe Pardue - C Programming for Microcontrollers, featuring ATMEL's AVR Butterfly and the free WinAVR Compiler, Smiley Micros, 2005. Smiley Micros
Chuck Baird - Programming Microcontrollers using Assembly Language, Lulu.com, 2006. cbaird.net

Wiki

Template:Wikipediapar Template:Wikipediapar

Wikiversity:Embedded System Engineering
The massmind and its technical reference has a lot of information about embedded systems hardware and software. Massmind is almost a wiki.
Robotics Wiki: AVR development
Forth Freak wiki: PFAVR
ByteForth 8-bit Forth development environment wiki on Forth Freak
PyMite wiki

Official Atmel Websites

Programming & Educational Websites

Other AVR Related Websites

Mailing List & Forums

University Courses