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

[Colin O'Flynn]

Hello,

A while ago I was browsing through the avrdude manager, looking for a project 
to pick up. I saw that ELF request Eric put in, and started hacking out some 
code. I never finished it because it looked like a lot more work and I didn't 
see anyone really screaming for it... but now things have changed. Not the 
work part, the screaming part ;-)

I'll see if I can finished the ELF parsing part. I'll leave the command line 
stuff for now, or more accurately whatever patch I make shouldn't be 
considered the final version. I'll put some cheesy command line switch on, 
that can be changed later.

Regards,

 -Colin

On Saturday 10 March 2007 19:57, Eric Weddington wrote:
> > -----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
>
>
>
> _______________________________________________
> avrdude-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avrdude-dev