Whats UART->USB Chip like FTDI FT232RL is Thinking in Term of Mbps Speed? - Page 1
Forum section: electronics / projects

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 07, 2011, 04:54:47 pm
content: maybe an old statement, but... FTDI claimed to support USB2.0 full speed, ie 12Mbps = 1.5MBps, but i only can do 64KBps fastest with it, WTF?!64KBps is USB0.5. not even close to USB1.1 Std Speed 1.5Mbps (187KBps)whats the faster uart to usb chip out there? 480Mbps will be better, USB3 5Gbps will be the best. even the USB1.1 187KBps++ will be better than FTDI232RL!

author: Simon
author_rank: Unknown
timestamp: November 07, 2011, 05:26:50 pm
content: USB2.0 is 480 Mbps

author: enz
author_rank: Regular Contributor
timestamp: November 07, 2011, 05:44:15 pm
content: Quote from: Simon on November 07, 2011, 05:26:50 pmThis is normally called High-Speed, while Full-Speed refers to 12Mbps.Quote from: Mechatrommer on November 07, 2011, 04:54:47 pmThe reachable USB transfer rate heavily depends on the device you are talking to and the software you are using.1. What is the exact setup for your transfer rate mesurement?2. What device are you talking to3. Are you using ths VCP (Virtual Com-Port) drivers or D2XX driver4. If you are using the VCP driver, of course your transfer rate will belimited to the configured baudrate.Maybe these points can give you some hints.Best regards,Martin

author: ejeffrey
author_rank: Super Contributor
timestamp: November 07, 2011, 05:47:50 pm
content: Full speed vs. low speed is mostly important because it limits the amount of bus time taken up and low-speed devices have limitations on packet length and type. The protocol speed is limited by the operating speed on the UART side. The fastest standard rate (from the 16550A UART family) for RS232 is 115.2 kbps. Multiples of that up to around 920 kbps are pretty common. The FT232R data sheet claims that it operates at up to around 3 Mbps, or 300 KB/s (each byte takes 10 bit slots counting the start and stop bits). The actual usable baud rate will depend on your level shifter and cable (if present), and receiving device. Also, that is the signaling rate: depending on the speed of your endpoint devices you may not be able to saturate it.Even if you find a transceiver that supports it, very few devices can talk RS232 at much above ~ 1 Mbps or RS485 at above 10 Mbps. If you need much higher speed, you will probably be better with a protocol designed for that purpose -- native USB being the most obvious answer.

author: jahonen
author_rank: Super Contributor
timestamp: November 07, 2011, 05:48:28 pm
content: Don't mix signaling speed with real speed you get using certain USB device. 480 Mbit/s is the gross bit rate, and depending on the used packets, the actual throughput might be very much less. In fact, if you send only one character per packet, then you can only send about 8000 characters per second, since USB 2.0 microframe interval is 125 µs.If you want maximum throughput in an application level, then you have to use full custom USB device using USB endpoints directly, forget those serial UARTs. Note that operating system may also limit the actual throughput for various reasons, like you can't get the theoretical latency for the data transfer but instead it is similar to the task scheduling interval.Regards,Janne

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 07, 2011, 11:24:25 pm
content: sorry i was not clear. i'm talking the ftdi that tucked on the arduino mega board. i used d2xx driver, i just re-read the usb bulk transfer doc for the ftdi, it said bulk transfer... 64Bytes max in one packet, sent at 1ms interval, exactly what i'm getting, cakculating... 64KBps. but in the spec... "USB2 Full Speed" shrug.

author: ivan747
author_rank: Super Contributor
timestamp: November 08, 2011, 12:32:17 am
content: Quote from: Mechatrommer on November 07, 2011, 11:24:25 pmYou can do up to 3 mbps according to the datasheet. Remember, an Arduino can't run this fast and it is very likely you won't need 3mbps because there is no space to store enough data to need that speed on the Arduino. In addition to that, there is a delay between USB packets. You have to wait for a 64 byte buffer to fill so the data is transmitted over USB or wait for a timeout (I think it is configurable) to expire so the chip can send the data to the computer via USB. That timeout really sucks when you need to transfer 3 bytes as quick as possible.Note: mbps is mega-BAUD per second.

author: shadewind
author_rank: Frequent Contributor
timestamp: November 08, 2011, 12:55:04 am
content: USB Full Speed refers only to the transfer mode, I believe, not to the actual transfer speed.

