Re: [avrdude-dev] Re: [Uisp-dev] Why two?

[Brian Dean]

On Wed, Aug 13, 2003 at 08:49:35PM +0000, E. Weddington wrote:

> > Probably a question in the same boat as why KDE/GNOME, 
> why Linux/*BSD 
> > etc.  To the best of my knowledge uisp was around well 
> before avrdude and 
> > seems to work okay despite all the additions over the 
> years.  Personally I 
> > have no experience with avrdude so i'm not qualified to 
> comment pros and 
> > cons, might have a look at it over the weekend.

Being the original author of AVRDUDE (then AVRPROG), I was not aware
of any programming software available for FreeBSD, including UISP at
the time I wrote it (sometime in 1999 I think).  I recall that at the
time I had basic working functionality there also was no programmer
available in the FreeBSD ports collection.  Later, at the time I
committed AVRPROG (later to become AVRDUDE) to the FreeBSD ports
collection, I recall Joerg W. mentioning that he had some problems
with UISP - I don't recall the details, but it wasn't working for him
under FreeBSD.  I sent Joerg an early copy of AVRPROG and he reported
success with it.  Joerg had already committed the avr-gcc port for
FreeBSD, but there was a clear lack of working programmer software for
the FreeBSD OS.  Thus, I committed AVRPROG to the FreeBSD ports tree
to help others in the same position and have had many people write and
thank me for that.  AVRPROG has improved a lot since then, was renamed
to AVRDUDE (to avoid the issue of confusion with Atmel's own
AVRPROG.EXE binary), and since then several folks have contributed to
improve it even more and to port it to Windows and Linux.

That's pretty much the history from the AVRDUDE (AVRPROG) perspective.
I don't know the history of UISP.

On technical merits, I haven't really looked at the UISP source, so I
can't really comment on that, how it's structured, etc.

I believe the main thing AVRDUDE has that UISP doesn't is the ability
to add new devices and some types of programmers without recompiling,
i.e., AVRDUDE tries to be table-driven as much as possible, and the
table data is represented in a parseable configuration file (yacc
grammar based) that is read upon startup, and can be extended by the
user, either directly or through the use of their $HOME/.avrduderc
file.

This has the advantage that it can get someone out of a tight spot
when they need support for a device that is not present, they can
modify the config file themselves and add the part or new programmer
pin-out (in the case of the common parallel port programmer) without
having to wait for a new release or recompile the source themselves.
In practice, however, I don't know how much this actually helps folks
- I wonder if most folks just run the release version and rarely take
advantage of this feature, but I could be wrong about that.

Personally, I don't see a problem with two (or more) programmers.  If
there's a certain feature someone wants and one of the programmers
doesn't support it, chances are the other one might.  If there is only
one available and it doesn't do what you want, you're kind've stuck.

And just to muddy the waters even more, I seem to remember someone
else starting another AVR programmer and calling it 'AVRPROG', not to
be confused with my 'AVRPROG' (now AVRDUDE) or Atmel's own
'AVRPROG.EXE'.  That's been a while back - I haven't kept track of the
status of that project.

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