As Eric Weddington wrote: > I know that you lean towards having a single .fuse space with multiple > bytes. Can you answer these questions:
> - How would a user specify the fuse information in their application (with a > proposed avr-libc API that was discussed)? Yes, some kind of avr-libc API. My (rough) ideas are something like LFUSE(OSC_INT_RC | SUT_14CK_65MS | CKDIV8); HFUSE(SPIEN | JTAGEN | BOOTSZ_4096); or maybe (for those who already know what they want) LFUSE(0xe2); HFUSE(0x91); but then, why not simply FUSES(0xe2, 0x91); ? > - How would a user specify each fuse byte individually? Do they need it? Don't they simply want to program *all* fuse bytes? Anyway, see above. > - How would the user know which byte went to which fuse address location? Why do they need to know? As long as the connection between the names above and the actual fuse is obvious, I don't think anybody cares. Despite, it's always been obvious to me that the index order is lfuse, hfuse, efuse. (Only the LPM fuse reading breaks that by using the index order lfuse, lock, efuse, hfuse. Ick.) Also, see another posting from me: new fuse bytes did appear in the past over thee lifetime of a product line (the AVR8). In case the current fuse space exhausts, and somone things the Xmegaplus needs another ultrafuse, the single address space for all fuses could simply be extended, without touching everything again. > > And unlike the offset hack, that parameter > > cannot be applied universally, so the old offset hack cannot be > > replaced by it. But then, we'll end up in two things for the same > > purpose: to distinguish different target memory spaces, some of them > > would be recognized by section name, and some of them would be > > recognized by their internal offset. > That is a bogus argument. The fuses don't necessarily have their own > "target memory spaces" because *they are never seen by the > application*. The application can read them, but not really in an indexed way, OK. Anyway, all the other tools treat the fuses and lock bits as a kind of memory space, including the Atmel stuff (JTAG ICE, STK500 protocol), and so does avrdude (and avarice) internally. It juest doesn't make any sense to me to try pretending they were anything else than a memory space which would justify treating them differently than other memory spaces. > The application can address flash, sram, and eeprom. It cannot > address the fuses. That doesn't matter here as the user simply doesn't care at all about whether we use section names, memory offsets, a pile of postcards or whatever as long as it works. It doesn't matter whether these memory ranges are user addressable but whether the tools treat them rather uniformly -- and they do. (Btw., reading lock and fuse bits in the AVR much more resembles reading ROM than accessing the EEPROM does. The former uses LPM, the latter goes through a peripheral device.) > 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 guess this has several reasons, the ELF file looks rather opaque to the user (``I don't know what I'm really giving away when I send that file to my customer.''), while one can ``look inside'' the hex file easily. The ELF file probably has a reputation of being fat and bloated. > Avrdude needs to have this capability. If they can all program the AVR > from an ELF file, then there is no need for them to work with multiple hex > files, or a bastardized hex file. If you call that hex file `bastardized', why don't you attribute the ELF file the same? ;-) > Even if we don't necessarily have the tools go off of fixed section > names, is there some other way, in the ELF file, to tag one or more > sections, as belonging to "fuses" without it having to have some > magical address offset that is bogus to begin with? No, ELF doesn't know about multiple memory spaces. > the fuse bytes into individual sections (1 byte per section) and have the > tools then work with these fixed section names, because they can't be > combined with any other section, ... You are repeating this over and over again, but I still don't see what you think here. I don't see what having three different sections (name space bloat) of one byte each would buy us, compared to one section of variable (currently max 3) length. *Who* do you think would ever manually mess with the combined fuse space, and then, if he did, why do you think that person wouldn't be able to do the very same with the three single sections? A mere mortal simply won't notice any of these anyway, they do appear in the linkerscript (but they have to appear there anyway in order to be dragged into the output ELF file). Btw., I think if you don't go for the offset option, you'll end up in complaints about overlapping sections from the linker (as your new fuse sections all start at offset 0, and thus would appear to collide with the interrupt vector table). I guess before discussing that further, there should really be a prototype implementation of the entire toolchain: libc macros (simplified API draft), linker script modifications, test run. > 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. -- 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
