Go Down

Topic: "Upload Using Programmer" and reported sketch size/max flash space (Read 1 time) previous topic - next topic

cal-eng

Jun 10, 2013, 03:50 pm Last Edit: Jun 10, 2013, 05:45 pm by cal-eng Reason: 1
Trying to get a bit of clarity on what the "Upload Using Programmer" option actually does with respect to the bootloader and available flash space on the Arduino board in question.

The general (mis?)understanding is that "Upload Using Programmer" allows you to use all the flash space on the MCU, and removes the bootloader.  This sounds plausible, but unless you change the AVR bootloader fusebits it seems that this won't ever work that way...

It seems with all boards, the reported maximum size available for a HEX file does not change even if you use "Upload Using Programmer", which contradicts the most basic assumption about this feature, but makes perfect sense!  Also, if the compiled HEX file goes over the maximum listed in "boards.txt", but below the MCU limit, the compile will fail, which is to be expected..

I'm assuming that the AVR is quite robust and even though you have a bootloader reset vector in place, when there is no bootloader code present it simply "loops around" and executes code from address zero.

In the case of Arduino, a custom entry in boards.txt could easily overcome the bootload-specific size limit, but I assume that new fuse bits also need to be set to remove the bootloader settings (size and reset vector)?

I assume that a hex file that arbitrarily exceeds the bootloader boundary (by raising the size limit in boards.txt, but not adjusting the bootloader settings) will crash horribly, or do all sorts of other odd things?


Can anyone clarify that a compiled sketch will run correctly if the fusebits are re-set and the code uses near the maximum amount of flash?  Or, any other observations with respect to the bootloader fusebits, HEX size, etc.



Thanks.

Jeremyvnc

I am also wondering all of this.  I've got a complex system that is pushing the boundaries of the ~30k available (up to 26k) and i'm not some yet.  I don't need the bootloader because I only program it using the avrispmkii.

I've just optimized the code for ram using progmem and f() everywhere and am continually optimizing it for flash but I would like to stay away from the core arduino libraries.

Any thoughts on the original poster's question?
Thanks.

techydude

The general (mis?)understanding is that "Upload Using Programmer" allows you to use all the flash space on the MCU, and removes the bootloader. 
just stumbled across this post.  after agonising through issues like these myself with programming my own PCBs via Arduino IDE, i figured an answer might help others :)

correct.  the bootloader factory-programmed onto all Arduino standard boards allows programming via a serial/USB i/f.  but if you prefer to program via a device-programmer (like the Atmel AVRISP mkII, & many others), then doing so will erase (remove) the bootloader from it & you regain the space normally consumed by the bootloader for yourself - in other words, for an ATmega328, the entire 32kB Flash space, you don't lose (~4kB?) to the bootloader.

This sounds plausible, but unless you change the AVR bootloader fusebits it seems that this won't ever work that way...
correct.  Arduino handles this for official/standard Arduino boards.  for other 'Arduino compatible', & for your own, boards you need to create a new entry in boards.txt with appropriately set fuse-bits & other parameters, so that your app runs instead of the bootloader.

(& every time the IDE is updated, you need to copy those custom entries & other stuff over from the old Arduino installation to the new, which is why v1.5.x beta now supports these 'custom' board definitions in the Arduino/hardware folder, which is of course preserved/untouched across upgrades.)

It seems with all boards, the reported maximum size available for a HEX file does not change even if you use "Upload Using Programmer", which contradicts the most basic assumption about this feature, but makes perfect sense!  Also, if the compiled HEX file goes over the maximum listed in "boards.txt", but below the MCU limit, the compile will fail, which is to be expected..

In the case of Arduino, a custom entry in boards.txt could easily overcome the bootload-specific size limit, but I assume that new fuse bits also need to be set to remove the bootloader settings (size and reset vector)?
I'm not familiar enough with Arduino's innards to say for sure, but I suspect the Arduino IDE doesn't bother to show correct free-space figures in the event of using the 'Upload using Programmer' method, because it's done so rarely by Arduino neophytes, & doubling the number of boards shown in the menu would confuse too many people.   But basically you are right, if there were 'dedicated' entries in boards.txt for use in the event of 'Upload with Programmer' *and* if the person making those entries got the figures right, *then* the free-space numbers shown should be correct, & genuine compile attempts larger than the AVR chip's actual Flash space will fail.  For standard Arduino boards, they are not, I suspect as a simplicity measure.

I assume that a hex file that arbitrarily exceeds the bootloader boundary (by raising the size limit in boards.txt, but not adjusting the bootloader settings) will crash horribly, or do all sorts of other odd things?
Can anyone clarify that a compiled sketch will run correctly if the fusebits are re-set and the code uses near the maximum amount of flash?  Or, any other observations with respect to the bootloader fusebits, HEX size, etc.
good question.  for my own PCBs with ATtiny & AT90USB1286 chips, I've added explicit entries in boards.txt with correct fuse-bit settings & other parameters, and "it just works".  bit if you get fuse-bits or other size parameters wrong, then yeah, "your mileage may vary" lol

Anthony.

Go Up