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

[Michael Hennebry]

On Mon, 24 Sep 2007, Eric Weddington wrote:

> 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

As I look at the spec sheet for the ATmega168,
I would say that that is not true.
It's true for the low fuse byte, which is all clocking.
It's not true for the high fuse byte.
It's trivially true for the extended fuse byte.

Fuse bits + lock bits certainly do not form a coherent whole.

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

What about clocking agnostic code?
Given the choice between fake fuse data and none,
one should pick none.
Fake data is in the same category as incorrect comments.

The person who loads it might not be the person who made it.
It might not even be a person who usually does such things.
In fix-it mode, information can get lost.
Fake data is one more ting to trip over.

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

Failure is better.
Defaults, including factory specs, will produce surprise.
Early surprises are better than late surprises.

-- 
Mike   address@hidden
"Horse guts never lie."  -- Cherek Bear-Shoulders