[prev in list] [next in list] [prev in thread] [next in thread]
List: libftdi
Subject: Re: libftdi and ftdi_sio
From: Benjamin Bass <benbass () codedstructure ! net>
Date: 2015-09-01 21:41:01
Message-ID: 0478D78D-9784-4489-8AB1-48C18A73E483 () codedstructure ! net
[Download RAW message or body]
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 <shashank@chintal.in> 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 libftdi+unsubscribe@developer.intra2net.com \
> <mailto:libftdi+unsubscribe@developer.intra2net.com>
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@developer.intra2net.com
[Attachment #3 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space;" class="">Hi Chintalagiri,<div \
class=""><br class=""></div><div class="">Author of pylibftdi here; I suspect the \
issue is with the version of pylibftdi you are using.</div><div class=""><br \
class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><div \
class="">pylibftdi version : 0.16.0pre</div><div class="">libftdi \
version : libftdi_version(major=1, minor=1, micro=0, \
version_str='1.1', snapshot_str='v1.1-12-g2ecba57')</div><div class="">libftdi \
library name : libftdi1.so.2</div><div class="">libusb version \
: libusb_version(major=1, minor=0, micro=17, nano=10830, rc='', \
describe='<a href="http://libusbx.org'" class="">http://libusbx.org'</a>)</div><div \
class="">libusb library name : libusb-1.0.so.0</div><div class="">Python \
version : 2.7.6</div><div class="">OS platform \
: \
Linux-3.13.0-55-generic-x86_64-with-Ubuntu-14.04-trusty</div></div><div class=""><br \
class=""></div><div class="">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.</div><div \
class=""><br class=""></div><div class="">Happy to take this off-list if you want to \
discuss anything pylibftdi-specific further.</div><div class=""><br \
class=""></div><div class="">Regards,</div><div class="">Ben Bass</div><div \
class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Aug \
2015, at 02:16, Shashank Chintalagiri <<a href="mailto:shashank@chintal.in" \
class="">shashank@chintal.in</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div \
class=""><div class=""><div class=""><div class=""><div class="">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. <br class=""><br class=""></div><br class="">I notice \
the following (expected) behaviour : <br class=""><br class=""></div> * Using \
libftdi causes ftdi_sio to be unloaded (detached). Any ftdi_sio provided /dev/ttyUSBx \
disappear.<br class=""></div><div class=""> * All /dev/ttyUSBx disappear, \
regardless of how many FTDI devices are connected and how many of those have libftdi \
drivers attached.<br class=""></div> * 'Creating' a pylibftdi Device (which \
effectively translates to an ftdi_usb_open_* call) makes libftdi active.<br \
class=""></div> * 'Closing' a pylibftdi Device does not seem to reload \
ftdi_sio.<br class=""><br class=""><br class=""></div><div class="">What I'm having \
some trouble with is the following : <br class=""><br class=""></div><div \
class=""> * Is it possible to use libftdi on some (or one) FTDI devices, but \
continue using ftdi_sio on others? If so, how.<br class=""><br class=""></div><div \
class=""> * 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. <br \
class=""></div><div class=""><br class=""> * 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.<br class=""><br class=""></div><div class=""> * 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?<br class=""><br class=""><br class=""></div><div \
class="">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 <span class="">libusb_attach_kernel_driver() after </span><span \
class="">libusb_release_interface</span>() and before <span \
class="">ftdi_usb_close_internal</span>() in <span \
class="">ftdi_usb_close</span>(<span class="">). 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().</span> Is there any chance for this to \
work?<br class=""><br class=""><br class=""></div><div class=""><br \
class=""></div><div class="">For reference, here is the relevant portion of the code \
that I'd like to be able to use : <br class=""><br class="">driver = \
pylibftdi.Driver()<br class="">devices = driver.list_devices()<br class="">serials = \
[x[2] for x in devices]<br class=""><br class=""></div><div class=""># If I exit at \
this point, /dev/ttyUSBx is still available.<br class=""><br class="">with \
pylibftdi.Device(device_id="some serial number") as device:<br class=""></div><div \
class=""><br class=""> # This 'with' ... is a contextmanager in \
python. At the end of this code<br class=""></div><div class=""> # \
block, device.close() is called automatically. Within pylibftdi, this <br \
class=""></div><div class=""> # is implemented as a call to \
libftdi's ftdi_usb_close and then<br class=""></div><div class=""> \
# ftdi_usb_deinit<br class=""><br class=""></div><div class=""> chipid = \
c_uint()<br class=""> device.ftdi_fn.ftdi_read_chipid(byref(chipid))<br \
class=""><br class=""># /dev/ttyUSBx is gone, but at this point I want it back. <br \
class=""><br class=""></div><div class=""><br class="">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) : \
<br class=""><br class="">def close(self):<br class=""> """<br \
class=""> close our connection, free resources<br class=""> \
"""<br class=""> if self._opened:<br class=""> \
ctx_p = cast(byref(self.ctx), POINTER(ftdi_context_partial)).contents<br \
class=""> self.fdll.ftdi_usb_close(byref(self.ctx))<br \
class=""> if self.auto_detach:<br class=""> \
dev = ctx_p.libusb_device_handle<br class=""> \
if dev:<br class=""> \
self.driver._libusb.libusb_attach_kernel_driver(dev, \
1)<br class=""> self.fdll.ftdi_deinit(byref(self.ctx))<br \
class=""> del self.ctx<br class=""> \
self._opened = False<br class=""></div><div class=""><div class=""><div class=""><div \
class=""><div class=""><div class=""><div class=""><div class=""><div class=""><br \
class=""><br class="">[1] <a \
href="http://pylibftdi.readthedocs.org/en/latest/pylibftdi.html" \
class="">http://pylibftdi.readthedocs.org/en/latest/pylibftdi.html</a><br \
class="">[2] <a href="http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00123.html" \
class="">http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00123.html</a><br \
class=""><br class=""><br class=""></div><div class="">Thanks,<br class=""></div><div \
class="">Chintalagiri Shashank<br class=""><br class=""><br \
class=""></div></div></div></div></div></div></div></div></div></div>
<br class=""><hr class=""><p class=""><b class="">libftdi</b> - see <a \
href="http://www.intra2net.com/en/developer/libftdi" \
class="">http://www.intra2net.com/en/developer/libftdi</a> for details.<br class=""> \
To unsubscribe send a mail to <a \
href="mailto:libftdi+unsubscribe@developer.intra2net.com" \
class="">libftdi+unsubscribe@developer.intra2net.com</a></p>
<br class=""></div></blockquote></div><br class=""></div>
<br><hr><p><b>libftdi</b> - see <a \
href="http://www.intra2net.com/en/developer/libftdi">http://www.intra2net.com/en/developer/libftdi</a> \
for details.<br> To unsubscribe send a mail to <a \
href="mailto:libftdi+unsubscribe@developer.intra2net.com">libftdi+unsubscribe@developer.intra2net.com</a></p>
<br></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic