Re: [avrdude-dev] Re: STK500v2 Programmers (was Hello)

[Joerg Wunsch]

As Wouter van Gulik wrote:

> There is however one catch. The current stk500v2 implementation in
> avrdude (for ISP) is via the CMD_SPI_MULTI.

This has mainly historical reasons.  AVRDUDE started up implementing
the ISP protocol by itself.  Later on, when STK500 protocol support
has been added, it was mostly implemented by wrapping the existing ISP
protocol around the SPI_MULTI command, because that's been the
simplest way to accomplish the job.  Same for STK500v2, it's basically
been a fork of the STK500v1 implementation, with just the
communication protocol changing.  Only the block read/write functions
have been implemented on top of true STK500 commands, but all
single-byte operations (terminal mode, but also all fuse and lock bit
stuff) still remained on top of SPI_MULTI.

> It a sort of raw SPI stream (I guess, never really looked into it).

Exactly.

> The same problem arises for a bootloader that supports stk500v2, it
> depends on what you want to support, avrdude or AvrStudio.

Well, full command support is probably a bit more work to implement in
the firmware, isn't it?  Just adding SPI_MULTI in addition to it is
most likely not going to add much more, given that it's a very raw
procedure.

> Are there any plans on supporting programming ISP via the opcodes?

I contemplated using it for the STK600 implementation, but then,
continuing to use SPI_MULTI works fine. ;-)  It would certainly be safe
to use the non-SPI_MULTI mode for genuine Atmel tools like the STK600
or AVRISPmkII.  However, I'm somewhat hesitant to generally apply it,
for just the reasons you mentioned: if someone developed a firmware to
work just with AVRDUDE, they might leave out a good bit of commands,
knowing that AVRDUDE mostly uses SPI_MULTI.  Now, if AVRDUDE suddenly
started to insist on the native STK500 commands, these firmware
implementations might fall over.  Now assume this is just a bootloader
implementation where every byte eventually counted, so there's not been
much space for a correct ``Not implemented'' response for the other
commands, and suddenly these people would be hosed...  So now I simply
don't know what to do.

Opinions on this?  We could add some -x option to tell the
implementation to resort to SPI_MULTI.  OTOH, what gives?  What would
be gained by not using SPI_MULTI?

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

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