0

My application on PC sends a file (2 MB) in chunks of 1 KB to embedded device.

I use FTDI Windows driver, I use the classic FT_Write() API function as my code is cross-platform.

Note: These issues below appear when I use 1KB chunk size. Smaller chunk (I tried 64 bytes) works fine.

The problem is the function returns "0 byte sent" every couple hundred packets and stuck. I found a work around, by purging both TX and Rx, followed by ResetDevice() call recovered the chip. It still happened every couple hundred packets, but at least I can send the whole file (2 MB).

But when I use USB isolator (http://www.bb-elec.com/Products/USB-Connectivity/USB-Isolators/Compact-USB-Port-Guardian.aspx) the work around failed.

I believe my work around is not a graceful solution.

Note: I use large chunk because of suggestion I found in FTDI application note below:

When writing data to an FTDI device, as much data as possible should be buffered in the application and written to the device in a single write function call (either WriteFile for a VCP application using the Win32 API, FT_Write if using the D2XX classic interface or FT_WriteFile if using the D2XX FT_W32 interface). The result of this is that the data will be written to the device with 64 bytes per USB packet.

Any idea what's the proper fix for these issues? Is it related to FTDI initialization? My driver version is 2.12.16.0 (3/9/2016).

Community
  • 1
  • 1
serenity
  • 11
  • 5

1 Answers1

2

  1. I also saw the same problem of API FT_Write() not working right if too much data was passed, while working on the library for my USB device Nusbio. I mostly work in the mode Synchronous Bitbanging rather than UART but after all it is the same hardware, driver and API.

  2. There are the USB 2.0 specification or the FTDI FT232RL specification and then there is reality of the electron and bit. The expected numbers of transfer speed never really match at least at first. In other words it is complicated (see more below in my referenced blog post).

  3. In 2015 I was under the impression that with FTDI chip FT232RL the size of 384 bytes was working well and the number comes from the chip datasheet (128 byte receive buffer and 256 byte transmit buffer). Using a size of 500 bytes would still work but above 600 bytes thing would not work.

    I later used the chip FT231X which has a larger buffer (1k, 512 byte receive buffer and 512 byte transmit buffer). and was able to transfer with FT_Write() 1k and 2k buffer of data, therefore more than doubling my speed of transfer. But above 2k things would not work.

  4. In 2016, I read every thing you can read about FTDI USB 2.0 Full speed chip, I came to the conclusion that FT_Write should support up to 64K (see datasheet for the following chip FT232RL, FT231X, FT232H, FT260, FT4222).

I also did some research on faster serial port communication from .NET than 115200 baud.

Somehow I was able to update my C# library to send data in buffer of 32k in FT_Write() and it is working with the FT232RL and the FT231X chip, but I can't tell you what changed. I was probably not completely underdanding the in and out of the USB 2.0 full speed FTDI technology.

For example let's say you are using the FT232RL and transfering 384 bytes at the time with FT_Write(). Knowing that there is at least a 1 milli-second latency in USB 2.0 full speed what ever you do, you are transfering from a USB point of view 384*1000/1024, that is 375 K byte/s in theory (that would be the max), that said now what is the baudrate supported by your embedded device. What is the baudrate used? The FT232RL max baudrate is 900 000 baud, which would give you only 900000/(1+8+1) == 87 K byte/S. Right away you can tell there is going to be some problem, may be the FTDI driver takes care of it or not. I can't tell. Re do the math based on the baudrate supported by your embedded device, and a 384 byte buffer sent 1000 per second, then slow down your USB speed with a sleep() to match your baud rate.

That is where I would start.

MadeInTheUSB
  • 110
  • 6