avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] BETA Release is now available - please test (was: Good


From: Brian Dean
Subject: Re: [avrdude-dev] BETA Release is now available - please test (was: Good news: STK500v2 and JTAG ICE mkII code committed to CVS)
Date: Sat, 14 May 2005 19:46:32 -0400
User-agent: Mutt/1.4.2.1i

On Sat, May 14, 2005 at 07:32:06PM -0400, Colin O'Flynn wrote:

> I agree - I have myself ran into this problem. I'd previously
> e-mailed the list about a suggested change but got no feedback and
> eventually forgot about it. I've attached the message afterwards, if
> you think what I suggest is reasonable I'll go ahead and write a
> patch to do so.

> Instead of automatically changing the fuses, perhaps it should ask
> if it should revert the fuses.

> The reason I mention this is I had a VERY sketchy programming setup,
> very unreliable. However safemode read the fuses at the beginning of
> the run, and all times they got reported as 0x00. At the end of the
> program attempt they worked again, and read as their real
> values. But then they got changed to 0x00..

I wonder if it might be good to try and read the fuse bits several
times and ensure that they read consistently?  I don't know that this
would have helped in this situation, without a reset or something in
between.

Alternatively, you could test explicitly for edge cases like 0x00, but
that may not work because presumably 0x00 represents perfectly valid
fuse settings in some cases.

> As soon as I saw safemode report that the fuses were read as 0x00 I
> new I was screwed, as it is fairly easy to see that 0x00 is not a
> valid read pattern.  So if the user was asked what to do it could
> let them figure out that the fuses shouldn't be changed. I guess I
> really have no one to blame but myself for not using that behaviour
> originally, I just didn't think of it ;-)

That sounds reasonable - ask for confirmation before actually doing
it.

> Then there could be an option to not ask at all, and just change
> them back for batch files.

I'd suggest that maybe keep safe-mode on by default, but ask for
confirmation if it is going to make a change.  I think we need
explicit permission before changing any fuse bit values that weren't
requested.  Do have an option like you suggested to don't ask -
specifying that is like giving permission.  But if the "don't ask"
option is _not_ specified, and it is running from a batch file, then
disable safe-mode.  I think you can test if avrdude is running from a
script or not by calling the 'isatty()' function.  If it returns true,
then avrdude was run from an interactive terminal, otherwise is it
being run non-interactively.  In the case of non-interactive, I think
safe-mode perhaps should be disabled unless an explicit option is
specified to enable it.  That way we won't be changing any fuse bits
without explicit permission.

-Brian




reply via email to

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