avrdude, the command line that writes flash, EEPROM and fuse bits

Three memories, and one flag that decides which

AVRDUDE is the AVR Downloader Uploader, a program for downloading and uploading the on-chip memories of Microchip's AVR microcontrollers. What it can write is stated precisely: the Flash and EEPROM, and, where the programming protocol supports it, the fuse and lock bits.

That last clause is the one to internalise. Fuses and lock bits are not ordinary memory. A fuse byte configures things like the clock source or the boot section size, and the lock bits protect against further reads of the flash. Whether avrdude can reach them at all depends on the programmer and the protocol it speaks, which is why the capability is qualified rather than promised. Writing them is also the step where a mistake has lasting consequences, since a bad fuse can leave a part that no longer boots and no longer accepts the same commands.

The tool was originally written in 2003 by Brian S. Dean and has been maintained since 2006 by Jörg Wunsch with contributions from others listed in the AUTHORS file. A quarter of a century in, the interface has stayed deliberately small, which is why it remains the answer in toolchains, CI scripts and lab benches even though plenty of newer chips and boards exist.

The programmer, the part, and the memory selector

The command line has three parts that must agree with each other. The general shape given in the documentation is:

avrdude -c <programmer> -p <part> -U flash:w:<file>:i

`-c` names the programmer hardware, `-p` names the target part, and `-U` is the memory operation, where `flash:w` means write to flash, `<file>` is the input path and the trailing `i` requests the Intel HEX format. Every one of those three has to be right, and the documentation is blunt about the last part of the equation: there are many different programmers and options that may be required for the programming to succeed.

The worked example from the README programs an Arduino Uno on the serial port COM1 with a HEX file called blink.hex, and the flags are all doing specific jobs:

avrdude -c arduino -P COM1 -b 115200 -p atmega328p -D -U flash:w:objs/blink.hex:i

`-c arduino` selects the Arduino programmer, `-P COM1` names the serial port, `-b 115200` sets the baud rate, `-p atmega328p` identifies the target chip.

Run the command with no arguments at all and it lists the available options, so the tool documents itself when you are stuck.

Direct instruction mode for parts avrdude does not model

There is a second way to drive the chip, and it is the one that makes avrdude useful for hardware avrdude has never heard of. Alongside the normal command set, the tool supplies a direct instruction mode that allows any programming instruction to be issued to the AVR chip regardless of whether avrdude implements that specific feature of a particular chip.

This matters more than it first appears. A part database covers the chips that were known when it was written, and the field of new devices moves faster than any table. With direct instruction mode, a new part does not need a full driver. You talk to the programmer in the protocol's own terms, and the parts of the protocol that avrdude does understand are still available to you. It is the same reasoning behind why a low-level escape hatch exists in a tool with a friendly high-level layer on top.

The trade is that the friendly layer is where the safety lives. The high-level commands know the meaning of a byte in a particular memory region, and the direct mode does not. Anyone using it needs the programming protocol documentation for the programmer in hand, and should expect to handle the details that the part-specific code would otherwise handle.

libavrdude and the Qt demonstrator that arrived with version 8

Starting with version 8, a GUI implementation was added, and the point of it is stated as being to demonstrate that the functionality of libavrdude is suitable for implementing a native GUI rather than a command line wrapper. That framing tells you what changed architecturally: the command line tool was refactored so that a separate library carries the real work, and the GUI is a consumer of that library.

The GUI is built on the Qt toolkit with its Python bindings, called PySide. Either Qt5 with PySide2, or Qt6 with PySide6 is supported, so a distributable built for one Qt generation will not run on the other without a matching build.

A script named avrdude-gui is installed into the same location as the command line program and starts the GUI, and it carries builtin help describing the usage. In practice the interesting consequence is for developers rather than for users: if you are building tooling around avrdude, the library is the supported seam, and the demonstrator is a reference for how to drive it. The repository layout supports that reading, with the C sources under src/, a CMakeLists.txt and CMakeSettings.json at the root, a build.sh, an INSTALL file and a tools/ directory, plus supporting-docs/ and the avrdude.pdf manual.

