RE: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude Feature Request andCall for Volunteers

[Eric Weddington]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Friday, March 09, 2007 2:21 PM
> To: address@hidden; address@hidden
> Subject: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude 
> Feature Request andCall for Volunteers
> 
> 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.

Yes. But now it's really needed. :-)


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

Hmm. I see what you mean about the older AVRs. My concern with having a
single .fuse section is endianness, and especially how would you handle this
with your proposal for extending avr-libc (below, which btw I like a lot)?

What about sub-sections?:
.fuse
.fuse.low
.fuse.high
.fuse.extended


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

Well that's the problem, as you said: those offsets are fictitious. I don't
want to base real code on offsets that are fictitious, especially as they
may not apply to future devices, and then it would be a real mess. The
section names are much more realistic to base the code off of.

Also, right now, the Makefile Templates that we have do NOT even combine the
EEPROM and Flash sections in a single file. If they did, then not only
avrdude would have to be updated, but so would AVR Studio's tools would have
to be updated, again based on arbitrary offsets. All of this is not very
backwards-compatible. This is not a good idea.

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

True, but there are only a finite number of combinations. This is why I gave
part of the algorithm in the email. If those sections exist, then do the
update for that particular part.

> Perhaps it would be easier to use a different option
> than -U to specify a single combined address-space file.  

I still don't like the 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? ;-)

Well the only solution is, of course, read-before-write, and only write if
different. I assume this can be done on the fuses and eeprom.

Also, realize that the feature that I'm proposing is *intended* for factory
programming for manufacturing, i.e. this would likely be used for the
initial, first programming of a device. Not necessarily used in an R&D
environment where EEPROM cell wear may become an issue after thousands of
programming cycles.

> 
> * * *
> 
> 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);

I *really* like this idea! :-)

But would implementation be easier if we changed the syntax to OR in the
values? Also maybe change the identifiers to not clash with register bit
values? Example:

LFUSE(FUSE_RC_OSC | FUSE_CKDIV8);
HFUSE(FUSE_EESAVE | FUSE_JTAGEN);


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

All the better to get crackin' and do this! ;-)

Eric