> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Galen Seitz > Sent: Saturday, March 10, 2007 3:25 PM > To: [email protected] > 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 [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
