avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] RFC: fuse bit handling from a file


From: Joerg Wunsch
Subject: Re: [avrdude-dev] RFC: fuse bit handling from a file
Date: Thu, 13 Feb 2003 16:13:02 +0100
User-agent: Mutt/1.2.5i

As Brian Dean wrote:

> I'm willing to do this for avrdude.

Fine.

> As you mentioned, avrdude would prefer any fuses be in their own
> memory file, i.e., hfuse.hex, lfuse.hex, etc since that would work
> today without any changes to avrdude.  However, I can see how that
> might not be the best solution for other avr tools.

Yep, it would require (up to) three different files to be created
using avr-objcopy.  All this needs to be handled within a single
generic Makefile, regardless of which device type to program.
Experience shows that people are always too lazy to actually even read
the "make" documentation and/or understand what is there in the
Makefile...  They tend to use whatever Makefile we give to them, and
then bitterly complain if it doesn't work for them, telling you that
make exited with error code 1. :-/  (Eric already sounds like a broken
record in pointing people to the "make" documentation. ;-)

> A seperate memory section produced by avr-gcc/avr-libc, seems ok.

Btw., unless you plan to read the ELF file directly :), you don't need
to care much about this.

I have no idea about the endurance of the fuse bits.  Maybe it's a
good idea to first verify whether they already match, so programming
them can be skipped?

> Within avrdude, I could look for a special memory type, "fuses" or

"cfuses" -- combined fuses

That would be unambiguous with the existing names ("fuse" is already
taken on devices that have only one fuse bit cell).

> whatever, and then break that up and populate the seperate fuse
> memories of whatever part is currenctly being operated upon.  Within
> the avrdude.conf config file, it may be handy to tell avrdude at what
> offset within the "fuses" memory section each fuse byte resides (and
> the length - currently they are all one byte, but I don't know if
> that's a guarantee for future parts).

I think it is, by now, Atmel has always invented a new name when it
came to extending the fuse bits. :-/

But yes, these ideas appear OK to me.

Thanks!
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

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