author: IanB
author_rank: Super Contributor
timestamp: November 08, 2011, 01:22:01 am
content: Quote from: ivan747 on November 08, 2011, 12:32:17 amI think it's megabits per second. 1 baud is not necessarily the same as 1 bps.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 08, 2011, 11:04:27 am
content: @Janne: thanks for explaining. maybe i should look into the "utilizing USB endpoints" thing.@Ivan747: i configured Arduino to send 2Mbps, but this 512Kbps USB thing is the bottleneck Arduino has to wait for it. i only successfull at transferring max 512Kbps if i send a full 64bytes data, so i have to utilize all this 64bytes as much as i can. i'm not sure how to configure it any faster (i tried 0, 10, 100 latency setting in d2xx driver, no better at all. still stucked at 512Kbps max). i believe the 3Mbps max you're talking about is the uart speed, not USB speed.@IanB: agree with your definition of baud vs bit. but in this modern world, there's less point to send 1 bit in 2 bauds (if its really existed), somostlybaud = bit (for digital 1,0). i said mostly, i dont say exactly. i do aware though to send 1 byte through uart, we need 10 bauds to do it (parity/end bit whatnot)but from my layman's POV, when the USB spec said 12Mbps, i'll expect that or somewhere near that. from what i can see, FTDI failed to utilize this BW in their uart->usb implementation, or there's some config i havent know yet. 512Kbps on 12Mpbs capable device/protocol is a failure IMHO, even the USB1 1.5Mbps benchmark. i hope i can be corrected.

author: IanB
author_rank: Super Contributor
timestamp: November 08, 2011, 03:42:04 pm
content: Quote from: Mechatrommer on November 08, 2011, 11:04:27 amNo, you cannot "send 1 baud" down a connection. That is not how baud is defined. 1 baud is defined as 1 symbol per second, and one symbol can represent several bits, depending on the physical encoding used. So it is possible for the baud rate to be lower (maybe multiples lower) than the bit rate. (Back when modems were in common use the 28.8 kbps high speed modems were still operating at 2400 baud, since 2400 baud is about the maximum rate a telephone line can support.)Basically you should not use the term baud unless you are a communications engineer. Just use bits per second (bps), since that is what matters to an information systems or software engineer.

author: ejeffrey
author_rank: Super Contributor
timestamp: November 08, 2011, 04:26:45 pm
content: Quote from: Mechatrommer on November 08, 2011, 11:04:27 amYour expectation is unrealistic and wrong. That is all there is to it. USB full speed is the protocol speed, which is 12 Mbps. That is all it means.QuoteThe FTDI chip in question supports async serial signaling rates of up to 3 Mbps. Its sustained transfer rate is lower due to buffer sizes and frame delays, and even if it weren't, the arduino itself can't go this fast. The failure is in your expectation: expecting link speed to equal device sustained throughput is just wrong.

author: GrumpyDave
author_rank: Contributor
timestamp: November 08, 2011, 04:56:59 pm
content: Hi MechatrommerMaybe you are not using bulk transfer mode but interrupt?Could be related or just a co-incidence but the reason I say this is because USB Human Interface device specification (HID) gives a maximum 64 bytes transfer per every 1ms interrupt, so 64Kbyte/sec. It all depends how you identify your device to the computer during enumeration.Also that is for "Full speed" (12mbit) standard, for "Low speed" HID transfer will give you 800 byte/sec, I.E. One byte per 1ms interrupt.Regards.

author: Neilm
author_rank: Super Contributor
timestamp: November 08, 2011, 07:10:43 pm
content: I have successfully used the FT232RL at very much faster speeds than those you report. Is this on a PCB that is properly laid out? You might find that some of the problems you are having are due to the tracks not meeting the specification.Neil

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 09, 2011, 08:08:13 am
content: Quote from: ejeffrey on November 08, 2011, 04:26:45 pmi admit that my expectation is highly probably wrong, thats why i stand to be corrected. but before i make further statement... what is "protocol speed"? why "protocol speed" is alot more than "data speed"? is it like USB has to send multiple times of the same data through the line? just as in "long distance/redundancy/noisy communication theory"?Quote from: ejeffrey on November 08, 2011, 04:26:45 pmyes i know about the 3Mbps thing. and i can send data from Arduino at 2Mbps flat, i know that. i'm talking about the "USB side of the thing" (512Kbps only) not "uart/async serial side" (2Mbps from Arduino), sorry if its not clear to you. and again, whose "buffer sizes and frame delays"?Quote from: GrumpyDave on November 08, 2011, 04:56:59 pmi use polling. i've used interrupt. and from the doc, what i've used is bulk transfer mode... 64Bytes per packet, 1ms interval between packets.Quote from: GrumpyDave on November 08, 2011, 04:56:59 pmthis is my point is that 64KBps != 12Mbps, but we should not be surprised as HID is not bulk data intensive application. and i'm not talking "Low Speed" HID spec. let us stick to what is "12Mbps USB2 Full Speed" specification. and how do i make PC to identify or enumerate Arduino+FTDI as Hi (Full) speed device?Quote from: Neilm on November 08, 2011, 07:10:43 pmplease do advice how fast is it? whats the setting in d2xx driver? and is this suggesting, that my Arduino Mega bought from chinese ebay (which i think complied to Arduino Spec) has its board layout wrong?attached txt is how i set d2xx parameters in C++. its FTDI class calling setDefaultParm from class constructor, and later i mod the parm in OpenDevice, FWIW if someone wonder.

author: Bambur
author_rank: Regular Contributor
timestamp: November 09, 2011, 04:57:58 pm
content: Mechatrommer, in order to get high data transfer rates you need to use several endpoints in your USB device and do several large transfers on the PC side in the same time. This way you increase the utilization of USB, i.e. USBD will schedule more transactions to your device through USB Host Controller. USB is trickier than just a serial bus

author: westfw
author_rank: Super Contributor
timestamp: November 10, 2011, 04:29:48 am
content: I'm pretty sure that with a "bulk transfer", the host can transmit more than one packet per millisecond, as long as that doesn't interfere with polling other devices on the US bus at least once per millisecond. The receive direction I'm less sure about, but I would assume that is also the case (after all, other "full speed" devices achieve more than 128Kbytes/s) Whether the driver (and etc) supports this or not is a separate question :-( I'd expect maximum throughput to be with a buffer size of 64 bytes, since the FTDI only claims to have 128bytes of output buffering. I'm pretty sure that the input buffer of 256 bytes puts a limit of 2.56Mbps on input speed; even if it can transfer more than 128byte/ms, it shouldn't end up polled more than every ms, so latency attacks you...Even at 64 bytes per millisecond, that should be 640Kbps throughput by my calcs; where are you getting only 64kbps?QuoteWhen data is transmitted between particular points on the bus, it is transmitted at a raw data rate of 12Mbps. That's a "hard" limit on maximum throughput. Then you have to take into account sharing the bus with other peripherals and/or endpoints, plus the overhead of the protocols needed to allow such sharing, plus error checking, plus whatever else they want/need to do.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 10, 2011, 10:32:48 am
content: Quotei said 64KBps, not 64Kbps. 64Bytes * 1000 parts of a second = 64KBps * 8b/B = 512Kbps. and thats the averaged when i probed the uart comm. the more precise figure is 2Mbps of 64Bytes transfer through uart, then a halt silence, then goes another packet after 1ms from "previous packet start point".Quoteyes agree i have to take this into consideration, thanks for reminding me. but during my testing, iirc there was no USB traffic going on, and the 64KBps is seems to be super stable, regardless of USB traffic, but i think i should do further detailed testing for this.

author: Bambur
author_rank: Regular Contributor
timestamp: November 10, 2011, 01:36:50 pm
content: Assuming that the FTDI chip you use supports the USB 2.0 full-speed signaling, the transactions for the port it is connected to, are scheduled for 1 ms time interval (USB FS frame). That's why you see one bulk transaction in 1 ms only. The ways to do more transactions are in my previous post, though I am not sure FTDI chip supports multiple endpoints.

