The latency is due to the host application. This may vary on different hosts.
The delay of 1ms for gpio toggle command is expected.
As I mentioned in the thread: Slave Select Out (SSEL_OUT) out timing not in CY7C65211 data sheet - REPEAT with higher frequency the SSEL to SCLK time difference will reduce.
If you are using a GPIO to select a slave, then the latency can be reduced in the host application by calling the SpiReadWrite call as soon as the GPIO is toggled.
The delay incurred in the IC is comparatively very less.
This issue is not related to slave select. Let me reprhase it to hopefully make it clearer what I am asking:
If it takes ~1 ms for a CySetGpioValue function call to complete, why does it take ~15 msec for a CySpiReadWrite function call to complete?
It seems to me that all the data should be delivered to the Cypress IC within ~1 msec over the USB, so does it then take ~13 msec for the IC to take those instructions, produce the SPI datagram, and finally another ~1msec to return the data to the host over USB?
Maybe another way to put it is: what is the total time from all USB data received by the IC to the time that all data from the SPI transaction is ready to be sent back to the host on the USB?
The host library will take some time to set up the request (both read and write) and send the device IO control code to the driver (cyusb3) which in-turn performs the respective operation on the device.
Yes, the IC as well will take time perform the requested operation.
This data is not characterized.
You can use a hardware analyzer or software analyzer like wireshark pcap to capture the traces between the USB-Serial device and the host, determining the actual read/write command sent from the host and response received from the device.
Thanks for the help on this.
It looks like there are at least two areas I can reduce cylce time for my application (which needs to transmit 16,384 bytes total over the SPI):
Issue #1. Reduce the ~16 msec latency per SPI transaction
Issue #2. Reduce the number of SPI transactions (ideally a single buffer of at least the size of the total number of bytes I need to transfer)
I am guessing that increasing the buffer size of the 65211 is not possible?
If not, could I use an FX3 instead for this purpose? The FX3 would solve Issue #2, since a single DMA could handle 65536 bytes, so I wouldn't even need to double-buffer, correct?
For Issue #1, what would be a latency estimate for a bulk USB3 transfer from the host to the FX3?
Is there a different IC that would be better suited than FX3?
If you are looking only SPI interface FX3 is best suited.
We also have FX2LP which has GPIF and I2C, but not SPI.
The transfers in FX3 can be handled using DMA channels (maximum 64KB buffer) in the firmware which will reduce the latency incurred due to the IC. Overall the latency will be reduced. The data can be hardcoded in FX3 firmware. Else, burst transfers can be used to transfer 16KB at once from the host to FX3 (at 3.0 speed).