Max transfer speed over FTDI

Created Sat, 07 Jan 2012 18:02:50 +0000 by EmbeddedMan

EmbeddedMan

Sat, 07 Jan 2012 18:02:50 +0000

A friend recently needed the maximum possible transfer speed between the PC and a MAX32 over the built in FTDI USB port.

I had no problem using 921600 as the baud rate (the highest that the FTDI chip supports) if you make the following changes:

In p32_defs.h, add the following line:

#define _UARTMODE_BRGH  3

and in HardwareSerial.cpp, in the function HardwareSerial::begin() replace

uart->uxBrg.reg	 = ((__PIC32_pbClk / 16 / baudRate) - 1);	// calculate actual BAUD generate value.
	uart->uxSta.reg = 0;
	uart->uxMode.reg = (1 << _UARTMODE_ON);			//enable UART module
	uart->uxSta.reg  = (1 << _UARTSTA_UTXEN) + (1 << _UARTSTA_URXEN);	//enable transmitter and receiver

with

uart->uxSta.reg = 0;
	if (baudRate < 200000)
    {
        uart->uxBrg.reg	 = ((__PIC32_pbClk / 16 / baudRate) - 1);	// calculate actual BAUD generate value.
        uart->uxMode.reg = (1 << _UARTMODE_ON);			//enable UART module
	}
    else
    {
        uart->uxBrg.reg	 = ((__PIC32_pbClk / 4 / baudRate) - 1);	// calculate actual BAUD generate value.
        uart->uxMode.reg = (1 << _UARTMODE_ON) | (1 << _UARTMODE_BRGH);			//enable UART module
    }
    uart->uxSta.reg  = (1 << _UARTSTA_UTXEN) + (1 << _UARTSTA_URXEN);	//enable transmitter and receiver

Then you can use all FTDI supported baud rates up to 921600.

I'll submit this for the next release as well.

*Brian

FMMT666

Sun, 08 Jan 2012 00:26:47 +0000

I had no problem using 921600 as the baud rate (the highest that the FTDI chip supports) if you make the following changes:

Nice upgrade, but actually the chip supports up to 3Mbit/s. 2MBit/s are a common, practical limit as the bit error rate rises above that value and other strange things might happen...

EmbeddedMan

Sun, 08 Jan 2012 17:37:22 +0000

Correct - have you tested that speed on the Uno or Max boards?

I have not been able to because I don't have a program on the PC side (yet) that can open the FTDI port using a non-standard baud rate.

In, fact, FTDI actually has USB->Serial chips that go up to 12Mbps. !!

*Brian

FMMT666

Wed, 11 Jan 2012 00:52:50 +0000

Correct - have you tested that speed on the Uno or Max boards?

No, not on these, but a lot of other boards. Do you ask because of the 1k resistors in the TX/RX line (Max32)? If they really cause problems, lower them, but this should not be necessary. Even with 50pF input capacitance, we're at 1/10 of the bit rate. That should work...

In, fact, FTDI actually has USB->Serial chips that go up to 12Mbps. !!

Oh yes, I know (although I use them in bulk transfer mode at much higher bandwidth). Drawback: They require an external crystal, an additional waste of board space...

And regarding the price, at least for "low transfer rates", a Microchip MCP2220 could be a better choice (except for its missing DTR pin, which is used for reset...)

EmbeddedMan

Tue, 17 Jan 2012 05:44:27 +0000

And, if you want to transfer up to 2Mbps over the FTDI connection on a chipKIT, here's how. (2Mbps is the fastest that we can go, because the only faster speed is 3Mbps and the PIC32 can't do 3Mbps on its UART).

1. Download the latest FTDI drivers from h[url]ttp://www.ftdichip.com/Drivers/VCP.htm[/url]

2. Unzip them, and open up the ftdiport.inf file.

3. Find line 132, which starts HKR,,"ConfigureData" . . . and find the text "10,27" which is about 33 characters in. Replace the "10,27" with "01,00", so that the beginning of that line now looks like this:

HKR,,"ConfigData",1,11,00,3F,3F,01,00,00,00,88, . . .

Then save the file.

4. Plug in your chipKIT board.

(The rest is assuming Windows 7/Vista - I'm sure the same basic idea will work fo Windows XP, but I'm not sure about Mac/Linux)

5. Go to Start->Devices and Printers

6. Right click on the FT232R USB UART device in the Unspecified section. Select "Properties".

7. Then click on the hardware tab. Then click on the USB Serial Converter under "Device Functions:".

8. Then click on Properties, then click on Change Settings. Then click on the Driver tab. Then click on Update Driver.

9. Then click on Browse my computer for driver software.

10. Then click on Let me pick from a list of device drivers on my computer.

11. Then click on Have Disk.

12. Then click on Browse, and surf over to where you unziped the new FTDI driver.

13. Click on the ftdiport.inf file, then click open. Then click OK. Then click Next.

14. Windows may complain that it is unsigned, tell it to go ahead and install anyway.

15. Click Close. Then click Close again.

16. Now click on USB Serial Port (COMxx) (in the FT232R USB UART Properties window, which you should be back to), and then repeat steps 8 through 15.

Now, you should be able to do a

Serial.begin(2000000);

In your setup() function in your sketch, and then start TeraTerm up, open the serial port that your chipKIT is on, and select 300 baud. And you should be able to get your data out of the chipKIT at about 200KB/s. I've aliased 300 baud with 2Mbps in the driver, so that whenever you select 300, it actually uses 2Mbps. That's what the changed line in the inf file does.

*Brian

peplin

Tue, 20 Nov 2012 22:05:21 +0000

Sorry to resurrect this thread, but I just made the patch in the latest version of MPIDE (mpide-0023-linux-20120903.tgz) and it's still required to get faster than 115200 baud rates over HardwareSerial. Is there any particular reason why the changes isn't made upstream?

EmbeddedMan

Wed, 21 Nov 2012 04:53:42 +0000

The reason is because this creates a non-standard FTDI driver install. I did not assume that we wanted to create such a thing as part of the standard MPIDE distribution.

However, it may be a good idea to make this change to MPIDE permanent.

Anybody have any good reasons why not?

*Brian

peplin

Wed, 21 Nov 2012 05:07:07 +0000

Yeah, to be clear I'm not talking about the changes to the FTDI driver - I'm doing this from Linux anyway.

EmbeddedMan

Fri, 23 Nov 2012 04:25:37 +0000

Ahh, OK, You're just referring to the changes in the MPIDE code. I completely forgot to pull those in. I'll work on that now.

*Brian