Is there any way to speed up the ISP programming process?

I'm using a 1284P in my project and my uploads seem to be going really slow and I believe it is because the IDE is erasing all the flash on board each time it uploads. Is it possible to avoid doing that and just leave any garbage data after the program? I would assume it would not interfere with the program for it to be there and since my programs right now are small it should greatly speed up my testing process.

How slow is slow? FLASH memory must be erased before it can be programmed.

Eh, feels like it's taking maybe 20 seconds? Haven't timed it. Just seems slow.

Also, I have an old laptop I used to program some other chips and with the same programmer it is way faster than my Macbook. Any idea what might cause that?

In short - YES, write smaller programs...

What is your process in programming the chip?

Well, I set the fuses like so the first time because I was having trouble getting it to program (the IDE hides the option to upload with a programmer so even though I had a programmer selected I was getting com port errors and didn't know why until I figured out the right upload option was on the fil emenu):
http://www.frank-zhao.com/fusecalc/fusecalc.php?chip=atmega1284p&LOW=CE&HIGH=F9&EXTENDED=FF&LOCKBIT=FF

But the boards.txt file has the following fuses:
http://www.frank-zhao.com/fusecalc/fusecalc.php?chip=atmega1284p&LOW=FF&HIGH=DE&EXTENDED=FD&LOCKBIT=FF

I'm not sure if they get programmed though because a couple weeks ago I had a chip on a breadboard that was running slow and I was using the same boards.txt and the right chip selected on the menu. So I don't think it was being programmed to use my external oscillator. But the current chip is running at the right speed, going by the fact that my led now blinks once a second like it's supposed to.

Other than that, I just select upload via programmer from the file menu, and I have usbtiny seleced for programmer and avr-developers.com selected as the board for my 1284p.

The thing about one computer programming faster than the other was with 328P's. I haven't tried it with this chip; I don't have time to mess around with that right now I gotta get this board working pronto and the slow programming is only a minor inconvenience.

Use an Atmel AVR ISP MKii within AVR Studio- really fast, once you get past the reeeeeally slow opening screen - it takes so long, I use File :Upload Using Programmer within the IDE instead.

What size image are you uploading? (What size is the dot-hex file?)

scswift:
I'm using a 1284P in my project and my uploads seem to be going really slow and I believe it is because the IDE is erasing all the flash on board each time it uploads. Is it possible to avoid doing that and just leave any garbage data after the program?

According to the datasheet for the Atmega2560 a chip erase takes a maximum of 9 mS, so I don't think that is the big bottleneck (I can't find the figure for the 1284P but I presume it is similar).

The hex size varies but one was up to 44K.

I've also been getting avrdude verificatons errors, though the slowness has occurred before this and with multiple chips. I then found the verbose option and turned that on. It takes 24 seconds to write 8400 bytes. Then it takes 14 seconds to verify it, then I get an error about a byte missmatch, but my program still seems to do what it's supposed to.

I've unchecked the preference to verify code after upload, but it still seems to be doing it and I've restarted the IDE to be sure. Is there no way to stop it from spending 14 seconds verifying code when it is going to error anyway?

According to one of ladyada's webpages, the usbtinyisp takes a second to program a kilobyte. Maybe you need a faster programmer. The AVRISP mkII sells for $35 and it is supported by Atmel.

http://www.ladyada.net/make/usbtinyisp/

I'm actually using this:

But I don't know if it's any faster or not. Since it's using the usbtiny drivers perhaps not.

According to one of ladyada's webpages, the usbtinyisp takes a second to program a kilobyte

Hm, that's only 8kbps. Is the bottleneck is in the programmer-programee interface? Or is the bottleneck in the PC-usbtinyisp interface (which appears to be bit-banged without the benefit of a FTDI or Max USB-serial IC)?

Can you post the avrdude commands that you are using. Also, have you tried adjusting the ISP frequency?

You can use the -B option to specify the ISP speed. By default the value is 10 which means 100KHz clock, this is good for target clock speeds > 500KHz. If you want the high speed clockrate (400KHz) for target frequencies > 4MHz you can use "-B 1" to speed up programming
To calculate the SPI frequency from the delay value, use this formula:

SPI clock frequency in KHz = 1000/(1.5+B) where B is the delay value

In general, the clock frequency should be at least 4 times larger than the target clock frequency. Try "-B 32" if you're having clocking issues, that should handle even 128khz clocks.

source: USBtiny-based AVR Programmer

I wrote a programmer that reads files from an SD card, here:

It took something like 48 seconds to check, upload, verify 60518 bytes of code. I think you can crank up the rate if the target processor is running at a reasonable rate (eg. 16 MHz). But, under a minute sounds reasonable.

It takes 24 seconds to write 8400 bytes. Then it takes 14 seconds to verify it ...

That sounds slow by comparison.

I haven't had the time yet to try changing the frequency but I have gotten serial uploads to work and they are super fast in comparison to what I was getting with ISP. I still willw ant to figure out why ISP is slow though when I need to put the final code on all my boards, but that will have to wait a few days.

SPI clock frequency in KHz = 1000/(1.5+B) where B is the delay value

In general, the clock frequency should be at least 4 times larger than the target clock frequency.

Is it just me or is this backwards, I think it meant to say "the target clock frequency should be at least 4 times larger than the source SPI frequency".

Anyway, if B is 0, then the SPI clock should end up about 666kHz, which even if we allow for a 10x clock factor, should work on a target chip running at a 6.66MHz CPU clock. So even an 8MHz Atmega should, in theory, be able to accept ISP with -B 0. (This is assuming, of course, that your programmer can accept data from the PC at > 666kbps.)

I would agree that the target, being programmed, should be operating at a higher clock frequency than the SPI frequency used for programming. Otherwise it couldn't respond.