how to program arduino with avrdude and AVRISPmkII *without* nuking bootloader?

Hi guys,

I can program the arduino using the bootloader. Or I can program it using AVRISPmkII, but that
nukes the bootloader so I think have to replace it with another avrdude command before I can
use bootloader programming again.

Also, the bootloader programming method (-c arduino avrdude option) is nice and fast, its like
its only rewriting the pages in question for small programs. I'd like to get the AVRISPmkII
programming to be that fast, and also not necessarily nuke the bootloader. I've tried using
--section-start=.text=0x7800 at link time but that doesn't do it. I've tried -D option to
avrdude to skip the erase but it still takes a long time, nukes the bootloader, and results
in a non-working program.

Any have a compile/avrdude recipe that can do what I'm looking for?

Also, I couldn't find any good documentation on what --section-start and -Map options really do?

Thanks,
Britton

If you're having problems programming with the AVRISPmkII, why do you want to use it? Why not just use the bootloader for programming?

I don't think you can program the chip with an external programmer without nuking the bootloader. Flash has to be erased before it can be written, and the only "erase" command available to external programmers is "chip erase" (the bootloader is allowed to execute a "page erase" command, but this is not available to SPI or even parallel programming.)

I'm working on a package designed to help people migrate from arduino to a raw uc environment if they want. Don't get me wrong I love arduino but I think one of its nicest features is people can get a gentle start with uc but then move to pure C and really mimimal
uc hardware.

So getting started using the ISP is a useful step maybe. Also, the bootloader seem to leave the chip in a slightly different state than AVRISPmkII program (e.g. IO lines set for output). So for migrating to a fully embedded design it looks useful to go to ISP programming eventually.

I'm working on a package designed to help people migrate from arduino to a raw uc environment if they want.

Then why bother with the bootloader? If the user has "moved on" to using a programmer, why would they want the bootloader?

Also, the bootloader seem to leave the chip in a slightly different state than AVRISPmkII program (e.g. IO lines set for output).

I know that's the case for pin 13 (the on-board LED) and I suspect that's the case for pin 1 (TX). Are there other pins effected by the bootloader? Other hardware differences?

the bootloader seem to leave the chip in a slightly different state than AVRISPmkII program (e.g. IO lines set for output).

This shouldn't be the case for the new bootloader (optiboot.) It uses the WDT to start the sketch immediately after reset, so EVERYTHING that is set by reset should be in the correct state. (alas, this is not quite everything that people expected to be set by reset, as was discovered during the Uno SMD deployment.)

You can certainly write a tool that always reloads the bootloader after a chip erase, even if it has to read that out of the chip itself, but that would be a bit contrary to your goal of using "standard" tools...

So for migrating to a fully embedded design it looks useful to go to ISP programming eventually.

So go ahead and nuke the bootloader. If and when they want to go back to the Arduino environment they can reload the bootloader using the ISP.

Don