pyusb-users — PyUSB users mailing list discussion

Re: [pyusb-users] USBError: Operation timed out

[Karl P. <ka...@tw...>]

I'm pretty sure you're not actually sending the request that the manual
says.

Caleb Mayfield <cal...@gm...> wrote:
>  I am new to using Python and PyUSB. I am trying to write a program to
> communicate with a 3M Quest SoundPro sound meter. Because I'm new, I'm
> starting simple. The vendor was gracious enough to send me the manual
> they
> have on the commands for the unit. Right now all I'm trying to do is
> request the serial number and read the response. I just need to get
> communication between a Raspberry Pi and the device working. I have used
> the software on a Windows 7 machine along with a USB sniffer to verify
> the
> commands and endpoint address were correct.
> 
> This is the program;
> 
> import usb.core
> 
> import usb.util
> 
> import sys
> 
> dev = usb.core.find(idVendor=0x130c, idProduct=0x0001)
> 
> if dev is None:
> 
> raise ValueError('Device not found')
> 
> dev.set_configuration()
> 
> print "Connected to " + str(dev)
> 
> QS = '0x51,0x53,0x0D'   #Call for Serial number
> 
> dev.write(0x02,QS,0,0)

I don't believe this is really right, you're probably meant to send the
three bytes, 0x51, 0x53, 0xd, not the 14 bytes, 0, x,5,1,,,0,x,5,3.....

You probably just want to do something like...

dev.write(0x02, "QS\r", 0, 0)


If you can share the manual, You can probably get more correct help than
my asumptions. :)

Cheers,
Karl P

[pyusb-users] USBError: Operation timed out

[Caleb M. <cal...@gm...>]

 I am new to using Python and PyUSB. I am trying to write a program to
communicate with a 3M Quest SoundPro sound meter. Because I'm new, I'm
starting simple. The vendor was gracious enough to send me the manual they
have on the commands for the unit. Right now all I'm trying to do is
request the serial number and read the response. I just need to get
communication between a Raspberry Pi and the device working. I have used
the software on a Windows 7 machine along with a USB sniffer to verify the
commands and endpoint address were correct.

This is the program;

import usb.core

import usb.util

import sys

dev = usb.core.find(idVendor=0x130c, idProduct=0x0001)

if dev is None:

raise ValueError('Device not found')

dev.set_configuration()

print "Connected to " + str(dev)

QS = '0x51,0x53,0x0D'   #Call for Serial number

dev.write(0x02,QS,0,0)

ret = dev.read(0x82,0x0040,0,1000)

sret=''.join([chr(x) for x in ret])

print "Return Raw: ",ret

print "Return : ", sret

(End of program)

This is the error I get when I run the program:

Python 2.7.3 (default, Mar 18 2014, 05:13:23)

[GCC 4.6.3] on linux2

Type "copyright", "credits" or "license()" for more information.

>>> ================================ RESTART
================================

>>>

Connected to <usb.core.Device object at 0x75176030>

Traceback (most recent call last):

  File "/home/pi/qspSLM.py", line 18, in <module>

    ret = dev.read(0x82,0x0040,0,1000)

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 638, in
read

    self.__get_timeout(timeout)

  File "/usr/local/lib/python2.7/dist-packages/usb/_debug.py", line 52, in
do_trace

    return f(*args, **named_args)

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb10.py",
line 493, in bulk_read

    timeout)

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb10.py",
line 593, in __read

    timeout))

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb10.py",
line 357, in _check

    raise USBError(_str_error[retval.value])

USBError: Operation timed out

>>>

The device has responded twice, both times it was the code that the return
value requested was invalid.

If anyone can help shed light on why this is timing out I would appreciate
it.

Re: [pyusb-users] pyusb on Windows

[Wander L. C. <wan...@gm...>]

2015-05-27 18:12 GMT-03:00 UNIVERSAL PHONE <uni...@gm...>:
> Hi,
>
>
>
> When i used pyusb with Python on Windows (i have installed libusb1-1.4.0), i
> have this error:
>
>
> ValueError: No backend available
>
>
>
> What must i do ?
>
> So on libusb-1.0.19 version, there are no "setup.py" file ??
>
>

libusb Windows binaries can be found at libusb website [1]

