[avrdude-dev] [RFC] avrdude Feature Request and Call for Volunteers

[Eric Weddington]

All,

First, my apologies to those who are subscribed to both lists and getting
this message twice. I wanted this initial post to have a wider audience, but
further discussion should be limited to the avrdude mailing list, i.e.
please remove the avr-gcc-list address from the CC list when replying.

Problem: 
There are many users of the AVR toolchain that would like to have the
ability to automate the programming of their devices. There are problems
when it comes to fuse information. AVR Studio has a GUI where the user has
to manually set the fuses in checkboxes, which can be error prone when it
comes to automating the programming process. The current solution is to
create a batch/script file that calls command line programming tools (either
avrdude, or Atmel's command line tools) with the fuse information on the
command line. However, this fuse information is not tied to the application
directly. When dealing with a line of products, it can get confusing making
sure that the correct fuse information goes with the correct application.

Needs: 
A way for the software engineer to set the fuse information in the
application directly, so that it is embedded in the final output file and
for the programmer software to be able to take the final output file, that
contains the application for the flash, eeprom data, and fuse data, and to
be able to Do The Right Thing and automatically program the device with all
the relevant information.

Proposal:
There is a way, right now, to embed fuse information into the final ELF file
created by AVR GCC. It can be easily done by creating a const uint8_t
variable, assigning the particular fuse byte and then putting an
__attribute__ on the variable to place it in its own named section (much
like the way a bootloader is done). I propose that we standardize the
section names that are used for fuse information as:

.lfuse = Low Fuse Byte
.hfuse = High Fuse Byte
.efuse = Extended Fuse Byte

These sections should consist of a single byte in the final ELF file.

Avrdude should be modified to provide the rest of the solution:

- Modify avrdude to be able to read an ELF file directly. To do this,
avrdude should use the BFD library found in the GNU Binutils project.
Avrdude should be able to recognize the following sections in the ELF file:
.text, .eeprom, .lfuse, .hfuse, .efuse. Note that, initially, only *reading*
an ELF file would be needed. Writing to an ELF file format should be
deferred (perhaps indefinitely).

- If an ELF file is specified on the avrdude command line, then the
programming algorithm should be something like:
        - If fuse sections exist (.lfuse, .hfuse, .efuse), then program the
fuses with the .?fuse sections, verify fuses
        - If .text section exists, erase flash, program flash with .text
section, verify flash.
        - If .eeprom section exists, erase eeprom (if fuse settings allow),
program eeprom with .eeprom section, verify eeprom
The idea is that the user should not *necessarily* have to specify every
single step on the avrdude command line. It should automatically be able to
Do The Right Thing. However, the implementation should not prevent the user
from specifying every step on the command line (using the -U switch), if the
user wants to have a different order

The rationale for doing all this via the ELF file, is that ALL of the
information is contained in the single ELF file. Otherwise, there has to be
further commands in the Makefile to convert all the sections in the ELF file
to separate Intel Hex files (including the single byte fuse information) and
then the Hex files are programmed into the device. This causes further
hassle especially if the place that does the automated programming is
separate from the engineering. Multiple hex files need to be sent with the
programmer software, and this can be error prone. It is less error prone if
a *single* ELF file can be sent with the programmer software (avrdude.exe,
avrdude.conf), and this single ELF file corresponded with a single product,
and the command line for avrdude is very simple and the programmer knows the
correct programming algorithm, i.e. it just becomes a black box and easy to
use.

I'm certainly open to ideas to further enhance this feature request, or if
I've missed something. However, I don't want to expand the scope of the
feature too much to make it difficult to impelement.

I am also raising a call for volunteers! :-) I think that this would be a
useful feature, and I hope others do too. I also know that there is never
enough help on the Open Source projects. Please let us know if you would be
interested in helping out in implementing this feature on avrdude. :-)

Thanks,
Eric Weddington