ftdi-rs/libftd2xx

Unloading usbserial module on Linux

jwillikers opened this issue · 7 comments

jwillikers commented

Is it necessary to unload the usbserial module on Linux?
It's kinda built-in to my kernel on Fedora.

$ sudo rmmod usbserial
rmmod: ERROR: Module usbserial is builtin.

I'm able to unload ftdi_sio.

newAM commented

I never had to unload usbserial on NixOS and Ubuntu, only ftdi_sio.

  • 👍1
jwillikers commented

Shouldn't running the list example not be empty for my connected FT232H, though?

$ cargo run --example list --features static
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/examples/list`
device: DeviceInfo { port_open: false, speed: Some(HighSpeed), device_type: FTAM, vendor_id: 0x0000, product_id: 0x0000, serial_number: , description:  }

I'm trying to run something using the ftdi-embedded-hal crate and it appears to be running but I'm wandering if it isn't actually connecting to anything.

newAM commented

The FTDI devices get the USB strings & VID/PID from the onboard EEPROM, I have seen that occur before with an invalid EEPROM when Adafruit shipped me a faulty FT232H.

You can change the EEPROM with the APIs in this crate, but I found that pyftdi's CLI tool for updating the EEPROM is much more user friendly.

jwillikers commented

Thanks, that was helpful.
The manufacturer, serial number, and another field were all corrupted.
Took me a while to figure out how to write to the EEPROM after erasing everything including the VID/PID.

Before doing that, though, why would driving the NeoPixels with Adafruit's NeoPixel SPI library, which uses pyftdi, not have any problems?
It worked when the EEPROM was corrupted.
Just curious, especially since the corrupt EEPROM issue seems to cause things to fail silently.
Of course, I might be doing something else wrong.

newAM commented

Before doing that, though, why would driving the NeoPixels with Adafruit's NeoPixel SPI library, which uses pyftdi, not have any problems?

The libftd2xx driver is made for Windows unfortunately, and Linux support was shoehorned in afterwards. The result of this is a Windows-like experience on Linux.

pyftdi can make significantly better decisions about device detection because they are using libusb directly without any considerations for Windows. The open source driver, libftdi, would probably work as well, though the embedded-hal implementations for that driver are a work-in-progress: ftdi-rs/ftdi-embedded-hal#2

Outside of this project I generally try to avoid libftd2xx on Linux because the open source ones are better.

jwillikers commented

That's awesome! Looking forward to it.

newAM commented

Closing this issue now as the first release of ftdi-embedded-hal has been made, feel free to reopen if that doesn't resolve it!

  • 👍1