FTDIchip's FT2232 USB to SPI converter: fundamental question

[vandelay]

usb to spi converter

I am using an FT2232 chip to provide an SPI interface over USB. When reading up on the provided SPI.dll documentation, I was surprised to find the two functions SPI_Read and SPI_Write. Since SPI is a full duplex transfer, how can it be that there are separate read and write functions provided? Could it be that (since USB communicates in packets), the command is sent to the SPI on write and the simultaneously recieved data dumped, then the expected response data (a given nr of bytes to be read) is read by writing dummy data the same size, transmitting the whole buffer back in a single USB packet? It would make sense as data could be transfered alot faster over USB, but in my case (reading very few response bytes at a time, many commands to many SPI slaves) I am left with alot less effective bandwidth than what the FT2232 datasheet first appeared to indicate.. I read it could do 6MHz SPI (IIRC), but I am starting to suspect that's a clock number I cannot base my bandwidth math on..

Any clarification on this would be great..

 

[coros]

ft2232 spi

It is true that sending few bytes over USB is very slow. I don't know the functions in the spi.dll, because i am using the FT2232 with linux, but i have written my own spi functions for programming avr uP with this chip. At the beginning i sent and received every 4 bytes with a separate FT_write and FT_read commands, and it was very slow. Programming of 32kB flash took about 5 minutes!!. Then i made a buffered writes and reads: write all the data into a buffer and then send the whole buffer with one FT_write. The increase in speed was tremendous - programming now took about 3s. And it is possible to read and write data simultaneously, because the data is stored in a buffer, that can be read with one FT_read command after the transmission is completed. USB has been designed to send packets of data not single bytes. A packet consists of 64 data. If you write less data, then the controller waits a specified time - typically 16ms ( for the rest ) and only after that time has elapsed sends the data. The time can be changed with FT_SetLatencyTimer. So sending few bytes one at a time is very slow - even less than 1kbBs.

Regards

 

[vandelay]

usb spi converter

Thanx alot for sharing your experience, Coros.

I'll just revise my circuit with an extra MCU collecting the data, sending everything back over USB, buffered in a single package.

A question; I only need to collect 24 bytes.. should I perhaps program the MCU to respond with 64 bytes whereof 40 bytes is dummy, to avoid the latency issue?

 

[coros]

usb to spi

You could also write custom functions for reading and writing like i did. Then i think it is not necessary to use additional MCU. When i wrote the avr programmig at first i did like this - the very slow version: For reading one byte from the flash of the avr i need to send 3 bytes command then i read 1 byte response, so i used FT_write with 3 bytes command for avr, then with FT_read i received 1 byte. That was slow. Now the buffered version: for eg i want to read 256 bytes from the avr ( the transfer to avr is still 3 bytes command and address and 1 byte response ).
This i need to send to FT2232: 0x11, 0x02, 0x00, 3 bytes command for avr, 0x20, 0x00, 0x00
0x11 0x02 0x00 is command for FT to send 3 bytes of data, 0x20 0x00 0x00 is command for FT to read one byte from the avr.

So i send 9*256 bytes with one FT_write, then i read 256 bytes with one FT_read. The diffrence is that i don't read the 1 byte of data immediately after sendig the 3 bytes of command, so the FT2232 stores it in its internal buffer and sends it when it is full. Then i get all 256 bytes with one FT_read. For more description read the MPSSE commands description on FTDI site.

 

[IamnotJunk]

ftdi chip

why not use microchip USB solution? There are demos and programs read to go.

 

[vandelay]

ft_read

why not use microchip USB solution? There are demos and programs read to go.

Because USB speed will still be the bottleneck if sending individual bytes, and you will have to program your own PC drivers. Personally, I have an FT2232 DIP module, it comes with drivers, dll libraries, source code examples and driver documentation.. Easy choice for me..

Added after 24 minutes:

coros,

packaging all data on a single "page" is still the way to go for me I believe, and I'll explain why:

The data is read by a real-time program on the PC requiring an update every 0.05 seconds or so (I will vary with different update frequencies). One update needs all the data, as fresh as possible (sensor readings). By reading all the data into the MCU and sending them in a single USB package, I believe I have the best solution for my application.

Besides, I have already designed a board with onboard MCU (dsPIC30F6012). It now uses some analog sensors too, so I will use interrupt-driven A/D conversion and IIR filter the readings, in addition to provide a buffer for the SPI sensors I've programmed alot dsPIC in the past and I have all the MCU code I need embedded in previous projects

I'm all good, thanks for the feedback!!

 

[Fruity]

Re: FTDIchip's FT2232 USB to SPI converter: fundamental ques

Hi,

I actually have a similar question about FT2232 ( I am using the FT2232H but the principle is the same ).

I am trying to use the bidirectional feature of SPI.
I want to send one byte via MOSI while receiving one byte via MISO, so all that in 8 SPI CLK.

I have searched and searched for hours, and can't make it work. It is has if everything was always half duplex.

Hopefully someone on this list will be able to help !

 

[andrepepino]

FT2232 USB to SPI converter

Hello guys!

Well, i´m thinking to buy a FT2232D for controlling 8 audio channels, individualy, using SPI Protocol.

USB -> FT2232D --CH1--> AD8801#1 --CH1,CH2,CH3,CH4--> Amplifiers
|---CH2--> AD8801#2 --CH5,CH6,CH7,CH8--> Amplifiers

BUT, i want to generate each channel signal, so my update rate needs to be faster I can! (approx.: 0,5ms)

I don´t need to read nothing! Just sending data!

Do you think it is possible??

Thanks!