avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude Feature RequestandCal


From: Eric Weddington
Subject: RE: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude Feature RequestandCall for Volunteers
Date: Sat, 10 Mar 2007 12:21:07 -0700

 

> -----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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]