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

[Joerg Wunsch]

As address@hidden wrote:

> I'm envisioning a perl/python/whatever script which reads the Atmel
> files from some directory, plus a custom avrdude XML file containing
> whatever needed information isn't there, and writes the final XML
> configuration file(s).

If it's simple enough, I'd even go with XSLT "stylesheets".  I just
added a couple of those to the tools/ directory that can be used to
transform the new STK600 targetboard.xml file into various tables (two
for printing out the routing and socket card names from inside
AVRDUDE, and one for the documentation to tell which card combination
supports what target AVR).

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, which is about the only information that
was/is missing in Atmel's XML files.  IOW, all the information we need
ought to be there already, we just have to pick up what we need (and
add another subtree to carry the per-programmer information).

> Since we're apparently not allowed to distribute the Atmel XML
> files, and they're not easily extracted from the Atmel AVR Studio
> distribution without an actual Windows box, the generated file
> should presumably be included with a source distribution and removed
> only by "distclean".

Not even by distclean, they can just stay there.

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


As Weddington, Eric wrote:

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

> This has got to be a complete non-issue.

Probably, yes.

> I would much rather have a file organization that
> makes sense.

Well, for XML, I think a single final file almost makes more sense
than several dozens of files.  So say something like

<avrdude:configuration version="2.0">
  <avrdude:programmer name="bsd">
    <avrdude:comment>Brian Dean's parallel-port bit-bang 
programmer</avrdude:comment>
    <!-- ... -->
  </avrdude:programmer>
  <avrdude:programmer name="stk500">
    <avrdude:comment>Atmel's STK500 in ISP mode</avrdude:comment>
    <!-- ... -->
  </avrdude:programmer>
  <avrdude:device name="AT09S1200">
    <!-- ... -->
  </avrdude:device>
  <avrdude:device name="ATmega1281">
    <!-- ... -->
  </avrdude:device>
</avrdude:configuration>

Each individual <avrdude:programmer> and <avrdude:device> entry is
kept within one file within the source tree (to ease the development
work).

[about combining the files]

> This just adds another unnecessary step to the build process.

Given the simplicity of that job, that's also a non-issue though.

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

> Something that will work cross-platform. Last I saw, libxml is used
> in the xmlstar project (sourceforge) successfully on multiple
> platforms.

OK, I can look into that.  I'd prefer something that we might perhaps
include as source code within AVRDUDE itself, rather than having a
prerequisite binary library (.so or DLL) in the target system.

> > Any other things to consider?

> I definitely lean towards one xml file per device or per
> programmer. It makes it simpler to add support (just add a new
> file).

For the development tree, I fully agree with this.  I don't think
users would care that much about it though, so I still see it as more
convenient to be able to just move a single file around on the target
machine.

> Thanks for doing all the great work for supporting the STK600! :-)

You're welcome!  I'm a little sad I can't already program that Xmega
device ;-), but they are really more different than I expected.

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

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