I'm currently trying to convince AVRDUDE to work with the JTAG ICE mkII (and ultimately AVR Dragon) when the target is completely in debugWire mode. That way, only a single wire (+ GND, of course) is needed in order to reprogram those target AVRs that support debugWire (all newer ATtinys and the ATmega48/88/168). I made some progress already here.
As debugWire is quite limited in its features, several things simply cannot be done there, for example reading or writing fuses or lock bytes. I'm not quite sure about EEPROM yet. (That triggered my previous question: the erase cycle counter currently always tries to read out the last four EEPROM cells, regardless of whether the user really requested this.) Basically, any unsupported memory operation could simply return a -1, and leave handling the error to the caller. However, there's one thing I came to find really annoying in AVRDUDE's design, and I question its value now: if the respective programmer's read or write byte method failed, avr_read_byte() and avr_write_byte() divert to avr_read_byte_default() and avr_write_byte_default(), and they will in turn try to setup a generic ISP command. For that reason, the "cmd" method is mandatatory for each programmer. Obviously, that cannot work if the programmer in question isn't using any form of ISP at all. I generally question the value of that fallback, unless someone can convince me about it being useful. It would be fine by me, if the respective programmer doesn't support their own read and write byte methods, to use avr_read_byte_default() and avr_write_byte_default() in place. But what sense does it make to retry an individual programmer's signalled failure using that same programmer's cmd method? If people think the current way of doing things is really useful, I'd at least like to make the "cmd" method optional. Currently, the JTAG ICE implementations already fill in a dummy for that method that just writes a message to stderr, and is never supposed to be called at all. The change would then be to skip the above mentioned diversion to avr_read_byte_default() and avr_write_byte_default() if the programmer in question doesn't support the "cmd" method, and rather return that programmer's error from its "read_byte" and "write_byte" methods. Obviously, at least one of either the "cmd", or the "read_byte" and "write_byte" methods will have to be supplied by any programmer implementation. Opinions? -- 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
