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

[Bernard Fouché]

Hi.

I'm reading about this ELF feature enrichment, and as the technical 
manager of a small company making a few thousands products a year still 
based on ATMEGA's here is my 2 cents point of view:

- subcontractors flashing the chips want hex files. They usually manage 
many different target MCU and not having the same file format for all 
targets will just add complexity since they'll want to fall back to hex 
files anyway. Unless keil/etc move also to this ELF feature, I think 
that only a very few companies will use the ELF format for that purpose, 
all others will stick to the well-known-do-as-usual hex file format.

- Setting the fuse in the source code does not allow one to perform a 
complete test of a .ELF and its .HEX derivatives: if you test a version 
not locking the chip and not calling the bootloader (for instance), and 
have to recompile or relink to enable these features, then you must 
again test the complete image since the .ELF is not the same. This is 
the only way to be sure that a particular .ELF file is validated. So 
you'll end up testing .hex files that won't need recompilation/link later..

- Fuse bytes are particular to a chip for a given set of features to 
activate/disactivate and used when flashing a chip. Source code is 
designed to pass thru macro processors, be as much as portable as 
possible, etc. I don't see any portability/simplicity improvement here 
if the fuses have to be defined and managed in .c/.h files. The solution 
will be to fiddle Makefiles to use conditionnal compilation or macros: 
the problem will move from avrudude command line options to buried 
macros in source files.

- The proposed solution appear to me as trying to use ELF files for a 
purpose that fits better in ar/tar/zip garden.

We use PHP scripts for a couple of years to handle avrdude while 
developing and we send .hex files to subcrontractors for volume 
production. We also have tests systems that can reflash products if 
needed. These tests systems runs on Mac OS/X while we develop on Linux. 
Many other people uses windows. Having to manage the .ELF format on 
different platforms will add probably a maintenance burden to avrdude.

I would prefer much more to be able to tell avrdude to use such or such 
feature offered by the fuses thru the command line instead of 
calculating the values for a particular MCU. For instance:

--fuse-set-reset-vector=bootloader --fuse-set-bootloader-size=2k

And have avrdude calculate and report the fuse values to use in 
production to reach the same result.

Regards,

   Bernard

Bob Paddock wrote:
> 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.
>
>
> _______________________________________________
> avrdude-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
>