Three package routes, and the GPL-2.0 question

Installation is straightforward on every platform the project names. On Linux the instruction is to install the package `avrdude` with the software package manager, and the example given is for Debian and Ubuntu:

sudo apt-get install avrdude

On macOS the tool is available through MacPorts or Homebrew. On Windows the documentation points at the Releases page for the latest version, and the project also publishes documentation for current and previous releases on GitHub Pages. In all three cases the README adds that you can build avrdude yourself from source, with the build instructions living in the project wiki. The build system in the repository is CMake, and the wiki is where the platform-specific details live, since the main branch is documented only by the most recent avrdude.pdf.

The licence is GPL-2.0, with the text in the COPYING file. For a tool you invoke from a build script, that is an unremarkable choice. For the library, it is the point to think about. Linking libavrdude into a closed-source product is a different question from running the avrdude binary, and this review is not the place to answer it. The relevant fact for a technical reader is simply that the library is GPL-2.0, so any product that links it inherits the obligations that licence carries. If you only need the command line behaviour, the licence question does not arise at all.

A release every few months, with a manual that lags main

The release history shows steady output: v8.1 on 2025-06-23, v8.2 on 2026-07-11 and v8.3 on 2026-09-11, with the last push to the repository on 2026-10-14. The repository is not archived, and the gap between v8.2 and v8.3 is about two months.

Documentation is the one place where the project is explicit about a gap. Documentation for current and previous releases is on GitHub Pages, so a pinned release has proper documentation that does not move under you. The main branch is different: it is documented only with the most recent avrdude.pdf. The practical reading is that if you are tracking main, you are working from a single PDF rather than the browsable documentation, and if you need stable reference material, the released version is where to read it.

The repository also carries the usual release-support files. NEWS is there for the changelog, INSTALL for installation notes, AUTHORS for the contributor list, and the workflows in.github/ drive the build that the status badge points at. For a project that has been shipping since 2003, that structure is the interesting part: the code is old and the process around it is current, and the interface you script against has stayed stable enough that a command written for one chip and one programmer is still close to the same shape today.

Where avrdude is the wrong tool

There are two clear boundaries. The first is the target family. avrdude is for AVR microcontrollers. A part from a different architecture, whether an ARM Cortex design, an AT91SAM part or a chip from another vendor, is out of scope, and the part identifier and programming protocol are AVR specific. If your board is not AVR, this tool does not apply.

The second is that avrdude writes whatever you tell it to write. There is no transactional step, no verification of a fuse configuration against what the datasheet says the part should have, and no confirmation that a boot loader is present before the boot section fuse is changed. The tool is a protocol implementation with a convenient layer on top, and the convenient layer is where the safety comes from. A script that loops over devices and writes fuse bytes needs to come from a source that knows what those bytes mean.

There is a third practical constraint that shows up in scripted use. Because the programmer, the part, the port and the baud rate all have to be specified and all have to match, avrdude is easy to script and easy to misconfigure. A build that silently programmed a different part, or that burned a lock bit, would not fail loudly. For a hobby bench that is acceptable. For a pipeline that produces hardware in volume, avrdude is one component that needs to sit behind validation you write yourself.

Editorial conclusion

avrdude fits anyone flashing an AVR part from a script, a CI job or a workbench, and it is still the reference implementation for the programmer protocols, with v8.3 published on 2026-09-11 and the last push on 2026-10-14. It does not fit a production firmware pipeline that cannot tolerate a wrong fuse byte or a part identifier that is off by one letter, and the libavrdude library is a GPL-2.0 component, which rules out linking it into a closed-source tool without a licence review. Before you script it, confirm two things: that the `-p` part identifier matches your exact device, and that you know what each fuse bit does, since avrdude will write it as given. The documentation for current and previous releases is published on GitHub Pages, and the main branch is documented only by avrdude.pdf.

Frequently asked questions

Official sources

1. avrdudes/avrdude on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases