Hi All, I agree with Jörg. The preferred Arduino bootloader, optiboot, chooses not to fulfill the full range of features of the programming protocol. That is their choice and, IMHO, a good choice at that. Why? It meets the needs of their target user group who overwhelmingly are not professional programmers. They want to be able to program an Arduino (not an AVR!).
Changes should be made to help the majority of user's lives to be bug/failure/problem free. I am not sure that the majority of Arduino users would understand the issue here, let alone be able to make an informed choice as to whether they need the change. Just to clarify: I use the term "Arduino User" not in a derogatory fashion; I use it merely to highlight that they are typically not professional, MCU embedded developers who would willingly choose to program an AVR "bare-metal". That was my two cents - bill is in the Post :o) Herr Stuart Cording BEng (Hons) Penckstr. 1 80995 München Tel: 089 80077609 Mobil: 01573 473 8680 On 7 Feb 2013 22:32, "Simon Sabato" <invalid.nore...@gnu.org> wrote: > Follow-up Comment #4, bug #37812 (project avrdude): > > I will make three more cases for why I think there should be an option to > skip > the "don't program blank pages" optimization. Then I will go away. > > 1) there is an assumption built in that an "erased" page is full of 1's. > It > is slightly inelegant to not have any way of working around that > assumption in > a system which behaved differently, should such a system ever be > implemented. > > > 2) if you don't provide that option, you will be potentially incorrectly > programming many many existing Arduinos where the default is now to use the > bootloader to program. > > 3) if you don't provide that option, BEST CASE solution (and what you > propose) > is that the bootloader will have to emulate full-chip-erase by doing a > page-by-page erase of the entire chip, before programming. This is (a) > much > slower than full-chip erase, and (b) almost never necessary, because most > people don't program the whole chip. > > #3 is a very inelegant best case solution to a problem that could be > resolved > by merely disabling an optimization in the code (which in 99% of cases will > have no speed impact at all). > > If this a matter of effort in making the change, I will gladly volunteer my > time! :) > > _______________________________________________________ > > Reply to this item at: > > <http://savannah.nongnu.org/bugs/?37812> > > _______________________________________________ > Message sent via/by Savannah > http://savannah.nongnu.org/ > > > _______________________________________________ > avrdude-dev mailing list > avrdude-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avrdude-dev > _______________________________________________ avrdude-dev mailing list avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev