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

[Dave N6NZ]

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