Weird behavior of FTDI breakout board (NOT ftdigate!)

[derGoldstein]

Hi all,
First to clarify: this has nothing to do with the FTDI driver fiasco, the chips weren't bricked.

I normally use 2 USB/Serial chips to communicate with (mostly) PIC projects: FT232R and CP210x. Usually I'll see if I have a FT232R available and use that one, otherwise I'll use a CP210x. I've never noticed any difference in behavior, except for the drivers appearing differently. I never needed to move data over UART at higher baud rates (over ~57600), but now I do and suddenly there's a huge difference: the FTDI chip doesn't seem to "allow" anything higher than 57600.
But that's not the really weird part: when I set a device to a higher baud rate, the device WORKS -- it just works much more slowly... So if I set the baud to 460800 (on both the PIC and the software on the PC) and use the CP210x part, I get the transfer speeds I expect, but if I replace it with an FT232R, it moves data around about 4 times slower.

I think I removed all other variables: I used 2 different FTDI chips and several different CP210x chips. I also replicated the circuit on a breadboard with the same components, and the same code on the PIC. Everything else behaves the same, except that the FTDI chip is slower.

I'm really at a loss, I don't know what else to check. I googled FTDI baud rate problems, but whenever a baud rate problem shows up the FTDI chip blocks the communication, it doesn't *slow it down*... The only thing I can think of is that both of my FTDI chips are from SparkFun, specifically a retired product: https://www.sparkfun.com/products/retired/718 ... But it was retired because people wanted a 3.3v/5v switch, not because it didn't work.

Any help would be appreciated.

[moffy]

Have you tried running it at the 5v I/O?

[derGoldstein]

It's running at 5V. If it was a voltage problem I assume it wouldn't work at all, as opposed to working in weird way.

[westfw]

Using what application on the PC side?
USB throughput is highly dependent on the Application/Driver combination being able to efficiently aggregate data into packets.  It's not hard to imagine a situation where you get limited by the USB packets/sec rather than the bitrate on the serial side.

FWIW, various arduino people report upload speed improvements operating an FTDI at 1Mbps..

[derGoldstein]

The PC is running a very simple python script, using PySerial. The final program will be more complicated but just testing the data transfer is trivial.

If the solution is doing anything with the driver then I'm in trouble... I'm trying to make it as easy to use as possible -- plug it in, install the driver (if it's not already installed), and run the software. I thought that the FTDI chips have a reputation of being the easiest to work with (ahem, except for the bricking possibility), I definitely didn't think you'd have to mess with the driver settings.

If it's a problem with the driver settings, what should I be looking for? The "USB transfer sizes" are at their max values at the moment. I tried selecting the baud rate manually in the driver port setting but that didn't have any effect (I don't even know what that's supposed to do, I thought that was set by the software on either end, not the driver).

If all else fails I'll boil it down the the smallest possible PIC program and the simplest possible python script, but it seems to me that if it works with the CP210x chips then the only difference is in the USB/serial bridge.

[derGoldstein]

Found it: It's the "Latency Timer" setting in the advanced driver settings. I systematically went over all the settings until I found what had an effect on the transfer rate. I then googled it and found this: https://projectgus.com/2011/10/notes-on-ftdi-latency-with-arduino/    . What I don't understand is why would the default driver settings be gimped? Why would you ever set the latency setting to higher than 1? I'm sure there's some reason but I can't think of it...

Anyway, thanks a lot for pointing me to the driver settings!