Jeff Rowberg
2014-12-06 21:06:06 UTC
Darn, I forgot a helpful subject line. Sorry about that. Fixed now...though
that probably means I broke the thread structure.
I was able to re-test on a laptop running an older version of Linux Mint
natively (no VM), and after a few compatibility tweaks, I got it to
communicate correctly AND there is no weird delay anymore! I believe the
issue may be specific to the VM, although I am really unsure why, and would
love any insight anyone might have. I also need to do some more testing on
a different machine with the latest Ubuntu, so that I can more confidently
point at the VM environment as the cause rather than something else.
In case anyone is interested, I've pushed the relevant code up to a Github
repo:
https://github.com/jrowberg/keyglove/blob/master/host/python/kglib.py#L335
If I learn anything more, I'll be sure to follow up.
--Jeff
On Sat, Dec 6, 2014 at 12:55 AM, Jeff Rowberg <***@rowberg.net> wrote:
Hello PyUSB community!
that probably means I broke the thread structure.
I was able to re-test on a laptop running an older version of Linux Mint
natively (no VM), and after a few compatibility tweaks, I got it to
communicate correctly AND there is no weird delay anymore! I believe the
issue may be specific to the VM, although I am really unsure why, and would
love any insight anyone might have. I also need to do some more testing on
a different machine with the latest Ubuntu, so that I can more confidently
point at the VM environment as the cause rather than something else.
In case anyone is interested, I've pushed the relevant code up to a Github
repo:
https://github.com/jrowberg/keyglove/blob/master/host/python/kglib.py#L335
If I learn anything more, I'll be sure to follow up.
--Jeff
On Sat, Dec 6, 2014 at 12:55 AM, Jeff Rowberg <***@rowberg.net> wrote:
Hello PyUSB community!
I'm trying to solve a raw HID write delay problem when using PyUSB 1.0.0b2
with Python 2.7 in an Ubuntu 14.10 Linux environment, actually running
inside a VMware Player virtual machine on a Windows 8.1 64-bit desktop. I'm
communicating from the Python script to a Teensy++ configured in Raw HID
mode. I have been able to make this work perfectly in Windows using
PyWinUSB, and using the Teensy++ manufacturer's own RawHID C demo code, and
*almost* in Linux with PyUSB. In fact, I even get the data moving back and
forth over the IN and OUT interrupt endpoints, intact and in order.
The problem is that there is a very measurable delay (usually between
200ms and 500ms, varying) whenever I try to use the .write() method to send
data to the device. I receive it instantly whenever anything new comes in;
I've narrowed down the delay very specifically to the single line that
self.pyusb_endpoint_out.write(raw_packet)
The "raw_packet" variable is an array of bytes. The data is delivered
properly, and everything else works great on the device and in the response
that comes back, so I know it's being interpreted correctly. It just takes
way longer than it should.
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 : 0x2 Teensyduino RawHID
ENDPOINT 0x83: Interrupt IN ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x83 IN
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x40 (64 bytes)
bInterval : 0x1
ENDPOINT 0x4: Interrupt OUT ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x4 OUT
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x40 (64 bytes)
bInterval : 0x1
I read data from 0x83 and send it out 0x4. Both are interrupt endpoints,
so I would assume this should be pretty straightforward.
The Python script is fairly complicated, so I won't post the whole thing
here (though I will be happy to post it on Github if needed; that's where
it will end up, but I was kinda hoping to actually make it work first).
1. It's running in VM of Ubuntu 14.10, on a Win8 machine. I can try a
non-VM Ubuntu environment, but it will take some time to arrange that.
2. The script starts a separate daemon thread which constantly tries to
read from endpoint 0x83, timing out every second and retrying whenever
there is no data available. This approach seems to work perfectly, but I'm
wondering if it has some adverse effect on the ability to write data in a
timely fashion. The thread runs in a single handler function that looks
# handler for reading incoming raw HID packets via PyUSB (thread
started in local connect() method)
ret =
self.devobj.read(self.pyusb_endpoint_in.bEndpointAddress,
self.pyusb_endpoint_in.wMaxPacketSize)
self.responses_pending =
self.responses_pending - 1
self.on_api_idle()
# PyUSB timeout, probably just no data
sys.exc_clear()
# "Input/Output Error" or "No such device", this is
serious
self.on_unplugged()
self.disconnect()
raise KeygloveHIDError("PyUSB read thread error: %s" %
e)
3. The packets being sent are 64 bytes in size. The trailing bytes beyond
the important part of the data payload are padded to zeros to fill the
whole size. I had originally tried without doing this (by accident, in
fact), so the byte array I wrote was only perhaps 5-10 bytes long, and then
realized that I'd forgotten to pad it. However, the same delay exists
whether or not the bytes are zero-padded out to the full report size, so
that isn't it.
Given the above, is there ANY reason why there would be a 100+ millisecond
seemingly arbitrary delay sending a 64-byte packet?
--Jeff
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
pyusb-users mailing list
https://lists.sourceforge.net/lists/listinfo/pyusb-users
with Python 2.7 in an Ubuntu 14.10 Linux environment, actually running
inside a VMware Player virtual machine on a Windows 8.1 64-bit desktop. I'm
communicating from the Python script to a Teensy++ configured in Raw HID
mode. I have been able to make this work perfectly in Windows using
PyWinUSB, and using the Teensy++ manufacturer's own RawHID C demo code, and
*almost* in Linux with PyUSB. In fact, I even get the data moving back and
forth over the IN and OUT interrupt endpoints, intact and in order.
The problem is that there is a very measurable delay (usually between
200ms and 500ms, varying) whenever I try to use the .write() method to send
data to the device. I receive it instantly whenever anything new comes in;
I've narrowed down the delay very specifically to the single line that
self.pyusb_endpoint_out.write(raw_packet)
The "raw_packet" variable is an array of bytes. The data is delivered
properly, and everything else works great on the device and in the response
that comes back, so I know it's being interpreted correctly. It just takes
way longer than it should.
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 : 0x2 Teensyduino RawHID
ENDPOINT 0x83: Interrupt IN ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x83 IN
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x40 (64 bytes)
bInterval : 0x1
ENDPOINT 0x4: Interrupt OUT ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x4 OUT
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x40 (64 bytes)
bInterval : 0x1
I read data from 0x83 and send it out 0x4. Both are interrupt endpoints,
so I would assume this should be pretty straightforward.
The Python script is fairly complicated, so I won't post the whole thing
here (though I will be happy to post it on Github if needed; that's where
it will end up, but I was kinda hoping to actually make it work first).
1. It's running in VM of Ubuntu 14.10, on a Win8 machine. I can try a
non-VM Ubuntu environment, but it will take some time to arrange that.
2. The script starts a separate daemon thread which constantly tries to
read from endpoint 0x83, timing out every second and retrying whenever
there is no data available. This approach seems to work perfectly, but I'm
wondering if it has some adverse effect on the ability to write data in a
timely fashion. The thread runs in a single handler function that looks
# handler for reading incoming raw HID packets via PyUSB (thread
started in local connect() method)
ret =
self.devobj.read(self.pyusb_endpoint_in.bEndpointAddress,
self.pyusb_endpoint_in.wMaxPacketSize)
self.responses_pending =
self.responses_pending - 1
self.on_api_idle()
# PyUSB timeout, probably just no data
sys.exc_clear()
# "Input/Output Error" or "No such device", this is
serious
self.on_unplugged()
self.disconnect()
raise KeygloveHIDError("PyUSB read thread error: %s" %
e)
3. The packets being sent are 64 bytes in size. The trailing bytes beyond
the important part of the data payload are padded to zeros to fill the
whole size. I had originally tried without doing this (by accident, in
fact), so the byte array I wrote was only perhaps 5-10 bytes long, and then
realized that I'd forgotten to pad it. However, the same delay exists
whether or not the bytes are zero-padded out to the full report size, so
that isn't it.
Given the above, is there ANY reason why there would be a 100+ millisecond
seemingly arbitrary delay sending a 64-byte packet?
--Jeff
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
pyusb-users mailing list
https://lists.sourceforge.net/lists/listinfo/pyusb-users