#71 Support for cable modes (e.g. SPI) other than JTAG

open
nobody
None
5
2008-04-17
2008-04-17
Kolja Waschk
No

Date: 2008-04-11 18:48
Sender: vvoipio
Logged In: YES
user_id=103853
Originator: NO

SPI is an interesting thing, because JTAG is essentially a subset of SPI. They use the same pins with a bit different names:

TCK <-> SCK (clock output)
TDO <-> MISO (input)
TDI <-> MOSI (output)
TMS <-> nSS (output)

This mapping makes all JTAG bit-bang hardware able to act as a SPI master. Even some more sophisticated hardware can do it, for example the FT2232 MPSSE is able to run SPI. Highly dedicated hardware (not able to change clock polarity, internal TAP, etc.) is then another thing.

To implement SPI we need the following things:

- ability to set up the polarity and clock phase (CPOL, CPHA)
- ability to set the nSS state
- ability to exchange a message of n bits

And that's it. This is also enough to make a JTAG interface, but JTAG benefits from having a separate mechanism to run the TMS instead of stepping it one bit at a time. SPI in general makes little use of nSS within a message.

I should not think this would be exceedingly difficult to make in the cable drivers. It just requires that there is an agreement on the API.

---

Another thing is that once we have the low level SPI running, different programming algorithms, etc. need to be written on top of that. I, for one, would be interested in programming AVRs with UrJTAG.

But even without the higher level, a simple SPI machine might be worth the trouble. It would enable simple prototyping and manual programming of all sorts of tiinyweeny things.

---

I2C (and SMBus) is then a fish from another bond. It cannot be run with he same HW, so it requires more effort than just seeing that the pins are in the right order.

Discussion