Menu
▾
▴
pyusb-users — PyUSB users mailing list discussion
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
|
| 2008 |
Jan
(1) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(8) |
Jun
(4) |
Jul
|
Aug
|
Sep
(11) |
Oct
|
Nov
|
Dec
(20) |
| 2009 |
Jan
(16) |
Feb
(7) |
Mar
(9) |
Apr
(4) |
May
(6) |
Jun
(17) |
Jul
(3) |
Aug
(4) |
Sep
(5) |
Oct
(10) |
Nov
(16) |
Dec
|
| 2010 |
Jan
(22) |
Feb
(18) |
Mar
(9) |
Apr
(102) |
May
(29) |
Jun
(40) |
Jul
(80) |
Aug
(21) |
Sep
(47) |
Oct
(13) |
Nov
(19) |
Dec
(45) |
| 2011 |
Jan
(82) |
Feb
(20) |
Mar
(47) |
Apr
(25) |
May
(18) |
Jun
(24) |
Jul
(24) |
Aug
(47) |
Sep
(23) |
Oct
(22) |
Nov
(69) |
Dec
(20) |
| 2012 |
Jan
(56) |
Feb
(42) |
Mar
(43) |
Apr
(27) |
May
(18) |
Jun
(11) |
Jul
(61) |
Aug
(19) |
Sep
(13) |
Oct
(49) |
Nov
(32) |
Dec
(37) |
| 2013 |
Jan
(46) |
Feb
(14) |
Mar
(13) |
Apr
(20) |
May
(20) |
Jun
(3) |
Jul
(19) |
Aug
(7) |
Sep
(4) |
Oct
(33) |
Nov
(7) |
Dec
(15) |
| 2014 |
Jan
(5) |
Feb
(21) |
Mar
(3) |
Apr
(3) |
May
(30) |
Jun
(1) |
Jul
(30) |
Aug
(2) |
Sep
(22) |
Oct
(14) |
Nov
(22) |
Dec
(6) |
| 2015 |
Jan
(7) |
Feb
(4) |
Mar
(16) |
Apr
(9) |
May
(17) |
Jun
(28) |
Jul
(3) |
Aug
(18) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(3) |
| 2016 |
Jan
(15) |
Feb
(18) |
Mar
(12) |
Apr
(14) |
May
(15) |
Jun
(3) |
Jul
(3) |
Aug
(42) |
Sep
(24) |
Oct
(6) |
Nov
(5) |
Dec
(6) |
| 2017 |
Jan
(6) |
Feb
(2) |
Mar
(12) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(7) |
| 2018 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
|
May
(10) |
Jun
(20) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(20) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(9) |
Dec
|
| 2020 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(5) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(8) |
Dec
(2) |
| 2021 |
Jan
(16) |
Feb
(1) |
Mar
|
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
(7) |
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joe <te...@jo...> - 2016-09-15 09:56:07
|
Am 15.09.2016 um 11:48 schrieb Joe: > What's the best method to install it? My test machine runs under Win 10 > Version 1607 (64 Bit) with Python. Didn't get it running with the infos > from https://pypi.python.org/pypi/hid/0.1.1 > Regards - Joe > > ------------------------------------------------------------------------------ > _______________________________________________ > pyusb-users mailing list > pyu...@li... > https://lists.sourceforge.net/lists/listinfo/pyusb-users Sorry, Python version number was not mentioned. We are using Python 3.5.2 |
|
From: Joe <te...@jo...> - 2016-09-15 09:48:22
|
Am 15.09.2016 um 09:01 schrieb Nicolas Pinault: > Under Windows, USB HID devices have to be accessed through the HID API, > not the USB API. This means you can't use PyUSB with HID devices under > Windows. > > Try this package : https://pypi.python.org/pypi/hid/0.1.1 > > Nicolas > > ------------------------------------------------------------------------------ > _______________________________________________ > pyusb-users mailing list > pyu...@li... > https://lists.sourceforge.net/lists/listinfo/pyusb-users What's the best method to install it? My test machine runs under Win 10 Version 1607 (64 Bit) with Python. Didn't get it running with the infos from https://pypi.python.org/pypi/hid/0.1.1 Regards - Joe |
|
From: Joe <te...@jo...> - 2016-09-15 08:52:44
|
Am 15.09.2016 um 09:01 schrieb Nicolas Pinault: > Under Windows, USB HID devices have to be accessed through the HID API, > not the USB API. This means you can't use PyUSB with HID devices under > Windows. > > Try this package : https://pypi.python.org/pypi/hid/0.1.1 > > Nicolas > > ------------------------------------------------------------------------------ > _______________________________________________ > pyusb-users mailing list > pyu...@li... > https://lists.sourceforge.net/lists/listinfo/pyusb-users Very interesting info, Nicolas. I'll try it. Joe |
|
From: Nicolas P. <nic...@aa...> - 2016-09-15 07:38:53
|
Under Windows, USB HID devices have to be accessed through the HID API, not the USB API. This means you can't use PyUSB with HID devices under Windows. Try this package : https://pypi.python.org/pypi/hid/0.1.1 Nicolas |
|
From: Joe <te...@jo...> - 2016-09-14 21:59:24
|
I am trying to get data from the usb interface of an UT61B DMM.
That's my test program:
import usb.util
import usb.backend.libusb1
def Gosub():
failures = 0
failuresmaximum = 48
dev = usb.core.find (idVendor = 0x1a86, idProduct = 0xe008) #
Multimeter UT61B
if dev == None:
print ('Multimeter UT61B not found')
else:
print ('Multimeter UT61B was found')
print ('dev:\n' + str (dev) + '\n')
dev.set_configuration ()
ep = dev [0] [0,0] [0]
if ep == None:
print ('ep is None')
else:
data = None
while failures < failuresmaximum:
try:
data = dev.read (ep.bEndpointAddress, ep.wMaxPackeSize)
print ('Success. len (date): ' + len (date))
except:
failures += 1
print ('Failures: ' + str (failures))
if data == None:
print ('No data read')
else:
for ss in data:
print (str (ss))
print ('Starting')
Gosub ()
print ('Ready.-')
I get this output:
Starting
Multimeter UT61B was found
dev:
DEVICE ID 1a86:e008 on Bus 004 Address 002 =================
bLength : 0x12 (18 bytes)
bDescriptorType : 0x1 Device
bcdUSB : 0x100 USB 1.0
bDeviceClass : 0x0 Specified at interface
bDeviceSubClass : 0x0
bDeviceProtocol : 0x0
bMaxPacketSize0 : 0x8 (8 bytes)
idVendor : 0x1a86
idProduct : 0xe008
bcdDevice : 0x1200 Device 18.0
iManufacturer : 0x1 WCH.CN
iProduct : 0x2 USB to Serial
iSerialNumber : 0x0
bNumConfigurations : 0x1
CONFIGURATION 1: 100 mA ==================================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x2 Configuration
wTotalLength : 0x29 (41 bytes)
bNumInterfaces : 0x1
bConfigurationValue : 0x1
iConfiguration : 0x4 Error Accessing String
bmAttributes : 0x80 Bus Powered
bMaxPower : 0x32 (100 mA)
INTERFACE 0: Human Interface Device ====================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x4 Interface
bInterfaceNumber : 0x0
bAlternateSetting : 0x0
bNumEndpoints : 0x2
bInterfaceClass : 0x3 Human Interface Device
bInterfaceSubClass : 0x0
bInterfaceProtocol : 0x0
iInterface : 0x0
ENDPOINT 0x82: Interrupt IN ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x82 IN
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x8 (8 bytes)
bInterval : 0x5
ENDPOINT 0x2: Interrupt OUT ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x2 OUT
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x8 (8 bytes)
bInterval : 0x5
Failures: 48
No data read
Ready.-
Here is the USB trace of this failing code:
0 InfoStart 23:07:22.463 00:00:00.000 00:00:00.000
PNP 1 IRP_MN_QUERY_CAPABILITIES Down 23:07:32.703 00:00:10.239 00:00:10.239
PNP 2 IRP_MN_QUERY_CAPABILITIES Up 23:07:32.703 00:00:10.239
00:00:00.000 00:00:00.000 SUCCESS
URB 3 URB_FUNCTION_CLASS_INTERFACE Down 23:07:32.795 00:00:10.332
00:00:00.092 0 bytes OUT PENDING
URB 4 URB_FUNCTION_CONTROL_TRANSFER Up 23:07:32.795 00:00:10.332
00:00:00.000 00:00:00.000 0 bytes OUT SUCCESS
URB 5 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:07:32.795
00:00:10.332 00:00:00.000 8 bytes IN PENDING
URB 6 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:07:32.795
00:00:10.332 00:00:00.000 8 bytes IN PENDING
URB 7 URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Down 23:07:32.795
00:00:10.332 00:00:00.000 258 bytes IN PENDING
URB 8 URB_FUNCTION_CONTROL_TRANSFER Up 23:07:32.795 00:00:10.332
00:00:00.000 00:00:00.000 18 bytes IN SUCCESS
URB 9 URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Down 23:07:32.795
00:00:10.332 00:00:00.000 258 bytes IN PENDING
URB 10 URB_FUNCTION_CONTROL_TRANSFER Up 23:07:32.795 00:00:10.332
00:00:00.000 00:00:00.000 28 bytes IN SUCCESS
IOCTL 11 IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION Down 23:07:33.806
00:00:11.343 00:00:01.010 PENDING
USBINTERFACE 12 IdleNotification Down 23:07:33.806 00:00:11.343
00:00:00.000 PENDING
URB 13 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:07:33.806
00:00:11.343 00:00:00.000 00:00:01.010 0 bytes IN CANCELLED
URB 14 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:07:33.806
00:00:11.343 00:00:00.000 00:00:01.010 0 bytes IN CANCELLED
USBINTERFACE 15 IdleNotification Down 23:07:33.806 00:00:11.343
00:00:00.000 PENDING
16 InfoStop 23:07:38.742 00:00:16.278 00:00:04.935 00:00:16.278
And here is the USB trace of a c++ program, which succeeds in reading
this DMM:
0 InfoStart 23:18:54.186 00:00:00.000 00:00:00.000
PNP 1 IRP_MN_QUERY_ID Down 23:19:03.550 00:00:09.364 00:00:09.364
PNP 2 IRP_MN_QUERY_ID Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 3 IRP_MN_QUERY_CAPABILITIES Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 4 IRP_MN_QUERY_CAPABILITIES Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 SUCCESS
PNP 5 IRP_MN_QUERY_DEVICE_TEXT Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 6 IRP_MN_QUERY_DEVICE_TEXT Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 7 IRP_MN_QUERY_DEVICE_TEXT Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 8 IRP_MN_QUERY_DEVICE_TEXT Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 9 IRP_MN_QUERY_ID Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 10 IRP_MN_QUERY_ID Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 11 IRP_MN_QUERY_ID Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 12 IRP_MN_QUERY_ID Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 13 IRP_MN_QUERY_ID Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 14 IRP_MN_QUERY_ID Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 15 IRP_MN_QUERY_ID Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 16 IRP_MN_QUERY_ID Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 NOT_SUPPORTED
PNP 17 IRP_MN_QUERY_INTERFACE Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 18 IRP_MN_QUERY_INTERFACE Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
PNP 19 IRP_MN_QUERY_BUS_INFORMATION Down 23:19:03.550 00:00:09.364
00:00:00.000
PNP 20 IRP_MN_QUERY_BUS_INFORMATION Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 SUCCESS
PNP 21 IRP_MN_QUERY_RESOURCE_REQUIREMENTS Down 23:19:03.550 00:00:09.364
00:00:00.000
PNP 22 IRP_MN_QUERY_RESOURCE_REQUIREMENTS Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 NOT_SUPPORTED
PNP 23 IRP_MN_QUERY_RESOURCES Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 24 IRP_MN_QUERY_RESOURCES Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 NOT_SUPPORTED
PNP 25 IRP_MN_DEVICE_ENUMERATED Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 26 IRP_MN_QUERY_INTERFACE Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 27 IRP_MN_QUERY_INTERFACE Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 NOT_SUPPORTED
PNP 28 IRP_MN_DEVICE_ENUMERATED Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 SUCCESS
PNP 29 IRP_MN_QUERY_LEGACY_BUS_INFORMATION Down 23:19:03.550
00:00:09.364 00:00:00.000
PNP 30 IRP_MN_QUERY_LEGACY_BUS_INFORMATION Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 NOT_SUPPORTED
PNP 31 IRP_MN_QUERY_RESOURCE_REQUIREMENTS Down 23:19:03.550 00:00:09.364
00:00:00.000
PNP 32 IRP_MN_QUERY_RESOURCE_REQUIREMENTS Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 NOT_SUPPORTED
PNP 33 IRP_MN_FILTER_RESOURCE_REQUIREMENTS Down 23:19:03.550
00:00:09.364 00:00:00.000
PNP 34 IRP_MN_FILTER_RESOURCE_REQUIREMENTS Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 NOT_SUPPORTED
PNP 35 IRP_MN_QUERY_CAPABILITIES Down 23:19:03.550 00:00:09.364
00:00:00.000
PNP 36 IRP_MN_QUERY_CAPABILITIES Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 SUCCESS
PNP 37 IRP_MN_START_DEVICE Down 23:19:03.550 00:00:09.364 00:00:00.000
PNP 38 IRP_MN_START_DEVICE Up 23:19:03.550 00:00:09.364 00:00:00.000
00:00:00.000 SUCCESS
URB 39 URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Down 23:19:03.550
00:00:09.364 00:00:00.000 18 bytes IN PENDING
URB 40 URB_FUNCTION_CONTROL_TRANSFER Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 18 bytes IN SUCCESS
URB 41 URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Down 23:19:03.550
00:00:09.364 00:00:00.000 9 bytes IN PENDING
URB 42 URB_FUNCTION_CONTROL_TRANSFER Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 9 bytes IN SUCCESS
URB 43 URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Down 23:19:03.550
00:00:09.364 00:00:00.000 41 bytes IN PENDING
URB 44 URB_FUNCTION_CONTROL_TRANSFER Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 41 bytes IN SUCCESS
URB 45 URB_FUNCTION_SELECT_CONFIGURATION Down 23:19:03.550 00:00:09.364
00:00:00.000 41 bytes OUT
URB 46 URB_FUNCTION_SELECT_CONFIGURATION Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 41 bytes IN SUCCESS
URB 47 URB_FUNCTION_CLASS_INTERFACE Down 23:19:03.550 00:00:09.364
00:00:00.000 0 bytes OUT PENDING
URB 48 URB_FUNCTION_CONTROL_TRANSFER Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 0 bytes OUT SUCCESS
URB 49 URB_FUNCTION_GET_DESCRIPTOR_FROM_INTERFACE Down 23:19:03.550
00:00:09.364 00:00:00.000 101 bytes IN PENDING
URB 50 URB_FUNCTION_CONTROL_TRANSFER Up 23:19:03.550 00:00:09.364
00:00:00.000 00:00:00.000 37 bytes IN SUCCESS
URB 51 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:03.566
00:00:09.380 00:00:00.015 8 bytes IN PENDING
URB 52 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:03.566
00:00:09.380 00:00:00.000 8 bytes IN PENDING
PNP 53 IRP_MN_QUERY_CAPABILITIES Down 23:19:03.566 00:00:09.380
00:00:00.000
PNP 54 IRP_MN_QUERY_CAPABILITIES Up 23:19:03.566 00:00:09.380
00:00:00.000 00:00:00.000 SUCCESS
PNP 55 IRP_MN_QUERY_PNP_DEVICE_STATE Down 23:19:03.566 00:00:09.380
00:00:00.000
PNP 56 IRP_MN_QUERY_PNP_DEVICE_STATE Up 23:19:03.566 00:00:09.380
00:00:00.000 00:00:00.000 NOT_SUPPORTED
PNP 57 IRP_MN_QUERY_DEVICE_RELATIONS Down 23:19:03.566 00:00:09.380
00:00:00.000
PNP 58 IRP_MN_QUERY_DEVICE_RELATIONS Up 23:19:03.566 00:00:09.380
00:00:00.000 00:00:00.000 SUCCESS
PNP 59 IRP_MN_QUERY_ID Down 23:19:03.566 00:00:09.380 00:00:00.000
PNP 60 IRP_MN_QUERY_ID Up 23:19:03.566 00:00:09.380 00:00:00.000
00:00:00.000 SUCCESS
PNP 61 IRP_MN_QUERY_ID Down 23:19:03.566 00:00:09.380 00:00:00.000
PNP 62 IRP_MN_QUERY_ID Up 23:19:03.566 00:00:09.380 00:00:00.000
00:00:00.000 SUCCESS
PNP 63 IRP_MN_QUERY_DEVICE_RELATIONS Down 23:19:03.566 00:00:09.380
00:00:00.000
PNP 64 IRP_MN_QUERY_DEVICE_RELATIONS Up 23:19:03.566 00:00:09.380
00:00:00.000 00:00:00.000 SUCCESS
URB 65 URB_FUNCTION_CLASS_INTERFACE Down 23:19:07.756 00:00:13.570
00:00:04.190 5 bytes OUT PENDING
URB 66 URB_FUNCTION_CONTROL_TRANSFER Up 23:19:07.756 00:00:13.570
00:00:00.000 00:00:00.000 5 bytes OUT SUCCESS
URB 67 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:19:07.756
00:00:13.570 00:00:00.000 00:00:04.190 8 bytes IN SUCCESS
URB 68 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:07.756
00:00:13.570 00:00:00.000 8 bytes IN PENDING
URB 69 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:19:07.772
00:00:13.586 00:00:00.015 00:00:04.205 8 bytes IN SUCCESS
URB 70 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:07.772
00:00:13.586 00:00:00.000 8 bytes IN PENDING
URB 71 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:19:07.788
00:00:13.601 00:00:00.015 00:00:00.031 8 bytes IN SUCCESS
URB 72 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:07.788
00:00:13.601 00:00:00.000 8 bytes IN PENDING
URB 73 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:19:07.788
00:00:13.601 00:00:00.000 00:00:00.015 8 bytes IN SUCCESS
URB 74 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:07.788
00:00:13.601 00:00:00.000 8 bytes IN PENDING
URB 75 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Up 23:19:07.803
00:00:13.617 00:00:00.015 00:00:00.015 8 bytes IN SUCCESS
URB 76 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER Down 23:19:07.803
00:00:13.617 00:00:00.000 8 bytes IN PENDING
...
How should I change the above pyusb test program to get the DMM results?
Regards - Joe
|
|
From: Hermann H. <her...@we...> - 2016-09-14 11:05:14
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div> <div>I am preparing an Installation Guide for my DSO program.</div> <div>I do not want to do obsolete or redundant work.</div> <div>Therfore I ask the following:</div> <div>* Are there plans for a new version of pyusb1 in the near future?</div> <div>* Are there plans for a Windows Installation Guide?</div> <div>Sincerely Hermann</div> <div> </div></div></body></html> |
|
From: Bob S. <bob...@gm...> - 2016-09-07 23:06:21
|
Follow up if anyone is interested. It would appear that HDO4034's USBTMC interface has non-compliant values in the bInterval field for the interrupt endpoint which is preventing the Mac OS X USB driver from providing properties on the endpoint. Nathan on the libusb-devel mail group suggested a patch to libusb to work around this that works in my testing. See the libusb-devel mail group for more details. I am working with LeCroy to see if they can issue a software/firmware update for the scope to fix this issue. Thanks, Bob On Tue, Sep 6, 2016 at 5:07 PM, Bob Schmanski <bob...@gm...> wrote: > More details of my ongoing debugging. I found and enabled libusb > debugging. Here are the relevant messages during claim_interface(): > > 2016-09-06 17:02:56,824 DEBUG:usb.backend.libusb1:_ > LibUSB.claim_interface(<usb.backend.libusb1._DeviceHandle object at > 0x1070d82d0>, 0) > [19.661232] [00000a0b] libusb: debug [libusb_claim_interface] interface 0 > [19.661742] [00000a0b] libusb: debug [get_endpoints] building table of > endpoints. > [19.661763] [00000a0b] libusb: debug [get_endpoints] interface: 0 pipe 1: > dir: 0 number: 1 > [19.661770] [00000a0b] libusb: debug [get_endpoints] interface: 0 pipe 2: > dir: 1 number: 1 > [19.661779] [00000a0b] libusb: error [get_endpoints] error getting pipe > information for pipe 3: unknown error (0xe0004061) > [19.661982] [00000a0b] libusb: error [darwin_claim_interface] could not > build endpoint table > ------------------------------------------------------------ > --------------- > USBError Traceback (most recent call > last) > > > I'm taking my debugging to the libusb-devel mailing list at this point. > However, if anyone has any thoughts on my problem, I'd be happy to hear > them. > > Thanks, > Bob > > On Tue, Sep 6, 2016 at 4:31 PM, Bob Schmanski <bob...@gm...> > wrote: > >> After further debugging and digging, it does appear that the call to >> "usblib_claim_interface()" is returning the value -99, not "None". "None" >> is the output of _libusb_errno[ret] for return code -99, also defined as >> LIBUSB_ERROR_OTHER. So, the real question is, why does claim_interface() >> return -99? >> >> Thanks, >> Bob >> >> > |
|
From: Bob S. <bob...@gm...> - 2016-09-07 00:07:44
|
More details of my ongoing debugging. I found and enabled libusb debugging. Here are the relevant messages during claim_interface(): 2016-09-06 17:02:56,824 DEBUG:usb.backend.libusb1:_LibUSB.claim_interface(<usb.backend.libusb1._DeviceHandle object at 0x1070d82d0>, 0) [19.661232] [00000a0b] libusb: debug [libusb_claim_interface] interface 0 [19.661742] [00000a0b] libusb: debug [get_endpoints] building table of endpoints. [19.661763] [00000a0b] libusb: debug [get_endpoints] interface: 0 pipe 1: dir: 0 number: 1 [19.661770] [00000a0b] libusb: debug [get_endpoints] interface: 0 pipe 2: dir: 1 number: 1 [19.661779] [00000a0b] libusb: error [get_endpoints] error getting pipe information for pipe 3: unknown error (0xe0004061) [19.661982] [00000a0b] libusb: error [darwin_claim_interface] could not build endpoint table --------------------------------------------------------------------------- USBError Traceback (most recent call last) I'm taking my debugging to the libusb-devel mailing list at this point. However, if anyone has any thoughts on my problem, I'd be happy to hear them. Thanks, Bob On Tue, Sep 6, 2016 at 4:31 PM, Bob Schmanski <bob...@gm...> wrote: > After further debugging and digging, it does appear that the call to > "usblib_claim_interface()" is returning the value -99, not "None". "None" > is the output of _libusb_errno[ret] for return code -99, also defined as > LIBUSB_ERROR_OTHER. So, the real question is, why does claim_interface() > return -99? > > Thanks, > Bob > > |
|
From: Bob S. <bob...@gm...> - 2016-09-06 23:31:47
|
After further debugging and digging, it does appear that the call to "usblib_claim_interface()" is returning the value -99, not "None". "None" is the output of _libusb_errno[ret] for return code -99, also defined as LIBUSB_ERROR_OTHER. So, the real question is, why does claim_interface() return -99? Thanks, Bob |
|
From: Bob S. <bob...@gm...> - 2016-09-06 22:10:12
|
Here is the debug trace output for the "hdo.clear()" statement, in context with the statements leading up to it (I can provide the debug for the "hdo = usbtmc.Instrument(0x05FF,0x1023)" statement also, but it is large and exceeds the max post size without moderator approval): $ ipython Python 2.7.12 (default, Jun 29 2016, 14:05:02) Type "copyright", "credits" or "license" for more information. IPython 5.1.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import usbtmc In [2]: hdo = usbtmc.Instrument(0x05FF,0x1023) In [3]: hdo.clear() 2016-08-31 17:41:33,198 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0) 2016-08-31 17:41:33,198 DEBUG:usb.backend.libusb1:_Lib USB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0, 0, 0) 2016-08-31 17:41:33,198 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0) 2016-08-31 17:41:33,199 DEBUG:usb.backend.libusb1:_Lib USB.open_device(<usb.backend.libusb1._Device object at 0x11079d950>) 2016-08-31 17:41:33,199 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration(<usb.backend.libusb1._DeviceHandle object at 0x1111226d0>) 2016-08-31 17:41:33,199 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0) 2016-08-31 17:41:33,199 DEBUG:usb.backend.libusb1:_Lib USB.is_kernel_driver_active(<usb.backend.libusb1._DeviceHandle object at 0x1111226d0>, 0) 2016-08-31 17:41:33,199 DEBUG:usb.backend.libusb1:_Lib USB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0, 0, 0, 0) 2016-08-31 17:41:33,199 DEBUG:usb.backend.libusb1:_Lib USB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0, 0, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 1, 0, 0, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0, 0, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 2, 0, 0, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0, 0, 0) 2016-08-31 17:41:33,200 DEBUG:usb.backend.libusb1:_Lib USB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x11079d950>, 0) 2016-08-31 17:41:33,201 DEBUG:usb.backend.libusb1:_Lib USB.claim_interface(<usb.backend.libusb1._DeviceHandle object at 0x1111226d0>, 0) --------------------------------------------------------------------------- USBError Traceback (most recent call last) > |
|
From: Bob S. <bob...@gm...> - 2016-09-06 22:03:39
|
Hi,
I'm using PyUSB along with usblib1 and python-usbtmc, and I am getting this
strange error every time I attempt to do anything with an instantiated
"Instrument" object from python-usbtmc with a particular USB device. Other
USB devices work fine with these same Python libraries. What is going on
here? It seems like "None" should never be a valid error number (should
actually be a real number). Any thoughts on what to look for or where to
go next? I'm a realtive newbie to Python debugging, so any pointers to
good debugging practices would be appreciated also.
I am running Mac OS X El Capitan (10.11.6).
Some details of what I am doing:
import usbtmc
hdo = usbtmc.Instrument(0x05FF,0x1023)
hdo.ask('*IDN?')
results in:
USBError: [Errno None] Other error
This exact same sequence (with different USB VID and PID) works with other
gear.
The traceback shows that the lowest level function in usbtmc that causes
this error is "clear()". In other words, this produces the same error:
import usbtmc
hdo = usbtmc.Instrument(0x05FF,0x1023)
hdo.clear()
Any ideas? I may start experimenting with different backends to see if
that yields anything interesting.
Here are some details of my setup:
Python 2.7.12 (see below)
$ brew info libusb
libusb: stable 1.0.20 (bottled), HEAD
Library for USB device access
http://libusb.info
/usr/local/Cellar/libusb/1.0.20 (27 files, 492.9K) *
Poured from bottle on 2016-08-17 at 10:52:34
From: https://github.com/Homebrew/homebrew-core/blob/master/Formul
a/libusb.rb
==> Options
--universal
Build a universal binary
--with-default-log-level-debug
Build with default runtime log level of debug (instead of none)
--without-runtime-logging
Build without runtime logging functionality
--HEAD
Install HEAD version
$ pip show PyUSB
---
Metadata-Version: 2.0
Name: pyusb
Version: 1.0.0
...
$ pip show libusb1
---
Metadata-Version: 2.0
Name: libusb1
Version: 1.5.1
...
$ pip show python-usbtmc
---
Metadata-Version: 2.0
Name: python-usbtmc
Version: 0.7
...
Here is the traceback from iPython at the exception (I will provide the
full DEBUG output in a subsequent posting since otherwise this post exceeds
the max allowable size):
USBError Traceback (most recent call last)
<ipython-input-3-a36f0cb89a8d> in <module>()
----> 1 hdo.clear()
/usr/local/lib/python2.7/site-packages/usbtmc/usbtmc.pyc in clear(self)
634
635 if not self.connected:
--> 636 self.open()
637
638 # Send INITIATE_CLEAR
/usr/local/lib/python2.7/site-packages/usbtmc/usbtmc.pyc in open(self)
336 self.connected = True
337
--> 338 self.clear()
339
340 self.get_capabilities()
/usr/local/lib/python2.7/site-packages/usbtmc/usbtmc.pyc in clear(self)
643 self.iface.index,
644 0x0001,
--> 645 timeout=self.timeout)
646 if (b[0] == USBTMC_STATUS_SUCCESS):
647 # Initiate clear succeeded, wait for completion
/usr/local/lib/python2.7/site-packages/usb/core.pyc in ctrl_transfer(self,
bmRequestType, bRequest, wValue, wIndex, data_or_wLength, timeout)
1032 and rqtype != util.CTRL_TYPE_VENDOR:
1033 interface_number = wIndex & 0xff
-> 1034 self._ctx.managed_claim_interface(self,
interface_number)
1035
1036 ret = self._ctx.backend.ctrl_transfer(
/usr/local/lib/python2.7/site-packages/usb/core.pyc in wrapper(self, *args,
**kwargs)
100 try:
101 self.lock.acquire()
--> 102 return f(self, *args, **kwargs)
103 finally:
104 self.lock.release()
/usr/local/lib/python2.7/site-packages/usb/core.pyc in
managed_claim_interface(self, device, intf)
165
166 if i not in self._claimed_intf:
--> 167 self.backend.claim_interface(self.handle, i)
168 self._claimed_intf.add(i)
169
/usr/local/lib/python2.7/site-packages/usb/_debug.pyc in do_trace(*args,
**named_args)
58 fn = type(args[0]).__name__ + '.' + f.__name__
59 _trace_function_call(logger, fn, *args[1:],
**named_args)
---> 60 return f(*args, **named_args)
61 _interop._update_wrapper(do_trace, f)
62 return do_trace
/usr/local/lib/python2.7/site-packages/usb/backend/libusb1.pyc in
claim_interface(self, dev_handle, intf)
809 @methodtrace(_logger)
810 def claim_interface(self, dev_handle, intf):
--> 811 _check(self.lib.libusb_claim_interface(dev_handle.handle,
intf))
812
813 @methodtrace(_logger)
/usr/local/lib/python2.7/site-packages/usb/backend/libusb1.pyc in
_check(ret)
593 raise NotImplementedError(_strerror(ret))
594 else:
--> 595 raise USBError(_strerror(ret), ret, _libusb_errno[ret])
596
597 return ret
USBError: [Errno None] Other error
|
|
From: Nicolas P. <nic...@aa...> - 2016-09-02 13:48:17
|
Le 02/09/2016 à 11:33, Joe a écrit : > Am 02.09.2016 um 11:22 schrieb Xiaofan Chen: >> On Thu, Sep 1, 2016 at 10:30 PM, Joe <te...@jo...> wrote: >>> We use two DMMs UNI-T UT61B. They have two interfaces each, a RS232C >>> Interface and a USB interface. >>> The RS232C interfaces work well. Without any command before, the DMMs >>> continuously send 2 .. 3 packages of 14 Bytes per second. We get them with a >>> little Python 3.52 script, using PySerial. It's ok. >>> >>> But the younger of our computers have no RS232C comports, and I don't want >>> to use virtual comports. So I try to use the USB interfaces of the DMMs with >>> PyUSB 1.0, but somethin is wrong with this test script (using Win10 Version >>> 1607, 64 bit): >> You need to check what kind of USB protocol the USB interface uses. >> Maybe it is also a USB Serial Port and you can use the PySerial. If it >> is not a USB serial port and you do not know the communication protocol, >> then you have to carry out reverse engineering. >> >> Google seems to say that sigrok supports it. You can try ask there >> for the protocol. >> https://sigrok.org/wiki/UNI-T_UT61B >> > Thank you, Xiaofan, I'll look at sigrok. > In the mean time I tried another attempt: > > import usb.util > import usb.backend.libusb1 > > def Gosub(): > failures = 0 > failuresmaximum = 48 > dev = usb.core.find (idVendor = 0x1a86, idProduct = 0xe008) # > Multimeter UT61B > if dev == None: > print ('Multimeter UT61B not found') > else: > print ('Multimeter UT61B was found') > print ('dev:\n' + str (dev) + '\n') > dev.set_configuration () > ep = dev [0] [0,0] [0] > if ep == None: > print ('ep is None') > else: > data = None > while failures < failuresmaximum: > try: > data = dev.read (ep.bEndpointAddress, ep.wMaxPackeSize) > print ('Success. len (date): ' + len (date)) > except: > failures += 1 > print ('Failures: ' + str (failures)) > if data == None: > print ('No data read') > else: > for ss in data: > print (str (ss)) > > print ('Starting') > Gosub () > print ('Ready.-') > > Output: > > Starting > Multimeter UT61B was found > dev: > DEVICE ID 1a86:e008 on Bus 003 Address 003 ================= > bLength : 0x12 (18 bytes) > bDescriptorType : 0x1 Device > bcdUSB : 0x100 USB 1.0 > bDeviceClass : 0x0 Specified at interface > bDeviceSubClass : 0x0 > bDeviceProtocol : 0x0 > bMaxPacketSize0 : 0x8 (8 bytes) > idVendor : 0x1a86 > idProduct : 0xe008 > bcdDevice : 0x1200 Device 18.0 > iManufacturer : 0x1 WCH.CN > iProduct : 0x2 USB to Serial > iSerialNumber : 0x0 > bNumConfigurations : 0x1 > CONFIGURATION 1: 100 mA ================================== > bLength : 0x9 (9 bytes) > bDescriptorType : 0x2 Configuration > wTotalLength : 0x29 (41 bytes) > bNumInterfaces : 0x1 > bConfigurationValue : 0x1 > iConfiguration : 0x4 Error Accessing String > bmAttributes : 0x80 Bus Powered > bMaxPower : 0x32 (100 mA) > INTERFACE 0: Human Interface Device ==================== > bLength : 0x9 (9 bytes) > bDescriptorType : 0x4 Interface > bInterfaceNumber : 0x0 > bAlternateSetting : 0x0 > bNumEndpoints : 0x2 > bInterfaceClass : 0x3 Human Interface Device > bInterfaceSubClass : 0x0 > bInterfaceProtocol : 0x0 > iInterface : 0x0 > ENDPOINT 0x82: Interrupt IN ========================== > bLength : 0x7 (7 bytes) > bDescriptorType : 0x5 Endpoint > bEndpointAddress : 0x82 IN > bmAttributes : 0x3 Interrupt > wMaxPacketSize : 0x8 (8 bytes) > bInterval : 0x5 > ENDPOINT 0x2: Interrupt OUT ========================== > bLength : 0x7 (7 bytes) > bDescriptorType : 0x5 Endpoint > bEndpointAddress : 0x2 OUT > bmAttributes : 0x3 Interrupt > wMaxPacketSize : 0x8 (8 bytes) > bInterval : 0x5 > > Failures: 48 > No data read > Ready.- > > Does anybody see the mistake? Your device is a HID device. You can't use PyUSB with HID devices under Windows. For HID devices I use this : https://pypi.python.org/pypi/hid/0.1.1 Nicolas > > Thank you - Joe > > > ------------------------------------------------------------------------------ > _______________________________________________ > pyusb-users mailing list > pyu...@li... > https://lists.sourceforge.net/lists/listinfo/pyusb-users > . > -- *Nicolas PINAULT R&D electronics engineer *** ni...@aa... <mailto:ni...@aa...> *AATON-Digital* 38000 Grenoble - France Tel +33 4 7642 9550 http://www.aaton.com http://www.transvideo.eu French Technologies for Film and Digital Cinematography Follow us on Twitter @Aaton_Digital @Transvideo_HD Like us on Facebook https://www.facebook.com/AatonDigital |
|
From: Joe <te...@jo...> - 2016-09-02 09:33:12
|
Am 02.09.2016 um 11:22 schrieb Xiaofan Chen: > On Thu, Sep 1, 2016 at 10:30 PM, Joe <te...@jo...> wrote: >> >> We use two DMMs UNI-T UT61B. They have two interfaces each, a RS232C >> Interface and a USB interface. >> The RS232C interfaces work well. Without any command before, the DMMs >> continuously send 2 .. 3 packages of 14 Bytes per second. We get them with a >> little Python 3.52 script, using PySerial. It's ok. >> >> But the younger of our computers have no RS232C comports, and I don't want >> to use virtual comports. So I try to use the USB interfaces of the DMMs with >> PyUSB 1.0, but somethin is wrong with this test script (using Win10 Version >> 1607, 64 bit): > You need to check what kind of USB protocol the USB interface uses. > Maybe it is also a USB Serial Port and you can use the PySerial. If it > is not a USB serial port and you do not know the communication protocol, > then you have to carry out reverse engineering. > > Google seems to say that sigrok supports it. You can try ask there > for the protocol. > https://sigrok.org/wiki/UNI-T_UT61B > Thank you, Xiaofan, I'll look at sigrok. In the mean time I tried another attempt: import usb.util import usb.backend.libusb1 def Gosub(): failures = 0 failuresmaximum = 48 dev = usb.core.find (idVendor = 0x1a86, idProduct = 0xe008) # Multimeter UT61B if dev == None: print ('Multimeter UT61B not found') else: print ('Multimeter UT61B was found') print ('dev:\n' + str (dev) + '\n') dev.set_configuration () ep = dev [0] [0,0] [0] if ep == None: print ('ep is None') else: data = None while failures < failuresmaximum: try: data = dev.read (ep.bEndpointAddress, ep.wMaxPackeSize) print ('Success. len (date): ' + len (date)) except: failures += 1 print ('Failures: ' + str (failures)) if data == None: print ('No data read') else: for ss in data: print (str (ss)) print ('Starting') Gosub () print ('Ready.-') Output: Starting Multimeter UT61B was found dev: DEVICE ID 1a86:e008 on Bus 003 Address 003 ================= bLength : 0x12 (18 bytes) bDescriptorType : 0x1 Device bcdUSB : 0x100 USB 1.0 bDeviceClass : 0x0 Specified at interface bDeviceSubClass : 0x0 bDeviceProtocol : 0x0 bMaxPacketSize0 : 0x8 (8 bytes) idVendor : 0x1a86 idProduct : 0xe008 bcdDevice : 0x1200 Device 18.0 iManufacturer : 0x1 WCH.CN iProduct : 0x2 USB to Serial iSerialNumber : 0x0 bNumConfigurations : 0x1 CONFIGURATION 1: 100 mA ================================== bLength : 0x9 (9 bytes) bDescriptorType : 0x2 Configuration wTotalLength : 0x29 (41 bytes) bNumInterfaces : 0x1 bConfigurationValue : 0x1 iConfiguration : 0x4 Error Accessing String bmAttributes : 0x80 Bus Powered bMaxPower : 0x32 (100 mA) INTERFACE 0: Human Interface Device ==================== bLength : 0x9 (9 bytes) bDescriptorType : 0x4 Interface bInterfaceNumber : 0x0 bAlternateSetting : 0x0 bNumEndpoints : 0x2 bInterfaceClass : 0x3 Human Interface Device bInterfaceSubClass : 0x0 bInterfaceProtocol : 0x0 iInterface : 0x0 ENDPOINT 0x82: Interrupt IN ========================== bLength : 0x7 (7 bytes) bDescriptorType : 0x5 Endpoint bEndpointAddress : 0x82 IN bmAttributes : 0x3 Interrupt wMaxPacketSize : 0x8 (8 bytes) bInterval : 0x5 ENDPOINT 0x2: Interrupt OUT ========================== bLength : 0x7 (7 bytes) bDescriptorType : 0x5 Endpoint bEndpointAddress : 0x2 OUT bmAttributes : 0x3 Interrupt wMaxPacketSize : 0x8 (8 bytes) bInterval : 0x5 Failures: 48 No data read Ready.- Does anybody see the mistake? Thank you - Joe |
|
From: Xiaofan C. <xia...@gm...> - 2016-09-02 09:22:12
|
On Thu, Sep 1, 2016 at 10:30 PM, Joe <te...@jo...> wrote: > > > We use two DMMs UNI-T UT61B. They have two interfaces each, a RS232C > Interface and a USB interface. > The RS232C interfaces work well. Without any command before, the DMMs > continuously send 2 .. 3 packages of 14 Bytes per second. We get them with a > little Python 3.52 script, using PySerial. It's ok. > > But the younger of our computers have no RS232C comports, and I don't want > to use virtual comports. So I try to use the USB interfaces of the DMMs with > PyUSB 1.0, but somethin is wrong with this test script (using Win10 Version > 1607, 64 bit): You need to check what kind of USB protocol the USB interface uses. Maybe it is also a USB Serial Port and you can use the PySerial. If it is not a USB serial port and you do not know the communication protocol, then you have to carry out reverse engineering. Google seems to say that sigrok supports it. You can try ask there for the protocol. https://sigrok.org/wiki/UNI-T_UT61B -- Xiaofan |
|
From: Joe <te...@jo...> - 2016-09-01 14:42:57
|
We use two DMMs UNI-T UT61B. They have two interfaces each, a RS232C
Interface and a USB interface.
The RS232C interfaces work well. Without any command before, the DMMs
continuously send 2 .. 3 packages of 14 Bytes per second. We get them
with a little Python 3.52 script, using PySerial. It's ok.
But the younger of our computers have no RS232C comports, and I don't
want to use virtual comports. So I try to use the USB interfaces of the
DMMs with PyUSB 1.0, but somethin is wrong with this test script (using
Win10 Version 1607, 64 bit):
import usb.util
import usb.backend.libusb1
def Gosub():
failures = 0
failuresmaximum = 48
dev = usb.core.find (idVendor = 0x1a86, idProduct = 0xe008) #
Multimeter UT61B
if dev == None:
print ('Multimeter UT61B not found')
else:
print ('Multimeter UT61B was found')
dev.set_configuration (1)
cfg = dev.get_active_configuration()
intf = cfg [(0, 0)]
ep = usb.util.find_descriptor (intf, custom_match = \
lambda e:
usb.util.endpoint_direction (e.bEndpointAddress) == \
usb.util.ENDPOINT_IN)
if ep == None:
print ('ep is None')
else:
s = None
while failures < failuresmaximum:
try:
s = ep.read (64, 50)
print ('Success. len (s): ' + len (s))
counter = 0
except:
failures += 1
print ('Failures: ' + str (failures))
if s == None:
print ('No data read')
else:
for ss in s:
print (str (ss)) # Not decoded; just to check:
something received?
print ('Starting')
Gosub ()
print ('Ready.-')
I get this output:
Starting
Multimeter UT61B was found
Failures: 48
No data read
Ready.-
How to fix - any hint?
Regards - Joe
|
|
From: Hermann H. <her...@we...> - 2016-08-31 07:29:03
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div name="quoted-content"><br/> <br/> < I have edited libusb wiki to warn against using libusb0.sys<br/> < with libusb Windows.<br/> Thank you.</div> <div name="quoted-content">One like<img alt="" class="smiley" src="https://cdn.webde.de/cdn/mail/client/wicket/resource/static-res/---/mc/img/smileys/default/s_33.gif" style="margin: 4px 2px 0; vertical-align: bottom;"/>and one follower!<img src="cid:4f8fb9fbc7e4c23d219d6287d3798e31f597a930a80f67e0c65d391ae99407cd"/></div> </div> </div> </div></div></body></html> |
|
From: Xiaofan C. <xia...@gm...> - 2016-08-28 10:03:55
|
On Thu, Aug 25, 2016 at 9:33 AM, Xiaofan Chen <xia...@gm...> wrote: > On Tue, Aug 23, 2016 at 5:20 AM, Tormod Volden <lis...@gm...> wrote: > >> >> Now when it comes to the libusb <-> kernel hardware driver interaction >> on Windows, it is not easy to get the full overview of possibilities, >> requirements and failure modes. Quoting from >> https://github.com/libusb/libusb/wiki/Windows : >> "libusb0.sys access is done through the libusbK DLL, therefore, if you >> plan to use the libusb-win32/libusb0.sys driver in libusb, you must >> have that library installed. If using a recent version of Zadig, you >> should not have to do anything, at it will install the library for >> you." >> >> Whether this was always (or still!) true I am not sure. >> > > Yes Zadig will install libusbk.dll when installing libusb0.sys > or libusbk.sys driver. However, it is not recommended to use > libusb0.sys (device driver mode or filter driver mode) with > libusb Windows (libusb-1.0 API). > > Ref: https://github.com/libusb/libusb/issues/94 > > In general, you should use WinUSB driver to use libusb > Windows (libusb-1.0 API). > I have edited libusb wiki to warn against using libusb0.sys with libusb Windows. https://github.com/libusb/libusb/wiki/Windows#Driver_Installation -- Xiaofan |
|
From: Hermann H. <her...@we...> - 2016-08-27 07:03:31
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><br/> Hi Xiaofan Chen<br/> <br/> <In general, you should use WinUSB driver to use libusb<br/> <Windows (libusb-1.0 API).<br/> </div> <div style="margin:0 0 10px 0;">I will try that.</div> <div style="margin:0 0 10px 0;">H.H.</div> </div> </div> </div></div></body></html> |
|
From: Xiaofan C. <xia...@gm...> - 2016-08-25 01:33:36
|
On Tue, Aug 23, 2016 at 5:20 AM, Tormod Volden <lis...@gm...> wrote: > > Now when it comes to the libusb <-> kernel hardware driver interaction > on Windows, it is not easy to get the full overview of possibilities, > requirements and failure modes. Quoting from > https://github.com/libusb/libusb/wiki/Windows : > "libusb0.sys access is done through the libusbK DLL, therefore, if you > plan to use the libusb-win32/libusb0.sys driver in libusb, you must > have that library installed. If using a recent version of Zadig, you > should not have to do anything, at it will install the library for > you." > > Whether this was always (or still!) true I am not sure. > Yes Zadig will install libusbk.dll when installing libusb0.sys or libusbk.sys driver. However, it is not recommended to use libusb0.sys (device driver mode or filter driver mode) with libusb Windows (libusb-1.0 API). Ref: https://github.com/libusb/libusb/issues/94 In general, you should use WinUSB driver to use libusb Windows (libusb-1.0 API). -- Xiaofan |
|
From: Hermann H. <her...@we...> - 2016-08-24 10:27:35
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi dear maintainers.</div> <div> </div> <div>I have compiled the results of the pick wrong library issue and some investigations in an issue on github.</div> <div>However I could not attach the PDF file and therefore provide it here.</div> <div> </div> <div>Please study it carefully.</div> <div> </div> <div>I will not be here until september, so you have enough time to think and try to verify or falsify my thesis</div> <div>before you respond.</div> <div> </div> <div><strong>The game is not over.</strong></div> <div><strong>I will be back!</strong></div> <div><strong>I will find these f...... installed libraries!</strong></div> <div> </div> <div>Hermann</div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div name="quoted-content"> </div> </div> </div> </div></div></body></html> |
|
From: Hermann H. <her...@we...> - 2016-08-24 09:34:55
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div> <div>Hi Jeff,</div> <div>I have opened an issue on this topic. Please read it and try to falsify or verfy my thesis.</div> <div>I will not be back to my mailbox before september, so you have ample time.</div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;">So long</div> <div style="margin:0 0 10px 0;">Hermann</div> <div name="quoted-content"> </div> </div> </div> </div></div></body></html> |
|
From: Karl P. <ka...@tw...> - 2016-08-23 17:25:32
|
Tormod Volden <lis...@gm...> wrote: > On Tue, Aug 23, 2016 at 3:05 PM, Jay Aurabind wrote: > > > > I just managed to get it working. Simply added an exception for the > > try block for ValueError: continue > > > > Is this an acceptable solution generally? Is there a point in asking > > pyOCD to take it ? > > I would try to filter on vid/pid first. Are there many > different vid/pids possible, but they all have "CMSIS-DAP" in > the product string? > > IMO manually filtering through the product string is a bad > idea, but if it cannot be avoided, yes, you should an exception > for devices where you can't retrieve the product string. yeah, well, would be good to tell ARM that. A device class or interface class or anything, but no, by definition, a CMSIS-DAP device is identified _only_ by the product string containing "CMSIS-DAP" Thanks ARM! |
|
From: Jay A. <jay...@gm...> - 2016-08-23 16:17:46
|
On 23 August 2016 at 21:08, Tormod Volden <lis...@gm...> wrote: > On Tue, Aug 23, 2016 at 3:05 PM, Jay Aurabind wrote: >> >> I just managed to get it working. Simply added an exception for the >> try block for ValueError: continue >> >> Is this an acceptable solution generally? Is there a point in asking >> pyOCD to take it ? > > I would try to filter on vid/pid first. Are there many different > vid/pids possible, but they all have "CMSIS-DAP" in the product > string? > I'm not sure if that can be generalized. The actual name it shows is "DAPLink CMSIS-DAP". Unless the debug adapter is running the DAPLink firmware[1], which is an open source project[2], this name can could be anything else. The device I am connecting to, is a baseboard for Hexiwear which has an OpenSDA debug port, which happens to have support for running DAPLink firmware. [1]:https://developer.mbed.org/handbook/DAPLink [2]:https://github.com/mbedmicro/DAPLink > IMO manually filtering through the product string is a bad idea, but > if it cannot be avoided, yes, you should an exception for devices > where you can't retrieve the product string. > Looks like that is quickest hack to get it fixed until pyOCD devs figure out a proper way to do it. I'm gonna add these 3 lines right after 88 and request them to take it: except ValueError: if board.idVendor is 0xd28 and board.idProduct is 0x204: continue > Try for instance "lsusb -v" versus "sudo lsusb -v" - a normal user > will often not see the product strings listed, whereas the superuser > does. > > Regards, > Tormod > > ------------------------------------------------------------------------------ > _______________________________________________ > pyusb-users mailing list > pyu...@li... > https://lists.sourceforge.net/lists/listinfo/pyusb-users -- Thanks and Regards, Aurabindo J |
|
From: Tormod V. <lis...@gm...> - 2016-08-23 15:38:52
|
On Tue, Aug 23, 2016 at 3:05 PM, Jay Aurabind wrote: > > I just managed to get it working. Simply added an exception for the > try block for ValueError: continue > > Is this an acceptable solution generally? Is there a point in asking > pyOCD to take it ? I would try to filter on vid/pid first. Are there many different vid/pids possible, but they all have "CMSIS-DAP" in the product string? IMO manually filtering through the product string is a bad idea, but if it cannot be avoided, yes, you should an exception for devices where you can't retrieve the product string. Try for instance "lsusb -v" versus "sudo lsusb -v" - a normal user will often not see the product strings listed, whereas the superuser does. Regards, Tormod |
|
From: Tormod V. <lis...@gm...> - 2016-08-23 15:32:18
|
On Tue, Aug 23, 2016 at 3:02 PM, Jay Aurabind wrote:
> On 23 August 2016 at 16:40, Tormod Volden wrote:
>> It usually shouldn't try to retrieve descriptor strings from other
>> devices than the ones targeted. The device descriptor (retrieved and
>> cached by the OS) is usually enough to filter out the right devices
>> (e.g. filtering on vid/pid). How are the devices filtered in your
>> program?
>
> Here is the code which creates the error:
>
> all_devices = usb.core.find(find_all=True)
>
> if not all_devices:
> logging.debug("No device connected")
> return []
>
> boards = []
>
> # iterate on all devices found
> for board in all_devices:
> interface_number = -1
> try:
> # The product string is read over USB when accessed.
> # This can cause an exception to be thrown if the device
> # is malfunctioning.
> product = board.product
>
> This is how pyusb is used. The program doesn't go beyond the last line
> shown above, if run as normal user. See full source github[1].
There is a grave mismatch between comment and code here:
# find all devices matching the vid/pid specified
all_devices = usb.core.find(find_all=True)
There is nothing in the code that filters on vid/pid.
usb.core.find(find_all=True) will return all devices the OS know of.
Then the code goes on to request the product string from all these
devices... It can be expected that this goes wrong on devices for
which the user has no permissions.
>
> [1]:https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/pyDAPAccess/interface/pyusb_backend.py#L88
>
>>
>>>> Some devices can be released from the kernel, and then be available
>>>> for you to manipulate it through the device node (and thus via e.g
>>>> libusb and pyusb). See for instance the libusb_detach_kernel_driver()
>>>> function in libusb. However, in most cases people use libusb and pyusb
>>>> to access devices that have no kernel driver.
>>>
>>> In that case, even the root should not be able to write to those
>>> devices, since its exclusively managed by kernel. Then how come I get
>>> no errors when I run pyocd with root permissions ?
>>
>> You won't be able to claim any of its interfaces, but I suppose some
>> control transfers are still allowed.
The pyocd code actually goes on to detach any kernel driver (line
111). This might succeed if it is run by root (or user with sufficient
permissions).
Tormod
|
13 messages has been excluded from this view by a project administrator.
![https://cdn.webde.de/cdn/mail/client/wicket/resource/static-res/---/mc/img/smileys/default/s_33.gif"](https://cdn.webde.de/cdn/mail/client/wicket/resource/static-res/---/mc/img/smileys/default/s_33.gif"){kind=link}