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