For libusb support, however, I recommend the libusb mailing list.

[1] http://libusb.info/

>
> Thks
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>



-- 
Best Regards,
Wander Lairson Costa

[pyusb-users] pyusb on Windows

[UNIVERSAL P. <uni...@gm...>]

Hi,



When i used pyusb with Python on Windows (i have installed libusb1-1.4.0),
i have this error:


*ValueError: No backend available*



What must i do ?

So on libusb-1.0.19 version, there are no "setup.py" file ??



Thks

[pyusb-users] (no subject)

[UNIVERSAL P. <uni...@gm...>]

Hi,


I would like enable or disable a USB port, do you have example ?



Thks

Re: [pyusb-users] Windows

[Wander L. C. <wan...@gm...>]

2015-05-27 6:35 GMT-03:00 UNIVERSAL PHONE <uni...@gm...>:
> Hi!!!
>
>
>
> Can i use pyUSB on a Windows OS with python ?
>
>

You need either libusb [1] or libusb-win32 [2] installed first. Then
inside PyUSB source directory, type:
python setup.py install

Now just look at the tutorial [3] to learn how to use the API.

[1] http://www.libusb.info

[2] http://libusb-win32.sourceforge.net

[3] https://github.com/walac/pyusb/blob/master/docs/tutorial.rst

>
>
> Thks
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>



-- 
Best Regards,
Wander Lairson Costa

[pyusb-users] Windows

[UNIVERSAL P. <uni...@gm...>]

Hi!!!



Can i use pyUSB on a Windows OS with python ?




Thks

[pyusb-users] (no subject)

[UNIVERSAL P. <uni...@gm...>]

How to list USB device ?

Re: [pyusb-users] List device

[Wander L. C. <wan...@gm...>]

2015-05-25 13:20 GMT-03:00 UNIVERSAL PHONE <uni...@gm...>:
> How to list USB device ?
>

You can use the find function to discover your USB device. You might
want to read to tutorial [1] to discover the find function
capabilities.

[1] https://github.com/walac/pyusb/blob/master/docs/tutorial.rst


-- 
Best Regards,
Wander Lairson Costa

[pyusb-users] List device

[UNIVERSAL P. <uni...@gm...>]

How to list USB device ?

Re: [pyusb-users] How to handle Solaris's strange library location?

[Wander L. C. <wan...@gm...>]

2015-05-01 21:17 GMT-03:00 Chapman Flack <gh...@an...>:
> 2015-04-28 11:16:13 Wander Lairson Costa <wander.lairson@gm...>:
>>> Should that name just be added to the big list o' names already
>>> in libusb0.py _load_library()? Or check for sys.platform == 'sunos5'
>>> and define a different _load_library that knows the right path? Or
>>> some other approach?
>
>> Sorry, you commented this in the patch and I completely forgot
>> to answer it. I think the simplest solution would be to add it
>> to the list of candidates.
>
> Looking more closely, it wouldn't need added to the candidate list,
> because it's called libusb.so and "usb" is already a candidate. It
> would be found if it were in a more usual directory, but not in
> /usr/sfw/lib. I was working on Solaris 10; possibly Solaris 11 has
> moved it to solve that problem, as
> https://www.mail-archive.com/ope...@ma.../msg13077.html
> suggests.
>

This probably fixes the issue, but PyUSB needs to be fixed for Solaris
10 too (I think).

>> He doesn't necessarily need to rewrite the app in C, but he
>> can write a faster backend. I am not worried about optimization
>> right now, but guessing common paths seems like a smart and simple
>> optimization.
>
> I looked more at where the external processes he complained of get run,
> and sure enough, it's in ctypes.util.find_library. It /unconditionally/
> tries to run expensive stuff like gcc or objdump to "find" your argument,
> even if you pass a full path. (oh yes, another thing that wasn't working:
> the /usr/sfw/bin/gcc on solaris actually does know to look in /usr/sfw/lib,
> but it uses the Solaris ld. The ctypes.util.find_library code assumes GNU ld
> with a -t option to write all the found file names as it sees them, but -t
> to solaris ld means something else altogether.)
>

Well, maybe the issue lies on ctypes, and we could patch it to find
libraries in Solaris. I am not versed on Solaris, so what I am saying
might be bs.

