1 ms delay for SPI->USB transfers

[joeromano]

I have been using the SUB-20 C API with great success, but would like to know if it is possible to change the following:

I am using the SUB-20 as a master to do SPI read/write operations at 4MHz, and then read that data into a PC via USB using the provided XDimax API. I have noticed that the sub_spi_transfer(...) function is a blocking call that takes approximately 1ms to complete. Using an oscilloscope to observe the SPI transfer behavior I have noticed that the SUB-20 correctly does the SPI master communication at 4Mhz, and then uses the remainder of the 1 ms window to just pause and wait until the next sub_spi_transfer(...) command. Is there any way to reduce this 1 ms delay? I assume it has something to do with USB communication rates, which I am not very familiar with. I would very much like to reduce this delay if possible.

Thanks for any help or explanation that anyone can provide.

-Joe

[xol]

Hi Joe,
The problem does related to USB communication. Your assumption was correct.
USB Host (PC in your case) has 1ms USB frame. It means any new USB transfer can be started only with new 1ms frame. That's why back to back spi_transfer calls have 1ms gap between.
The most simple way to eliminate it is to use longer transfers. I mean if you need to send 10 bytes sent them in one call to spi_transfer.
Another option is to use USB2 hub. USB2 frame is 125us.

[joeromano]

Thanks xol for the quick response!

That explanation does make sense to me.

I am using the SUB-20 under linux and I checked via the "lsusb" command and noticed that the SUB-20 was getting automatically recognized as a USB 1.1 (full speed device), and not a 2.0 high-speed device. Should the SUB-20 be recognized as a USB2 high-speed device? Basically I am wondering if the SUB-20 is actually a USB2 high speed device and it is just my operating system recognizing it incorrectly and accessing it via full-speed. Anyone have any thoughts on why that would be happening or how to fix? I will keep playing with it and see if I can force it to be recognized as high-speed.

[xol]

SUB-20 is USB1.1 device and your system recognize it correctly.
What I mean is that on USB-2.0 systems with high speed hub frame can be reduced to 125us even for USB 1.x devices behind hub.

[jkesterson]

Hi Joe,
The problem does related to USB communication. Your assumption was correct.
USB Host (PC in your case) has 1ms USB frame. It means any new USB transfer can be started only with new 1ms frame. That's why back to back spi_transfer calls have 1ms gap between.
The most simple way to eliminate it is to use longer transfers. I mean if you need to send 10 bytes sent them in one call to spi_transfer.
Another option is to use USB2 hub. USB2 frame is 125us.

The simple way to eliminate the lost bandwidth (using larger transfers) doesn't work apparently due to the limited size of the buffers in the device. If you try to do a large transfer, after about 59 bytes are transferred, then the usb must transfer another "block" of data, which through the 1 msec "blocking" appears to be no faster at all.

What is worse than that is that the slave select terminates after the first block; and therefore the slave doesn't get the data anyway. In order to make this bandwidth effective, it seems that the sub-20 needs more buffer space.

Perhaps it is there (?) and I have not found out how...

John.

[xol]

Hi Joe,
What is worse than that is that the slave select terminates after the first block; and therefore the slave doesn't get the data anyway. In order to make this bandwidth effective, it seems that the sub-20 needs more buffer space.
John.

It is not correct. Please check it again and make sure you are using latest firmware and library. We have fixed Slave Select issue a long time ago.
But if you are sure there is a problem let us know.
Good news are that we are working now on increased SPI buffer. I believe release will be ready next week. Keep watching the forum.

[xol]

Release ready:
viewtopic.php?f=2&t=3&p=172#p172