Comments (14)
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.
from ftdi-rs.
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?
from ftdi-rs.
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.
from ftdi-rs.
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.
from ftdi-rs.
@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 instead1. 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?
- 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.
from ftdi-rs.
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.
from ftdi-rs.
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 :)
from ftdi-rs.
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?
from ftdi-rs.
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.
from ftdi-rs.
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.
from ftdi-rs.
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.
from ftdi-rs.
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.
from ftdi-rs.
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...)
from ftdi-rs.
I've got a few deadlines at the moment, but I'm going to look into this, hopefully in a couple weeks or so.
from ftdi-rs.
Related Issues (4)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ftdi-rs.