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