Re: [avrdude-dev] config file change

[Brian Dean]

On Sun, Mar 16, 2003 at 02:06:47PM -0800, Theodore A. Roth wrote:

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

Ok, I'm confused.  I thought you were talking about the #define's that
Atmel lists in their AVR061 app note that I copied into the sample
config file for reference.  To my knowledge, these codes are specific
to the STK500 programmer.  Am I wrong about this - does this number
derive from the part's signature byte in some way?  If so, then we
don't need it at all, we can just read the signature bytes and pass
the right one to the STK500.

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

If you do this, it should be implemented as a list of possible
signature byte values.  E.g., I've read at least one data sheet errata
that said that devices mfg'd before such and such a date have a
different set of signature bytes than devices mfg'd after that date.
See the errata for the ATmega103 for an example of this.

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

I think it is STK500 specific - they came from Devices.h which was in
the accompanying ZIP file as part of app note AVR061.

Here is the head of that file:

----------------------------------------------------------------------
//**** ATMEL AVR - A P P L I C A T I O N   N O T E  ************************
//*
//* Title:              AVR061 - STK500 Communication Protocol
//* Filename:           devices.h
//* Version:            1.0
//* Last updated:       09.09.2002
//*
//* Support E-mail:     address@hidden
//*
//**************************************************************************

#ifndef __DEVICES_INCLUDED
#define __DEVICES_INCLUDED

/* 0x00-0x0F reserved */

/* 0x10-0x1F ATtiny 1K devices */

#define ATTINY10    0x10
#define ATTINY11    0x11
#define ATTINY12    0x12
#define ATTINY15    0x13

/* 0x20-0x2F ATtiny 2K devices */

#define ATTINY22    0x20

...
----------------------------------------------------------------------


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

Fine.

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

Perhaps then we should make the programmer name be part of the
parameters - i.e., what about:

        part
                id = "foo";
                ...
                devcode = "avr910", 0x50;
                devcode = "stk500", 0x47;
                ... etc.

Within the part structure, this would be implemented as an array or
linked list.  The only thing I'm thinking about is that if we have
additional programmers pop up, we'll need to change the grammar to
include them.  But I guess we need to do that anyway to add the
keyword for the programmer type assignment.  Either way I'm good -
just offering alternatives for you mull over.  If you want, I can help
to implement this part (bad pun) - just say the word.

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

Probably wise - better to bail than possibly damage a part.

Cheers,
-Brian