> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Joerg Wunsch > Sent: Friday, March 09, 2007 2:21 PM > To: [email protected]; [email protected] > 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 _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
