Embedded Systems/Atmel AVR
The Atmel AVRTM 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.
- 1 Memory
- 2 Reset
- 3 Interrupts
- 4 General Purpose I/O Ports
- 5 Timer/Counters
- 6 Serial Communication
- 7 Analog Interfaces
- 8 Other Integrated Hardware
- 9 AVR Selection
- 10 Programming Interfaces
- 11 Debugging Interfaces
- 12 Firmware Programming
- 13 References
- 14 College Courses
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 memory for data and program storage, and so does not require any external memory.
The four types of memories in a Atmel AVR are:
- Data memory: registers, I/O registers, and SRAM
- Program flash memory
- Fuse bits
All these memories are on the same chip as the CPU core. Each kind of memory is separated from each other, in different locations on the chip. Address 0 in data memory is distinct from address 0 in program flash and address 0 in EEPROM.
All AVR microcontrollers have some amount of 16 bit wide non-volatile flash memory for program storage, from 1 KB up to 256 KB (or, 512-128K typical program words). The program memory holds the executable program opcodes and static data tables. Program memory is linearly addressed, and so mechanisms like page banking or segment registers are not required to call any function, regardless of its location in program memory.
AVRs 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 AVRs can also be reprogrammed with a high-voltage parallel or serial programmer, and via JTAG (again, in situ) on certain chips. The flash memory in an AVR can be re-programmed at least 10,000 times.
Many of the newer AVRs (MegaAVR series) have the capability to self-program the flash memory. This functionality is used mainly by bootloaders.
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 (000016-001F16) followed by the reserved space for up to 64 I/O registers (002016-005F16). The actual usable SRAM starts after both these sections (address 006016). (Note that the I/O register space may be larger on some more extensive devices, in which case the beginning address of SRAM will be higher.) Even though there are separate addressing schemes and optimized opcodes for register file and I/O register access, they can still be addressed and manipulated as if they were SRAM.
The I/O registers (and the program counter) are reset to their default starting values 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 64 KB. When enabled, external SRAM is overlaid by internal SRAM; an access to address 000016 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 32 KB or less, one option is to use a higher-order address line to drive the chip select line to the SRAM.
Almost all AVR microcontrollers have internal 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. AVRs ship from the factory with the EEPROM erased, i.e. the value in each byte of EEPROM is FF16.
Many of the AVRs have errata about writing to EEPROM address 0 under certain power conditions (usually during brownout), and so Atmel recommends that programs not use that address in the EEPROM.
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 also a fuse to enable serial in-system programming, which is set by default. If it is set incorrectly, the only way to program the chip is by using 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.
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.
AVRs 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. On some AVRs the watchdog can be programmed to issue an interrupt instead of resetting the processor. This functionality can be used to wake up the AVR from a sleep mode.
The RESET pin is used for in-system serial programming, as a GPIO, or for debugWIRETM 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.
AVRs 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 AVRs have at least one dedicated external interrupt pin (INT0). Older AVRs can trigger an interrupt on a high or low level, or on a falling edge. Newer AVRs add more options, such as triggering on the rising edge or either edge. Additionally, many of the newer AVRs 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. GPIOs are grouped into "ports" of up to 8 pins, though some AVRs 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 AVRs, and was used to read the value on the port pin, regardless of the data direction. Newer AVRs allow a write to the PIN register to toggle the corresponding PORT bit, which saves a few processor cycles when bit-banging an interface.
All AVRs have at least one 8-bit timer/counter. For brevity, a timer/counter is usually referred to as simply a timer.
Some of the Tiny series have only one 8-bit timer. At the high end of the Mega series, there are chips with as many as six timers (two 8-bit and four 16-bit).
A timer can be clocked directly by the system clock, by a divided-down system clock, or by an external input (rising or falling edge). Some AVRs also include an option to use an external crystal, asynchronous to the system clock, which can be used for maintaining a real-time clock with a 32.768 kHz crystal.
In normal mode, the timer counts up to the top FF8 (or FFFF16), roll over to zero, and set an overflow bit, which may cause an interrupt if enabled. Within the interrupt routine, the counter can be loaded with the desired value in addition to any other processing required.
The Clear Timer on Compare (CTC) mode allows for the timer to be cleared when it matches a value in the compare register, before the timer reaches the top and overflows. Clearing the timer prior to overflow manipulates the timer resolution, allowing for greater control of the output frequency of a compare match. It can also simplify the counting of an external event.
The value of a timer can be read back at any time, even while it is running. (There is a specific sequence documented in the datasheets to read back a 16-bit timer so that a consistent result is returned, since the AVR can only move 8 bits at a time.) A timer can be halted temporarily by changing its clock input to "no clock source," then resumed by re-selecting the previous clock input.
PWM (Pulse Width Modulation)
Many of the AVRs include a compare register for at least one of the timers. The compare register can be used to trigger an interrupt and/or toggle an output pin (i.e. OC1A for Timer 1) when the timer value matches the value in the compare register. This may be done separately from the overflow interrupt, enabling the use of pulse-width modulation (PWM).
Some AVRs also include options for phase-correct PWM, or phase- and frequency-correct PWM. Phase correction is required by many motors.
The ATtiny26 is unique in its inclusion of a 64 MHz high-speed PWM mode. The 64 MHz clock is generated from a PLL, and is independent of, and asynchronous to, the processor clock.
Some AVRs also include complementary outputs suitable for controlling some motors. A dead-time generator (DTG) inserts a delay between one signal falling and the other signal rising so that both signals are never high at the same time. The high-end AT90PWM series allows the dead time to be programmed as a number of system clock cycles, while other AVRs with this feature simply use 1 clock cycle for the dead time.
Output Compare Modulator
An Output Compare Modulator (OCM), which allows generating a signal that is modulated with a carrier frequency. OCM requires two timers, one for the carrier frequency, and the second for the signal to be modulated. OCM is available on some of the Mega series.
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 implement 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 RS-232 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 latter often happens with the low-pincount AVRs in DIP packages.
Finally, there is also the possibility to use additional logic to implement 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 RS-232 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 RS-232 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 is highly recommended. The serial communication features most commonly to be found on AVRs are discussed in the following sections.
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. USART is an acronym from the following words:
- Can be used in a lot of different serial communication scenarios
- Can be used for synchronous serial communication (sender and receiver are synchronised by a particular clock signal)
- Can be used for asynchronous serial communication (sender and receiver are not explicitly synchronised via a clock signal, but synchronise on the data signal).
- The hardware in the AVR can receive serial data
- The hardware can send serial data
Earlier AVRs had a UART that did not support synchronous serial communication, hence the absence of the "S" in the acronym.
USARTs or UARTs work with logic voltage levels while e.g. the RS-232 protocol requires much different voltage levels than the 5 V or 3.3 V 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 communicate with RS-232, RS-485, MIDI, LIN bus, or CANbus devices, to name some of the popular protocols.
See Robotics: Computer Control: The Interface: Networks for more details.
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 +15 V, and -3 to -15 V, but +/-12 V 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. 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 400 kbit/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:
- Master In Slave Out.
- Master Out Slave In.
- 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)(Except on the mega128).
Universal Serial Interface Some AVRs, 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.
SPI, RS-232, I2C, 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 Celsius or Fahrenheit, depending on your sensor), readings from a pressure sensor, control signals to turn off a pump, or the bytes of a JPEG image. Some of this meaning may be assigned by the use of a serial communications protocol.
A serial protocol must handle a wide variety of usage conditions, as well as provide for recovering from failures. For example, if two sensors are connected to a single microcontroller (such as inside and outside temperature), the protocol provides a way for the receiver on the other end of the serial line to discern which reading belongs to which sensor. If a cable is unplugged during transmission, or a byte is lost due to line noise, the protocol can provide a way to re-synchronize the transmitter and the receiver.
The Serial Programming wikibook contains more discussion of serial protocols.
Analog to Digital
Analog to digital conversion uses digital number to represent the proportion of the analog signal sampled. For example, by applying a 3 V to the input of an ADC with a full-scale range of 5 V, will result as 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 , or 255. 10 bits will provide output from 0 to .
10 bit sample: in ADCH:ADCL or
8 bit sample: in ADCL
Many AVRs include an ADC, specifically a successive-approximation ADC. The ADC reference voltage (5 V in the example above) can be an external voltage, an internal fixed 1.1 V 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 AVRs include more specialized peripherals for specific applications.
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 crystals 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.
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).
AVRs without built-in USB can use an external chip such as the PDIUSB12, or for a low-speed and minimal functionality device, a firmware-only approach.
Two firmware-only USB drivers are
- obdev, which is available under an Open Source compliant license with some restrictions, and
- USBtiny, which is licensed under the GPL.
- The LUFA library, released under the MIT License, allows the USB-enabled AVR microcontrollers to act as a USB Host, slave or OTG device.
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 FTDI. 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. See Embedded Systems/Particular Microprocessors#USB interface for more details on such USB interface chips.
Some newer models have a built in temperature sensor hooked up to the ADC.
The AVR microcontrollers are divided into three groups:
- AVR (Classic AVR)
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 megaAVRs. All AVR devices have the same basic instruction set and memory organization, so migrating from one device to another AVR is usually trivial.
The classic AVR is mostly EOL'd, and so new designs should use the Mega or Tiny series. Some of the classic AVRs have replacement parts in the mega series, e.g. the AT90S8515 is replaced by the mega8515.
Atmel provides a Parametric Product Table which compares the memory, peripherals, and features available on the entire line of AVRs.
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 and 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 AVR Butterfly 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 8 MHz, however it is factory set by software to 2 MHz 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.
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 ATmega328 (ATmega8 or ATmega168 in older boards), 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.)
- Olimex produces many AVR-based development and prototyping boards, and has a list of links to example projects as well.
- Protostack has development boards and kits for the 28 pin AVR microcontrollers (atmega8 etc) plus a number of AVR Tutorials
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 Serial Programming
HVSP 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. HVSP is essential when working with an AVR whose RESET pin is disabled to allow using it as another general-purpose IO pin. As RESET no longer has its in-built function for SPI programming, the 12 volt signal allows reliable signalling that programming should take place, as it is something the chip should not otherwise see during normal operation.
High Voltage Parallel Programming
HVP 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.
Most AVR models can reserve a bootloader region, 256 B - 2 KB, 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 AVRs are available with a mask ROM rather than flash for program memory. 
Because of the large up-front cost and minimum order quantity, mask ROM is only cost-effective for a large production run.
The AVR offers several options for debugging, mostly involving on-chip debugging while the chip is in the target system.
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 32 KB 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,
JTAG can also be used to perform a Boundary Scan test , 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.
debugWIRETM 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 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.
Atmel 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.
- Simulavr is a free (GPLv2) simulator working with GDB and commonly used with AVR-GCC.
A microcontroller won't do much without firmware; program code to tell the microcontroller what to do. Firmware for AVRs 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
- Atmel Studio 6: Assembler, Simulator & WinAVR Compatible Project Editor (free download)
- AVR Instruction Set User Guide
- AVR Assembler Site
- AVR Assembler Forum
- AVR Assembler Tutorial
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.
- GNAT AVR Compiler from AdaCore.
- B# is a modern, object-oriented language designed explicitly for small footprint embedded systems.
- The BASCOM-AVR development environment is a BASIC Compiler for the AVR family. The IDE includes an editor, compiler, simulator and a lot of library functions. The demo version is 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, which runs on Windows. The downloaded version is limited to 100 lines of code.
- EEBasic is an implementation of BASIC on a AVR Mega644 which only requires a terminal or terminal emulator to program; no PC based compiler (or other IDE) is used. Language extensions provide for use of the on-chip peripherals.
- AttoBASIC is a FREE implementation of a hardware orientated Tiny BASIC for the AVR ATmega88, ATmega168, ATmega328, ATmega2560, ATmega32U4 and AT90USB1286 micro-controllers. This includes all ARDUINO products using the supported AVR's as well as the TEENSY++2.0. Communications is through the UART for all supported AVR's (or the ATmega32U4 and AT90USB1286 USB interface). It contains support for the ADC, PWM, SPI, TWI and 1-Wire interfaces as well as an Input Capture feature (a gate-time selectable pulse counter), Direct Digital Synthesis (DDS) of square waves via a single port-bit toggle, nRF24L01 RF Transceiver and DHT temperature and humidity sensors. Programs can be SAVEd and LOADed to/from EEPROM via a File System and a self-start feature allows a program saved in EEPROM to be automatically run at start-up. The LUFA (DFU and CDC modes) and OptiBoot boot-loaders are integrated into the project. Pre-built HEX files are available for the ATmega88, ATmega168, ATmega328, ATmega2560, ATmega32U4 and AT90USB1286 at clock speeds of 4, 8, 16 and 20MHz. Builds are available with and without the OptiBoot-loader (or LUFA) as well as builds for the ATmega32U4 and AT90USB1286 UART or USB for serial I/O. The full source code is provided as are sample programs. Older versions support the ATMEGA163 and ATMEGA8515/AT90S8515 as well as the ATTINY2313/AT90S2313.
- GCC, the GNU Compiler Collection, has thorough AVR support for the C programming language.
- Windows: WinAVR development tools, the Windows port of GCC. Now, it can even plug into the latest AVR Studio.
- 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"
- Debian and Ubuntu users, simply "
- Development upon AVR GCC itself happens at the AVR-GCC maillist.
- Libraries for GCC
- 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.
- MikroElektronika mikroC PRO for AVR is a full-featured ANSI C compiler for AVR and software libraries.
- 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 required 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.
- ByteForth (wiki) (purchase) – Includes a (dis)assembler, simulator, ISP-programmer and supports almost any AVR microcontroller to date. Many library functions and example programs. It comes with a complete (Dutch) language manual. There is however an English language version with a 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 AVRs; source code is not available. The author's web site also includes some PCB layouts for use with Avise.
- avrforth is a 16-bit subroutine threaded Forth kernel for Atmel's AVR series of microcontrollers.
- FlashForth is a 16-bit subroutine threaded Forth system for Atmel's Atmega series of microcontrollers.
- MikroForth Adresses the ATtiny (documentation in German)
- asforth A subroutine threaded Forth like system
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.=== 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.
- uLisp - A Lisp interpreter for the Arduino. Based on a subset of Common Lisp, supports the ATmega328, ATmega2560 and ATmega644/1284.
- AVRco development environment – IDE also includes simulator and HLL debugger with JTAG-ICE. Includes numerous library functions.
- MikroPascal – Includes AVR-specific libraries, plus help and examples. Free version is limited to 4 KB.
- Embedded Pascal – IDE running under Windows 95,98 and NT. Language extensions provide for mixing AVR assembly in pascal code.
- Micro Python is a lean and fast implementation of the Python 3 programming language that is optimised to run on a microcontroller.
- 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."
Official Atmel Websites
- AVRfreaks wiki
- Serial Programming:MAX232 Driver Receiver
- Wikiversity:Embedded System Engineering
- The massmind technical reference has an AVR section, plus a lot of general information about embedded systems hardware and software. Massmind is almost a wiki.
- AVR wiki offline as of 2010-02-15
Programming & Educational Websites
- AVR Assembly Language Site
- AVR Machine Language
- Free AVR Tutorials and Projects
- AVR learning
Mailing List & Forums
- The AVR Forum
- AVR-Chat & AVR-GCC mailing list
- AVR Butterfly Group
- Muhammad Ali Mazidi - AVR Microcontroller and Embedded Systems: Using Assembly and C, Pearson Education.
- 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
- Richard H. Barnett - Embedded C Programming And The Atmel AVR, Delmar Cengage Learning; 2 edition (June 5, 2006)
The following courses are known to use the Atmel AVR as part of the curriculum.
- Introduction to Mechatronics, Santa Clara University
- Embedded System Design Laboratory, Stanford University
- Designing with Microcontrollers, Cornell University
- San Jose State University
- Microprocessors and Interfacing, UNSW
The following courses are known to use the Atmel AVR as part of the curriculum.