avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] config file change


From: Theodore A. Roth
Subject: Re: [avrdude-dev] config file change
Date: Sun, 16 Mar 2003 16:32:31 -0800 (PST)

On Sun, 16 Mar 2003, Brian Dean wrote:

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

I was wrong. I realized this once I started digging into the code more after 
sending my previous message.

It should be implemented as avr910_devcode and stk500_devcode as I 
originally thought since the sig bytes are different than the 
programmer specific devicecodes.

<snip>

:)> 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 -

I like the <programmer>_devcode better myself. Less confusing in the config 
file.

:)just offering alternatives for you mull over.  If you want, I can help
:)to implement this part (bad pun) - just say the word.

I think I've got a handle on it. Take a look at the attached patch and see 
if anything screams idiocy.

The pgm->cmd mechanism is going to need some serious work though. The avr910 
doesn't have direct access to the SPI commands. I'll keep plugging on it...


Ted


Attachment: avr910-patch1.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]