(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. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