> I don't really feel like also writing patches for ctypes, but I think it
> probably would be a good optimization here to just try a few common
> full paths before falling back to the ctypes.util.find_library. It might
> just plain work better, in addition to solving the whole startup delay
> issue that made that blogger think he had to port everything to C. :)
>

IMO, This kind of optimization should live in cypes, because all
applications using it will benefit of faster startup times. If Python
guys are not interested, I am.

> I'll think about how a patch would look....
>

I think a dictionary indexed by sys.platform, whose contents is a list
of well known directories to try load libusb from. This code should
live in the libloader module.


-- 
Best Regards,
Wander Lairson Costa

Re: [pyusb-users] what's the goal for earliest Python supported?

[Wander L. C. <wan...@gm...>]

2015-05-01 21:25 GMT-03:00 Chapman Flack <gh...@an...>:
> README.rst says >= 2.4, _interop.py says >= 2.3.
>

The initial goal for PyUSB was >= 2.3, but it turned out to be
infeasible. That code comes from that time, and it was never updated.

> Would you accept a patch that changed _interop to 2.4 and
> deleted the sorted() and groupby() alternative code?
> Or one that changed README to 2.3?
>

A patch cleaning things is more than welcome :D

> Just minor housekeeping, but happened to notice it.
>

Re: [pyusb-users] a dream of uniform serial-usb handling...

[Chapman F. <gh...@an...>]

21 Apr 2015 10:17:53 -0300 Wander Lairson Costa <wander.lairson@g...>:

> I am not very versed into pyserial and ftdi stuff. One question comes
> to my mind is: what's the advantage of moving stuff from pyserial to
> pyusb?

I might have needed to give a broader view first. I did not intend to
move anything from /pyserial/ to pyusb. Those two have a sort of equal,
independent relationship.

The use of pyserial is for any Python code that wants to use a serial
comm port. The code should be able to pass some provided string to
serial.serial_for_url() and get a Serial instance back, and use it.
Whether the actual port is a UART on the motherboard, or some tunneled-
over-IP thing, or a USB-to-serial chip with a driver in the kernel, or
a USB-to-serial chip with a driver built with pyusb. So pyserial is a
common API for serial ports whether they are USB or not.

Respectively, pyusb is a common API for USB devices whether they are
serial ports or not. :)

The only interdependency is that if somebody uses pyusb to write a driver
for a USB-to-serial chip, it ought to be written to supply a class that
derives from serial.Serial. And somehow, that driver needs to get called
when somebody passes a certain form of string to serial.serial_for_url().

Those two pieces of glue right now are in the package pyftdi.serialext.
But FTDI is only one brand of (perhaps not fully standard-class-compliant)
USB-to-serial chip, and package pyftdi is really a hardware-specific driver
for that chip ... all except for the subpackage pyftdi.serialext which is
/not/ specific to that chip. It's just the same glue code that any
pyusb-based USB-to-serial driver would have to duplicate in some form.
It's just that Emmanuel wrote it first, and put it in pyftdi. :)

It defines the useful base class UsbSerial that is both an instance
of serial.Serial and proxies a pyusb device. It also contains the code
to act as a protocol-scheme hook into serial.serial_for_url and
recognize strings that should be USB devices.

These are the pieces of code that I think could be hoisted up from
pyftdi and would reasonably be in pyusb for general use by pyftdi
and any other similar drivers for USB-to-serial chips from MCT or Prolific
or Cypress or whomever.

> I have an idea of providing an usb.classes package, which would ship
> modules for each USB standard class.

I like that idea. And if that existed, the package for class 02 would
reasonably be the right place for this common code.

I'm sure you've noticed how usb.org defines standard class protocols
and there are some devices that actually work that way, but others rush
to market and provide similar functionality but not with the standard-
defined protocol. For example (the first one I crashed into), the Audio
class defines a USB MIDI protocol, but manufacturers like Midiman make
USB-MIDI devices that work with their own strange protocol. Having a
driver for the standard class protocol is great because it will work with
any device that complies, but as soon as you attach one of the strange
devices you need its own strange driver code.

