PyUSB

2011/1/4 Emmanuel Blot <eblot.ml@...>:
> Hello,
>
> Did anyone succeed running pyusb (or even libusb...) under Windows ?
>
> I've tried on Windows XP 32-bit the following combinations, without any success:
>
>  1. Python 2.6.5/Cygwin 1.7, libusb-win32
>  2. Python 2.6.5/Cygwin 1.7, libusb-1.0.5+git
>  3. Python 2.6.5/Cygwin 1.7, libusb-1.0.7+git
>  4. Python 2.7.1, libusb-1.0.8 (latest binaries)
>
> I got various results, from "Segmentation Fault" to "No backend
> available" or even "Error: Operation not supported or unimplemented on
> this platform"
>
>  * "Segmentation fault" is produced with Cygwin and libusb-win32.
> Another variant with this combination is the sudden death of the
> Python interpreter, with no error message, back to the infamous CMD
> prompt...
>  * "No backend available" is produced with Cygwin and libusb-1.0.x, it
> seems that CDLL() find the proper library ('cygusb-1.0.dll' *), but
> sees no symbols in it:
>   * hhasattr(l, 'libusb_init') fails,
>   * lib.libusb_set_debug does the same
>  * "Error: Operation not supported or unimplemented on this platform"
> is "performed" with the native Python 2.7.1 interpreter (no Cygwin)
>
> It seems that using libusb on Windows is more complex than on any
> other platform (no kidding!, the opposite way would have been
> surprising...).
> I have not installed WinUSB stuff as recommended here:
> http://libusb.org/wiki/winusb_driver_installation, as I already
> installed the native Windows drivers for the USB device.
>
> Any help would be greatly appreciated, I guess I miss something
> obvious with this platform,
>
Cygwin is still problematic. I have tested alpha 1 in Windows 7 32
bits with both libusb 1.0 and libusb-win32. Using libusb (either 1.0
or libusb-win32) is not as straightforward in Windows as in other
platforms. It requests a device driver for your peripheral be running
(quite opposite from others platforms, where you need to detach the
device driver). libusb 1.0 uses WinUSB, which I am not sure is
available in Windows XP (I guess so, you might find some info in the
libusb.org website), and libusb-win32 has its own device driver, which
I am sure runs on Windows XP.

Anyway, you have to install the device driver for your peripheral.
Both libraries have tools to make this task easier, please check the
projects respective websites for details.

Best regards,
Wander

> libusb 1.0 uses WinUSB, which I am not sure is
> available in Windows XP (I guess so, you might find some info in the
> libusb.org website)

It seems it is supported since WinXP SP2:
  http://msdn.microsoft.com/en-us/library/ff540196.aspx
but some specific files need to be installed.
I missed this part... I'll try tomorrow with Windows 7.

> and libusb-win32 has its own device driver, which
> I am sure runs on Windows XP.

Unfortunately, it makes the Cygwin Python interpreter to crash on my machine.

Have you run the tests with a native Python interpreter or with the Cygwin port?
I'd like to stick to the tested configuration for now.

> Anyway, you have to install the device driver for your peripheral.

This is what I did: I've installed the D2XX Windows drivers (latest
release) available from the FTDI web site.
My understanding is that for libusb-1.0 at least, if these original
drivers are installed, there's no need to install another device
driver. I'll double-check

Thanks for your help,
Manu

Happy New Year, All,

Is there a function allowing disconnection of a USB device once finished a pair of write/read? Although more write/read pairs will be requested later on, I prefer to re-establish the connection as needed.

I used dev=usb.core.find() to connect a printer and was able to write/read to it. Do anyone know if there is a function under dev can close the connection?

Thanks,
Charlie

On Wed, Jan 5, 2011 at 3:19 AM, Emmanuel Blot <eblot.ml@...> wrote:
>> Anyway, you have to install the device driver for your peripheral.
>
> This is what I did: I've installed the D2XX Windows drivers (latest
> release) available from the FTDI web site.
> My understanding is that for libusb-1.0 at least, if these original
> drivers are installed, there's no need to install another device
> driver. I'll double-check

