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 Bob Paddock
> Sent: Friday, March 09, 2007 6:03 PM
> To: address@hidden
> Subject: Re: [avr-gcc-list] Re: [avrdude-dev] [RFC] avrdude 
> FeatureRequestandCall for Volunteers
> 
> On Friday 09 March 2007 19:07, Eric Weddington wrote:
> 
> > > I'd rather not see non-source code data in the source code,
> > > that just adds to the validation burden.
> > 
> > How?
> 
> Traceability requirements.  Which is not to say you can't put
> "Program fuses to X/Y/Z", in the requirement document.
> Also in a design review you'll have people that can review
> the source code, assuming their competent in the language
> at hand (why else are they in the review?), but they may
> have no clue about the hardware at the 'fuse' level,
> so those source code lines about the fuses
> becoming something "ambiguous" in some of the review
> meeting minutes.  Which ends up causing more paper work...

Thanks for explaining...
 
> > And I have other requests, from people who do volume 
> programming, that want
> > such a way to reduce errors.
> 
> They are willing to install a program supplied by each 
> customer, on their networked
> equipment?  Sounds like large security hole to me.  Also how 
> does avrdude
> interface to the chip-shooter (think robot handling the 
> chips, tho it is
> more like a pick&place machine.  In ultra high volume the chips are
> programmed before they are put in a package.)?
> 
> A different approach would be to find out the hardware being used
> and talk to that manufacture, about what they need to get the
> data into their system.  I know years ago when I worked with BP
> equipment you still had the equivalent of script file that contained
> the file names of the .hex files, and the fuse settings, that the BP
> read.

Ah, I see what you mean. I guess it all depends on how one defines "volume
programming" and the level of rigor for the procedure. The situation you
describe sounds like *really* high volume (given a robotic/pick&place
programmer machine) but also one that is inflexible in its procedures (must
require .hex file and nothing else). The kinds of situations that I've heard
is still dealing with thousands of devices, but low-cost human labor doing
the programming and much more flexibility concerning the procedures that can
be implemented. In this particular case, anything that helps reduce errors
is more preferrable than being fixed to a particular procedure.

> > In the end, having this feature available, does not make 
> this feature
> > *required*. It is still up to the designers decision to do 
> it this way, or a
> > different way.
> 
> Yes.

And really that's the thing that I'm looking for, is choice. I don't like to
dictate one set of procedure over another as many things are situational
dependent.
 
> > How are these scripts any different then using batch files 
> on Windows or
> > shell scripts on *nix? What makes them advantageous over 
> other methods that
> > can be done right now without modifying avrdude?
> 
> I'm not sure there is an advantage, other than compatibility 
> with the existing
> scripts.  In our local production we do use the batch files 
> on Windows.  I wrote
> a rather complex menu system in batch files so our production 
> people just
> had to pick a part number that needed programmed; I agree that was not
> fun.  

Ouch! :-P

> Was just an other idea, in the hopes of not having to 
> touch the source code.
> 
> In the end it all comes down to the documentation, regardless
> of the mechanism of implementation.  Someone at some point
> has to get the fuses set correctly in some file, and have a 
> reliable system
> in place so that they are correct when the widget is built as 
> the end result.

Exactly. :-)