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.
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. > - 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. 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). Perhaps it would be easier to use a different option than -U to specify a single 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? ;-) * * * 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); By that time, we probably caught up with what PIC users did already have for some years now. :-)) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