The same situation seems to exist for serial. There is a communications
class spec that defines a standard protocol, and if there were a pyusb
driver for that protocol, it would work with any compliant device (for
example, Cypress). I think it would be good if such a driver could be
developed, and even distributed as part of pyusb in the usb.classes package.

That would not end the need for strange nonstandard protocol drivers like
pyftdi, as long as strange chips like FTDI are being sold. I can imagine
a possible rule that only drivers for strict USB class specified protocols
might be part of pyusb in usb.classes, and drivers for non-class-compliant
hardware would remain in separate packages like pyftdi.

But it would make sense that usb.classes.communication (or whatever it
should be named) contains the common glue such as the proxy class derived
from Serial and the hook to intercept serial_for_url. The ideal would be
that if somebody had Python code that wanted a serial port, they could
pass argv[1] to serial_for_url() and get a usable Serial instance back,
whether the argument was /dev/ttyS0 or /dev/ttyUSB3 (in-kernel driver)
or something like usb://0x0683,0x1550/?drv=ftdi or usb://0x04b4,0x0003/
(which would be a Cypress chip and Just Work with the class standard
driver because Cypress implements the standard)....

Does that clarify the structure I had in mind?

-Chap

[pyusb-users] what's the goal for earliest Python supported?

[Chapman F. <gh...@an...>]

README.rst says >= 2.4, _interop.py says >= 2.3.

Would you accept a patch that changed _interop to 2.4 and
deleted the sorted() and groupby() alternative code?
Or one that changed README to 2.3?

Just minor housekeeping, but happened to notice it.

-Chap

Re: [pyusb-users] How to handle Solaris's strange library location?

[Chapman F. <gh...@an...>]

2015-04-28 11:16:13 Wander Lairson Costa <wander.lairson@gm...>:
>> Should that name just be added to the big list o' names already
>> in libusb0.py _load_library()? Or check for sys.platform == 'sunos5'
>> and define a different _load_library that knows the right path? Or
>> some other approach?

> Sorry, you commented this in the patch and I completely forgot
> to answer it. I think the simplest solution would be to add it
> to the list of candidates.

Looking more closely, it wouldn't need added to the candidate list,
because it's called libusb.so and "usb" is already a candidate. It
would be found if it were in a more usual directory, but not in
/usr/sfw/lib. I was working on Solaris 10; possibly Solaris 11 has
moved it to solve that problem, as
https://www.mail-archive.com/ope...@ma.../msg13077.html
suggests.

> He doesn't necessarily need to rewrite the app in C, but he
> can write a faster backend. I am not worried about optimization
> right now, but guessing common paths seems like a smart and simple
> optimization.

I looked more at where the external processes he complained of get run,
and sure enough, it's in ctypes.util.find_library. It /unconditionally/
tries to run expensive stuff like gcc or objdump to "find" your argument,
even if you pass a full path. (oh yes, another thing that wasn't working:
the /usr/sfw/bin/gcc on solaris actually does know to look in /usr/sfw/lib,
but it uses the Solaris ld. The ctypes.util.find_library code assumes GNU ld
with a -t option to write all the found file names as it sees them, but -t
to solaris ld means something else altogether.)

I don't really feel like also writing patches for ctypes, but I think it
probably would be a good optimization here to just try a few common
full paths before falling back to the ctypes.util.find_library. It might
just plain work better, in addition to solving the whole startup delay
issue that made that blogger think he had to port everything to C. :)

I'll think about how a patch would look....

-Chap

Re: [pyusb-users] How to handle Solaris's strange library location?

[Wander L. C. <wan...@gm...>]

2015-04-27 22:01 GMT-03:00 Chapman Flack <gh...@an...>:
> Hi,
>

Hi,

> I recently sent a patch so the ctypes structures would have
> the right sizes on Solaris (thanks for merging!), but I was
> not sure what would be the best way for the libusb0 backend
> to handle the strange location of the shared object on Solaris.
> It's /usr/sfw/lib/libusb.so.1
>
> Should that name just be added to the big list o' names already
> in libusb0.py _load_library()? Or check for sys.platform == 'sunos5'
> and define a different _load_library that knows the right path? Or
> some other approach?
>

Sorry, you commented this in the patch and I completely forgot to answer it.
I think the simplest solution would be to add it to the list of candidates.

