FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Tycho

Pages: [1]
Discussion - Hardware / Re: FT232H SPI 30 MBaud wrong transmission
« on: June 16, 2021, 12:19:16 PM »

SPI modes 1 and 3 are not supported with our MPSSE engine.
If you require these modes, then you will need to consider FT4222H:

Best Regards,
FTDI Community
Actually, CPOL=1, CPHA=0 is SPI mode 2.

Discussion - Hardware / FT232H SPI 30 MBaud wrong transmission
« on: June 10, 2021, 12:12:10 PM »

I'm getting wrong readout values if I increase the baud rate to 30 MBaud, see screenshots. I'm transmitting 0x1010 as MSB, CPOL=1, CPHA=0. At 5, 10 and 15 MBaud everything is ok, but at 30 MBaud, although the oscilloscope picture seems to be ok, there is a bit shift.

Are there any issues with FT232H SPI at high baud rates?

Thank you very much in advance!

Discussion - Hardware / Re: FT232H SPI continuous readout
« on: June 04, 2021, 10:31:52 AM »
If I understood it correctly, LibMPSSE DLL is built on top of FTD2XX.dll. This will not solve my problem because I already implemented SPI with FTD2XX.dll.

The question is: are the delays caused by USB bulk in general or is it wrong use of FTD2XX.dll on my side?

Discussion - Hardware / FT232H SPI continuous readout
« on: June 02, 2021, 09:05:10 AM »
I'm using FTDI C232HM HiSpeed USB 2.0 cable to communicate with a SPI interface. The device is based on FT232H chip from FTDI. I would like to continuously read out a SPI device which has 800 kBaud data rate. It also has a RDY line, which is connected to GPIOL1 line of FT232H. After every conversion inside the device RDY line is toggled and I can wait on high/low with 0x88/0x89 MPSSE command.

To do a burst read out I'm sending
//single sequence start
0x88 //trigger on high

0x80 //Chip Select low

0x20 //burst readout 8 bytes

0x80 //Chip Select high
repeat, but now beginning with 0x89 //trigger on low
//single sequence end

I can send this sequence to MPSSE and it works fine. I'm getting two SPI readouts directly after every RDY line change (seen on oscilloscope). If I send the sequence x 1000 in one write to MPSSE it works fine, too.
The problem starts if I try to adapt this scheme for continuous readout. To do read outs continuously I tried to write to MPSSE a second time directly after the first write. But the second SPI start is delayed, I think due to USB bulk mode.

My idea was that there is a queue on MPSSE, it is processed continuosly and I can fill it during processing from time to time to have an endless data stream, so I increased the first write to 3200 sequences. The SPI sequence burst lasts 25 ms but the second sequence burst only begins after a 35 ms delay, although it is written directly after the first. With flush command 0x87, not waiting for availability of complete SPI readout but reading out only the actual received SPI bytes and other tricks it seems to work fine for some time, but only until I switch e.g. to a browser or Win10 starts to do other tasks in background, something like locking the screen due to inactivity. Then I get delays that are sometimes longer than 100 ms.

Is it possible to use MPSSE/FT232H for low latency continuous SPI readout? Maybe there is a driver which has isochronous transfer mode?

Thank you very much in advance!

Pages: [1]