AVR-Chat

Hi Tom,

On Thu, Oct 27, 2005 at 10:09:38AM -0500, Thomas Keller wrote:

>   May I offer a friendly suggestion?

Of course!

>   If you were to document (I haven't read the docs, perhaps you have
> already done this?) the format of the data needed to give AVR Dude
> the ability to work with specific devices, you could work in a
> fashion more in keeping with the open source philosophy, e.g., as
> new devices are introduced by Atmel, those who need the ability to
> work with them could develop the apriopriate configuration files,
> and then submnit them to you for inclusion in the project, as well
> as making the availabnell much mor equickly than waiting until the
> project members have the opportunity to build the configurations and
> prepare a new release.

You have described the way it currently works.  The part definitions
are documented in the avrdude.conf file where the part definitions are
maintained.  Also, there are plenty of examples there as well.

The specifics for each AVR processor are encoded in the avrdude.conf
file in a form similar to the way the programming information is
presented in the actual Atmel AVR datasheets.  The avrdude.conf file
is an ASCII text file, editable by any text editor.  The AVRDUDE
executable parses this file on startup using a custom grammar
developed for this purpose, and loads the part definitions into
memory.  No part information is built into the executable file itself,
thus, when a new part becomes available, one only has to update their
avrdude.conf file to gain the ability to use that part.  Thus, folks
don't have to wait for a new AVRDUDE release to get support for a
processor that is not yet available in the current release.  Most
recent part definitions, in fact, have been submitted by folks from
the AVRDUDE user community.

Similarly, programmer pinout definitions are also configurable to a
large degree, at least within the parallel port class of programmer.
Everybody and their brother has their own parallel pinout for their
homemade programmer.  I recognized this early on and made AVRDUDE
configurable in this respect.  To add a new pinout, you simply create
a new programmer name and tell AVRDUDE which pins of the parallel port
do what.

Also, the programmer model in AVRDUDE is written in an object oriented
way similar to a device driver.  It is not very hard to add an
entirely new programmer type.  Different programmer types include the
PPI (parallel port interface where the parellel port pins are
bit-banged to generate the programming sequence), STK500 (Atmel stk500
V1 protocol, AVRISP, etc), STK500V2 (stk500 V2 protocol), AVR910,
butterfly, JTAG MkII device, etc, etc.  To implement a new programmer,
it is primarily simply a matter of implementing each major routine for
using that programmer.  While not as easy as adding new part
definition or a new parallel port pinout, it is designed to be
extensible and accessible to those with modest C programming
knowledge.

Thus, whether you are a programmer or not, contributions to the
project are possible depending on your need and skill level.

>    As a further (and perhaps not as welcome a suggestion) idea, you
> could make the entire processor interface configurable, thereby
> making it possible for users of other processor families to make use
> of your excellent work.  Atmel, as we all know, provides processors
> other than AVRs, and much as I hate to say it, PIC programmers
> coulod certainly benefit from the ability to use your tool.  Let us
> not forget the Freescale, Analog Devices, Philips, Topshiba, Zilog,
> Intel and the many, many other embedded processor families that are
> out there, as well.

Regarding the support for other processors, that will have to wait for
someone else to step up.  We stay plenty busy enough supporting just
the AVR line.

>    And, yes, I would be more than willing to participate in the
> programming effort for such a modification to the AVR Dude tool.

Thanks, Tom.  We welcome contributions to AVRDUDE as many here can
attest.  See the ChangeLog file for a list of contributions - we name
names in the ChangeLogs and CVS commit records so folks do get
recognized for their efforts.  Major contributors are listed in the
AUTHORS file, though I see a few notable omissions there that I need
to correct.  Please feel free to help in whatever way you can.

-Brian
-- 
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/