> I also recently saw this blog post here:
> http://emergent.unpythonic.net/01330399156
>
> where somebody wrote a C port of a Python script that was
> using pyusb because it was too slow. The post says that the
> compiler, objdump, and ldconfig were getting run when the Python
> script started up. I don't see that when I run it (same script,
> but I modified it to pass a find_library lambda that just returns
> the Solaris library path). So maybe the only time those expensive
> external processes get run are during the library search? In that
> case, maybe it's good to hardcode the path when known ... or fall
> back to the expensive way if the hardcoded path isn't found.
>

He doesn't necessarily need to rewrite the app in C, but he can write
a faster backend.
I am not worried about optimization right now, but guessing common
paths seems like a smart and simple optimization.

> -Chap
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users



-- 
Best Regards,
Wander Lairson Costa

Re: [pyusb-users] pyusb-users Digest, Vol 79, Issue 1

[Emmanuel B. <ebl...@gm...>]

Foreword: Please do not reply to digest messages (or without editing
the subject), as tracking threads is quite difficult :-) Thanks.

> I understand. I think what I was proposing was less drastic: I think
> the UsbSerial class (and indeed the whole serialext package) is more
> general than just for FTDI chips, and would make more sense as a part
> of pyusb. Then all different USB-serial chip drivers, including pyftdi,
> could share it as common code.

I do not mind if some pyftdi code move to pyusb, but this is really up
to Wander.
I'm not sure it would really make sense though.

I'm sure nobody wants to move the UsbTools class: this code is crap (I
can write this as I wrote it :-) ).
The features it provides are definitely useful, as enumerating a full
USB bus topology takes so much time that it should be done as few
times as possible. However the way it is implemented is really ugly
(it was a quick and dirty hack that has not been removed) and
rewriting it is my todo list for years...
To sum up: rewrite it, do not import it if you really need it.

The only potential issue with licenses is the ftdi.py file. All other
ones do no need to use the LGPL v2 license.

Manu.

[pyusb-users] How to handle Solaris's strange library location?

[Chapman F. <gh...@an...>]

Hi,

I recently sent a patch so the ctypes structures would have
the right sizes on Solaris (thanks for merging!), but I was
not sure what would be the best way for the libusb0 backend
to handle the strange location of the shared object on Solaris.
It's /usr/sfw/lib/libusb.so.1

Should that name just be added to the big list o' names already
in libusb0.py _load_library()? Or check for sys.platform == 'sunos5'
and define a different _load_library that knows the right path? Or
some other approach?

I also recently saw this blog post here:
http://emergent.unpythonic.net/01330399156

where somebody wrote a C port of a Python script that was
using pyusb because it was too slow. The post says that the
compiler, objdump, and ldconfig were getting run when the Python
script started up. I don't see that when I run it (same script,
but I modified it to pass a find_library lambda that just returns
the Solaris library path). So maybe the only time those expensive
external processes get run are during the library search? In that
case, maybe it's good to hardcode the path when known ... or fall
back to the expensive way if the hardcoded path isn't found.

-Chap

[pyusb-users] AUTO: Guillaume Schatz is out of the office (returning 27.04.2015)

[Guillaume S. <Gui...@po...>]

I am out of the office until 27.04.2015.

I'll respond to your email when I return.
Best regards,
Guillaume



Note: This is an automated response to your message  "[pyusb-users]
pyusb-users Digest, Vol 79, Issue 1" sent on 26.04.2015 21:50:38.

This is the only notification you will receive while this person is away.

[pyusb-users] pyusb-users Digest, Vol 79, Issue 1

[Chapman F. <gh...@an...>]

On Sun, 19 Apr 2015 13:31:14 +0200, Emmanuel Blot <ebl...@gm...>
wrote:

> A quick note about the licensing scheme of pyftdi (and friends).
> Some parts are LGPL-licensed because I've initially developed cftdi on
> top of libftdi - a Python-to-C wrapper for libftdi, and used an API
> which is very close to libftdi, which is released as LGPL.
> ...
> I have no objection to move to MIT license the whole pyftdi
> package, I just do no want to deal with this licensing nightmare.

