A compact AVR programmer that doesn't require ugly cables.
Failed to load latest commit information.
docs Datasheets. May 9, 2012


AVR In-System Programmer

By Mike Tsao and Dennis Gentry


This is a new spin on the AVR ISP. It's based on the ATmega 'u2 family of AVR devices. Influences while designing, in no particular order:

Design Goals

  1. It should be pocketable, or capable of being kept in a mesh backpack compartment, without snagging on anything. This means SMD rather than through-hole, few or no required pin headers, and right-angle headers where headers are required.
  2. No special cables needed. In the common case of a standard 6-pin ISP header on the target board, the programmer needs only a commodity mini-B USB cable. The target audience is DIY people who are designing their own circuits, and in that case it's very unlikely new designs would use a 10-pin ISP header with 4 NC pins.
  3. It should be a real USB device rather than emulating serial over USB, so it needs fewer avrdude options to pass in.
  4. Jumpers should be truly optional. The device should be usable without jumper header pins even soldered onto the board.
  5. Support in current versions of avrdude. With the real-USB-device requirement, this narrows it down to USBasp, USBtiny, or AVRISP mkII emulation.
  6. Inexpensive. To be clear, most AVR programmers are inexpensive, and it's not a goal to be less expensive than them.
  7. Distinctive. The angled 6-pin socket satisfies this goal.
  8. Fast. This should be entirely dependent on the quality of the firmware, because the device itself should be capable of high-speed USB.
  9. Good-looking enough to be presentable without a case.
  10. JTAG/XSVF programming via The JTAG Whisperer. This means we need to support varying target voltages.
  11. Bring out the serial pins on the ATmega to provide a USB-to-TTL converter with an FTDI-cable-compatible pinout.
  12. Support for all low-voltage programming methods (SPI, TPI, PDI). Note that TPI/PDI turned out to be hard to do with the serial functionality. It should work, but with external resistors and a breadboard.

Notes That Will Someday Become Documentation

  • Fuses are -U lfuse:w:0xDE:m -U hfuse:w:0xD9:m -U efuse:w:0xF7:m -U lock:w:0xFF:m. These are default with 16MHz crystal and HWBE=0.


  • Err, USBasp? USBtiny? You know those bitbang USB, right? Why consider those protocols if your ATmegaXXu2 has native USB? It's just a question of avrdude support. Both those protocols are based on open-source hardware, so I'd prefer to base my work on them. Another consideration is that there shouldn't be a problem with borrowing their VID/PID pairs. The bit-banging aspect of the protocols is orthogonal to their suitability.
  • Your circuit mentions the ATmega8u2. You know the '32u2 is only like $1.00 more, right? True (actually only 40 cents more in quantity), and the initial prototypes will use the '32u2. But we're going to try to fit the intended functionality into 8KB flash and 512 bytes SRAM. Beyond that, the device is looking more like a general-purpose gadget. If we were building such a thing, the ATmega32u4 (not the 32u2) is a better choice.
  • About that general-purpose gadget: why aren't you building one? The Bus Pirate is cool. Yes, the Bus Pirate is cool, and indeed it would be nice to have one built on an open toolchain. But this isn't that device. The intent is to have a specialized tool that's always available, never needing a misplaced cable, never needing a firmware update, during those times when you've bricked an AVR or CPLD and just need it fixed.
  • What's this about AVRISP mkII? Right, at the moment the prototypes are running the LUFA project AVRISP mkII. This hardware doesn't include any of its own software, but just in case you build a copy and run LUFA on it, we'd like to incorporate LUFA's MIT-style license and copyright notice by reference here. Thanks, Dean!