No you have to install WinUSB driver to use libusb-1.0 Windows.
Right now it only supports WinUSB and HID backend. Since
your device is not an HID device, you have to install WinUSB
driver in order to use libusb-1.0 Windows backend.

You can use Zadig (GUI based) to install WinUSB driver for
your device.
http://libusb.org/wiki/windows_backend


-- 
Xiaofan

2011/1/4 Emmanuel Blot <eblot.ml@...>:
>> libusb 1.0 uses WinUSB, which I am not sure is
>> available in Windows XP (I guess so, you might find some info in the
>> libusb.org website)
>
> It seems it is supported since WinXP SP2:
>  http://msdn.microsoft.com/en-us/library/ff540196.aspx
> but some specific files need to be installed.
> I missed this part... I'll try tomorrow with Windows 7.
>
>> and libusb-win32 has its own device driver, which
>> I am sure runs on Windows XP.
>
> Unfortunately, it makes the Cygwin Python interpreter to crash on my machine.
>
Cygwin is still unsupported. I've given just a shallow look on Cygwin,
but it feels like it just has the static versions of libusb 1.0 and
libusb-win32.

> Have you run the tests with a native Python interpreter or with the Cygwin port?
> I'd like to stick to the tested configuration for now.
>
>> Anyway, you have to install the device driver for your peripheral.
>
> This is what I did: I've installed the D2XX Windows drivers (latest
> release) available from the FTDI web site.
> My understanding is that for libusb-1.0 at least, if these original
> drivers are installed, there's no need to install another device
> driver. I'll double-check
>
libusb 1.0 needs WinUSB driver and libusb-win32 needs the libusb0.sys
driver. With libusb-win32, you can install its driver as a filter
driver on top of the current driver of your device, but it is not the
recommended way.


-- 
Best Regards,
Wander Lairson Costa
LCoN - Laboratório de Computação Natural - Natural Computing Laboratory
(http://www.mackenzie.com.br/lcon.html)
Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)
Faculdade de Computação e Informática (FCI)
Universidade Presbiteriana Mackenzie - SP - Brazil

2011/1/4 Chu, Charlie (Chia-Lin, SanDiego) <charlie.chu@...>:
> Happy New Year, All,
>
> Is there a function allowing disconnection of a USB device once finished a pair of write/read? Although more write/read pairs will be requested later on, I prefer to re-establish the connection as needed.
>
> I used dev=usb.core.find() to connect a printer and was able to write/read to it. Do anyone know if there is a function under dev can close the connection?
>
Well, there is no "concept" of device connection either in USB spec or
in PyUSB. What we have is PyUSB having some internal resources
allocated (device opening, interface claiming, etc), which can be
relinquished using the usb.util.dispose_resources function. That's it.

-- 
Best Regards,
Wander Lairson Costa
LCoN - Laboratório de Computação Natural - Natural Computing Laboratory
(http://www.mackenzie.com.br/lcon.html)
Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)
Faculdade de Computação e Informática (FCI)
Universidade Presbiteriana Mackenzie - SP - Brazil

> Cygwin is still unsupported. I've given just a shallow look on Cygwin,
> but it feels like it just has the static versions of libusb 1.0 and
> libusb-win32.

The dynamic libraries (cygusb*.dll) are located in /usr/bin/, not in /usr/lib/
http://cygwin.com/packages/libusb1.0/libusb1.0-1.0.7+gitbd62c472-1

> libusb 1.0 needs WinUSB driver and libusb-win32 needs the libusb0.sys
> driver. With libusb-win32, you can install its driver as a filter
> driver on top of the current driver of your device, but it is not the
> recommended way.

Ok, I'll try once again under Windows 7, with the native Python interpreter.

Thanks,
Manu

2011/1/5 Emmanuel Blot <eblot.ml@...>:
>> Cygwin is still unsupported. I've given just a shallow look on Cygwin,
>> but it feels like it just has the static versions of libusb 1.0 and
>> libusb-win32.
>
> The dynamic libraries (cygusb*.dll) are located in /usr/bin/, not in /usr/lib/
> http://cygwin.com/packages/libusb1.0/libusb1.0-1.0.7+gitbd62c472-1
>
So, maybe it is just a matter of adding /usr/bin for library search
path. Going to check that when have some time...

