Upload using programmer question(s)

hey gang-

I have never really messed with using the ICSP headers/SPI bus to upload sketches before..

(just recently actually).. but dont know much about it..

this involves the Arduino IDE & an Arduino Duemilanove 2009 board..

Some basic questions:

1.) Do you need to have the Arduino ISP sketch written to the Arduino before using the: "Upload using programmer" option in the Arduino IDE/ (File >>> Upload using programmer)

I understand doing this removes/over-writes the bootloader, making for quicker boot times, and giving maximum space on the chip (the space the bootloader would have normally occupied)

I have only even used my Arduino to flash blank chips with a bootloader... and then used an FTDI cable to upload sketches with.. (everything always seemed to work out)

recently.. I had a project that was a pcb with minimal Arduino circuit (no vReg, +3.3v @ 8MHz INTERNAL clock..etc).. and was very small in size, not much bigger than a microSD socket...

-and-

a project where the ICSP headers/pins/pads were forgotten about and not broken out...

instead of trying to solder directly to the pin on the ATmega328P-AU chip on the pcb..

I purchased one of these:
http://www.hobbyking.com/hobbyking/store/index.asp

so I could flash a bootloader to the blank chip,... once it was all assembled on the pcb... and then use the serial headers (that was broken out correctly) to upload sketches and use the serial monitor for feedback/debugging..etc..

however, with that cable I have above, I finally got to thinking about using the Upload using programmer option.. (since on the FIRST project mentioned above.. the ICSP pads are not through holes..but pads.. and are in odd locations due to size/space issues that had to be dealt with).. so I wouldnt have to solder on leads and un-solder them again after Im done..

makes this alot FASTER and easier (once the firmware is tested) to just Upload using programmer to these custom pcb's/projects instead of soldering on custom leads to flash bootloader.. then solder on new leads to upload the sketches..etc..

but this lead me to some questions...

Questions regarding chip (fuse?) settings:

1.) When I flash a bootloader to a chip.. I usually pick: (+5v/16MHz or +3.3v/8MHz or +3.3v/8MHz INTERNAL for BREADBOARD) depending on the project..
from my understanding when I do this.. it changes stuff on the chip (fuse settings..etc) to let the chip know that it should run @ +5v logic or +3.3v logic.. or what kind of clock to use/run at......right?

2.) If I am NOT flashing a bootloader to the blank chip.. and instead just use 'Upload using programmer'.. how does the chip know how to behave? how does it knwo its shoudl run @ +5v or +3.3v logic? or what clock speed to run at? or if it should use the INTERNAL 8MHz clock for example?

or should always flash the bootloader to the chip first (to set the fuses and what not).. even if after, you plan on using Upload using programmer option to bypass the bootloader wait 7 get more space back..etc..??

thanks!

Both Burning bootloader or Upload using programmer requires the use of an ISP programmer. If you are using the Duemilanove as ISP then yes, you need to load the ArduinoISP sketch first.

  1. The fuse settings have nothing to do with voltage levels. They are mainly for setting the clock options and booloader options.

  2. Before flashing the sketch using Upload using programmer, you need to at least once burn bootloader, mainly to set the fuses for the clock options you are using.

#2 - got it..

thanks!

(makes sense)

You can upload a sketch to a devie using the ArduinoISP sketch BUT you need to know how to run AVRDude from the command line and where the .HEX file of that sketch is saved. You don't need a bootloader in the destination device to do this. It is not done from the Arduino IDE, but from the command line (a DOS prompt)

Hmmm. Maybe I should write a little program in VB that would let you do that - fill in the blanks and hit go and it would call AVRDude with the appropriate command line....

I do this all the time from the IDE.
Connect the programmer - I use an AVR ISP from MDfly.com, or Atmel AVR ISP MKii, just to keep the clutter down.
Burn a bootloader first, gets the fuses set correctly. Select a board type that matches your uC and crystal speed and voltage.

Then, File:Upload Using Programmer to upload the sketch you have opened in the IDE.
You don't need to mess with avrdude commands or finding the hex file that you may have created at an earlier time.

thanks everyone..

I understand now..

a bootloader, or some sort of 'step', DOES need to be done to a blank chip before just using "Upload using programmer" to set the fuses on the chip..

Last Question:

Since 1 of my projects using the 'breadboard bootloader' (+3.3v @ 8MHz INTERNAL clock)...
and I believe they come set to run on internal clock from factory...

does (for example) writing the Breadboard bootloader to the chip first (in this case) have any special use?
(ie: is it setting any fuses differently than how the chip comes configured from the factory?)

thanks~!

Yes, most often the factory settings are set to 1MHz internal clocking, the 8MHz/DIV8. So if you want to run at 8MHz, then you do need to change the default fuse settings by burning bootloader. Also note, that it is possible to create an empty bootloader file, so that you only really are burning the fuses for the clock settings.

Hello, hopefully someone on this thread might be able to pick up my question, as the present topic is pretty close. In my understanding, a typical uC needs a boot file to specify clocking parameters. The default clock setting might be, for example, 1 MHz internal, based on an 8 MHz XTAL. Now, if this is true, would one expect to see across the XTAL terminals a square wave at 1 MHz? I have an Atmel uC and assumed it would start its clock on its own, but there is no clock signal present.

Thanks.

Jsevic:
Hello, hopefully someone on this thread might be able to pick up my question, as the present topic is pretty close. In my understanding, a typical uC needs a boot file to specify clocking parameters.

Not actually in the bootloader, but in the "fuses", which are in a separate memory space. You will always have the fuses set to something whether or not you have a bootloader programmed.

Jsevic:
The default clock setting might be, for example, 1 MHz internal, based on an 8 MHz XTAL. Now, if this is true, would one expect to see across the XTAL terminals a square wave at 1 MHz? I have an Atmel uC and assumed it would start its clock on its own, but there is no clock signal present.

Thanks.

The factory default clock source parameters are set for an internal clock, so you won't see anything on the external clock pins until you have set your fuses to use a clock source on those pins.

hiduino:
Yes, most often the factory settings are set to 1MHz internal clocking, the 8MHz/DIV8. So if you want to run at 8MHz, then you do need to change the default fuse settings by burning bootloader. Also note, that it is possible to create an empty bootloader file, so that you only really are burning the fuses for the clock settings.

Hardly worth the effort as the first upload using programmer from the IDE will erase the flash and bye bye goes the bootloader, never to return unless reburned.

hiduino:

  1. The fuse settings have nothing to do with voltage levels. They are mainly for setting the clock options and booloader options.

Not quite true -- the fuses also specify the BOD reset voltage levels, which are typically configured with respect to the operating voltage of the chip. Surprised no-one picked you up on this.

hiduino:
2) Before flashing the sketch using Upload using programmer, you need to at least once burn bootloader, mainly to set the fuses for the clock options you are using.

Also not quite true -- it is perfectly possible to program a "raw" chip with a sketch, using the factory default fuse settings. You can even set your production fuse values at the same time if you are using an avrdude script or directly from the command line.

But, the upload can be slow, because the programmer has to run its clock no faster than 250KHz, to communicate with the factory chip with its clock set at 1MHz. So in practice it's usually more efficient to first write fuses to operate at the faster speed (which is quick,as there are only a handful of bytes to be written), and then upload the main program at the faster speed.