ArduinoToBreadboard tutorial workaround?

Hi I want to burn the bootloader onto, and program, a ATMEGA328 w. minimal additional circuitry (no external clock) like in this tutorial:

However my arduino is a Arduino Uno (R3), and the tutorial states that the method is only compatible with the Arudino Duemilanove. My question is: Is this information outdated? Or is there a workaround for using a Arduino Uno?

To use the ArduinoISP sketch on an Arduino UNO you need to disable the UNO's Auto Reset after you upload the ArduinoISP sketch. Connect a 1 to 10 uF capacitor between the UNO's Reset pin (+) and Ground pin (-).

Note that if the ATmega328p chip is not fresh from the factory, for instance if it ever has an Arduino bootloader burned, it may need the crystal in order to be programmed. The serial programming uses the system clock and a chip configured to use a crystal won't have a working system clock if the crystal isn't present.

The microprocessor used in the Duemanilove is the ATmega168 and in the UNO the ATmega328P is used. (Later versions of the Duemanilove used the ATmega328). Functionally there are no differences. However, technically, there are several differences:

The ATmega328P is a 'P' version, this added letter signifies the PicoPower version. This just means that this microprocessor can work on 5 volts (like the ATmega328 and the ATmega168 do), but it can ALSO work on 3,3 volts. (That is all the P means.)

Next to that the ATmega328 with or without the P has double the flash capacity; 32 Kbytes in stead of ATmega168's 16 Kbyte. So functionally, there are no differences, other than the extra flash space for writing your sketches to.

Next thing you should keep in mind is that these microprocessors have a signature. It is unique for the microprocessor family. So every ATmega328 has the same number, but it differs from ATmega328P's signature. This way an ISP (In-System Programming) Programmer (a device that can flash the bootloader on the ATmega chips) can verify if it is connected to the correct (expected) chip.

The Duemanilove is reset using Serial line 'DTR' (Down to Reset, meaning: bring voltage down to reset). The UNO uses the same technique to reset the ATmega chip, so I see no problem there. The tutorial does mention the UNO, so I wouldn't say it is outdated. However, it seriously lacks the correct information, since the solution provided by johnwasser will work. If you give the reset line a capacitor, it will hold power. Then when the Arduino software on your computer tries to reset the ATmega chip it brings the reset line down. At that point the capacitor will release its charge, preventing the reset line on the ATmega to actually lower long enough for the chip to reset. This way you can use a UNO to flash another ATmega chip.

Let us know how everything works out ;)

However my arduino is a Arduino Uno (R3), and the tutorial states that the method is only compatible with the Arudino Duemilanove. My question is: Is this information outdated? Or is there a workaround for using a Arduino Uno?

UNO R3 works fine. This information is probably valid to prior UNO R3 only. Go ahead.

Thanks for all the response. The blank atmega328p chips are on the way. Ill reply here when I get it out.

Ok so the ATMEGA328P-PUs have arrived and naturally I've met some obstacles when trying to [u]burn the bootloader[/u] onto the chip. I've been following these two guides:

My config: -I've loaded 'ArduinoISP' from the Examples meny. -Access Tools > Boards > 'ATmega328 on a breadboard (8 MHz internal clock)'. -Set the programmer to 'Arduino as ISP'. -Made sure I'm using the right USBport -Selected Tools > Burn Bootloader (both on its own, and after pressing the reset button of the Arduino Uno). -Wired the ATmega328 I wish to burn the bootloader onto as shown in the "ArduinoToBreadboard" tutorial. Also tried adding a 1uF cap from Reset to Ground as suggested, and tried adding a 10k resistor from +5V to reset (not both cap. and res. at the same time). -Added caps between +5V and Ground to eliminate any noise.

My problem: I keep getting the "avrdude: stk500_getsync(): not in sync: resp=0x00" which seems to apply to a large number of different possible issues and situations. I've tried to read up on it, but all the threads dealing with bootloader burning seems to be unconclusive. I've tried uploading standard programs to my Arduino Uno (using the normal programmer and board options) and all my digital pins seems to be fine. There's no problem with the connection between the computer and the Uno.

So I'm left kinda clueless here. If anyone have any suggestions I'll be very grateful! Will have another go at it tomorrow.. been at this for hours :P

Tried another ATmega328 chip (I bought two) and checked all my wires and voltages. Everything look correct. Still same result thought…

Finally got it working!!! I used this guide as suggested earlier: I followed the guide right up to the point where its suggested to program the chip using a FTDI cable. From here on I followed the ArduinoToBreadboard guide at, removing the Arduino UNO chip, using the normal AVRISP mkII programmer and setting the board to LilyPad Arduino w/ ATmega328. Works like a charm! :stuck_out_tongue_closed_eyes:

A bit late for the party, but for what it's worth: I was able to use the instructions at as such to burn the bootloader with the mininal setup (328P chip), using UNO R3. Actually, I even skipped some wiring: no need to feed 5V and GND on both sides of the target chip. I did have the "Arduino as ISP" sketch loaded all the time on my UNO.

Also, to program the chip on the breadboard, no need to change the wiring (and more importantly, remove the chip from the UNO board!) from the bootloader burn setup. I did add a 10uF capacitor between UNO's (not the chip on the breadboard) GND and reset, then uploaded a scetch to the breadboard chip using "Upload Using Programmer". If you use a sketch that blinks pin13, you immediately see the effect on the UNO board (although the program runs on the target chip), as the pins are still connected.

Not actually fully up to speed why "Upload Using Programmer" was needed, as I used a similar setup to program an ATTiny with UNO and I'm pretty sure I was using the normal "Upload"... maybe it's because now there were two similar chips involved (the one on UNO, one on breadboard) and there was a conflict somewhere.