-- 
Best Regards,
Wander Lairson Costa
LCoN - Laboratório de Computação Natural - Natural Computing Laboratory
(http://www.mackenzie.com.br/lcon.html)
Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)
Faculdade de Computação e Informática (FCI)
Universidade Presbiteriana Mackenzie - SP - Brazil

> So, maybe it is just a matter of adding /usr/bin for library search
> path. Going to check that when have some time...

AFAICT from my yesterday unsuccessful attempts, ctypes (cygwin /
Python 2.6.5) automatically find the cygusb-1.0.*dll libraries from
/usr/bin, the dedicated "cygwin" case in pyusb-1.0.0a1/libusb10 is not
even used.

Cheers,
Manu

On Wed, Jan 5, 2011 at 5:21 PM, wander.lairson <wander.lairson@...> wrote:
> Cygwin is still unsupported. I've given just a shallow look on Cygwin,
> but it feels like it just has the static versions of libusb 1.0 and
> libusb-win32.

Once upon a time, I got Cygwin to work with pyusb and
libusb-1.0 (build it from source, the Cygwin package is too old).
But I just tried it under Windows 7 and it does not seem to work.
I will check again later.

Plain Python 2.6 Windows works fine.

-- 
Xiaofan

> Plain Python 2.6 Windows works fine.

I've installed the driver with Zadig for the USB device, which is connected.
Before copying the DLL, I got the "No backend available" error, so I
guess that now the DLL is found.

I've copied
   \libusb_2010.12.10\MS64\dll\libusb-1.0.dll into System32, and
   \libusb_2010.12.10\MS32\dll\libusb-1.0.dll into SystemWOW64.
Am I right or should I move the DLL elsewhere ?

I still get the following error:
  Error: Operation not supported or unimplemented on this platform
on Windows 7 64 bits, using plain Python 2.7.1 64-bit.

I also install Python 2.6.6 32-bit on the same W7/64 machine.
And I get the exact same error:
  Error: Operation not supported or unimplemented on this platform
on Windows 7 64 bits, using plain Python 2.6.6 32-bit.

Any way I could track down the issue?

Thanks,
Manu

On Wed, Jan 5, 2011 at 10:45 PM, Emmanuel Blot <eblot.ml@...> wrote:
> I've copied
>   \libusb_2010.12.10\MS64\dll\libusb-1.0.dll into System32, and
>   \libusb_2010.12.10\MS32\dll\libusb-1.0.dll into SystemWOW64.
> Am I right or should I move the DLL elsewhere ?

This is correct.

> I still get the following error:
>  Error: Operation not supported or unimplemented on this platform
> on Windows 7 64 bits, using plain Python 2.7.1 64-bit.

I have not tried to use 64bit Python. But I am using
64bit Windows 7 and 32bit Python 2.6.5.

> I also install Python 2.6.6 32-bit on the same W7/64 machine.
> And I get the exact same error:
>  Error: Operation not supported or unimplemented on this platform
> on Windows 7 64 bits, using plain Python 2.6.6 32-bit.
>
> Any way I could track down the issue?
>

I will check again.



-- 
Xiaofan

Thanks. I think that's what I wanted.

Best regards,
Charlie

-----Original Message-----
From: wander.lairson [mailto:wander.lairson@...] 
Sent: Wednesday, January 05, 2011 1:25 AM
To: pyusb-users@...
Subject: Re: [pyusb-users] Disconnecting USB

2011/1/4 Chu, Charlie (Chia-Lin, SanDiego) <charlie.chu@...>:
> Happy New Year, All,
>
> Is there a function allowing disconnection of a USB device once finished a pair of write/read? Although more write/read pairs will be requested later on, I prefer to re-establish the connection as needed.
>
> I used dev=usb.core.find() to connect a printer and was able to write/read to it. Do anyone know if there is a function under dev can close the connection?
>
Well, there is no "concept" of device connection either in USB spec or
in PyUSB. What we have is PyUSB having some internal resources
allocated (device opening, interface claiming, etc), which can be
relinquished using the usb.util.dispose_resources function. That's it.

