RE: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude FeatureRequestandCall for Volunteers

[Eric Weddington]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> rg] On Behalf Of Galen Seitz
> Sent: Saturday, March 10, 2007 3:25 PM
> To: address@hidden
> Subject: Re: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude 
> FeatureRequestandCall for Volunteers
> 
> Eric Weddington wrote:
> > 
> > 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)
> 
> I realize your are trying to keep things simple for 
> production, but I tend to
> think that some sort of command line switch is desirable.  I 
> don't necessarily
> like the idea of a bare file name defaulting to programming.  
> I think I'd 
> prefer two separate switches, one for programming and one for 
> verifying.  The
> programming switch would perform the above sequence, and the 
> verify switch
> would attempt to verify all applicable sections in the elf 
> file.  Perhaps
> using the bare file name could default to verifying, and on a 
> verify error,
> the error message could include a hint as to how to program, ie
>   Verify failed at address 0x0000 (use -p to program)

Hmm. I see what you mean about not having a default sequence tied to a file
type. It's too implied.

I guess what I'm trying to avoid is having an outrageously long command
line, with multiple -U switches to do that main sequence above. I'm thinking
of very non-technical people using the command line for the mass
programming, and so I would like to keep the command line as simple as
possible for this particular case. I would be ok with creating a new switch
that basically does that default sequence. I don't know about separating it
into a programming part and a different verifying part, because if we're
going that far, then one might as well use multiple -U switches. The point
is that during mass programming, one usually wants to program *and* verify,
and if the verify fails, remove the device from the line and analyze the
problem later. The intent is to use this programming sequence for
production, not R&D where the verification step is often skipped to save
time.

Eric