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. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
