libftdi and ftdi_sio

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

libftdi and ftdi_sio

Shashank Chintalagiri
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


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libftdi and ftdi_sio

Ryan Tennill
On 8/22/2015 8:16 PM, Shashank Chintalagiri 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
> [2]
> http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00123.html
>
>
> Thanks,
> Chintalagiri Shashank

I have done this in C using the libusb call that referenced and then
closing the device using  libusb_close(). Using this method, I am able
to collect serial data from 59 devices with libftdi and use minicom on
one or more other devices at the same time. When I'm done with the
ttyUSBx I can then recapture it with libftdi.

I don't use libusb_set_auto_detach_kernel_driver() myself, not sure if
that happens in the lib someplace though.

Ryan

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libftdi and ftdi_sio

Krishnendu Chatterjee
In reply to this post by Shashank Chintalagiri

Opening one ftdi device with libftdi (say bound to /dev/ttyUSB0) will not detach any other ftdi device bound to other ports (say /dev/ttyUSB1).

On Aug 23, 2015 6:46 AM, "Shashank Chintalagiri" <[hidden email]> 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


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]




libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libftdi and ftdi_sio

Benjamin Bass
In reply to this post by Shashank Chintalagiri
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 <[hidden email]> 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


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]





libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Loading...