avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] Re: WinAVR


From: Bernard Fouché
Subject: Re: [avrdude-dev] Re: WinAVR
Date: Sun, 28 Aug 2005 21:15:56 +0200

On 20:47:49 28/08/2005 "E. Weddington" <address@hidden> wrote:
> Thanks Bernard. Is this patch in the avrdude Patch Tracker?Ye
You're welcome :-). Yes the patch is on the tracker. I've submited also a
patch (#4328) to have avrdude taking care of device locking for Linux but I
wonder if it could work with Cygwin for WinAVR.


For patch #4338 ('v2' problems), one has to decide if some tokens must be
changed in avrdude.conf for atmega64/128 (I did not check other atmega's)
or if the code in stk500v2.c should look for other tokens.


For #4328 (Device locking) I never used autoconf & such so I do not know
how to have two constants being set at './congigure' time.


I'm happy with the shift to 'v2' (BTW I used it with different STK500 &
avrisp) since I think it is much faster and safer: for instance on some
project, with the v1 protocol, you had to remove the ISP probe and put it
back each time you wanted to flash since the avrisp was hung. 'v2' seems
much more resistant, even when the project is using the SPI ports for it's
own use. So the avrisp cable is less manipulated and last longer. At last,
if you forgot to plug the avrisp on the target, with 'v1' you had to run
avrdude another time. With 'v2', avrdude will be able to start its job as
soon as you plug the target : it loops until the isp answers.


So we have wrote/verifyed flash memory many times, with applications
starting from 0x0000, bootloaders, and hex files having both an application
and a bootloader but a gap in the middle and it works well.


We read and wrote also many times the eeprom, memory bits and lock bits and
everything is fine. However, at the moment we only use atmega64 and 128
chips. 


 Bernard





reply via email to

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