I understand. I think what I was proposing was less drastic: I think
the UsbSerial class (and indeed the whole serialext package) is more
general than just for FTDI chips, and would make more sense as a part
of pyusb. Then all different USB-serial chip drivers, including pyftdi,
could share it as common code.

In my first message I wondered whether pyusb wanted to grow beyond just
wrapping libusb, but then I read this in pyusb's README.rst:

> Until 0.4 version, PyUSB used to be a thin wrapper over libusb.
> With 1.0 version, things changed considerably. Now PyUSB is an
> API rich, backend neutral Python USB module easy to use.

That convinces me even more that for pyusb to absorb the serialext
common code and UsbSerial base class from pyftdi would make sense
all around.

I think everything in serialext already *is* BSD licensed, so that
much should be easy. The only sticking point is that it makes some
incidental use of UsbTools from the LGPL part of pyftdi. The most
significant thing used there is parse_url. Did you also derive
parse_url from something in libftdi? I just looked over the libftdi
API and I didn't see something similar.

If parse_url was something you added, then maybe it is not a
problem for you to BSD license it to match the serialext code,
and it could also be raised to the status of something more
general in pyusb, where it could unify the way you specify a
device whether pyftdi or something else is the driver.

In fact, if we could do that, it might be worth thinking out
a url scheme that applies even to non-serial USB devices. I was
just setting something up recently to talk to a device that needs
only control transfers, not a whole serial interface, and it would
be nice to be able to specify that device as a URL also.

I'm only beginning to think about what a general usb url scheme
might look like, so take this as brainstorming, but maybe the
'scheme' portion should just be 'usb://' and I could pass something
like usb://0x067b:0x2303 as an argument to a script that just does
a pyusb device lookup and a control transfer.  Or if I have a script
that expects some kind of serial port and uses pyserial. I could
pass it /dev/ttyS0 or /dev/ttyUSB0 if the kernel driver is in place,
or usb://0x0683:0x1550?driver=ftdi and it gets a Serial instance in
every case and Just Works.

If the url scheme gets generalized a bit away from what's now in
pyftdi, maybe that also moots the license question around the existing
parse_url. But perhaps it is still good to BSD license the existing
parse_url if that is possible, just so there is less to worry about.

What do you think?
-Chap

Re: [pyusb-users] a dream of uniform serial-usb handling...

[Wander L. C. <wan...@gm...>]

Hi,

I am not very versed into pyserial and ftdi stuff. One question comes
to my mind is: what's the advantage of moving stuff from pyserial to
pyusb?
I have an idea of providing an usb.classes package, which would ship
modules for each USB standard class. But I didn't elaborate onto this
yet, it is currently only a vague idea. This might be what you want
here.

2015-04-19 8:31 GMT-03:00 Emmanuel Blot <ebl...@gm...>:
> On Sun, Apr 19, 2015 at 2:53 AM, Chapman Flack <gh...@an...> wrote:
>>> Reactions? Does my dream make sense to other pyusb-users readers?
>
> Hi,
>
> A quick note about the licensing scheme of pyftdi (and friends).
> Some parts are LGPL-licensed because I've initially developed cftdi on
> top of libftdi - a Python-to-C wrapper for libftdi, and used an API
> which is very close to libftdi, which is released as LGPL.
>
> At that time, I've been in touch with one of the authors of libftdi to
> ask whether I could use the same API (and some part of the code,
> although ported from C to Python) with a MIT-style license. To be
> honnest, LGPL is quite hard to master, LGPL with Python is - for me -
> nearly impossible to understand. For instance, what is "static
> linking" or "dynamic linking" in Python's world?
>
> Anyway, LGPL in this case was so fuzzy to interpret, and because I had
> no time to dig into the licensing "mess" I chose to keep the same
> license as libftdi.
>
> >From my point of view, I used to be in favor of GPL-like licenses as a
> hobbyist, but as a profesionnel developer, this license scheme keeps
> giving me headaches, even after some dedicated training...
>
> I always release new code under MIT / BSD 3 clauses. I wish I could
> release pyftdi under MIT license as well, if somebody who master
> licensing issues can tell whether it could collide or not with the
> distant roots of pyftdi, that is libftdi.
>
> To sum up: I have no objection to move to MIT license the whole pyftdi
> package, I just do no want to deal with this licensing nightmare. Any
> advice on this topic is very welcome.
>
> Cheers,
> Manu
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users



