[avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude Feature Request and Call for Volunteers

[Joerg Wunsch]

Eric,

I generally agree with your idea to allow setting the fuse values from
within the source code.  I've tossed that idea around on the avrdude
list a couple of years ago already.

As Eric Weddington wrote:

> 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

That somehow ignores those parts (admittedly older AVRs) that only
have a single fuse byte.  My personal proposal (subject to discussion,
of course) is to just invent a single .fuse section which can take up
to three bytes.  AVRDUDE then needs to be extended so it can handle
that combined fuse address space, and properly "distribute" it across
the actual fuses.  (Some of the programming protocols used already
work that way, but that doesn't help us much: other protocols like
manual ISP use three completely different commands.)

The only issue is with all those historic AVRs: they didn't offer a
uniform view to the fuse bits, but the actual bit position depended on
the programming method used.  Frequently, only HV programming has been
able to program all fuses there at all.  Not sure how to handle these.

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

That's a good idea anyway, but the fuse reading IMHO doesn't depend on
that at all.  I believe with the extended hex format, avrdude could
already be taught to understand all those fictitious offsets right
now, so if you specify a hex file that has both, flash and EEPROM
settings, the latter can be recognized by their 0x810000 offset.

However, adding that logic to avrdude will be a bit of work, as the
actual file needs to be parsed for its logical components (which then
in can be turned into single update operations for each memory space
in question).  Perhaps it would be easier to use a different option
than -U to specify a single combined address-space file.  Also, it
might be useful to be able to suppress updating individual parts on
some invocations.  Not only that updating the fuses to the same value
could perhaps contribute to some EEPROM cell wear, but you might not
want to re-initialize your EEPROM all the time as well.  (Isn't that
what has already been bothering AVR Studio users? ;-)

* * *

The next step will be to extend avr-libc so it could offer symbolic
operations to handle the fuses.  Something like:

LFUSE(RC_OSC, CKDIV8);
HFUSE(EESAVE, JTAGEN);

By that time, we probably caught up with what PIC users did already
have for some years now. :-))

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

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