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

[Wouter van Gulik]

Joerg Wunsch schreef:
> 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.

I understand why it is like it is these days. I would not have done in 
different ;)

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

Adding SPI multi in to a stk500v2 programmer is not a big issue of 
course. But adding SPI commands and STK500v2 commands to a bootloader, 
is total overkill.

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

We could just generate a new programmer type stk500v2_isp_command or 
something alike that explicitly uses the command set, and not changing 
the default behavior.

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

My bootloader only works with AvrStudio, there is no room to implement 
the SPI decoding in parallel, having it work with avrdude is a nice 
feature. ;)

But more seriously maybe we gain some speed? Because we have less 
overhead? (Just wildly guessing here). The downside is that avrdude is 
more depending on the firmware inside the programmer. The SPI_MULTI 
route is almost independent of the firmware. As long as SPI multi is 
supported we are ok.

But the main thing we gain is that users can create bootloaders that 
work well with AvrStudio and avrdude. Not just one of them. That is 
where this whole discussion was about... :D

Besides it is not that hard to implement? The protocol layout equals the 
HVSP, it's just the command opcodes that needs to be changed. Kinda like 
the HVSP/Parallel solution that is now in avrdude.

Wouter