Hi Chintalagiri, Author of pylibftdi here; I suspect the issue is with the version of pylibftdi you are using.
I’ve just tested the original test code you wrote with a ‘watch -n 0.5 “ls -l /dev/ttyUSB*”’ running in another terminal, and it works as intended for me (ttyUSBx remains following the with statement; I’ve also tested by including some raw_input() statements inside the `with` to pause things and see the devices do disappear and then reappear). I’m running Ubuntu 14.04, if it’s of any relevance. The following is the output I get from python -m pylibftdi.examples.info: pylibftdi version : 0.16.0pre libftdi version : libftdi_version(major=1, minor=1, micro=0, version_str='1.1', snapshot_str='v1.1-12-g2ecba57') libftdi library name : libftdi1.so.2 libusb version : libusb_version(major=1, minor=0, micro=17, nano=10830, rc='', describe='http://libusbx.org') libusb library name : libusb-1.0.so.0 Python version : 2.7.6 OS platform : Linux-3.13.0-55-generic-x86_64-with-Ubuntu-14.04-trusty The version of pylibftdi released on pypi is still 0.15 and doesn’t have this auto-detach feature, but there are some things to finish off with regards the streaming API which mean a release of 0.16 hasn’t happened yet. I’d be interested to see if the latest version from bitbucket works for you. Happy to take this off-list if you want to discuss anything pylibftdi-specific further. Regards, Ben Bass > On 23 Aug 2015, at 02:16, Shashank Chintalagiri <[email protected]> wrote: > > I'm 'using' libftdi. Assume for he purpose of this discussion that I only > care about posix systems, and if necessary than can be restricted to modern > desktop linuxes. While the actual code I'm running is python code using > pylibftdi [1], an approach from the C and libftdi perspective is fine. > > > I notice the following (expected) behaviour : > > * Using libftdi causes ftdi_sio to be unloaded (detached). Any ftdi_sio > provided /dev/ttyUSBx disappear. > * All /dev/ttyUSBx disappear, regardless of how many FTDI devices are > connected and how many of those have libftdi drivers attached. > * 'Creating' a pylibftdi Device (which effectively translates to an > ftdi_usb_open_* call) makes libftdi active. > * 'Closing' a pylibftdi Device does not seem to reload ftdi_sio. > > > What I'm having some trouble with is the following : > > * Is it possible to use libftdi on some (or one) FTDI devices, but continue > using ftdi_sio on others? If so, how. > > * After I'm done using libftdi, I'd like to have the /dev/ttyUSBx back. I > know I can do this by manually running insmod, but I'm hoping that it can be > achieved without manual intervention. Since libftdi is able to (effectively) > run rmmod, I would expect it to be able to reverse it's actions either at an > algorithmically determined point or at the user's explicit request. > > * The creation of the pylibftdi Device instance includes a call to libusb's > libusb_set_auto_detach_kernel_driver(), which should, according to the > documentation, reload the kernel when the device is released. This does not > work. Is there something I'm missing here? Is there a libftdi specific way / > function which can reload ftdi_sio - either on device close or by an explicit > function call by my code, assuming that I take responsibility for any > unintended side effects of doing so. > > * If you have, say, 3 FTDI devices, of which 2 use libftdi. If only one of > those two are closed, then reloading ftdi_sio at that point is likely not a > good idea. If there is an attach_kernel_driver() or similar function within > libftdi, what rationale does it use? Similarly, if libusb's > libusb_set_auto_detach_kernel_driver() was to work or a call to > libusb_attach_kernel_driver() was made, how would libusb handle this and how > would libftdi react to this? > > > I found a small patch [2] on the mailing list which seemingly addressed this > issue. The OP there didn't seem to want to see it through, and that line of > code didn't make it into libftdi. Would that piece of code have worked? Is / > was there something inherently wrong with that approach? More immediately, > would it be possible to use that approach from outside libftdi? Specifically, > the proposed patch involved calling libusb_attach_kernel_driver() after > libusb_release_interface() and before ftdi_usb_close_internal() in > ftdi_usb_close(). However, if I'd like to be able to do this with vanilla > libftdi, the libusb_attach_kernel_driver() call would have to come either > before or after ftdi_usb_close(). Is there any chance for this to work? > > > > For reference, here is the relevant portion of the code that I'd like to be > able to use : > > driver = pylibftdi.Driver() > devices = driver.list_devices() > serials = [x[2] for x in devices] > > # If I exit at this point, /dev/ttyUSBx is still available. > > with pylibftdi.Device(device_id="some serial number") as device: > > # This 'with' ... is a contextmanager in python. At the end of this code > # block, device.close() is called automatically. Within pylibftdi, this > # is implemented as a call to libftdi's ftdi_usb_close and then > # ftdi_usb_deinit > > chipid = c_uint() > device.ftdi_fn.ftdi_read_chipid(byref(chipid)) > > # /dev/ttyUSBx is gone, but at this point I want it back. > > > And here is the route I think may work (though I haven't had a chance to try > it yet for lack of a device on hand) : > > def close(self): > """ > close our connection, free resources > """ > if self._opened: > ctx_p = cast(byref(self.ctx), POINTER(ftdi_context_partial)).contents > self.fdll.ftdi_usb_close(byref(self.ctx)) > if self.auto_detach: > dev = ctx_p.libusb_device_handle > if dev: > self.driver._libusb.libusb_attach_kernel_driver(dev, 1) > self.fdll.ftdi_deinit(byref(self.ctx)) > del self.ctx > self._opened = False > > > [1] http://pylibftdi.readthedocs.org/en/latest/pylibftdi.html > <http://pylibftdi.readthedocs.org/en/latest/pylibftdi.html> > [2] > http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00123.html > <http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00123.html> > > > Thanks, > Chintalagiri Shashank > > > > libftdi - see http://www.intra2net.com/en/developer/libftdi > <http://www.intra2net.com/en/developer/libftdi> for details. > To unsubscribe send a mail to [email protected] > <mailto:[email protected]> -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