author: JTR
author_rank: Regular Contributor
timestamp: November 11, 2011, 12:57:01 pm
content: Quote from: Mechatrommer on November 07, 2011, 11:24:25 pmI think you misunderstand the data. A bulk transfer once requested is started after the next start of frame (SOF). These happen at 1ms intervals. Therefore there could be a latency of 1ms for transfers to get underway. Once they are started multiple "transactions" can happen within each frame. For full speed USB up to 19 of these transactions max are possible. (In practice you don't get anything like this.) Each transaction has a max packet size of 64 bytes.If you are only requesting small amounts of data to be transferred via the FTDI API only that amount will happen per frame. To get higher bandwidth you need to request much larger chunks. The FTDI driver will split it up into multiple transfers and you may get 6-10 per frame. If you start requesting transfers of 1024-4096 bytes you should see your bandwidth jump to realistic full speed levels.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 11, 2011, 03:08:09 pm
content: Quote from: JTR on November 11, 2011, 12:57:01 pmi've requested (ie sent) 128 bytes in one API call, it got splitted into 2 perfectly packets (1ms interval), and i've requested 65bytes, i got 2, 1 packet 64bytes, 1 packet 1 byte, 1ms apart, sigh!maybe my next question is... has anyone successfully achieved higher data rate with FT232RL? if yes, can you share the schematic and d2xx driver setting? maybe i should try again later.

author: ToBeFrank
author_rank: Regular Contributor
timestamp: November 11, 2011, 04:50:29 pm
content: I have also used the FT232RL at higher bit rates. In my case I was doing 1.5Mbaud (1.2Mbits/s). Did you look athttp://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf? In particular section 6 FTDIPORT.INF Options.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 11, 2011, 07:06:12 pm
content: 2bfrank: i guess its under "6.2 Changing the Default USB Transfer Size"?. i have the doc but never take it seriously as i thought that only to change default behaviour of the device, which can be changed in software/API as well? am i wrong?

author: ToBeFrank
author_rank: Regular Contributor
timestamp: November 11, 2011, 07:20:58 pm
content: Quote from: Mechatrommer on November 11, 2011, 07:06:12 pmI think it can be set by software, but I can't remember. It's been a while since I worked with the ftdi chip. I didn't see them set in your text file you attached though. Unless the Arduino code included in there is supposed to be doing it. I don't know anything about Arduino.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 12, 2011, 12:27:13 am
content: its in the last line in ftdi.txt. it is called when opening the device is succesfull... (arduino is the variable of class type FTDI which encapsulate D2XX driver, ie its API calls)... and this code is from PC software side, not running from the arduino board. the variable name arduino is just to indicate the PC/ftdi chip is connected to arduino board...Code:#define BAUDRATE 2000000#define USB_PACKET 64if (arduino.Open(SERIAL_NUMBER) != FTDI_OK) return false;arduino.Latency = 10;arduino.PacketSize = USB_PACKET;arduino.BaudRate = BAUDRATE;and still, reading the AN_107 app note, the max packet size is 64bytes (the same with other doc i read b4). from arduino (the chip's uart) side, i'm not aware of any method to set the ft232 behaviour, arduino just send/receive the data at 2Mbps. i have to make the wait or "fancy synchronization" code due to this packeting/bottleneck behaviour, otherwise it will somehow, hanged. changing ft232 behaviour is i think only from PC side.for anyone with arduino mega board and Windows OS who want to try the working application you may download the hex/pc app/asm code fromhttp://www.soasystem.com/eng/amla. you may probe the uart line to see what i'm talking about. edit the asm code or PC app code if you can make it any better. (pls request the PC app code if interested, i've not included there since anybody can do their own flavoring in PC, ie using d2xx api), but really from arduino board side, it got nothing to do with ftdi behaviour/code. all the asm/hex code is doing is sending/receiving uart data. the other code, is just to wait/synchronize signal from PC before sending next data to avoid hanging (or lost data or buffer overrun?). PC->arduino comm protocol and sequence is described in the asm code.

author: ToBeFrank
author_rank: Regular Contributor
timestamp: November 12, 2011, 01:20:33 am
content: Quote from: Mechatrommer on November 12, 2011, 12:27:13 amNo. According to AN107, the max value that you can set in the driver is 0x3F (63), but that's not the transfer size in bytes. The actual transfer size in bytes is (driver_value + 1) * 0x40. For the max value of 0x3F, that's 4096 bytes. According to AN107, that's also the default. If you're setting your packet size to 64, you're limiting yourself to 64 byte packets.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 12, 2011, 01:44:51 am
content: o sorry. i just quick read it, my mistake. i'll check again later. thanks 2bfrank.edit: ok, i've got it. it was my mistake to limit myself to 64 bytes packet. now set to 4096 bytes and i'm running at average 195KBps or 1.56Mbps, very close to USB1.1 spec. thanks 2bfrank for pointing me to the right spot. it was unclear to me that the max packet size is 4096 bytes. FTDI is not bad after all! cheers!and no need to edit *.inf. its all can be set from API.