FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: Using FT_SetTimeouts() with FT_Write() for D2XX  (Read 14953 times)

Ron

  • Newbie
  • *
  • Posts: 2
    • View Profile
Using FT_SetTimeouts() with FT_Write() for D2XX
« on: October 06, 2022, 03:11:10 PM »

I am using D2XX drivers and FTD2XX_NET v1.1.0 in my C# application to communicate via serial port and toggle GPIO pins.

First I set the timeous using FT.SetTimeouts(5000, 0) and then I send data in loop using FT.Write() function.
I can see that the data received by the computer on the other end is corrupted.

For example, sending an array of bytes [1,2,3,4,5,6,7,8,9,0] using the following function:

void SendData()
{
    var byteArray = new byte[] { 1,2,3,4,5,6,7,8,9,0 };
    for (int i=0; i<5; i++) {
        // purge RX and TX
        FT.Purge(FT_PURGE.FT_PURGE_RX | FT_PURGE.FT_PURGE_TX);
        // write 10 bytes
        FT.Write(byteArray, 10, ref numBytesWritten);
    }
}

can result in the following data received on the other end:
[1,2,1,2,1,2,3,1,2,1,2,3,4,5,6,7,8,9,0]

But when I set the TX timeout to 5000 using FT.SetTimeouts(5000, 5000) the data is received properly.

It looks like the TX timeout of 0 causes FT.Write() to return immediately and
the consecutive calls to FT.Write() corrupt the data sent by the previous calls to FT.Write().

My questions:

1. Does TX timeout of 0 mean "infinity" or actual zero?
2. Is there an API that I can use to ensure that the previous transmission finished?
 
Please help. 
« Last Edit: October 06, 2022, 04:55:53 PM by Ron »
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 892
    • View Profile
Re: Using FT_SetTimeouts() with FT_Write() for D2XX
« Reply #1 on: October 07, 2022, 10:54:44 AM »

Hello,

Setting the timeout to 0 means that there is no timeout, so effectively it is infinity. We recommend that users set the timeout to around 5000 to allow for time to complete the read and write operations. If it set too low there will be no time to complete these operations.

Best Regards

FTDI Community   
Logged

Ron

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Using FT_SetTimeouts() with FT_Write() for D2XX
« Reply #2 on: October 12, 2022, 06:41:05 AM »

Thanks for the response.

I see that the answer to my first question is:

    "Setting the timeout to 0 actually means 'return immediately and do not wait for FT_Write() to complete'"


My second question still stands:

    Is there an API that I can use to ensure that the previous transmission finished?

Thanks in advance.

Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 892
    • View Profile
Re: Using FT_SetTimeouts() with FT_Write() for D2XX
« Reply #3 on: October 12, 2022, 09:53:48 AM »

Hi,

You could try doing a check on lpdwBytesWritten in FT_Write. This shows the number of bytes written to the device. So you could use this to see if all the data has been sent, before starting the next transmission.

Best Regards

FTDI Community
Logged

allenhuffman

  • Newbie
  • *
  • Posts: 48
  • Mostly harmless.
    • View Profile
    • Sub-Etha Software
Re: Using FT_SetTimeouts() with FT_Write() for D2XX
« Reply #4 on: August 01, 2023, 10:17:29 PM »

My second question still stands:

    Is there an API that I can use to ensure that the previous transmission finished?

I have been down this rabbit hole. There is not. You just know the data has been handed out to the FTDI driver.

This is a problem, because there is a get status call that should tell you if it is busy, but due to a hardware issue in the FTDI chip, if you call that while data transfer is in progress, it can corrupt that data.
Logged