FTDI 2232H USB to I2C

some video shots

2009-11-01T17:44:00.008+01:00

The FTDI driver board connected to my 2 dimmer boards by I2C. Running a test asking 4 status requests and 4 update requests with 100ms delay between them. Average of 55ms for 4 commands running on the test on the same PC as the driver. Which would be around 1 second if you use the FTDI with bit bang mode.

The actual board based on the high speed FTDI 2232H chip running the same test.

The output of the driver program written in C. This program handles the real RS232 FTDI reads and writes. It's also programmed to be extremely portable. It's tested on windows as well as linux. I used a socket approach to send and receive commands because this is the most portable way. So a host program is able to connect ,request and update by using the dedicated socket port.

This video shows the output of the java based host program. It's actually running on a linux system to prove the great amount on portability. It's easy to take whatever system you like to interface the FTDI board. You also can for instance take a web based design and communicate internally by using regular sockets. The average here was just a bit higher 65ms due to the overhead on wireless network.

I think finally my system is a great success. It's very fast , I2C commands are extendable ,low cost and has an extreme high rate on portability.

errata on timings

2009-10-23T21:48:00.006+02:00

After I did the timings I did some thinking ... And yes I forgot to include the RS232 control bits in my calculation. So in fact when having 1 start bit , 8 data bits , 1 stop bit and no parity there are 10 bits to transfer per byte. So indeed don't forget you have 25% overhead on control bits.

serial bit speed 4 500 000 bits/s
serial byte+control speed 450 000 bytes /s
4096 bytes transfer in 9,1ms

So the above calculation for the speed is the right one. I measured around 9ms with my scoop so this confirmed the latter. Also the fact I mentioned on the usb latency when only receiving is not correct. I can only measure the real serial speed when hooking in with scoop. Only when testing Rx-Tx complete chain I can deduce the latency. So I must get 18.2 ms to Rx-Tx the 8k ideally.

on windows 19.8ms -> 1.6 ms latency
on linux 18.8 ms -> 0.6 ms latency

Still some nice results I must say. Far better than using the FTDI in bit bang modes. As I wrote before these modes are far from efficient as they had to transfer byte after byte over the USB.

bit bang Tx 84 bytes 200ms
bit bang Rx 84 bytes 250ms

Meanwhile I wrote some middle ware software to test the all chain. I can send 16 messages of 256 bytes in one chunk now. Timings are wonderful ! Only 140ms to Tx - I2C -Rx them all. If I compare that with the bit bang mode:

Tx 200 ms * 16 = 3.2 seconds

With my system only 140ms which is a factor 23 faster !

Next blog I will show a small video about my test setup so stay tuned for more on this great interface.

some more timings

2009-10-18T15:25:00.007+02:00

Here are some results with maximum speed (maximum cortex USART1 speed):

Test setup:

serial speed 4.5 MB/s -> ca 549 kb/s
tx/rx buffers taken 4k bytes
cortex DMA transfer used on both rx/tx
host PC1 with window 7 RC drivers 2.04.16
host PC2 with linux ubuntu 9.04 2xx so 0.4.16
FTDI latency on 1ms

So tx/rx theoretical time should be 7.28 ms / 4k.

Win7 Project written in C with VC 2008 using the 2xx FTDI DLL:

PC tx - Cortex rx time 8.9 ms / 4k
PC tx - Cortex rx- Cortex tx - PC rx time 19.8ms / 8k

Linux Project written in gnu C (gcc) using 2xx shared 2xx lib:

PC tx - Cortex rx time 8.9 ms / 4k

PC tx - Cortex rx- Cortex tx - PC rx time 18.8 ms / 8k

Linux Project written in java NB with RXTX:
Test succeeded only with baud rate at 9600 !!!
Bad results not comparable
Conclusion:

USB latency is now dropped to

--> 1,5 ms / 4K

--> 3 ms / 8K

Which can be seen as the normal due to the minimum USB latency timeout of 1ms.

