5 Replies Latest reply on Nov 7, 2020 6:23 AM by YatheeshK_36



      Is there any way to reduce the USB-->SPI latency on CY7C65211A on a Windows platform?  When I perform GPIO toggles they take place in about 1 msec but when I perform an SPI transaction of 2 bytes it takes about 15 msec.  So, there's going to be some Windows latency due to USB polling interval, but for USB2 that seems to be 1 msec so I should see 1msec + SPI transaction time for the SPI transaction as well???  This leads me to believe that there is some latency in the IC itself...?

        • 1. Re: CY7C65211



          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.




          • 2. Re: CY7C65211

            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?

            • 3. Re: CY7C65211



              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.




              • 4. Re: CY7C65211



                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?





                • 5. Re: CY7C65211



                  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).