How long does it take to upload a sketch to a breadboard Arduino ?

EDIT : (topic subject)
Answer : SIX DAYS !! :frowning:

Below is the original post, and have now updated the situation in Reply #1

---===---

1a. i have setup a Breadboard Arduino following Nick Gammon's guide here.

1b. A blank ATMega328 chip has been bootloaded successfully and confirmed detected using Nick Gammon's sketch.

Now, i got a cheap eBay USB-to-TTL-converter with the CH340G chip which has failed me so far, but that's for another topic.

the official Arduino pages describe a method where you remove the existing ATMega chip and then use the FTDI chip on the Uno board to program the Breadboard chip - i would like to avoid pulling chips off the Uno board as it's an original and i'd like to keep it as intact as possible.

...

i have since found this old thread; SOLVED:Sketches to breadboard-arduino..without removing the real Arduino's chip? - Interfacing w/ Software on the Computer - Arduino Forum and tried to use the solutions in it.

2a. i have tried the method in Reply #8 - using a sketch to bypass the TX/RX tricking them into being input pins for the breadboard chip.
(this is the serial-disable.ino that is used;

#define ledbrd 13
#define rxpin 0
#define txpin 1

void setup() {

    pinMode(ledbrd, OUTPUT);  // initialize digital pin 13 as an output.
    Serial.end(); // disable the serial port to start using the tx and rx and input port
    pinMode(rxpin, INPUT); //set the serial rx pin as general input 
    pinMode(txpin,INPUT); // set the serial tx pin as general input
    
}

// Very low duty cycle blink to indicate idle mode of  UNO board
void loop() {
  digitalWrite(ledbrd, HIGH);   // turn the LED on 
  delay(1);              // wait for a  very short (minimum) time
  digitalWrite(ledbrd, LOW);    // turn the LED off
  delay(4000);              // wait for many seconds
  
}

)
that didn't work and i didn't consider investigating further as it seemed rather risky for the original chip.

2b. so i proceeded to try the method mentioned in Reply #7 (of same thread mentioned above) - it seemed much more comprehensive and was also better documented. (it's basically using the ArduinoISP as the programmer.)

suffice to say - it didn't work - i get the avrdude: stk500_getsync(): not in sync: resp=0x[color=blue][b]e[/b][/color]0 error.

i followed on with the fuse change, editing the Extended Fuse in "boards.txt" from 0x05 to 0x07.
i even tried changing it to 0xFD because that's the value that shows up when i used Nick Gammon's Board_Detector sketch.

finally, i tried the "blocking the autoreset" with the 120 (actually 100+22) Ohm resistor b/n RESET and 5V and 10 uF capacitor b/n RESET and GND.

still no success but the error was now;

avrdude: stk500_getsync(): not in sync: resp=0x[color=blue][b]0[/b][/color]0

can anyone suggest what i can try next ?

SO - i finally gave in and followed the "correct way" and removed the original chip.

following this;
from https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard
Uploading Using an Arduino Board

my layout is slightly different because i had followed Nick Gammon's placement of the capacitors.

it STILL FAILED !

since the original ATmega chip had been removed, the Uno board was simply waiting for another one ;
SO - the "breadboard chip" got slotted in to the Uno - and that (obviously) finally worked.

removing the "breadboard 328" and putting it back onto the breadboard finally meant i had a breadboard Blink.ino running.

FWIW: i noticed the LED flicker faintly when i first powered the Breaduino up, (via 5V from Uno board) and then it eventually went into the blink sketch.

i tried AGAIN to upload the blink sketch to the breadboard 328 with different blink settings but...

[color=orange]avrdude: stk500_getsync(): not in sync: resp=0x00[/color]

all i know now is that the new 328 chip works, but my breadboard setup doesn't - perhaps it is failing somewhere ?

here are some pics of it;

