Hubbry Logo
AVR microcontrollersAVR microcontrollersMain
Open search
AVR microcontrollers
Community hub
AVR microcontrollers
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
AVR microcontrollers
AVR microcontrollers
from Wikipedia
AVR logo
Various older AVR microcontrollers: ATmega8 in 28-pin narrow dual in-line package (DIP-28N), ATxmega128A1 in 100-pin thin quad flat pack (TQFP-100) package, ATtiny45 in 8-pin small outline (SO-8) package
ATmega328P in 28-pin narrow dual in-line package (DIP-28N). It is commonly found on Arduino boards.

AVR is a family of microcontrollers developed since 1996 by Atmel, acquired by Microchip Technology in 2016. They are 8-bit RISC single-chip microcontrollers based on a modified Harvard architecture. AVR was one of the first microcontroller families to use on-chip flash memory for program storage, as opposed to one-time programmable ROM, EPROM, or EEPROM used by other microcontrollers at the time.

AVR microcontrollers are used numerously as embedded systems. They are especially common in hobbyist and educational embedded applications, popularized by their inclusion in many of the Arduino line of open hardware development boards.

The AVR 8-bit microcontroller architecture was introduced in 1997. By 2003, Atmel had shipped 500 million AVR flash microcontrollers.[1]

History

[edit]

The AVR architecture was conceived by two students at the Norwegian Institute of Technology (NTH),[2] Alf-Egil Bogen[3] and Vegard Wollan.[4]

Atmel says that the name AVR is not an acronym and does not stand for anything in particular. The creators of the AVR give no definitive answer as to what the term "AVR" stands for.[4] However, it is commonly accepted that AVR stands for Alf and Vegard's RISC processor.[5] Note that the use of "AVR" in this article generally refers to the 8-bit RISC line of Atmel AVR microcontrollers.

The original AVR MCU was developed at a local ASIC design company in Trondheim, Norway, called Nordic VLSI at the time, now Nordic Semiconductor, where Bogen and Wollan were working as students.[citation needed] It was known as a μRISC (Micro RISC)[6] and was available as silicon IP/building block from Nordic VLSI.[7] When the technology was sold to Atmel from Nordic VLSI, the internal architecture was further developed by Bogen and Wollan at Atmel Norway, a subsidiary of Atmel. The designers worked closely with compiler writers at IAR Systems to ensure that the AVR instruction set provided efficient compilation of high-level languages.[8]