-- 
Best Regards,
Wander Lairson Costa

Re: [pyusb-users] a dream of uniform serial-usb handling...

[Emmanuel B. <ebl...@gm...>]

On Sun, Apr 19, 2015 at 2:53 AM, Chapman Flack <gh...@an...> wrote:
>> Reactions? Does my dream make sense to other pyusb-users readers?

Hi,

A quick note about the licensing scheme of pyftdi (and friends).
Some parts are LGPL-licensed because I've initially developed cftdi on
top of libftdi - a Python-to-C wrapper for libftdi, and used an API
which is very close to libftdi, which is released as LGPL.

At that time, I've been in touch with one of the authors of libftdi to
ask whether I could use the same API (and some part of the code,
although ported from C to Python) with a MIT-style license. To be
honnest, LGPL is quite hard to master, LGPL with Python is - for me -
nearly impossible to understand. For instance, what is "static
linking" or "dynamic linking" in Python's world?

Anyway, LGPL in this case was so fuzzy to interpret, and because I had
no time to dig into the licensing "mess" I chose to keep the same
license as libftdi.

>From my point of view, I used to be in favor of GPL-like licenses as a
hobbyist, but as a profesionnel developer, this license scheme keeps
giving me headaches, even after some dedicated training...

I always release new code under MIT / BSD 3 clauses. I wish I could
release pyftdi under MIT license as well, if somebody who master
licensing issues can tell whether it could collide or not with the
distant roots of pyftdi, that is libftdi.

To sum up: I have no objection to move to MIT license the whole pyftdi
package, I just do no want to deal with this licensing nightmare. Any
advice on this topic is very welcome.

Cheers,
Manu

[pyusb-users] AUTO: Guillaume Schatz is out of the office (returning 20.04.2015)

[Guillaume S. <Gui...@po...>]

I am out of the office until 20.04.2015.

I'll respond to your email when I return.
Best regards,
Guillaume



Note: This is an automated response to your message  "[pyusb-users] a dream
of uniform serial-usb handling..." sent on 19.04.2015 02:53:17.

This is the only notification you will receive while this person is away.

[pyusb-users] a dream of uniform serial-usb handling...

[Chapman F. <gh...@an...>]

Hi, I'm new to pyusb, thinking I have an idea to propose for how
uniformly serial and usb support in Python could be handled ... it
started with this sort of dream vision:

1. I have this gizmo that once upon a time had an old-fashioned 232
   serial interface to the computer. I can talk to it in Python:

   import serial
   giz = serial.serial_for_url(sys.argv[1])  # caller passes /dev/ttyS0

2. But that was then. These days it's the same gizmo with a
   USB-to-serial chip glued on the front. I'd like that to change my
   code as little as possible - maybe even not at all except for what
   the caller sends as argv[1].

   Under the hood a few different things could be going on:

2a. My kernel has a driver for that USB-to-serial chip, and makes a
    native device node.

    import serial
    giz = serial.serial_for_url(sys.argv[1])
    # caller passes /dev/serial/by-id/usb-0683_1550-if01-port0

2b. Maybe the kernel doesn't have a specific driver for that chip, but
    the chip has the right communications USB class and the kernel's
    usbserial generic driver might work with it. Same native device node
    gets created, so nothing changes in Python code, not even the device
    name.

2c. Instead of using an in-kernel driver, maybe pyusb is around and the
    chip is from FTDI...
    import serial
    import ftdi.serialext # ?? see more dream below
    giz = serial.serial_for_url(sys.argv[1])
    # caller passes ftdi://0x0683:0x1550/2

2d. Maybe the chip's an MCT instead? (caution, science fiction ahead)
    import serial
    giz = serial.serial_for_url(sys.argv[1])
    # caller passes mct://0x0711:0x0210/1

2e. Could there be a generic communications-USB-class driver, like the
    one the linux kernel has? (Also science fiction at the moment.)
    import serial
    giz = serial.serial_for_url(sys.argv[1])
    # caller passes usb://0x0683:0x1550/2

Ok, waking up from the dream ....

The current state of things is almost where it could allow all the above
to work.

