Re: [avrdude-dev] Initial STK600 support committed to CVS

[terran+avr]

> we used to do it.  We'd better generate as much as possible (if not
> all) for each new AVR device by converting Atmel's partdescription XML
> files, so some XML dialect for a new configuration file would seem a
> quite natural choice to me.

I'm envisioning a perl/python/whatever script which reads the Atmel
files from some directory, plus a custom avrdude XML file containing
whatever needed information isn't there, and writes the final XML
configuration file(s).  Since we're apparently not allowed to
distribute the Atmel XML files, and they're not easily extracted from
the Atmel AVR Studio distribution without an actual Windows box, the
generated file should presumably be included with a source
distribution and removed only by "distclean".

> Last time we've been discussing it, the only/main concern with
> per-device configuration files was that scattering several dozens of
> files on the target system contributes to wasted disk space due to
> file system fragmentation.

Does anybody care about this anymore?  If the filesystem block is 4k,
the average "wasted" space per file will be 2k, which at 70 files
is 140k.  The stripped binary itself is over 200k, much less the
complete package with data, documentation, configuration, etc.  The
only place I could see this being relevant is on an embedded device
running off a flash card, and even then I'm dubious.

> Any other things to consider?

There was some discussion a few months ago about a merged fuse address
space instead of the one byte lfuse, hfuse, efuse, xfuse, etc.  I am
not strongly for or against it, but *if* that's going to happen, I
believe this is the best time for such a change.

The feature I would most like to see in avrdude is an ability to
interpret the fuse bits in some more meaningful way.  The present
approach of reading the datasheet programming section by hand and
entering raw hexadecimal values with no programmatic confirmation of
their meaning is error-prone, and I have had to desolder more than one
TQFP because I set the fuse bits wrong due to user error and rendered
it unprogrammable.  The best source for the interpretation of the fuse
bits in each device is in the Atmel XML files, so if there's going to
be a parser for those files anyway, I believe this would be an ideal
time to improve the fuse handling.  I'm happy to work on that if we
can come up with a general idea for the interface that people support.