-- 
Best Regards,
Wander Lairson Costa
LCoN - Laboratório de Computação Natural - Natural Computing Laboratory
(http://www.mackenzie.com.br/lcon.html)
Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)
Faculdade de Computação e Informática (FCI)
Universidade Presbiteriana Mackenzie - SP - Brazil

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
pyusb-users mailing list
pyusb-users@...
https://lists.sourceforge.net/lists/listinfo/pyusb-users

2011/1/5 Xiaofan Chen <xiaofanc@...>:
> On Wed, Jan 5, 2011 at 5:21 PM, wander.lairson <wander.lairson@...> wrote:
>> Cygwin is still unsupported. I've given just a shallow look on Cygwin,
>> but it feels like it just has the static versions of libusb 1.0 and
>> libusb-win32.
>
> Once upon a time, I got Cygwin to work with pyusb and
> libusb-1.0 (build it from source, the Cygwin package is too old).
> But I just tried it under Windows 7 and it does not seem to work.
> I will check again later.
>
> Plain Python 2.6 Windows works fine.
>
Revision 89 fixed libusb-win32 under cygwin. I still have problems
with libusb-1.0 official cygwin build, it feels like there is no
symbol exported:

$ objdump.exe -T /usr/bin/cygusb-1.0.dll

/usr/bin/cygusb-1.0.dll:     file format pei-i386

objdump: /usr/bin/cygusb-1.0.dll: not a dynamic object
DYNAMIC SYMBOL TABLE:
no symbols

I haven't tried to compile libusb 1.0 from sources.

-- 
Best Regards,
Wander Lairson Costa
LCoN - Laboratório de Computação Natural - Natural Computing Laboratory
(http://www.mackenzie.com.br/lcon.html)
Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)
Faculdade de Computação e Informática (FCI)
Universidade Presbiteriana Mackenzie - SP - Brazil

On Sat, Jan 8, 2011 at 10:04 PM, wander.lairson
<wander.lairson@...> wrote:

> Revision 89 fixed libusb-win32 under cygwin. I still have problems
> with libusb-1.0 official cygwin build, it feels like there is no
> symbol exported:
>
> $ objdump.exe -T /usr/bin/cygusb-1.0.dll
>
> /usr/bin/cygusb-1.0.dll:     file format pei-i386
>
> objdump: /usr/bin/cygusb-1.0.dll: not a dynamic object
> DYNAMIC SYMBOL TABLE:
> no symbols
>
> I haven't tried to compile libusb 1.0 from sources.
>

Maybe this is not the real problem. It is the same for cygusb0.dll
(Cygwin libusb-win32).
mcuee@... ~
$ objdump -T /usr/bin/cygusb0.dll

/usr/bin/cygusb0.dll:     file format pei-i386

objdump: /usr/bin/cygusb0.dll: not a dynamic object
DYNAMIC SYMBOL TABLE:
no symbols

Plain Python under Windows 7 32bit.
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> import usb.backend.libusb10
>>> a=usb.backend.libusb10.get_backend()
>>> a
<usb.backend.libusb10._LibUSB object at 0x017A30D0>
>>>

Cygwin under Windows 7 32bit.

It seems to my Cygwin Ctypes does not have WinDLL.
I am not so sure if this is the problem. Last time I
rebuilt libusb-1.0 using cdecl, now it only supports
stdcall under Windows.

mcuee@... /cygdrive/d/work/pyusb/pyusb
$ python
Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> import usb.backend.libusb10
>>> a=usb.backend.libusb10.get_backend()
2011-01-10 20:28:33,067 ERROR:usb.backend.libusb10:Error loading libusb 1.0 back
end
Traceback (most recent call last):
  File "usb/backend/libusb10.py", line 601, in get_backend
    _setup_prototypes(_lib)
  File "usb/backend/libusb10.py", line 175, in _setup_prototypes
    lib.libusb_set_debug.argtypes = [c_void_p, c_int]
  File "/usr/lib/python2.6/ctypes/__init__.py", line 366, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python2.6/ctypes/__init__.py", line 371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'libusb_set_debug' not found (▒▒⌂)