Among the first of the AVR line was the AT90S8515, which in a 40-pin DIP package has the same pinout as an 8051 microcontroller, including the external multiplexed address and data bus. The polarity of the RESET line was opposite (8051's having an active-high RESET, while the AVR has an active-low RESET), but other than that the pinout was identical.

The Arduino platform, developed for simple electronics projects, was released in 2005 and featured ATmega8 AVR microcontrollers.

Device overview

[edit]

The AVR is a modified Harvard architecture machine, where program and data are stored in separate physical memory systems that appear in different address spaces, but having the ability to read data items from program memory using special instructions.

Basic families

[edit]

AVRs are generally classified into following:

tinyAVR – the ATtiny series

Flash size Frequency
[MHz]
Package SRAM EEPROM
0.5–32 KB 1.6–20 6–32-pin package 32–3072 bytes 64–512 bytes

The ATtiny series features small package microcontrollers with a limited peripheral set available. However, the improved tinyAVR 0/1/2-series (released in 2016) include:

  • Peripherals equal to or exceed megaAVR 0-series
  • Event System
  • Improved AVRxt instruction set (improved timing of calls), hardware multiply

megaAVR – the ATmega series

Flash size Frequency
[MHz]
Package SRAM EEPROM
4–256 KB 1.6–20 28–100-pin package 256–16384 bytes 256–4096 bytes

The ATmega series features microcontrollers that provide an extended instruction set (multiply instructions and instructions for handling larger program memories), an extensive peripheral set, a solid amount of program memory, as well as a wide range of pins available. The megaAVR 0-series (released in 2016) also has functionality such as:

  • Event system
  • New peripherals with enhanced functionality
  • Improved AVRxt instruction set (improved timing of calls)

AVR Dx – The AVR Dx family features multiple microcontroller series, focused on HCI, analog signal conditioning and functional safety.

Flash size Frequency
[MHz]
Package SRAM EEPROM Release year
16–128 KB 20–24 at 1.8–5.5 V 14–64-pin package 4–16 KB 512 bytes 2020

The parts numbers is formatted as AVRffDxpp, where ff is flash size, x is family, and pp is number of pins. Example: AVR128DA64 – 64-pin DA-series with 128k flash. All devices in the AVR Dx family include:

  • an Async Type D timer that can run faster than the CPU
  • 12-bit ADC
  • 10-bit DAC
  • AVR DA-series (early 2020) – The high memory density makes these MCUs well suited for both wired and wireless communication-stack-intensive functions.
    • integrated sensors for capacitative touch measurement (HCI)
    • updated core independent peripherals (CIPs) and analog peripherals
    • no external high frequency crystal
  • AVR DB-series (mid-late 2020) – inherits many features from the DA-family, while adding its own:
    • 2 or 3 on-chip opamps
    • MultiVoltage IO (MVIO) on PORTC
    • Supports external HF crystal
  • AVR DD-series
    • 16–64 KiB Flash
    • 2–8 KiB SRAM
    • 14–32-pin package
    • internal 24 MHz oscillator
    • 7–23-channel 130 kS/s 12-bit differential Analog-to-Digital Converter (ADC)
    • no amplifiers
    • 1 analog comparator
    • Two USARTs, one SPI, one dual-mode TWI
    • Multi-Voltage Input/Output (MVIO) support on 3 or 4 pins on Port C
    • 4 Configurable Custom Logic (CCL) cells, 6 Event System channels
  • AVR EA-series
    • 8–64 KiB Flash
    • 28–48-pin package
    • internal 20 MHz oscillator
    • 24–32-channel 130 kS/s 12-bit differential Analog-to-Digital Converter (ADC)
    • Programmable Gain Amplifier (PGA) with up to 16x gain
    • 2 analog comparators
    • Three USARTs, one SPI, one dual-mode TWI
    • no Multi-Voltage Input/Output (MVIO)
    • 4 Configurable Custom Logic (CCL) cells, 6 Event System channels

XMEGA

Flash size Frequency
[MHz]
Package SRAM EEPROM Release year
16–256 KB 32 44–100-pin package 1–32 KB 512–2048 bytes

the ATxmega series offers a wide variety of peripherals and functionality such as:

  • Extended performance features, such as DMA, "Event System", and cryptography support
  • Extensive peripheral set with ADCs

Application-specific AVR

  • megaAVRs with special features not found on the other members of the AVR family, such as LCD controller, USB controller, advanced PWM, CAN, etc.

FPSLIC (AVR with FPGA)

  • FPGA 5k to 40k gates
  • SRAM for the AVR program code, unlike all other AVRs
  • AVR core can run at up to 50 MHz[9]

32-bit AVRs

  • In 2006, Atmel released microcontrollers based on the 32-bit AVR32 architecture. This was a completely different architecture unrelated to the 8-bit AVR, intended to compete with the ARM-based processors. It had a 32-bit data path, SIMD and DSP instructions, along with other audio- and video-processing features. The instruction set was similar to other RISC cores, but it was not compatible with the original AVR (nor any of the various ARM cores). Since then support for AVR32 has been dropped from Linux as of kernel 4.12; compiler support for the architecture in GCC was never mainlined into the compiler's central source-code repository and was available primarily in a vendor-supported fork. At the time that AVR32 was introduced, Atmel had already been a licensee of the ARM architecture, with both ARM7 and ARM9 microcontrollers having been released prior to and concurrently with the AVR32; later Atmel focused most development effort on 32-bit chips with ARM Cortex-M and Cortex-A cores.

Device architecture

[edit]
Atmel ATxmega128A1 in 100-pin TQFP package
ATMEL MEGA32U4 die shot

The AVRs have 32 single-byte registers and are classified as 8-bit RISC devices.

Flash, EEPROM, and SRAM are all integrated onto a single chip, removing the need for external memory in most applications. Some devices have a parallel external bus option to allow adding additional data memory or memory-mapped devices. Almost all devices (except the smallest TinyAVR chips) have serial interfaces, which can be used to connect larger serial EEPROMs or flash chips.

Program memory

[edit]

Program instructions are stored in non-volatile flash memory. Although the MCUs are 8-bit, each instruction takes one or two 16-bit words. The size of the program memory is usually indicated in the naming of the device itself (e.g., the ATmega64x line has 64 KB of flash, while the ATmega32x line has 32 KB). There is no provision for off-chip program memory; all code executed by the AVR core must reside in the on-chip flash. However, this limitation does not apply to the AT94 FPSLIC AVR/FPGA chips.

Internal data memory

[edit]

The data address space consists of the register file, I/O registers, and SRAM. Some small models also map the program ROM into the data address space, but larger models do not.

Internal registers

[edit]

In the tinyAVR and megaAVR variants of the AVR architecture, the working registers are mapped in as the first 32 data memory addresses (000016–001F16), followed by 64 I/O registers (002016–005F16). In devices with many peripherals, these registers are followed by 160 “extended I/O” registers, only accessible as memory-mapped I/O (006016–00FF16).

Actual SRAM starts after these register sections, at address 006016 or, in devices with "extended I/O", at 010016.

Even though there are separate addressing schemes and optimized opcodes for accessing the register file and the first 64 I/O registers, all can also be addressed and manipulated as if they were in SRAM.

The very smallest of the tinyAVR variants use a reduced architecture with only 16 registers (r0 through r15 are omitted) which are not addressable as memory locations. I/O memory begins at address 000016, followed by SRAM. In addition, these devices have slight deviations from the standard AVR instruction set. Most notably, the direct load/store instructions (LDS/STS) have been reduced from 2 words (32 bits) to 1 word (16 bits), limiting the total direct addressable memory (the sum of both I/O and SRAM) to 128 bytes. Conversely, the indirect load instruction's (LD) 16-bit address space is expanded to also include non-volatile memory such as Flash and configuration bits; therefore, the Load Program Memory (LPM) instruction is unnecessary and omitted. (For detailed info, see Atmel AVR instruction set.)

In the XMEGA variant, the working register file is not mapped into the data address space; as such, it is not possible to treat any of the XMEGA's working registers as though they were SRAM. Instead, the I/O registers are mapped into the data address space starting at the very beginning of the address space. Additionally, the amount of data address space dedicated to I/O registers has grown substantially to 4096 bytes (000016–0FFF16). As with previous generations, however, the fast I/O manipulation instructions can only reach the first 64 I/O register locations (the first 32 locations for bitwise instructions). Following the I/O registers, the XMEGA series sets aside a 4096 byte range of the data address space, which can be used optionally for mapping the internal EEPROM to the data address space (100016–1FFF16). The actual SRAM is located after these ranges, starting at 200016.

General-purpose input/output (GPIO) ports

[edit]

Each GPIO port on a tiny or mega AVR drives up to eight pins and is controlled by three 8-bit registers: DDRx, PORTx and PINx, where x is the port identifier.

  • DDRx: Data Direction Register, configures the pins as either inputs or outputs.
  • PORTx: Output port register. Sets the output value on pins configured as outputs. Enables or disables the pull-up resistor on pins configured as inputs.
  • PINx: Input register, used to read an input signal. On some devices, this register can be used for pin toggling: writing a logic one to a PINx bit toggles the corresponding bit in PORTx, irrespective of the setting of the DDRx bit.[10]

Newer ATtiny AVRs, like ATtiny817 and its siblings, have their port control registers somewhat differently defined. xmegaAVR have additional registers for push/pull, totem-pole and pullup configurations.

EEPROM

[edit]

Almost all AVR microcontrollers have internal EEPROM for semi-permanent data storage. Like flash memory, EEPROM can maintain its contents when electrical power is removed.

In most variants of the AVR architecture, this internal EEPROM memory is not mapped into the MCU's addressable memory space. It can only be accessed the same way an external peripheral device is, using special pointer registers and read/write instructions, which makes EEPROM access much slower than other internal RAM.

However, some devices in the SecureAVR (AT90SC) family[11] use a special EEPROM mapping to the data or program memory, depending on the configuration. The XMEGA family also allows the EEPROM to be mapped into the data address space.

Since the number of writes to EEPROM is limited – Atmel specifies 100,000 write cycles in their datasheets – a well designed EEPROM write routine should compare the contents of an EEPROM address with desired contents and only perform an actual write if the contents need to be changed.

Program execution

[edit]

Atmel's AVRs have a two-stage, single-level pipeline design, meaning that the next machine instruction is fetched as the current one is executing. Most instructions take just one or two clock cycles, making AVRs relatively fast among eight-bit microcontrollers.

The AVR processors were designed with the efficient execution of compiled C code in mind and have several built-in pointers for the task.

Instruction set

[edit]

The AVR instruction set is more orthogonal than those of most eight-bit microcontrollers, in particular the 8051 clones and PIC microcontrollers with which AVR has competed. However, it is not completely regular:

  • Pointer registers X, Y, and Z have addressing capabilities that are different from each other.
  • Register locations R0 to R15 have more limited addressing capabilities than register locations R16 to R31.
  • I/O ports 0 to 31 can be bit addressed, unlike I/O ports 32 to 63.
  • CLR (clear all bits to zero) affects flags, while SER (set all bits to one) does not, even though they are complementary instructions. (CLR is pseudo-op for EOR R, R; while SER is short for LDI R,$FF. Arithmetic operations such as EOR modify flags, while moves/loads/stores/branches such as LDI do not.)
  • Accessing read-only data stored in the program memory (flash) requires special LPM instructions; the flash bus is otherwise reserved for instruction memory.

Some chip-specific differences affect code generation. Code pointers (including return addresses on the stack) are two bytes long on chips with up to 128 KB of flash memory, but three bytes long on larger chips; not all chips have hardware multipliers; chips with over 8 KB of flash have branch and call instructions with longer ranges; and so forth.

The mostly regular instruction set makes C (and even Ada) compilers fairly straightforward and efficient. GCC has included AVR support for quite some time, and that support is widely used. LLVM also has rudimentary AVR support. In fact, Atmel solicited input from major developers of compilers for small microcontrollers, to determine the instruction set features that were most useful in a compiler for high-level languages.[8]

MCU speed

[edit]

The AVR line can normally support clock speeds from 0 to 20 MHz, with some devices reaching 32 MHz. Lower-powered operation usually requires a reduced clock speed. All recent (Tiny, Mega, and Xmega, but not 90S) AVRs feature an on-chip oscillator, removing the need for external clocks or resonator circuitry. Some AVRs also have a system clock prescaler that can divide down the system clock by up to 1024. This prescaler can be reconfigured by software during run-time, allowing the clock speed to be optimized.

Since all operations (excluding multiplication and 16-bit add/subtract) on registers R0–R31 are single-cycle, the AVR can achieve up to 1 MIPS per MHz, i.e. an 8 MHz processor can achieve up to 8 MIPS. Loads and stores to/from memory take two cycles, branching takes two cycles. Branches in the latest "3-byte PC" parts such as ATmega2560 are one cycle slower than on previous devices.

Development

[edit]

AVRs have a large following due to the free and inexpensive development tools available, including reasonably priced development boards and free development software. The AVRs are sold under various names that share the same basic core, but with different peripheral and memory combinations. Compatibility between chips in each family is fairly good, although I/O controller features may vary.

The Atmel AVR GNU C/C++ cross compiler, "avr-gcc" and "avr-g++", is used in both WinAVR and Atmel Studio.[12][13][14][15][16] The Arduino team borrowed from WinAVR for the Windows version of the Arduino software.[17]

See external links for sites relating to AVR development.

Features

[edit]

AVRs offer a wide range of features:

  • Multifunction, bi-directional general-purpose I/O ports with configurable, built-in pull-up resistors
  • Multiple internal oscillators, including RC oscillator without external parts
  • Internal, self-programmable instruction flash memory up to 256 KB (384 KB on XMega)
    • In-system programmable using serial/parallel low-voltage proprietary interfaces or JTAG
    • Optional boot code section with independent lock bits for protection
  • On-chip debugging (OCD) support through JTAG or debugWIRE on most devices
    • The JTAG signals (TMS, TDI, TDO, and TCK) are multiplexed on GPIOs. These pins can be configured to function as JTAG or GPIO depending on the setting of a fuse bit, which can be programmed via in-system programming (ISP) or HVSP. By default, AVRs with JTAG come with the JTAG interface enabled.
    • debugWIRE uses the /RESET pin as a bi-directional communication channel to access on-chip debug circuitry. It is present on devices with lower pin counts, as it only requires one pin.
  • Internal data EEPROM up to 4 KB
  • Internal SRAM up to 16 KB (32 KB on XMega)
  • External 64 KB little endian data space on certain models, including the Mega8515 and Mega162.
    • The external data space is overlaid with the internal data space, such that the full 64 KB address space does not appear on the external bus and accesses to e.g. address 010016 will access internal RAM, not the external bus.
    • In certain members of the XMega series, the external data space has been enhanced to support both SRAM and SDRAM. As well, the data addressing modes have been expanded to allow up to 16 MB of data memory to be directly addressed.
  • 8-bit and 16-bit timers
    • PWM output (some devices have an enhanced PWM peripheral which includes a dead-time generator)
    • Input capture that record a time stamp triggered by a signal edge
  • analog comparator
  • 10 or 12-bit A/D converters, with multiplex of up to 16 channels
  • 12-bit D/A converters
  • A variety of serial interfaces, including
  • Brownout detection
  • Watchdog timer (WDT)
  • Multiple power-saving sleep modes
  • Lighting and motor control (PWM-specific) controller models
  • CAN controller support
  • USB controller support
    • Proper full-speed (12 Mbit/s) hardware & Hub controller with embedded AVR.
    • Also freely available low-speed (1.5 Mbit/s) (HID) bitbanging software emulations
  • Ethernet controller support
  • LCD controller support
  • Low-voltage devices operating down to 1.8 V (to 0.7 V for parts with built-in DC–DC upconverter)
  • picoPower devices
  • DMA controllers and "event system" peripheral communication.
  • Fast cryptography support for AES and DES

Programming interfaces

[edit]

There are many means to load program code into an AVR chip. The methods to program AVR chips varies from AVR family to family. Most of the methods described below use the RESET line to enter programming mode. In order to avoid the chip accidentally entering such mode, it is advised to connect a pull-up resistor between the RESET pin and the positive power supply.[22]

ISP

[edit]
6- and 10-pin ISP header diagrams

The in-system programming (ISP) programming method is functionally performed through SPI, plus some twiddling of the Reset line. As long as the SPI pins of the AVR are not connected to anything disruptive, the AVR chip can stay soldered on a PCB while reprogramming. All that is needed is a 6-pin connector and programming adapter. This is the most common way to develop with an AVR.

The Atmel-ICE device or AVRISP mkII (Legacy device) connects to a computer's USB port and performs in-system programming using Atmel's software.

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

PDI

[edit]

The Program and Debug Interface (PDI) is an Atmel proprietary interface for external programming and on-chip debugging of XMEGA devices. The PDI supports high-speed programming of all non-volatile memory (NVM) spaces; flash, EEPROM, fuses, lock-bits and the User Signature Row. This is done by accessing the XMEGA NVM controller through the PDI interface, and executing NVM controller commands. The PDI is a 2-pin interface using the Reset pin for clock input (PDI_CLK) and a dedicated data pin (PDI_DATA) for input and output.[24]

UPDI

[edit]

The Unified Program and Debug Interface (UPDI) is a one-wire interface for external programming and on-chip debugging of newer ATtiny and ATmega devices. UPDI chips can be programmed by an Atmel-ICE, a PICkit 4, an Arduino (flashed with jtag2updi),[25] or though a UART (with a 1 kΩ resistor between the TX and RX pins) controlled by Microchip's Python utility pymcuprog.[26]

High-voltage serial

[edit]

High-voltage serial programming (HVSP)[27] is mostly the backup mode on smaller AVRs. An 8-pin AVR package does not leave many unique signal combinations to place the AVR into a programming mode. A 12-volt signal, however, is something the AVR should only see during programming and never during normal operation. The high voltage mode can also be used in some devices where the reset pin was disabled by fuses.

High-voltage parallel

[edit]

High-voltage parallel programming (HVPP) is considered the "final resort" and may be the only way to correct bad fuse settings on an AVR chip.

Bootloader

[edit]

Most AVR models can reserve a bootloader region, 256 bytes to 4 KB, where re-programming code can reside. At reset, the bootloader runs first and does some user-programmed determination whether to re-program or to jump to the main application. The code can re-program through any interface available, or it could read an encrypted binary through an Ethernet adapter like PXE. Atmel has application notes and code pertaining to many bus interfaces.[28][29][30][31]

ROM

[edit]

The AT90SC series of AVRs are available with a factory mask-ROM for program memory, instead of flash.[32] Because of the large up-front cost and minimum order quantity, a mask-ROM is only cost-effective for high-production runs.

aWire

[edit]

aWire is a new one-wire debug interface available on the new UC3L AVR32 devices.

Debugging interfaces

[edit]

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

debugWIRE

[edit]

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

JTAG

[edit]

The Joint Test Action Group (JTAG) feature provides access to on-chip debugging functionality while the chip is running in the target system.[33] 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:

  1. The Atmel-ICE[34] is the latest adapter. It supports JTAG, debugWire, aWire, SPI, TPI, and PDI interfaces.
  2. The JTAGICE 3[35] is a midrange debugger in the JTAGICE family (JTAGICE mkIII). It supports JTAG, aWire, SPI, and PDI interfaces.
  3. The JTAGICE mkII[36] 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. Numerous third-party clones of the Atmel JTAGICE mkII device started shipping after Atmel released the communication protocol.[37]
  4. The AVR Dragon[38] 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. ATMEL changed the debugging feature of AVR Dragon with the latest firmware of AVR Studio 4 – AVR Studio 5 and now it supports devices over 32 KB of program memory.
  5. The JTAGICE adapter interfaces to the PC via a standard serial port.[39] Although the JTAGICE adapter has been declared "end-of-life" by Atmel, it is still supported in AVR Studio and other tools.

JTAG can also be used to perform a boundary scan test,[40] 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, while the hobbyist is probably better off testing with a multimeter or oscilloscope.

Development tools and evaluation kits

[edit]
Atmel STK500 development board

Official Atmel AVR development tools and evaluation kits contain a number of starter kits and debugging tools with support for most AVR devices:

STK600 starter kit

[edit]

The STK600 starter kit and development system is an update to the STK500.[41] The STK600 uses a base board, a signal routing board, and a target board.

The base board is similar to the STK500, in that it provides a power supply, clock, in-system programming, an RS-232 port and a CAN (Controller Area Network, an automotive standard) port via DE9 connectors, and stake pins for all of the GPIO signals from the target device.

The target boards have ZIF sockets for DIP, SOIC, QFN, or QFP packages, depending on the board.

The signal routing board sits between the base board and the target board, and routes the signals to the proper pin on the device board. There are many different signal routing boards that could be used with a single target board, depending on what device is in the ZIF socket.

The STK600 allows in-system programming from the PC via USB, leaving the RS-232 port available for the target microcontroller. A 4 pin header on the STK600 labeled 'RS-232 spare' can connect any TTL level USART port on the chip to an onboard MAX232 chip to translate the signals to RS-232 levels. The RS-232 signals are connected to the RX, TX, CTS, and RTS pins on the DB-9 connector.

STK500 starter kit

[edit]

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

STK500 Expansion Modules: Several expansion modules are available for the STK500 board:

  • 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, and 32-pin microcontrollers from the AT90PWM and ATmega family.
  • STK524 – Adds support for the ATmega32M1/C1 32-pin CAN/LIN/Motor Control family.
  • STK525 – Adds support for the AT90USB microcontrollers in 64-pin TQFP packages.
  • STK526 – Adds support for the AT90USB microcontrollers in 32-pin TQFP packages.

STK200 starter kit

[edit]

The STK200 starter kit and development system has a DIP socket that can host an AVR chip in a 40, 20, or 8-pin package. The board has a 4 MHz clock source, 8 light-emitting diode (LED)s, 8 input buttons, an RS-232 port, a socket for a 32 KB SRAM and numerous general I/O. The chip can be programmed with a dongle connected to the parallel port.

Supported microcontrollers (according to the manual)
Chip Flash size EEPROM SRAM Frequency
[MHz]
Package
AT90S1200 1 KB 64 B 0 B 12 PDIP-20
AT90S2313 2 KB 128 B 128 B 10 PDIP-20
AT90S/LS2323 2 KB 128 B 128 B 10 PDIP-8
AT90S/LS2343 2 KB 128 B 128 B 10 PDIP-8
AT90S4414 4 KB 256 B 256 B 8 PDIP-40
AT90S/LS4434 4 KB 256 B 256 B 8 PDIP-40
AT90S8515 8 KB 512 B 512 B 8 PDIP-40
AT90S/LS8535 8 KB 512 B 512 B 8 PDIP-40

Atmel-ICE

[edit]

The Atmel ICE is the currently supported inexpensive tool to program and debug all AVR devices (unlike the AVRISP/AVRISP mkII, Dragon, etc. discussed below). It connects to and receives power from a PC via USB, and supports JTAG, PDI, aWire, debugWIRE, SPI, SWD, TPI, and UPDI (the Microchip Unified Program and Debug Interface) interfaces.

The ICE can program and debug all AVRs via the JTAG interface, and program with additional interfaces as supported on each device:

  • 8-bit AVR XMEGA devices via the PDI 2-wire interface
  • 8-bit megaAVR and tinyAVR devices via SPI for all with OCD (on-chip debugger) support
  • 8-bit tinyAVR microcontrollers with TPI support
  • 32-bit SAM Arm Cortex-M based microcontrollers via SWD

Target operating voltage ranges of 1.62V to 5.5V are supported as well as the following clock ranges:

  • Supports JTAG & PDI clock frequencies from 32 kHz to 7.5 MHz
  • Supports aWire baud rates from 7.5 kbit/s to 7 Mbit/s
  • Supports debugWIRE baud rates from 4 kbit/s to 0.5 Mbit/s
  • Supports SPI clock frequencies from 8 kHz to 5 MHz
  • Supports SWD clock frequencies from 32 kHz to 2 MHz

The ICE is supported by the Microchip Studio IDE, as well as a command line interface (atprogram).

The Atmel-ICE supports a limited implementation of the Data Gateway Interface (DGI) when debugging and programming features are not in use. The Data Gateway Interface is an interface for streaming data from a target device to the connected computer. This is meant as a useful adjunct to the unit to allow for demonstration of application features and as an aid in application level debugging.

AVRISP and AVRISP mkII

[edit]
AVRISP mkII

The AVRISP and AVRISP mkII are inexpensive tools allowing all AVRs to be programmed via ICSP.

The AVRISP connects to a PC via a serial port and draws power from the target system. The AVRISP allows using either of the "standard" ICSP pinouts, either the 10-pin or 6-pin connector.

The AVRISP mkII connects to a PC via USB and draws power from USB. LEDs visible through the translucent case indicate the state of target power.

As the AVRISP mkII lacks driver/buffer ICs,[42] it can have trouble programming target boards with multiple loads on its SPI lines. In such occurrences, a programmer capable of sourcing greater current is required. Alternatively, the AVRISP mkII can still be used if low-value (~150 ohm) load-limiting resistors can be placed on the SPI lines before each peripheral device.

Both the AVRISP and the AVRISP mkII are now discontinued, with product pages removed from the Microchip website. As of July 2019 the AVRISP mkII is still in stock at a number of distributors. There are also a number of 3rd party clones available.

AVR Dragon

[edit]
AVR Dragon with ISP programming cable and attached, blue/greenish ZIF Socket

The Atmel Dragon is an inexpensive tool which connects to a PC via USB. The Dragon can program all AVRs via JTAG, HVP, PDI,[43] or ICSP. The Dragon also allows debugging of all AVRs via JTAG, PDI, or debugWire; a previous limitation to devices with 32 KB or less program memory has been removed in AVR Studio 4.18.[44] The Dragon has a small prototype area which can accommodate an 8, 28, or 40-pin AVR, including connections to power and programming pins. There is no area for any additional circuitry, although this can be provided by a third-party product called the "Dragon Rider".[45]

JTAGICE

[edit]

The JTAG In Circuit Emulator (JTAGICE) debugging tool supports on-chip debugging (OCD) of AVRs with a JTAG interface. The original JTAGICE (sometimes retroactively referred to as JTAGICE mkI) uses an RS-232 interface to a PC and can only program AVRs with a JTAG interface. The JTAGICE mkI is no longer in production, however it has been replaced by the JTAGICE mkII.

JTAGICE mkII

[edit]

The JTAGICE mkII debugging tool supports on-chip debugging (OCD) of AVRs with SPI, JTAG, PDI, and debugWIRE interfaces. The debugWire interface enables debugging using only one pin (the Reset pin), allowing debugging of applications running on low pin-count microcontrollers.

The JTAGICE mkII connects using USB, but there is an alternate connection via a serial port, which requires using a separate power supply. In addition to JTAG, the mkII supports ISP programming (using 6-pin or 10-pin adapters). Both the USB and serial links use a variant of the STK500 protocol.

JTAGICE3

[edit]

The JTAGICE3 updates the mkII with more advanced debugging capabilities and faster programming. It connects via USB and supports the JTAG, aWire, SPI, and PDI interfaces.[46] The kit includes several adapters for use with most interface pinouts.

AVR ONE!

[edit]

The AVR ONE! is a professional development tool for all Atmel 8-bit and 32-bit AVR devices with On-Chip Debug capability. It supports SPI, JTAG, PDI, and aWire programming modes and debugging using debugWIRE, JTAG, PDI, and aWire interfaces.[47]

Butterfly demonstration board

[edit]
Atmel ATmega169 in 64-pad MLF package on the back of an Atmel AVR Butterfly board

The very popular AVR Butterfly demonstration board is a self-contained, battery-powered computer running the Atmel AVR ATmega169V microcontroller. It was built to show off the AVR family, especially a then new built-in LCD interface. The board includes the LCD screen, joystick, speaker, serial port, real time clock (RTC), flash memory chip, and both temperature and voltage sensors. Earlier versions of the AVR Butterfly also contained a CdS photoresistor; it is not present on Butterfly boards produced after June 2006 to allow RoHS compliance.[48] The small board has a shirt pin on its back so it 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. The AVR Butterfly also has a piezoelectric transducer that can be used to reproduce sounds and music.

The AVR Butterfly demonstrates LCD driving by running a 14-segment, six 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, but 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 via a standard RS-232 serial plug with new programs that users can write with the free Atmel IDE tools.

AT90USBKey

[edit]

This small board, about half the size of a business card, is priced at slightly more than an AVR Butterfly. It includes an AT90USB1287 with USB On-The-Go (OTG) support, 16 MB of DataFlash, LEDs, a small joystick, and a temperature sensor. The board includes software, which lets it act as a USB mass storage device (its documentation is shipped on the DataFlash), a USB joystick, and more. To support the USB host capability, it must be operated from a battery, but when running as a USB peripheral, it only needs the power provided over USB.

Only the JTAG port uses conventional 2.54 mm pinout. All the other AVR I/O ports require more compact 1.27 mm headers.

The AVR Dragon can both program and debug since the 32 KB limitation was removed in AVR Studio 4.18, and the JTAGICE mkII is capable of both programming and debugging the processor. The processor can also be programmed through USB from a Windows or Linux host, using the USB "Device Firmware Update" protocols. Atmel ships proprietary (source code included but distribution restricted) example programs and a USB protocol stack with the device.

LUFA[49] is a third-party free software (MIT license) USB protocol stack for the USBKey and other 8-bit USB AVRs.

Raven wireless kit

[edit]

The RAVEN kit supports wireless development using Atmel's IEEE 802.15.4 chipsets, for Zigbee and other wireless stacks. It resembles a pair of wireless more-powerful Butterfly cards, plus a wireless USBKey; and costing about that much (under $US100). All these boards support JTAG-based development.

The kit includes two AVR Raven boards, each with a 2.4 GHz transceiver supporting IEEE 802.15.4 (and a freely licensed Zigbee stack). The radios are driven with ATmega1284p processors, which are supported by a custom segmented LCD driven by an ATmega3290p processor. Raven peripherals resemble the Butterfly: piezo speaker, DataFlash (bigger), external EEPROM, sensors, 32 kHz crystal for RTC, and so on. These are intended for use in developing remote sensor nodes, to control relays, or whatever is needed.

The USB stick uses an AT90USB1287 for connections to a USB host and to the 2.4 GHz wireless links. These are intended to monitor and control the remote nodes, relying on host power rather than local batteries.

Third-party programmers

[edit]

A wide variety of third-party programming and debugging tools are available for the AVR. These devices use various interfaces, including RS-232, PC parallel port, and USB.[50]

Uses

[edit]
Atmel AVR ATmega328 28-pin DIP on an Arduino Duemilanove board
Atmel AVR ATmega8 28-pin DIP on a custom development board

AVRs have been used in various automotive applications such as security, safety, powertrain and entertainment systems. Atmel has recently launched a new publication "Atmel Automotive Compilation" to help developers with automotive applications. Some current usages are in BMW, Daimler-Chrysler and TRW.

The Arduino physical computing platform is based on an ATmega328 microcontroller (ATmega168 or ATmega8 in board versions older than the Diecimila). The ATmega1280 and ATmega2560, with more pinout and memory capabilities, have also been employed to develop the Arduino Mega platform. Arduino boards can be used with its language and IDE, or with more conventional programming environments (C, assembler, etc.) as just standardized and widely available AVR platforms.

USB-based AVRs have been used in the Microsoft Xbox hand controllers. The link between the controllers and Xbox is USB.

Numerous companies produce AVR-based microcontroller boards intended for use by hobbyists, robot builders, experimenters and small system developers including: Cubloc,[51] gnusb,[52] BasicX,[53] Oak Micros,[54] ZX Microcontrollers,[55] and myAVR.[56] There is also a large community of Arduino-compatible boards supporting similar users.

Schneider Electric used to produce the M3000 Motor and Motion Control Chip, incorporating an Atmel AVR Core and an advanced motion controller for use in a variety of motion applications but this has been discontinued.[57]

FPGA clones

[edit]

With the growing popularity of FPGAs among the open source community, people have started developing open source processors compatible with the AVR instruction set. The OpenCores website lists the following major AVR clone projects:

  • pAVR,[58] written in VHDL, is aimed at creating the fastest and maximally featured AVR processor, by implementing techniques not found in the original AVR processor such as deeper pipelining.
  • avr_core,[59] written in VHDL, is a clone aimed at being as close as possible to the ATmega103.
  • Navré,[60] written in Verilog, implements all Classic Core instructions and is aimed at high performance and low resource usage. It does not support interrupts.
  • softavrcore,[61] written in Verilog, implements the AVR instruction set up to AVR5, supports interrupts along with optional automatic interrupt acknowledgement, power saving via sleep mode plus some peripheral interfaces and hardware accelerators (such as UART, SPI, cyclic redundancy check calculation unit and system timers). These peripherals demonstrate how could these be attached to and configured for this core. Within the package, a full-featured FreeRTOS port is also available as an example for the core + peripheral utilization.
  • The opencores project CPU lecture[62] written in VHDL by Dr. Jürgen Sauermann explains in detail how to design a complete AVR-based system on a chip (SoC).

Other vendors

[edit]

In addition to the chips manufactured by Atmel, clones are available from LogicGreen Technologies.[63] These parts are not exact clones – they have a few features not found in the chips they are "clones" of, and higher maximum clock speeds, but use SWD (Serial Wire Debug, a variant of JTAG from ARM) instead of ISP for programming, so different programming tools must be used.

Microcontrollers using the ATmega architecture are being manufactured by NIIET in Voronezh, Russia, as part of the 1887 series of integrated circuits. This includes an ATmega128 under the designation 1887VE7T (Russian: 1887ВЕ7Т).[64]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
AVR microcontrollers are a family of 8-bit reduced instruction set computing (RISC)-based microcontrollers originally developed by Corporation in 1996 and acquired by in 2016, renowned for their high performance, low power consumption, and code efficiency in embedded applications. Featuring an advanced RISC architecture with up to 130 instructions that execute in a single clock cycle, AVR devices utilize a separating program and data memory for enhanced speed and efficiency. Microchip's AVR portfolio encompasses diverse families tailored to various needs, including the tinyAVR series for compact, low-power designs in and IoT devices; the megaAVR for general-purpose applications with higher pin counts and peripherals; and modern lines like AVR DA, DU, and DD that incorporate core-independent peripherals (CIPs) for autonomous operation, reducing CPU load in tasks such as and interfacing. Additionally, specialized variants like AVR SD provide hardware safety features compliant with ASIL C and SIL 2 standards for automotive and industrial safety-critical systems. These microcontrollers support a wide voltage range (typically 1.8V to 5.5V) and draw minimal current (as low as a few microamps in sleep modes), enabling battery-powered and energy-efficient deployments across sectors including industrial automation, home appliances, wearables, and connected devices. The AVR architecture's design emphasizes developer productivity, with optimized support for and assembly languages, allowing most instructions to complete in one cycle for up to 1 MIPS per MHz performance, and integrated tools like X IDE for seamless programming and debugging. Since their inception by engineers Alf-Egil Bogen and Vegard Wollan—whose initials inspired the "AVR" name—these microcontrollers have evolved to include advanced features such as event system crossbars for peripheral interconnectivity without CPU intervention, hardware cryptographic accelerators in select models, and compatibility with wireless connectivity modules for IoT ecosystems.

History

Origins and early development

The development of the AVR architecture began in 1996 at Corporation, spearheaded by engineers Alf-Egil Bogen and Vegard Wollan, who were students at the Norwegian University of Science and Technology. Their initiative addressed key limitations of prevailing 8-bit microcontrollers, such as the 8051, including poor performance, high power consumption, and inefficient instruction execution typical of CISC designs. The inaugural AVR device, the AT90S1200, was released by in 1997, featuring 1 KB of on-chip and a RISC-based instruction set that achieved superior code density compared to contemporaries. This design emphasized a , with distinct buses for program and data memory to support simultaneous access and enable single-level pipelined execution for enhanced throughput. A pivotal in the AT90S1200 was the integration of in-system programmable , which allowed direct reprogramming via serial interfaces without requiring external programmers or UV erasure, marking a shift from traditional or OTP ROM approaches. Subsequent milestones included the prototyping of the ATmega series in 1998, which expanded memory capacities up to 64 KB flash in early models like the ATmega603, and the full commercialization of the megaAVR line around 2000, broadening applications in embedded systems.

Evolution and acquisition by Microchip

In the early 2000s, expanded the AVR microcontroller lineup to address diverse application needs, introducing the tinyAVR family in 1999 specifically for low-pin-count devices in space-constrained designs such as sensors and small appliances. This series emphasized compact packaging and reduced complexity while maintaining the core AVR RISC architecture's efficiency. Later, in 2008, launched the XMEGA family, which incorporated advanced features like a (DMA) controller for efficient data handling and an event system enabling peripheral-to-peripheral communication without CPU intervention, enhancing performance in applications requiring real-time processing. In the mid-2000s, introduced 32-bit microcontrollers, aiming to extend the architecture into higher-performance segments with models like the UC3 series launched in , but ultimately discontinued the line in favor of adopting ARM-based processors for better ecosystem compatibility and market scalability. This shift reflected broader industry trends toward standardized 32-bit cores. In 2016, acquired for an equity value of approximately $3.56 billion, integrating the AVR portfolio alongside to create a comprehensive offering for embedded systems. The acquisition, completed in April 2016, enabled synergies in , distribution, and software tools, positioning AVR as a key asset in Microchip's expanded dominance. Post-acquisition, Microchip initiated rebranding and unification efforts in 2018, migrating AVR development support from Studio to the cross-platform MPLAB X Integrated Development Environment to streamline workflows across AVR, PIC, and other families. This unification included enhanced compiler integration and peripheral libraries, reducing development for engineers. In the , Microchip focused AVR advancements on ultra-low power consumption—such as sub-microampere sleep modes—and IoT compatibility, incorporating features like secure boot and protocol stacks to support connected edge devices in smart homes and industrial monitoring. A notable milestone came in 2024 with the AVR DU series, introducing integrated USB 2.0 for up to 15W power delivery and enhanced security in compact packages, followed by the 2025 AVR SD series, optimized for functional safety compliance under standards like ASIL C.

Families and variants

Core families and classifications

The AVR microcontrollers are organized into core families primarily distinguished by performance tiers, pin counts, memory capacities, architectural features, and intended applications, with the classic lineup encompassing the tinyAVR, megaAVR, XMEGA, and families. These classifications reflect a progression from entry-level devices optimized for minimal resource use to more advanced offerings with enhanced peripherals and processing capabilities, all generally operating within a supply voltage range of 1.8 V to 5.5 V. The 8-bit families (tinyAVR, megaAVR, and XMEGA) utilize a , featuring separate address spaces and buses for program memory (Flash) and data memory (SRAM/), which enables simultaneous access for improved efficiency over pure von Neumann designs. In contrast, the family introduced 32-bit processing but has since been discontinued, with no new developments after 2011. The tinyAVR family represents the lowest performance tier, targeting compact, cost-sensitive designs with limited I/O requirements, typically featuring 6 to 32 pins and up to 8 KB of Flash program memory alongside small amounts of SRAM (up to 1 KB) and (up to 512 bytes). These devices are well-suited for basic interfacing, simple control logic, and battery-powered applications where space and power constraints are paramount, such as in wearables or remote monitors. A representative example is the ATtiny85, which provides 8 pins, 8 KB Flash, 512 bytes SRAM, and 512 bytes in an 8-pin package, supporting up to 20 MHz operation at 5 V while maintaining low power consumption in active and sleep modes. In the mid-range performance tier, the megaAVR family offers greater versatility for general-purpose embedded systems, with pin counts from 28 to 100 and capacities ranging from 4 KB to 256 KB, complemented by up to 16 KB SRAM and 4 KB in larger variants. This family balances feature richness and efficiency, making it ideal for industrial automation, , and prototyping platforms like the , where multiple peripherals such as timers, ADCs, and communication interfaces are needed. For instance, the provides 32 pins, 32 KB Flash, 2 KB SRAM, and 1 KB , enabling robust I/O handling (up to 23 programmable pins) and operation up to 20 MHz across the full voltage range. The XMEGA family advances the 8-bit AVR lineup into a higher performance tier, incorporating sophisticated peripherals like DMA controllers, event systems for inter-peripheral communication, and optional cryptographic accelerators, with pin counts spanning 32 to 100 and Flash memory from 16 KB to 384 KB, paired with up to 32 KB SRAM and 4 KB EEPROM. These enhancements support demanding applications in motor control, power management, and connectivity-enabled devices requiring real-time processing and reduced CPU intervention. The ATxmega128A1 exemplifies this, offering 64 pins, 128 KB Flash, 8 KB SRAM, and 2 KB EEPROM, along with 12-bit ADC/DAC, multiple UARTs/SPI/I2C, and DMA for efficient data handling at up to 32 MHz. The AVR32 family diverged from the 8-bit cores as a 32-bit superscalar RISC architecture, supporting up to 512 KB Flash, 128 KB SRAM, and pin counts from 64 to 144, targeted at processing, USB hosting, and high-integration embedded systems emphasizing low power and cost efficiency. Featuring a five-stage , SIMD instructions, and hardware acceleration in some variants, it aimed to bridge and capabilities but was phased out post-2011 in favor of ARM-based alternatives.

Recent developments and new series

In 2020, Microchip introduced the AVR DA family, which incorporates an advanced event system for efficient peripheral communication without CPU intervention, a real-time counter (RTC), and operation up to 24 MHz with up to 128 KB of , making it suitable for real-time control applications and capacitive touch interfaces. In 2020, the AVR DB family was also launched, offering similar low-power performance to the DA series but with enhanced analog features like op-amps and higher pin counts in some variants, up to 64 KB Flash and 16 KB SRAM, targeted at industrial control and home appliances requiring precise analog interfacing. The AVR DD family, launched in , builds on this with enhanced core-independent peripherals including multi-voltage I/O (MVIO) for flexible interfacing, an internal PLL enabling up to 48 MHz for specific timers, and up to 64 KB of , targeting applications like that require precise timing and power domain management. In 2023, the AVR EA series emerged with a focus on integrated analog features such as a 12-bit ADC, 10-bit DAC, and core-independent peripherals optimized for closed-loop control systems, supporting up to 20 MHz operation and 64 KB of Flash memory in compact packages for space-constrained designs. Microchip's 2024 AVR DU family integrates full-speed USB 2.0 connectivity with secure boot mechanisms and support for up to 15 W power delivery via USB, enabling development of human interface devices (HID) and communication device class (CDC) peripherals, while maintaining 24 MHz CPU speed and up to 64 KB of Flash. The AVR SD series, released in Q1 2025, introduces dual-core lockstep architecture for compliance with ASIL C and SIL 2 standards, achieving sub-$1 pricing in volume for automotive and industrial applications requiring high reliability and low cost. These developments reflect broader trends in AVR evolution toward nanoWatt-level power efficiency, native USB integration for IoT edge devices, and built-in features to meet automotive and industrial standards, extending the platform's relevance beyond classic families like megaAVR.

Architecture

Core processor design

The 8-bit AVR core is a (RISC) processor designed for high performance and low power consumption in embedded applications. It features a compact optimized for efficient code execution, with most operations performed directly on hardware registers to minimize memory access overhead. This design enables the core to achieve up to 1 MIPS per MHz, making it suitable for real-time control tasks. Central to the 8-bit AVR core are 32 general-purpose 8-bit working registers, labeled R0 through R31, which serve as the primary data storage for computations and are directly connected to the (ALU) for single-cycle operations. Among these, the pairs R26-R27 (X-register), R28-R29 (Y-register), and R30-R31 (Z-register) can be concatenated to form 16-bit address pointers for indirect addressing, facilitating efficient manipulation in program and SRAM. The core employs a , which separates program access via a 16-bit program bus from access via an 8-bit bus; this allows simultaneous instruction fetch and execution, enhancing throughput without the bottlenecks of von Neumann designs. Instruction execution in the 8-bit AVR core utilizes a two-stage consisting of fetch and execute phases, enabling most of the 130+ instructions to complete in a single clock cycle through parallel ALU operations on register operands. Exceptions include the 32-bit unsigned multiply instruction (MUL), which requires two cycles to produce a 16-bit result stored across registers R0 and R1. The stack is implemented as a software-managed LIFO structure in SRAM, with the 16-bit stack pointer (SP) residing in the I/O register space and pointing to the top of RAM; there is no dedicated hardware stack, requiring explicit initialization by the . latency is fixed at four clock cycles, comprising the completion of the current instruction, saving the return address to the stack, and jumping to the interrupt vector. To support low-power operation, the 8-bit AVR core includes several power-saving modes, such as Idle mode, where the CPU is halted while peripherals and the clock continue running, allowing quick resumption of execution upon . In Power-down mode, the core and most peripherals are shut off, with only the external reset and brown-out detection remaining active to prevent erratic behavior from voltage drops. Brown-out detection (BOD) is an that monitors the supply voltage (VCC) and triggers a reset if it falls below a programmable threshold, typically 1.8V to 4.0V, ensuring reliable operation in battery-powered systems.

32-bit processor design

The 32-bit AVR microcontrollers are based on the architecture, a high-performance 32-bit RISC load/store design for embedded applications emphasizing low power consumption. It features up to 32 general-purpose 32-bit registers (R0-R31), a 5-stage (fetch, decode, execute, , writeback) achieving 1 instruction per clock cycle for most operations, and variable-length instructions (16/32-bit) for high code density. The architecture supports advanced features including a (MPU) with 8 regions, SIMD extensions, branch prediction, and a prioritized event system for low-latency interrupts. AVR32 uses a flat 32-bit up to 4 GB, with optional MMU in some implementations.

Memory and storage organization

AVR microcontrollers employ a Harvard architecture with distinct memory spaces for program and data, enabling parallel access for improved performance. The primary non-volatile program memory is implemented as in-system self-programmable Flash, organized in 16-bit words to accommodate instructions that are either 16 or 32 bits wide. This Flash memory supports byte-addressability through word-aligned access, where the program counter (PC) treats addresses as bytes but fetches instructions in 16-bit increments. In classic 8-bit AVR devices, the PC is 16 bits wide, limiting the addressable program space to 64 kilobytes (32K words), though modern variants like the megaAVR series extend this to 256 kilobytes via additional addressing mechanisms. Self-programming is facilitated by the Store Program Memory (SPM) instruction, which allows the CPU to erase and write Flash pages (typically 64 to 512 bytes) from within application code, enabling features like bootloaders without external hardware. Data in AVR consists of static RAM (SRAM), which serves as the volatile storage for variables, stack, and temporary data, unified under a single linear starting from 0x0000. This space includes the 32 general-purpose registers (mapped to addresses 0x00-0x1F), I/O registers (0x20-0x5F), extended I/O (if present), and internal SRAM, with the stack pointer configurable within the SRAM region for function calls and interrupts. Typical SRAM sizes range from 128 bytes in tinyAVR devices to 8 kilobytes in larger megaAVR models, though modern DB-series AVRs reach 16 kilobytes. Addressing modes for data include direct (immediate 16-bit address), indirect (via X, Y, or Z pointers), indirect with displacement (offset up to 63 bytes), and indirect with pre-decrement or post-increment, providing flexible access without memory-mapped I/O in classic AVRs—though XMEGA and later series introduce extended I/O mapping for larger spaces. Non-volatile data storage is provided by a separate space, typically ranging from 128 bytes to 4 kilobytes depending on the device family, such as 512 bytes in ATmega328P or 4 kilobytes in ATmega128. This memory is accessed through dedicated registers (EEAR for address, EEDR for data, EECR for control) and special instructions like EEWrite and EERead, ensuring atomic operations with write protection. Unlike Flash, EEPROM supports byte-level granularity and higher endurance (up to 100,000 write/erase cycles), making it suitable for persistent settings. Program memory addressing uses the 16-bit Z-register as a byte pointer, where the least significant bit selects the low or high byte of a word, while data addressing leverages 16-bit pointers for the full SRAM space in classic devices; XMEGA extends this with 24-bit data addressing for larger SRAM. Configuration settings, including clock source selection, brown-out detection, and bootloader enabling, are managed via fuse bits stored in a dedicated section of the . These fuses are one-time programmable (with limited reprogramming in some cases) and organized into bytes (e.g., high, low, and extended fuse bytes), read via the same SPM mechanism used for Flash programming. Lock bits, also in Flash, complement fuses by restricting external access to memory for security.
Memory TypeOrganizationTypical Size RangeAccess MethodEndurance
Program (Flash)16-bit words, byte-addressable4 KB–256 KB (8-bit AVR)SPM instruction for self-programming; LPM for reads10,000 cycles
Data (SRAM)Linear byte-addressable space128 B–16 KBDirect/indirect modes via CPU pointersVolatile
EEPROMByte-addressable non-volatile128 B–4 KBDedicated registers/instructions (EEAR, EECR)100,000 cycles
Fuses/Lock BitsBits in Flash section1–3 bytesSPM for programming/readingOne-time programmable

Input/output and peripherals

AVR microcontrollers feature (GPIO) ports for interfacing with external devices, with configurations supporting up to eight ports labeled PORTA through PORTH, each managing eight individual pins. Each port is controlled by three 8-bit registers: the Data Direction Register (DDRx) to set pin direction as input or output, the PORTx register to write output values or enable internal pull-up resistors for inputs, and the PINx register to read input states. Pins in input mode can activate optional pull-up resistors to prevent floating states, and many devices support pin change interrupts to detect transitions on any pin within a port, enabling efficient event-driven responses. Timer/counters in AVR devices provide versatile timekeeping and signal generation functions, including both 8-bit and 16-bit variants capable of operating in modes such as normal count, clear timer on compare (CTC), fast PWM, and phase-correct PWM for or output. These timers support programmable prescalers derived from the system clock, input capture for measuring pulse widths, and overflow or compare-match interrupts; in certain tinyAVR models, 16-bit timers can run asynchronously using an external 32.768 kHz for low-power applications like real-time clocks. Communication peripherals in AVR microcontrollers facilitate serial data exchange, with the Universal Synchronous/Asynchronous Receiver/Transmitter (USART) enabling full-duplex operation at configurable baud rates, supporting asynchronous modes with parity and stop bits or synchronous master/slave configurations. The supports high-speed, full-duplex synchronous communication in master or slave mode, using separate lines for clock, data in/out, and to connect multiple slaves. The Two-Wire Interface (TWI), compatible with the protocol, allows multi-master bus and addressing for connecting sensors and memory devices; advanced families like XMEGA include controllers to offload CPU during data transfers across these interfaces. Analog peripherals include a 10-bit successive approximation (ADC) with up to 12 multiplexed channels for single-ended or differential measurements, featuring programmable gain, internal voltage references, and conversion rates up to 15 ksps, often with modes to enhance accuracy by halting the CPU during sampling. Select models incorporate an 8-bit (DAC) for waveform generation and analog comparators to monitor voltage levels against references, triggering interrupts on threshold crossings. Additional peripherals encompass the , an independent 8-bit counter clocked by an internal RC oscillator that resets the if not periodically cleared by software, promoting system reliability in fault-tolerant applications. Modern AVR series, such as megaAVR 0-series and tinyAVR 1-series, integrate a real-time counter (RTC) driven by a 32.768 kHz watch crystal or internal oscillator, supporting periodic interrupts and alarm functions while operating in low-power sleep modes.

Instruction set and execution

Instruction set architecture

The AVR family includes 8-bit and 32-bit microcontrollers. The 8-bit devices use the following RISC ISA, while 32-bit devices employ a separate 32-bit RISC instruction set with different instructions and addressing. The AVR (ISA) for 8-bit devices is a reduced instruction set computing (RISC) design featuring over 130 instructions, most of which execute in a single clock cycle to enable efficient performance in embedded applications. This ISA emphasizes simplicity and , with instructions grouped into categories such as arithmetic and logic operations, , branching and , and data transfer, all tailored to support compact code generation. Arithmetic instructions include operations like ADD (add without carry), SUB (subtract without borrow), ADIW (add immediate to word), and MUL (multiply unsigned), which perform 8-bit or 16-bit computations on registers while updating status flags such as carry, zero, and sign. Logical instructions encompass AND, OR, (exclusive OR), and COM (one's complement), enabling bitwise manipulation for tasks like masking and toggling bits in registers. Bit operations provide direct access to individual I/O register bits via instructions such as SBI (set bit in I/O register) and CBI (clear bit in I/O register), along with testing instructions like SBIC (skip if bit in I/O register is cleared) and BRBS (branch if status flag set). Branching supports conditional and unconditional jumps, including RJMP (relative jump), BRNE (branch if not equal), and IJMP (indirect jump), facilitating efficient program flow control without the overhead of complex decoding. Data transfer instructions operate exclusively through the 32 general-purpose registers, adhering to a load-store model that prohibits direct memory-to-memory operations; examples include MOV (move between registers), LDI (load immediate into register), LD (load from space to register), and ST (store from register to space). is managed by subroutine instructions like CALL (call subroutine) and RET (return from subroutine), as well as power management commands such as SLEEP (enter ) and WDR (watchdog reset). The ISA supports several addressing modes to balance flexibility and efficiency: register-direct for operations between registers (e.g., ADD Rd, Rr); immediate for constant loading (e.g., LDI Rd, K where K is an 8-bit constant); data indirect for pointer-based access (e.g., LD Rd, X using register pair X as the address); indirect with displacement (e.g., LDD Rd, Y+q where q is a 6-bit offset from 0 to 63); and indirect with pre- or post-increment/decrement (e.g., LD Rd, X+). Program memory addressing includes direct (for short jumps) and indirect modes, with no support for immediate addressing in program space to maintain the separation. Instructions vary in length for optimal code density, with most encoded in 16 bits (2 bytes) and a subset—such as long jumps (JMP) and calls (CALL)—requiring 32 bits (4 bytes), allowing the ISA to achieve compact binaries suitable for flash-limited devices. This design is specifically tuned for efficient execution of code generated by compilers, incorporating instructions like MOVW (move word) and 16-bit arithmetic to minimize instruction count in compiled programs.

Program execution model

The AVR microcontroller employs a two-stage for program execution, consisting of an instruction fetch stage from program memory and an execution stage involving the (ALU) and registers. This design allows the fetch of the next instruction to occur simultaneously with the execution of the current one, enabling most instructions to complete in a single clock cycle via the single-cycle ALU. However, pipeline stalls occur on changes such as branches, where the fetched instruction is discarded, resulting in an additional cycle for resolution. Program execution begins at the reset vector located at address 0x0000 in program memory, where the AVR core initializes I/O registers to their default values before jumping to the main application code via an absolute or relative jump instruction. The boot process is configurable through fuse bits, such as BOOTRST, which can redirect the reset vector to the start of a reserved boot loader section in Flash memory for self-programming or alternative boot mechanisms. Interrupt vectors follow immediately after the reset vector in low program memory, with their placement adjustable via the IVSEL bit in the MCU control register to the boot section if needed. Interrupts are handled by saving the return address on the stack, clearing the global interrupt enable bit (I-bit) in the (SREG), and jumping to the corresponding vector address. The I-bit must be set in SREG to enable globally, after which individual peripheral interrupts can be unmasked. Upon completing the service routine with a return-from-interrupt instruction (RETI), the I-bit is automatically restored, allowing normal execution to resume. Clock domains in the AVR separate the CPU clock (clk_CPU) from the system clock (clk_SYS) and peripheral clocks, with the CPU clock derived by dividing the system clock using a configurable prescaler in the CLKPR register. This prescaler allows dynamic adjustment of the CPU frequency for , while peripherals like timers often feature independent prescalers to operate at fractions of the CPU clock, ensuring synchronized yet flexible timing across the system.

Performance characteristics

AVR microcontrollers deliver high performance through their modified Harvard RISC , which supports single-cycle execution for most instructions, enabling efficient throughput relative to clock speed. Classic 8-bit AVR devices typically operate at clock frequencies from 1 MHz to 20 MHz, while newer series such as the DD family extend this to up to 24 MHz across a wide supply voltage range of 1.8V to 5.5V. This design yields a consistent performance rating of approximately 1 MIPS per MHz; for example, a 16 MHz device achieves 16 MIPS, allowing system designers to balance processing power and energy use effectively. Power efficiency is a hallmark of AVR performance, with active-mode consumption ranging from 0.1 mA/MHz at low voltages (e.g., 0.2 mA at 1 MHz and 2V) to around 5 mA/MHz under higher voltage and temperature conditions. In sleep modes, such as power-down, current draw drops below 1 µA, supporting extended battery life in embedded applications. These characteristics stem from the AVR's optimized process and peripheral integration, which minimize leakage and dynamic power. Code efficiency further enhances AVR throughput, with the instruction set averaging about 1.8 bytes per instruction due to its compact 16-bit format and rich set of 130+ operations, most executed in one cycle. This results in high program , often outperforming CISC alternatives in memory-constrained environments. In benchmarks, AVR devices match in I/O throughput for typical tasks but excel in RISC-based , delivering faster execution and smaller footprints without clock division penalties.

Programming interfaces

Serial programming methods

Serial programming methods for AVR microcontrollers provide low-voltage interfaces for , enabling updates to , , and fuse bits without removing the device from its application circuit. These methods leverage serial protocols to facilitate efficient development, prototyping, and field updates, contrasting with high-voltage techniques used for locked or protected devices. The key interfaces include (ISP), Tiny Programming Interface (TPI), Program and Debug Interface (PDI), and Unified Program and Debug Interface (UPDI), each optimized for specific AVR families and offering varying levels of pin efficiency and speed. In-System Programming (ISP), also known as programming, is the foundational serial method for classic AVR devices, particularly the megaAVR series. It employs a 6-pin connector comprising VCC, GND, RESET, SCK (serial clock), (master in, slave out), and MOSI (master out, slave in), utilizing the device's built-in SPI hardware for communication. This interface operates at , typically matching the device's supply (1.8V to 5.5V), and supports programming speeds up to half the clock . The protocol initiates with the programmer asserting the RESET pin to enter programming mode, followed by a synchronization byte (0xAC or 0x53 depending on the command phase) to establish communication; subsequent 4-byte command sequences handle operations like loading extended addresses, reading/writing flash or , and verifying fuses. ISP's SPI-based nature ensures robust, bidirectional data transfer, making it widely adopted for in-circuit programming of devices like the ATmega328P. The Tiny Programming Interface (TPI) is a compact 2-pin serial interface designed for low-pin-count tinyAVR devices, such as the ATtiny13A, ATtiny25, ATtiny45, and ATtiny85. It uses the RESET pin for clocking (TPICLK) and a dedicated bidirectional pin (TPIDATA), along with VCC and GND, to minimize PCB routing in space-constrained designs. Operating at speeds up to 1/4 of the system clock (typically up to 4 MHz), TPI employs a half-duplex protocol with 16-bit frames (instruction + address/), where the sends commands after asserting RESET, and the target responds with status or . Synchronization begins with a specific enable sequence on the pins, followed by bit-serial transfers clocked by TPICLK. TPI supports programming of Flash, , and fuses but lacks capabilities, making it suitable for simple, cost-effective embedded applications. The Program and Debug Interface (PDI) is a 2-wire serial interface designed for the XMEGA family and select AVR devices, combining programming and debug capabilities in a compact . It uses the RESET pin for clocking (PDI_CLK) and a single bidirectional data pin (PDO) for all transfers, requiring only VCC and GND for power, which minimizes routing complexity on PCBs. Operating at clock speeds up to 16 MHz, PDI employs a double-buffered where the programmer sends 12-bit frames (1 start bit + 8 data bits + even + 1 stop bit) in a half-duplex manner, with the target echoing received data for verification. The protocol features a command-response structure: After reset, the target enters receive (RX) mode and waits for the first start bit, synchronized by the PDI_CLK provided by the programmer, followed by commands prefixed with a 0xE0 instruction byte to specify operations such as reading/writing pages or fuse bits. PDI's efficiency supports faster programming times compared to ISP for larger devices, and it is backward-compatible with XMEGA's event system for integrated debug. The Unified Program and Debug Interface (UPDI) represents the latest evolution in AVR serial programming, introduced for modern low-pin-count devices such as the tinyAVR 0-series, 1-series, and AVR Dx family. This single-wire interface uses one dedicated UPDI pin for bidirectional, half-duplex asynchronous communication, alongside VCC and GND, reducing the need for multiple pins and enabling simpler board designs for space-constrained applications. Supporting baud rates up to 450 kbps (depending on supply voltage and ), with the initial break at 115.2 kbps for , UPDI employs a UART-like protocol with 9-bit frames (8 bits + start/stop/parity), where the generates a 115.2 kbps break signal post-reset to enter programming mode. occurs via specific byte pairs (0x55 followed by 0x00 or 0x02), after which commands are issued in a response-based format: a 16-bit instruction word specifies the operation (e.g., STCS for store to CPU register or LDS for load from ID), followed by address and bytes for accessing flash, , or fuses. UPDI's streamlined design enhances programming speed and security through features like pointer-based addressing, making it ideal for high-volume production of tinyAVR devices like the ATtiny402. Across these interfaces, AVR serial programming protocols adhere to a consistent command-response , beginning with hardware reset and bytes to align the programmer and target, followed by structured packets for read/write/erase and fuse configuration. This ensures reliable verification and error handling, such as parity checks in PDI and UPDI or status polling in ISP, supporting operations up to several megabits in size.

High-voltage programming techniques

High-voltage programming techniques in AVR microcontrollers utilize elevated voltage levels to activate the internal programming circuitry, enabling access to flash memory, EEPROM, and fuses even when low-voltage interfaces are disabled due to fuse misconfigurations. These methods are essential for recovering "bricked" devices where standard serial programming is unavailable, such as when the reset disable fuse (RSTDISBL) prevents normal operation. They apply approximately 12V to the RESET pin to enter programming mode, overriding typical reset behavior and activating dedicated high-voltage detection circuits. High-Voltage Parallel Programming (HVPP) employs a 10-pin interface primarily for early AVR devices like the AT90S series and initial megaAVR models. The interface includes connections for VCC, GND, a 12V supply on the RESET pin (to enable programming mode), control signals such as RDY/BSY (ready/busy), OE (output enable), and WR (write), along with address lines (A0–A7) and bidirectional data lines. Once the is applied, the process involves loading address and data bytes in parallel, followed by control pulses to program or verify locations and fuses; this allows efficient bulk operations but requires more pins and wiring compared to serial alternatives. HVPP is particularly valued for its ability to fully reprogram locked devices without relying on on-chip bootloaders. High-Voltage Serial Programming (HVSP) is a 6-pin variant optimized for pin-constrained tinyAVR devices, simplifying the interface while maintaining 12V activation on the RESET pin. It uses serial lines including TPIDATA (data in/out), TPICLK (clock), and additional control signals like RDY/BSY, alongside VCC and GND. The programming sequence mirrors HVPP in enabling the chip via high voltage but serializes data transfer: commands, addresses, and bytes are shifted in serially using clocked protocols, enabling fuse recovery and memory programming with fewer connections. This method evolved from HVPP to suit smaller packages, reducing hardware complexity for embedded applications. These techniques have been largely deprecated in favor of low-voltage serial methods since around 2005, as newer AVR architectures integrated more robust in-system programming options; however, they remain supported in tools like AVR Dragon, Atmel-ICE, and STK600 for legacy compatibility and recovery scenarios.

Bootloaders and alternative methods

AVR microcontrollers feature on-chip bootloaders that reside in a dedicated section of the Flash program memory, reserved through fuse configuration to enable self-programming capabilities. The size of this bootloader section is selectable via the BOOTSZ1:0 fuse bits, offering predefined options typically ranging from 512 bytes to 8 kilobytes, depending on the device family such as megaAVR, where settings correspond to 512, 1,024, 2,048, or 4,096 words (each word being 16 bits). This reserved area allows the code to remain intact while the application section is updated, utilizing the Store Program Memory (SPM) instruction for writing to Flash from within the device itself. A common implementation is the AVR109 protocol, which facilitates bootloader communication over a UART interface for uploading new firmware to the Flash and without requiring external hardware programmers beyond a serial connection. The protocol supports commands for reading device signatures, erasing memory, and programming pages, making it suitable for field updates in embedded systems. The BOOTRST fuse determines whether reset vectors point to the bootloader or application code, ensuring seamless transitions during operation. For the XMEGA family, the Program and Debug Interface (PDI) serves as a 2-wire protocol for programming and on-chip , extending traditional interfaces with high-speed access to spaces using dedicated PDI_DATA and PDI_CLK pins. This interface supports full-speed programming rates and is enabled by default on XMEGA devices, allowing efficient in-system updates without additional pins. An alternative single-wire method, aWire, leverages the device's RESET pin to transmit a special enable sequence, enabling programming and debug functions on AVR devices lacking dedicated interface pins, such as certain tinyAVR models. Mask-ROM variants of AVR microcontrollers provide a non-reprogrammable program memory option for high-volume production, where the firmware is fixed during manufacturing to reduce costs in applications not requiring field updates. For instance, the AT90S2313 in its mask-ROM configuration offers 2K bytes of fixed program storage alongside 128 bytes of EEPROM, suitable for cost-sensitive, stable designs like consumer electronics. These variants sacrifice reprogrammability for lower per-unit pricing in large quantities, with the core AVR architecture intact but Flash replaced by one-time mask-programmed ROM. In the modern AVR DU series, USB-integrated bootloaders enable direct updates over USB, incorporating secure mechanisms with to protect against unauthorized modifications. These bootloaders leverage Read-While-Write (RWW) Flash, allowing uninterrupted operation during updates, and pair with features like Program and Debug Interface Disable (PDID) to lock out external access post-deployment. This supports in-field patching for security vulnerabilities or feature enhancements via the USB interface, enhancing reliability in USB-centric applications such as bridges and HID devices.

Debugging interfaces

On-chip debug systems

AVR microcontrollers incorporate on-chip debug systems to facilitate embedded without requiring multiple dedicated pins, particularly suited for resource-constrained designs. The primary implementation is debugWIRE, a one-wire bidirectional interface that repurposes the RESET pin for communication, enabling low pin-count devices such as those in the tinyAVR and megaAVR families to support debugging operations. This system allows developers to control program execution, monitor internal states, and modify memory contents during runtime, all while the microcontroller remains in-circuit. debugWIRE operates by serializing debug commands and responses over the single wire, supporting core functions like halting the CPU, single-stepping through instructions, and reading or writing to registers and memory locations. For instance, it enables variable watching through monitoring, allowing real-time inspection of SRAM, I/O registers, and flash contents without halting unrelated peripherals. The interface is activated by programming the debugWIRE Enable (DWEN) fuse bit, which configures the device to enter debug mode automatically upon reset, provided the lock bits are not set to restrict access. Once enabled, the system overrides the standard RESET functionality, prioritizing debug signals. Breakpoints form a key capability of debugWIRE, implemented as software breakpoints by inserting the AVR BREAK instruction (opcode 0x9598) into , allowing multiple instances but requiring recompilation and flashing of the modified code. Single-stepping complements this by advancing the one instruction at a time, facilitating detailed code tracing. These features are particularly useful for iterative development on devices like the , where debugWIRE provides full visibility into execution without external probes beyond the single wire. Despite its efficiency, debugWIRE has notable limitations that impact its applicability. The debug interface uses a baud rate derived from the system clock divided by 128 (typically 62–187 kHz depending on the system clock ), which can slow sessions on higher-speed applications and prohibits integration into chains for multi-device setups. Enabling the DWEN fuse also incurs a power consumption overhead, as certain clock domains remain active even in modes to support debug readiness, potentially increasing idle current draw by several microamperes. Additionally, external reset capability is disabled during debug sessions due to pin sharing, necessitating careful board design to avoid conflicts. To mitigate these, the DWEN fuse should be disabled in production via high-voltage or parallel programming methods once is complete.

External debug protocols

AVR microcontrollers support external debugging primarily through the (Joint Test Action Group) interface, which adheres to the IEEE 1149.1 standard for boundary-scan testing and has been extended for on-chip debug capabilities. This protocol uses a test access port (TAP) controller to facilitate non-intrusive access to the device's internal state, enabling features like program execution control and data inspection without halting the entire system. The interface on supported AVR families, such as megaAVR and select XMEGA devices, employs a 4-wire setup comprising TCK (test clock input), TMS (test mode select), TDI (test data input), and TDO (test data output), with an optional fifth wire for (test reset). functionality allows testing of interconnections on assembled boards by shifting data through boundary cells around the device's I/O pins, verifying joints and pin connectivity. AVR-specific extensions leverage the JTAG instruction register to access the on-chip debug (OCD) unit, supporting operations like CPU halt, single-step execution, and insertion. AVR implementations incorporate private JTAG instructions—codes 0x08 through 0x0B—to interface directly with the OCD module, providing low-level access to program memory, data memory, registers, and the for advanced tasks. These proprietary instructions enable precise control over execution flow, such as reading or writing internal resources during halted states, while maintaining compatibility with the public IEEE 1149.1 instruction set for standard operations. The OCD unit, accessed via these extensions, integrates seamlessly with the TAP to support source-level in development environments. JTAG chains allow multiple AVR devices to be connected in series on a single interface, where the TDO of one device connects to the TDI of the next, enabling collective or targeted OCD access by shifting instructions through the chain to select specific devices via their instruction registers. This configuration supports efficient debugging in multi-microcontroller systems, though the total chain length is practically limited by and timing constraints. The JTAG clock frequency (TCK) is typically restricted to one-fourth or less of the target's system clock to ensure stable operation, permitting speeds up to 6 MHz in high-frequency AVR configurations like those running at 24 MHz. Support for JTAG is absent in pin-constrained families like tinyAVR due to the lack of dedicated pins, and newer AVR series have largely deprecated multi-wire JTAG in favor of the single-wire UPDI protocol, which consolidates programming and functions for reduced and pin usage in modern low-pin-count devices.

Development tools

Official evaluation kits and boards

provides a range of official evaluation kits and starter boards designed to facilitate prototyping, , and development for AVR microcontrollers, supporting both classic and modern AVR families such as megaAVR, tinyAVR, and AVR DA/DB series. These platforms typically include onboard sockets, interfaces for programming and , and peripherals like LEDs, buttons, and expansion headers to enable rapid application testing without extensive external hardware. The STK500, introduced in the early 2000s, is a modular starter kit targeted at 8-bit AVR microcontrollers, featuring sockets for 8-pin, 20-pin, 28-pin, and 40-pin DIP-packaged devices to accommodate a variety of AVR chips. It supports In-System Programming (ISP) via its 10-pin connector and includes basic peripherals such as an LCD module, LEDs, and switches for initial code validation on megaAVR devices. The STK600, released around 2006 and extending into the 2010s, builds on this modularity as a comprehensive development system for both 8-bit and 32-bit AVR microcontrollers, allowing users to swap device-specific routing cards for different package types like TQFP and QFN. It incorporates JTAG and ISP interfaces, an onboard programmer, and expandable I/O through daughter cards, making it suitable for prototyping complex applications with features like ADC testing and serial communication. Atmel-ICE, launched in 2015, serves as an all-in-one USB 2.0-based debugger and programmer compatible with AVR and , offering support for interfaces including debugWIRE, , PDI, and UPDI to enable full-speed debugging and in-circuit programming. This compact tool integrates seamlessly with Microchip Studio IDE, providing breakpoint capabilities, variable inspection, and flash programming for AVR devices across families, and it includes virtual COM port functionality for [serial communication](/page/serial communication) during evaluation. The Curiosity Nano series, introduced in the late and expanded through the , comprises low-cost, compact evaluation boards for tinyAVR, AVR DA, and AVR DB microcontrollers, emphasizing ease of use with integrated programming/debug interfaces via a 20-pin connector and USB connectivity. Examples include the AVR128DA48 Curiosity Nano, which features the AVR128DA48 MCU with onboard op-amps, multiple voltage domains (MVIO), user LEDs, switches, and crystals for peripheral evaluation, and supports mikroBUS expansion for adding sensors and modules. Similarly, the AVR64DD32 Curiosity Nano targets the AVR DD family with full debug support, while the AVR128DB48 variant includes header strips for custom I/O extensions. These boards prioritize rapid prototyping with minimal footprint, often under 1 inch square, and compatibility with X IDE for seamless code deployment. For specialized applications, the AVR32SD32 Curiosity Nano evaluation kit, released in 2025, focuses on the AVR SD series for safety-critical designs compliant with ASIL C and SIL 2 standards, incorporating the AVR32SD32 MCU with full programming/debug capabilities, onboard LEDs, and expansion options for testing in automotive and industrial contexts. The Raven kit, an earlier evaluation platform from the late , integrates two AVR Raven boards with ATmega128RFA1 picoPower MCUs, 2.4 GHz transceivers, LCD displays, and a USB for and demonstrations, though it is now discontinued. These kits highlight Microchip's emphasis on integrated peripherals like sensors and modules to accelerate development in targeted domains.

Programmers and in-circuit emulators

The AVRISP mkII is a high-speed in-system (ISP) designed for programming and field upgrades of 8-bit AVR microcontrollers via USB, supporting ISP and PDI interfaces for a wide range of devices including ATmega and ATtiny series (discontinued). It enables programming of Flash, , fuses, and lock bits, and integrates with Studio for straightforward device configuration and verification. The AVR Dragon serves as an affordable multi-interface development tool, supporting ISP, , debugWire, and PDI protocols for both 8-bit and 32-bit AVR devices with on-chip debug (OCD) capabilities (discontinued). It facilitates programming, , and emulation at a low cost, making it suitable for hobbyists and professionals working on AVR projects, and connects via USB to host systems. The JTAGICE3 provides professional-grade and programming for AVR microcontrollers, particularly XMEGA series, using and PDI interfaces, and includes a virtual COM port for during development (discontinued). Launched in 2011, it supports on-chip for based SAM devices as well, with features like breakpoints and step-through execution integrated into Studio. The AVR ONE! is a high-end offering advanced features such as program trace, performance analysis, and source-level for complex 8-bit and 32-bit AVR applications (discontinued). Introduced in 2008, it supports multiple interfaces including , PDI, and debugWire, enabling real-time code execution monitoring and integration with development boards for comprehensive testing. These hardware tools integrate seamlessly with Microchip Studio, the official IDE for AVR development, which provides a unified environment for code editing, compilation, programming, and debugging across AVR and SAM devices. Following Microchip's 2016 acquisition of , MPLAB X IDE added beta support for the majority of AVR microcontrollers starting with version 5.05 in October 2018, allowing developers to use these programmers within the cross-platform MPLAB ecosystem for enhanced portability and tool compatibility.

Applications and ecosystem

Common uses and industries

AVR microcontrollers find extensive use in , particularly through the platform, which leverages the ATmega series—such as the ATmega328P in the —for hobbyist projects, educational tools, and prototyping. These applications benefit from the microcontrollers' ease of programming and integrated peripherals, enabling rapid development of interactive devices. Additionally, AVR devices power remote controls and toys, supporting features like infrared communication and low-power wireless modules for reliable operation in battery-operated gadgets. In industrial settings, megaAVR and XMEGA families excel in systems, programmable logic controllers (PLCs), and networks, offering high performance and robustness for , equipment, and monitoring. Their advanced peripherals, including event systems and DMA controllers in XMEGA, facilitate efficient real-time operations in harsh environments, serving as cost-effective alternatives to more complex controllers. The automotive sector employs the AVR SD family for safety-critical systems, achieving compliance with ASIL C and SIL 2 standards to support engine control units (ECUs), advanced driver-assistance features, and other functional safety applications. Dual-core lockstep architectures in these MCUs ensure fault detection within milliseconds, enhancing reliability in vehicle electronics. For (IoT) and wireless applications, tinyAVR microcontrollers provide ultra-low-power operation ideal for battery-powered sensor nodes and edge devices, while the Raven kit demonstrates implementations for in smart home and industrial monitoring setups. These capabilities stem from integrated low-power modes and support for protocols like , enabling extended device lifetimes in connected ecosystems. AVR microcontrollers are also utilized in devices for applications such as acquisition in wearables and diagnostic tools, benefiting from their low power consumption and reliability in patient monitoring systems. In , as of March 2025, entry-level AVR MCUs support safety-critical functions like flight control systems and safety, complying with standards. The global AVR microcontrollers market, valued at US$122 million in 2024, is projected to expand significantly, reaching US$192 million by 2031 at a CAGR of 6.8%, fueled by demand for energy-efficient solutions in wearables, , and IoT deployments.

Third-party support and clones

The AVR architecture benefits from extensive third-party support, including affordable that enable (ISP) without relying on official Microchip hardware. One prominent example is USBasp, an open-source USB-based ISP programmer designed specifically for Atmel AVR controllers, utilizing an ATmega8 or ATmega88 and passive components for firmware-only USB operation. Another widely used option is the Arduino as ISP method, which repurposes an board—such as the Uno with an ATmega328P—to act as a low-cost ISP programmer for other AVR devices, leveraging the board's SPI interface and a provided sketch to handle programming tasks. Complementing these hardware solutions is AVRdude, a versatile open-source command-line utility for downloading, uploading, and manipulating flash, , and fuse bits on AVR microcontrollers via ISP, parallel, or serial interfaces, integrated into many development environments. The broader AVR development ecosystem is enriched by open-source tools that facilitate compilation and integration. The AVR-GCC compiler, part of the , provides a complete —including assembler, linker, and standard C libraries—for generating efficient code targeting AVR's RISC architecture, with ongoing support from the and Microchip. The Arduino IDE extends this by offering a user-friendly interface for AVR programming, abstracting low-level details while allowing direct access to AVR peripherals through its core libraries. Similarly, PlatformIO provides cross-platform IDE support for AVR devices, incorporating AVR-GCC, AVRdude, and compatibility to streamline building, uploading, and debugging for boards like the ATmega328P. Open-source FPGA implementations offer soft-core alternatives to hardware AVR chips, enabling , prototyping, and customization on reconfigurable logic devices. The Soft AVR Core project delivers a synthesizable 8-bit AVR-compatible processor with a 2-stage , supporting AVR2, AVR25, and AVR3 instruction sets, along with peripherals like timers and UART, targeted at FPGAs from vendors such as and Lattice for educational and embedded applications. Another example is the RISC-8 soft-core, a compact 8-bit CPU that achieves partial compatibility with the AVR instruction set—implementing core operations like arithmetic and branching—while fitting into small FPGAs for low-resource environments, though it lacks full architectural fidelity. While Microchip maintains dominance in AVR production following its acquisition of , third-party clones are limited primarily to variants from Chinese manufacturers, often replicating popular models like ATtiny series chips in DIP packages but exhibiting inconsistencies in performance and reliability. No major competing vendors produce fully compatible AVR alternatives at scale, with discussions in technical communities noting the scarcity of legitimate drop-in replacements beyond Microchip's portfolio. The AVR community fosters ongoing innovation through dedicated forums and resource repositories. AVR Freaks, hosted by Microchip, serves as a primary online hub for developers, featuring discussions on programming, peripherals, and troubleshooting, with threads often sharing code snippets for interfaces like I2C and SPI. Extensive open-source libraries for AVR peripherals—such as those for ADC, PWM, and communication protocols—are curated in collections like Awesome AVR, promoting reusable code for and reducing development time.

References

Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.