You notice that Linux can perform 1ms better with 8k than win 7 ! Again a proof that for some processing Linux performs much faster than windows. The java test on linux was very bad. As soon speeds were higher than 9600 the receiver could not follow at all and stayed suspended on the read function. I don't know the reason for this but probably a mix of causes ( jre , rxtx lib and driver )

Any way I know for now that I can proceed using the 2xx DLL which performs very good and offers a nice portability between windows and Linux. You can simply take your code from one project to the other. However on linux you have to make sure that ftdi_sio and usbserial are unloaded with rmmod. Your user program will only run with sudo as root. I must investigate that further but is less important.

I continue in making the message layout buffers and programming the cortex to understand the commands. As soon I have some overall results I will write one last topic here.

Some timings

2009-10-17T21:54:00.004+02:00

Here are some results of the first tests I did:

Test setup:

serial speed 2.25 MB/s -> ca 275 kb/s
tx/rx buffers taken 4k bytes
cortex DMA transfer used on both rx/tx
host PC with window 7 RC
FTDI latency on 2ms

So tx/rx theoretical time should be 14,56 ms.

Project written in C with VC 2008 using the 2xx FTDI DLL:

PC tx - Cortex rx time 18 ms / 4k
PC tx - Cortex rx- Cortex tx - PC rx time 40 ms / 8k

Project written in java with NB using RXTX DLL:

PC tx - Cortex rx time 18 ms / 4k

PC tx - Cortex rx- Cortex tx - PC rx time 54 ms / 8k

First conclusion:

Still some USB overhead but far less than the bit bang modes:

-> serial mode 3ms / 4K

-> bit bang 2ms / 2-64 bytes

Also the java is slower than the C approach. But this is nothing new as the java program must cross a few more layers than the C one ;-) To give you an idea I had to loop around to read all the bytes in java. Sometimes even 3 times to have the 4k fully read:

while ( temp != 4096 ){

readin = inputStream.read( rbuf , temp ,rbuf.length - temp);

temp += readin;

}

Therefore time increases due to the overhead on executing java code on the PC (40 -> 54 ms )

While using the 2xx DLL in C this was not needed and I could limit to one read as this was always the full 4k. Also the fact that is function is blocking while the java streams don't:

stat = FT_Read ( hSer1 , ReadBuffer, 4096 ,&read);

I will do some more tests on my linux machine with the java approach and gnu C. But the big advantage is that we can make the I2C message and put them into the 4K buffer. Once transfered they will be treated in a batch one after the other using dedicated I2C hardware on the cortex instead of making it by the FTDI. I did some tests transferring 84 bytes using the I2C FTDI DLL with bit bang mode ( with the previous design ) and the timings were between 200 - 300 ms ! I can assure you already that we are gone do much better than that. Let say we will try to reach a factor 5 faster. Stay tuned to follow the results....

new schematics

2009-10-17T20:54:00.007+02:00

Left the PCB layout

Features:

- 2 x I2C ( 400k )

- Serial speed 4M

- USB bus powered

- STM32F103RET

- JTAG + reset

Schematics:

Hardware by:

manes6969 at

telenet dot

brand new approach

2009-10-17T19:52:00.004+02:00

As you could read in my previous stories there were a few issues using the FTDI in bit bang mode. The most important one was the minimum latency of 2ms to send a few bytes and converting them to I2C protocol. Now I took a totally different approach in using the FTDI chip as a usual USB to RS232 converter. I used the latest FTDI chip series FT2232H as I had the opportunity with this huge change. This chip has 4096 byte buffers on board and can have speeds of more than 4M bit a second. Because I use the chip pure as RS232 device I had to make the I2C with something else of course. And guess what , I took the STM32 to do this job. I have quit some experience now with this MCU that I challenged myself to interface it with the FTDI chip. So the USB2I2C bridge came finally to an end. I will use it as a gateway in my dimmer project ( see my other blogs ) On the picture you can see the final result. I will post the schematics later on and will tell a bit on speeds too.

multithreaded approach

2008-10-09T19:06:00.002+02:00

I rewrote the first test program with a multithreaded approach. Basically there are three thread involved:

PollThread
LogicThread
MainThread

