RE: [avr-chat] Re: GUI wrapper for avrdude

[Eric Weddington]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
>  On Behalf Of David Brown
> Sent: Sunday, August 26, 2007 3:04 AM
> To: address@hidden
> Subject: Re: [avr-chat] Re: GUI wrapper for avrdude
>
> On some microcontrollers I've used, the fuses are programmed
> as part of
> the memory.  For example, on the COP8 devices, the code
> memory is from
> 0x0000 to 0x7fff, while the fuses are from 0x8000 to 0x8005 (IIRC).
> Perhaps it's possible to pick a similar "standard" for the
> AVRs, so that
> gcc support for fuses needs nothing more than a new placed section in
> the linker files, along with a few macros in a C header file
> to fill the
> section, and support from avrdude and other programmers.  Obviously
> you'd also want to get Atmel's support in AVR Studio, but the
> benefits
> of having the fuse settings as part of the hex file would be large.

I will echo Joerg's comments, in that this idea has been discussed already
recently. I think there's a lot of agreement for something like this.

I don't know about having the fuse settings as part of the *Intel hex file*,
per se. IMHO, it makes more sense to teach avrdude how to read ELF files.
For example, the EEPROM section is not copied out to the Flash hex file. The
EEPROM section is copied to its own hex file. But if avrdude knows how to
read ELF files directly, then all the sections needed are in a single file.
If they're in a single file, then a user could easily distribute the single
ELF file (with an invocation of the avrdude command line) to a manufacturer
for automatic programming, no error-prone GUI manipulation required.

What is needed now is to decide what should be the offsets. Ideally they
should leave plenty of room for potential expansion, and it would also be
ideal if the offsets would allow the AVR32 address space. Thoughts, anyone?

Getting support in AVR Studio is not a problem if the basic issues are
addressed.

Eric Weddington