Re: [avrdude-dev] [bug #37812] STK500V2 not programming "blank" pages when not erasing flash (-D)

[Stuart Cording]

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" <address@hidden> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>