As Bob Cunningham wrote: > There is no reason to use a broken tool, nor to argue with folks who have > defended its decade of brokenness.
OK, so far about Bob. I'd like to get opinions from others on this. My ideas so far: . The current behaviour has been intented as an optimization, and this certainly makes a lot of sense for the more common use cases (reading out memory to program it back later, or for some kind of eyeball review or disassembly). So I don't like it to go away completely. . Sure, I see Bob's point that sometimes, one might want to retain a full image of what has been there. . I also see the point that with an application, followed by a bootloader very far away, basically the same considerations as above could be made to the intervening 0xFFs. But where to draw the line? One option for #2 were to have a separate indication that you really want the full image, like -U flash:R:flashfile:i, where the capital 'R' indicates it. That far, it should be simple to do. As for #3, one idea I've got is to always consider full flash pages. If a flash page turns out empty, omit it from the image. That way, a few bytes of 0xFF won't be dropped, but all large holes will. (Such holes are not only related to bootloaders, but could also happen if there are separate application data. The Xmegas even have their "apptable" area for that purpose.) But how to handle ancient AVRs that don't have paged flash? Impose some kind of artificial pagesize just for that purpose? Any other opinions? -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avrdude-dev
