john1993:
im using v5.11.1 and the command line is " avrdude -p m128 -c usbasp -U flash:w:t.hex".
ok. So there is no -P option. I use -Pusb but it turns out that for usbasp programmer type the port
is ignored so that explains the port "lpt1" stuff.
i never turn on the verify you referred to. in my experience if theres no problem the first time then it works the next million times so no need to verify. specially since verify takes several times longer than write.
I keep hearing (reading) you say this.
But I'm not understanding what you mean because it doesn't make sense to me.
The -V option disables verification of the image after the burn. By default the burn is verified.
So it isn't something your turn on it is something you can turn off.
Using -V speeds things up because avrdude isn't reading the flash after the burn to verify it against the image.
there is no option to lower the boot address. even if that made much difference, which i dont think it would, client requires it to be in the top 256 bytes.
What I meant by this is that if you change the fuses to make the bootloader section larger,
the bootloader will start at lower address. With the largest section it will start at 0x3800
vs 0x3F00
By starting at lower address, your code will end at a lower address. That means from 0 to the
end of your bootloader code will be smaller and that will speed things up (a little).
Where the code lives or the size of the bootloader block isn't that important for debugging.
i developed this loader a couple years ago for smaller avr chips but now its needed for m128 and m1284. it works with any terminal program (no avrstudio or avrdude) because it accepts hex files directly instead of all that stk/109 baloney. also incorporates a bios which if im not mistaken is unique among bootloaders. and generally much faster than most isp programming.
I've also seen programmers that take a simple srecord file as input. While simpler, overall it isn't
as functional or as robust as a an actual program with a more advanced protocol.
Things like setting fuses or verifying the burn are not possible with the simpler interfaces.
i wonder why usbasp code to skip ff was deleted. is this the root of the problem? hard to believe since other programmers do it too. why cant avrdude skip unused locations? sounds like a bug to me. unfortunately im not in a position to modify usbasp or avrdude compiler code. only assembler atm. i see at least three others in recent posts in this forum similarly inconvenienced. and they are not involved in thousands of downloads like me. any other suggestions?
Good questions.
My personal belief is that much of this goes back to there being too many ways to update the flash
as well as some liberties taken by certain programmers/bootloaders.
The lower level code in avrdude does not know what was done prior to it being called nor what will be done after.
Some programmers/bootloaders will not erase the part even when they are told but rather erase each page
as the page is written. With those types of programmers/bootloaders skipping the 0xffs will not work.
The fastest way to update the flash is to erase it first then do full page writes only to the pages that
have something in them that needs to be written.
While its speed typically isn't an issue,
avrdude has taken the approach that working in many environments takes priority over speed.
The issue that I see impacting you is that avrdude doesn't seem to be very smart when it comes to sparse images
Internally it allocates a buffer for the full flash size, sets it to all 0xff, then reads in the data from the file.
Then it burns the flash from 0 up to the highest address used.
For a bootloader, that means you end up burning the entire part vs just the bootloader
at the top.
UPDATE:
I've just looked at the avrdude code to look for the "smarts" that westfw refered to as being in 5.11
It appears to me that this is not in the 5.11 or 5.11.1 source I have checked out
but it does appear to be in the mainline trunk code.
avr.c was updated with this "smarts" on sept 14, 2011
Now I'm really curious and will have to look closer at the revision history to see what is going on.
--- bill