[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joerg Wunsch
Subject: Re: [avr-chat] Re: GUI wrapper for avrdude
Date: Mon, 27 Aug 2007 22:24:49 +0200 (MET DST)

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.

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.  The work^H^H^H^Hhackaround has been to
introduce offsets which are simply way beyond the address space
implemented in any AVR's single memory area.  There's a
well-established set of offsets already (with AVR-GDB being the one
using the most different memory regions right now), and if we have to
extend the list of offsets (like for fuse bits), we can always do.

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 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.

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]