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: > > [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 _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
