timings

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.