AVR-Chat

Brian,

Thank you for your responses. I cannot let this go without one more 
round of discussion.

> Hi Mike,
>
> On Mon, May 16, 2005 at 07:54:14AM -0500, Mike Perks wrote:
>
> > 1. I tried building my own version from source and found the makefile
> > schema impenetrable. I understand why some of the complexity is there
>
> The Windows binary of AVRDUDE is normally provided through the WinAVR
> distribution.  However, this being a beta release of AVRDUDE, it may
> be a little while before you can expect a pre-built binary for
> Windows.  When this is available, we'll put it up on our download area.

Windows is not my platform of choice but it certainly is the most 
popular "choice". I don't quite understand why it takes so long to 
produce a Windows version. Is this a statement about testing or 
building? I am not suggesting that you provide a Windows only version, 
only that it might be prudent to consider which platforms you support as 
a priority over others. Apologies if you already made that decision and 
have decided that Windows IS further down on the list.

>
> > 2. Just like version 4.4, there is no Windows binary available. In
> > the end I went to Klaus Leidinger's site to download a Windows
> > version of 4.4.
>
> See above.

I got my version 4.4 from WinAVR. However I not sure I would want to 
force people to reinstall a new WinAVR every time a new release of 
AVRDude became available. Given that you have built a Windows version of 
4.4, why not add it to the download area on the website?

>
> > 3. Klaus and others have made a number of improvements to their
> > version that I didn't see in 4.4 and I use his version instead as it
> > supports 115,200 baud download. I would to see the code reconverged
> > if possible, or at minimum have their changes added to the 5.0
> > release.
>
> Which programmers are you referring to?  The STK500 and Atmel AVRISP
> use 115,200 by default so, of course, AVRDUDE supports this.  Also, if
> you have a custom bootloader that emulates the STK500 protocol but
> requires a different baud rate, the baud rate can be overridden using
> the -b option, or by specifying the 'baudrate' parameter in the
> programmer configuration section of the config file.  In general, the
> -b <baudrate> command line option or the 'baudrate' keyword in the
> programmer config file will override the default baud rate for any
> serial programmer.

My mistake about not supporting 115,00 with STK500/Atmel AVRISP. I have 
a custom ISP that implements the AVR910 protocol (from Klaus' site). The 
-b option is not documented either in the command line help or in the 
documentation. I think it would help to add it there.

>
> > 4. Because I don't use AVRDude on a daily basis, I always end up
> > reaching for the manual to remember the names for the chip I'm using
> > and other parameters. I know there is some command line prompting
> > but even so its rare that I can get AVRDude to run like I want first
> > time. I'm aware of the GUI version and have tried that as well.
>
> AVRDUDE is a cross-platform application, supported on FreeBSD, Linux,
> Mac OS X, and Windows.  Implementing it as a GUI application on
> Windows-only is not at all within the goals of the AVRDUDE project.

I wasn't suggesting you implement a GUI version of AVRDude as this is a 
departure from the intent of AVRDude. I was really talking about the 
autodiscovery part and perhaps some synonyms for the part names that 
match the actual device names e.g. atmega8535 instead of m8535.

> The typical method of not having to remember a command line is to
> simply encode the command as a rule in your Makefile.  I.e.:
>
>      flash: ${TARGET}.hex
>              avrdude -p ${CPU} -V -U flash:w:${TARGET}.hex
>
> Then, to download your program to your device, you just say:
>
>     make flash

Good trick. I will remember that.

>
> > I think what's missing is the simplicity of AVRProg auto-discovery
> > with the flexibility of AVRDude.
>
> We've discussed adding auto-discovery on the avrdude dev list.  We're
> not opposed to it, but it just hasn't been a priority.  We're happy to
> accept patches if you choose to implement such a feature.

Fair comment. I could certainly work on enhancements but time and 
priority is always a problem :)

>
> > 5. It's not clear to me why I (or anyone else) would need to upgrade to
> > 5.0 if we didn't need the two functions listed below.
>
> You should know that JTAGICE support and STK500 V2 support have been
> highly requested features of AVRDUDE.  We are fortunate enough to have
> an active user base who submit patches and feature enhancements.  The
> STK500V2 support was contributed by one of our users and was greatly
> appreciated, especially considering that the newest version of AVR
> Studio wants to upgrade the firmware on the STK500 to V2 and without
> that support, would make AVRDUDE no longer able to support that
> person's STK500.  That seems like a pretty good reason to upgrade.

Yes I saw the appends about that problem. Kudos to whoever provided the 
STK200 support.

>
> > In fact what does it mean that you have JTAGICE support and which
> > ones did you test it with?
>
> Sorry - I thought it was clear that I stated we now support Atmel's
> currently shipping JTAGICE unit, the JTAGICE MkII.

My mistake. Yes that is clear. However I was also wondering if there 
were any other fixes, enhancements and where these were documented.

>
> > 6. The AVRDude website is not helpful as it doesn't even mention the 5.0
> > beta. I would to see some effort applied to the website to make it
> > better. I didn't create sr #103514
> > (http://savannah.nongnu.org/support/?func=detailitem&item_id=103514) 
> <http://savannah.nongnu.org/support/?func=detailitem&item_id=103514%29> 
> but
> > it pretty much sums up my feelings as well. If the website is in poor
> > shape and I can't even find a Windows version of 4.4, what does this say
> > about the authors.
>
> The Windows version of AVRDUDE is built and provided as part of the
> WinAVR distribution.  However, you are free to build AVRDUDE from
> source, in which case you need to enable the PDF doc build by
> specifying the --enable-docs=yes configure script option.  Note that
> in all cases, avrdude ships with a complete 'man' page which describes
> all avrdude features and command-line switches.  But alas, Windows
> doesn't support 'man' pages.

As I noted, I had some difficulty in setting up a build environment for 
AVRDude and didn't know all the prereq packages to get. Part of this 
complexity is from supporting multiple platforms and part from the 
autogeneration of documentation and the CONF file. Perhaps a writeup on 
building AVRDude would be helpful.

>
> > Few people are going to bother testing AVRDude 5.0 if there is no
> > Windows version and no documentation on exactly what it does.
>
> Understand that this is a beta release.  Please be patient - it might
> be a week or two before we can provide an AVRDUDE-only installer,
> outside of the WinAVR release.  But the normal way to get AVRDUDE for
> Windows is to simply install the WinAVR package which provides not
> only AVRDUDE, but also GCC and the rest of the AVR development
> environment.

Actually just an EXE and a ZIP would be helpful to get people started. 
Although I'm sure you would then get other people asking for an 
installer as well.

>
> Also, understand that AVRDUDE is cross platform.  We also support
> FreeBSD Unix, Linux, and Mac OS X.  It also runs on Sun Solaris and
> other Unix platforms.  Windows is but one host that we support.  While
> supporting Windows is important to us, making AVRDUDE Window-specific
> is not within the goals of the project.  Windows already has AVR
> Studio for AVR development.  I originally wrote AVRDUDE (then AVRPROG)
> to support FreeBSD Unix where there was no AVR programming support.
> AVR Studio was not even an option on Unix.  The other platform support
> came later, Windows being one of them.  When originally Eric suggested
> a Windows port, I changed the name to AVRDUDE to avoid conflict with
> Atmel's AVRProg.exe programmer.  That's how AVRDUDE has evolved.
>
> Thanks for the comments, Mike.  I hope this helps to clarify some of
> your questions.

Yes thank you.

Regards,
Mike <http://www.bdmicro.com/>