I have an arduino uno set up as an isp. From the arduino ide I can write a sketch and download to a uc connected to the isp. A
If I write a program in studio and then try and program the ttarget connected to the isp....... I actually reprogram the isp rather than the target! The command line for avrdude is identical in both cases.
I have read of needing a 10uF cap but as all works well from the ide I have not tried it.
Any suggestions?
I got the ArduinoISP program working without using the suggested cap. I remember that it was easy to get confused as to which AVR you were actually programming - the one on the Arduino that becomes the ArduinoISP or the one being programmed by the ArduinoISP. I had to reread the instructions to get it right. But I didn't try using an externally generated .hex file from studio so I can't comment on that.
Smiley
I have read of needing a 10uF cap but as all works well from the ide I have not tried it.Any suggestions?
I've never gotten ArduinoISP to work withoutthe cap on reset. Why it ever worked for you is a good question, but it is important to have it.
JJ
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
You used a 10uF cap on the reset? A 100nF with a 10k pullup maybe, but 10uF?
Smiley
You used a 10uF cap on the reset? A 100nF with a 10k pullup maybe, but 10uF?
In practice, I've used a 1 uF successfully. I doubt 100 nF would work reliably.
JJ
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
None of the circuits in the ArduinoISP web page show the use of a capacitor:
http://arduino.cc/en/Tutorial/Ar...
When I use an FTDI breakout board to program an Arduino, I use a 100nF cap between DTR and reset with a 10K pullup on reset. This is to put the AVR into the Arduino bootloader mode.
Using ArduinoISP is different in that it cause the master arduino to generate the ISP signals needed to program a slave AVR. No capacitor is indicated for this reset in the original documents and I've not needed any capacitor to do this in my version of the ArduinoISP.
Maybe a 10uF across Vcc and GND would help if you've got an iffy power supply.
I'm not sure what a 10uF cap would do across reset and ground other than delay the signal and keep it high for a while after it is shut down.
So we have two different uses for the reset pin, in one you are putting the AVR in the bootloader mode and the program is uploaded via the TXD and RXD pins. In the other, the reset is used for the ISP program upload which goes through the SPI pins. The former can use a small cap, the latter doesn't need one. Apples and Oranges.
Smiley
What is the problem?
Talk to UNO bootloader:
avrdude -c arduino -P com12 -b 115200 -p ATmega328P
Using ArduinoISP:
avrdude -c stk500v1 -P com12 -b 19200 -p ATmega328P
The first one uses a completely different baudrate.
The second one should still work even if the DTR line 'resets' the ArduinoISP sketch.
I can see some ambiguity if you were to recompile ArduinoISP.ino sketch to run at 115200 baud.
Yes, some old Arduino bootloaders run at 19200 baud. So it would be wise to recompile ArduinoISP to use a different baud rate.
David.
The theory is as david says: by running arduinoISP at a different baudrate than the bootloader, the initial autoreset doesn't matter - avrdude sends commands to the bootloader but it ignores them (because they are at the wrong speed, so it doesn't recognize them), and starts running the arduinoISP sketch, which DOES recognize them.
There are a couple of problems with this theory:
1) Original Arduino Unos shipped with a version of optiboot that would keep running the bootloader in the presence of ANY serial traffic, recognizable or not. (http://code.google.com/p/arduino... )
2) The bootloader timeout and the avrdude timeout/retry algorithms need to be compatible.
I've always had better luck using ArduinoISP on an Arduino that has the autoreset disabled (using the cap, or using an older, pre-autoreset board.)
None of the circuits in the ArduinoISP web page show the use of a capacitor:
http://arduino.cc/en/Tutorial/Ar...
5. Wire your Arduino board to the target as shown in the diagram below. (Note for the Arduino Uno: you'll need to add a 10 uF capacitor between reset and ground.)
On the Arduino Uno, you'll need to connect a 10 uF capacitor between reset and ground (after uploading the ArduinoISP sketch).
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I have read enough from the comments above to make me question whether what I (thought I) observed is correct. ie IDE wrote to slave but command line wrote to Uno. I will go back and verify this evening.
the cap discussion still confuses me and I wonder if it is historic.
If I look at the avrdude code - see below - the "ardunio" programmer option explicitly resets the Uno by asserting DTR (and RTS just in case). This resets the Uno which then starts in bootloader mode and accepts the program comms to write the uno flash.
The "stk500" option (presume this is same as stk500v1) does not reset the device so the arduinoIsp sketch will keep running and be ready to accept data and send on via the SPI to the slave device.
If the statements above are correct then does the cap still serve a purpose?
static int arduino_open(PROGRAMMER * pgm, char * port)
{
strcpy(pgm->port, port);
if (serial_open(port, pgm->baudrate? pgm->baudrate: 115200, &pgm->fd)==-1) {
return -1;
}
/* Clear DTR and RTS to unload the RESET capacitor
* (for example in Arduino) */
serial_set_dtr_rts(&pgm->fd, 0);
usleep(50*1000);
/* Set DTR and RTS back to high */
serial_set_dtr_rts(&pgm->fd, 1);
usleep(50*1000);
/*
* drain any extraneous input
*/
stk500_drain(pgm, 0);
if (stk500_getsync(pgm) < 0)
return -1;
return 0;
}
static int stk500_open(PROGRAMMER * pgm, char * port)
{
strcpy(pgm->port, port);
if (serial_open(port, pgm->baudrate? pgm->baudrate: 115200, &pgm->fd)==-1) {
return -1;
}
/*
* drain any extraneous input
*/
stk500_drain(pgm, 0);
// MIB510 init
if (strcmp(ldata(lfirst(pgm->id)), "mib510") == 0 &&
mib510_isp(pgm, 1) != 0)
return -1;
if (stk500_getsync(pgm) < 0)
return -1;
return 0;
}
smileymicros wrote:So I guess you missed point #5:None of the circuits in the ArduinoISP web page show the use of a capacitor:
http://arduino.cc/en/Tutorial/Ar...Quote:And the caption to the first image:5. Wire your Arduino board to the target as shown in the diagram below. (Note for the Arduino Uno: you'll need to add a 10 uF capacitor between reset and ground.)Quote:JJOn the Arduino Uno, you'll need to connect a 10 uF capacitor between reset and ground (after uploading the ArduinoISP sketch).
I'm going to have to look a bit deeper at this using the UNO. I thought I used the UNO with no problem, but maybe I got lucky.
Sorry,
Smiley
I'm going to have to look a bit deeper at this using the UNO. I thought I used the UNO with no problem, but maybe I got lucky.Sorry,
Smiley
I dug a bit deeper myself. I did in fact manage to get avrdude to connect to the ArduinoISP on an UNO without a capacitor across RESET and GND... much to my surprise.
When I'd tried this some months ago I'd had no luck. It seemed avrdude was timing out before the ArduinoISP could respond, due to the delay imposed by the UNO reset and bootloader running. At the time I saw similar behaviour with the Arduino IDE (1.0).
I don't know what I did differently to make it work now. I haven't yet confirmed the behaviour under the Arduino IDE.
JJ
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
the "ardunio" programmer option explicitly resets the Uno by asserting DTR (and RTS just in case).
This resets the Uno which then starts in bootloader mode and accepts the program comms to write the uno flash.
The "stk500" option (presume this is same as stk500v1)
does not reset the device so the arduinoIsp sketch will keep running and be ready to accept data and send on via the SPI to the slave device.
If the statements above are correct then does the cap still serve a purpose?
after re-investigating I can report a very silly mistake..... the led that I was monitoring on my target to verify the download OK was correctly referenced in the arduino code.... but wrongly referenced in the studio code.
everything was actually working OK all along :oops:
in the end.... using the stk500v1 programmer type and the arduinoISP sketch I am able to programme from the arduino IDE or from the the command line with code generated by either the arduino environment or raw code from studio.
I have not added any caps and all is well. whether this is a fluke with my particular Uno (rev 3 I think) or not I don't know.
Thanks to all for the valuable info.
The theory is as david says: by running arduinoISP at a different baudrate than the bootloader, the initial autoreset doesn't matter - avrdude sends commands to the bootloader but it ignores them (because they are at the wrong speed, so it doesn't recognize them), and starts running the arduinoISP sketch, which DOES recognize them.There are a couple of problems with this theory:
1) Original Arduino Unos shipped with a version of optiboot that would keep running the bootloader in the presence of ANY serial traffic, recognizable or not. (http://code.google.com/p/arduino... )2) The bootloader timeout and the avrdude timeout/retry algorithms need to be compatible.
I've always had better luck using ArduinoISP on an Arduino that has the autoreset disabled (using the cap, or using an older, pre-autoreset board.)
It should be possible to identify which release of optiboot is present on a punter's UNO. e.g. calculate a CRC.
I have run ArduinoISP on several different Arduinos and with several Arduino releases. I have never had a problem.
There are a finite number of official Arduino releases. So it should not be too difficult to make a definitive report about any optiboot+arduino problem.
I really can't see that a capacitor is necessary.
David.