FT232R USB working but is ridiculously slow

[MOS6502]

I am using a FT232R to download files into a project I have built using a terminal program (RealTerm). The Files download fine with no data lose or any other problems even at high Baud rates.

However, the speed of the transfer is incredibly slow. The file I am downloading is 160kB, at a Baud of 115200 it is taking 1min and 26sec.

I think it should only take 14 seconds (163840 * 10 / 115200 = 14.2).

I am using 8bits of data, no parity, 1 stop bit and no handshaking.

I am only passing the data in one direction (from terminal program to my project), it should just be a continues stream of 160k bytes.

I have experimented with changing a latency and the transfer size but changing these settings did not fix the slow speed problem.

I would really like to know why it takes so long, is it because of the way the terminal program sends the bytes to the FT232R driver? or is it because I am not using handshaking? or some other reason?

Anyone have any experience similar to this or have any ideas what could be causing this?

 

[FvM]

is it because of the way the terminal program sends the bytes to the FT232R driver?

I suppose so. Sending text files with a terminal programm is usally slowed down intentionally. Apart from this problem it's unreliable unless you manage to define a unique start sequence. Binary file transfer methods can be expected to work much faster, there are some that aren't slowed down by a handshake, e.g. YMODEM, which I have used at times for maximum speed software downloads. To achieve full available interface speed, can write to the serial port in a C or C# program.

 

[PaulHolland]

Hi, What happens is that you most likely are calling on your PC side the uart driver (file handle etc) byte for byte, this will result in system call's into windows byte for byte and this will result in you sending a USB frame that normally can hold 1K of data only holding ONE byte. Since the USB frames are scheduled your transfer rate will be very slow. What you have to do is send a block of data, 128 bytes for example !!. And send this yourself not using a terminal program written for a real UART. These old program's are always calling and sending byte for byte since the old uart chips and drivers (dos) worked like this. Sending it yourself to a com port is very simple and not much more than writing a file .

 

[MOS6502]

Thanks guys, that does make sense.

Another issue I have noticed is that when I plug or unplug the USB cable to my project I recieve some random serial data. Is this normal or expected?

My project is in "self powered configuration", so it'a already powered on before I connect or disconnect the USB cable.

Of coarse, if I have the USB cable connected before powering up my project it will run fine, but I would like the project to be capable of hot plugging the USB cable.

 

[PaulHolland]

You should always design something so that it is able to recover from unexpected situations, this also means that you can receive random noise (bytes) before real information is received.

 

[horace1]

seems very slow, are you writing to the serial port a byte at a time or in blocks.
Would be worth trying using hardware COM1 port to see if it is the FT232R or something else

---------- Post added at 14:46 ---------- Previous post was at 14:42 ----------

"Another issue I have noticed is that when I plug or unplug the USB cable to my project I recieve some random serial data. Is this normal or expected?"

I have the same problem with a TTL-232R-3V3 - when I unplug the cable from the USB port I receive odd characters (which I ignore) - probably something to do with the FTDI USB driver

 

[FvM]

when I plug or unplug the USB cable to my project I recieve some random serial data.

On plugging, it may be due to windows trying to identify a serial mouse at the respective serial port. The function can be disabled in system control manager, I think.
Basically the problem would be solved by designing a reliable protocol, as mentioned previously. Unplugging will generate spurious signals anyway.

 

[MOS6502]

Thanks everyone for all the help with this.
Good news, problem solved, so to help anyone with the same problem, you could try what ended up fixing it for me. Placing a 100k pull down on the 12MHz output solved the problem. I am using the 12Mhz clock out of the FT232R for the UART clock, when no USB is plugged in, I hold the FT232R in reset which tristates the outputs. I am not 100% sure why this only caused a problem while plugging the USB connector in, but it was.

 

[luben111]

notice that USB has so called "polling time". USB is not like RS232 event driven interface (it has no interrupt on new data) and the PC have to "poll" the data. So if you use the default Windows polling time (10ms) and you also request the data by sending some command it can take quite long. FTDI works fast if you send the data as a unbreakable stream, but once you start request-answer data the performance could be quite poor