pyftdi for windows

[rqx110]

there is a fork project provides a better out-of-the-box experience by supporting the default Windows plug-and-play drivers provided by FTDI. https://github.com/mariusgreuel/pyftdiwin

could you merge these codes?

[eblot]

Yes I guess I could but it would require to create pull request(s). If you know the author or volunteer to create those PRs, please let me know.

[eblot]

I had a quick look at this project/fork.

From what I understand, I think it would make much more sense to add D2XX support to pyusb rather than to PyFtdi:

1. It could be used for other pyusb-based projects, not only PyFtdi
2. PyFtdi is designed not to have a direct dependencies on a native library. I'm pretty sure having a requirement on ctypes would create issues with other projects that rely on PyFtdi. This means this would have to be an optional dependency, which might be not simple to handle.
3. Testing is also an real issue :(

[eblot]

BTW I've added a direct link to this project from https://eblot.github.io/pyftdi/requirements.html#development

[mcuee]

I do not think it makes sense for the function to be added in pyusb.

Your best bet is to improve https://github.com/mariusgreuel/pyftdiwin.

I have closed https://github.com/pyusb/pyusb/issues/539 as not planned.

[mcuee]

BTW, the author of pyftdiwin also did the following fork of libftdi (subset) for use with avrdude Windows. https://github.com/avrdudes/libftdi

[nylnx]

I think the only real way to implement support for both Windows and Linux would be to build a way for pyftdi to accept different/custom backends. In a first step, someone would have to ask @mariusgreuel for permission to take his emulation layer and repackage it to a standalone backend one could pull and use together with pyftdi.

In a later step it would probably make sense for pyftdi to move its backend interface away from USB towards a generic description and USB would only be an implementation of this interface for Linux and for Windows it would remove the necessity to translate USB commands to FTDI driver commands and simply implement the interface directly with the driver commands.

What are your thoughts?

[eblot]

Hi @nylnx,

Adding D2XX or any close source native library to this project would be the exact anti-definition of PyFtdi: it has been designed and supported as a way NOT to have to drag native libraries and all the issues that come with them.

To be fully honest: I do hate Windows and I do not want to deal with it. Adding a D2XX compatible layer to PyFtdi would mean having to test pyftdi with it before every single release.

I believe the best way at this point for users that really want to use Windows to create a fork from pyftdi and/or to resume the work from pyftdiwin if it is no longer supported.

Adding experimental support for Windows to pyftdi (to help some users) was one of the biggest mistakes of this project - there are many other ones though :-). I would be more than happy to remove any doc entries related to Zadig from pyftdi and replace them with pointers to this new project.

Note that it seems there are already existing Python wrapper modules around D2XX for people that want to use the official FTDI APIs from Python.

[mcuee]

I believe the best way at this point for users that really want to use Windows to create a fork from pyftdi and/or to resume the work from pyftdiwin if it is no longer supported.

Totally agree.

[NsTrmb]

FYI : on my side i'm using WSL2 with pyftdi + USB binding from Windows to Linux and all is working like a charm 😸