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

[Dave N6NZ]

Joerg Wunsch wrote:
> I got enough of STK600
> support in AVRDUDE up & running today to commit it to CVS.  Covered so
> far is programming the "classic" 8-bit AVRs (AT90, ATtiny, ATmega),
> using the same methods that are available already for the STK500 (ISP,
> PP, HVSP).
Very good!

> Adding support for the STK600's on-board JTAG programmer might follow,
> it's an encapsulation of the JTAG ICE mkII protocol so I'd have to see
> how to put wrappers around our jtag2 handlers.
Sounds very useful.

> Alas, adding support for the ATXmegas will require quite a bit more of
> work than I anticipated.  These parts are really different from the
> classic AVRs in many respects, and so the entire programming scheme is
> also quite different.  From a high-level point of view, several areas
> in the Xmegas can be accessed separately (including erasing them
> separately), like bootloader and application flash.  That alone will
> require UI changes.
Yes... I noticed that as well.  I was looking at the XMega128a1 
datasheet with the idea of doing a configuration entry for it... and 
decided it was too radically different to dig into.

> > From a low-level point of view, the STK600 uses a completely different
> command set for them.  This in turn will require a number of new
> parameters to be added to the configuration file.  That got me back to
> the idea we've been discussing some time ago: the current avrdude.conf
> is a half-megabyte lump of text, almost unmaintainable anymore the way
> 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 agree that a style sheet based XML->XML translator is probably the way 
to go here. XML is somewhat verbose, but all sorts of parsers and 
viewers and checkers and editors exist, so unless there is a strong 
motivation to use something else, even XML-haters should just hold their 
nose a go with it.

The size of the conf file isn't really so much of a storage issue these 
days.  Maybe a performance issue just reading it all in.  I'd like to 
suggest creating a conf directory, and put one XML file per part number 
in the conf directory.  People who care about disk space can rm the 
one's they don't want, and it would also be easy to distribute updates.

> 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.  If that's the only point, I'd propose a
> scheme where there are separate XML files (one per device, one per
> programmer) within the development tree, but they will then be
> combined into a single avrdude-conf.xml during the build, so the
> target system will still have just one configuration file.
Is this really an issue?  I can think of tools that have much worse 
directory habits that this change would cause --- browser cache, for 
instance.

-dave