[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avrdude-dev] Is the fallback to the generic ISP command really useful?

From: Joerg Wunsch
Subject: [avrdude-dev] Is the fallback to the generic ISP command really useful?
Date: Wed, 15 Nov 2006 22:53:02 +0100
User-agent: Mutt/1.5.11

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

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


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]