Open Source (re)implementation of D2XX drivers for FTDI chips?

Hi All,

I need to provide the USB connectivity for USB not capable microcontroller. The FTDI chips are the simplest and cheap solution. However the VCP drivers do not provide sufficient throughput. The D2XX do not, but they are not open source, so are usable only for a few platforms, for which FTDI has provided binaries of their library. Is there any Open Source equivalent of the D2XX drivers? Has anybody succeeded to reverse engineer the USB protocol used by the D2XX drivers?

--
TIA & Regards,
Wojtek
Reply to
Wojciech Zabolotny
Loading thread data ...

I have found myself

formatting link
It is Open Source and GPLed, however it is unclear if it is able to provide functionality and throughput comparable with the D2XX drivers... Does anybody know it?

-- Regards, Wojtek

Reply to
wzab

The FTDI web page says drivers are available for:

Windows Vista x64 Windows XP x64 Windows Server 2003 x64 Windows Vista Windows XP Windows Server 2003 Windows 2000 Windows ME Windows 98 Linux Mac OS X Mac OS 9 Mac OS 8 Windows CE.NET (Version 4.2 and greater)

Third-party drivers are available for:

Linux Free BSD Open BSD QNX Windows CE

I haven't tried any of these, but I wonder what systems you are using if that selection counts as "only a few platforms". Their broad support of systems is one of the reasons for FTDI's popularity.

As for open source drivers, modern Linux and *BSD kernels have drivers for at least some FTDI parts as standard.

If you are wanting drivers for other systems, have you contacted FTDI for information before trying to reverse engineer existing drivers?

Reply to
David Brown

Nearly all functionality of D2XX is also available with direct USB access via e.g. libusb. Libusb is also available for windows.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

It looks like someone else has had as much "fun" with the FTDI interface library as I have!

Thanks for the link, G.

Reply to
ghelbig
[...]
[...]
[...]

E.g. Linux on the CRIS platform, or Linux on the ARM platform.

Further the README.dat provided for the Linux library states: "This library has been tested using kernel 2.4.25." It is definitely not the latest wversion of the kernel. What about the new 2.6.xx kernels? Maybe switching from 2.4 to 2.6 does not make a difference for FTDI library, but anyway why it is not tested with 2.6?

Hmmm, AFAIK they are only the VCP-like drivers with limited throughput.

Having the open source drivers is anyway desired - e.g. for easier debugging or for optimizing for particular needs. Maybe it is a kind of "ideology" but I prefere to avoid closed source solution as far as possible.

-- Wojtek

Reply to
wzab

They don't?? What speeds are you running them at?

I've used their FT232BM at a 2mbps datarate with decently high throughputs.......... on a 50mhz Parallax uC.

I've tested both the VCP and the D2XX with great results.... I eventually ended up using D2XX just because it supports DTR/DSR flow which was required given the implementation I was working with.

This was in JAVA with a JNI under Windows.

Keith

Reply to
Keith M

I need to transfer a big amount of data from the device, which is not USB capable. The device is able to provide the datastream with rate 8Mb/s or even

10Mb/s, so the higher rate I can achieve, the better. Unfortunately the design is price sensitive, so that's why I tried to use the FTDI chip.

-- Wojtek

Reply to
wzab

FTDI chips are only full speed so 8Mbps is about the best that you can expect to get. If you need more throughput then you will need to use a high-speed device.

Andrew

Reply to
Andrew Jackson

I fully understand the preference for open source drivers, especially on a Linux system. It's not ideology, it's practicality for better development and better products.

I did not realise that the Linux drivers from FTDI and in the kernel source code were limited like this - I thought they consisted of kernel code within the main Linux tree and some user space functionality that is independent of the kernel. But then, I haven't look at it in detail (we've only needed Windows drivers so far).

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.