avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Atmel's XML part description files


From: Brian Dean
Subject: Re: [avrdude-dev] Atmel's XML part description files
Date: Fri, 11 Feb 2005 19:48:38 -0500
User-agent: Mutt/1.4.2.1i

On Fri, Feb 11, 2005 at 03:29:40PM -0800, Erik Walthinsen wrote:

> The problem is that I can't get stk500v2 working unless I get access to 
> those several dozen numbers per part that only exist in the Atmel XML files.
> 
> One way or another they have to be made available, and from the little 
> I've looked at the way avrdude.conf is handled, it'd make a lot more 
> sense to replace it with XML.  Or at the very least redo the parsing so 
> that it's a generic language instead of a very very token-specific 
> language.  Each of the tags for a given parameter are currently 
> hardcoded into the source, where they really should be treated as opaque 
> names and put into a tag/value list for use by the various drivers. 
> That's a change I'm not capable of making because I never have had any 
> luck (or even much training) in actually implementing grammars.

Adding the necessary keywords to the parser for avrdude.conf will be a
lot easier than gutting the internal data structures of avrdude.  The
keywords in the avrdude.conf file basically map very closely to fields
of the AVRPART and AVRMEM data structures.  This makes the code
implementation very easy in that you don't have to perform symbol
table lookups for each part parameter, you just reference it directly
as in part->chip_erase_delay, for example.

So why are there several dozen additional parameters needed for the V2
protocol?  What additional information is required?  If you let me
know what additional parameters are necessary, I will see about
extending our existing parser and data stuctures to accomodate them.

I'm not fundamentally opposed to XML or anything but converting to XML
isn't going to buy us any additional ease with regard to the internal
coding.  The only reason I think it might be useful is so that we can
use Atmel's part definition files directly, but it doesn't look like
we are allowed to include them with the distribution.  And we can't
rely on them being on the system already since avrdude supports 3
other platforms where AVR Studio cannot be installed.  So the benefit
ratio of converting to XML seems to be pretty low, at least at the
moment.  At least that's my opinion.

In general, I think XML is quite verbose and it will make maintaining
the config file harder, at least until such time as we can use
Atmel's.  Again, that's just my opinion.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]