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

[Erik Walthinsen]

Brian Dean wrote:
> Can you tell me what type the parameters should be, i.e., double, int,
> byte, string, etc?  And also, an example or two of the values they
> will take?  Just for the ones I've repeated below; I've filled in the
> ones that I think I can guess but want to double check:
Every one but blockSize is uint8_t, actually.  It's uint16_t for the 
sole purpose of holding "256".

> >        blockSize     - can we use the existing 'page_size' for this?
>
>                           I think it is already used this way for some
>                           parts - see, for example, the ATmega64 in
>                           avrdude.conf; I think this might only cause
>                           use problems if Atmel goes to a 'paged' memory
>                           structure for eeprom.  It's easy enough to add,
>                           though so maybe it's better not to overload
>                           page_size.
In the atmega64's xml file they list the blockSize for both Flash and 
EEPROM as 256, even though the eeprom's pageSize is listed as 8 
elsewhere (apparently for parallel mode only though).  The implication 
is that when reading flash or eeprom you "must" read blockSize bytes per 
request, though we can figure out by experimentation if that's true or 
it's just a maximum.  256 would make sense as that, since the stk500v2 
max packet size is 275 bytes.

> Are the at89xx parts Atmel's 8051 variant?  If so, we only support AVR
> so we can ignore that.
Yup, they are indeed the 8051's.  Although it seems to be implied that 
the stk500v2 protocol can do both and that they're effectively identical 
(except for that return-byte thing), so it might be easy to support later.

> Adding the actual keywords shouldn't take too long.  I expect that the
> values in IspEnterProgMode, IspLeaveProgMode, and IspChipErase will go
> into the AVRPART structure, while the others will go into the AVRMEM
> structure.
Yup.

> I wonder if I should try and add a more flexible way to incorporate
> this new data, something like:
>
>   part_extend
>        id = "m128";
>        stk500v2_timeout   = 200;
>        stk500v2_stabDelay = 100;
>        ...
>        memory "flash"
>             mode  = foo;
>             delay = bar;
>   ;
>
> The idea would be to fill in the specified information to the existing
> part.  Thus, we could potentially generate one big file containing
> this information seperately from the existing avrdude.conf file which
> would lend itself to easier update when Atmel makes changes, i.e., we
> can regenerate the whole thing without having to merge the information
> for each part into the avrdude.conf file which might make later
> maintenance easier.  Of course, all the new values could be specified
> under the "part" definition as well.  The "part_extend" definition
> would just add to the previously defined part instead of creating a
> new part element.  Just a thought.

Well, what I want to check into is actually whether some of these values 
*ever* change from part to part.  OTOH it's probably safe to include 
them regardless.  From that point of view it might make more sense to 
add things the other way around, with a part_default section.

A larger project would be to rearrange the parser so that the various 
config values aren't hardcoded tokens but are treated as symbols, so 
stk500v2 would e.g. call something like 
config_get_part_tag_int("stk500v2_timeout"), and if we have to add 
another tag later we just add the query into the code and config file 
without having to add more tokens to the parser.  Then again it'd 
probably be just as easy to go straight to XML instead.