I am using a Beaglebone Green connected to my PC with the USB serial. Then I need to connect in the host USB connector a device that needs FTDI D2XX drivers. These drivers are installed according FTDI procedure. What appends is that I run the commands ‘sudo rmmod ftdi_sio’ and sudo rmmod usbserial’ to allow the D2XX drivers to work but when I connect the device in the USB host port it seams that the ftdi_sio is still active because it detects the device. It seams that the VCP drivers are reloaded every time I connect the device. Does any one have a clue why this appends ?
Kernel drivers are loaded automatically upon detection of a device.
You shouldn’t need to have to manually unload drivers. If libftd2xx wants to directly access the usb device it can detach the ftdi_sio kernel driver itself, e.g. as seen in libftdi (an open-source alternative to libftd2xx):
If libftd2xx fails to do this, that would simply be a bug in libftd2xx.
Note that you don’t need ftdi_sio to communicate with a beaglebone unless you’re using an ftdi usb-serial cable to connect to the beaglebone’s debug serial port, which is not typical. So as an option of last resort you could just blacklist the ftdi_sio driver to prevent it from getting loaded. That can be done by creating a file /etc/modprobe.d/blacklist-ftdi_sio.conf containing the following line:
A better solution would be to use an udev rule to prevent the driver from being loaded only for the specific devices for which you want to use libd2xx. I don’t remember the details of how to do this but you can try a google search.
But like I said, in the end these are all just workarounds for bad software, they should not be needed if libd2xx is doing its job correctly.
I send a event log when I connect the device to the host usb port. Before I just removed the ftdi_sio and usbserial drivers. Repeating the rmmod command I get the message that the drivers are not loaded.
The log event list after reconnect the device is this one:
USB device drivers are typically loaded based on the VID and PID of the usb device. You didn’t actually include the usb device (the parent of the ttyUSB0 device, /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1:1.0) in your output. Its parents are not relevant.
I don’t know how to do it. To get these listings I just run the command 'sudo udevadm monitor ’ and then connecting the device I got the output above ( first list ).
I already run a small program using the D2xx drivers but for that I had to remove the VCP drivers more than once just before run the program. My goal is to discover a way to make a rule to avoid this loading at start up as you suggested.
Like I said, detaching the ftdi_sio driver should be the responsibility of the library you’re using. If libftd2xx fails to do this, my recommendation would be to use libftdi instead which should properly take care of this.
If it’s not possible to use libftdi instead of libftd2xx, you should probably consider complaining to FTDI that libftd2xx should detach the kernel driver (e.g. using libusb_detach_kernel_driver() if they’re using libusb). As a workaround you can blacklist the ftdi_sio driver entirely as I already explained in an earlier reply.
I wouldn’t bother digging into udev unless you specifically need to use a mix of devices that need ftdi_sio and devices that need libftd2xx.
According the FTDI manual, I need to detach the VCP drivers because it is Linux.
The libftd2xx seamed more complicated to use and that it is why I was avoiding to use ( also the device supplier has already some routines with D2xx drivers ).
I will try to blacklist the drivers.
“VCP drivers” and “D2xx drivers” are Windows-specific terms, the linux equivalent of VCP is the ftdi_sio driver, the linux equivalent of D2xx is libftd2xx. I treated these terms as equivalent in my previous comments.
An open-source alternative to libftd2xx is libftdi.
If FTDI is saying you need to detach the ftdi_sio driver yourself then they’re simply incompetent, it’s the responsibility of their libftd2xx library. The aforementioned open source alternative, libftdi, does this correctly.
Yes that indeed confirms they’re not actually competent regarding how linux works, which also gives little confidence in their libftd2xx library, hence my recommendation to consider the open-source alternative libftdi which shouldn’t have these problems.
BTW there’s absolutely never a reason to remove the usbserial driver, I have not the slightest idea why they included that in their instructions. But even removing ftdi_sio is just a silly workaround for a problem in their library.