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

[Brian Dean]

Hi Erik,

On Fri, Feb 11, 2005 at 05:57:50PM -0800, Erik Walthinsen wrote:

> Here's the file I came up with comparing the stk500v2 appnote against 
> what is currently in avrdude.conf:

Excellent!

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:

> IspEnterProgMode
>         timeout       - unsigned int
>         stabDelay     - unsigned int
>         cmdexeDelay   - unsigned int
>         synchLoops    - unsigned int
>         byteDelay     - unsigned int
>         pollValue     - uint8_t

> IspLeaveProgMode
>         preDelay      - unsigned int
>         postDelay     - unsigned int

> IspChipErase
>         pollMethod    - ??

> IspProgramFlash
>         mode          - ?
>         delay         - ?

> EEPROM Program
>         mode          - ?
>         delay         - ?

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

> out the hard way from the 'o's in the command sequences.  There aren't 
> any at89xx descriptors in the avrdude.conf I have (CVS from about a week 
> ago), so I'm not really sure how the value '4' makes sense, if all the 
> command sequences are only 4 bytes...  Guess I'll have to check an 
> at89xx datasheet.

Are the at89xx parts Atmel's 8051 variant?  If so, we only support AVR
so we can ignore that.

> If I can get a patch that adds these fields to the parser, I can
> probably get to code-complete within a day or two, and get the stuff
> all tested and theoretically working soon thereafter.

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.

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.

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