Some timings

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....