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

[Eric Weddington]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
>  On Behalf Of Joerg Wunsch
> Sent: Monday, August 27, 2007 2:25 PM
> To: address@hidden
> Subject: Re: [avr-chat] Re: GUI wrapper for avrdude
>
> Michael Hennebry <address@hidden> wrote:
>
> > You can let the tool read or infer the offsets from the elf file.
> > E.g. any 1 byte section named .hfuse can be infered to carry fuse
> > data regardless of its offset.
>
> What about things like user-defined EEPROM sections?  User-defined ROM
> sections?  Oh, there's already a popular one named .bootload.
>
> I'm not too fond about the idea of hardcoding section names.  This
> didn't work too well in the past -- look at all the people who try to
> debug an application consisting of a .text plus a .bootload section in
> AVR Studio within a single application.

To be fair, there may be a bug in AVR studio where it doesn't load any other
code section other than .text. That obviously needs to get fixed.

>
> Let's face it, our linker can already only handle a flat (32 or more
> bits wide) address space anyway.  It will take any section starting at
> address zero as an overlap of another section starting at address
> zero, and complain about it.

Which, I agree, is bad news.

<snip>
> The advantage is that the result will not only work on ELF files but
> also on image files like Intel Hex, provided (obviously) you generate
> a single hex file combining the contents of *any* loadable section,
> i.e. you don't have any -j or -R options on the avr-objcopy
> command-line.  The offsets will then simply propagated into the hex
> file, and all that needs to be done is teaching avrdude about the
> physical memory regions each offset describes.

This is where I differ, but only slightly. AVR Studio already knows about
ELF files. If we teach avrdude about ELF files, then there is no need to
even deal with the Intel hex file format at all. The Intel hex file format
is only needed because of legacy programmers (BP comes to mind). These
legacy programmers will not know that there are multiple address spaces
(program, eeprom, fuses) in a single Intel hex file and they will barf. It
will be near impossible to get them to use our extended Intel hex format.
IMHO, better just to stick with ELF, because it was designed to be
extensible, and teach the tools to use ELF.

> This could be done in
> the config file on a per-device base, so suppose Atmel would suddenly
> start producing a new superior controller, say they call it Xmega :),
> which considerably extends the flash ROM address space, well, the
> Xmega family would simply use a different set of offset than the
> classic AVRs used to use.

What I would very much like to avoid is having one set of offsets for
"Xmega", another set of offsets for "Ymega", and a third for "Zmega". If we
can choose a set of offsets that will *probably* work for all AVR families
(and ideally for the AVR32 as well, but I'm flexible on this point), then I
can almost *guarantee* that these offsets will be adopted by AVR Studio
tools as well. ;-) I'm open to suggestions...

Eric Weddington