Re: [avrdude-dev] config file change

[Theodore A. Roth]

On Sun, 16 Mar 2003, Brian Dean wrote:

:)On Sun, Mar 16, 2003 at 11:11:13AM -0800, Theodore A. Roth wrote:
:)
:)> The avr910 needs a devicecode in the config file like the stk500 does. 
:)> Sadly, the codes are not compatible.
:)
:)Figures.
:)
:)>  #   part
:)>  #       id               = <id> ;                 # quoted string
:)>  #       desc             = <description> ;        # quoted string
:)> -#       devicecode       = <num> ;                # numeric
:)> +#       stk500_devcode   = <num> ;                # numeric
:)> +#       avr910_devcode   = <num> ;                # numeric
:)>  #       chip_erase_delay = <num> ;                # micro-seconds
:)
:)Such a change would be fine with me, I don't think backward
:)compatibility is a huge deal, since we replace the file at
:)installation/upgrade time anyway.

Ok.

:)
:)But ... and this may be crazy, so feel free to tell me so.
:)
:)Since these appear to be programmer specific, what about listing the
:)device codes within programmer definition instead of the part
:)definition?  The format might be look something like this:
:)
:)      devicecode = <part-id>, <devicecode>;
:)
:)<part-id> would be the id string from the part, and <devicecode> the
:)numeric device code.  This would require a new linked list be included
:)within the programmer structure that contains some structure that
:)holds these values.

We should call it the dev_sig_id then instead of the device code. This 
number is truely independant of the the programmer and shouldn't be called 
stk500_devcode.

Well, thinking about this a bit more, we should probably read the 
3-byte signature value any ways. Then have sig_fam_id and sig_dev_id in the 
configure file for the device. If the read/config values don't match, we 
mostly screwed. In theory, there could be devices that have the same 
sig_dev_id, but different sig_fam_id.

I guess I was a bit confused as to what the devicecode is. I think 
sig_dev_id is a bit more clear as to the the nature of the value.

Does avr910_devcode sound make sense? To me it does since the programmer 
uses various codes to note which device to consider.

:)
:)One advantage is that if more programmers are supported, and they need
:)to have their own device codes, too, we won't have to update the
:)grammar to support them.  The disadvantage is that it would be
:)slightly harder to locate the device code for a particular part, since
:)you'd have to loop through the device-code list for the programmer and
:)try and match the id string to the current part to find it.  Not a
:)huge deal, be harder than part->devicecode.

I think that everything for a device should be in the section for the device 
in the config file. Makes it easier for users to add new devices if it is 
all in one place.

BTW: The avr910 programmers will return a list of supported devices (via the 
't' command). I'm thinking about that if the user selects a device and it's 
not in the list of supported devices (for the programmer), then bomb out.

Ted