The Pollthread serve to check the FTDI ADBUS line connected to the interrupt. Whenever an interrupt arrives an Event is set to signal the MainThread that work has to be done. The access to the FDTI is guarded by a mutex. Let me show you the code:

DWORD WINAPI PollThread ( LPVOID lp )

{

UCHAR ad [1];

UCHAR in [5];

UCHAR out [5];

status = FTDI_I2C_STARTUP( _400KHZ );

status = FTDI_I2C_PCA_READN_ALL( PCA9698_INPUT_READ , in );

RefSet.FromByteBuf(in);

RefSet.flip();

RefOut.ToByteBuf(CmdOut);

status = FTDI_I2C_PCA_WRITE_ALL( PCA9698_OUTPUT_WRITE , CmdOut );

while (1)

{

WaitForSingleObject(InterruptAckEvent,INFINITE);

WaitForSingleObject(FtdiMutex,INFINITE);

status = FTDI_2XX_READN_ADBUS(ad);

ReleaseMutex(FtdiMutex);

while ( (ad[0] & INT_MASK_FLAG) != 0 )

{

WaitForSingleObject(FtdiMutex,INFINITE);

status = FTDI_2XX_READN_ADBUS(ad);

ReleaseMutex(FtdiMutex);

}

SetEvent(InterruptEvent);

}

return 0;

}

The second thread is the LogicThread that will be created by the MainThread on event basis. This thread reads the inputs resets the interrupt and sends an acknowledge to the the PollThread. This is needed because otherwise the interrupt event will be send more than ones if it is not reset. The read and writes will be guarded by the same mutex as the PollThread. Here is the code:

DWORD WINAPI LogicThread ( LPVOID lp )

