[avrdude-dev] Initial STK600 support committed to CVS

[Joerg Wunsch]

After I got an STK600 for testing last week, and with the friendly
support of Eirik Rasmussen of Atmel Tronheim, 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).

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.

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.

>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.

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.  (The
development XML files could even be well-formed once in itself, and
the build system just drops the <?xml> header line when merging them
together.)

Are there any preferences for an XML parser library to use?

Any other things to consider?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)