> -----Original Message----- > From: Michael Hennebry [mailto:[EMAIL PROTECTED] > Sent: Monday, September 24, 2007 8:08 AM > To: Eric Weddington > Cc: [EMAIL PROTECTED]; 'avr-libc-dev' > Subject: RE: [avr-libc-dev] Re: [RFC] Unified ELF file > > > What if a user doesn't want to assign a fuse, > e.g. the last time he played with that fuse > the cure required a soldering iron? > Would one have to keep the sections separate to > allow assigning only some fuses and lock bits? > > The avrdude wrapper I wrote assumes separate sections.
First, lets separate two concepts. The ELF file is just supposed to contain the data (fuse, lock, etc.). It does not know, or care, about any programming algorithms or what the user wants to do with that information. Programming software (such as avrdude, or AVR Studio programmers) will take that data and program the device according to how the user commands it. So it is entirely up to the user to decide how they want their device programmed. The only thing that we need to do is to make sure that the format of the ELF file does not inhibit the user from doing something useful. And you bring up a good point. In the patch that I posted, these separate *input* sections (.lfuse, .hfuse, .efuse) are combined into a single *output* section (.fuse). What if a user only wants to program a single byte (for example, hfuse)? I propose a counter-argument: it makes no sense for *the user* to want to program a single fuse byte. Here's why: The fuse bits, in total, are a logical set of data. That's why they are called "fuse bits". The fact that they are broken up into 2 or 3 separate bytes is arbitrary due to the underlying physical organization of the memory on-chip. However, it is up to the user to decide, for each fuse bit, what that value should be. And, more importantly, the entire set of fuse bits are tightly bound to the particular device *and* application that is being written for that device. This is why it makes sense to set the fuse bit data in the application directly. If the user willfully, or accidentally, ignores the setting of any fuse bit (or, by default, a group of 8 fuse bits in a byte), then it's caveat emptor and there is nothing that we can do to programmatically save the users from themselves, other than specify the factory default settings. If the user does not specify a particular byte (group of fuse bits), then automatically setting them to default settings would follow the principle of least surprise. Now follow this to programming. If all the fuse information is set in the ELF file, and the programming software is commanded to program all fuse information, all is good. Why would the user only want to program partial fuse information? The only reason to do this is for experimentation. And doing so would be a violation of the fuse data that the programmer originally specified in the source code (and hence put into the ELF file). I would argue that if a user still wants to do this, then change the fuse data set in the application (and hence changed in the ELF file), or to use other existing mechanisms to program the fuses, for example, in avrudude one can specify the fuse data directly on the command line. I agree that the programming software needs to be intelligent about programming all fuse bytes, to reduce wear. All programming software should read the fuse byte, compare it with what should be programmed, and if they are not different, then do not do an erase/program cycle. The fuse data is logically coherent. If one wants to experiment, then there are other existing means to do this. When a user has settled on the exact values for all the fuses, then that information should be codified in the source code, compiled into the ELF file, so that other users can safely program the entire device, without human intervention and error to the software engineer's specification. The whole point of this is not to monkey around with "only changing one fuse byte". One can do this via explicitly on the command line without ever having to change the layout of the ELF file. If the ELF file format does not have to change, then it makes the most sense to have a single memory area where *all* of the fuse information can be explicitly included, and any avr-libc API should be able to specify a default value if the user forgets to do that in their code. Eric Weddington _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
