As Eric Weddington wrote: > Or to extend it further:
> FUSES(OSC_INT_RC | SUT_14CK_65MS | CKDIV8, SPIEN | JTAGEN | BOOTSZ_4096); Yes, that's the basic idea. I don't know whether individual macros for each fuse or one for all of them would make it simpler for the user. Probably individual macros as Colin suggests the user might want to update just one of them. Alas, each AVR might have a different default fuse, so we cannot simply use 0xff as the default value. > > > The "universal hex file" is the resulting ELF file from the > > > toolchain. > > I've heard voices here that not everybody would be happy about this. > I don't think it's so much fat and bloated as it's a binary format Still, it carries a lot of baggage along with it: % ls -l foo.elf *hex -rwxr-xr-x 1 j staff 5115 May 8 21:49 foo.elf* -rw-r--r-- 1 j staff 4297 May 8 21:48 largedemo.hex -rw-r--r-- 1 j staff 30 May 8 21:48 largedemo_eeprom.hex The .elf file on top has *only* the `alloc' sections in it. Sure, it's not *that* fat. But users have their habits, and often have been using load files like intel hex for years. > > > If we're moving towards using the ELF file for everything, then > > > it doesn't make sense to add the flat hex file capability to the > > > tools. > > For avrdude, both would actually be identical as libbfd can handle > > both input formats transparently. > Agreed that it would be straight-forward work. IMO, it would just be > unnecssary work. The cool thing with libbfd is that it actually *isn't* more work at all. It's all there already. As Colin O'Flynn wrote: > For the namespace vs. offset: > Are you allowed to use both? aka can I pull the "magic offset" from > some known non-changing section? It doesn't make much sense. > The code would then do this: > --Look for section .eeprom > --Get address of .eeprom starting But what if the user moved the start address? The existing offsets have been there for several years now, and are a fairly stable constant these days. > Which could make just one ".fuse" memory section that contains the > three bytes. Or it could possible be renamed something more general > purpose, such as ".hardware" or whatnot. Then we could fit the > processor type, signature bytes, etc all in there. Well, these are not writable. But the lock bits come to mind. Alas, at least in the JTAG ICE, they got their own memory space. > You absolutely *must* be able to program a single fuse byte IMO. OK. > That way you just change what you need... You still have to specify all bits for a byte though. > I also plan on the "magic" mode of avrdude having it see if the > fuses need to be changed, and only changing them if they differ. So > if the user can say they don't care about a certain fuse that's even > easier. OK, fine. -- 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