{

UCHAR in [5];

UCHAR out [5];

WaitForSingleObject(FtdiMutex,INFINITE);

status = FTDI_I2C_PCA_READN_ALL( PCA9698_INPUT_READ , in );

ReleaseMutex(FtdiMutex);

SetEvent(InterruptAckEvent);

BitSetExtended<40> InNew(in);

InNew.flip();

for ( int input = 0 ; input <>

{

if ( (RefSet[input] != InNew[input]) && (InNew.test(input)) )

{

RefOut.flip(input);

}

RefSet = InNew;

RefOut.ToByteBuf(CmdOut);

WaitForSingleObject(FtdiMutex,INFINITE);

status = FTDI_I2C_PCA_WRITE_ALL( PCA9698_OUTPUT_WRITE , CmdOut );

status = FTDI_I2C_DAC_SET(0,0);

ReleaseMutex(FtdiMutex);

return 0;

}

The last thread is the main and is very small. Basically this thread waits until the interrupt event is set and creates the LogicThread with a priority just a bit higher to force the context switch immediately:

InterruptEvent = CreateEvent(NULL,false,false,L"Local\\INT");

InterruptAckEvent = CreateEvent(NULL,false,true,L"Local\\INTACK");

FtdiMutex = CreateMutex(NULL,false,L"Local\\FTDI");

// start to poll

CreateThread(NULL,0,PollThread,NULL,0,&PollThreadId);

while (1)

{

WaitForSingleObject(InterruptEvent,INFINITE);

hThreadLogic = CreateThread(NULL,0,LogicThread,NULL,CREATE_SUSPENDED,&LogicThreadId);

SetThreadPriority(hThreadLogic,THREAD_PRIORITY_ABOVE_NORMAL);

ResumeThread(hThreadLogic);

CloseHandle(hThreadLogic);

}

The program works very stable. The only thing I noticed was that the process better runs with ABOVE_NORMAL priority as normal on the eee Asus PC. This is due to having only a single core and running quit small with 1GHz. The only improvement I can add is a mutex object on the input BitSet to exclude all possible race conditions possible. But it's only a test of course.

final results

2008-09-26T10:01:00.010+02:00

On the picture you can see my test equipment for the FTDI. Three parts are involved:

1. Asus EEE PC as platform
2. FTDI interface board ( small one)
3. I2C I/O board ( big one )

The final test I did was based on the fact that I simulated the real domotic logic as close as possible to the final program logical blocks. I also included the fact of worse case timings. The best way to explain this is by showing you the piece of test code I wrote:

void TestWorstCaseTiming(void)

{
UCHAR in [5]; //I2C InBuf
UCHAR out [5]; //I2C OutBuf
UCHAR ad [1]; //Int

//*********INIT BLOCK
status = FTDI_I2C_STARTUP( _400KHZ );
//*********PREPARE IN AND INVERT
status = FTDI_I2C_PCA_READN_ALL( PCA9698_INPUT_READ , in );
BitSetExtended<40> InSet(in);// start with real values
InSet.flip();// invert push = 1
//*********PREPARE OUT ALL TO ZERO
BitSetExtended<40> OutSet(CmdOut);
//OutSet.none();
OutSet.ToByteBuf(CmdOut);
status = FTDI_I2C_PCA_WRITE_ALL( PCA9698_OUTPUT_WRITE , CmdOut );//16ms
//*********MAIN LOOP
while (1)
{
//*********POLL LOOP
status = FTDI_2XX_READN_ADBUS(ad);
while ( (ad[0] & INT_MASK_FLAG) != 0 )
{
//overwrite time to have total chain time at the end
GetSystemTime(&begin);
status = FTDI_2XX_READN_ADBUS(ad);//2ms
}
//*********DOMOTICS LOGIC READ
status = FTDI_I2C_PCA_READN_ALL( PCA9698_INPUT_READ , in );//22ms
//*********DOMOTICS LOGIC COMPARE AND MODIFY
BitSetExtended<40> InNew(in);
InNew.flip();
for ( int input = 0 ; input <>
{
if ( (InSet[input] != InNew[input]) && (InNew.test(input)) )
{
OutSet.flip(input);
}
}
//*********DOMOTICS LOGIC UPDATE LAST IN
InSet = InNew;
//*********DOMOTICS LOGIC PREPARE AND OUT
OutSet.ToByteBuf(CmdOut);
status = FTDI_I2C_PCA_WRITE_ALL( PCA9698_OUTPUT_WRITE , CmdOut );//16ms
status = FTDI_I2C_DAC_SET(0,0);//10ms
//*********CHECK TIME
//Sleep(30); simulate cpu charge
GetSystemTime(&end);
printf ("cpu time : %d ms\n",end.wMilliseconds-begin.wMilliseconds);
// should be ca 50ms + Xms logic
}
}

The program flow is very simple. I poll on interrupt flag change in the inner while loop. As soon this becomes signals I leave the loop to read in the values of the PCA-IN. I check upon which bits are changed and also if this bit equal to 1. Due to the fact I use the inputs as button device I'm not interested if this bit is zero because this indicates the released state. I'm only act upon state pushed here. I invert the PCA-OUT accordingly to have a toggle behaviour on the leds. I didn't use a complex mapping for the in and out simply in-bit[0] relates to out-bit[0] etc for all 40 of them. Finally I write the new output state to the I/O board. I also added the DAC write just for timing simulating purposes but has no further meaning in this test. As you can see in the code I use the BitSetExtended<40> InNew(in) class. This one I wrote to ease the work with atomic bits. It's an extended (derived) STD class of BitSet:

template class BitSetExtended : public bitset<_n>
{
typedef __int64 _Ty;
public:
BitSetExtended ( );
BitSetExtended ( __int64 ll );
BitSetExtended ( PUCHAR pC );
void ToByteBuf ( PUCHAR pC);
private:
enum { _Nb = CHAR_BIT * sizeof (_Ty),_Nw = _N == 0 ? 0 : (_N - 1) / _Nb };
void _Treat64( __int64 _X);
void _Tidy(_Ty _X = 0);
void _Trim( void );
_Ty _A[_Nw + 1];

};

My estimated 50ms total time was quite correctly. I tried pretty much with a real button switch connected on several inputs to check if the program was fast enough to trigger all interrupt coming from the PCA-IN. And it worked very well I must say ! I can in some unreal conditions trigger an error but this really testing as a fool and can not be compared to the usual real life application. I inserted a sleep line in the code to simulate higher domotic logic execution time. I went even to 30ms and my system continued working stable. I need this test to be sure that with the final code ,which will be much more than what I have now, the program will not suffer any timing site effects.

Conclusion:

I find this a very good result even with quit slow communication of the FTDI USB device. In this test I wrote the code chained one block after the other. I didn't use any optimizations on the code flow and avoided working with multiple threads. I can think of a couple changes in terms of logic and threading which can optimize the program a little bit eg seperate the poll code into one thread using events and syncronizations on the FTDI object. Perhaps writing the read-in bits to a queue system and trait the changes in an other thread. I will look into this possibilties soon and report in my blog as usually do. But I must say I'm one step closer to my decision for taking this approach as my future domotic server.

timings

2008-09-21T20:21:00.006+02:00

What are the results using the FDTI chip as a I2C peripheral ? The same as you pehaps I was very curious about the performance using it from the USB driver and DLL. To get a good idea I wrote some higher level functions that use the API the make things easier accessing the PCA device. i divided it into:

- Init
- Read ADBUS interrupt line
- Read byte(s) from PCA
- Write bytes(s) to PCA

Basically the init function put the PCA in the correct mode and initialize the FTDI chip properly regarding the speed. I used 1Mhz speed as the PCA can handle this fast I2C speed but this will not be a bottleneck as we'll see. To initialize it took 350ms. This sounds big and actually it's but this is only done ones at the start of the program and is not that important.

Than I started to poll on the INT line :

read int time : 1 ms
status : ef
read int time : 3 ms
status : ef
read int time : 1 ms
status : ef
read int time : 3 ms
status : ef

As you can see an average of 2ms. This was after I changed the LatencyTime parameter of the FTDI from 16ms to 2ms which is the minimum. If you don't do that the fastest result you get is 16ms ! I continued with the read of 5 consequent bytes from the PCA and I got ca 22ms. This is a bit disappointed. I did the same writing 5 bytes and this was a bit better ca 16ms. To deduce the overhead per byte I wrote a command to read/write just one byte:

read pca time : 9 ms
status : ff
read pca time : 9 ms
status : ff
write pca time : 8 ms
write pca time : 8 ms

So the fasted time in read or write to an external I2C device using the USB FTDI chip is ca 10ms. So this had a 2ms overhead for any extra byte to read or send. I see a few reasons for these poor performance results:

1. The USB overhead for small data packets
2. Minimum FTDI latency is 2ms
3. High level MPSSE command structure (atomic)

I checked the DLL code and most of the functions were well written and can not be optimized. However in the read cycle this can be optimized a little bit but not worth to try and see much differences I think.

Although the performance is not that fantastic, this design let you interface a PC platform (linux,windows,CE,mac) with any customized external board that uses a I2C bus as communication. And it's a very cheap and powerful solution. You can make your programs on your favourite platform without using embedded micro controllers. Use the power of that platform to interact with other high level software components without having the limitations of embedded boards. So anyone that have to work with some extended I2C based device can make use of this chip. Be ware this only counts for the latest series of FTDI eg 2232C or D. One of the drawbacks I see is that to serve systems running 24/7 using this solution, you have to let a PC running too and that's may be a kind of overkill. In that case it's better to have a small embedded system with very low power consumption or at least a PC platform without sensitive mechanical parts like fans or hard drives.

So the question still remains for me if I'm going to use this as my domotic server system or not. I keep you posted on in this blog. In my next I'll present the overall setup with a nice picture of the components I used.

FTCI2C DLL functionalities

2008-09-19T12:42:00.002+02:00

Nothing received on my last mail. So the FDTI support is not that friendly if you ask me. Nevertheless I modified the DLL code so I now have access to the ADBUS and ACBUS bus GPIO. Although the ADBUS access is limited. But as I promised, this post will be dedicated to the API calls you can use when the FT2232 device is in MPSSE mode. The next post I will show some results on timings from several tests I did to get a better idea on the capabilities of this chip using it for other purposes than usb to serial conversions.

Mainly two possible ways to work with this device. You can pick the VCP (virtual com port) or the D2XX (low level design and special modes). In my case I downloaded the D2XX package. I took the windows based package but also linux , windows CE and even MAC are possible. Resources are available on the following site:

http://www.ftdichip.com/Drivers/D2XX.htm

The FTDI software comes with a zip file archive with following components:

- ftdi driver
- ftd2xx.dll
- ftd2xx.lib
- ftd2xx.h

These are the minimum components you need to start making your programs using visual studio. If you choise to interface an I2C bus peripheral than you must download an ectra development package to be able to work easier with the internal command structure of the FT2232. This can be found :

http://www.ftdichip.com/Projects/MPSSE/FTCI2C.htm

Components included are :

- ftci2c.h
- ftci2c.dll
- ftci2c.lib

Basically you can do pretty much with the default API functions the DLL exports and are quit simple to use. Here is the list of APIs:

FTCI2C_API
FTC_STATUS WINAPI I2C_GetNumDevices(LPDWORD lpdwNumDevices);

FTCI2C_API
FTC_STATUS WINAPI I2C_GetDeviceNameLocID(DWORD dwDeviceNameIndex, LPSTR lpDeviceNameBuffer, DWORD dwBufferSize, LPDWORD lpdwLocationID);

FTCI2C_API
FTC_STATUS WINAPI I2C_OpenEx(LPSTR lpDeviceName, DWORD dwLocationID, FTC_HANDLE *pftHandle);

FTCI2C_API
FTC_STATUS WINAPI I2C_Open(FTC_HANDLE *pftHandle);

FTCI2C_API
FTC_STATUS WINAPI I2C_Close(FTC_HANDLE ftHandle);

FTCI2C_API
FTC_STATUS WINAPI I2C_InitDevice(FTC_HANDLE ftHandle, DWORD dwClockDivisor);

FTCI2C_API
FTC_STATUS WINAPI I2C_GetClock(DWORD dwClockDivisor, LPDWORD lpdwClockFrequencyHz);

FTCI2C_API
FTC_STATUS WINAPI I2C_SetClock(FTC_HANDLE ftHandle, DWORD dwClockDivisor, LPDWORD lpdwClockFrequencyHz);

FTCI2C_API
FTC_STATUS WINAPI I2C_SetLoopback(FTC_HANDLE ftHandle, BOOL bLoopbackState);

FTCI2C_API
FTC_STATUS WINAPI I2C_SetMode(FTC_HANDLE ftHandle, DWORD dwCommsMode);

FTCI2C_API
FTC_STATUS WINAPI I2C_Write(FTC_HANDLE ftHandle, PWriteControlByteBuffer pWriteControlBuffer,
DWORD dwNumControlBytesToWrite, BOOL bControlAcknowledge, DWORD dwControlAckTimeoutmSecs,
BOOL bStopCondition, DWORD dwDataWriteTypes, PWriteDataByteBuffer pWriteDataBuffer, DWORD NumDataBytesToWrite,
BOOL bDataAcknowledge, DWORD dwDataAckTimeoutmSecs, PFTC_PAGE_WRITE_DATA pPageWriteData);

FTCI2C_API
FTC_STATUS WINAPI I2C_Read(FTC_HANDLE ftHandle, PWriteControlByteBuffer pWriteControlBuffer,
DWORD dwNumControlBytesToWrite, BOOL bControlAcknowledge, DWORD dwControlAckTimeoutmSecs,
DWORD dwDataReadTypes, PReadDataByteBuffer pReadDataBuffer, DWORD dwNumDataBytesToRead);

FTCI2C_API
FTC_STATUS WINAPI I2C_GetDllVersion(LPSTR lpDllVersionBuffer, DWORD dwBufferSize);

FTCI2C_API
FTC_STATUS WINAPI I2C_GetErrorCodeString(LPSTR lpLanguage, FTC_STATUS StatusCode,
LPSTR lpErrorMessageBuffer, DWORD dwBufferSize);

As you can see quit a complete list of functions that you can call almost directly. The principe is based on dividing the i2c commands into a ControlBuffer and a DataBuffer. This is done to simplify the internal calls to the FTDI2232 command set available. Here is an example out of my library I write to prepare a command for the PCA device:

FTDI_API FTC_STATUS FTDI_I2C_PCA_WRITE_ALL ( UCHAR adr , PCHAR buf )
{
FTC_STATUS stat;

PageWriteData.dwNumBytesPerPage = PCA9698_MAX_DATA;
PageWriteData.dwNumPages = PCA9698_MAX_PAGE;

WriteControlBuffer[0] = adr;
WriteControlBuffer[1] = PCA9698_WRITE_ALL;

memcpy ( WriteDataBuffer , buf , PCA9698_MAX_DATA );

stat = I2C_Write( hI2C,
&WriteControlBuffer,
PCA9698_CONTROL_BYTES,
FTDI_WANT_ACK,
FTDI_TIME_OUT,
FTDI_WANT_ACK,
PAGE_WRITE_TYPE,
&WriteDataBuffer,
PCA9698_MAX_DATA,
FTDI_WANT_ACK,
FTDI_TIME_OUT,
&PageWriteData
);I2C_RETURN_ERROR;

I2C_RETURN_SUCCES;
}

So in fact you can organize your calls in seperate functions library for readability or you can of course also call it directly within your main logic. Due to the fact I modified the FTDI DLL code I better add my functions directly in the code of the DLL. This has an extra advantage in using only one single device handle. If you need the GPIO calls together with I2C you need to call functions out of the basic ftd2xx.dll and you need to open up an other handle. This means that if you work like that you simply can't let open two handles in your program. I show you the lines that I changed to be able to access the ACBUS:

In function FT2232cMpsseI2c::InitDataInOutClockFrequency I commented out these lines:

// outputs on GPIO21-24
// FTC_AddByteToOutputBuffer(SET_HIGH_BYTE_DATA_BITS_CMD, false);
// FTC_AddByteToOutputBuffer('\x0F', false);
// FTC_AddByteToOutputBuffer('\x0F', false);

If you don't do that every time the device gets initialized the ACBUS is set to output and the 4 lines become high. Another thing I did was changing the WriteProtectEnable flag. This flag is related to pin 4 of the ADBUS and not documented in the specifications. It's not quit clear to me why they use it but I guess to make the internal command calls save for multihreading.

In function FT2232cMpsseI2c::ReadDataFromExternalDevice I modified the flag to false :

Status = WriteAddressExternalDevice(ftHandle, (*pWriteControlBuffer)[0], ControlAckType, dwControlAckTimeoutmSecs, false);

I needed to that because my PCA OE was connected to pin 4. After these changes the OE was working properly and the ACBUS was available for input as well as for output whitout any changes when calling the InitDevice function.

I went not into great details regarding the code and of course I assume that you know how to build a DLL and use third party DLLs from within visual studio. The purpose of this post is just showing you the fact that FDTI device can be put into other modes than the widly used VCP mode. Next I will tell you bit more on the results of my tests. For the ones interested in reading some hardware specifications

http://www.ftdichip.com/Documents/DataSheets.htm

I can't attach the DLL source code here in this google blog which is a pitty but if you're interested just give me a reaction on this post.

pcb ready

2008-09-13T11:51:00.002+02:00

As you can see on the left this is the final design. It's a try out to investigate the possibilities of the FTDI 2232D chip. The objective was using the FTDI provided DLLs and interface my IO board via I2C.

The first tests were perfect ! The chip in MPSSE mode let you communicate via I2C just by calling a few DLL API calls. But soon I noticed that this mode had some drawbacks. In de specifications of the chip nothing is telling you that if you use the MPSSE mode the gpios of the ADBUS and ACBUS are not available ! As my OE and INT of the IO board were connected using these gpio pins, the design became useless. Of course I tried to write to FTDI support but they are not that fast in response. Here are some FTDI answers:

- Is the use of ADBUS4-7 totally free as GPIO when using the DLL FTCI2C with the FTDI 2232D device ?

Ans: Unfortunately when you set the mode for MPSSE those GPIO are not available.

- In case of no please write some additional design remarks in dedicated specifications to avoid confusion and bad design.

Ans: We will elaborate this point in our future updates.

- In case of yes is it also free to use ACBUS as gpio together with I2C DLL ?

Ans: NO

- Is it possible to have the source code of the I2C DLL ?

Ans: Sure attached.

At last they attached the source code of the DLL which was a good thing. Nevertheless I wrote some final mail to point out my situation and what I really need for my design:

First of all thanks for your quick answer and attaching the source code. Bad news of course to hear that the GPIOs can not be combined together with the MPSSE mode. It's not quit clear to me if the behaviour comes from using the DLL or it's inherent on the MPSSE mode itself. (not checked the code in detail yet) But one thing that FTDI definitly must do is add some remark in the specification. The pdf as is now only shows following notes in the column MPSSE:

**Note 4 : MPSSE is Channel A only.
**Note 8 : SI/WU is not available in these modes.

This should be extended with a dedicated note like "GPIOs not available.." in case it's inherent on MPSSE mode and if the cause is due to the DLL in software this can be noted in the API pdf as such.

However my design issue remains and I want to find a solution. The purpose is to have 8 GPIOs available not at the same time when I need the I2C functionality. I want to poll on some eg xxBUS1 signal and act upon it when this is low with a I2C command. So it's important to have a statefull GPIO when using the I2C commands and returning to GPIO mode. Therefore maybe I can use channels A/B in some combination.

Can I use the device channel B in GPIO mode to poll and switch to MPSSE mode on channel A without losing the state on channel B ? What mode for B to use ?
I think the use of EEPROM is mandatory in such a A/B configuration ?

I hope you can point me in the right direction to solve my problems with the right design approach.

Still no answer. So maybe there's still a small change to combine the GPIOs with MPSSE I2C mode but I doubt it really. In the next blog I present some DLL calls I made to work with FTDI.

initial host platform

2008-08-20T20:44:00.000+02:00

I took the asus eee notebook as the target platform because this it doesn't have a hard disk build in. This pc works completely on SSD. The only mechanical weak part is still the small fan. XP is installed on the 4G C drive and the 8G D drive serves for data and programs. Not having a hard disk has a great advantage espacially if it must work 24/7. Also the small layout is ideal for placing it in a switch board closet. It has default WIFI on board so my access point can be dropped. It runs on a celeron M 1Ghz processor more than enough power to drive my needed applications. I also benefit of the audio availability which is built in by default. I already tested it for a few days with my web server running and the no issues were dedected. The only bad thing I can say for now is that it only has 4Gb to store the operating system on. As windows XP SP3 is installed now I only have 500Mb left. But up till now I see no blocking issues to start working with this configuration. Maybe this can be replaced in time by a server system running on RAID. I'll see what I can get out of this small 3E pc.

first analyse

2008-08-20T20:29:00.001+02:00

On the left my first ideas to cope with an FTDI based architecture. I isolated a few topics:

- Development platform
- Target deployment
- Physical composition
- Low level software interpretation

Mean less to say that this can be changed when I'll have some feedback on the overall performance and reliability of the system in this initial layout.

kick off

2008-08-20T18:34:00.000+02:00

Just started with the FT2232D chip of the new FTDI USB generation. I tried to order a development kit but the order never came trough so I cancelled it. Meanwhile I wrote some hardware specification to build my own board that easily interfaces my I2C IO board. I already did some first tests with a VC program and the FTDI dedicated DLL to have a first impression on performance. I did these tests with a ft232 chip of the previous generation. One USB call via the DLL api takes a minimum time of 2ms. This is acceptable however. So I continued my strategy in using this chip targeted for I2C communication. So it can be used together with my IO board. This means of course that the final application will be running on a PC platform. I'm not sure yet if the OS will be windows or linux because FTDI drivers are provided for several possible operating systems. But I start my development on windows for a start.

The PCB layout will soon be in production. Attached to this blog the drawing of the customized pcb. As soon it's soldered properly I post a picture. Further news will follow as we go ahead !