Consider implementing a FTDI D2XX backend

[tanriol]

Consider implementing a FTDI D2XX backend

[tanriol]

That's even without mentioning the fact that using the ftd2xx.lib automatically means no GPL components in the same software. Fortunately for this case, GPL is not exactly popular in the Rust community.

[tanriol]

Also, what does "driverless" actually mean? Is there no driver at all? Auto installed from Windows Update? Auto installed by the application on first run?

[xobs]

I suppose it means auto-installed from Windows Update, or more likely the ftdi serial driver is shipped with Windows. As an example, when using the Icebreaker with swot, a user just needs to plug it in. There is no additional setup needed and no programs to install. This is similar to how, for example, the Lattice programmer software works, or the Segger J-Link software.

I do agree that ftd2xx.lib does raise some licensing concerns, which is why it would make sense to put it behind a feature gate.

[xobs]

Additionally, from the download page:

FTDI drivers may be used only in conjunction with products based on FTDI parts.
FTDI drivers may be distributed in any form as long as license information is not modified.

...which is rather interesting because their zip files don't actually include license information.

[cr1901]

@tanriol I don't understand how it works, but in the *nix world (tested on NetBSD and Linux), libusb has some magic that can tell the kernel to detach the default device driver- which on FTDI devices is almost certainly a serial port- and tell libusb to take over.

For whatever reason libusb can't do the same detaching on Windows, but the ftd2xx.lib drivers can. Unfortunately, since they're closed-source, I don't know how they detach the serial port drivers.

libwdi/Zadig is typically used to replace the default Windows device driver completely with a kernel mode driver that libusb talks to instead¹. It works, but it's irritating.

And tbh, I'm not aware good wrapper that allows you to choose ftd2xx.lib or libftdi1 as a backend, and use a unified API. Opportunity to be the first :P?

1. As of Windows 8, it's also possible to use a special USB descriptor that tells Windows that the device speaks WinUSB, without installing a special device driver. libusb can talk to WinUSB just fine.

[newAM]

I was looking at using the D2xx driver with rust and I ran into the same issue; the license is not very clear. I sent an email to FTDI support asking if this specific use case is OK.

In the worst case it is possible to download the archive (it is only 880KiB for Linux x64 release) in build.rs, though that is not at all ideal.

[newAM]

The message:

Hello,

I am building an open source rust library which interfaces with your D2xx FTDI driver, and I am hoping you can offer me some clarification on the license terms.

I would like to redistribute the D2xx drivers from this page as a component of the library.
The download page states: "FTDI drivers may be distributed in any form as long as license information is not modified."

However, on the specific license terms page here it states: " 3.1.7 not to provide, or otherwise make available, the Software in any form, in whole or in part (including, but not limited to, program listings, object and source program listings, object code and source code) to any person."

I am not a lawyer, and I am a bit confused by these seemingly conflicting statements.

May I re-distribute your FTDI D2xx driver as a component of a library?

Thanks
-Alex

The reply:

Hello Alex,

Yes I can see why the wording might be confusing, I will be sure to let the relevant teams know to update this.

In any case, I talked to my manager and you are free to redistribute the D2XX driver as a component of your library.

Best Regards,
Aaron Jones
Customer Support Engineer

This is enough for me. I started an FFI library on the weekend downloading the source in build.rs. I will clean this up this weekend and hopefully get the Windows build functional.
https://github.com/newAM/libftd2xx-ffi-rs

Should I add the D2xx driver as a configurable backend for this library or start a new one? Adater layers are always a bit messy - but they do seem less messy in rust. There will still be sacrifices to simplicity. I just want to make sure that these changes will be welcome here :)

[tanriol]

Nice to hear!

I don't have experience working with D2XX. How much does its API differ from the libftdi API - is the difference only in function names or more deep?

[xobs]

It's very similar. One difference, as I understand it, is that FTDI -- being a device company -- writes their APIs from the perspective of the device, whereas libftdi autors -- being software people -- write their APIs from the perspective of the computer. So occasionally you'll get "send" and "recv" swapped between the two APIs. It's purely syntactic though.

I was able to port iceprog from C++ to Rust and libftdi to D2XX without too much issue and without too much familiarity with the library simply by looking up calls that seemed similar and replacing them.

[newAM]

I cleaned up the repository and got the FFI bindings compiling & running on Linux + Windows. It still needs more work, but the core functionality is there.

Do either of you have any ideas on what I should use for [free] Windows CI? I see travis has an early adopters Windows platform and I am wondering if there is anything else out there.

[tanriol]

I've used Github Actions for libftdi1-sys.

Speaking about integration with this crate: sounds possible to make it work as an alternate backend under a separate feature.

[newAM]

Updating this issue years later. I was looking to make a separate back-end when I started on libftd2xx, but I was not familiar enough with the language to do this at the time (it was my first project in rust).

@geomatsi is now working on this problem in ftdi-rs/libftd2xx#48 (review), which adds an MPSSE trait (in a separate repository) that both the ftd2xx type and the libftdi type can implement.

[cr1901]

At this point, there are several different FTDI crates for Rust, all of them in various stages of completion with different APIs (and/or HAL traits) providing the same thing.

Although I'm no longer that interested in maintaining my own crate, I still get PRs from ppl who want to use my crate. An MPSSE trait could be quite useful that's shared between the various FTDI impls.

(I wonder if there also could be a "wrapper" trait in ftdi-embedded-hal such that if you impl the wrapper trait you get a free HAL impl...)

[tanriol]

I've got a few deadlines at the moment, but I'm going to look into this, hopefully in a couple weeks or so.