-- 
Xiaofan

On Wed, Jan 5, 2011 at 9:30 PM, Xiaofan Chen <xiaofanc@...> wrote:
> Plain Python 2.6 Windows works fine.
>

Here is a run log under Windows 7 32bit. The firmware used
is Jan Axelson's Generic HID example. The firmware
loops back the HID input and output report.

D:\work\pyusb\pyusb>d:\Python26\python.exe
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> import usb.util
>>> dev = usb.core.find(idVendor=0x0925, idProduct=0x7001)
>>> dev.set_configuration()
>>> dev.write(1,'01',0)
3
>>> ret=dev.read(0x81,2,0,1000)
>>> sret=''.join([chr(x) for x in ret])
>>> sret
'01'

>>> dev.write(1,'ab',0)
3
>>> ret=dev.read(0x81,2,0,1000)
>>> sret=''.join([chr(x) for x in ret])
>>> sret
'ab'
>>>




-- 
Xiaofan

On Mon, Jan 10, 2011 at 8:41 PM, Xiaofan Chen <xiaofanc@...> wrote:

> It seems my Cygwin Ctypes does not have WinDLL.
> I am not so sure if this is the problem. Last time I
> rebuilt libusb-1.0 using cdecl, now it only supports
> stdcall under Windows.
>

It is indeed true under Cygwin.

