As Andreas Weber wrote: > Mark H. (http://palmavr.sourceforge.net/cgi-bin/fc.cgi) and I > discuss if we should program a FLTK GUI for avrdude with Fuse bit > calculator (similar to his online version). The emphasis should be > to calculate and program the fuse bits, not to up- or download the > firmware.
I'd kindly ask you to reconsider that somewhat, and try writing a full GUI that completely integrates into avrdude, rather than yet another frontend. Some time ago, I restructured the avrdude source code to clearly separate the backend code (that now goes into an internal library) from the frontend code (the classic CLI main.c). One of the major ideas behind that was to make it easier to write a different frontend, based on the identical backend code the command-line UI uses. The major advantage of that is that it will automatically ``scale'' with avrdude: new devices will always be added to everything as a whole, rather than trying to catch up after each release only. Also, it will constitute a uniform utility to the user that way. Jörg Lachmann, the original author of avrdude-gui (who later abandoned the project due to lack of time) once already toyed with the idea to rewrite it completely using FLTK. So perhaps you might even try discussing all that with him, and see whether he'd like to comment on some things. After all, he's at least once tried already, and perhaps got his experience to share so you don't have to repeat some of his earlier mistakes. > My question is now if some facts of the case from 2005 has changed > or where we could get the fuse bit information NOT reading all the > datasheets individually. Or is it legal to write a xml converter > tool which extracts only the fuse settings? That's exactly the way Atmel suggests. They don't allow copying these files verbatim into an open-source project, but they explicitly allow picking up all the information one needs from it. Btw., if you opt for an integration into avrdude rather than a separate tool, this would probably require to store the fuse information inside the avrdude configuration. The current size of avrdude.conf bothers me, it's approaching half a megabyte already. Also, the current structure shows some significant shortcomings in other areas as well: the flat name space has caused arbitrary naming in certain areas, just to distinguish e. g. the different poll timeouts used within certain contexts. So some kind of restructuring appears to be overdue. I'd like to know about other developer's opinions on that. Ideally, I'd like to at least see it split into one file per AVR part, and maybe one file for the rest, or even one file per supported programmer as well. The idea to use XML files rather than plain text files is also tempting, given that many of the modern programmer parameters are to be extracted from Atmel's part description XML files anyway. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
