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

[Bob Paddock]

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...

> 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.

> 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.

> 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.  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.