some video shots

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

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

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

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

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

be