Joerg Wunsch wrote:
I've meanwhile got the word that AVR Studio itself uses fixed byte
patterns for the individual ISP commands to pass them down into the
STK500, since these commands have never changed, and are very likely
not going to ever change. That means we could simply drop all our bit
patterns from avrdude.conf,
Oh happy day!
I was just digging into converting a few from the new AvrStudio beta.
Maybe I'll wait a little bit :)
which is about the only information that
was/is missing in Atmel's XML files.
The feature I would most like to see in avrdude is an ability to
interpret the fuse bits in some more meaningful way. [...]
That's hard to do within the current command-line UI. I'd see this as
a job for a GUI, which should in theory have been made possible by the
recent split into a backend library, with main.c being just *one*
possible frontend, offering the traditional CLUI.
But sure, if someone would start such a GUI as an integral part of
AVRDUDE, there's nothing that would prevent us from extracting the
respective fuse information so the GUI could use it. Even if the
information is not initially there within the configuration XML: just
add it to the script (or XSLT stylesheet), re-run, and then it will be
there.
I'm biased towards including the fuse information now, as we make this
change, even if no current front-end uses it. It doesn't seem like
there are a lot of software architecture decisions to be made about fuse
information -- it's mainly just a few strings of data per part with a
very regular organization. That way it's there, it's done, we won't
have another big debate about changing the configuration file, and
anybody that wants it can use it.
As for using it in the command line interface, it would be useful to
have even something as simple as a "fuse reporting" mode that, instead
of programming, printed the fuse names. Something like:
avrdude [...] --pretend -U lfuse:w:0xaf:m
You would program:
crystal oscillator,...
Messages like "disables JTAG", "disables ISP", and "programs flash read
protection" might even be an excuse for using the character color escape
sequences to display in some scary color. That is, assuming we can
figure out from the XML which are the risky fuse bits.
-dave
_______________________________________________
avrdude-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
