Support for FTDI D2XX driver #2106
Conversation
mon
changed the title
mon
changed the title
| "Non-default FTDI interfaces", | ||
| )); | ||
| } | ||
| let Some(serial) = usb_device.serial_number() else { |
There was a problem hiding this comment.
I have multiple FTDI devices without external EEPROMs, and thus without serial numbers.
There was a problem hiding this comment.
As far as I can tell, you will still have a serial number, it will just be the empty string, so I think it'll still work in your case.
Not being able to map the nusb device path to ftdi device path certainly sucks.
There was a problem hiding this comment.
Unfortunately this definitely returns an error for me with FTDIs without external EEPROMs.
There was a problem hiding this comment.
Blast, thanks for testing. Do you often need to target a particular device? Could this just lazily use the first device instance? Or should I rework it and try another identification scheme
|
Unfortunately, Windows (11) seems very determined to install VCP drivers for my FT2232H. I either wasn't able to coerce it to use freshly installed D2XX drivers (whatever I do, Zadig identifies as |
Interestingly, I get that exact same driver, and initially was setting the "use D2XX" bit in my EEPROM. But I discovered that on my machine at least, it works in d2xx mode out of the box. It might be worth me making some sort of MVP/test app to more obviously report the state of all devices. |
|
Out of curiosity, what chip are you using? I'm on a FT232H, which is a little different from the classic FT232R, I wonder if chip types are perhaps treated differently. |
Mainly a 2232H but I see the same behavior with a 232H. |
|
Hmm - one more check (thanks for your help so far) - the libftd2xx I'm starting to think that perhaps my serial number filter when opening the device is the true culprit, and this'll help confirm. |
|
FTDIBUS driver, serial number was programmed by me. FTDI drivers, no serial number (no EEPROM in fact) Interestingly, the 2232H sometimes outputs this for either or both interfaces: FT2232H with Interface 0 WinUSB, Interface 1 FTDIBUS (serial number programmed by me) Note the interface with WinUSB driver is missing. |
- Just open the first device, don't try and be smart with serial
- Check for an empty read queue before we wait {timeout} for it to return 0 bytes
- clippy
By default in Windows 10, FTDI devices get a proprietary driver installed. This allows you to access MPSSE mode via the "D2XX" interface. The libftd2xx crate provides a safe abstraction over this.
This PR splits the FTDI driver into two parts - a new mode, using D2XX, and the old mode, using "Raw" USB comms (better names encouraged...).
This is a huge boon to user friendliness, because FTDI devices will "just work" instead of needing to grab zadig and give admin permissions and make a self-signed driver. In practice, I've also seen Windows replace the WinUSB driver, making the zadig approach unreliable.
I discovered midway through this PR that probe-rs only supports JTAG via FTDI probes, so I can't actually test it (I only have SWD devices on hand), but I wrote a similar patch for openocd, and didn't encounter any major bugs. Hopefully it's the same here.