- pyserial already provides serial_for_url() that can open a native
  serial device node or a "url" with extensible schemes via
  protocol_handler_packages. It already provides a SerialBase class and
  several implementations.

- There's already a UsbSerial base class that extends SerialBase and is
  used as a mixin for the pyftdi driver allowing it to be used as a
  pyserial driver. This should work for other USB-to-serial drivers
  (prolific, mct, whatever) too, or a generic communications-USB-class
  driver.

- That UsbSerial class, and the rest of the 'serialext' package, was
  contributed to pyftdi by Emmanuel Blot, but maybe pyftdi isn't the
  best place for it, because it could be a base mixin for many different
  USB-serial driver protocols and ftdi is just one specific one.

- Maybe it would make sense if pyftdi.serialext became pyusb.serialext
  instead? It is BSD-licensed (unlike the rest of the code in pyftdi,
  which carries LGPL headers) so that much should be a comfortable fit
  with pyusb.

- That way, any Python driver for a USB-serial chip would probably
  import pyusb (as it likely would anyway) and extend UsbSerial.

- Moving serialext would require Emmanuel Blot's agreement for pyftdi,
  and for a while pyftdi would probably have to do try: import
  pyusb.serialext; except ImportError: import pyftdi.serialext; to work
  in old and new cases.

- UsbSerial does import some UsbTools code from pyftdi proper (LGPL),
  most significantly parse_url, which is useful. It would be good to
  have one url-parsing scheme applicable across any USB-serial drivers,
  not just as part of pyftdi. Maybe Emmanuel could be approached about
  allowing BSD licensing for usbtools.py?

- At the moment there isn't a generic,
  don't-care-what-the-chip-is-as-long-as-I-can-bulk-read-write-it
  pure-pyusb driver like the usbserial generic one in the linux kernel.
  I might be interested enough to try writing one at some point. Maybe
  such a generic usb-serial driver would also be at home within pyusb?
  I realize both of these proposals turn pyusb into something slightly
  more than a ctypes wrapper on libusb. Maybe that's not desired, and
  there should just be a package usbserial in its own right, with
  relationships like

      pyserial                      pyusb
         |                            |
	 +--------------+-------------+
	                |
	            serialusb
	  (UsbSerial base class,
           generic USB-class-based driver)
	                |
	+-------+-------+------------------...
        |       |
      pyftdi    other specific USB-serial chip drivers...


On the other hand, if there is no objection to growing pyusb a little
bit beyond wrapping libusb, that would save creating another separate
package.

Reactions? Does my dream make sense to other pyusb-users readers?

Thanks,
Chapman Flack

Re: [pyusb-users] Question About Waiting for Prompts for the USB Device

[Kyle D. <kd...@lt...>]

Hi Wander,

Serial number is not what I'm looking for. The android phone will be
running an app with 3 buttons. I want my code to run and then reach a
certain point and then wait for the button prompt on the app which will
send some message. If it's the correct message I'll continue with my code,
otherwise it'll send an error. I'm just confused at how sending and
receiving messages works.

On Sun, Mar 29, 2015 at 12:46 PM, Wander Lairson Costa <
wan...@gm...> wrote:

> 2015-03-29 12:42 GMT-03:00 Kyle Dotter <kd...@lt...>:
> > Currently I have a program that takes the serial number from an android
> > phone automatically and saves it to a certain list. However, I don't want
> > this process to be automated. There's an android app being written to go
> > with this program and we want there to be a button that the user has to
> > press in order for it to continue with the program.  I'm confused about
> how
> > I am actually receiving messages from the phone, however. I've looked at
> the
> > tutorial and I'm wondering if it'd be as easy as just having a read
> command?
> > Something like
> >
> > message = <read device USB>
> > if message = <whatever I'm expecting, defined by the app>
> > <continue if good, keep waiting and checking if not>
> >
> > Is this doable? I'm not the best with python and this usb communication
>
> Hi,
>
> If you are talking about the USB serial number, the device object has
> a property called 'serial_number' that returns what you want.
>
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> > sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for
> > all
> > things parallel software development, from weekly thought leadership
> blogs
> > to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > pyusb-users mailing list
> > pyu...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyusb-users
> >
>
>
>
> --
> Best Regards,
> Wander Lairson Costa
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>