avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] Butterfly proposal: Exit upgrade function


From: Martin Thomas
Subject: Re: [avrdude-dev] Butterfly proposal: Exit upgrade function
Date: Tue, 3 Feb 2004 17:03:07 +0100

>On Thursday 29 January 2004 18:10, Michael Mayer wrote:
>> On Tue, Jan 27, 2004 at 14:54:08 +0100, Martin Thomas wrote:
>> > With an added call for "exit upgrade" it is no longer necessary
>> > to reset the BF after a firmware update with avrdude.
>> > I suppose 'E' is sent by AVRPROG when pressing the
>> > [Exit] button. So the butterfly_close functions might be a good
>> > place to add the call.
>>
>> Thats a very good point, I will add it.
>>
>> What do you think about adding a new exitspec to the -E option to
>> stop avrdude from sending this final 'E'? What would be a good name
>> for it? "-E noexitupgrade" or "-E stayupgrademode" is IMHO much too
>> verbose. Any suggestions?
>
>How about "-E reset" and "-E noreset"? This is not technically 
>correct, but describes the behaviour.
>
>Cheers
>  Jan-Hinnerk

For the preinstalled Butterfly bootloader the term reset would be 
"technically correct" the bootloader issues a watchdog reset
when it receives an "E" since the BOOTRST fuse is blown
the BF restarts it's bootloader.

So yes, option -E noreset would be a nice feature if someone
programs the flash and the eeprom in separate AVRDUDE
calls. Although I'm not sure if this would work with the current
(4.3.0) Butterfly programmer init. 

-E reset should be the default to avoid frustration since the 
Butterfly seems to be "dead" if it stays in bootloader command 
receive mode and can not be reactived without system reset 
(or sending "E"). I've patched my "personal" version of avrdude 
just with the proposed line and I'm satisfied with this but have do 
admit I've never programmed the Butterflys ATmega169 eeprom 
with avrdude so far.

I've planned to announce it later, but - whatever: I've ported
AVRDUDE 4.3.0 to work on Windows without the need of
the cygwin.dll. Some changes where needed in the source code
and I don't know if everything is correct. Feel free to test it.
I've tested with the STK500 and a mega16 and have positive
feedback from someone using the STK500 and mega8515s.
The source is based on V4.3.0 and does not include the latest
changes from the savannah cvs done bei "Henni" (Jan-Hinnerk?).
The source archive together with a Windows binary can be 
found on:
http://www.siwawi.arubi.uni-kl.de/avr_projects/index.html#avrdudew32

Benefits:
- faster in MS-Windows
- no link to cygwin1.dll - easier redistribution like  in WINAVR
- avoid version mismatch with other cygwin dlls in the system
- no link to cygwin1.dll - smaller binary installer packages
- possibly a larger user and tester base because of easier installation
  and faster programming/flashing compared to some other 
  programmers

The changes shouldn't break the unix build but I've only tested 
the comiler/link with cygwin-"standard" and cygwin-"non-dll".

Avrdude seems to be faster with "windows native" than with
"windows cygwin-dll" this may break timings esp. with
STK200-type interfaces - needs testing.

So far I follow this list from the savannah list-archive please 
"cc" to the adress mentioned on my "avr-projects" page.

Cheers,
Martin





reply via email to

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