avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] avrdude.conf.in cleanup


From: Brian Dean
Subject: Re: [avrdude-dev] avrdude.conf.in cleanup
Date: Wed, 19 Nov 2003 23:20:13 -0500
User-agent: Mutt/1.5.5.1i

On Wed, Nov 19, 2003 at 10:53:02PM +0100, Jan-Hinnerk Reichert wrote:

> Here is a cleanup for the config.

Committed, thank you!

> BTW: What delays are used for fuse and lock bytes, if none are 
> defined?

I think it will not wait if the delays are not initialized.  Now that
you've pointed this out, I'm wondering if it might be a good idea to
default these to whatever the "flash" values are for the part?

Few people have probably been bitten by this simply because of the way
the fuse bytes are handled, i.e., one at a time and delays are
naturally inserted in between.  However, this may explain the
behaviour I saw recently when using a parallel port programmer.  I did
this:

  avrdude -p m128 -c stk200 -U efuse:w:0xff:m -U hfuse:w:0xc9:m -U 
lfuse:w:0x2f:m

The second fuse byte specified (hfuse) failed to program.  This never
happened when I used the STK500, but of course, it's probably handling
the delays correctly.  I'm now wondering if the lack of delays for the
fuse bytes caused this problem.

Only recently did I introduce the -U option which allows multiple
memory types to be programmed on the command line at the same time, so
getting fast fuse byte programming in succession was a lot more
difficult.  Probably why this hasn't come up before.

When I get a few spare moments, I'll fix this by defaulting memory
types where the delay is zero (uninitialized) to be the value that is
specified for the "flash", unless anyone has a better idea.

-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/




reply via email to

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