0
\$\begingroup\$

How can I get very high speed from a FTDI chip?

I have tried with FT232RL with UART in 230.4kbps but I want much more than this. Will I need some other different speed?

\$\endgroup\$
  • 1
    \$\begingroup\$ What are you trying to accomplish? What is the data source/sink? A megabit should be achievable, but you can go much faster with a device like a CY7C68013A \$\endgroup\$ – Chris Stratton Aug 22 '14 at 15:27
  • \$\begingroup\$ I'm trying make Real time monitoring with AVR and some sensors, like adc,temperature, ultrasonic sensor etc. Im using VS C# for software and ftd2xx_net.dill \$\endgroup\$ – MrBit Aug 22 '14 at 15:48
  • 1
    \$\begingroup\$ Until now I have accomplished a simple communication program between atmega32 and pc via ft232rl. The pc sends 1 byte on mcu, mcu writes this byte to an lcd 1602 and sends two bytes as response back to pc witch corresponding to an adc conversion. My program print the result on Windows form and updates a progressbar \$\endgroup\$ – MrBit Aug 22 '14 at 15:54
6
\$\begingroup\$

The pc sends 1 byte on mcu, mcu writes this byte to an lcd 1602 and sends two bytes as response back to pc witch corresponding to an adc conversion.

Your problem isn't bandwidth then, but rather with latency. People think of the USB bus as being very fast, because for most purposes, once it gets started moving packets of data it can move a lot in them quickly.

However USB is also extremely slow in one respect: it takes a comparatively long time to start moving a packet of data. When the data comes in small chunks, and sending new ones depends on receiving the response to previous ones, you constantly suffer that latency, and your data rate falls far below what the USB or continuous baud rate can support.

Typically the opportunity to start a transfer comes about 1000 times a second, and if you only send one byte per transfer that means your effect data rate is a mere 1000 bytes per second (the 1980's called and they want their dialup modem back). But actually, your progress is even slower, as you need to send two bytes in the other direction before you can do it again. So likely you are accomplishing fewer than 500 cycles per second...

You need to redesign your protocol so that you can move large amounts of data in each direction without requiring confirmation - it's waiting for that round-trip over the USB bus that is killing your throughput, not the actual baud rate. By itself, a chip with father baud rate or USB version won't actually help.

Your existing hardware may actually be fine.

\$\endgroup\$
  • \$\begingroup\$ In the future I will try to support transmission of whole buffer.., this means at least 128bytes in 4,5ms. But I want to achieve this more quickly, for example 128 bytes in under 500us \$\endgroup\$ – MrBit Aug 22 '14 at 16:30
  • \$\begingroup\$ It may be worth noting that some newer FTDI chips use the "high speed" rather than "full speed" mode of USB 2.0 and as a consequence get 8,000 chances per second to communicate rather than only 1,000. \$\endgroup\$ – supercat Aug 22 '14 at 16:41
  • \$\begingroup\$ I think ft232rl chip running already on usb 2.0 but as I see my problem its unresolved as I using atmega32 because this mcu does not go much more than 230.4kbps \$\endgroup\$ – MrBit Aug 22 '14 at 16:46
  • \$\begingroup\$ The ftdi chip working with d2xx drivers and baud rate for uart its in max speed of my mcu \$\endgroup\$ – MrBit Aug 22 '14 at 16:56
  • 1
    \$\begingroup\$ Real time communication is not what USB is for. If the (possibly reduced with USB-HS) latency is too high, move your processing to an embedded board with direct (or at least local bus) I/O, or change your requirement. \$\endgroup\$ – Chris Stratton Aug 22 '14 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.