Re: [avrdude-dev] Re: [AVR-Chat] AVRDUDE 5.0 BETA Release

[Joerg Wunsch]

(No idea whether my Cc to the yahoogroups list will be accepted, but
I'll give it a try.)

As Brian Dean wrote:

> > 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 ...

Why that?

Besides, the chip names are rather common abbreviations (even IAR uses
the very same abbreviations for their compiler's MCU option), but you
can always use the long names which happen to be the official AVR chip
names (case-insensitive).  So if you're going to program an ATmega128,
you can either say "-p m128", or "-p atmega128", or "-p ATmega128".
If you don't remember it's the -p option to tell avrdude about the
part name, just say "avrdude", and watch the usage output.

Btw., the default programmer type (-c option) and (hardware) port (-P
option) can be customized in the avrduderc file ($HOME/.avrduderc on
Unix, offhand I'm not sure about the Windows filename).  That way, the
only remaining mandatory option is -p for the part name.  Of course,
you'll most likely also want to supply either one of the -U options,
or the -t option for an interactive operational mode.

> Implementing it as a GUI application on Windows-only is not at all
> within the goals of the AVRDUDE project.

There was/is an attempt to provide a GUI frontend for it (avrdude-gui
on sourceforge.net), but it seems the author of that attempt has been
sidetracked quite a bit.  Currently, it's in pre-alpha state.

> > 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.

Remember it cannot work for all AVRs, notably not for the AT90S1200.
That MCU has a different ISP protocol, and as you need to know that
beforehand, you cannot guess the chip type.  (That's also been the
reason why UISP did not work for the AT90S1200, at least not in the
early versions I've been trying by that time.  avrdude could be made
work for it, so I became an avrdude user.)  Also, there's always the
chance that a particular chip has a damaged chip ID (yet still works
correctly anyway).  I've seen that more than once, albeit not lately
(i.e. only for older AT90 chips, maybe it's fixed now).

But auto-discovery would work reliably enough on other chip types,
yes.

> > 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.

The mkI might follow later, but I won't make any promises about it.

It's sufficiently similar to the mkII to perhaps allow cloning the
mkII code, yet sufficiently different not only in its communications
protocol but also in subtle other ways.  For example, flash ROM is
addressed in 16-bit units on the mkI, while all memory areas including
ROM are addressed in 8-bit units on the mkII.  Yet, you cannot specify
an odd byte count in a memory read operation for ROM on the mkII (at
least not when using the SPM memory type), even though you can specify
an odd start address...

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)