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