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

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - fcona

Pages: [1]
1
Discussion - Drivers / Re: FT_Read returns 0 bytes using D2XX driver
« on: November 23, 2020, 03:01:16 PM »
Hi ogacns94,
I don't know if you are having my same problem, so I'll describe it here, together with the workaround that worked for me, hoping it will be useful for you too.
My company has been using the D2XX library for quite a long while, mainly on Windows and macOS. Last week we tried it on Linux with our new Raspberry Pi 400.
Basically my application communicates with an FPGA, which can receive some configuration commands (using FT_Write) and streams data continuously (which I read using FT_GetStatus and FT_Read). Now, even if the device streams the data correctly, as can be checked with the windows and mac applications, on linux I receive a bunch of data until the FT_GetStatus stops notifying the presence of new data available in the driver buffer, and the stream stucks. This happens everytime, even if the amount of data received before the driver refuse to work changes with each execution.

This very same thing already happened to me in the past, but in macOS. At the time the latest release of the driver for mac was 1.4.4, and the funny thing was that the application worked just fine with the release I used before, 1.2.2. After a brief email exchange with FTDI support they released version 1.4.16 which fixed my problem. So, I tried to look for an older version of the linux driver, more specifically 1.3.6, and guess what? It worked!

Now, of course you can try an older version of the driver too and hopefully that will solve your issue. However, the version numbers of the drivers for macOS and for linux are suspiciously similar, and probably the underlying source code is very similar too in many respects since they are both unix systems. So maybe, just maybe, the same issue is present in version 1.4.8 of the linux driver, and a merge of the latest bug fixes for the mac driver can fix that too.

Best,

Filippo

Pages: [1]