FT2232H bit banging and serial interface simultaneusly on 2 channels

[myle00]

Hi,

I have seen that people on this board have used the FT2232H before. This IC has two separate ports which you can bit bang or use a USB to serial converter. I'm wondering if it's possible to use the bit bang interface on one channel and the serial interface on the other at the same time? The spec sheet doesn't seem to say anything about it that I saw.

In addition, I only used the bit bang interface of the FT232. When used in synchronous bit bang mode I can read/write whole chunks of data (instead of byte by byte) which increases the throughput. I have never used the serial capabilities to interface it with, say with a AVR using SPI. The way I understand a serial device is that the OS must read each byte as it comes in and respond accordingly (i.e. if it's a start signal etc.). If that is the case then throughput must be very low and I wouldn't be able to use it to send large quantities of data (such as a 30kHz ADC data) like I do in bit bang mode? Is that true? What's the actual throughput (bit rate) of an FT232/FT2232 in whatever serial mode? Tomorrow I'll experiment to see what the max throughput of an FT232 is in bit bang using different transfer sizes.

Thanks in advance,
Matt

 

[bigdogguru]

I'll be interested in reviewing your results.

I've bit banged a FT232R in several modes, but have yet to experiment with a FT2232H.

Is this a breakout board, your own design or a serial to USB converter?

Good Luck

 

[FvM]

Configuring one channel for bit bang using ftd2xx driver and the other as virual com port is supported for FT2232 (I guess, it's the same for FTx232H). It has to be setup in the configuration EEPROM.

Achievable throughput in bit bang depends on how you manage to send off a number of actions as a block. If you're required to poll a device status, USB and OS induced delays will thwart it. In this case, you better put some local "intelligence" into a CPLD to manage the handshake.

Achievable COM port throughputs are well documented by FTDI, as far as I remember. Of course, they depend on the utilized OS interface. Using block read and write with a Windows OS easily achieves Mbaud speeds on a virtual com port.

 

[myle00]

@bigdogguru I have been using an FT232 for a while now on my own PCB board, it interfaces directly to an AVR micro (which interface to an ADC) as well as to a shift register controlling valves. Both I communicate with (simultaneously) using bit bang modes. I haven't used the FT2232H yet, but I'd probably make my own breakout board so I could connect my various other boards to it in a modular fashion.

@FvM I have never done serial communication so I wasn't exactly sure if/how I could do block read/writes for my purpose. Right now I have it set up in bit bang where the FT232 in a loop provides a clock output on one pin while reading input on 4 pins. When the AVR has data, it'll send it on the 4 pins, but if it sees that new data is ready at the ADC, it'll stop sending data momentarily and collect the ADC data and then start sending again. Using my own bit bang codes I can tell when that happened and when post processing each large block of data I extract only the valid data. Would a serial interface be suited for this kind of task, because it'd have to continue reading data while the AVR is collecting the ADC data and not responding to any control signals (which I assume is an issue), because if the driver were to return data every time the AVR stopped responding it'd seriously reduce performance. Would serial interface for this needlessly complicate things?

I'm happy with my bit banging and hopefully tomorrow I'll see my max throughput (for my computer) that way. However, I wanted to switch to serial mode because I figured it'd make programming more standard instead of my custom codes. I think you were referring to FTDI "AN232B-04 Data Throughput, Latency and Handshaking". From that it appears that in serial mode there are more ways to flush the input buffer (i.e. using control chars or modem line switching), which will reduce throughput so I wouldn't use it anyway. So I cannot really see, given the above situation that serial mode would improve my performance.

But I was still wondering if someone has actual data for an example computer sending the largest block of data in (any) serial mode to see what the throughput is (it'd be different/less than bit bang I assume because of the added control signals?).

Thanks,
Matt

 

[FvM]

For basic serial data transfer, no control signals are needed. The data flow is controlled by the USB protocol itself. That's basically the same when sending a sequence of bit banging commands without waiting for a response.

I didn't check yet, but I would expect that a sustained rate of 3 MBaud can be achieved.

 

[myle00]

So I tested the performance on two computers and following is the data.

In the zip file is the cpp file that ran the test, 2 txt log files for both computers and a excel file analyzing the data and graphing.

What I tested was as you increase the transfer size and you request reads/writes in units of this size, how does performance vary with size. You can see in the image attached that for the faster computer, with the largest transfer size (64BK) speed was 200KB/s.

Transfer size should be a multiple of 64 bytes. For each 64 bytes, 62 bytes is your data and two bytes is used by he driver. So at 1024*64 (64KB) you actually send 62*1024 (63488). Performance is maximized when you send data matching the transfer size.

If you look at my code you'd see three loops. The outer loop increases the transfer size from 1*64 bytes to 1024*64 (64KB). The inner loop replicates each sample 20 times to get a more accurate measure. With the middle loop I meant to test what happens if for a given transfer size (i.e. 640 bytes and 620 bytes of data) I make I read request in multiples of that (i.e. 5*620, 3100). I ended up not doing that and instead only sending the exact multiple of the transfer size because it was incredibly slow. That actually puzzles me because in the data sheets they say that performance is increased if you send in multiples of the transfer size. Maybe they only meant an exact multiple?

Note, I increased the USB timeout to 250ms so that any delays would be obvious. Also, I ran it at 62500 Baud so to get 16*62500 (1M) because that's what I need for my hardware connected to the FT232. Although I've read that the clock on the FT232 is not accurate.

Here are the relevant FTDI docs: https://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf, https://www.ftdichip.com/Support/Documents/AppNotes/AN232B-03_D2XXDataThroughput.pdf

Also note that the rates is bytes rates because the data gets output to 8 pins simultaneously.

Let me know if I could have made the code better. Here's the computer specs

---

Code C++ - [expand]
1
2
3
4
Windows 7 32bit. 2GB RAM - Intel® Core™2 CPU  6400 @ 2.13GHz   2.13 GHz
Windows 7 64bit. 8GB RAM - Intel® Core™ i7 CPU 860 @ 2.8 GHz     2GHz
ftd2xx.dll - 32bit (for both) 2.08.14
Compiled with VC++ 2010, release version

---

Here's the short version of the code

---

Code C++ - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
for (int tr= 1;tr<=MAX_PACKETS;++tr)    // For each transfer size from 1*64 to MAX_PACKETS*64 (64Kb)
{
    FT_SetUSBParameters(ftHandle, tr*PACKET_SIZE, 0); 
    Sleep(50);
    // Write in multiples of the transfer size, max 50 multiples or 3 multiples for trasnfer size of MAX_PACKETS*64
    int mult= 1;
    for (;mult<2 && mult*tr<=3*MAX_PACKETS;++mult)
    {
        dStart= cTimer.Seconds();
        // Replicate 50 times
        
        for (int i= 0;i<25;++i)
        {
            dStart= cTimer.Seconds();
            FT_Write(ftHandle, tx, mult*tr*DATA_PER_PACKET, &BytesWritten);
            dMid= cTimer.Seconds();
            FT_Read(ftHandle,rx,mult*tr*DATA_PER_PACKET,&RxBytes);
            dEnd= cTimer.Seconds();
            dWrite[i]= dMid-dStart;
            dRead[i]= dEnd-dMid;
            dTotal[i]= dEnd-dStart;
            
        }
    }
    Sleep(50);
}

---

Do you think that serial mode can top this?

Matt

 

[FvM]

Do you think that serial mode can top this?

I assume yes, but I don't have comparative tests. I don't have present projects relying on FTDI throughput. One question is, if the D2XX driver (FT_xx functions) is adding procession time to the native Windows interface.

The x232H devices are offering an increased baud rate of 12 Mbaud and also promising lower turn-around delay in USB high speed mode, that's not restricted by the 1 ms tick of standard USB.