mcuee@... ~
$ python
Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> import usb.util
>>> from ctypes import CDLL, WinDLL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name WinDLL
>>> c=CDLL('cygusb-1.0.dll')
>>> c.libusb_init(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/ctypes/__init__.py", line 366, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python2.6/ctypes/__init__.py", line 371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'libusb_init' not found (4▒▒⌂)
>>>



-- 
Xiaofan

2011/1/10 Xiaofan Chen <xiaofanc@...>:
> On Mon, Jan 10, 2011 at 8:41 PM, Xiaofan Chen <xiaofanc@...> wrote:
>
>> It seems my Cygwin Ctypes does not have WinDLL.
>> I am not so sure if this is the problem. Last time I
>> rebuilt libusb-1.0 using cdecl, now it only supports
>> stdcall under Windows.
>>
>
> It is indeed true under Cygwin.
>
Just wondering if libusb with stdcall under Cygwin is correct. If not,
should it be reported to libusb or cygwin guys?

-- 
Best Regards,
Wander Lairson Costa
LCoN - Laboratório de Computação Natural - Natural Computing Laboratory
(http://www.mackenzie.com.br/lcon.html)
Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)
Faculdade de Computação e Informática (FCI)
Universidade Presbiteriana Mackenzie - SP - Brazil

On Mon, Jan 10, 2011 at 9:24 PM, wander.lairson
<wander.lairson@...> wrote:
> 2011/1/10 Xiaofan Chen <xiaofanc@...>:
>> On Mon, Jan 10, 2011 at 8:41 PM, Xiaofan Chen <xiaofanc@...> wrote:
>>
>>> It seems my Cygwin Ctypes does not have WinDLL.
>>> I am not so sure if this is the problem. Last time I
>>> rebuilt libusb-1.0 using cdecl, now it only supports
>>> stdcall under Windows.
>>>
>>
>> It is indeed true under Cygwin.
>>
> Just wondering if libusb with stdcall under Cygwin is correct. If not,
> should it be reported to libusb or cygwin guys?
>

I will check with the libusb mailing list.


-- 
Xiaofan

On Mon, Jan 10, 2011 at 9:19 PM, Xiaofan Chen <xiaofanc@...> wrote:
> On Mon, Jan 10, 2011 at 8:41 PM, Xiaofan Chen <xiaofanc@...> wrote:
>
>> It seems my Cygwin Ctypes does not have WinDLL.
>> I am not so sure if this is the problem. Last time I
>> rebuilt libusb-1.0 using cdecl, now it only supports
>> stdcall under Windows.
>>
>
> It is indeed true under Cygwin.
>

Once I changed libusb.h to use cdecl calling convention, then
it seems to work. Right now I am having problems with
Cygwin libusb-1.0 (invalid handle) so I can not test it fully
but the dll loading will work.

mcuee@... /cygdrive/d/work/libusb1/win/cygwin/libusb-pbatard/examples
$ python
Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import CDLL, WinDLL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name WinDLL
>>> c=CDLL('cygusb-1.0.dll')
>>> c.libusb_init(None)
libusb:debug [libusb_init] created default context
libusb:debug [libusb_init]
libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation
libusb:debug [htab_create] libusb:debug [windows_clock_gettime_threaded] using 1
021 entries hash tablehires timer available (Frequency: 2539062 Hz)

libusb:debug [usbi_add_pollfd] add fd 3 events 1
0
>>> import usb.core
>>> import usb.util
>>> dev = usb.core.find(idVendor=0x0925, idProduct=0x7001)
libusb:debug [libusb_init] reusing default context
libusb:debug [libusb_get_device_list]
libusb:debug [windows_get_device_list] allocating new device for session [61]
libusb:debug [windows_get_device_list] allocating new device for session [1B1]
libusb:debug [get_api_type] driver(s): USBHUB
libusb:debug [get_api_type] matched driver name against HUB API
libusb:debug [windows_get_device_list] allocating new device for session [25E]
libusb:debug [get_api_type] driver(s): USBHUB
libusb:debug [get_api_type] matched driver name against HUB API
libusb:debug [windows_get_device_list] allocating new device for session [B5]
libusb:debug [windows_get_device_list] found existing device for session [25E]
libusb:debug [init_device] (bus: 2, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT
_HUB#4&278C294E&0'
libusb:debug [windows_get_device_list] found existing device for session [B5]
libusb:debug [init_device] (bus: 1, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT
_HUB20#4&7056C45&0'
libusb:debug [windows_get_device_list] allocating new device for session [2A1]
libusb:debug [init_device] found 1 configurations (active conf: 1)
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 55 bytes)
libusb:debug [init_device] (bus: 1, addr: 1, depth: 1, port: 5): '\\.\USB#VID_04
03&PID_CFF8#53T9XDR4'
libusb:debug [windows_get_device_list] allocating new device for session [23D]
libusb:debug [init_device] found 1 configurations (active conf: 1)
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 34 bytes)
libusb:debug [init_device] (bus: 2, addr: 5, depth: 1, port: 8): '\\.\USB#VID_04
5E&PID_00E1#5&207B166D&0&8'
libusb:debug [windows_get_device_list] allocating new device for session [24F]
libusb:debug [init_device] found 1 configurations (active conf: 1)
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 34 bytes)
libusb:debug [init_device] (bus: 2, addr: 2, depth: 1, port: 4): '\\.\USB#VID_04
6D&PID_C054#5&207B166D&0&4'
libusb:debug [windows_get_device_list] allocating new device for session [117]
libusb:debug [init_device] found 1 configurations (active conf: 1)
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 32 bytes)
libusb:debug [init_device] (bus: 2, addr: 1, depth: 1, port: 1): '\\.\USB#VID_05
8F&PID_9360#2004888'
libusb:debug [windows_get_device_list] allocating new device for session [1D0]
libusb:debug [init_device] found 1 configurations (active conf: 1)
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 41 bytes)
libusb:debug [init_device] (bus: 2, addr: 4, depth: 1, port: 7): '\\.\USB#VID_09
25&PID_7001#5&207B166D&0&7'
libusb:debug [windows_get_device_list] allocating new device for session [B7]
libusb:debug [init_device] found 1 configurations (active conf: 1)
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 32 bytes)
libusb:debug [init_device] (bus: 2, addr: 3, depth: 1, port: 6): '\\.\USB#VID_FF
FF&PID_0005#DEADC0DE'
libusb:debug [get_api_type] driver(s): USBCCGP
libusb:debug [get_api_type] matched driver name against Composite API
libusb:debug [windows_get_device_list] found existing device for session [2A1]
libusb:debug [get_api_type] driver(s): HIDUSB
libusb:debug [get_api_type] lower filter driver(s): DC3D
libusb:debug [get_api_type] matched driver name against HID API
libusb:debug [windows_get_device_list] found existing device for session [23D]
libusb:debug [get_api_type] driver(s): HIDUSB
libusb:debug [get_api_type] matched driver name against HID API
libusb:debug [windows_get_device_list] found existing device for session [24F]
libusb:debug [get_api_type] driver(s): USBSTOR
libusb:debug [windows_get_device_list] found existing device for session [117]
libusb:debug [get_api_type] driver(s): HIDUSB
libusb:debug [get_api_type] upper filter driver(s): LIBUSB0
libusb:debug [get_api_type] matched driver name against HID API
libusb:debug [windows_get_device_list] found existing device for session [1D0]
libusb:debug [get_api_type] driver(s): LIBUSB0
libusb:debug [windows_get_device_list] found existing device for session [B7]
libusb:debug [windows_get_device_list] unlisted ancestor for '\\.\HID#COMPROHIDD
EVICE&COL01#1&2D595CA7&0&0000' (non USB HID, newly connected, etc.) - ignoring
libusb:debug [windows_get_device_list] unlisted ancestor for '\\.\HID#COMPROHIDD
EVICE&COL02#1&2D595CA7&0&0001' (non USB HID, newly connected, etc.) - ignoring
libusb:debug [windows_get_device_list] unlisted ancestor for '\\.\HID#COMPROHIDD
EVICE&COL03#1&2D595CA7&0&0002' (non USB HID, newly connected, etc.) - ignoring
libusb:debug [windows_get_device_list] unlisted ancestor for '\\.\HID#COMPROHIDD
EVICE&COL04#1&2D595CA7&0&0003' (non USB HID, newly connected, etc.) - ignoring
libusb:debug [windows_get_device_list] unlisted ancestor for '\\.\HID#COMPROHIDD
EVICE&COL05#1&2D595CA7&0&0004' (non USB HID, newly connected, etc.) - ignoring
libusb:debug [windows_get_device_list] setting HID interface for [23D]:
libusb:debug [set_hid_interface] interface[0] = \\.\HID#VID_045E&PID_00E1&COL01#
6&E999C51&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [windows_get_device_list] setting HID interface for [23D]:
libusb:debug [set_hid_interface] interface[1] = \\.\HID#VID_045E&PID_00E1&COL02#
6&E999C51&0&0001#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [windows_get_device_list] setting HID interface for [24F]:
libusb:debug [set_hid_interface] interface[0] = \\.\HID#VID_046D&PID_C054#6&A6CC
B04&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [windows_get_device_list] setting HID interface for [1D0]:
libusb:debug [set_hid_interface] interface[0] = \\.\HID#VID_0925&PID_7001#6&22E6
8DE4&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [libusb_unref_device] destroy device 1.0
libusb:debug [libusb_unref_device] destroy device 2.0
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_unref_device] destroy device 2.255
libusb:debug [libusb_unref_device] destroy device 1.255
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 2.5
libusb:debug [libusb_unref_device] destroy device 2.2
libusb:debug [libusb_unref_device] destroy device 2.1
libusb:debug [libusb_unref_device] destroy device 2.3
>>> dev
<usb.core.Device object at 0x7fe152cc>



