Q: I am using the Cheetah SPI Host Adapter to test an SPI slave device. My test setup includes Windows 7, Visual Studio 2010, C#, and Cheetah API software.

I'm running the SPI slave outputs data continuously on MISO at 20 MHz clock rate to be monitored by my application. Occasionally, my application sends configuration data on MOSI to the SPI slave also at 20 MHz.

I call ch_spi_async_submit() four times, then repeatedly call { ch_spi_async_collect (), ch_spi_async_submit() }.

Should the SPI clock be continuous?  The queue contains an array of 100,000 bytes and nothing else (no delays or anything) and the SPI clock is 20 MHz.  I am getting a 9-cycle break in the clock for every submit.  Do you have any suggestions to reduce delay?

A: Thanks for your question! The Cheetah Software API architecture allows maximum flexibility of the control lines (SS1, SS2, and SS3) as well as providing a mechanism to avoid USB scheduling delays. Following are two examples to send multiple SPI packets with one transfer:

Example 1:

This example uses sync transfer steps: the ch_spi_batch_shift function returns to the caller after the entire queue has been shifted on the SPI bus.

1. Assert the OE.
2. Assert the appropriate SS, queue the data, and deassert SS.
3. Add delay on the bus.
4. Assert the appropriate SS, queue the data, and deassert SS.
5. Add delay on the bus.
6. Assert the appropriate SS, queue the data, and deassert SS.
7. Call the batch shift function.

In Example 1, one transaction consists of three parts:

• In the first part, the SS signal goes to low, the data is sent, and the SS signal goes high.
• In the second part , the SS signal goes to low, the data is sent, and the SS signal goes high.
• In the third part, the SS signal goes to low, the data is sent, and the SS signal goes high. The SS goes low and high 3 times in this transaction.

Example 2:

This is an alternative, non-blocking implementation that can be used instead of ch_spi_batch_shift:

• The functions ch_spi_async_submit and ch_spi_async_collect allow the user to submit a batch queue and perform other tasks (including assembling and submitting a subsequent queue) before collecting the results of the initial SPI shift operation.
• When using the async transfer, the user can send multiple packets in one transaction, and the SS performs similarly to the sync transfer of Example 1.

As shown in the figure below, when the SS goes low, after tsac (min: 6.5 tclk; max: 7 tclk) the SCLK gets first clock edge. The user can add tud (min: 8 tclk, max: 2^32 tclk) to this period. For more details about Cheetah signaling characteristics, please refer to section 2.5 of the Cheetah SPI Host Adapter User Manual.

Cheetah SPI Signaling Byte-Level Timing

Cheetah SPI Signaling Characteristics

For more information about Cheetah SPI Host Adapter and other products, you can refer to:

Cheetah SPI Host Adapter

Cheetah SPI Host Adapter User Manual

Total Phase Products

Product Selector Guide

We hope this answers your question. If you have other questions about our Host Adapters or other Total Phase products, feel free to email us at sales@totalphase.com or support@totalphase.com.