avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] Fix warnings patch


From: Joerg Wunsch
Subject: Re: [avrdude-dev] Fix warnings patch
Date: Fri, 29 Aug 2003 21:16:52 +0200
User-agent: Mutt/1.2.5i

As Brian Dean wrote:

> > I'm all for including more in the docs than just having a 
> > reformat of the man page. And certainly a FAQ would be nice.
> 
> Excellent!  Thanks to both you and Joerg for volunteering :-)

OK, i'm already maintaining the avr-libc FAQ, i don't object to
maintaining another FAQ. ;-)

> Seriously though, I think this is a great idea.  The manual now was
> basically a rough duplicate of the man page because Windoze doesn't
> have the concept of man pages, and without that, there'd be no Windows
> doc at all.

Well, it's easy enough to convert troff to PS and then to PDF.  (groff
is certainly also in the Cygwin tools.)

Also, i see man2html in the FreeBSD ports, the info says:

``Convert nroff(1) man pages to HTML''

The only dependency is Perl-5, so that might be an option as well.
Maintaining duplicate files is a nightmare, so i'm suggesting that we
continue maintaining the man page the way it is (short reference that
just lists all the options and features), and change the texinfo doc
into something more elaborate.

> > I would certainly recommend reconsidering the usage of -e. 
> > It's definitely more common to erase then program, than 
> > programming without erasing. Why require a switch for 
> > common usage?
> 
> I really don't have any major objection to this.  I only wonder if the
> decibel level of complaints will be louder if we go the other way.  We
> may instead have people then complain that: "Why did my eeprom get
> erased when I programmed my flash?"

Enable the EESAVE fuse. ;-)

Well, i wouldn't make such an incompatible change right now.  However,
what should be easy (and perhaps doable even for the next release) is
to read the first few ROM cells, and warn the luser that flash is not
empty when they're going to program a ROM that has not been erased.
Programming should IMHO continue anyway, they can always ^C out of it
if this programming attempt has been in error.

Unless they are only going to program a bootloader, the first ROM
cells always contain the reset vector, so they're typically always
allocated.  Thus it's not necessary to read the entire ROM in order
to tell whether it's (likely) erased or not.

> Of course, we could make avrdude a little smarter by depricating the
> -f -i/-o and -m options and prefering folks use -U instead.  Then,
> avrdude can look at all the memory operations specified and if any one
> of them specify the flash, then do an erase cycle before starting any
> programming.

The -U option is still relatively new, so implying an auto-erase for
it if it contains a ROM option is fine by me (could be even made
tunable in the config file).  Defaulting to auto-erase for the
historical options is IMHO a too incompatible change to previous
versions.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

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