-- 
Xiaofan

On Wed, Jan 5, 2011 at 11:40 PM, Xiaofan Chen <xiaofanc@...> wrote:
> On Wed, Jan 5, 2011 at 10:45 PM, Emmanuel Blot <eblot.ml@...> wrote:
>> I've copied
>>   \libusb_2010.12.10\MS64\dll\libusb-1.0.dll into System32, and
>>   \libusb_2010.12.10\MS32\dll\libusb-1.0.dll into SystemWOW64.
>> Am I right or should I move the DLL elsewhere ?
>
> This is correct.
>
>> I still get the following error:
>>  Error: Operation not supported or unimplemented on this platform
>> on Windows 7 64 bits, using plain Python 2.7.1 64-bit.
>
> I have not tried to use 64bit Python. But I am using
> 64bit Windows 7 and 32bit Python 2.6.5.
>
>> I also install Python 2.6.6 32-bit on the same W7/64 machine.
>> And I get the exact same error:
>>  Error: Operation not supported or unimplemented on this platform
>> on Windows 7 64 bits, using plain Python 2.6.6 32-bit.
>>
>> Any way I could track down the issue?
>>
>
> I will check again.
>

Works for me.

Here is a simple run log under Windows 7 64bit and Python 2.7 64bit.

D:\work\pyusb\pyusb>c:\Python27\python.exe
Python 2.7 (r27:82525, Jul  4 2010, 07:43:08) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> import usb.util
>>> dev = usb.core.find(idVendor=0x0925, idProduct=0x7001)
>>> dev.set_configuration()
>>> dev.write(1,'py',0)
3
>>> ret=dev.read(0x81,2,0,1000)
>>> sret=''.join([chr(x) for x in ret])
>>> sret
'py'
>>>

