-----Original Message-----
From:
address@hidden
[mailto:address@hidden
rg] On Behalf Of Scott L. Price
Sent: Saturday, March 10, 2007 11:39 AM
To: Galen Seitz
Cc: address@hidden
Subject: Re: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude
Feature RequestandCall for Volunteers
Galen Seitz wrote:
Eric Weddington wrote:
-----Original Message-----
From: address@hidden
[mailto:address@hidden
org] On Behalf Of Joerg Wunsch
Sent: Friday, March 09, 2007 2:21 PM
To: address@hidden; address@hidden
Subject: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude Feature
Request andCall for Volunteers
...snip...
Also, it
might be useful to be able to suppress updating
individual parts on
some invocations. Not only that updating the fuses to
the same value
could perhaps contribute to some EEPROM cell wear, but
you might not
want to re-initialize your EEPROM all the time as well.
(Isn't that
what has already been bothering AVR Studio users? ;-)
Well the only solution is, of course, read-before-write, and only
write if
different. I assume this can be done on the fuses and eeprom.
Also, realize that the feature that I'm proposing is
*intended* for
factory
programming for manufacturing, i.e. this would likely be
used for the
initial, first programming of a device. Not necessarily
used in an R&D
environment where EEPROM cell wear may become an issue
after thousands of
programming cycles.
FWIW, I would prefer to use the same file for development
and production.
A single file reduces the number of variables when someone
calls and says
'It doesn't work'.
I like the idea of read-before-write, but for development I
would still
want some way to control whether flash, eeprom, or fuses
are written on
an individual basis. For development work I would like to
tell avrdude
to verify the fuses and then write to flash. I think this
would catch
the majority of my own programming mistakes.
galen
I agree. I really like the idea of the single file, but I need to be
able to tell it not to write to things on an individual basis.
Hi Galen, Scott,
Thanks for the feedback. Would an algorithm such as this be acceptable?:
1. If -U switches exist on command line, then follow those sequences exactly
2. else (no -U switches exist on command line) follow automatic sequence:
2.1. Fuses (verify, if different: write and verify)
2.2. Flash (erase, write, verify)
2.3. EEPROM (verify, if different: erase, write, and verify)
Eric