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 _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
