avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] cvs back again and butterfly cleanup


From: Jan-Hinnerk Reichert
Subject: Re: [avrdude-dev] cvs back again and butterfly cleanup
Date: Thu, 11 Dec 2003 13:11:21 +0100
User-agent: KMail/1.5.1

On Thursday 11 December 2003 12:36, Michael Mayer wrote:
> The cvs is back again (see http://savannah.gnu.org/statement.html)
>
> Today I checked out the new sources: compiles fine and works
> flawlessly with my butterfly.
>
> Last week the removal of no_show_func_info() from avr910.c was
> discussed. I did this today for butterfly.c, here is my patch. The
> baudrate-patch from Jan-Hinnerk is included, too. Different speed
> settings aren't supported by the butterfly, but it can be useful if
> someone uses a slightly modified version of the atmel bootloader.
> But even for 19200 baud the blockmode is quite fast: 10.2 sec for a
> full 16kB read or write.

Thanks for the patch. Looks fine. However, we are not able to do any 
changes to the CVS at the moment ;-(

> For the butterfly device, it is redundand to give a device type at
> the command line as this device uses always a m169 - it is
> specified as a small evaluation board for this processor type. So I
> would like to introduce a default device type info. If no device
> type is set, it gets initialized to "m169". If, for some reason,
> the user should feel the need to use a different device type this
> default could be easily overridden using the -p switch. I suggest
> to add a new member to struct programmer_t called "default_part".
> It will be initialized to NULL giving the actual behavior for
> avr910 and stk500, but can be changed to "m169" in
> butterfly_initpgm.

IMHO it would be better to make a more general change: We should give 
_every_ programmer the chance to autodetect the part, if none was 
selected at the command line. Autodetect should at least work for PPI 
and AVR910, if the device signature is not locked (and if the chip is 
not an AT90S1200 ;-)

/Jan-Hinnerk





reply via email to

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