RE: [avr-libc-dev] Re: [RFC] Unified ELF file

[Eric Weddington]

> -----Original Message-----
> From: Michael Hennebry [mailto:address@hidden
> Sent: Monday, September 24, 2007 8:08 AM
> To: Eric Weddington
> Cc: address@hidden; 'avr-libc-dev'
> Subject: RE: [avr-libc-dev] Re: [RFC] Unified ELF file
>
>
> What if a user doesn't want to assign a fuse,
> e.g. the last time he played with that fuse
> the cure required a soldering iron?
> Would one have to keep the sections separate to
> allow assigning only some fuses and lock bits?
>
> The avrdude wrapper I wrote assumes separate sections.

First, lets separate two concepts. The ELF file is just supposed to contain
the data (fuse, lock, etc.). It does not know, or care, about any
programming algorithms or what the user wants to do with that information.
Programming software (such as avrdude, or AVR Studio programmers) will take
that data and program the device according to how the user commands it. So
it is entirely up to the user to decide how they want their device
programmed.

The only thing that we need to do is to make sure that the format of the ELF
file does not inhibit the user from doing something useful. And you bring up
a good point. In the patch that I posted, these separate *input* sections
(.lfuse, .hfuse, .efuse) are combined into a single *output* section
(.fuse). What if a user only wants to program a single byte (for example,
hfuse)?

I propose a counter-argument: it makes no sense for *the user* to want to
program a single fuse byte. Here's why: The fuse bits, in total, are a
logical set of data. That's why they are called "fuse bits". The fact that
they are broken up into 2 or 3 separate bytes is arbitrary due to the
underlying physical organization of the memory on-chip. However, it is up to
the user to decide, for each fuse bit, what that value should be. And, more
importantly, the entire set of fuse bits are tightly bound to the particular
device *and* application that is being written for that device. This is why
it makes sense to set the fuse bit data in the application directly.

If the user willfully, or accidentally, ignores the setting of any fuse bit
(or, by default, a group of 8 fuse bits in a byte), then it's caveat emptor
and there is nothing that we can do to programmatically save the users from
themselves, other than specify the factory default settings. If the user
does not specify a particular byte (group of fuse bits), then automatically
setting them to default settings would follow the principle of least
surprise.

Now follow this to programming. If all the fuse information is set in the
ELF file, and the programming software is commanded to program all fuse
information, all is good. Why would the user only want to program partial
fuse information? The only reason to do this is for experimentation. And
doing so would be a violation of the fuse data that the programmer
originally specified in the source code (and hence put into the ELF file). I
would argue that if a user still wants to do this, then change the fuse data
set in the application (and hence changed in the ELF file), or to use other
existing mechanisms to program the fuses, for example, in avrudude one can
specify the fuse data directly on the command line.

I agree that the programming software needs to be intelligent about
programming all fuse bytes, to reduce wear. All programming software should
read the fuse byte, compare it with what should be programmed, and if they
are not different, then do not do an erase/program cycle.

The fuse data is logically coherent. If one wants to experiment, then there
are other existing means to do this. When a user has settled on the exact
values for all the fuses, then that information should be codified in the
source code, compiled into the ELF file, so that other users can safely
program the entire device, without human intervention and error to the
software engineer's specification. The whole point of this is not to monkey
around with "only changing one fuse byte". One can do this via explicitly on
the command line without ever having to change the layout of the ELF file.
If the ELF file format does not have to change, then it makes the most sense
to have a single memory area where *all* of the fuse information can be
explicitly included, and any avr-libc API should be able to specify a
default value if the user forgets to do that in their code.

Eric Weddington