And 32bit Python 2.6 under Windows 7 64bit.
D:\work\pyusb\pyusb>c:\Python26\python.exe
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> import usb.util
>>> dev = usb.core.find(idVendor=0x0925, idProduct=0x7001)
>>> dev.set_configuration()
>>> dev.write(1,'py',0)
3
>>> ret=dev.read(0x81,2,0,1000)
>>> sret=''.join([chr(x) for x in ret])
>>> sret
'py'


-- 
Xiaofan

On Mon, Jan 10, 2011 at 9:24 PM, wander.lairson
<wander.lairson@...> wrote:
> 2011/1/10 Xiaofan Chen <xiaofanc@...>:
>> On Mon, Jan 10, 2011 at 8:41 PM, Xiaofan Chen <xiaofanc@...> wrote:
>>
>>> It seems my Cygwin Ctypes does not have WinDLL.
>>> I am not so sure if this is the problem. Last time I
>>> rebuilt libusb-1.0 using cdecl, now it only supports
>>> stdcall under Windows.
>>>
>> It is indeed true under Cygwin.
>>
> Just wondering if libusb with stdcall under Cygwin is correct. If not,
> should it be reported to libusb or cygwin guys?
>

According to the Cygwin list, technically Cygwin Python
should be able to support stdcall (WinDLL) but it has
not been implemented.
http://cygwin.com/ml/cygwin/2011-01/msg00103.html

Pete Batard will change to use cdecl for his libusb-1.0
branch as the result of this.
http://libusb.6.n5.nabble.com/Cygwin-Python-Ctypes-and-libusb-1-0-stdcall-td3334825.html#a3337429

-- 
Xiaofan

2011/1/11 Xiaofan Chen <xiaofanc@...>:
> On Mon, Jan 10, 2011 at 9:24 PM, wander.lairson
> <wander.lairson@...> wrote:
>> 2011/1/10 Xiaofan Chen <xiaofanc@...>:
>>> On Mon, Jan 10, 2011 at 8:41 PM, Xiaofan Chen <xiaofanc@...> wrote:
>>>
>>>> It seems my Cygwin Ctypes does not have WinDLL.
>>>> I am not so sure if this is the problem. Last time I
>>>> rebuilt libusb-1.0 using cdecl, now it only supports
>>>> stdcall under Windows.
>>>>
>>> It is indeed true under Cygwin.
>>>
>> Just wondering if libusb with stdcall under Cygwin is correct. If not,
>> should it be reported to libusb or cygwin guys?
>>
>
> According to the Cygwin list, technically Cygwin Python
> should be able to support stdcall (WinDLL) but it has
> not been implemented.
> http://cygwin.com/ml/cygwin/2011-01/msg00103.html
>
> Pete Batard will change to use cdecl for his libusb-1.0
> branch as the result of this.
> http://libusb.6.n5.nabble.com/Cygwin-Python-Ctypes-and-libusb-1-0-stdcall-td3334825.html#a3337429
>
Thanks for the help and update.

--