> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Michael Hennebry > Sent: Wednesday, September 26, 2007 9:52 PM > To: Dave Hylands > Cc: avr-libc-dev > Subject: Re: [avr-libc-dev] Re: [RFC] Unified ELF file > > On Wed, 26 Sep 2007, Dave Hylands wrote: > > > On 9/26/07, Colin O'Flynn <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > > I propose a counter-argument: it makes no sense for > *the user* to want to > > > > program a single fuse byte. > > > > > > I agree with Eric 100% here. If you are going to be > setting the fuse bytes, you > > > *must* set them all. Otherwise you are assuming the > current state of fuse > > > bytes. Sure they *should* be default, but if someone else > had their hands on > > > the chip it might change. That's the sorta scenario where > two months down the > > > road stuff stops working, and you can't figure out why... > > > > Perhaps, what should be included is a set of fuse bytes and a > > corresponding mask. This would allow the program to set > just the bits > > it was interested in, rather than being required to set all of the > > bits. > > He might not do it because it allows > something he wants to forbid. > > How about eliminating the surprise issue this way: > Include the masks in the elf file. > Declare that a well-made tool will not accept a mask > other than all-ones unless explicitly told to. > A bondage and discipline tool will not > accept a mask other than all-ones. > > Whatever is done, don't use default fuse values. > Default fuse values will produce surprises.
Oh? And how would non-default fuse value not produce surprises? Default fuse values are known good values and can be looked up in the datasheet. I have many real-world cases where this overall feature is useful, and if the user acceidentally does not specify a fuse byte, then a default should be used. If it can even be done. I'm not turning this into a bike-shed event. Patches welcome. Eric _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
