[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] Atmel's XML part description files
From: |
Erik Walthinsen |
Subject: |
Re: [avrdude-dev] Atmel's XML part description files |
Date: |
Fri, 11 Feb 2005 20:37:38 -0800 |
User-agent: |
Debian Thunderbird 1.0 (X11/20050116) |
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.
- Re: [avrdude-dev] Atmel's XML part description files, (continued)
Re: [avrdude-dev] Atmel's XML part description files, Erik Walthinsen, 2005/02/11
- Re: [avrdude-dev] Atmel's XML part description files, E. Weddington, 2005/02/11
- Re: [avrdude-dev] Atmel's XML part description files, Erik Walthinsen, 2005/02/11
- Re: [avrdude-dev] Atmel's XML part description files, Brian Dean, 2005/02/11
- Re: [avrdude-dev] Atmel's XML part description files, Erik Walthinsen, 2005/02/11
- Re: [avrdude-dev] Atmel's XML part description files, Brian Dean, 2005/02/11
- Re: [avrdude-dev] Atmel's XML part description files,
Erik Walthinsen <=
Re: [avrdude-dev] Atmel's XML part description files, E. Weddington, 2005/02/12