[avrdude-dev] [RFC] avrdude Feature Requestand Call for Volunteers

[Wouter van Gulik]

...<snip>...

> 
> Thanks for the feedback. Would an algorithm such as this be acceptable?:
> 
> 1. If -U switches exist on command line, then follow those sequences 
> exactly 2. else (no -U switches exist on command line) follow 
> automatic sequence:
>       2.1. Fuses (verify, if different: write and verify)
>       2.2. Flash (erase, write, verify)
>       2.3. EEPROM (verify, if different: erase, write, and verify)
> 
> Eric
> 

This sequence would prevent us from programming some fuses. For example if
we wish to use the reset pin as IO we can't reach the device any longer. But
programming the fuses at the end of the cycle might be slow (running off
slow internal clock). So I suggest we need something like:

        2.1. Fuses (setup fast clock) (verify, if different: write and
verify)
        2.2. Flash (erase, write, verify)
        2.3. EEPROM (verify, if different: erase, write, and verify)
        2.4. Fuses/LockBits (verify, if different: write and verify)

I don't now if all AVR devices have a separated lock byte. And I guess not
all "programming-preventing" bits are in the same byte and same bit location
across the complete AVR series.
And of course the R&D would not want the last step to be done.

More on topic, can't we make a single executable file that contains the
AVR-DUDE programming as well as the file it needs to program? We would have
a single file containing the flash, eeprom and fuse bits, we now still need
to define: the programmer type, the programmers clock speed, etc.
Something like a script or batch file is mostly used for settings these
options. Can't this be contained within the executable along with the ELF
file(s)? Or maybe in the ELF file?
This would prevent change of commandline's, using wrong input files etc. The
only thing the production department need is this single file.
To me this seems even more useful. 
Just my 2 cent,

Wouter