Adventures in spi output

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
Posts: 22
Joined: Wed May 16, 2018 7:28 am
Location: Australia

Adventures in spi output

Postby psupine » Thu Sep 12, 2019 11:27 am

I'm a bit unsure which topic channel I should put this under because it spans a few.

I've been simulating SPI output with a 24 bit samples.

The issues are that:
- port serial data is clocked on the falling edge, but my target DAC samples SDIN on the falling edge
- port serial data is clocked out LSB first, but my target DAC expects MSB first
- I need to either gate the clock for 24 falling edges, or provide a synch frame signal (which I need anyway). 24 bits is not a directly supported transfer size in xC.

The XMOS lib_spi code controls the clock phase by faking a half rate clock written as uint32_t consisting of alternating ones and zeros. To match this approach the data word must be modified so that each bit occurs twice, and the lib_spi code does this by a brute force lookup-table that maps 8 bit indexes in 16 bit values, and it cleverly does the bit reverse in the same lookup step.

I appropriated that library code and modified it to transfer 24 bit words instead and all simulated just fine, but then I remembered that the XS2 instruction set includes single instructions for both bitrev AND zip. I rewrote my code so that it didn't use the lookup table approach used by lib_spi but used these two instructions instead. This gave the same answer as before only faster. I can only assume that the lib_spi was written under XS1 and either hasn't been updated or is stuck as legacy.

Anyone who is writing SPI based code on XS2 parts should have a look at how the library does this bit stuffing and then look at the zip instruction.(*)

While I was re-reading the various specs I also found set_port_inv() and partout(). As far as I can tell, set_port_inv() can NOT be used to modify the sense of an output. The spec talks about a "driven pin" but it is unclear whether the pin is driven from externally or from internal buffers. I tried to use it to invert an output clock port in simulation, but that didn't work as I'd hoped. Inverting that clock edge would be, I think, the only aspect that prevents being able to use the SPI without the data bit replication and manual clocking shenanigans.

Can anyone confirm that output clock ports cannot be inverted at the pin?

* I love the chip, but honestly, a zip instruction?

Who is online

Users browsing this forum: No registered users and 5 guests