the circuit is different from the "official Arduino" suggestion (above) in that;

  1. i have added another 0.1 uF cap to the AREF (as per CrossRoads reply in another thread with this picture; (i don't have a Zener diode though, but that's supposed to "be optional".)

and;

  1. i have a 0.1 uF cap b/n the Uno board RESET and the breadboard 328 pin 1 (as per CrossRoads pic above, and ALSO in Nick Gammon's minimum breadboard layout.

now i have run out of ideas on what else to change to get the breadboard to accept an upload as per "official Arduino" setup.

does anybody out there have any suggestions ?

Thanks.

You are using the circuit setup in schematic shown in #1?

Are those 0.1 or .01 μF capacitors.

If you are using CH340 you need the appropriate drivers for it.

What is written on the crystal capacitors.

A collage is good but we need to see where wires go.
Good 'images' allows us to clearly see the pins, wires and components so we can trace things out.

larryd:
You are using the circuit setup in schematic shown in #1?

i am tryimg to uise THIS;

https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard
[b]Uploading Using an Arduino Board[/b]

EXACTLY.

larryd:
Are those 0.1 or .01 μF capacitors.

0.1 uF

larryd:
If you are using CH340 you need the appropriate drivers for it.

that's a whole different issue, i can't even get it to work using the FTDI chip on the Uno board.

larryd:
What is written on the crystal capacitors.

22 - i bought them specifically with those values.

larryd:
A collage is good but we need to see where wires go.
Good 'images' allows us to clearly see the pins, wires and components so we can trace things out.

i'll try and take better pics in the daytime, but in the meantime, there's the yellow & green (i am even following the same colours as the circuit !!) jumper-pair from the TX/RX of the Uno.

and then there's a Purple-Blue-Green ( =Reset-5V-GND at the Uno) - which you can see goes to the power rail on the breadboard - while the purple connects to the white jumper to go via the series cap. (all these five can be seen in the bottom photo.)

Cannot tell for sure, but Reset from the main PCB should connect directly to pin 1 of the controller chip.

larryd:
Cannot tell for sure, but Reset from the main PCB should connect directly to pin 1 of the controller chip.

indeed, that is how it should be - but it doesn't work, and perusing many of the threads regarding this similar case, a capacitor in series seems to be the way to go (to ensure reset is brought low);

as per CrossRoads pic above;

and even in Nick Gammon's own thread;

of course these are actually meant to connect to the FTDI pin, whereas in this case, it's "only" connected to the Uno RESET pin.

anyway - here are some better photos, hope you can see it clearly now.
Thanks for your responses, btw.

full layout

close up

NOTE (only in these latest photos)
i forgot to replace one of the crystal caps back after i took it out last night to confirm what was written on it. (so it was still sitting out there on the rail when i took these photos)

Yes. Well... Programming an AVR on a breadboard is a relatively "advanced" topic, and what you are experiencing is more or less what people frequently went through before bootloader-based boards with built-in USB support (like Arduino) became the norm.

How much of the theory of what you're trying to do do you (or could you) understand? It might be time to step back and try to figure out what is going on, instead of jumping from one tutorial to another and moving things around somewhat randomly. For example, I can't quite tell from this thread whether you might have erased the Serial bootloader by programming a sketch via the Arduino as ISP process...

westfw:
Yes. Well... Programming an AVR on a breadboard is a relatively "advanced" topic, and what you are experiencing is more or less what people frequently went through before bootloader-based boards with built-in USB support (like Arduino) became the norm.

i see, good to know - i will adjust my expectations accdly then.
if there are ppl patient enough to guide me through the learning process, i'm willing to stick with having to go through the fundamentals first and not just "get straight to blink-ing".

so, could we be looking at 'breadboard capacitance' issues here ?

westfw:
How much of the theory of what you're trying to do do you (or could you) understand? It might be time to step back and try to figure out what is going on, instead of jumping from one tutorial to another and moving things around somewhat randomly.

i have followed (understood) Nick Gammon's guide which explained some theory behind what was being done.

and i think i have grasped most of what has been outlined on this page;
https://www.arduino.cc/en/Tutorial/ArduinoISP
(interesting to note that it's not linked or referenced anywhere on the "official" ArduinoToBreadboard or Standalone pages - one would think it was mandatory reading before attempting Breadboard/Standalone circuits.

and based on what snippets i have caught from some "advanced threads", what is going on is this;

  1. the Arduino board and IDE have simplified the process of programming the microcontroller chip with the use of the 'bootloader'.

  2. the IDE (utilising avrdude) compiles the Arduino (C++) code into the 'HEX' file which is the 'machine-language' file that gets uploaded into the ATmega chip.

  3. the bootloader facilitates uploading of "sketches" via the Arduino IDE and is not really required if programming the ATmega chip to be used in a permanent situation.

[please do correct any statements above which are inaccurate or have some form of misunderstanding.]

what i don't yet understand is the difference between using ISP (ie. the SPI-bus/connections; MOSI, MISO, CLK + RESET) and "just" the TX/RX connections. i assume they both use the USB-to-TTL converter chips (ie. FTDI, CP2102, or CH340G) ?

westfw:
For example, I can't quite tell from this thread whether you might have erased the Serial bootloader by programming a sketch via the Arduino as ISP process...

i don't think so - after the first avrdude: stk500_getsync(): not in sync: resp=0x00 errors occurred, i did re-confirm that the bootloader was still in there using Nick Gammon's "Atmega_Board_Detector" sketch.

If you are using an off board FTDI cable to program the chip on your breadboard, DTR from the FTDI cable would connect to a 0.1 μF capacitor which connects to pin 1 (reset) of the controller chip (10K would be connected pin 1 to +5v).

If you are using the onboard USB I.C. to program the controller, Reset from the power strip, connects directly to pin one of the controller. There would be no 10K or 0.1 μF capacitor on the breadboard controller pin 1 as they are already on the UNO.

If you are using the UNO ICSP pins to program a breadboard controller, there must be an UNO controller on the UNO board (which has the ISP sketch installed).
The wiring to the breadboard controller is different than the FTDI/USB process.

larryd:
If you are using the onboard USB I.C. to program the controller, Reset from the power strip, connects directly to pin one of the controller. There would be no 10K or 0.1 μF capacitor on the breadboard controller pin 1 as they are already on the UNO.

ahh, i see - OK then.

...<<removes the 10K>>...

nope... still no success :frowning:

from what i understand, the RESET pin needs to be kept HIGH, right ?
and brought LOW when uploading a sketch to the chip.

would it help if i used the "old way" using a button to 'bring it LOW' before uploading ?
any tips on what sort of 'timing' i should attempt - i understand there is some sort of art to it...

incidentally, the "official" layout/circuit does have the 10K;

i tried this, also removing all the decoupling caps (as per Nick Gammon's layout), AND even using those blue wires to connect the crystal similarly, but that didn't help - should i trim the crystal leads as short as possible ? (and the 22 pF caps as well ?)

can we confirm it is a breadboard physical layout issue ?

how do i test the 22 pF caps are working - i've checked continuity on every other connection on the breadboard.

(and, for the sake of the blatantly obvious, the RX goes to RX and not TX, right ?)

EDIT:
would using the ISP method actually be "easier" - or more straightforward to trouble-shoot ?

Let’s stop for a second.
Can you upload a sketch to the controller when it is plugged into the UNO?

Make sure you plug the chip in the socket correctly.

larryd:
Let’s stop for a second.

yes, let's really go to absolute fundamentals !

larryd:
Can you upload a sketch to the controller when it is plugged into the UNO?

yes, this whole exercise has been going in reverse and going forward incrementally from the "standard setup" that works.

i tried to find a method that avoided removing the microcontroller (328) from the UNO board, but finally gave in and removed it - that didn't work (for the New 328 on the breadboard) - so, i put the New 328 INTO the UNO board and that worked (and then placed it back into the breadboard) - that is how the Breadboarduino now has a blink sketch running.

I'm confused, I’m old.

When you just put the controller back into the UNO I.C. socket, you were able to upload a different sketch to it?

larryd:
I'm confused, I’m old.

When you just put the controller back into the UNO I.C. socket, you were able to upload a different sketch to it?

well, i am trying to minimise pulling and pushing 328s from the UNO board. (it takes me ages doing it s l o w l y and c a r e f u l l y . . . )

this is how it unfolded; (all using the TX/RX methodology)

  1. Old 328 in UNO , New 328 on breadboard - NO GO. (this was obvious - but i had been trying this with the SPI methodology. )

  2. Removed Old 328 from UNO , New 328 on breadboard - NO GO. this is ofc the "official" setup in the diagram.

  3. Plugged in New 328 into UNO - this is the "normal setup" and there's no 'transferring' (TX/RX or SPI) going on.

so; 3) confirms the New 328 is OK. EDIT: ie. not a chip problem nor bootloader

i have since taken it out of the UNO and put it back on the breadboard.
the Old 328 is NOT yet replaced - since the whole (next) exercise is to TX/RX the sketch (to the Breaduino) with a 328 removed from UNO board.

I am trying to see if there is something wrong the USB controller.

From your answer, I cannot determine if you were/are able to program the 328 controller with a new sketch (while it is plugged into the UNO PCB).

Sleep time here.

:sleeping:

larryd:
I am trying to see if there is something wrong the USB controller.

i should hope not - that's the original FTDI on the UNO board !

larryd:
From your answer, I cannot determine if you were/are able to program the 328 controller with a new sketch (while it is plugged into the UNO PCB).

it can, the New 328 was a blank chip, successfully bootloaded using Nick Gammon's sketch but never able to receive a sketch - until it was plugged directly into the UNO board. (which was the ultimate basic step and HAD to work !)

FWIW : it has a strange(?) EFuse of 0xFD instead of 0x05 or 0x07 - don't know if that makes any diff.

larryd:
Sleep time here.

:sleeping:

ok - get some rest, thanks for the attention so far.

Okay.
So the controller can be programmed while it is installed in the UNO but not when it sits in the breadboard.

You are sure all the wiring is okay, sometimes you get bad jumper wires.

Assume the breadboard crystal is good, as are all the capacitors (22pF).

I would make sure none of the controller pins are bent under the chip.

I would us a DMM and check the ‘power’ pins on the breadboard controller for 5v.

I would remake the circuit physically somewhere else on the breadboard.

My Melatonin is taking hold.

larryd:
You are sure all the wiring is okay, sometimes you get bad jumper wires.

Assume the breadboard crystal is good, as are all the capacitors (22pF).

I would make sure none of the controller pins are bent under the chip.

I would us a DMM and check the ‘power’ pins on the breadboard controller for 5v.

i have since added a 7805 (voltage regulator) to the breadboard and the New 328 blink sketch can run totally disconnected from the UNO.

i think that can confirm the connections, the crystal and the caps are all okay ?

EDIT:
speaking of the 7805, the https://www.arduino.cc/en/Main/Standalone says to use 2 x 10uF capacitors, but the datasheet of the LM7805 from TI shows this;

which one is "more correct" ?

i think that can confirm the connections, the crystal and the caps are all okay ?

Yes.

The RX and TX wires are okay? replace them with new ones anyway.

The reset, GND and +5v wires are okay? replace them with new ones anyway.

Check for proper soldering on the female headers on the UNO.

Make sure the header wires to the breadboard fit snuggly into the UNO female headers.

For sure, no more tonight ???

It’s morning. :slight_smile:

Leave the breadboard cct. wired to the 7805 (with input 100nF capacitor).
Your cct. in Figure 1 will work, however, the .33 can be changed to .1uF (ceramic) mounted very close to the input of the regualtor.

'Remove' the breadboard wire going to the 5v pin of the UNO.

Leave the common GND, reset, RX and TX wires going to the UNO.

Therefore the breadboard controller will be powered from the external 7805.

Try to up load now.

This makes no sense, there must be a bad wire.